[gentoo-dev] Last rites: app-arch/xarchiver

[gentoo-dev] Last rites: app-arch/xarchiver

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

# Markos Chandras <hwoarang@gentoo.org> (02 Nov 2013)
# On behalf of Treecleaners
# Upstream started a complete rewrite of the package
# meaning that existing bugs will not be fixed by future
# version bumps of the existing code.
# It is unclear when/if the new code will be released any time
# soon so masked for removal in 30 days.
# The package can be re-introduced later on if the new
# maintainer feels it is stable enough.
# See #483588 and #473692
app-arch/xarchiver

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQJ8BAEBCgBmBQJSdSV1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88t6UP/RnVftEt5nvWMGTAZeiTVBy+
rc/KdpW4tT7xNlkfoQvtmcBjx7UPXePOUcmRVODaOK/F5R5gCijnwqoENP2r0xVV
KX8kmZL2R1oX98p9hRssiZ3a6wiZbvGsy8P/voOvQhKJCu0i1xl/Iio/5ZfyTaQT
zFtcMC8nn0LIFH20lQft5ukFQTQdoktb8XL70dfjSU8iCu/lrBrIU19cdOH5psev
IEzu39t732aqNiEoXJb6r8l9kpBeeunRQ7pDP3GC8RunME/MxHuNELJPqCUFC4F7
iRJZd6fFyY3pSObhXA6FtEtLPx0xSX+FEOKE/OGOaDnrQ3IMm9nwk5/zLjGZCXhi
spW7z970Kv6f9VzUEQmLGBDA8pgRkZo2bfvd4hMjeK/Szzr/v+FU0RjKrYwV0Wxo
ncXWFmL/MwWhXo6Nc8LjN+4BDUlZKDNMgf30R+g3LxhCLmX98fHFbVjGvL4nrGkF
z/zqVtnk4led1ipGQFQweseaNYbQrkq4nJbgATjLAOcQwsrpZEj3PGs89uI/Eo3f
830YGeleoIZkd1pf1QwVoHdLxbBlIKlVua/PgXtfQLTEqdgxrY5Se9Mqf25xqwfx
KejCOHDWWWYFTlfkodKkiM3qsvzwORM0+b6JA2jxw047yeXoDTb1y2q0X0oA+kjT
Ri+2zibvoDZJksjRz4xR
=Xd15
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Last rites: app-arch/xarchiver

[yac]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I don't think that upstream deciding to rewrite a package is good
enough reason to tree clean the package. Have you done this
with eg. bind package which is constantly rewritten and constantly have
security issues?

The same goes for closing bugs until the versions are
removed from portage (either because version deprecation or treeclean
with proper reason) as users may find those informational.


On Sat, 02 Nov 2013 16:16:53 +0000
Markos Chandras <hwoarang@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> # Markos Chandras <hwoarang@gentoo.org> (02 Nov 2013)
> # On behalf of Treecleaners
> # Upstream started a complete rewrite of the package
> # meaning that existing bugs will not be fixed by future
> # version bumps of the existing code.
> # It is unclear when/if the new code will be released any time
> # soon so masked for removal in 30 days.
> # The package can be re-introduced later on if the new
> # maintainer feels it is stable enough.
> # See #483588 and #473692
> app-arch/xarchiver
> 
> - -- 
> Regards,
> Markos Chandras
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> 
> iQJ8BAEBCgBmBQJSdSV1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
> OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88t6UP/RnVftEt5nvWMGTAZeiTVBy+
> rc/KdpW4tT7xNlkfoQvtmcBjx7UPXePOUcmRVODaOK/F5R5gCijnwqoENP2r0xVV
> KX8kmZL2R1oX98p9hRssiZ3a6wiZbvGsy8P/voOvQhKJCu0i1xl/Iio/5ZfyTaQT
> zFtcMC8nn0LIFH20lQft5ukFQTQdoktb8XL70dfjSU8iCu/lrBrIU19cdOH5psev
> IEzu39t732aqNiEoXJb6r8l9kpBeeunRQ7pDP3GC8RunME/MxHuNELJPqCUFC4F7
> iRJZd6fFyY3pSObhXA6FtEtLPx0xSX+FEOKE/OGOaDnrQ3IMm9nwk5/zLjGZCXhi
> spW7z970Kv6f9VzUEQmLGBDA8pgRkZo2bfvd4hMjeK/Szzr/v+FU0RjKrYwV0Wxo
> ncXWFmL/MwWhXo6Nc8LjN+4BDUlZKDNMgf30R+g3LxhCLmX98fHFbVjGvL4nrGkF
> z/zqVtnk4led1ipGQFQweseaNYbQrkq4nJbgATjLAOcQwsrpZEj3PGs89uI/Eo3f
> 830YGeleoIZkd1pf1QwVoHdLxbBlIKlVua/PgXtfQLTEqdgxrY5Se9Mqf25xqwfx
> KejCOHDWWWYFTlfkodKkiM3qsvzwORM0+b6JA2jxw047yeXoDTb1y2q0X0oA+kjT
> Ri+2zibvoDZJksjRz4xR
> =Xd15
> -----END PGP SIGNATURE-----
> 



