This is your one-day friendly reminder ! The monthly Gentoo Council
meeting is tomorrow in #gentoo-council on irc.freenode.net. See the
channel topic for the exact time (but it's probably 2000 UTC).
If you're supposed to show up, please show up. If you're not supposed
to show up, then show up a
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-
On 07-05-2008 16:23:12 +0300, Mart Raudsepp wrote:
> This is a plea and also a request for comments on the matter of
> using .tar.lzma tarballs or not, and for what packages this is
> acceptable and for what not.
Just as a little background:
GNU chose to switch from bzip2 to lzma, for it produces
On Wed, 2008-05-07 at 16:23 +0300, Mart Raudsepp wrote:
> I'd be happy if some other unpacker is used than lzma-utils - one that
> does not depend on libstdc++ - I'm sure it can be done, heck it's done
> in integrated form in some other projects in less than a couple
> kilobytes of code for the un
On Wed, May 7, 2008 at 3:23 PM, Mart Raudsepp <[EMAIL PROTECTED]> wrote:
> I'd be happy if some other unpacker is used than lzma-utils - one that
> does not depend on libstdc++ - I'm sure it can be done, heck it's done
> in integrated form in some other projects in less than a couple
> kilobyte
> On Wed, 07 May 2008, Natanael Copa wrote:
> busybox has unlzma and seems to be a part of "system".
> Should also be easy to create a really tiny unlzma from the busybox
> source and ship with portage, or create a patch for tar or something.
The decoder of lzma-utils is also written in C on
> On Wed, 7 May 2008, Benedikt Morbach wrote:
> tar-1.20 has lzma support, so maybe it could handle this too, once it
> goes into stable
This doesn't help, since it needs the lzma binary as a filter.
Ulrich
--
gentoo-dev@lists.gentoo.org mailing list
Hi,
I sent this to -dev to, but I think as an ordinary user I can't write there...
On Wed, May 7, 2008 at 3:23 PM, Mart Raudsepp <[EMAIL PROTECTED]> wrote:
> I'd be happy if some other unpacker is used than lzma-utils - one that
> does not depend on libstdc++ - I'm sure it can be done, heck it's
On Wed, 2008-05-07 at 16:23 +0300, Mart Raudsepp wrote:
> I do realize one would remove build-time dependencies and the toolchain
> on an embedded system on deployment anyway, but this means gcc USE=nocxx
> USE flag is pretty much useless, while it would be nice to use it to
> ensure that nothing s
Hi,
I think, as long as there is no really minimal lzmadec available
yet (as standalone package), we should more standard compressors
like gzip or bzip2. Adding that whole bunch of deps just to
save a few bytes IMHO isn't worth it.
cu
--
--
Enrico Weigelt wrote:
I think, as long as there is no really minimal lzmadec available
yet (as standalone package), we should more standard compressors
like gzip or bzip2. Adding that whole bunch of deps just to
save a few bytes IMHO isn't worth it.
Keep in mind that this might mean doing our
Richard Freeman wrote:
Enrico Weigelt wrote:
I think, as long as there is no really minimal lzmadec available
yet (as standalone package), we should more standard compressors
like gzip or bzip2. Adding that whole bunch of deps just to save a
few bytes IMHO isn't worth it.
Keep in mind that th
On Wed, 07 May 2008 16:23:12 +0300
Mart Raudsepp <[EMAIL PROTECTED]> 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
13 matches
Mail list logo
