Slackware-Current

[Grogan]

That's too bad, Slackware has gotten too complex for its britches (i.e. no package dependencies). It's no longer the easy to maintain by hand, easy to customize system that it used to be and breakage is entirely possible.

[Zema Bus]

I did a fresh install of Slackware today. still a few things to do but I got all the basic things configured and working including Grub. XFCE only this time. I dropped in the last kernel I compiled in the previous Slackware install and I'm running on it now until I do 6.15, initrd-free!

[Grogan]

The problem with even that is (using XFCE instead of KDE Asthma), there's still a metric shit tonne of libraries in L you don't need, that you're probably installing because it's impractical to cherry pick. See, I can't stomach that, I'd have to painstakingly remove packages (it is too onerous to figure out during the install, who has patience for that lol) and that would be a pain in the ass to sort.

Hopefully this one won't blow up on you. Stick to the Slackware repos for slackpkg or whatever tool you're going to use.

Yeah, initrds are for sissies

(and for hardware enumeration, it is best to have any permanent hardware drivers built in, otherwise udev in the initramfs is going to do it in arbitrary order, changing resource assignments and device numbers, haphazardly. I fucking HATE that shit you get with distro dogfood kernels)

[Zema Bus]

I had some trouble with it repeatedly disabling sound. Sound would work just fine and then later it wouldn't. In the audio settings my primary Intel audio would look ok but there would be no sound. Switching it to another sound source, either an external USB sound adapter or displayport (via the audio jack on one of my displays) would work for a while, but eventually it would disable those, and at one point no sound sources showed up in the audio settings, just "dummy output". In alsamixer I kept finding automute enabled after previously disabling it. I went ahead and updated Slackware and compiled 6.15. After booting back in I had to disable automute again in alsamixer but so far it's still working.

This is the most recent version of XFCE, out of the box it looks better than it used to, with dark themed panels and moderately dark default wallpaper. But it has the same problem that previous versions of XFCE have had in recent years in that if transparency is used it makes panel icons and other panel elements transparent too, and if more than a mild amount is used they will look all faded out. Right now I have a moderate amount of transparency in the panels, about 70% opacity, and it's very hard to read the clock. I used to be able to take it to 50% or less opacity without any problem. I'll see if I can find some way to keep the icons from becoming transparent along with everything else.

[Zema Bus]

I found something that helped a lot. In the panel settings under the Appearance tab, with 'Solid color' as the style, click on the color and add a custom color (the + button), then slide the opacity slider (hard to see the slider but it's right under the color range diagram) to the far left side until the resulting color is almost or fully transparent. Then after applying that setting, back in the previous window fine tune the opacity to the desired effect.

[Grogan]

I compile my xfce4-settings with --disable-sound-settings

I don't want anything configuring my audio. What I do use is the xfce4 volume control plugin though. For getting at other settings I'd just pop open pavucontrol or something. I keep my hdmi audio device unconfigured, so I only have the one.

The main reason I don't want the new XFCE is because I would die without my customized black plasmafire style with the glowy orange gradient. It's got a shaped panel with image, that I really like and that will be broken because they have deprecated the thing that it uses.

That's what you have to do, tweak a style you like yourself. I'm never happy with anything out of the box.

[Zema Bus]

I've been having a weird issue with my auto-hiding bottom panel that has all my launchers - it only works properly for a brief while during a session, then it no longer unhides when the mouse cursor is moved down there...but if I move the mouse to the bottom of the other display it then unhides. I couldn't figure out why it started doing that, it's nothing to do with which display is primary. I didn't find anything on a search, though it's not an easy thing to find search results for. I finally resolved it by changing my bottom panel to be more like a traditional XFCE bottom panel - just wide enough to contain my launchers and expandable, and I set it to "intelligently" hide, so that it remains visible and only hides if a window moves into its space. I also minimized its height. So far so good, and with it shrunk down I don't mind it being on the desktop all the time so much.

slackwarexfce.jpg

Yeah, I still have the default XFCE wallpaper, I'll change it eventually but this one I didn't hate so I let it stay for a little while

[Grogan]

I hate panel autohide malfunctions... I used to have KDE do that and have to delete my configs to get it back and start over.

I use "always" in XFCE for panel auto-hiding.

Do you have a saved session? I don't save sessions because bad parameters can get in there and cause tomfoolery like delays on logging in/out and panel position problems. That's ~/.cache/sessions for me, and probably still the same, unless $XDG_CACHE_HOME is set to something else. Try nuking ~/.cache/sessions

You can also play with the timings, if you create a ~/.config/gtk-3.0/gtk.css file with this:

Code: Select all

#XfcePanelWindow {
   -XfcePanelWindow-popup-delay: 400;
   -XfcePanelWindow-popdown-delay: 100;
}

Why I do it is that I don't like the panel hide delay, I want it to re-auto-hide sooner and 100 works well for me (note that there is still a bit of arbitrary delay, it will be a bit longer than 100 ms). Don't make that number 0 or the panel may not auto-show.

You can reload the panel with:

Code: Select all

xfce4-panel -r

If you have a saved session, you might have to delete ~/.cache/sessions for it to work.

[Zema Bus]

Thanks Grogan I'll try that. I didn't think I had a saved session, when I launch XFCE nothing is left open from the prior session, but on looking in my .cache/sessions there are a lot of *.state files.

[Zema Bus]

I ran into this compiling kernel 6.19.8:

Code: Select all

/usr/bin/ld.bfd: vmlinux.o: in function `add_root_nvdimm_bridge':
acpi.c:(.text+0xeb830f): undefined reference to `devm_cxl_add_nvdimm_bridge'
make[2]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1
make[1]: *** [/usr/src/linux-6.19.8/Makefile:1276: vmlinux] Error 2
make: *** [Makefile:248: __sub-make] Error 2

