Describe the bug
Printers which are configured and working in CUPS do not show up in the print dialog of GTK applications. Previously there was a Print to file (PDF) printer option which is no longer present. Notably Firefox and Evince are effected.
I am using Sway as my window manager which may be relevant, but printing worked previously.
I tested with Okular a QT application and it does still have all the printers available to it including print to file.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
See configured printers in the print dialog as well as the Print to File (PDF) option.
Additional context
Relevant sections of `/etc/nixos/configuration.nix:
# Enable CUPS to print documents.
services.printing = {
enable = true;
defaultShared = true;
};
services.avahi.enable = true;
services.avahi.nssmdns = true;
programs.system-config-printer.enable = true;
Metadata
"x86_64-linux"
Linux 5.2.16, NixOS, 20.03pre193829.f0fec244ca3 (Markhor)
yes
yes
nix-env (Nix) 2.3
"nixos-20.03pre193829.f0fec244ca3"
/nix/var/nix/profiles/per-user/root/channels/nixos
Perhaps dbus is not started properly? My printers are showing up for firefox & evince when launched through plasma5.
@matthewbauer thanks for the suggestion, unfortunately it didn't solve the issue for me. I just tried running sway with dbus-run-session sway
and printers still aren't showing up.
Some further information, I just rebooted into the last configuration I had for NixOS 19.09 on the unstable channel and printing is working again. So this seems to be related to the update to 20.03. Perhaps there was a GTK upgrade or something else major introduced in that time?
https://github.com/NixOS/nixpkgs/pull/69434 Fixes this
I am still experiencing the issue unfortunately :( Printers still do not show up in GTK applications (e.g. firefox, evince), even with #69434 . I am using i3 as my WM, is that relevant?
@noneucat Can you paste nix run nixpkgs.nix-info -c nix-info -m
?
Are you using the configuration mentioned in the issue?
This would actually be an issue with the system-config-printer
application.
So are you using programs.system-config-printer.enable
? Which I believe is the GUI program that also provides the service for other applications for printing. It would also be best to limit tests to that program since evince
and firefox
are just interacting with it over DBus.
To get the proper info from DBus you can maybe do
dbus-monitor --session "interface='org.fedoraproject.Config.Printing'"
while you interact with it for some info.
The original report here said
Notice the print dialog has no options to print
So you've established there's no options in here?
@worldofpeace Yes -- no options appear in the print dialog for evince
or firefox
even after setting programs.system-config-printer.enable
:
system-config-printer
does list the printer as expected:
I am not using the configuration listed in the original report. Relevant part of my config:
services.printing.enable = true;
services.printing.browsing = true;
services.printing.drivers =
with pkgs; [
gutenprint
gutenprintBin
samsung-unified-linux-driver_1_00_36
];
services.samsung-unified-linux-driver_1_00_36.enable = true;
programs.system-config-printer.enable = true;
System information:
- system: `"x86_64-linux"`
- host os: `Linux 4.19.76, NixOS, 20.03.git.7ff17ce (Markhor)`
- multi-user?: `yes`
- sandbox: `yes`
- version: `nix-env (Nix) 2.3`
- channels(root): `"nixos-19.09pre191505.7d5375ebf4c"`
- channels(noneucat): `""`
- nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`
No activity on DBus related to printing while I interact with it:
~ % dbus-monitor --session "interface='org.fedoraproject.Config.Printing'"
signal time=1570247967.542757 sender=org.freedesktop.DBus -> destination=:1.34 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string ":1.34"
signal time=1570247967.542786 sender=org.freedesktop.DBus -> destination=:1.34 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
string ":1.34"
@wkral I'm seeing there's an add
button. It appears system-config-printer
is listing a printer to be setup and configured because it's detected. Have you configured the printer?
I know at least, this can be confusing with NixOS being declarative.
(an aside, we do have declarative printers)
@worldofpeace Yes my system-config-printer
app found the printers that were already configured in cups through the web interface as well. The symptoms @noneucat is showing appear to be identical to mine.
I left this issue open because the #69404 fixes haven't made their way into master yet as staging-next
hasn't been merged in since you added the fix there. Builds have been failing for trunk-combined
for a week and a half or so. I figured with the 19.09
release going on those things would be resolved in time so just being patient.
It might be more urgent for @noneucat but I've just been booting into my earlier config to print, it's not an everyday activity for me.
@worldofpeace Sorry, I think I gave some bad information on Friday. I do see your fix included in master, I was in a detached head position on my repo from working on another issue and didn't realize.
I did a rebuild against my local copy of nixpkgs
today and I still have the issue even with your fix in place. So maybe it's something else causing the issue.
system-config-printer
has always worked for me though for whatever reason I don't have icons showing in that application, though that's probably a different issue.
If you have any suggestions on how to diagnose the issue I'm happy to help I don't have a great deal of knowledge about the working of dbus, but I can run stuff on this configuration.
As far as the declarative printers goes, I did notice that feature was recently merged as it came up while I was investigating this issue. It doesn't seem to affect printers set up by other means so I was hoping to give it a try after resolving this issue.
Since 19.09 was released today I tried switching to that channel off of unstable
and it fixes the issue for me. It would seem something is different between the two channels. Maybe that helps narrow things down but there is already quite a difference between the two. Nothing jumps out doing a git diff 19.09 --stat
maybe it would for someone with a bit more knowledge.
@worldofpeace thanks for pointing me to this issue from discourse. I'm trying to track this down. It seems cups support is enabled by default for Linux systems:
However, I've found this interesting Link:
https://wiki.debian.org/CUPSDriverlessPrinting#CUPS_2.2.4_and_the_GTK_Print_Dialog
@wkral do you use a driverless printer setup with cups? I get the following error in CUPS' web interface when adding a printer with a certain PPD file:
The Arch wiki points that this issue is a cause of nss-mdns not configured properly. Although I'm rather sure nss-mdns is configured properly on my machine (as a proof, cups does find my network printer) this troubleshooting hint indicates the debian's wiki page statement:
The print dialog of GTK applications such as firefox and evince does not function in the same way as the Qt and Libreoffice dialogs. It obtains queue and printer information directly from DNS-SD broadcasts and not through CUPS, so it has no knowledge of what CUPS 2.2.4 and later are capable of doing.
Is correct.
Anyway, I didn't figure out yet why / how editing cups-browsed.conf
should solve this as debian's wiki explains. I tries using either both / one of:
services.printing.browsedConf = ''
CreateIPPPrinterQueues driverless
CreateRemoteCUPSPrinterQueues No
'';
But it didn't make any difference.
Update: I've found an evidence I'm not the only one experiencing the "Unable to copy PPD file" error:
https://bbs.archlinux.org/viewtopic.php?pid=1861730#p1861730
On NixOS, I've managed to copy the ppd file from the store, gzip --decompress
it, and fix it by removing every line containing "Custom" at the beginning of it. I've filled a bug report to hplip: https://bugs.launchpad.net/hplip/+bug/1847563
Never mind that, this doesn't have to do anything with what printer driver / ppd is used..
The problem is that GTK isn't able to locate printers using DNS-SD. It doesn't even use CUPS at all.
@wkral this issue bothers me sincerely. I have a strong suspicion this has to do something with dbus, as @matthewbauer has suggested. I'd be glad to compare our configurations - from /etc/nixos/configuration.nix
up to your .xinitrc
and general environment. Would you be willing to chat on IRC / Riot / Keybase?
@doronbehar I'll be available in a few hours, I gather our timezones are rather separated but maybe tonight for me tomorrow morning for you?
@wkral the time fits for me now, I hope it's not too late for you. I'm available on Keybase, Telegram, and Riot as doronbehar
so you can reach out to me there, pretty much through the whole weekend.
Just wanted to let you know that I have the very same problem. The list of printers in the printing dialogue turned empty with an update (nixos-unstable
) at least several weeks ago, probably in August some time (since I do not use my printers very often, I cannot pinpoint exactly when it happened).
My current workaround is to always save stuff as PDF and use lp
from the command line.
This is so annoying right?! @dpaetzel If you are interested, I'd be happy to try to debug this together with you, if the time fits.
If it's of any help, you can find my current printing configuration here https://github.com/dpaetzel/nixos-config/blob/master/sokrates/configuration.nix#L88 .
Sorry, the time currently does not fit :-/ Perhaps during the weekend sometime.
While trying to investigate this, I've reached the conclusion that GTK doesn't use CUPS at all to find the printers, it uses dBus / avahi (or something like that) to find them. Therefor, I'm more interested in the following:
services.xserver.enable
? What other settings do you use for services.xserver
?$DBUS_SESSION_BUS_ADDRESS
? In a bare TTY and in a your window environment?.xinitrc
?I'm addressing both of you @wkral and @dpaetzel , and whoever that's experiencing this issue as well.
While trying to investigate this, I've reached the conclusion that GTK doesn't use CUPS at all to find the printers, it uses dBus / avahi (or something like that) to find them. Therefor, I'm more interested in the following:
I do not have Avahi enabled.
Do you set
services.xserver.enable
? What other settings do you use forservices.xserver
?
Yes, I do. https://github.com/dpaetzel/nixos-config/blob/c176ad12eea6cffe8c7f032e17088b1e3618a169/xmonad.nix#L5
What is the value of
$DBUS_SESSION_BUS_ADDRESS
? In a bare TTY and in a your window environment?
This variable is _empty_ in a bare TTY.
In my window environment (window manager: XMonad, display manager: lightdm) its value is: unix:abstract=/tmp/dbus-OO7Ia2PbK7,guid=917ddec079deeb15be99d0f95da01c09
What do you put in your
.xinitrc
?
I don't have that file.
Thank you for your effort :)
Thanks for the info.
It seems that with either one of the following options:
services.xserver.updateDbusEnvironment
services.xserver.displayManager.startx.enable
services.xserver.desktopManager.plasma5.enable
set or unset, We get the same behavior of $DBUS_SESSION_BUS_ADDRESS
.
@matthewbauer What is the value of your $DBUS_SESSION_BUS_ADDRESS
? In a bare tty and outside of it? Do you have anything set in your .xinitrc
? What other settings do you use with services.xserver
?
Good news everyone!
While investigating this issue in a non-Nix way, I've encountered many instructions such as this and this stating that this issue is related to gtk3's use of the cups libraries.
This led me to the conclusion that the problem is with gtk's cups printing backend. These backends can be found here:
/nix/store/...-gtk+3-3.24.8/lib/gtk-3.0/3.0.0/printbackends/
Their inclusion is controlled in Nix here:
Current GTK3 in master is not yet compiled by hydra so it may take a while until you'll see the update maybe improving something. Besides that, our version of cups is outdated for 2 weeks now (v2.3.0).
While attempting to update cups through an overlay in my configuration.nix
, Somehow, and I don't know why, without even restarting Firefox, I suddenly was able to see my printers in the dialog! :tada:
`I'm pretty sure that once cups 2.3.0 will be here and the gtk will be recompiled with it, the issue will be fixed :relieved:.~ EDIT: It seems that although upgrading these might help, a simple workaround in the meantime is explained in my next comment.
I just ran into this issue as well, great that a fix appears to be imminent! For now I worked around it by printing from the falkon
browser.
Somehow, and I don't know why, without even restarting Firefox, I suddenly was able to see my printers in the dialog! :tada:
So there's a workaround? Can it be explained for 'mere mortal' users like me or should we rather just wait it out?
My comments must be confusing.. Actually, now I see that while writing that previous comment, I haven't mentioned that I've also tried installing to my user environment nixpkgs.gtk3
. Hence the workaround is:
nix-env -iA nixpkgs.gtk3
Firefox loads libraries dynamically and somehow it could found gtk3's printbackends only when gtk3 was explicitly installed in my user environment. That's why Firefox didn't even need a restart.
Upgrading gtk3 or cups shouldn't make a difference. I'll edit my previous comment according to this new discovery.
The question is, why doesn't Firefox find the gtk3's printbackends? This is one of those issues that would have never appear in a "Normal" FHS compatible distribution..
ccing @eelco @andir and @vcunat as you are the maintainers of Firefox and Evince - our example / showcase GTK3 based programs.
Our task:
Make these GTK applications (by wrapping / patching them) find GTK's printbackends.
My comments must be confusing
Well, I'm pretty new to NixOS, so that's probably on me ;)
tried installing to my user environment nixpkgs.gtk3
Ah! Adding it to my systemPackages
also did the trick for me! Thanks! Weird though...
Update:
After reading gtkprintbackend.c
I've discovered that this workaround works as well:
export GTK_PATH=${gtk3}/lib/gtk-3.0
We need to add this variable to all of the shell wrappers that wrap GTK3 based programs. Somewhere around here:
What do you think @worldofpeace ?
Hence the workaround is:
nix-env -iA nixpkgs.gtk3
Yes! Works for me as well! Thank you!
@doronbehar We set GTK_PATH
globally
https://github.com/NixOS/nixpkgs/blob/58f090cc7b92edfee8c390b5a131a1417273c590/nixos/modules/programs/environment.nix#L41
On my system /run/current-system/sw/lib/gtk-3.0/3.0.0/printbackends
is linked, and likely on the systems who have this issue just don't have gtk3 linked... I can't reproduce this because the modules I use have pkgs.gtk3.out
in systemPackages
.
I see. The problem is that if a certain user doesn't have modules enabled which somehow add pkgs.gtk3
to systemPackages
, he encounters this issue. I don't enable any GUI related module in configuration.nix
besides xserver
and I'm experiencing this issue. In comparison, enabling gnome desktop-manager will do this:
Mate as well:
Pantheon:
Xfce:
This is quite a dilemma... Even if the services printing
and xserver
are enabled, it'll be pretty heuristic to be sure the user will want this package permanently in the store.
Perhaps a new configuration to be named services.printing.enablePrintingFromGui
would be appropriate?
I was affected by this problem but with Chrome.
The Chrome's print dialog listed my printer but cups didn't seem to receive the print job. If I opened the "system print dialog" from Chrome's print dialog, my printer wasn't listed.
Everything seems to work if I add 'gtk3' to systemPackages.
@doronbehar Yeah that was a bit too late for me last night. But I'm glad to see a lot of progress on identifying the issue. Thanks.
Exploring the GTK_PATH
angle, expanding the path I get the following:
/home/wkral/.nix-profile/lib/gtk-2.0:/home/wkral/.nix-profile/lib/gtk-3.0:/etc/profiles/per-user/wkral/lib/gtk-2.0:/etc/profiles/per-user/wkral/lib/gtk-3.0:/nix/var/nix/profiles/default/lib/gtk-2.0:/nix/var/nix/profiles/default/lib/gtk-3.0:/run/current-system/sw/lib/gtk-2.0:/run/current-system/sw/lib/gtk-3.0
But none of those directories exist. When adding the gtk3
or gtk3.out
the /run/current-system/sw/lib/gtk-*
get added. What's really weird for me is that on the 19.09
channel those directories still don't exist but the printers show in the dialog. I have no idea how that's happening since searching through directories under this state I can't find any of the printbackends/*.so
files.
@worldofpeace To actually fix this issue, I would guess there are probably two ways to go about this. First, as @doronbehar pointed out most of the desktop environments add gtk3.out
to the environment.systemPackages
Perhaps that should be done for the set of window managers as well like sway and i3.
Second, it would seem that things that depend on gtk3
could possibly add it to the systemPackages
or if there is some other mechanism to make it a runtime dependency. Perhaps that would be conditional on having printing enabled?
Any advice on what would be the preferred way? Maybe there is still something missing to explain why things are working on 19.09
?
I should have on optimal solution in a few days @wkral. And it works in 19.09
because GTK_PATH
isn't set in 19.09
.
Thanks, that's great news, looking forward to it.
It seems that on my system GTK_PATH
is set in my env in both channels 19.09
and unstable
I was comparing the two earlier.
Oh wait we have since https://github.com/NixOS/nixpkgs/commit/becde6132bf4847b80666aecb619032c286cc733. I just got mixed up because of https://github.com/NixOS/nixpkgs/pull/68492 which on master probably makes that environment leak to user systemd services and dbus services.
This is one of those issues which always reminds me of https://github.com/NixOS/nixpkgs/issues/60260
Adding gtk3 fixes this issue for me, using xfce4 on unstable.
This is from the documentation
Otherwise, GTK+ goes in turn through the directories in GTK_PATH, followed by the directory .gtk-3.0 in the user's home directory, followed by the system default directory, which is libdir/gtk-3.0/modules. (If GTK_EXE_PREFIX is defined, libdir is $GTK_EXE_PREFIX/lib. Otherwise it is the libdir specified when GTK+ was configured, usually /usr/lib, or /usr/local/lib.)
We define GTK_EXE_PREFIX
so it looks in /run/current-system/sw/lib
and not the libdir it was configured with. I believe this was the correct choice, it's just we rely on it being in systemPackages.
@jtojnar Do you think we should go back on our choice to set GTK_EXE_PREFIX
?
Or should we wrap GTK_PATH
? Firefox is already doing this, it's an improvement I'm willing to PR for wrapGAppsHook
.
So it turns out we were setting environment variables completely unnecessarily.
I've unset them in https://github.com/NixOS/nixpkgs/commit/dd050270c78a0e214ed7cb9e25bae43b45406473, as I forgot we had a patch to gtk2 for themes.
Can someone verify this fixes this issue? If GTK_EXE_PREFIX
isn't set it should just try to load the printer module from gtk's compiled prefix.
Indeed, unsetting GTK_EXE_PREFIX
makes my printers appear in the dialog again as well! :tada: This seems to be the best solution so far.
I'm sorry but I'm currently not able to build my complete system from master to test your specific commit (however, I cannot see why it would not work).
Closing as I feel this is confirmed fixed.
@worldofpeace I did a rebuild from head of master and can (I guess double) confirm the fix. Thanks very much.
Nice job, thank you very much! :slightly_smiling_face:
Most helpful comment
I should have on optimal solution in a few days @wkral. And it works in
19.09
becauseGTK_PATH
isn't set in19.09
.