Bug 1033952

Looks like a problem with the proprietary plugin and/or the printer.
In any case not something we can fix.

Could you fill this bug at HPLIP upstream ?
https://bugs.launchpad.net/hplip/+filebug

(In reply to Jiri Popelka from comment #1)
I saw a similar bug report on Launchpad before filing it here, although I'm not sure if it's the same one. It's also for older hplip version.
It's this one: https://bugs.launchpad.net/hplip/+bug/1196711

Original bug description doesn't sound exactly the same, but comment #4 (from the reporter of the bug) clearly describes my problem. Also, comment #8 describes the bug on Mint with my printer as well.

It says 'fix released' and no other comments are present, so I'm not sure if it's fixed or not.

Anyway, if you could please check? In case it will look like the same bug to your experienced eyes, I will gladly create an Launchpad account and comment on it.
In case I should create new report there, I will do that instead.


Thanks.

I've filed a separate bug report which I think gets to the point of it.

Can you run "hp-firmware" instead of "hp-plugin"? Does that allow the printer to print again each time it is connected?

Thank you.

I tried hp-firmware, same result as with hp-plugin.
Like with hp-plugin, after running hp-firmware, the plugin is loaded and I can print.
After turning printer off, plugin is not loaded and printing is not possible.

Isn't the problem with this patch - hplip-udev-rules.patch, which removes udev rule intended to automatically load firmware?

Unfortunately it isn't as simple as removing that patch, as hp-config_usb_printer needs to be shipped as well, but it pulls dependencies from the 'hplip' package into 'hplip-common'. Needs thinking about how best to split that.

It is possible to use hp-firmware tool. Something like this:
SUBSYSTEM=="usbmisc", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="2b17", RUN+="/usr/bin/hp-firmware -y3&"
works for me.

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

hplip downloaded from http://hplipopensource.com works fine. Definitely the problem is in firmware is not being loaded on printer plug in. I examined udev rules in hpmud.rules and it seems that Fedora's rpm is missing the following string which actually loads firmware:

# This rule will check the smart install feature, plugin status and firmware download for the required printers.
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/python /usr/bin/hp-config_usb_printer $env{BUSNUM}:$env{DEVNUM} ; fi &'"

Right: but see comment #6.

(In reply to Tim Waugh from comment #6)
> Unfortunately it isn't as simple as removing that patch, as
> hp-config_usb_printer needs to be shipped as well, but it pulls dependencies
> from the 'hplip' package into 'hplip-common'.

What about not removing the udev rule (mentioned in comment #9),
but moving it into separate udev file that would be shipped (along with hp-config_usb_printer) in the main package ?
Then it might work provided the main package is installed.

Jiri: yes, that seems like a good approach. It will still mean that people without the main package installed will see this issue, though, so I wonder whether the hpijs sub-package should just be folded into the main package eventually. In other words, I don't think HPLIP is designed to allow the GUI parts to be separated out -- or to be used remotely.

Also, that rule looks pretty clumsy, I guess because of wanting to run on non-systemd systems. Maybe instead of the check for systemctl, we could re-write it to use ENV{SYSTEMD_WANTS}+=hplip-printer*.service. What do you think?

(In reply to Tim Waugh from comment #12)
> so I wonder
> whether the hpijs sub-package should just be folded into the main package
> eventually.

What is the reason why we have hplip and hpijs separated ?
I understand it as separation of data (hpijs) and control (hplip).
But since bug #1194186 fix we've had PDDs in both packages.
Also many of the printers which have ppd/drv in hpijs require running hp-plugin from hplip.
So I lean to merging those two together.

> In other words, I don't think HPLIP is designed to allow the GUI
> parts to be separated out -- or to be used remotely.

What GUI parts do you mean ? I don't see any in hplip/hpijs, only in hplip-gui.

> Also, that rule looks pretty clumsy, I guess because of wanting to run on
> non-systemd systems. Maybe instead of the check for systemctl, we could
> re-write it to use ENV{SYSTEMD_WANTS}+=hplip-printer*.service. What do you
> think?

That looks like the proper way, yes.

Let's just merge them then. I don't now remember why hpijs was initially split out, and it seems to be causing more problems than it's solving.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 '20'.

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 20 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.

(In reply to Jiri Popelka from comment #11)
> What about not removing the udev rule (mentioned in comment #9),
> but moving it into separate udev file that would be shipped (along with
> hp-config_usb_printer) in the main package ?
> Then it might work provided the main package is installed.

http://pkgs.fedoraproject.org/cgit/hplip.git/commit/?id=188cf820f01f9ce4a6cfd54b74d8083f7ab18587

(In reply to Tim Waugh from comment #12)
> Also, that rule looks pretty clumsy, I guess because of wanting to run on
> non-systemd systems. Maybe instead of the check for systemctl, we could
> re-write it to use ENV{SYSTEMD_WANTS}+=hplip-printer*.service. What do you
> think?

I'm staying with 'systemctl --no-block start hplip-printer@.service' [1] to not diverge from upstream too much, but I suggested the change in https://bugs.launchpad.net/hplip/+bug/1479431

[1] https://bbs.archlinux.org/viewtopic.php?id=181080

(In reply to Tim Waugh from comment #14)
> Let's just merge them then. I don't now remember why hpijs was initially
> split out, and it seems to be causing more problems than it's solving.

http://pkgs.fedoraproject.org/cgit/hplip.git/commit/?id=2ef869366f07cbddb2d5a9d91b5b3ac80a62a5a6

hplip-3.15.7-3.fc23 has been submitted as an update for Fedora 23.
https://admin.fedoraproject.org/updates/hplip-3.15.7-3.fc23

Package hplip-3.15.7-3.fc23:
* should fix your issue,
* was pushed to the Fedora 23 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing hplip-3.15.7-3.fc23'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-12379/hplip-3.15.7-3.fc23
then log in and leave karma (feedback).

hplip-3.15.7-3.fc23 has been pushed to the Fedora 23 stable repository.  If problems still persist, please make note of it in this bug report.

Yesterday I was notified that this still doesn't work, so this time I'm [1]:

- moving 56-hpmud.rules into main package completely
  - leaving hp-config_usb_printer in main package
- removing hplip-printer@.service as the 56-hpmud.rules doesn't call
systemctl --no-block start hplip-printer@$env{BUSNUM}:$env{DEVNUM}.service
anymore as it did few versions ago, but calls directly
/usr/bin/nohup /usr/bin/hp-config_usb_printer $env{BUSNUM}:$env{DEVNUM}'
(see also https://bugs.launchpad.net/hplip/+bug/147943)

Result is that hplip-udev-rules is now very minimalistic so it's not prone to breaking anytime upstream changes the rules file (which has been quite often).

[1] http://pkgs.fedoraproject.org/cgit/hplip.git/commit/?h=f23&id=6a8ce90c340d94960d3ee15400e98695f47c7616

(In reply to Jiri Popelka from comment #20)
> (see also https://bugs.launchpad.net/hplip/+bug/147943)

https://bugs.launchpad.net/bugs/1479431

hplip-3.15.11-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-641840267e

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

hplip-3.15.11-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update hplip'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-641840267e

This new version is a huge step for me. So now when I plug the printer I get asked by software to install a firmware, out of memory was some package starting with foo2qxq? Right after the printer is detected and installed, in control center the printer will not show still any firmware. Also it will not work properly.
Instead if after this, I remove the printer from the control center and add it again, then I am able to choose the firmaware and it will work properly.

hplip-3.15.11-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.