[gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

I'd like to remove <net-print/foo2zjs-99999999. Non-live versions are
severely outdated (2008) and unusable (upstream changes tarballs
in-place, digest verification is broken).

The upstream doesn't support snapshots of the tarball, and claims the
auxiliary files cannot be redistributed.

I think the best course of action is to leave just the live ebuild (I'm
using it on one system that has a printer that requires it).

If there are no objections, I'm going to make the change. My guess is
that most people don't care about this abandoned package, and the people
who are using it will appreciate removal of the brokenness.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[Gökdeniz Karadağ]

On 02-06-2011 18:20, "Paweł Hajdan, Jr." wrote:
> I'd like to remove<net-print/foo2zjs-99999999. Non-live versions are
> severely outdated (2008) and unusable (upstream changes tarballs
> in-place, digest verification is broken).
>
> The upstream doesn't support snapshots of the tarball, and claims the
> auxiliary files cannot be redistributed.
>
> I think the best course of action is to leave just the live ebuild (I'm
> using it on one system that has a printer that requires it).
>
> If there are no objections, I'm going to make the change. My guess is
> that most people don't care about this abandoned package, and the people
> who are using it will appreciate removal of the brokenness.
>

I use the foo2zjs package, and because other versions are broken, have 
moved to the live version. But I think expecting a stable version in the 
tree is not too much for a user. A tarball snapshot in a ~dev space 
would solve the issue I presume.

Further problems with the current live ebuild are as follows. It seems 
that I have forgotten to file bugs about these issues previously.
  * Does not install PPD files (bug #369819)
  * Does not use FOO2ZJS_DEVICES from previous versions, thus downloads 
lots of tar files multiple times. (bug #369821)

Existance of previous ebuilds *currently*; allows for comparison, 
detection, and hopefully fixing of these issues.

-- 
Gökdeniz Karadağ

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On Thu, 02 Jun 2011 17:20:41 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> The upstream doesn't support snapshots of the tarball, and claims the
> auxiliary files cannot be redistributed.
> 
> I think the best course of action is to leave just the live ebuild
> (I'm using it on one system that has a printer that requires it).

I think it may be useful to have a snapshot anyway. If you can't
tarball it, maybe a tagged VCS ebuild? I'm not sure if such a thing is
supposed to lie unmasked in the tree but it's better than no non-live
ebuild.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

On 6/2/11 6:51 PM, Michał Górny wrote:
> I think it may be useful to have a snapshot anyway. If you can't
> tarball it, maybe a tagged VCS ebuild? I'm not sure if such a thing is
> supposed to lie unmasked in the tree but it's better than no non-live
> ebuild.

I know that would be useful, and I'd love to do that.

However, as far as I know there is no VCS. The guy just changes the
tarballs and updates the webpage.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On 6/2/11 7:00 PM, Dane Smith wrote:
> I'm going to guess you've already tried this, but just in case. Did
> you try asking him to version things more... sanely? I've had to do
> that a few times and people are usually surprisingly receptive.

Right, that's a good idea. Have you visited <http://foo2zjs.rkkda.com/>
? The message on that page is quite hostile towards distros:

> *** DON'T USE the foo2zjs package from: Ubuntu, SUSE,
> Mandrake/Manrivia, Debian, RedHat, Fedora, Gentoo, Xandros, EEE PC,
> Linpus, MacOSX, or BSD! *** Download it here and follow the
> directions below.

Also, someone has asked a similar question:
<http://foo2zjs.rkkda.com/forum/read.php?29,2802,2802>. He got no response.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

On 6/2/11 7:00 PM, Dane Smith wrote:
> I'm going to guess you've already tried this, but just in case. Did you
> try asking him to version things more... sanely? I've had to do that a
> few times and people are usually surprisingly receptive.

Ah, and see also
<http://osdir.com/ml/linux.frugalware.devel/2005-11/msg00022.html>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

On 6/2/11 6:04 PM, Gökdeniz Karadağ wrote:
> I use the foo2zjs package, and because other versions are broken, have
> moved to the live version. But I think expecting a stable version in the
> tree is not too much for a user. A tarball snapshot in a ~dev space
> would solve the issue I presume.

We can't have a tarball, most of the files from the package are
non-redistributable.

> Further problems with the current live ebuild are as follows. It seems
> that I have forgotten to file bugs about these issues previously.
>  * Does not install PPD files (bug #369819)
>  * Does not use FOO2ZJS_DEVICES from previous versions, thus downloads
> lots of tar files multiple times. (bug #369821)

I replied on those bugs. Thank you for reporting.

> Existance of previous ebuilds *currently*; allows for comparison,
> detection, and hopefully fixing of these issues.

They'll always be in the CVS history.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[dev-random]

On Fri, Jun 03, 2011 at 08:40:26AM +0200, "Paweł Hajdan, Jr." wrote:
> ...
> We can't have a tarball, most of the files from the package are
> non-redistributable.
> ...

Then why do ebuilds contain line LICENSE="GPL-2"?

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

On Thu, 02 Jun 2011 19:17:44 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> On 6/2/11 7:00 PM, Dane Smith wrote:
> > I'm going to guess you've already tried this, but just in case. Did
> > you try asking him to version things more... sanely? I've had to do
> > that a few times and people are usually surprisingly receptive.
> 
> Right, that's a good idea. Have you visited
> <http://foo2zjs.rkkda.com/> ? The message on that page is quite
> hostile towards distros:

Sorry, I haven't seen this either. I thought you mean a VCS when you
mentioned a 'live' ebuild. Now that I see how the ebuilds look like,
I have only one idea. It's simple yet ugly.

You could have a 'versioned' ebuild linked to the actual SRC_URI,
and bump it whenever you notice the upstream tarball changes. This
would allow users to have the package upgraded automatically.
I think it would be similar to the situation we had with adobe-flash
packages.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:
> You could have a 'versioned' ebuild linked to the actual SRC_URI,
> and bump it whenever you notice the upstream tarball changes. This
> would allow users to have the package upgraded automatically.
>   

I don't think this will help users much. It will just make the package
uninstallable between the time the upstream tarball changes and the
package is bumped.
A live ebuild is at least honestly telling users what to expect.

> I think it would be similar to the situation we had with adobe-flash
> packages.
>   

It reminds me more of the (now defunct) live ebuild of chromium-bin


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[Chí-Thanh Christopher Nguyễn]

Patrick Lauer schrieb:
> On 06/03/11 16:09, Chí-Thanh Christopher Nguyễn wrote:
>   
>> Michał Górny schrieb:
>>     
>>> You could have a 'versioned' ebuild linked to the actual SRC_URI,
>>> and bump it whenever you notice the upstream tarball changes. This
>>> would allow users to have the package upgraded automatically.
>>>   
>>>       
>> I don't think this will help users much. It will just make the package
>> uninstallable between the time the upstream tarball changes and the
>> package is bumped.
>> A live ebuild is at least honestly telling users what to expect.
>>     
> Just mirror the darn tarball in a stable location.
> I've done that for silly and weird upstreams ...
>   

The problem (already mentioned earlier in this thread) is that some
parts are not redistributable.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[Patrick Lauer]

On 06/03/11 16:09, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
>> You could have a 'versioned' ebuild linked to the actual SRC_URI,
>> and bump it whenever you notice the upstream tarball changes. This
>> would allow users to have the package upgraded automatically.
>>   
> 
> I don't think this will help users much. It will just make the package
> uninstallable between the time the upstream tarball changes and the
> package is bumped.
> A live ebuild is at least honestly telling users what to expect.

Just mirror the darn tarball in a stable location.
I've done that for silly and weird upstreams ...
> 
>> I think it would be similar to the situation we had with adobe-flash
>> packages.
>>   
> 
> It reminds me more of the (now defunct) live ebuild of chromium-bin
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 
> 


-- 
Patrick Lauer         http://service.gentooexperimental.org

Gentoo Council Member and Evangelist
Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[ross smith]

> The problem (already mentioned earlier in this thread) is that some
> parts are not redistributable.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn


I've looked through the website and the tarbell and I've not seen
anything that says it's not redistributable.   In the readme, there is
some warning that things built with JBIG1 may fall under software that
is already patentable, but that doesn't say the file can't be
distributed.   What part of it is causing that problem?

Best,
Ross Smith

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

On 6/3/11 4:09 PM, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
>> You could have a 'versioned' ebuild linked to the actual SRC_URI,
>> and bump it whenever you notice the upstream tarball changes. This
>> would allow users to have the package upgraded automatically.
> I don't think this will help users much. It will just make the package
> uninstallable between the time the upstream tarball changes and the
> package is bumped.
> A live ebuild is at least honestly telling users what to expect.

Agreed. The 'version' ebuild linked to the tarball changing in place is
actually the current state of non-live ebuilds (by the way, do people
responding in this thread actually read ebuilds in question?).

This thread is about removing those 'versioned' ebuilds, so your
response could be interpret as "don't remove them". But then they're
broken, and if I bump them today a few weeks/months from now they'll be
broken again.

The live ebuild should be more "resilient".

>> I think it would be similar to the situation we had with adobe-flash
>> packages.
> It reminds me more of the (now defunct) live ebuild of chromium-bin

Interesting, I was maintaining chromium-bin and I masked it. Doesn't
seem similar to me (did you mean google-chrome-bin or similar hacks?).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[Chí-Thanh Christopher Nguyễn]

"Paweł Hajdan, Jr." schrieb:
> This thread is about removing those 'versioned' ebuilds, so your
> response could be interpret as "don't remove them". But then they're
> broken, and if I bump them today a few weeks/months from now they'll be
> broken again.
>   

I'm all for removing the non-live ebuilds.

>> It reminds me more of the (now defunct) live ebuild of chromium-bin
>>     
> Interesting, I was maintaining chromium-bin and I masked it. Doesn't
> seem similar to me (did you mean google-chrome-bin or similar hacks?)

I meant the chromium-bin-9999.ebuild which did this:
LV=`curl --silent
http://build.chromium.org/buildbot/snapshots/chromium-rel-linux${arch_path}/LATEST`
elog "Installing/updating to version ${LV}"
wget -c
"http://build.chromium.org/buildbot/snapshots/chromium-rel-linux${arch_path}/${LV}/chrome-linux.zip"
-O "${T}"/${PN}-${LV}.zip
76

So essentially a live ebuild which downloads changing stuff from a http URI.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[Chí-Thanh Christopher Nguyễn]

ross smith schrieb:
> I've looked through the website and the tarbell and I've not seen
> anything that says it's not redistributable.   In the readme, there is
> some warning that things built with JBIG1 may fall under software that
> is already patentable, but that doesn't say the file can't be
> distributed.   What part of it is causing that problem?
>   

To my knowledge, the firmware files for HP printers are not
redistributable.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

On 6/3/11 9:18 AM, dev-random@mail.ru wrote:
> On Fri, Jun 03, 2011 at 08:40:26AM +0200, "Paweł Hajdan, Jr." wrote:
>> ...
>> We can't have a tarball, most of the files from the package are
>> non-redistributable.
>> ...
> 
> Then why do ebuilds contain line LICENSE="GPL-2"?

Good catch. Well, the situation here is really unclear. Most of the
package obviously is under GPL-2. Files downloaded by getweb script are
copyrighted, but they have no clear license.

I'm not a maintainer of the package, I'm just trying to make it work a
bit better and remove the brokenness. ;-)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

On 6/2/11 5:20 PM, "Paweł Hajdan, Jr." wrote:
> I'd like to remove <net-print/foo2zjs-99999999. Non-live versions are
> severely outdated (2008) and unusable (upstream changes tarballs
> in-place, digest verification is broken).

I went ahead and committed the change. I might try to provide some
non-live ebuild in the future, and of course help is welcome.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

On Wed, 08 Jun 2011 16:09:53 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> On 6/2/11 5:20 PM, "Paweł Hajdan, Jr." wrote:
> > I'd like to remove <net-print/foo2zjs-99999999. Non-live versions
> > are severely outdated (2008) and unusable (upstream changes tarballs
> > in-place, digest verification is broken).
> 
> I went ahead and committed the change. I might try to provide some
> non-live ebuild in the future, and of course help is welcome.

BTW if you'd like to create an eclass for that kind of live packages
(which fetch packages from upstream), I could add smart rebuild
possibility to start-live-rebuild [1]. This way, foo2zjs users would be
able to upgrade their package whenever upstream tarball changes.

[1]:https://github.com/mgorny/smart-live-rebuild

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

On 6/8/11 4:17 PM, Michał Górny wrote:
> BTW if you'd like to create an eclass for that kind of live packages
> (which fetch packages from upstream), I could add smart rebuild
> possibility to start-live-rebuild [1]. This way, foo2zjs users would be
> able to upgrade their package whenever upstream tarball changes.
> 
> [1]:https://github.com/mgorny/smart-live-rebuild

Interesting, sounds like that could be useful. But I have no idea how
such an eclass would look like (rather trivial), and there are not many
packages that would use it (currently just one).

How about PROPERTIES="live"? We could add "live" to possible values of
PROPERTIES...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

On Wed, 08 Jun 2011 18:14:49 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> On 6/8/11 4:17 PM, Michał Górny wrote:
> > BTW if you'd like to create an eclass for that kind of live packages
> > (which fetch packages from upstream), I could add smart rebuild
> > possibility to start-live-rebuild [1]. This way, foo2zjs users
> > would be able to upgrade their package whenever upstream tarball
> > changes.
> > 
> > [1]:https://github.com/mgorny/smart-live-rebuild
> 
> Interesting, sounds like that could be useful. But I have no idea how
> such an eclass would look like (rather trivial), and there are not
> many packages that would use it (currently just one).
> 
> How about PROPERTIES="live"? We could add "live" to possible values of
> PROPERTIES...

That won't be enough. s-l-r has to get somehow the method of checking
and the URL list. Right now, it is constructed in such a way that
the method is based on VCS eclass being inherited, and then it grabs
appropriate ebuild vars from environment.bz2.

Such an eclass would have to take tarball URIs in some kind of envvar
and export some kind of 'download timestamp'. Then the Python module in
s-l-r would HEAD those URIs to get the current timestamp and compare
that to the value exported in environment.bz2.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: removal of <net-print/foo2zjs-99999999 (earlier versions are fubar)

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On 6/8/11 6:25 PM, Michał Górny wrote:
> Such an eclass would have to take tarball URIs in some kind of envvar
> and export some kind of 'download timestamp'. Then the Python module in
> s-l-r would HEAD those URIs to get the current timestamp and compare
> that to the value exported in environment.bz2.

Feel free to suggest such an eclass and/or file an enhancement bug for
the package, but for now I probably won't be able to work on that.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]