Gentoo Desktop

This for a Samba server. I've figured out that it's related to PAM settings, I just haven't figured out what rules I need to properly authenticate.

Ran into a weird issue with HL2, though; I could launch the game and play it, but I couldn't load a saved game.
Apparently, Steam defaults to using the Linux binary (understandable) which seems to have...issues. Forcing Steam to use the Proton layer allows it to use the Windows binary and then I can successfully load a saved game.
 
Ran into an issue with Webex and VirtualBox; well, the issue was VB, but I first noticed it in conjunction with Webex.

Apparently, VB was configured to use Alsa for sound. Not sure how that happened, but regardless it did. So, everything was working fine, near as I could tell, until I went to jump on a Webex call while running VB. I access my customer through a VM on my side (running in VB) and connect to a VM on their side using an application named "Windows App" which is essentially RDP, but don't call it that because it's totally and completely different, see, and you have to use this special Microsoft Windows application to access it.

Anyway, I was doing some training for my customer so was using audio from the remote VM into my VM, and somehow that caused VB to grab Alsa exclusively, so Webex wouldn't work (in fact NOTHING involving my local audio would work; even the sound control panel was unable to do anything).

I went into VB settings for the VM and changed it from using Alsa to PulseAudio, and now things are working much better. Not quite sure what went wrong there.
 
Games seem to be just a little jittery. Specifically, I've noticed that Portal 2 and Half-Life 2 seem to jump just a bit when turning left or right. Strafing left or right seems fine, it's rotating that seems specifically to cause the game to 'twitch'. I don't recall Mint behaving this way, but it COULD just be me.
 
Gizmo said:
Ran into an issue with Webex and VirtualBox; well, the issue was VB, but I first noticed it in conjunction with Webex.

Apparently, VB was configured to use Alsa for sound. Not sure how that happened, but regardless it did. So, everything was working fine, near as I could tell, until I went to jump on a Webex call while running VB. I access my customer through a VM on my side (running in VB) and connect to a VM on their side using an application named "Windows App" which is essentially RDP, but don't call it that because it's totally and completely different, see, and you have to use this special Microsoft Windows application to access it.

Anyway, I was doing some training for my customer so was using audio from the remote VM into my VM, and somehow that caused VB to grab Alsa exclusively, so Webex wouldn't work (in fact NOTHING involving my local audio would work; even the sound control panel was unable to do anything).

I went into VB settings for the VM and changed it from using Alsa to PulseAudio, and now things are working much better. Not quite sure what went wrong there.
Click to expand...
ALSA was always a bit of a pain. Sound mixing from multiple applications required the dmix plugin, with applications configured to point to the pcm.dmixer device rather than to the hardware itself, or else the hardware would be locked for the application's exclusive use.

PulseAudio... was worth avoiding for several years, but once grown-ups went in and fixed its lead developer's mess, it actually solved a lot of problems by providing a more rational architecture for applications to be built against.

I'd guess that VB grabbed the raw device rather than the mixer device, and PipeWire's ALSA emulation honoured its legacy behaviour.
 
So, apparently the X shim in Wayland only kindof works?

It seems that Webex on Wayland doesn't do screen-sharing because of an issue with the WebRTC screen-sharing API.
 
Started X instead of Wayland as my Compositor and I can share the screen in Webex now. Apparently, support for Wayland is Coming Soon in Webex (via Xwayland).
 
Gizmo said:
So, apparently the X shim in Wayland only kindof works?
Click to expand...
I think that's a fair summary. Some methods that worked in X aren't permitted with the wayland security model, so either the applications get updated, or the xwayland interface needs to capture it, or you'll simply use X11.
 
So I still haven't figured out the Samba config that I need to get it working so I can share files between my Windows machine and my Gentoo machine. Frankly, I have tried very hard, but copying the Samba config from my Linux Mint install didn't seem to work, so there's likely some component I'm missing.

I've been concentrating on trying to get my Canon MF743cdw printer working. I've got CUPS running and it's seeing the printer over the network, and it gives me status, but I can't actually get it to print. The print jobs go into the CUPS queue and CUPS SAYS that it printed them successfully, but the printer status log doesn't show it ever actually received anything.

I'm hampered somewhat by the fact that I'm trying to cabbage the DEB Canon driver package into Gentoo, since neither the Gentoo Portage net-print/cnrdrvcups-lb package nor the .tar.gz Canon source code will compile (they both fail with the same error) and I thought doing the DEB package would get me there quicker than trying to debug the Canon Makefile.

I know the Canon drivers work from the DEB package, because Linux Mint prints to the printer over the network just fine.
 
For Samba, if pam is getting in the way, just turn it off:
/etc/samba/smb.conf section
[global]
obey pam restrictions = no
 
Kaitain said:
What error do you get with the Canon compilation failure?
Click to expand...
In digging into this a bit more, it looks like the Canon driver code isn't C99 compliant, and makes an implicit cast from int to char, which apparently is a compiler error under C99.

I added -Wno-int-conversion to the Makefile for the particular module that was throwing the error and now it compiles. I've still to go through and remove the Debian files I copied hither and yon before I run 'make install' to see what happens.
 
Kaitain said:
For Samba, if pam is getting in the way, just turn it off:
/etc/samba/smb.conf section
[global]
obey pam restrictions = no
Click to expand...
Yeah, I expect that PAM is exactly my problem as Linux Mint has PAM configured, and I haven't felt like wading through the sea of file references to figure out what they are doing.
 
So, the Canon printer drivers that are in Portage appear to be broken, as mentioned above. It appears that the e-build attempts to patch the drivers, but for some reason the patch to fix the bad cast doesn't work.