- -- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: F97A36A1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJSdTyBAAoJEIN+7RD5ejah9vcH/2NhbApohR5Bq14fQzHgcne0
YJ7TV3m75ttr4rpb3Ox1HQeRrzDnDJuLuaPY/MzXGw+QuMrA30y5cCc10V08AaFO
SfxYY+GwrvdbqMbwxeULbtuIKgTTwdb5gBNL+3gpx+8xdZeZvTd/MHTKnu185ejq
wYc2MyS3S1ttSFIcVp550uQ+lMdq9cn/a4T2LN/Pclzmpjh/DsE5eIaEACUMRlSx
c76rVunc1CWzgwGwzGsfs0ES/Qv26eL7sf7oL89LKsTCzg07yaSQVMP7eEvB9k5j
CJtbhFcaBfunhPSP4bov2sKq8f6Clvn236hFazvL3THsCCr5hH5Ny3IeiE2tFdk=
=A1Sm
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Last rites: app-arch/xarchiver

[Markos Chandras]

On 11/02/2013 05:55 PM, yac wrote:
> Hi,
> 
> I don't think that upstream deciding to rewrite a package is good
> enough reason to tree clean the package. Have you done this
> with eg. bind package which is constantly rewritten and constantly have
> security issues?
> 
> The same goes for closing bugs until the versions are
> removed from portage (either because version deprecation or treeclean
> with proper reason) as users may find those informational.
> 

Ok let me clarify this again

1) The original code of the package is gone since upstream started from
scratch.
2) It has no maintainer.
3) It has open bugs and upstream will never fix them and there is no
maintainer to patch the code to fix it properly.

So per treecleaner policy the package will be removed.

Or have you just volunteered to become maintainer and fix the bugs?

-- 
Regards,
Markos Chandras

Re: [gentoo-dev] Last rites: app-arch/xarchiver

[yac]

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

On Sat, 02 Nov 2013 17:57:34 +0000
Markos Chandras <hwoarang@gentoo.org> wrote:

> On 11/02/2013 05:55 PM, yac wrote:
> > Hi,
> > 
> > I don't think that upstream deciding to rewrite a package is good
> > enough reason to tree clean the package. Have you done this
> > with eg. bind package which is constantly rewritten and constantly
> > have security issues?
> > 
> > The same goes for closing bugs until the versions are
> > removed from portage (either because version deprecation or
> > treeclean with proper reason) as users may find those informational.
> > 
> 
> Ok let me clarify this again
> 
> 1) The original code of the package is gone since upstream started
> from scratch.

What do you mean by gone? I still can `ebuild xarchiver* fetch` the
sources.

Otherwise this is not a reason to treeclean the package.

> 2) It has no maintainer.

Not a reason for treecleaning.

> 3) It has open bugs and upstream will never fix them and there is no
> maintainer to patch the code to fix it properly.

In bgo[1] there are two bugs open. Upstream [2] seems to have more bugs
but they also seem to be mostly new features or corner cases.

There already was discussion on treecleaning bug[3] where you claim the
package is "broken" while several users explain it is broken
*partialy*. Eg. c30 says only 2 formats doesn't work.

c21 claims it always crashes on passwords, however upstream bug reports
indicates it's also true for only some formats.

c6 indicates xarchiver will break on unrar-5 when it will go stable but
it still is not stable, is it? Given the way this issue is
communicated, I have to ask - Is it even true? The rar major version
seems to be related to rar format version rather then ABI/API.

Even if xarchiver breaks on unrar-5, I see many other packages
depending on unrar, do you know these will not break and possibility of
having both unrar4 and 5 will not be just due xarchiver?

