Created attachment 1741336 [details] printer settings with duplicate Description of problem: Version-Release number of selected component (if applicable): cups.x86_64 1:2.3.3op1-1.fc33 How reproducible: Steps to Reproduce: Just open the general printer settings and wait until a dummy printer is added I am using a hp281fdw attached to the network. Actual results: One dummy printer. You have to wait until the dummy printer is there, only afterwards you can add the ipp printer properly. [julius@localhost ~]$ lpstat -ev HP-ColorLaserJet-MFP-M278-M281 HP_Color_LaserJet_MFP_M281fdw_EACF20_ Gerät für HP-ColorLaserJet-MFP-M278-M281: ipp://HP%20Color%20LaserJet%20MFP%20M281fdw%20(EACF20)._ipp._tcp.local/ Expected results: [julius@localhost ~]$ lpstat -ev HP-ColorLaserJet-MFP-M278-M281 Gerät für HP-ColorLaserJet-MFP-M278-M281: ipp://HP%20Color%20LaserJet%20MFP%20M281fdw%20(EACF20)._ipp._tcp.local/ Additional info: It works flawlessly on other operating Systems e.g. Android, IOS, Windows 10. Driverless scanning works fine, but also simple-scan shows the device twice. I have studied computer science and have some experience, so i am willing to help debugging. It might be related to https://bugzilla.redhat.com/show_bug.cgi?id=1567984 https://bugzilla.redhat.com/show_bug.cgi?id=1784449 https://bugzilla.redhat.com/show_bug.cgi?id=1765328 https://bugzilla.redhat.com/show_bug.cgi?id=1765328
Created attachment 1741337 [details] simple-scan duplicate devices
Hi Julius, thank you for reporting the issue! You're right, the print queue situation is connected to existing bug tickets you found - it is about temporary queues and you seeing them twice isn't a bug, but the result of GTK way of dealing with temporary queues. If you see such duplicates, then you don't need to install print queue manually and you can just use the 'dummy' (it is called 'temporary' in reality) for printing. The key characteristic of temporary queue is the queue doesn't need a extra driver to work. The same thing applies to scanning, but here you need to remove hplip completely to get rid of a duplicate. There is sane-airscan package which provides eSCL and WSD interface for communication with a device. This way, you don't need a extra driver for scanning neither. Please check the following two things and let me know: 1) Does printing via HP_Color_LaserJet_MFP_M281fdw_EACF20_ works for you? If it doesn't work, then you hit the same issue as 1784449 and I will close the issue as duplicate of it. 2) Does scanning via 'eSCL HP Color LaserJet MFP M218fdw' scanner work for you? If it doesn't, please file a separate issue, enable airscan debugging in /etc/sane.d/airscan.conf by: [debug] trace = <path where the debug data will be saved> enable = true , try to scan again, take all created files and attach them to the new ticket. Beware: Some more advanced functionality doesn't have to be available for driverless printing/scanning because of various reasons - IPP/eSCL/WSD protocols itself doesn't provide the functionality itself, or printer vendor didn't implement the functionality properly or at all for IPP/eSCL/WSD client in the device. Thank you in advance!
1) Does printing via HP_Color_LaserJet_MFP_M281fdw_EACF20_ works for you? If it doesn't work, then you hit the same issue as 1784449 and I will close the issue as duplicate of it. The temporary queue ink level is not there and the settings page is empty. I can send jobs to the temporary queue and they get printed. Nevertheless it does not always work and sometimes the gnome-control-center printer settings crash. For some reason the abrt gui does not finish at step "Analyzing crash data". There might have been updates since the initial bug report, so i did everything from scratch. - I only enable airprint and airscan as seen in network_configuration.png - I delete all printers/queues and restart - A temporary queue with empty settings gets automatically added, i guess cups-browsed - I can print text from gedit and after some time also a PDF from evince but not the printer test page from gnome-settings - I do not see ink levels on the temporary queue, even after printing - i add the first printer from the new printer dialog (add_printer.png) and it seems to override the temporary one or the temporary one just disapeared - i can see advanced printer settings similar to jetdirect settings if i would enable port 9100 printing, but still no ink level - the gnome-settings printer test page produces an error as seen in scan_of_printerror.png - i remove the printer - the temporary queue is added again without ink levels - gnome printer settings crash - i add the third printer from the new printer dialog (add_printer.png) - the icon is different and the word "driverless" appears at the end. the temporary queue is still there - i have got limited (not full jetdirect as before) printer settings, which are also fine for me. - i can print trough the temporary queue and the non-temporary queue - after printing from the non-temporary queue ink levels appear below the non-temporary queue - I delete the temporary queue and it is not re-added by cups-browsed or whatever I would dare to say something is wrong in the add printer dialog. It tries to add a jetdirect printer instead of driverless IPP and you have to wait until the IPP printer appears as third option. 2) Does scanning via 'eSCL HP Color LaserJet MFP M218fdw' scanner work for you? If it doesn't, please file a separate issue, enable airscan debugging in /etc/sane.d/airscan.conf by: scanning via 'eSCL HP Color LaserJet MFP M218fdw' scanner does work. The good thing is that escl is selected by default. hopefully hplip only shows devices it has drivers for in the future...
Created attachment 1744311 [details] network configuration of hp printer
Created attachment 1744312 [details] add printer dialog
Created attachment 1744313 [details] scan of print error
Created attachment 1744314 [details] abrt_1
Created attachment 1744315 [details] abrt_2
(In reply to Julius from comment #3) > 1) Does printing via HP_Color_LaserJet_MFP_M281fdw_EACF20_ works for you? If > it doesn't work, then you hit the same issue as 1784449 and I will close the > issue as duplicate of it. > > The temporary queue ink level is not there and the settings page is empty. > I can send jobs to the temporary queue and they get printed. > > Nevertheless it does not always work and sometimes the gnome-control-center > printer settings crash. > For some reason the abrt gui does not finish at step "Analyzing crash data". > > There might have been updates since the initial bug report, so i did > everything from scratch. > > - I only enable airprint and airscan as seen in network_configuration.png > - I delete all printers/queues and restart > - A temporary queue with empty settings gets automatically added, i guess > cups-browsed > - I can print text from gedit and after some time also a PDF from evince but > not the printer test page from gnome-settings > - I do not see ink levels on the temporary queue, even after printing > - i add the first printer from the new printer dialog (add_printer.png) and > it seems to override the temporary one or the temporary one just disapeared > - i can see advanced printer settings similar to jetdirect settings if i > would enable port 9100 printing, but still no ink level > - the gnome-settings printer test page produces an error as seen in > scan_of_printerror.png > - i remove the printer > - the temporary queue is added again without ink levels > - gnome printer settings crash > - i add the third printer from the new printer dialog (add_printer.png) > - the icon is different and the word "driverless" appears at the end. the > temporary queue is still there > - i have got limited (not full jetdirect as before) printer settings, which > are also fine for me. > - i can print trough the temporary queue and the non-temporary queue > - after printing from the non-temporary queue ink levels appear below the > non-temporary queue > - I delete the temporary queue and it is not re-added by cups-browsed or > whatever > > I would dare to say something is wrong in the add printer dialog. It tries > to add a jetdirect printer instead of driverless IPP and you have to wait > until the IPP printer appears as third option. > > > 2) Does scanning via 'eSCL HP Color LaserJet MFP M218fdw' scanner work for > you? If it doesn't, please file a separate issue, enable airscan debugging > in /etc/sane.d/airscan.conf by: > > scanning via 'eSCL HP Color LaserJet MFP M218fdw' scanner does work. The > good thing is that escl is selected by default. hopefully hplip only shows > devices it has drivers for in the future... correction "- I delete the temporary queue and it is not re-added by cups-browsed or whatever" is not true. Sometimes the temporary queue is added again.
(In reply to Julius from comment #9) > correction > > "- I delete the temporary queue and it is not re-added by cups-browsed or > whatever" > is not true. Sometimes the temporary queue is added again. Please check the existing tickets, it is explained there - it is added by GTK, because it parses avahi responses automatically. The avahi response doesn't contain any ink information, only accepted document formats, if it is color device or not, if duplex is supported and device uri. It will be added every time GTK parses the avahi response (once upon a time). The issue is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1765328 . *** This bug has been marked as a duplicate of bug 1765328 ***
I do NOT think that it is a duplicate. "> I would dare to say something is wrong in the add printer dialog. It tries > to add a jetdirect printer instead of driverless IPP and you have to wait > until the IPP printer appears as third option." is the main problem together with crashes. Please read ALL information before closing it. You can see clearly from the scan that it is not a duplicate.
(In reply to Julius from comment #11) > I do NOT think that it is a duplicate. > > "> I would dare to say something is wrong in the add printer dialog. It tries > > to add a jetdirect printer instead of driverless IPP and you have to wait > > until the IPP printer appears as third option." > > is the main problem together with crashes. Driverless IPP takes more time because it does mdns request for devices in LAN, so it is expected to be shown a little bit later (depends on Avahi). Ad jetdirect - it is strange, you disabled port 9100 on the printer so it shouldn't be jetdirect. Can you verify the connection of print queue via lpstat -v <queue_name>? My guess is it is a 'dnssd' backend instead of 'socket' (the backend for jetdirect). Ad crash: The crash happened right after GTK adds entry for the temporary queue and similar strange crashes regarding mishandling temp queues in GTK happened before, so put it under generic issue #1765328 . I'm reassigning this to gnome-control-center, would you mind checking if the crash is at least tracked within coredumpctl? If so, you can use 'coredumpctl gdb' to open the latest coredump in gdb, get backtrace by 'bt f' and attach it here.
Thanks for your guidance. first printer in add printer dialog It does not work, but has full jetdirect printer settings: [julius@localhost ~]$ lpstat -v Gerät für HP-ColorLaserJet-MFP-M278-M281: dnssd://HP%20Color%20LaserJet%20MFP%20M281fdw%20(EACF20)._ipp._tcp.local/?uuid=564e424e-4c32-3246-4c58-80ce62eacf20 third printer in add printer dialog it works and has just IPP everywhere settings: [julius@localhost ~]$ lpstat -v Gerät für HP-ColorLaserJet-MFP-M278-M281: ipp://HP%20Color%20LaserJet%20MFP%20M281fdw%20(EACF20)._ipp._tcp.local/
Created attachment 1744734 [details] backtrace
(In reply to Julius from comment #13) > [julius@localhost ~]$ lpstat -v > Gerät für HP-ColorLaserJet-MFP-M278-M281: > dnssd://HP%20Color%20LaserJet%20MFP%20M281fdw%20(EACF20)._ipp._tcp.local/ > ?uuid=564e424e-4c32-3246-4c58-80ce62eacf20 > Thanks for the data, Julius! We now at least know the printer doesn't have port 9100 opened if masked :) . Ok, so the other thing what can be wrong is the driver. dnssd backend isn't made for IPP everywhere support, so it needs a classic driver. Gnome Control Center (to be precise, it is gnome settings daemon who runs under the control center, does the stuff) uses scp-dbus-service from system-config-printer-libs to get the correct PPD, but control center nor settings daemon require system-config-printer-libs, because not all users have printers. Then, if hplip or packagekit (scp-dbus-service is able to install missing drivers if the driver provides the matching rpm tag to printer device id via packagekit) is installed, then scp-dbus-service provides a driver name which CUPS understands (f.e. lsb/usr/HP/hp-color_laserjet_mfp_m278-m281-ps.ppd.gz). Settings daemon then takes the driver name and device uri and sends IPP request to CUPS to create a print queue. So to sum it up: 0) the dnssd queue doesn't print is a separate issue - please file a separate bugzilla on system-config-printer if any steps below don't help to get dnssd print queue working, or provide a data here and I'll copy them to the new bugzilla if needed 1) would you mind checking what PPD you get for this dnssd queue? See /etc/cups/ppd, the file is called <print_queue_name>.ppd if it exists (if it doesn't, the correct PPD wasn't found and the queue was created as a raw) and please attach it 2) if the PPD doesn't exist or it is bad, please check whether you have system-config-printer-libs+hplip/PackageKit installed 3) if those packages are installed and you still get bad PPD after you reinstall dnssd queue, please provide the output of 'lpinfo -l -v'. Then I will construct dbus command which simulates sending dbus message from settings daemon to scp-dbus-service for getting a driver and I need the exact device model and device id from 'lpinfo -l -v'. After that, I will ask you to try the command on your machine - if the correct driver is returned, then the error is in settings daemon too.
It was a fresh fedora 33 installation i think. [julius@localhost ~]$ dnf list system-config-printer-libs hplip packagekit Letzte Prüfung auf abgelaufene Metadaten: vor 0:01:16 am Mi 06 Jan 2021 18:00:11 CET. Installierte Pakete PackageKit.x86_64 1.2.2-2.fc33 @updates hplip.x86_64 3.20.11-1.fc33 @updates system-config-printer-libs.noarch 1.5.13-2.fc33 @updates i will upload the two ppds and "lpinfo -l -v" in a minute. the ppds are clearly different
Created attachment 1744988 [details] dnssd ppd
Created attachment 1744989 [details] ipp ppd
Created attachment 1744990 [details] lpinfo -l -v
(In reply to Julius from comment #16) > the ppds are clearly different If you compare PPDs you got for dnssd uri and for ipp (IPP everywhere) uri, they are always different, because the former uses classic PPD from hplip and the latter is generated by PPD generator. Anyway, seems like a different bug, please follow #1913555 for that.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Still broken on Fedora 35 Beta
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.