Hi Karel,

thank you for reporting the issue! The problem is on HP site - they want to place binary blobs in dirs, which do not exist, like:

/usr/lib/i386-linux-gnu/libjpeg.so.9
/usr/lib/x86_64-linux-gnu/libjpeg.so.9
/usr/lib64/x86_64-linux-gnu/libjpeg.so.9
/usr/lib/i386-linux-gnu/sane/libsane-hp2000S1.so
/usr/lib/x86_64-linux-gnu/sane/libsane-hp2000S1.so
/usr/lib64/x86_64-linux-gnu/sane/libsane-hp2000S1.so

It seems like some new shared libraries...

HP scripts, downloaded by hp-plugin, ignores these links and that's why installation outcome is 'Done'. But '__readPluginStatus' method checks existence of these links and if they do not exist, set '__plugin_state' to 'corrupted'. And '__readPluginStatus' method is called in 'getStatus' method, which is used in gui setupdialog (it is not shown when hp-setup is called as 'interactive').

IMO you should be able to add the printer by 'hp-setup -i', because CLI variant does not end right after finding out the plugin is 'corrupted' (it just check return value of hp-plugin command, which is 0, and all old libraries are in correct places, removing .run file from ~/.hplip seems fine). 

It is really confusing and troubling issue, but not really in my powers to solve it - because all links and files are downloaded directly from HP, because they cannot be packaged in Fedora. HP upstream should fix it their .run file.

The abrupt workaround would be exclude these links from check in __readPluginStatus in installer/pluginhandler.py. 

Reported upstream https://bugs.launchpad.net/hplip/+bug/1814574

hplip-3.18.12-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b489194d24

hplip-3.18.12-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b489194d24

https://bodhi.fedoraproject.org/updates/FEDORA-2019-b489194d24#comment-892211

(I thought Bodhi should switch automatically?)

hplip-3.18.12-4.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Can you try building an RPM package of the plugin using my spec file? https://gitlab.com/greysector/hplip-plugin

I noticed the new libs in the new version and tried to put them in the right place, but I don't have a printer that uses them so I couldn't test. It looks like you have one, so I'd appreciate it if you could test the latest version.

I'm not providing binary RPMs publicly because HP doesn't allow redistribution. I tried asking them for permission but the answer was: no.

@zdohnal: pls could you take a look and prepare what's needed to test?

@Dominik: if it doesn't move, ping me after RHEL8 is out - preferably in person, I tend to ignore mails from bugzilla, there's simply too many of them

Hi Dominik,

if you have correct info in your spec file, then the new shared libraries are for HP ScanJet Pro 2000, which Karel does not have. I only tested it by faking my HP officejet Pro 8500 wants plugin and check if older files are installed correctly and ignore the new ones for the time HP fixes its plugin.
Karel does have a type of HP color laserjet, which needed the plugin for scanning. And external scripts does not recognize if device actually needs only some of shared libraries and just install them all...

