Adam Borowski wrote:
> If you want a fair comparison:
> -rw-r--r-- 1 kilobyte kilobyte 98826240 Jun 16 20:26 octave-4.2.1.tar
> -rw-r--r-- 1 kilobyte kilobyte 15826565 Jul 7 17:13 octave-4.2.1.tar.lz
> -rw-r--r-- 1 kilobyte kilobyte 15174400 Jul 7 17:13 octave-4.2.1.tar.xz
>
> xz wins by 4.2%, wit
Adam Borowski writes:
> Thus, I'd recommend dropping lzip completely. It's worse and obscure.
> With every distro having standardized on xz, providing lzip tarballs is
> a pure waste of space.
Personally, I don't see why anyone should care which compression formats
upstream provides as long as
On Fri, Jul 07, 2017 at 11:01:12AM -0400, Lennart Sorensen wrote:
> On Mon, Jul 03, 2017 at 12:38:59PM +0100, Thomas Pircher wrote:
> > in the example you mentioned upstream have added xz to the set of archives
> > they distribute their source in. Currently[1] the GNU Octave source code is
> > bein
On Mon, Jul 03, 2017 at 12:38:59PM +0100, Thomas Pircher wrote:
> Hi Maria,
>
> in the example you mentioned upstream have added xz to the set of archives
> they distribute their source in. Currently[1] the GNU Octave source code is
> being distributed as .gz, lz and .xz tarballs.
>
> I don't get
Matthias Klumpp wrote...
> So, lzip isn't adopted widely, that's certainly not because of Debian
> or any other Linux distribution.
The war is over, the winner is VHS.
Trying to get lzip support in wider usage is somewhat a boot-up
problem: Few people see an advantage in doing this, so it doesn'
On Mon, 3 Jul 2017 16:25:37 +0200, Maria Bisen
wrote:
>2017-07-03 15:11 GMT+02:00 Matthias Klumpp :
>> So, lzip isn't adopted widely, that's certainly not because of Debian
>> or any other Linux distribution.
>
>I agree, but I thought that Debian adopting lzip could make lzip more
>widely adopted;
On Mon, 03 Jul 2017 12:38:59 +0100, Thomas Pircher
wrote:
>I don't get it; what exactly is the problem when upstream distributes
>their source in multiple formats, including .xz and .lz, among others?
That the lzip community knows that the lzipped sources will almost
never be decompressed by any
Hi Matthias,
2017-07-03 15:11 GMT+02:00 Matthias Klumpp :
>
> So, lzip isn't adopted widely, that's certainly not because of Debian
> or any other Linux distribution.
>
I agree, but I thought that Debian adopting lzip could make lzip more
widely adopted; and that's why I started this thread. Now
2017-07-03 14:42 GMT+02:00 Maria Bisen :
> [...]
> 4- As a result, lzip is almost never used alone (without xz), and Debian can
> justify forever the lack of lzip support
>
> You need to consider all four points to understand the issue.
No, please read again the mails previous developers wrote. Lz
Hi Thomas,
Thomas wrote:
> I don't get it; what exactly is the problem when upstream distributes
their
> source in multiple formats, including .xz and .lz, among others?
Please check again point 1 and 2. See below:
1- Somebody from Debian says: "if a lot of upstream tarballs start to be
nativel
Maria Bisen writes ("Re: Please add lzip support in the repository"):
> Moreover, software errors have already killed people:
Good grief.
This conversation is:
1. determined advocacy from an external project
2. going badly
3. not capable of leading to any productive outcome
li
On 2017-07-03 11:41, Maria Bisen wrote:
3- Somebody else, also from Debian, asks the upstream above to bring
back
the xz tarball
4- As a result, lzip is almost never used alone (without xz), and
Debian can
justify forever the lack of lzip support
Hi Maria,
in the example you mentioned upst
Hi,
Russ Allbery wrote:
>> As an user of Octave who wish to see more lzip adoption, I don't think
>> this to be fair.
> Octave's use of lzip is completely unrelated to Debian asking for xz.
> Providing xz in no way prevents Octave from also providing lzip. I think
> you are inventing a conflict
Paul Wise wrote...
> On Thu, Jun 15, 2017 at 9:05 PM, Christoph Biedl wrote:
>
> > I'm not keen on extending regular expressions like
> >
> > \.(gz|bz2|lzma|xz)$
> >
> > that I have in many places again and again.
>
> That sort of hard-coding should stop,
Understandable and desirable, but p
Maria Bisen writes:
> Also, I think the issue here it's not just proponents of lzip "coming
> here", but Debian people "going out", in what I reckon can be a conflict
> of interest.
This isn't what "conflict of interest" means. This is just an interest.
There is no conflict.
Currently, Debian
Hi Russ,
Russ Allbery wrote:
> Debian has never expressed any opinion about lzip outside of our project
> mailing lists. The only reason why it's even on our radar is that
> proponents of lzip keep *coming here* and trying to push it on us. Some
> of them are polite about it, and we've had poli
Maria Bisen writes:
> After reading again Guillem Jover's answer it seems to me that the only
> marketing campaign here is Debian against lzip. Even if you don't like
> something, for whatever personal reasons, I don't think it's fine to
> influence thousands of people, and Debian has the capacit
Hi,
Sorry for the delay, but I think this needs a clarification.
Ian Jackson wrote:
> For Debian binary and source packages, there is no benefit in ECC
> in the compression layer.
>
> I'm not sure why all of this isn't obvious.
>
> As an aside: I am sceptical of the value of ECC as part of a gen
Henrique de Moraes Holschuh writes ("Re: Please add lzip support in the
repository"):
> On Fri, 16 Jun 2017, Adrian Bunk wrote:
> > On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
> > >...
> > > We pretty much need Debian pac
On Fri, 16 Jun 2017, Adrian Bunk wrote:
> On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
> >...
> > We pretty much need Debian packages to be 100% correct in the first
> > place, they are not going to be subject to lossy recovery from
> > corruption (which is where lzi
Adrian Bunk wrote:
> On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
[...]
>> So, it would make more sense to have a par2 (or create a modern version
>> of it, actually) ECC layer on top of the compression layer, at which
>> point we can use one of the already supporte
On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
>...
> We pretty much need Debian packages to be 100% correct in the first
> place, they are not going to be subject to lossy recovery from
> corruption (which is where lzip is supposed to be much better than xz):
> we nee
On 2017-06-16 12:42:00 +0200 (+0200), Maria Bisen wrote:
[...]
> When I saw in the gcc thread that there's only one distribution
> not supporting lzip
[...]
Following the GCC discussion you linked, I believe it was actually a
reference to SLES lacking any package of lzip at all:
https://gcc.g
Russ Allbery wrote:
> Oh, you're concerned with what upstream tarballs Debian can consume
> without repackaging.
>
> I don't see any reason why this should prevent GCC from releasing tarballs
> compressed with lzip if they want to. They certainly wouldn't stop
> releasing tarballs in other format
> lzip 1.19 is available just in Debian experimental, because we are in
> final-countdown nearly-absolute freeze: we will release the next Debian
> stable this weekend, with lzip 1.18.
>
> lzip 1.19 should be uploaded to Debian unstable sometime after we
> release, at its debian maintainer discreti
On Thu, Jun 15, 2017 at 08:30:33PM -0700, Russ Allbery wrote:
> writes:
>
> > First of all, thank you for your kind and sympathetic message. I'm
> > referring to the second option you mentioned. We are using gcc, and it
> > seems that a reason to not use lzip in gcc is that Debian doesn't
> > sup
writes:
> First of all, thank you for your kind and sympathetic message. I'm
> referring to the second option you mentioned. We are using gcc, and it
> seems that a reason to not use lzip in gcc is that Debian doesn't
> support source tarballs in lzip format.
Oh, you're concerned with what upstr
On Thu, 15 Jun 2017, mariabi...@gmail.com wrote:
> PS: lzip version available in Debian is 1.16, but the last one is 1.19. Maybe
> it's time to update! :)
lzip 1.19 is available just in Debian experimental, because we are in
final-countdown nearly-absolute freeze: we will release the next Debian
On Thu, 15 Jun 2017, Christoph Biedl wrote:
> Also I doubt the reduced disk space and network bandwitdth usage of any
> new kid on the block (there's also zstd) really justifies the work
> needed to implement the support in the many tools that deal with the
> files. I might be convinced otherwise.
Hi,
Russ Allbery wrote:
> > Maria Bisen writes:
> > It's been drawn to my attention the topic included in this thread:
> > https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
> > I've got the feeling that the distribution the thread talks about is
> > precisely yours, Debian's. As stated there,
Hi Guillem,
Guillem Jover wrote:
> On Thu, 2017-06-15 at 17:22:53 +0500, Andrey Rahmatullin wrote:
> > On Thu, Jun 15, 2017 at 01:55:10PM +0200, Maria Bisen wrote:
> > > It's been drawn to my attention the topic included in this thread:
> > >
> > > https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
Maria Bisen writes:
> It's been drawn to my attention the topic included in this thread:
> https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
> I've got the feeling that the distribution the thread talks about is
> precisely yours, Debian's. As stated there, giving support to lzip in
> Debian see
Stuart Prescott writes ("Re: Please add lzip support in the repository"):
> > What is `apt-helper cat-file' and how does it help ?
>
> On stretch:
>
> $ apt-file search apt-helper
> apt: /usr/lib/apt/apt-helper
Ah. I looked on PATH. I expect "Fr
Hi!
On Fri, 2017-06-16 at 00:35:37 +1000, Stuart Prescott wrote:
> > What is `apt-helper cat-file' and how does it help ?
> $ apt-file search apt-helper
> apt: /usr/lib/apt/apt-helper
> $ /usr/lib/apt/apt-helper download-file
> http://deb.debian.org/debian/dists/sid/main/binary-amd64/Packages.x
> What is `apt-helper cat-file' and how does it help ?
On stretch:
$ apt-file search apt-helper
apt: /usr/lib/apt/apt-helper
$ /usr/lib/apt/apt-helper
apt 1.4.6 (amd64)
Usage: apt-helper [options] command
apt-helper [options] cat-file file ...
apt-helper [options] download-file uri
Paul Wise writes ("Re: Please add lzip support in the repository"):
> On Thu, Jun 15, 2017 at 9:05 PM, Christoph Biedl wrote:
> > I'm not keen on extending regular expressions like
> >
> > \.(gz|bz2|lzma|xz)$
> >
> > that I have in many place
Hi!
On Thu, 2017-06-15 at 17:22:53 +0500, Andrey Rahmatullin wrote:
> On Thu, Jun 15, 2017 at 01:55:10PM +0200, Maria Bisen wrote:
> > It's been drawn to my attention the topic included in this thread:
> >
> > https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
> >
> > I've got the feeling that the
On Thu, Jun 15, 2017 at 9:05 PM, Christoph Biedl wrote:
> I'm not keen on extending regular expressions like
>
> \.(gz|bz2|lzma|xz)$
>
> that I have in many places again and again.
That sort of hard-coding should stop, if you see it somewhere please
switch to using apt, either via the apt lib
Maria Bisen wrote...
> I've got the feeling that the distribution the thread talks about is
> precisely yours, Debian's. As stated there, giving support to lzip in
> Debian seems feasable and easy. Could it be possible, then, to add
> lzip support? : )
If I understand correctly, it's about using
On Thu, Jun 15, 2017 at 01:55:10PM +0200, Maria Bisen wrote:
> It's been drawn to my attention the topic included in this thread:
>
> https://gcc.gnu.org/ml/gcc/2017-06/msg00084.html
>
> I've got the feeling that the distribution the thread talks about is
> precisely yours, Debian's. As stated th
40 matches
Mail list logo