It also appears that there are two ebuilds for what is essentially the same driver set, but different versions. Both the cndrvcups-lb and cnrdrvcups-lb drivers are for the Canon ImageRunner printers, but the cnrdrvcups-lb is EAPI 8 and for version 8 of the Canon drivers, where cndrvcups-lb is EAPI 7 and version 5 of the Canon drivers.

The bigger problem (for me, anyway) is that these drivers are for the European Canon ImageRunner printers. Canon ImageRunner in the States isn't even supported by Canon, but by some 3rd-party outfit. And as far as I can tell, my ImageClass printer doesn't even exist in the European market.

I think I may be able to use the ebuild from the cnrdrvcups-lb drivers as a template for what I need, though. Not sure yet. I've slept a couple of times since the last time I mucked about with e-builds, so this could take a minute or two.

Both of the Canon ebuilds are looking for a maintainer. I might see about taking that once I figure this thing out.
 
So, after mucking about a bit, I finally figured the problem out. Part of my problem was that there weren't any errors being thrown in the CUPS log. After digging around, I discovered that setting "LogLevel debug" in the /etc/cups/cupsd.conf file would provide the level of logging that I needed to begin to get a handle on the problem.

Once that happened, I could see that there was an error in the Canon drivers during the Ghostscript processing:
Code: 
D [23/May/2026:17:28:32 -0500] [Job 16] PID 1380807 (/usr/libexec/cups/filter/rastertoufr2) did not catch or ignore signal 13.
D [23/May/2026:17:28:32 -0500] [Job 16] PID 1380808 (/usr/libexec/cups/backend/socket) exited with no errors.
E [23/May/2026:17:28:32 -0500] [Job 16] src = libcanon_pdlwrapper.c, line = 514, err = 0¥nINFO: cfFilterGhostscript: Processing page 2...
D [23/May/2026:17:28:32 -0500] cupsdMarkDirty(---J-)
D [23/May/2026:17:28:32 -0500] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files"
D [23/May/2026:17:28:32 -0500] [Job 16] Set job-printer-state-message to "src = libcanon_pdlwrapper.c, line = 514, err = 0¥nINFO: cfFilterGhostscript: Processing page 2...",
 current level=ERROR
D [23/May/2026:17:28:32 -0500] cupsdMarkDirty(----S)
D [23/May/2026:17:28:32 -0500] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files"
D [23/May/2026:17:28:32 -0500] cupsdMarkDirty(----S)

The salient portion is this line:
Code: 
E [23/May/2026:17:28:32 -0500] [Job 16] src = libcanon_pdlwrapper.c, line = 514, err = 0¥nINFO: cfFilterGhostscript: Processing page 2...

For reasons known only to God and the Maintainers of the cfFilterGhostscript code (and I'm questioning the knowledge of the Almighty...), the error thrown by the Canon driver isn't propagated up the stack . In any case, the print jobs fails and CUPS is just sitting there all fat and happy without a care in the world, completely oblivious to the fact that the print job NEVER GOT SENT.

I have to assume there's a reason this is the case, but for the life of me I haven't a clue what that reason might be.

Anyway, more digging revealed that this is an issue that the Arch community have wrestled with and tracked to to being a problem with the version of libxml2 that is being used; apparently this driver is expecting to link with libxml2.so.2 (specifically, it's the cnpkbidir precompiled binary they provide with the driver source). They deal with it by using libxml2-legacy.

I installed the bombo82 portage overlay, copied the cnrdrvcups-lb ebuild from that into my private repo (because bombo82 has more up-to-date drivers than the Gentoo repo, although the bombo82 drivers don't work either), modified the ebuild to make libxml2-compat a dependency, et voila! I have a working printer again.

I've tried to figure out what the exact difference is between dev-libs/libxml2 and dev-libs/libxml2-compat, and as near as I can find it's one of those deep dark secrets that you could tell me but then you'd have to shoot me.

As near as I can tell, libxml2-compat is just the previous major revision of libxml2? I guess it's just kept around to resolve issues like this (like libxml2-legacy on Arch)?
 
As far as I can tell, dev-libs/libxml2-compat only provides libxml2.so.2 in addition to libxml2.so.<whatever is current>. If I understand correctly, the Canon printer driver relies on a binary blob supplied by Canon with some code wrapped around it? Which would explain the dependency, if so.
 
Kaitain said:
As far as I can tell, dev-libs/libxml2-compat only provides libxml2.so.2 in addition to libxml2.so.<whatever is current>. If I understand correctly, the Canon printer driver relies on a binary blob supplied by Canon with some code wrapped around it? Which would explain the dependency, if so.
Click to expand...
Yeah, the guts of the driver is all proprietary, wrapped by bits to make it compatible.

Which actually gets me to another question: aren't they technically in violation of the GPL? I'm a bit unclear here, but it seems like the whole kerfuffle over Babu Labs would be relevant here.
 
Gizmo said:
Yeah, the guts of the driver is all proprietary, wrapped by bits to make it compatible.

Which actually gets me to another question: aren't they technically in violation of the GPL? I'm a bit unclear here, but it seems like the whole kerfuffle over Babu Labs would be relevant here.
Click to expand...
No more in violation than the nVidia binary drivers or the firmware binaries for all graphics and some sound and network cards. Writing an open source wrapper around a closed source binary blob is a rather well trodden path for hardware support in Linux.
 
Yeah, I'm inverting the order of precedence here. If your code can't run without including OSS bits then you have to comply with the OSS license. If your OSS code requires proprietary bits, then you have to comply with the proprietary license.

Makes sense, elsewise no drivers would exist at all, other than what enterprising individuals were able to cobble together themselves (without getting sued into oblivion, of course).
 
You must log in or register to reply here.
Back
Top