I'm trying to add a printer, published via dns-sd (by printserver running CUPS+Avahi).
When I run print-manager, and click “New printer”, my printer is discovered, but there is a red error “The name org.fedoraproject.Config.Printing was not provided by any .service files”. If I close the window and open it again, the printer is discovered and this error is displayed sometimes, and sometimes there is no error and no printer. It seems to be a bit random for now…
Created attachment 338448 [details]
This brand new emerge --info is so awesome it won't fit in the comment field.
Strangely this is provided by app-admin/system-config-printer-gnome
Which print-manager version was that? Do you still have the problem with 4.10.3?
(In reply to Andreas K. Hüttel from comment #3)
> Which print-manager version was that?
I have no idea. Which was the latest unstable at the time the bug was created?
Just tried with 4.10.3. The error now looks more beautiful and appears _every time_, not randomly.
(I should probably note that, obviously, I removed app-admin/system-config-printer-gnome before trying. The error disappeared when I reinstalled it.)
Same here with KDE SC 4.10.4.
Without system-config-printer-gnome, I always get the error message when adding a printer, but my network printer is well discovered.
Having system-config-printer-gnome emerged, the error message is gone, but gone as well is the list of discovered printers.
I just forgot to restart dbus. Done that, and the printer is discovered now.
added runtime dependency on app-admin/system-config-printer-gnome
(this does not pull in any gnome packages usually, don't worry)
system-config-printer dep is indeed required:
print-manager-4.10.3 $ grep -Ri org.fedoraproject.Config.Printing|wc -l
But having app-admin/system-config-printer-gnome in RDEPEND is ugly: it wants old and obsolete pygtk.
and related files are not in system-config-printer-common package? Having them in system-config-printer-gnome is pointless.
system-config-printer-* packages should be fixed and dep changed to app-admin/system-config-printer-common
Even ubuntu has it done much better:
Reopening and reassigning. Dependency on scp-gnome is not the way to go. I'' consider splitting rearrangig stuff in scp (maybe create separate ebuild for dbus interface) once I know what print-manager actually needs...
This should be resolved fast, because the new system-config-printer-gnome-1.4.1 has quite a huge amount of gnome/gtk3 dependencies. /me going to mask 1.4.1 until fixed.
I've tried to split scp like they do in Ubuntu, but in 1.4.3 the following line has appeared in scp-dbus-service.py, which gets called by print-manager when searching for printers:
from gi.repository import Gdk
So I'm currently stuck here:
ERROR:root:Could not find any typelib for Gdk
Traceback (most recent call last):
File "/usr/share/system-config-printer/scp-dbus-service.py", line 26, in <module>
from gi.repository import Gdk
ImportError: cannot import name Gdk
A dependency on x11-libs/gdk-pixbuf[introspection] didn't help, so maybe gtk+:3 is needed here for whatever reason...
Created attachment 364324 [details, diff]
keep more stuff in -common for use with kde-base/print-manager
Removed the Gdk calls, but then further down the code in scp-dbus-service.py they import jobviewer.py, which itself depends on gtk, pango etc. again. I had removed jobviewer.py in the 1.4.3-r1-split.patch as seen from the files list of Ubuntu, but that means they must have a circular dep scp-common <-> scp-gnome...
It seems to me a sane split where print-manager can really depend just on scp-common is not possible without serious code mangling.
I'm pretty confused ... seems that I'm missing something, can someone explain why
kde-base/kdeutils-meta has a dependency chain that explicitly blocks kde-base/system-config-printer-kde and depends on app-admin/system-config-printer-gnome instead?
I could find some clue in comment #12 that printer-manager depends on that -gnome thing, but why don't we go with the -kde thing in the first place?
(In reply to kavol from comment #15)
> kde-base/system-config-printer-kde and depends on
Where did you find kde-base/system-config-printer-kde?
There is no such ebuild in the portage tree right now as system-config-printer-kde has been deprecated some time ago in favour of kde-base/print-manager.
(In reply to Kirill Elagin from comment #16)
> (In reply to kavol from comment #15)
> > kde-base/system-config-printer-kde and depends on
> Where did you find kde-base/system-config-printer-kde?
um ... /usr/portage/kde-base/print-manager/print-manager-4.12.3.ebuild
> There is no such ebuild in the portage tree right now
I haven't gone so far in investigation, sorry, my overlook
> as system-config-printer-kde has been deprecated some time ago in favour of
don't know the reasons behind the change, but IMO, better to deprecate without replacement than to replace with GNOME stuff - those who want it can install it explicitly, and those who want to save resources (like me :-)) are not exactly happy finding out that tons of irrelevant stuff had sneaked in as dependencies of what is supposed to have nothing with that stuff ...
(In reply to kavol from comment #17)
> don't know the reasons behind the change, but IMO, better to deprecate
> without replacement than to replace with GNOME stuff - those who want it can
> install it explicitly, and those who want to save resources (like me :-))
> are not exactly happy finding out that tons of irrelevant stuff had sneaked
> in as dependencies of what is supposed to have nothing with that stuff ...
It was not the case until recently that system-config-printer-gnome pulled Gnome stuff. Seems that something has changed recently, unfortunately.
To me this is really upstream bug - print-manager not handling scp (optional runtime dependency) gracefully/predictably.
I think it's been handling it predictably for a while now (see comment #4).
And anyway, they claim it to be scp bug.
What gnome stuff is people trying to avoid here? scp has "gnome" name but I only see this dependencies there:
gnome-keyring? ( gnome-base/libgnome-keyring[introspection] )
Then... all this splitting (that causes us to be slower to bump scp as we are the only distribution doing that splitting and are a bit alone for that then) is for avoiding gtk+:3 dep? (because, seriously, people should really really try to use pygobject:3 instead of the completely dead and semi-broken :2 slot)
Well, even the KDE upstream doesn't agree with this splitting:
Personally, my preference is to hard-mask dev-libs/glib (locally, of course).
(In reply to Pacho Ramos from comment #22)
> Well, even the KDE upstream doesn't agree with this splitting:
The splitting does not really work, and at the same time upstream says s-c-p is not really mandatory. So, I would opt for
1) get rid of it
2) make it an optional dep in print-manager (what USE-flag then?)
3) call for a more descriptive _warning_ instead of that useless _error_ message, after all, I can add my printer just fine in print-manager without having s-c-p installed, only without the helping hand wrt device grouping
+1 from me.
We hide the dependency behind gtk USE flag lately, so I guess we're done.