Some additional info: looking in /var/log/cups/error_log I've found some number of the following errors:

W [12/May/2013:14:11:34 +0400] failed to find device: cups-HP_LaserJet_P1006

What does it mean? Why the device name is prepended with "cups-"? Is it correct?

And the output of journalctl:

May 12 14:44:34 olelukoie kernel: usb 8-2: new high-speed USB device number 8 using ehci-pci
May 12 14:44:35 olelukoie kernel: usb 8-2: New USB device found, idVendor=03f0, idProduct=3e17
May 12 14:44:35 olelukoie kernel: usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 12 14:44:35 olelukoie kernel: usb 8-2: Product: HP LaserJet P1006
May 12 14:44:35 olelukoie kernel: usb 8-2: Manufacturer: Hewlett-Packard
May 12 14:44:35 olelukoie kernel: usb 8-2: SerialNumber: AB06E3N
May 12 14:44:35 olelukoie kernel: usblp 8-2:1.0: usblp1: USB Bidirectional printer dev 8 if 0 alt 0 proto 2 vid 0x03F0 pid 0x3E17
May 12 14:44:35 olelukoie logger[5700]: loading HP Device 008 008
May 12 14:44:35 olelukoie systemd-udevd[5699]: missing file parameter for attr
May 12 14:44:35 olelukoie mtp-probe[5701]: checking bus 8, device 8: "/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-2"
May 12 14:44:35 olelukoie mtp-probe[5701]: bus: 8, device: 8 was not an MTP device
May 12 14:44:35 olelukoie logger[5703]: loading hp_laserjet_p1006 firmware 008 008
May 12 14:44:35 olelukoie logger[5704]: loading hp_printer_device 008 008
May 12 14:44:35 olelukoie logger[5706]: loading HP Device 8-2 8-2
May 12 14:44:35 olelukoie systemd[1]: Starting Printer.
May 12 14:44:35 olelukoie systemd[1]: Reached target Printer.
May 12 14:44:35 olelukoie systemd[1]: Starting Configure Plugged-In Printer...
May 12 14:44:35 olelukoie systemd[1]: Started Configure Plugged-In Printer.
May 12 14:44:35 olelukoie hp-mkuri[5710]: io/hpmud/model.c 625: unable to find [s{product}] support-type in /usr/share/hplip/data/models/mod

Here're two problems:
1. May 12 14:44:35 olelukoie systemd-udevd[5699]: missing file parameter for attr.
2. The last line with "hp-mkuri[5710]: io/hpmud/model.c 625".
BTW the long lines are truncated in this output.

*** Bug 10238 has been marked as a duplicate of this bug. ***

CC: (none) => kamz