To sum it up, I nor Karel are able to check if it works :(

well, I could at least test the packaging, as the plugin installation is required for my device

to have a clean system, not influenced by our previous experiments, I've run KDE spin live dvd in qemu

I've built the packages from the spec referenced in comment #6 and installed them all

this pulled the hplip packages, however, to run hp-setup, I had to add hplip-gui manually (tested with 3.18.12-4.fc29)

to detect the device in hp-setup, I had to use manual setup, putting in the IP, as qemu creates own network by default and the broadcasts don't cross the network boundaries ... it worked without any problem, the device got detected

trying to configure it further, I got the request to install the plugin, same as what was the original point of this bugreport

so, bad luck, the plugin rpms obviously don't work for me, it doesn't get detected as already installed plugin


a few notes:

- I was building with rpmbuild under root, not mock, so I may have missed some misbehaviour

- it complained about macros in comments

- the gpg2 command to get Source2 is missing output file specification (I don't work with gpg so I was a bit surprised by getting binary mess printed in console ...)

(In reply to Karel Volný from comment #9)
> well, I could at least test the packaging, as the plugin installation is
> required for my device
> 
> to have a clean system, not influenced by our previous experiments, I've run
> KDE spin live dvd in qemu
> 
> I've built the packages from the spec referenced in comment #6 and installed
> them all
> 
> this pulled the hplip packages, however, to run hp-setup, I had to add
> hplip-gui manually (tested with 3.18.12-4.fc29)

It looks like hplip should have Recommends: hplip-gui. hp-setup supports
running in text mode, which might explain why there's no hard dependency.

> to detect the device in hp-setup, I had to use manual setup, putting in the
> IP, as qemu creates own network by default and the broadcasts don't cross
> the network boundaries ... it worked without any problem, the device got
> detected
>
> trying to configure it further, I got the request to install the plugin,
> same as what was the original point of this bugreport

Can you try without GUI, using the following command with correct IP?
hp-setup -g --auto 66.35.250.209

> so, bad luck, the plugin rpms obviously don't work for me, it doesn't get
> detected as already installed plugin

It would be useful to know what part of detection fails.

> a few notes:
> 
> - I was building with rpmbuild under root, not mock, so I may have missed
> some misbehaviour

I build it myself with rpmbuild under an unprivileged user or in mock. Both
work for me without any issues.

> - it complained about macros in comments

Well, that shouldn't be an issue. I have alternate download URL commented
out in case HP messes up uploads again.

> - the gpg2 command to get Source2 is missing output file specification (I
> don't work with gpg so I was a bit surprised by getting binary mess printed
> in console ...)

I don't understand what you mean here.

Thanks for trying!

(In reply to Dominik 'Rathann' Mierzejewski from comment #10)
> (In reply to Karel Volný from comment #9)
> > well, I could at least test the packaging, as the plugin installation is
> > required for my device
> > 
> > to have a clean system, not influenced by our previous experiments, I've run
> > KDE spin live dvd in qemu
> > 
> > I've built the packages from the spec referenced in comment #6 and installed
> > them all
> > 
> > this pulled the hplip packages, however, to run hp-setup, I had to add
> > hplip-gui manually (tested with 3.18.12-4.fc29)
> 
> It looks like hplip should have Recommends: hplip-gui. hp-setup supports
> running in text mode, which might explain why there's no hard dependency.
> 

IMHO The problem with recommending is the recommended package is installed everytime with 'main' package when the recommended package is available in the repos and dnf transaction of main package does not fail when the recommended package is missing. So it is no good for use case (when we want to separate scripts, which can run in CLI and those which can use only GUI).



(In reply to Dominik 'Rathann' Mierzejewski from comment #10)
> > so, bad luck, the plugin rpms obviously don't work for me, it doesn't get
> > detected as already installed plugin
> 
> It would be useful to know what part of detection fails.
> 

IMO the check mentioned in comment#1 did not pass - __readPluginStatus() method checks for files from plugin - hp script knows which files they are by plugin.spec, which scripts from downloaded 'plugin' put in /usr/share/hplip. Did you updated plugin.spec too?

(In reply to Zdenek Dohnal from comment #11)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #10)
> > (In reply to Karel Volný from comment #9)
> > > well, I could at least test the packaging, as the plugin installation is
> > > required for my device
> > > 
> > > to have a clean system, not influenced by our previous experiments, I've run
> > > KDE spin live dvd in qemu
> > > 
> > > I've built the packages from the spec referenced in comment #6 and installed
> > > them all
> > > 
> > > this pulled the hplip packages, however, to run hp-setup, I had to add
> > > hplip-gui manually (tested with 3.18.12-4.fc29)
> > 
> > It looks like hplip should have Recommends: hplip-gui. hp-setup supports
> > running in text mode, which might explain why there's no hard dependency.
> > 
> 
> IMHO The problem with recommending is the recommended package is installed
> everytime with 'main' package when the recommended package is available in
> the repos and dnf transaction of main package does not fail when the
> recommended package is missing. So it is no good for use case (when we want
> to separate scripts, which can run in CLI and those which can use only GUI).

It won't be installed if soft dep installation is disabled or the package
is excluded. hp-setup supports both CLI and GUI modes, so I think it makes
sense to have a soft dep on hplip-gui, but of course it's your call.

> (In reply to Dominik 'Rathann' Mierzejewski from comment #10)
> > > so, bad luck, the plugin rpms obviously don't work for me, it doesn't get
> > > detected as already installed plugin
> > 
> > It would be useful to know what part of detection fails.
> > 
> 
> IMO the check mentioned in comment#1 did not pass - __readPluginStatus()
> method checks for files from plugin - hp script knows which files they are
> by plugin.spec, which scripts from downloaded 'plugin' put in
> /usr/share/hplip. Did you updated plugin.spec too?

That could be it, thanks for the clue. I'll patch plugin.spec.

(In reply to Dominik 'Rathann' Mierzejewski from comment #12)
> (In reply to Zdenek Dohnal from comment #11)
> > IMHO The problem with recommending is the recommended package is installed
> > everytime with 'main' package when the recommended package is available in
> > the repos and dnf transaction of main package does not fail when the
> > recommended package is missing. So it is no good for use case (when we want
> > to separate scripts, which can run in CLI and those which can use only GUI).
> 
> It won't be installed if soft dep installation is disabled or the package
> is excluded. hp-setup supports both CLI and GUI modes, so I think it makes
> sense to have a soft dep on hplip-gui, but of course it's your call.
> 

Soft dep installation is enabled by default, is it? If it is, there are really very few people who install the sw with other option than just 'dnf install'...
And do you have any link for more info for excluding? 

Thanks!

(In reply to Dominik 'Rathann' Mierzejewski from comment #12)
> (In reply to Zdenek Dohnal from comment #11)
> > (In reply to Dominik 'Rathann' Mierzejewski from comment #10)
[...]
> > > It would be useful to know what part of detection fails.
> > 
> > IMO the check mentioned in comment#1 did not pass - __readPluginStatus()
> > method checks for files from plugin - hp script knows which files they are
> > by plugin.spec, which scripts from downloaded 'plugin' put in
> > /usr/share/hplip. Did you updated plugin.spec too?
> 
> That could be it, thanks for the clue. I'll patch plugin.spec.

OK, I've just pushed a new release to my spec (3.18.12-2) file to gitlab,
please test with:

hp-setup -g -i 192.168.0.1

Substitute your printer's IP, of course.

On my machine, it seems to work fine:

hp-setup[29476]: debug: /usr/lib64/libjpeg.so.9 library file present.
hp-setup[29476]: debug: /usr/lib64/libjpeg.so.9 library status: 1
hp-setup[29476]: debug: /usr/lib64/sane/libsane-hp2000S1.so library file present.
hp-setup[29476]: debug: /usr/lib64/sane/libsane-hp2000S1.so library status: 1
hp-setup[29476]: debug: /usr/lib64/sane/libsane-hp2000S1.so.1 library file present.
hp-setup[29476]: debug: /usr/lib64/sane/libsane-hp2000S1.so.1 library status: 1

(In reply to Zdenek Dohnal from comment #13)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #12)
> > (In reply to Zdenek Dohnal from comment #11)
> > > IMHO The problem with recommending is the recommended package is installed
> > > everytime with 'main' package when the recommended package is available in
> > > the repos and dnf transaction of main package does not fail when the
> > > recommended package is missing. So it is no good for use case (when we want
> > > to separate scripts, which can run in CLI and those which can use only GUI).
> > 
> > It won't be installed if soft dep installation is disabled or the package
> > is excluded. hp-setup supports both CLI and GUI modes, so I think it makes
> > sense to have a soft dep on hplip-gui, but of course it's your call.
> 
> Soft dep installation is enabled by default, is it?

Correct.

> If it is, there are
> really very few people who install the sw with other option than just 'dnf
> install'...

I don't know about that.

> And do you have any link for more info for excluding? 

I use:

dnf update -x recommended_package_I_don't_want_to_install

or I just disable soft deps using
/etc/dnf/dnf.conf
[main]
...
install_weak_deps = false

(In reply to Dominik 'Rathann' Mierzejewski from comment #6)
> Can you try building an RPM package of the plugin using my spec file?
> https://gitlab.com/greysector/hplip-plugin
> 
> I noticed the new libs in the new version and tried to put them in the right
> place, but I don't have a printer that uses them so I couldn't test. It
> looks like you have one, so I'd appreciate it if you could test the latest
> version.
> 
> I'm not providing binary RPMs publicly because HP doesn't allow
> redistribution. I tried asking them for permission but the answer was: no.

Is this where redistribution permission was denied? It doesn't look like a no so much as their failure to follow up: https://bugs.launchpad.net/hplip/+bug/1214318

(In reply to kxra from comment #16)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #6)
[...]
> > I'm not providing binary RPMs publicly because HP doesn't allow
> > redistribution. I tried asking them for permission but the answer was: no.
> 
> Is this where redistribution permission was denied? It doesn't look like a
> no so much as their failure to follow up:
> https://bugs.launchpad.net/hplip/+bug/1214318

Their first answer (https://bugs.launchpad.net/hplip/+bug/1214318/comments/1) was no. I have no contacts at HP to follow up with, but I added a new comment to that bug.