hp-plugin doesn't work in hplip-3.17.9 - move to 3.17.10 if you need

[R P Herrold]

On Thu, 26 Oct 2017, Zdenek Dohnal wrote:

>  HP changed website this week, which has consequences for getting hp
>  proprietary plugin - it cannot be downloaded anymore for hplip-3.17.9,
>  which is in stable Fedoras (f25 and f26) and Fedora 27. ... 
>  upstream several times about uploading plugin into openprinting.org
>  website, but without answer (probably because it was available on
>  hplipopensource.com). That's the situation for hplip-3.17.9. 
 
>  Luckily, there is hplip-3.17.10 in updates-testing repository, which
> has
>  plugin on openprinting.org. So if someone now needs to install printer,
>  which needs proprietary plugin, please update hplip to 3.17.10 from 
Not so much luck, as a sufficiently good process mostly being 
followed ['The more a well designed process is followed and 
tweaked with improvements, the more lucky one becomes' ;) ]

The post partially quoted above points up another benefit from 
the virtue of 'packaging everything' as discussed in the 
recent 'packaging ruby dependencies' thread.  When an upstream 
'goes wonky' for whatever reason (there was a similar example 
in the Node.js ecosystem where a maintainer took down a minor 
but critical dependency, and 'broke world'), one can 'fall 
back' to the last SRPMS (and other VCS backups as well), and 
recover

Without packaged sources, and the discipline of sub-dependency 
determination and solution, and the 'four freedoms' checking 
goodness of a formal 'licenses review', and the additional set 
of eyes cross-checking work, one loses so much

-- Russ herrold

[Zdenek Dohnal]

On 10/26/2017 01:50 PM, R P Herrold wrote:
>  On Thu, 26 Oct 2017, Zdenek Dohnal wrote:
>
> > HP changed website this week, which has consequences for getting hp
> > proprietary plugin - it cannot be downloaded anymore for hplip-3.17.9,
> > which is in stable Fedoras (f25 and f26) and Fedora 27. ...
> > upstream several times about uploading plugin into openprinting.org
> > website, but without answer (probably because it was available on
> > hplipopensource.com). That's the situation for hplip-3.17.9.
>   
> > Luckily, there is hplip-3.17.10 in updates-testing repository, which has
> > plugin on openprinting.org. So if someone now needs to install printer,
> > which needs proprietary plugin, please update hplip to 3.17.10 from
>  Not so much luck, as a sufficiently good process mostly being 
>  followed ['The more a well designed process is followed and 
>  tweaked with improvements, the more lucky one becomes' ;) ]
>
>  The post partially quoted above points up another benefit from 
>  the virtue of 'packaging everything' as discussed in the 
>  recent 'packaging ruby dependencies' thread.  When an upstream 
>  'goes wonky' for whatever reason (there was a similar example 
>  in the Node.js ecosystem where a maintainer took down a minor 
>  but critical dependency, and 'broke world'), one can 'fall 
>  back' to the last SRPMS (and other VCS backups as well), and 
>  recover
>
>  Without packaged sources, and the discipline of sub-dependency 
>  determination and solution, and the 'four freedoms' checking 
>  goodness of a formal 'licenses review', and the additional set 
>  of eyes cross-checking work, one loses so much
>  
Issue is that plugin is proprietary (owned by HP) and it contains
precompiled data, so it cannot be packaged.  Upstream doesn't reply on
most issues. But this plugin is needed by group of printers, so there
needs to be a way to download it (if we want to support these printers
in Fedora).

-- 
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C

[Kevin Kofler]

Zdenek Dohnal wrote:
>  Issue is that plugin is proprietary (owned by HP) and it contains
>  precompiled data, so it cannot be packaged.  Upstream doesn't reply on
>  most issues. But this plugin is needed by group of printers, so there
>  needs to be a way to download it (if we want to support these printers
>  in Fedora). 
Another sad thing is that there is still a lot of code in the plugin blob 
that does not really need to be. The JBIG patents expired years ago, but all 
the algorithms depending on JBIG are still hidden in the plugin. There seems 
to be no move from HP on open-sourcing any of the algorithms in the plugin, 
no matter what made them end up in there in the first place. Some of those 
codecs (IIRC, most or all of the printing ones, but not many of the scanning 
ones) have third-party reverse-engineered drivers available, but they are 
not integrated in the HPLIP infrastructure. I also get the feeling that more 
and more of the current models need the plugin.

This is really sad, because HPLIP was originally a genuine contribution to 
Free Software (a high-quality manufacturer driver actually released as pure 
Free Software, the plugin did not even exist in the initial versions), but 
unfortunately, it is degenerating more and more into a freewashing tool for 
proprietary driver blobs. The codec algorithms that use the plugin are 
entirely implemented inside the plugin (not just the patented parts), the 
"Free driver" HPLIP is just a dispatching wrapper around the blob for those 
algorithms.

        Kevin Kofler