added nicolas, as iirc he worked on that (or i'm totally wrong)

I can confirm that this bug also affects the i586 platform.

CC: (none) => anthonyscott

*** Bug 10735 has been marked as a duplicate of this bug. ***

I'll take a look, the mkuri stuff could come from one of the Debian patches, or maybe some typo, looks rather strange:


May 12 14:44:35 olelukoie hp-mkuri[5710]: io/hpmud/model.c 625: unable to find [s{product}] support-type in /usr/share/hplip/data/models/mod

Could you maybe test with one of the hplip versions from cauldron, do you have some test installation to spare for that?

Status: NEW => ASSIGNED
Assignee: bugsquad => doktor5000

(In reply to Florian Hubold from comment #7)

> Could you maybe test with one of the hplip versions from cauldron, do you
> have some test installation to spare for that?

Unfortunately I don't have cauldron installations so I can not test new versions from that repo. And besides I'm on vacations until august and won't be able to test anything until then. May be someone else?

I do not know if this can be of use. I have had the same problem with my printer HP_Laserjet_1020.
I tried other distributions (mainly Debian e Debian based), but the problem was still there. I suspected that the problem is not in the hplip, but in a file in the boot process, most probably in the systemd (from time to time I was receiving some error messages). The only distribution that was loading the firmware is PClinuxOS, but with this distribution I had a problem with video card: I had to re-install the driver at every boot.
So I gave Mageia a new try. When installing the printer I got the message "missing gnome-keyring". As a matter of fact, it was installed. Since some other times I experienced that a program did not work properly until I installed some other packages that were not in the dependencies, but where similar to the one missing, I installed the following packages: gnome-keyring-sharp, gnome-keyring-gir1.0, gnome-keyring0, libsvn-gnome-keyring0 and there dependencies.
Immediately after that nothing happened. Then I was asked to install the updates and to restart the system. After this new boot I open the printer and the hplip loaded the firmware automatically.
I have not the knowledge to explain what happened but since then, so far at least, I have no problem

CC: (none) => tagliabue.renato

(In reply to Renato Tagliabue from comment #9)
> I do not know if this can be of use.
...
> I installed some other packages that were not in the dependencies, but where
> similar to the one missing, I installed the following packages:
> gnome-keyring-sharp, gnome-keyring-gir1.0, gnome-keyring0,
> libsvn-gnome-keyring0 and there dependencies.
> Immediately after that nothing happened. Then I was asked to install the
> updates and to restart the system. After this new boot I open the printer
> and the hplip loaded the firmware automatically.

I bet you can safely remove gnome-keyring-sharp and libsvn-gnome-keyring0 packages.

As for gnome-keyring0 the correct package name is lib/lib64gnome-keyring0 or gnome-keyring (without '0') and it is a dependency for system-config-printer.

The most interesting package here is gnome-keyring-gir1.0 (the correct name is lib/lib64gnome-keyring-gir1.0). It is not in dependencies of hplip or system-config-printer but it is required for python-keyring. The problem is that python-keyring is in turn not required neither for hplip nor system-config-printer even though system-config-printer requires gnome-python-gnomekeyring.

So there could be some trouble with python-keyring dependency in gnome-python-gnomekeyring package.

Yes, this can be of use but requires some testing. I'll test it as soon as I can and report results here. Hope this would solve the problem...

BTW there is another problem with gnome-keyring package: it contains arch-dependent binaries that prevent installing 32-bit gnome-keyring binaries version on 64-bit system. I think this package should be splitted in two.

Well, I'm a bit of confused but it seems like the problem was fixed with one of package updates. I had not updated my desktop PC nor tested printer's firmware loading for several weeks but today with all available official updates installed and without installing any additional package my HP printer began to work without any problem. Its firmware now loads automatically on printer powering on (I've tested it by powering printer on and off several times).

I'll also test with my laptop later this week and report.

I can confirm that this solution is working.
I was installed gnome-keyring-gir1.0 and firmware is loaded automatically.

For me it seems like the bug disappeared even without installing gnome-keyring-gir1.0 on both desktop and laptop. Could it be due to my login account is a member of wheel, usb and lp groups?

Can you please double-check? That is, remove thhose groups one by one (most likely lp) and then reboot (or logout/login again) and test again.

Same applies for gnome-keyring-gir1.0 - remove it and see if firmware install still works or not.

I've got no problem putting a fix for this in the package, if it has been confirmed to be working.

(In reply to Florian Hubold from comment #14)
> Can you please double-check? That is, remove thhose groups one by one (most
> likely lp) and then reboot (or logout/login again) and test again.
> 
> Same applies for gnome-keyring-gir1.0 - remove it and see if firmware
> install still works or not.
> 
> I've got no problem putting a fix for this in the package, if it has been
> confirmed to be working.

I did some tests. 
1. with only the package gnome-keyring-girl.0 and without the groups suggested by Oleg Bosis (wheel, usb, lp) the printer is working
2. with the three  groups and without gnome-keyring-girl, the printer is still working
3. without the group wheel or usb, the printer is not working
4. without the group lp (keeping only wheel and usb), the printer is working

So what you're basically saying is by adding a normal user to the group usb, and without gnome-keyring-gir1 the printer is working? Can you confirm that with a freshly created user please?

(In reply to Florian Hubold from comment #16)
> So what you're basically saying is by adding a normal user to the group usb,
> and without gnome-keyring-gir1 the printer is working? Can you confirm that
> with a freshly created user please?

As you asked I created a new user and added the groups usb and wheel and my printer is working.

Two observations:
1. it seems that the group lp is not strictly necessary
2. the groups to be added to normal user are the two above, both of them: if I add only one of them, my printer is not working

The real problem is that firmware loading should work regardless of the current users' groups. For example, it should work on print server when there are no any local users at all. And it doesn't work even with libgnome-keyring-gir1.0 installed. Automatic firmware loading only works when there's a local user with appropriate rights logged into X session (VT login doesn't work too).

Hmmm... Enabling udev logging "debug" level (uncommenting udev_log line in /etc/udev/udev.conf file and replacing "info" with "debug" in it) fixes the problem and firmware begins to load normally even when there're no users logged in... So it seems like a udev problem or some strange bug in HPLIP's udev rules...

I've had problems with Mga3 and Mga4 with an HP multi-function device.  It's not exactly the same as this bug, but it does involve having to install something manually, although only once.

I can only get the printer configuration to work if I first install manually system-config-printer.  This downloads includes a number of other packages.  Then on trying to configure the printer the system automatically downloads a couple of HP-related packages and then the configuration works.

Is this related in anyway, or should I file it as a separate bug?

CC: (none) => isolde

The above comment applies to i586.

@ Carolyn,

No, if there is a bug, then it is not the same as this one.

Did you install from a LiveCD? After installing with traditional installer, system-config-printer should be present the first time you boot into your newly installed Mageia. It doesn't fit on the LiveCD with its dependencies, though.

For the rest, everything you write sounds normal to me, it is as described in our documentation 
http://doc.mageia.org/mcc/3/en/content/system-config-printer.html#introduction
http://doc.mageia.org/mcc/3/en/content/system-config-printer.html#specificities
(for the last link, read the part about "Hewlett-Packard printers and All in one devices")

We should tell LiveCD users that they have to install system-config-printer. Would you have time to add a line about this to system-config-printer.xml in Calenco?

cc'ing docteam

CC: (none) => doc-bugs, marja11

Yes, I did install from a live CD, I didn't know you then have to install system-config-printer yourself.

I'll add that to the Calenco doc.

Carolyn

As there seems no proper solution, and we can't enable udev debugging just for printer installation to work, can somebody please report this issue upstream and verify what the root cause is?
Also ask about the group membership, which of them is mandatory and if gnome-keyring-gir1.0 is required or not.

You can do this by asking a question or reporting it as a bug, links are here: http://hplipopensource.com/hplip-web/support.html

It would also be really helpful if someone could test with the cauldron version, there have been quite some fixes for plugin handling and isntallation.

Severity: major => normal
Keywords: (none) => NEEDINFO

A git dependency are automatically added using syntax like:
  typelib(GnomeKeyring)

Now there could be a problem with this, however:
  gnome-python-gnomekeyring

Is the old binding, before GObject Introspection.

The gir package is the new way of binding.

See for instance:
https://developer.gnome.org/gnome-devel-demos/stable/window.py.html.en

I'd expect some code which has something like:
> from gi.repository import GnomeKeyring

if someone could grep all their .py files on their system for "GnomeKeyring" (case sensitive!) I'd really appreciate

CC: (none) => olav

$ urpmf --requires --literal 'typelib(GnomeKeyring)'
gwibber:typelib(GnomeKeyring)
python3-keyring:typelib(GnomeKeyring)
python-keyring:typelib(GnomeKeyring)
liferea:typelib(GnomeKeyring)
system-config-printer:typelib(GnomeKeyring)
gwibber:typelib(GnomeKeyring)
python3-keyring:typelib(GnomeKeyring)
python-keyring:typelib(GnomeKeyring)
liferea:typelib(GnomeKeyring)
system-config-printer:typelib(GnomeKeyring)
[src@bkor gnome-python-desktop]$ urpmf --provides --literal 'typelib(GnomeKeyring)'
lib64gnome-keyring-gir1.0:typelib(GnomeKeyring)[== 1.0]
libgnome-keyring-gir1.0:typelib(GnomeKeyring)[== 1.0]


Dependency seems to be there?

Note: I don't get why python-keyring has the dependency.

This all on Cauldron btw

i've reported this bug in launchpad

URL: (none) => https://bugs.launchpad.net/hplip/+bug/1245182

Next time please also mention the upstream bug here for completeness sake.
https://bugs.launchpad.net/hplip/+bug/1245182

There have been many fixes for firmware installation since this bug has been reported. Can you please check with the Mageia 4 version of hplip, if this bug still persists?

See Also: (none) => https://launchpad.net/bugs/1245182

With my printer -HP Laserjet 1020- the bug still persists with Mageia 4

Looks like I've found the reason of the problem. The bug is the consequence of patching udev rule (removing the line that comes after comment "# This rule will add printer and install plugin") and removing corresponding tool (hp-config_usb_printer) and systemd service (hplip-printer@.service). Bringing them back allows automatic loading of firmware to work properly on printer powering on.

(In reply to Oleg Bosis from comment #31)
> Looks like I've found the reason of the problem. The bug is the consequence
> of patching udev rule (removing the line that comes after comment "# This
> rule will add printer and install plugin") and removing corresponding tool
> (hp-config_usb_printer) and systemd service (hplip-printer@.service).
> Bringing them back allows automatic loading of firmware to work properly on
> printer powering on.

Can, you precise what you mean please ?

CC: (none) => andresalaun

(In reply to andre salaun from comment #32)
> Can, you precise what you mean please ?

Look at the spec file of hplip package: http://svnweb.mageia.org/packages/cauldron/hplip/current/SPECS/hplip.spec?revision=567495&view=markup

There're following lines present:
...
045: 	Patch107: hplip-udev-rules.patch
...
465 	rm -f %{buildroot}%{_bindir}/hp-config_usb_printer
466 	rm -f %{buildroot}%{_unitdir}/hplip-printer@.service
467 	rm -f %{buildroot}%{_datadir}/hplip/config_usb_printer.*
...

Now look at the patch mentioned in line 45 as Path107: http://svnweb.mageia.org/packages/cauldron/hplip/current/SOURCES/hplip-udev-rules.patch?revision=496307&view=markup

There're the following lines:

4 	@@ -11,8 +11,6 @@ LABEL="hpmud_usb_rules"
5 	ATTR{idVendor}=="03f0", ATTR{idProduct}=="????", OWNER="root", GROUP="lp", MODE="0660", ENV{sane_hpaio}="yes", ENV{libsane_matched}="yes", ENV{hp_test}="yes", ENV{ID_HPLIP}="1"
6 	
7 	
8 	-# This rule will add the printer and install plugin
9 	-ENV{hp_test}=="yes", PROGRAM="/bin/sh -c 'logger -p user.info loading HP Device $env{BUSNUM} $env{DEVNUM}'", RUN+="/bin/sh -c 'if [ -f /usr/bin/systemctl ]; then /usr/bin/systemctl --no-block start hplip-printer@$env{BUSNUM}:$env{DEVNUM}.service; else /usr/bin/nohup /usr/bin/hp-config_usb_printer $env{BUSNUM}:$env{DEVNUM} ; fi'"
10 	
11 	# If sane-bankends is installed add hpaio backend support to dll.conf if needed.
12 	ENV{sane_hpaio}=="yes", RUN+="/bin/sh -c 'grep -q ^#hpaio /etc/sane.d/dll.conf;if [ $$? -eq 0 ];then sed -i -e s/^#hpaio/hpaio/ /etc/sane.d/dll.conf;else grep -q ^hpaio /etc/sane.d/dll.conf;if [ $$? -ne 0 ];then echo hpaio >>/etc/sane.d/dll.conf;fi;fi'"

I mean that the presence of lines 465-467 in spec file and lines 4-12 in patch107 are the cause of the bug. These lines have to be removed from the spec and the patch and files mentioned in lines 465-467 in spec file have to be packaged properly.

(In reply to Oleg Bosis from comment #33)
> I mean that the presence of lines 465-467 in spec file and lines 4-12 in
> patch107 are the cause of the bug. These lines have to be removed from the
> spec and the patch and files mentioned in lines 465-467 in spec file have to
> be packaged properly.

No, that has been explicitly removed for security reasons. We cannot let any software download arbitrary binary code from some untrusted site and install them to the system.

I think the real bug here is that plugin/firmware that has been downloaded to the printer is not put there permanently and needs to be redownloaded after each power cycle, this seems broken to me. But seems upstream does also not react to the bugreport for that.

Apart from that, this patch has been added 6 months after you filed this bug, so it cannot be the only cause for this.

(In reply to Florian Hubold from comment #34)

> I think the real bug here is that plugin/firmware that has been downloaded
> to the printer is not put there permanently and needs to be redownloaded
> after each power cycle, this seems broken to me. But seems upstream does
> also not react to the bugreport for that.
> 
> Apart from that, this patch has been added 6 months after you filed this
> bug, so it cannot be the only cause for this.

No, you are wrong. The tool that is called hp-config_usb_printer do check the presence of the plugin and firmware and upload firmware to printer if it present. If not then it tries to download it first (this action requres root login so the user should see authorization request). And the udev rule make it work on printer powering on. Without this rule this tool will not run and firmware will not be uploaded to printer.

Security reasons are not a good excuse to forbid hardware owners to properly use their hardware. If you think that HP site is untrusted then you should remove hplip from repository completely and alow people to install it from HP official web site. And if not then you should not spoil hplip required functionality.  Neither debian nor ubuntu remove this tool. OpenSuSe replaces corresponding udev rule with their own one that directly calls hp-firmware instead of hp-config_usb_printer (look at their spec and patches). Only Fedora and Mageia (looking at Fedora I think) remove it completely and break all printers that require firmware uploading to operate.

And about 6 months: when I filed this bug I filed it against 3.12 version. Now we have 3.13 and current official one is 3.14. The versions are completely differnet. 3.12 had a problem with access rights. 3.13 is broken by this patch.

We are not forbidding anybody to use their hardware, same goes for preventing anyone to run hplip directly from upstream.

For current hplip, feel free to provide a patch or to take maintainership.

Assignee: doktor5000 => bugsquad

(In reply to Florian Hubold from comment #37)
> For current hplip, feel free to provide a patch or to take maintainership.

I have built and uploaded hplip 3.14.4 to our community testing repository:

ftp://ftp.mageialinux.ru/mageia4/construct/RPMS/i586/
ftp://ftp.mageialinux.ru/mageia4/construct/RPMS/x86_64/
ftp://ftp.mageialinux.ru/mageia4/construct/SRPMS/hplip-3.14.4-0.1.mga4.mrc.src.rpm

It fixes uploading firmware but has two more problems:
1. No notification (under KDE) when printer is powered on/off (though firmware is loaded correclty)
2. All hp-* tools that require root authorization hang (freeze) on authorizing step (password request dialog doesn't appear). Running these tools manually from "su -"'ed konsole works fine.

Well... HPLIP uses "su -" for root actions and uses pexpect to provide root password for this command. And it perfectly works in "C" locale but is completely broken for all other non-English locales as "su" command doesn't print any English words anymore. This is why authorization freezes: "su" waits for password but HPLIP tools do not understand it and do not provide it.

I'm not Python developer and I don't know how to properly setup locale before calling external tool and then revert locale back after the command finished so I need help.

The command itself is defined in 'password.py' file (in 'base' subdirectory) in __get_password_utils_ui function. Then the command is called in the same file in __password_check function in try/catch block using pexpect.spawn function.

I've tried to change the command to 'LC_ALL=C su - -c "%s"' but it did not work at all.

And the same issue applies to wget calls to download plugin/firmware. Downloading itself works but downloading error handling doesn't due to non-English wget output.

Seems I've found a simple and naive solution to locale issue and uploaded new build 0.2 to the same location as above (see comment 38). It would take some time to update the repository.

@Oleg: Could you check if using the mga5 packages for hplip also fixes this issue? 
Should be fixed via http://svnweb.mageia.org/packages?view=revision&revision=638283

Then we could push that as an official update to Mageia 3 and Mageia 4 users that might still encounter this issue.

I can not really test it as I don't have cauldron installation now. But it shouldn't work due to the patch called 'hplip-udev-rules.patch'. This patch should be removed completely (preferred way to solve) or changed according to openSuSe one at least (just upload firmware if it's present and do nothing if it's missing. see openSuSe package for details).

And please don't tell me about rules violations. Removing the patch would *not* cause downloading anything *automatically*. The tool blocked by this patch just detects if the printer requires proprietary plugin and displays the wizard-style GUI to *allow* user to download and install it if required.

Also don't forget about another problem with locale. Mageia provides localized su and wget tools so downloading and installing required plugin doesn't work without LC_ALL=C. The patch is available in my package ( http://packages.mageialinux.ru/mageia4/construct/SRPMS/hplip-3.14.6-0.1.mga4.mrc.src.rpm )

Mageia 3 changed to end-of-life (EOL) status 4 months ago.
http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ 

Mageia 3 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 Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Resolution: (none) => OLD
Status: ASSIGNED => RESOLVED

Changed version to 4 and reopened. The reason of the bug is different but the visual result is the same: required firmware is not uploaded to the printer when it is powerd on/plugged in.

Resolution: OLD => (none)
Version: 3 => 4
Status: RESOLVED => REOPENED

Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer 
maintained, which means that it will not receive any further security or bug 
fix updates.

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 
Mageia version.

Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't 
able to fix it before Mageia 4's end of life. If you are able to reproduce it 
against a later version of Mageia, you are encouraged to click on "Version" and 
change it against that version of Mageia. If it's valid in several versions, 
select the highest and add MGAxTOO in whiteboard for each other valid release.
Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO.

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 Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].

[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

I'd rather change the mga version of the bug to Cauldron.
I do follow all the changes to hplip package in mga repo and I do not see any sign of trying to fix the bug. The patch that completely disables udev rule to upload firmware is still here.

Ok

Whiteboard: (none) => MGA5TOO
Version: 4 => Cauldron

On the 25th of July, Phillipem uploaded the following packages to 
Cauldron's core/updates_testing:

    system-config-printer-1.5.7-5.mga6.i586
    system-config-printer-applet-1.5.7-5.mga6.i586
    system-config-printer-udev-1.5.7-5.mga6.i586

    system-config-printer-libs-1.5.7-5.mga6.noarch

    system-config-printer-1.5.7-5.mga6.x86_64
    system-config-printer-applet-1.5.7-5.mga6.x86_64
    system-config-printer-udev-1.5.7-5.mga6.x86_64


@ Anyone reading this:

* If this bug is valid for you in cauldron, then please test whether updating your system-config-printer packages to version 1.5.7-5.mga6 fixes the problem and report back in this bug report.

* If you do not have this bug in cauldron, but you do run cauldron, then please update those packages, too, and report in bug 18367 whether they work as expected.

CC: (none) => makowski.mageia

Assigning to all packagers collectively since hplip has no registered maintainer.

Assignee: bugsquad => pkg-bugs

It could be fixed by packaging the plugin in the nonfree repo.

CC: (none) => cooker

(In reply to Johnny A. Solbu from comment #50)
> It could be fixed by packaging the plugin in the nonfree repo.

No, it won't. The problem is in udev rule and not in the presence of plugin.

I've corrected the report title to clarify the problem a bit more...

I see updated hplip package in mageia 6 but the bug is still here. Are there any plans to fix it? Or I have to stop using mageia and switch to some other distro?

BTW I can not login to bugzilla with my previous login after recent password reset. Password was reset successfully but now I can only login with "uid" instead of "cn" or "givenName".

CC: (none) => olelukoie

(In reply to Oleg Bosis from comment #53)
> I see updated hplip package in mageia 6 but the bug is still here. Are there
> any plans to fix it? Or I have to stop using mageia and switch to some other
> distro?

Please, you are the one that knows how to fix it, and has the hardware to test the fix. So why don't you just attach a patch which follows mageia security policy (no download at each power on)?

CC: (none) => lists.jjorge

I have already described two ways of fixing the problem (see comment 42 for example):

1. Simply drop the first hunk of hplip-udev-rules.patch (it doesn't really violate any policy as it doesn't download anything automatically) - this is what I always do rebuilding your package to make my printer work

or

2. Change the first hunk of the same hplip-udev-rules.patch according to openSUSE change-udev-rules.diff (see openSUSE hplip package and an explanation of changes in their patch)

Hi
What is the current status?

CC: (none) => fri

Current status is the same: udev rule is broken and existing firmware is not used automatically.

OK thanks.
Referencing this in Bug 30065 - Update request: update hplip to latest 3.21.12 to add support for several new printers

Whiteboard: MGA5TOO => MGA8TOO

I'm confused by this bug.

I have an HP Color Laserjet CP1215, which according to https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html is supposed to require the plugin for "printing support" and has through many versions of hplip.

I don't remember ever seeing this bug's problem, or having much of any problem with hplip and this printer since first installing it in Mageia 7. 

That said, I just ran a command included with hplip, "hp-diagnose_plugin" and it tells me that a printer requires the plugin but it is missing! Yet the printer is working just fine. How could that be?

Is it possible that an appropriate plugin was installed when I first installed the printer, and has not been updated along with the rest of hplip ever since? That that old plugin is sending workable firmware to my old printer, but wouldn't be doing so for newer printers? 

I'm going to try installing the printer on another computer, and see what happens. I read somewhere that the HP plugin is proprietary and asks the user for an EULA acceptance confirmation before it is installed, yet I don't remember having to give that confirmation through many hplip updates. Why not?

CC: (none) => andrewsfarm

Well, that was a huge waste of time and effort. At least it was (mostly) in VirtualBox.

My CP1215 can be installed from system-config-printer, without the plugin, but the test page indicates it is using the FOO2HP.PPD driver, despite hplip being the option that was selected during the install. And indeed, a look at openprinting.org suggests this is the driver of choice for this printer. 

Several attempts at using hp-setup to install this printer failed, because of an inability to download and install the required hp plugin. The problem always had to do with the "key." Either it couldn't be downloaded from the same outlet as the plugin, or if downloaded manually the plugin showed as having been "altered." And without a verified plugin installed, hp-setup refused to proceed.

I'll go away now, and stop bothering people who might actually be able to accomplish something.

(In reply to Thomas Andrews from comment #60)
 The problem
> always had to do with the "key." Either it couldn't be downloaded from the
> same outlet as the plugin, or if downloaded manually the plugin showed as
> having been "altered." And without a verified plugin installed, hp-setup
> refused to proceed.

I had exactly the same problem with key file when downloading plugin, but then HPLIP provided me dialog box with the question if I wish to continue without key file (and warning that it could be dangerous). I've answered 'yes' (i.e. I wish to continue) and then plugin was installed and used.

The only problem is the lack of automatic 'plugin' (firmware) uploading into printer when I switch the printer on.

BTW question to bugzilla maintainers: why I always receive two identical emails on each reply in this thread?

(In reply to Oleg Bosis from comment #61)

> BTW question to bugzilla maintainers: why I always receive two identical
> emails on each reply in this thread?

I'm not a Bugzilla maintainer, but it looks to me like you did it yourself. As the reporter of the bug, you are automatically put on the list to receive emails about it. But when you put yourself on the "CC" list, you were put on the list to receive a second one.

I'll remove your name from the CC list. You should still receive emails for this bug, but only one copy.

CC: olegbosis => (none)

(In reply to Oleg Bosis from comment #61)
> (In reply to Thomas Andrews from comment #60)
>  The problem
> > always had to do with the "key." Either it couldn't be downloaded from the
> > same outlet as the plugin, or if downloaded manually the plugin showed as
> > having been "altered." And without a verified plugin installed, hp-setup
> > refused to proceed.
> 
> I had exactly the same problem with key file when downloading plugin, but
> then HPLIP provided me dialog box with the question if I wish to continue
> without key file (and warning that it could be dangerous). I've answered
> 'yes' (i.e. I wish to continue) and then plugin was installed and used.
> 
I tried that, but after it told me the plugin install was successful and I tried to continue, hp-setup dumped me right back to the "you need a plugin" step, and refused to go any farther with the install of the CP1215 printer. 

> The only problem is the lack of automatic 'plugin' (firmware) uploading into
> printer when I switch the printer on.
> 
Maybe because you didn't install a copy of the plugin that it accepted as "verified?"

Just tested new version of HPLIP from updates_testing. Downloading and installing plugin works without any problem, but udev rule still fails:

Feb 26 13:38:09 localhost kernel: usb 2-11: new high-speed USB device number 7 using xhci_hcd
Feb 26 13:38:09 localhost kernel: usb 2-11: New USB device found, idVendor=03f0, idProduct=3e17, bcdDevice= 1.00
Feb 26 13:38:09 localhost kernel: usb 2-11: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 26 13:38:09 localhost kernel: usb 2-11: Product: HP LaserJet P1006
Feb 26 13:38:09 localhost kernel: usb 2-11: Manufacturer: Hewlett-Packard
Feb 26 13:38:09 localhost kernel: usb 2-11: SerialNumber: AB06E3N
Feb 26 13:38:09 localhost kernel: usblp 2-11:1.0: usblp2: USB Bidirectional printer dev 7 if 0 alt 0 proto 2 vid 0x03F0 pid 0x3E17
Feb 26 13:38:09 localhost root[3797]: loading HP Device 002 007
Feb 26 13:38:09 localhost systemd-udevd[3796]: 2-11: Process '/bin/sh -c '/usr/bin/nohup /usr/bin/hp-config_usb_printer 002:007'' failed with exit code 127.
Feb 26 13:38:09 localhost root[3817]: loading HP Device 002 007
Feb 26 13:38:09 localhost systemd-udevd[3796]: 2-11: Process '/bin/sh -c '/usr/bin/nohup /usr/bin/hp-config_usb_printer 002:007'' failed with exit code 127.
Feb 26 13:38:09 localhost colord-sane[3812]: io/hpmud/musb.c 2099: Invalid usb_open: Permission denied
Feb 26 13:38:09 localhost colord-sane[3812]: io/hpmud/pp.c 627: unable to read device-id ret=-1

CC: olelukoie => (none)

(In reply to Thomas Andrews from comment #62)
> I'll remove your name from the CC list. You should still receive emails for
> this bug, but only one copy.

Oh, thank you. But it seems your attempt to remove me from CC list hadn't had any effect. I've removed myself once again ))

(In reply to Oleg Bosis from comment #65)
> (In reply to Thomas Andrews from comment #62)
> > I'll remove your name from the CC list. You should still receive emails for
> > this bug, but only one copy.
> 
> Oh, thank you. But it seems your attempt to remove me from CC list hadn't
> had any effect. I've removed myself once again ))

OK, I see the problem now. You are listed under two email addresses. Hover your cursor over your name in Comment 52 and you see the old one. Starting with Comment 53 you are seeing the new one. As a consequence, you are getting email to both of them, assuming both still exist.

I think you need someone with more authority than I have to fix that one.

Created attachment 13172 [details]
Patch to fix udev rule

I've adopted a patch from OpenSuSe's hplip package. This patch seems to fix hplip udev rule properly and my printer works correctly with it (i.e. firmware uploads to printer automatically and I also get correct toner and paper status info).

(In reply to Oleg Bosis from comment #67)
> Created attachment 13172 [details]
> Patch to fix udev rule
> 
> I've adopted a patch from OpenSuSe's hplip package. This patch seems to fix
> hplip udev rule properly and my printer works correctly with it (i.e.
> firmware uploads to printer automatically and I also get correct toner and
> paper status info).

Hi,

In hplip-3.22.2-1.mga8, that patch is included.  Could you test and see if it works for you, please?

Best regards,

Nico.

CC: (none) => nicolas.salguero

(In reply to Nicolas Salguero from comment #68)
> Hi,
> 
> In hplip-3.22.2-1.mga8, that patch is included.  Could you test and see if
> it works for you, please?
> 
> Best regards,
> 
> Nico.

Seems like installing plugin and uploading firmware works normally.

There is another small problem that may be related to udev rule: no automatic updating printer status in HPLIP Status Service, but I don't now the reason yet. I've set the update interval to 10 sec but it doesn't work. I'll open another bugreport if I find the cause of this problem...

Suggested advisory:
========================

The updated packages:
  - add support for several new printers;
  - fix uploading printer firmware automatically.

References:
https://bugs.mageia.org/show_bug.cgi?id=10072
========================

Updated packages in core/updates_testing:
========================
hplip-3.22.4-1.mga8
hplip-doc-3.22.4-1.mga8
hplip-gui-3.22.4-1.mga8
hplip-hpijs-3.22.4-1.mga8
hplip-hpijs-ppds-3.22.4-1.mga8
hplip-model-data-3.22.4-1.mga8
lib(64)hpip0-3.22.4-1.mga8
lib(64)hpip0-devel-3.22.4-1.mga8
lib(64)sane-hpaio1-3.22.4-1.mga8

from SRPM:
hplip-3.22.4-1.mga8.src.rpm

Version: Cauldron => 8
Status: REOPENED => ASSIGNED
Assignee: pkg-bugs => qa-bugs
Whiteboard: MGA8TOO => (none)
Keywords: Triaged => (none)

I own three HP printers, all three of which have been working with Mageia 8:

An aged-but-still-functioning Deskjet 5650
A not-so-aged Color Laserjet CP1215
A relatively-new Envy Photo 7858

Because this update concerns the HP plugin, which is supposed to be required for hplip with my Laserjet, I removed the Laserjet printer and rebooted before updating.

Downloaded the above packages with qarepo. No installation issues.

Checked the still-installed printers with the HP device manager, and immediately ran into trouble. While in the "Actions" tab, none of the printers showed as accessible. The "Status" tab showed a "Device Communication Error." Yet, I could change settings under the "Printer Settings" tab, and could print from other apps with the printer. This was the case with all printers, whether already installed or newly installed.

Trying to install the Laserjet with hp-setup has never been successful. I always run into problems getting the plugin to download and install. This time it was successful. While I wasn't able to print a test page from the device manager because of the issue in the last paragraph, I was able to print one from system-config-printer, and indeed it told me it was using the "hp-color-laserjet-cp1215.ppd" driver. 

In the past, installing the Laserjet from system-config-printer always used the "FOO2HP" driver, which doesn't require the plugin. And indeed, that is still the case. And, the quality of the FOO2HP driver is considerably better than that of hplip, so I will be continuing to use that driver with that printer.

I had one system where the Envy Photo 7858 had not yet been installed. I installed it with system-config-printer, and the issue from bug 30059, duplex printing on US letter paper, is still resolved.

(In reply to Thomas Andrews from comment #71)
> 
> Checked the still-installed printers with the HP device manager, and
> immediately ran into trouble. While in the "Actions" tab, none of the
> printers showed as accessible. The "Status" tab showed a "Device
> Communication Error." Yet, I could change settings under the "Printer
> Settings" tab, and could print from other apps with the printer. This was
> the case with all printers, whether already installed or newly installed.
> 
Adding the feedback tag because of this regression. The gui works properly with the one from hplip 3.21.12, but not with this version.

Keywords: (none) => feedback

Hi,

Here, with a Envy 5540, connected using Wifi, I show the same "Device Communication Error." in the "Status" tab but, after waiting maybe ten seconds, I show my printer and the printer also appears in the "Actions" tab.

I will try to see if I can find a solution for your problem on the Web.

Best regards,

Nico.

"connected using wifi..." Hmmm. I neglected to mention that all of my tests were printers connected through usb 2.0. 

The Laserjet is only capable of connecting through usb. The 7858 does have wireless capability, but I wasn't using it that way on that machine. The Deskjet can be usb or parallel, but I haven't use parallel in years.

(In reply to Thomas Andrews from comment #72)
> Adding the feedback tag because of this regression. The gui works properly
> with the one from hplip 3.21.12, but not with this version.

Does version 3.22.6 solve the regression?

Updated packages in core/updates_testing:
========================
hplip-3.22.6-1.mga8
hplip-doc-3.22.6-1.mga8
hplip-gui-3.22.6-1.mga8
hplip-hpijs-3.22.6-1.mga8
hplip-hpijs-ppds-3.22.6-1.mga8
hplip-model-data-3.22.6-1.mga8
lib(64)hpip0-3.22.6-1.mga8
lib(64)hpip0-devel-3.22.6-1.mga8
lib(64)sane-hpaio1-3.22.6-1.mga8

from SRPM:
hplip-3.22.6-1.mga8.src.rpm

Thanks, Nicolas.

No time to test right now - I have to get to work. But, I can remove the feedback tag, and maybe someone else can take a look before I get to it.

Keywords: feedback => (none)

I simply upgraded:

- hplip-3.22.6-1.mga8.x86_64
- hplip-gui-3.22.6-1.mga8.x86_64
- hplip-hpijs-3.22.6-1.mga8.x86_64
- hplip-hpijs-ppds-3.22.6-1.mga8.x86_64
- hplip-model-data-3.22.6-1.mga8.x86_64
- lib64hpip0-3.22.6-1.mga8.x86_64
- lib64sane-hpaio1-3.22.6-1.mga8.x86_64

Clean update. I rebooted the system just o be sure.

Test case: I just bought a used HP Color LaserJet CP3525dn 

I am not sure what HPLIP is supposed to do;
I clicked the tray icon (hp) and selected the device manager.
It correctly said no Installed HP devices found, and suggested three alternatives, one being to use the distros setup, so I used MCC > hardware > Printers.

There I chose Add > Network printer > AppSocket
Entered IP, a few settings, and it printed the test page.
Easy as that.

HP device manager still say "no Installed HP devices found"

I apparently do not know how to utilise this thing, nor what good it could do...

(In reply to Morgan Leijström from comment #78)
> I am not sure what HPLIP is supposed to do;
> I clicked the tray icon (hp) and selected the device manager.
> It correctly said no Installed HP devices found, and suggested three
> alternatives, one being to use the distros setup, so I used MCC > hardware >
> Printers.
> 
> There I chose Add > Network printer > AppSocket
> Entered IP, a few settings, and it printed the test page.
> Easy as that.

But what about after you Power Off the printer and turn it back on?
The initial bug is that the printer works when doing just as you described, but when the printer – or the computer in my experience back in the day – is turned off and back on again the printer will not work unless the printer is reinstalled.

I remember having this exact problem back in mga4 days, when I sold a HP LaserJet 1000 to my brother after testing it on the mga system in the second hand shop I worked at. We had to replace it for him.

Booted into the test system where I saw the regression, the one with all usb-connected printers, and brought it up-to-date. (New kernel, etc.) Before updating hplip, I tried the device manager once more, and made a discovery that I missed before. 

It seems that if I boot with the Laserjet and Envy powered down, then turn them on afterward, the device manager doesn't throw the communication error on those two. If I boot with them powered up, it does - even if I power them down and then back up again. The deskjet can't be fully powered down unless the power cord is pulled out (designed that way - stupid), so no matter what I do there's a communication error with that one.

Updated over version 3.22.4-1 with no installation errors, but the behavior is the same. And, it still works properly with hplip 3.21.12 in my production install on the same hardware.

(In reply to Johnny A. Solbu from comment #79)
> (In reply to Morgan Leijström from comment #78)
> But what about after you Power Off the printer and turn it back on?

Tested now: no problem.
This printer do not need firmware upload.

(In reply to Nicolas Salguero from comment #73)
> Hi,
> 
> Here, with a Envy 5540, connected using Wifi, I show the same "Device
> Communication Error." in the "Status" tab but, after waiting maybe ten
> seconds, I show my printer and the printer also appears in the "Actions" tab.
> 
I have my Envy Photo 7858 set up to connect using wifi on another computer, and it acts as you describe. So, it would seem that the regression I'm seeing only affects usb printers.

MGA8-64 Plasma on Acer Aspire 5253.
Using current HP Device manager to remove my HP Envy 6022 All-in-one wifi connected device. Checked in MCC-Hardware that no printer or scanner was listed.
Installed the updates OK.
HP Device manager does not handle wifi connections, so used MCC-Hardware-Printer to configure the printer (Find network printer - enter its IP-address, select type of device etc....), went OK.
Checked MCC-Hardware-scanner that device is listed: OK. But using Document scanner says a propietary plugin is needed, accepted it to download it from HP-site, installation was successfull and scanner works OK.
So OK for me, but waiting for others with other devices.

CC: (none) => herman.viaene

(In reply to Herman Viaene from comment #83)
> MGA8-64 Plasma on Acer Aspire 5253.
> Using current HP Device manager to remove my HP Envy 6022 All-in-one wifi
> connected device. Checked in MCC-Hardware that no printer or scanner was
> listed.
> Installed the updates OK.
> HP Device manager does not handle wifi connections, so used
> MCC-Hardware-Printer to configure the printer (Find network printer - enter
> its IP-address, select type of device etc....), went OK.
> Checked MCC-Hardware-scanner that device is listed: OK. But using Document
> scanner says a propietary plugin is needed, accepted it to download it from
> HP-site, installation was successfull and scanner works OK.
> So OK for me, but waiting for others with other devices.

All of the steps you performed _also_ works for the original issue posting.
You did not test the actuall step that the issue is about.

The actuall test happens after installing the printer, which is to turn the printer Off, and then back on.

According to Oleg and several people – including me when testing for my brother 5 years ago – the printer does not work when the printer is turned off and then back on (or in my case, restarting the computer).

The proprietary Firmware is supposed to be loaded when the printer becomes available, but it only did this during the proprietary plugin installation.

(In reply to Herman Viaene from comment #83)
> Installed the updates OK.
> HP Device manager does not handle wifi connections, so used

The device manager should be able to handle wifi, but it might be necessary to run it as root to do so. There is an option under the Device tab to setup a device. All that does is run the "hp-setup" command, but it does it as the user. 

Best way to install a wifi HP printer without using system-config-printer (MCC) is to run "hp-setup" as root. If you already know your printer's IP, you can run "hp-setup x.x.x.x" where the x's are the IP, and skip the discovery step.

Herman, if you could test the firmware upload as indicated in Comment 84, and it passes, I'm inclined to send this on despite the glitch with usb printers and the device manager. Addressing the issue that this bug was created for, and adding support for new printers, is more important than the problem I'm seeing. 

My problem can be worked around by not powering up usb printers until they are to be used, and for those older printers that never really shut down that can be accomplished with switching mains power to the printer's power supply. Probably better for the environment if that's done, anyway.

It's worth noting that this issue only affects HP printers that Require the proprietary pluging in order to Print, because they require software to upload the firmware into the printer every time the printer is started. Any other HP printer will not have any issues.

According to the files installed with the plugin, it affects these specific printers, which is the ones need in order to actually test the issue:

HP Laserjet 1000
HP Laserjet 1005 series
HP Laserjet 1018
HP Laserjet 1020
HP Laserjet p1005
HP Laserjet p1006
HP Laserjet p1007
HP Laserjet p1008
HP Laserjet p1009
HP Laserjet p1505
HP Laserjet Professional p1102
HP Laserjet Professional p1102w
HP Laserjet Professional p1566

@TJ Comment 85:
Device manager has two options to setup wifi printer:
the first (Ethernet/wifi) requires to open ports in the firewall, which I won't do, never.
The second option requires a temporary USB connection, which in my case is quite impractical, would need a 10 m. USB cable.
So for all my needs/options, it does not work.

@Johnny
My Envy 6022 does not require a plugin apparently for printing, but it does for scanning.

@Johnny Comment 84
Switching off and on the printer has no ill effects on this printer. Also scanning works OK after switching the printer back  on, the scanning works OK without requesting the propietary plugin.

@Johnny Comment 86:

That list is incomplete, according to https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html My guess would be that it is an old list that the hplip developers haven't kept updated, but it is only a guess. I'm not sure when the link was last updated, so there may be even more than indicated there.

@Herman:

My experience is with one , and only one printer capable of wifi operation, so I probably should not be dispensing advice on this subject. My apologies. Thank you for confirming that the issue appears to be resolved.

OKing, and Validating. I will open a new bug on the usb/device manager issue once this has been pushed. Advisory in Comment 70, with a revised package list in Comment 76.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: (none) => MGA8-64-OK

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2022-0092.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED