SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I thought it was pretty obvious that it wasn't a serious statement.
I was a little confused with your answer too. Hope it will be sorted upstream so the burden doesn't weight more for 32bits machines (still have one running 15.0). Anyway I think I would rather keep emacs up-to-date and stay on 15.0 on that old rig :-D
You can't have both installed but I am not aware of users having switched to emacs-nativecomp looking back.
I implemented it here and yes, there's a noticeable difference in responsiveness, but it does come with a downside: increased footprint.
I built emacs with --with-native-compilation=AOT here and the disk footprint balloons significantly (and it also takes a hell of a time to build). However, if you use native-compilation without AOT then modules are compiled on the fly as needed and stored in a subdirectory of ~/.emacs.d/ for each user resulting in duplication as each user will have their own copy of the cached jit-compiled modules.
If you're a heavy emacs user (I use it all the time) then it's likely worth it. A casual user, might prefer the interpreted build, for the smaller footprint. Basically, it's a "swings and roundabouts" take your choice situation.
To save a little bit of space, what I did was remove any .el file which had a corresponding .elc during packaging. It helps a little with the footprint but might not suit everyone.
After upgrading xfce4-terminal version from 1.1.1 to 1.1.2 on Mon Feb 5 19:54:29 UTC 2024, I faced the same issue as Issue-#299 at xfce4-terminal's gitlab.
==== from #299 ====
I recently updated to xfce4-terminal 1.1.2, and noticed
that when attempting to paste more than one line,
as in pasting something with a newline character included,
the unsafe dialog does not appear.
...
=================== https://gitlab.xfce.org/apps/xfce4-t...l/-/issues/299
And I recompiled xfce4-terminal-1.1.2 by applying the Arch patch below, then confirmed this copy&paste issue fixed for me.
xfce4-terminal-wrong-assert.patch
Code:
From 177fda86451cdeaaea8ed409e6d711b670699a97 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ga=C3=ABl=20Bonithon?= <gael@xfce.org>
Date: Tue, 6 Feb 2024 18:14:04 +0100
Subject: [PATCH] screen: Fix wrong assert
It's always been wrong (or has been for a long time) but de3e7aac
revealed it, because now it's no longer disabled by building with
--disable-debug.
Fixes: de3e7aac72fdcd3e62d69f37ec2570e5d668950a
Closes: #299
---
terminal/terminal-screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/terminal/terminal-screen.c b/terminal/terminal-screen.c
index 6e48b522..dc931ec7 100644
--- a/terminal/terminal-screen.c
+++ b/terminal/terminal-screen.c
@@ -1892,7 +1892,7 @@ terminal_screen_paste_unsafe_text (TerminalScreen *screen,
{
GtkWidget *dialog;
- g_return_if_fail (original_clipboard != GDK_SELECTION_CLIPBOARD && original_clipboard != GDK_SELECTION_PRIMARY);
+ g_return_if_fail (original_clipboard == GDK_SELECTION_CLIPBOARD || original_clipboard == GDK_SELECTION_PRIMARY);
dialog = terminal_screen_unsafe_paste_dialog_new (screen, text);
gtk_widget_show_all (dialog);
--
GitLab
Could we get pipewire and wireplumber broken out into separate packages? This will make it easier to test the packages independent of each other. Right now I'm using WP 0.4.81 with no issues, and it's inconvenient to freeze PW upgrades just to keep WP at a particular version.
Could we get pipewire and wireplumber broken out into separate packages? This will make it easier to test the packages independent of each other. Right now I'm using WP 0.4.81 with no issues, and it's inconvenient to freeze PW upgrades just to keep WP at a particular version.
This is what Patrick does when a really good suggestion has been made.
Sat Feb 10 21:19:10 UTC 2024
l/pipewire-1.0.3-x86_64-3.txz: Rebuilt.
Removed bundled wireplumber.
l/wireplumber-0.4.17-x86_64-1.txz: Added.
This has been broken out as a new package.
Thanks to alex14641 for the suggestion.
This is what Patrick does when a really good suggestion has been made.
Sat Feb 10 21:19:10 UTC 2024
l/pipewire-1.0.3-x86_64-3.txz: Rebuilt.
Removed bundled wireplumber.
l/wireplumber-0.4.17-x86_64-1.txz: Added.
This has been broken out as a new package.
Thanks to alex14641 for the suggestion.
It's good that wireplumber is now a separate package. It's better to trace the problems occured in pipewire. The incident happened when pipewire 1.0.1 onwards on slackware had bluetooth device connection problem. I thought that it was pipewire has a problem at first, but it turns out it was wireplumber all along why bluetooth devices does not on pipewire. Fortunately pipewire devs gave a workaround
In wireplumer doinst.sh.gz, cmp verboses in stdout, not stderr even if it exits with non 0 error, that's strange. The redirection must be 1> /dev/null but the "&&" is good.
Code:
# Toss redundant sample files:
for file in wireplumber.desktop ; do
cmp etc/xdg/autostart/${file} etc/xdg/autostart/${file}.sample 1> /dev/null && rm etc/xdg/autostart/${file}.sample
done
In wireplumer doinst.sh.gz, cmp verboses in stdout, not stderr even if it exits with non 0 error, that's strange. The redirection must be 1> /dev/null but the "&&" is good.
Code:
# Toss redundant sample files:
for file in wireplumber.desktop ; do
cmp etc/xdg/autostart/${file} etc/xdg/autostart/${file}.sample 1> /dev/null && rm etc/xdg/autostart/${file}.sample
done
The redirection is likely done to avoid any useless feedback on your console during package installation. There is no added value in reading "etc/xdg/autostart/wireplumber.desktop etc/xdg/autostart/wireplumber.desktop.sample differ".
But I would rather have achieved the same with "cmp -s" to render the cmp utility silent.
Good-to-go.... a fresh build of mplayer with both enabled now plays the original just fine.
OK, nevermind that request.
Have just discovered that while ffmpeg & mplayer included in the main tree of current and 15.0 etc can-not handle AV1 videos...
both seamonkey & firefox do in-fact play them just fine.
So, untill such time as AV1 capability becomes more needed in ffmpeg & mplayer,
they can both remain as-is and we can use seamonkey or firefox for any AV1 videos that we happen to encounter.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