> So per treecleaner policy the package will be removed.
> 
> Or have you just volunteered to become maintainer and fix the bugs?
> 

[1]
https://bugs.gentoo.org/buglist.cgi?quicksearch=xarchiver
[2] https://bugzilla.xfce.org/buglist.cgi?quicksearch=xarchiver
[3] https://bugs.gentoo.org/show_bug.cgi?id=483588
-- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: F97A36A1

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

Re: [gentoo-dev] Last rites: app-arch/xarchiver

[Alexandre Rostovtsev]

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

On Sat, 2013-11-02 at 20:12 +0100, yac wrote:
> c6 indicates xarchiver will break on unrar-5 when it will go stable but
> it still is not stable, is it? Given the way this issue is
> communicated, I have to ask - Is it even true? The rar major version
> seems to be related to rar format version rather then ABI/API.
> 
> Even if xarchiver breaks on unrar-5, I see many other packages
> depending on unrar, do you know these will not break and possibility of
> having both unrar4 and 5 will not be just due xarchiver?

Most GUI archiver frontends don't use libunrar (it's not gpl-compatible)
but instead run the rar or unrar executable and attempt to parse its
textual output. The format of this output in (un)rar-5 changed
significantly, so the frontends' parsing code needs to be rewritten.

>=app-arch/file-roller-3.8.4-r1 and >=kde-base/ark-4.11.2 have been
updated to support (un)rar-5. Earlier versions of file-roller and ark
work only with (un)rar-4, and the same is true for all released versions
of xarchiver.

If you wish to participate in xarchiver upstream development, you can
take a look at https://bugzilla.gnome.org/show_bug.cgi?id=707568 for how
file-roller's parser was updated to support both rar-4 and rar-5.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Last rites: app-arch/xarchiver

[Markos Chandras]

On 11/02/2013 07:12 PM, yac wrote:
> On Sat, 02 Nov 2013 17:57:34 +0000
> Markos Chandras <hwoarang@gentoo.org> wrote:
> 
>> On 11/02/2013 05:55 PM, yac wrote:
>>> Hi,
>>>
>>> I don't think that upstream deciding to rewrite a package is good
>>> enough reason to tree clean the package. Have you done this
>>> with eg. bind package which is constantly rewritten and constantly
>>> have security issues?
>>>
>>> The same goes for closing bugs until the versions are
>>> removed from portage (either because version deprecation or
>>> treeclean with proper reason) as users may find those informational.
>>>
>>
>> Ok let me clarify this again
>>
>> 1) The original code of the package is gone since upstream started
>> from scratch.
> 
> What do you mean by gone? I still can `ebuild xarchiver* fetch` the
> sources.
> 
> Otherwise this is not a reason to treeclean the package.
> 
>> 2) It has no maintainer.
> 
> Not a reason for treecleaning.
> 
>> 3) It has open bugs and upstream will never fix them and there is no
>> maintainer to patch the code to fix it properly.
> 
> In bgo[1] there are two bugs open. Upstream [2] seems to have more bugs
> but they also seem to be mostly new features or corner cases.
> 
> There already was discussion on treecleaning bug[3] where you claim the
> package is "broken" while several users explain it is broken
> *partialy*. Eg. c30 says only 2 formats doesn't work.
> 
> c21 claims it always crashes on passwords, however upstream bug reports
> indicates it's also true for only some formats.
> 
> c6 indicates xarchiver will break on unrar-5 when it will go stable but
> it still is not stable, is it? Given the way this issue is
> communicated, I have to ask - Is it even true? The rar major version
> seems to be related to rar format version rather then ABI/API.
> 
> Even if xarchiver breaks on unrar-5, I see many other packages
> depending on unrar, do you know these will not break and possibility of
> having both unrar4 and 5 will not be just due xarchiver?
> 
>> So per treecleaner policy the package will be removed.
>>
>> Or have you just volunteered to become maintainer and fix the bugs?
>>
> 
> [1]
> https://bugs.gentoo.org/buglist.cgi?quicksearch=xarchiver
> [2] https://bugzilla.xfce.org/buglist.cgi?quicksearch=xarchiver
> [3] https://bugs.gentoo.org/show_bug.cgi?id=483588
> 

I will not discuss this further. If you want to save it, step up and
maintain it.

-- 
Regards,
Markos Chandras