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
Hi Debian developers,
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 seems feasab
41 matches
Mail list logo
