This reverts commit e338d6a0fc. I originally
reverted the update because it broke my Samsung printer. Now, it turns out that
this issue can be fixed by deleting and then re-creating the printer in CUPS to
update the driver.
It's possible that Gutenprints 'cups-genppdupdates' could remedy the situation
as well, but I had no chance to verify that since I don't use Gutenprint.
Closes https://github.com/NixOS/nixpkgs/issues/13734.
This will probably be mandatory soon, and is a step in the right
direction. Removes the deprecated meta.version, and move some meta
sections to the end of the file where I should have put them in
the first place.
Adding this package to environment.systemPackages stops the
"Add new printer" button in gnome-control-center from being grayed out
and stops it from printing:
(gnome-control-center:16664): printers-cc-panel-WARNING **: Your system does not have the cups-pk-helper's policy "org.opensuse.cupspkhelper.mechanism.all-edit" installed. Please check your installation
But completing the printer setup requires some additional packaging
work. This is what happens when trying to _add_ a printer:
(gnome-control-center:18733): printers-cc-panel-WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.fedoraproject.Config.Printing was not provided by any .service files
(gnome-control-center:18733): printers-cc-panel-WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PackageKit was not provided by any .service files
`cups.desktop` that depends on some fixed version of `xdg-open` is not
particularly useful; it should use `xdg-open` from the environment
it's being run from.
As a side effect, one can now fiddle with `xdg_utils` package without
rebuilding pretty much every single one of graphical packages (they
all depend on `cups` through their graphical toolkits).
This not the latest, but the greatest version (by number of models still
supported).
A big bump. Everything seems to work fine. Tested with a Samsung CLP-325.
Also fixed some strange things. Did this ever even work? On x86_64?
Foomatic filters contained a 64-char c string hardcoded to /bin/bash.
This caused some filters (at least pdftops) to fail.
I also had to increase the size of the string because nix paths are too
long.
It was trying to find "gs" via execve, so use execvpe instead. It's
probably better to use gs's absolute path, but maybe not every
cups-filters user needs it.