I checked the Slackware forums and there were similar reports for the most recent releases of 6.19 and 6.18 in the kernel thread. Not 100% the same but close, and from the last few days.

Patrick Volkerdi posted this:

Install the kernel-headers from /testing first.

EDIT: Nevermind, 32-bit built but x86_64 still runs into that error. Back to the drawing board... might end up having to wait for 6.18.18.

EDIT2:

Code: Select all

--- ./drivers/cxl/acpi.c.orig   2026-03-12 06:15:13.000000000 -0500
+++ ./drivers/cxl/acpi.c        2026-03-12 16:45:58.723922521 -0500
@@ -956,7 +956,7 @@
        if (rc < 0)
                return rc;
 
-       if (IS_ENABLED(CONFIG_CXL_PMEM))
+       if (IS_REACHABLE(CONFIG_CXL_PMEM))
                rc = device_for_each_child(&root_port->dev, root_port,
                                           add_root_nvdimm_bridge);
        if (rc < 0)

Not sure if that patch would work in my case, or how to apply it.

[Grogan]

That patch isn't going to apply to Linux 6.19.8, but it's just lines way out of context. Here, I made you a new one, done properly (with -p1 depth)

Code: Select all

--- a/drivers/cxl/acpi.c	2026-03-13 12:26:05.000000000 -0400
+++ b/drivers/cxl/acpi.c	2026-03-17 05:37:35.984054247 -0400
@@ -972,7 +972,7 @@
 	if (rc < 0)
 		return rc;
 
-	if (IS_ENABLED(CONFIG_CXL_PMEM))
+	if (IS_REACHABLE(CONFIG_CXL_PMEM))
 		rc = device_for_each_child(&root_port->dev, root_port,
 					   add_root_nvdimm_bridge);
 	if (rc < 0)

First, save that as filename.patch (or anything, really) and stick it in the directory above your kernel source dir.

You'd apply it by being in the kernel source directory and doing:

Code: Select all

patch -Np1 -i ../filename.patch

(note that's one way to apply a patch... there are several command variants, e.g. "cat ../filename.patch | patch -p1" or "patch -p1 < ../filename.patch" and other silliness)

If you're using a .SlackBuild script, add the patch command to it (it will probably have patches where you can follow example... just be mindful that this has to be -p1

Alternatively... just don't build that driver (Intel Compute Express Link... you wouldn't have one of those memory controllers). Set it to N with menuconfig or whatever. You'll find it under Device Drivers --> PCI Support

[Zema Bus]

Thanks Grogan

[Zema Bus]

The patch worked!

I considered just going into menuconfig, but it's been a long day and I haven't been in there in years. At some point I will though.

[Grogan]

The quickest path to getting it done, I suppose

Glad you got it. But yes, you should trim the blubber from that config.

[Grogan]

I was a bit too incoherent to give a good answer last night. I had later read that slackware thread though when curious about the reason, and it's a kernel config issue. Petri Kaukasoina has the clue (I quit reading there as it makes sense... I don't think that the kernel devs are going to be fixing it like that patch though, it's a user problem, not kernel).

That's why it's unreachable to the linker.

CONFIG_CXL_ACPI=y while CONFIG_CXL_PMEM=m

While you've shut the linker up, what you've actually done is compiled a broken driver (without persistent memory support). Good thing almost nobody would be using it. (That's a shit sandwich that a distro kernel has things like that set to Y in the first place... it's why I don't eat distro dogfood)

That's likely caused by manually enabling things in the distro config (or changing them with sed etc.). See, "menuconfig" (or other proper configuration tools) resolves dependency issues like this. It's why I never say "just edit .config and change that to N" and such anymore.

This explains why I could build that driver (enabled with menuconfig) with or without that patch (yes, I tested it the other night before giving it to you). I was thinking his toolchains were out of whack, but no, it's a build dep issue.

[Zema Bus]

Maybe this weekend I'll go into menuconfig and try recompiling without that driver.

[Grogan]

Yeah, that would be best (disable the ruddy thing anyway), but also, say, disabling it and enabling it again and saving the config would fix that dep issue (forcing CONFIG_CXL_PMEM to Y). Just to illustrate how it's supposed to work.

[Grogan]

Misconfigurations like that aren't supposed to happen anymore, the kconfig system is supposed to enforce it. It did need some more mcgyvering to force y/m when the nvdimm dependency is the wrong state too. I didn't hit it because I knew better when enabling those things to test (Y, not m... I didn't test all m because the Slackware case was Y)

Linux 6.19.9:

cxl/acpi: Fix CXL_ACPI and CXL_PMEM Kconfig tristate mismatch

commit 93d0fcdddc9e7be9d4f42acbe57bc90dbb0fe75d upstream.

Commit e7e222ad73d9 ("cxl: Move devm_cxl_add_nvdimm_bridge() to
cxl_pmem.ko") moves devm_cxl_add_nvdimm_bridge() into the cxl_pmem file,
which has independent config compile options for built-in or module. The
call from cxl_acpi_probe() is guarded by IS_ENABLED(CONFIG_CXL_PMEM),
which evaluates to true for both =y and =m.

When CONFIG_CXL_PMEM=m, a built-in cxl_acpi attempts to reference a
symbol exported by a module, which fails to link. CXL_PMEM cannot simply
be promoted to =y in this configuration because it depends on LIBNVDIMM,
which may itself be =m.

Add a Kconfig dependency to prevent CXL_ACPI from being built-in when
CXL_PMEM is a module. This contrains CXL_ACPI to =m when CXL_PMEM=m,
while still allowing CXL_ACPI to be freely configured when CXL_PMEM is
either built-in or disabled.