Mailing List Archive

On N, 2008-05-08 at 21:09 +0200, Fabian Groffen wrote:
> > e) It has been suggested the support should have been added with new
> > EAPI instead of local build deps (some of which are missing, for
> > instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format
> > net-tools doesn't have a dep in addition to using lzma for no good
> > reason)
>
> Chill, relax and cool down.

Well, I said how it is. I don't see anything in it that indicates I am
so upset and angry that I need to do these things. I did however loose
hours of work time, but that's life.

> Instead, just ask those who decided to
> follow upstream why and if they have even thought about the issues you
> brought up.

This is what I am doing with this as well, in addition to the bug
reports. But as this is widespread to at least 4-6 system packages, I
brought it up here as well to ensure this is not something I have to
fight against in overlays and time wastes continuously in the future.
Oh and net-tools has not distributed anything in .tar.lzma, so this has
nothing to do with following upstream in any shape or form in this case.

--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

>>>>> "Doug" == Doug Goldstein <cardoe@gentoo.org> writes:

Doug> If you read the lzma changelogs, it appears to imply that newer
Doug> ones won't be able to read older formats. The changelog
Doug> specifically states if a user they are handling the issue
Doug> "gracefully" by telling the user to upgrade or downgrade their
Doug> lzma.

My understanding is that the new utils will be able to uncompress
current archives, but will not be able to create them and also will
be unable to convert current archives to the new format w/o a full
(and time-consuming) uncompress/compress cycle.

-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
--
gentoo-dev@lists.gentoo.org mailing list

On Wednesday 07 May 2008, Fabian Groffen wrote:
> m4, that one gave me some headaches, because lzma-utils required some
> eautoreconf, which introduced a nice cycle.

must have been a prefix-only bug as the version in the tree never did
-mike

On 10-05-2008 03:32:08 -0400, Mike Frysinger wrote:
> On Wednesday 07 May 2008, Fabian Groffen wrote:
> > m4, that one gave me some headaches, because lzma-utils required some
> > eautoreconf, which introduced a nice cycle.
>
> must have been a prefix-only bug as the version in the tree never did

Ehmm... you're right. Sorry about that.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-dev@lists.gentoo.org mailing list

On Saturday 10 May 2008, Fabian Groffen wrote:
> On 10-05-2008 03:32:08 -0400, Mike Frysinger wrote:
> > On Wednesday 07 May 2008, Fabian Groffen wrote:
> > > m4, that one gave me some headaches, because lzma-utils required some
> > > eautoreconf, which introduced a nice cycle.
> >
> > must have been a prefix-only bug as the version in the tree never did
>
> Ehmm... you're right. Sorry about that.

ive added a comment to the ebuild so as to future proof me or anyone else
forgetting about this gotcha.
-mike

* Mart Raudsepp <leio@gentoo.org> schrieb:

<big_snip />

IMHO, lzma is far from being mature enough from being suited as
packaging format for production systems. And actually, I don't
see the benefit over well-approved tar+(gz|bz2).

So my vote is to NOT use it for gentoo source packages.


cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
gentoo-dev@lists.gentoo.org mailing list

On Wed, 07 May 2008 16:23:12 +0300
Mart Raudsepp <leio@gentoo.org> wrote:

> Hello,
>
> Over the course of this year, a lzma-utils buildtime dependency has
> been added to a few system packages, to handle .tar.lzma tarballs.
> This has huge implications on the requirement of the system toolchain,
> which is highly disturbing from a minimal (lets say embedded) systems
> concern - lzma-utils depends on the C++ compiler and the libstdc++
> beast, while a minimal system would like to avoid this at all cost.

The new lzma-utils codebase uses liblzma, written in C. It's at the
alpha stage but supposedly supports encoding/decoding the current lzma
format "well enough" (;P). It probably has some fun bugs to find
and squish.

http://sf.net/mailarchive/forum.php?thread_name=200804251652.58484.lasse.collin%40tukaani.org&forum_name=lzmautils-announce

--
fonts, gcc-porting, by design, by neglect
mips, treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Duncan <1i5t5.duncan@cox.net> writes:

>> So it would also be possible to compile "lzmadec" without any need for
>> C++. Just call "make" in subdirs liblzmadec and lzmadec.
>
> What about USE=decode-only or something similar for lzma-utils, then? If
> desired, it could even be masked on "normal" profiles, but would then be
> there for the embedded and releng folks.

USE=cxx should do just fine, it will disable the C++-related parts,
whatever they are. Sincerely I'd quite like to enable it on my vserver's
build chroots too.

(BTW I considered using lzma for backup compression, but I didn't get
much different results from bzip2 in term of size, but took quite longer
in case of compression... I still have some doubts whether lzma is worth
it).

--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

Graham Murray <graham@gmurray.org.uk> writes:

> Should that be USE=-cxx? The help for USE=cxx says that this builds
> support for C++.

It was meant as setting a cxx USE on the ebuild, I wasn't certainly
meaning to disable the C++ parts with USE=cxx enabled ;)

--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:

> You miss my point. GNU tar sometimes changes its on disk format (and
> will be doing so again at some point for xattrs)

It's not really important to the discussion, but...

The TAR format is designed as such that on disk formats can be extended
without breaking entirely backward compatibility. For what it's worth,
extended attributes and ACLs are already supported by star (Schilling's)
and bsdtar (libarchive). The fact that GNU tar doesn't support them at
the moment is a different problem. On the other hand, even if the GNU
tar does not support reading those attributes, it does handle them
gracefully, warning the user of unknown extended headers, and then
proceeding to unpack the data without preserving the extended
attributes.

So what Doug said stands perfectly and does not interest GNU tar at all.

--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

On Thu, 08 May 2008 09:17:08 -0400
Doug Goldstein <cardoe@gentoo.org> wrote:

> Ryan Hill wrote:
> > The new lzma-utils codebase uses liblzma, written in C. It's at the
> > alpha stage but supposedly supports encoding/decoding the current
> > lzma format "well enough" (;P). It probably has some fun bugs to
> > find and squish.
> >
> > http://sf.net/mailarchive/forum.php?thread_name=200804251652.58484.lasse.collin%40tukaani.org&forum_name=lzmautils-announce

> According to the mailing list this change was done to fix security
> holes in the format and also resulted in a slightly different format
> that's incompatible with the previous verion. So lzma 5.x and higher
> will be a different on disk format. It's troubling to me that
> projects are using lzma when it's on disk format isn't even final and
> the project has security issues.

The current format is fine. It's the new format that has
design/security issues. Yes the formats are incompatible, but so
are .tar.lzma and .7z, which are both lzma. Either way I was just
offering it as a data point. I have no real opinion one way or the
other.


--
fonts, gcc-porting, by design, by neglect
mips, treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662