Re: RFC: Support for zstd in .deb packages?

2021-01-10 Thread Balint Reczey
On Sun, Jan 10, 2021 at 8:41 PM Bastian Blank wrote: > > Moin > > On Sun, Jan 10, 2021 at 08:20:33PM +0100, Balint Reczey wrote: > > I'm not a fan of CLAs either, but as I understand upstream requiring a > > CLA is not a blocker for compression libraries. > > Well, it means that the library might

Re: RFC: Support for zstd in .deb packages?

2021-01-10 Thread Bastian Blank
Moin On Sun, Jan 10, 2021 at 08:20:33PM +0100, Balint Reczey wrote: > I'm not a fan of CLAs either, but as I understand upstream requiring a > CLA is not a blocker for compression libraries. Well, it means that the library might get incompatible with upstream, because upstream will refuse

Re: RFC: Support for zstd in .deb packages?

2021-01-10 Thread Balint Reczey
Hi Ian, On Fri, Apr 27, 2018 at 2:03 PM Ian Jackson wrote: > > Guillem Jover writes ("RFC: Support for zstd in .deb packages?"): > > * Eternity contract: This would add yet another format that would need > > to be supported pretty much forever, to be able to at least unpack > > .deb's that

Re: RFC: Support for zstd in .deb packages?

2021-01-10 Thread Balint Reczey
Hi Guillem, On Fri, May 4, 2018 at 11:41 PM Nick Terrell wrote: > > > > On May 4, 2018, at 6:22 AM, Guillem Jover wrote: > > > > Hi! > > > > On Fri, 2018-04-27 at 07:02:12 +0200, Guillem Jover wrote: > >> The following is a quick run-down of the items from [F], not all > >> being important from

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

2021-01-10 Thread Balint Reczey
Hi Sebastian, On Sun, Apr 12, 2020 at 1:09 AM Sebastian Andrzej Siewior wrote: > > On 2018-03-11 21:51:05 [+0100], Balint Reczey wrote: > > For the recompressed firefox .deb (Ubuntu's > > firefox_58.0.2+build1-0ubuntu0.17.10.1_amd64.deb) increased ~9% in > > size but decompressed in <20% of the

Re: Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

2021-01-10 Thread Stuart Prescott
Sune Stolborg Vuorela wrote: > Can you provide some kind of hook in the environment so we at least can work > around it in the users, so that the internal functions (where the output of > __FILE__ is forwarded to) can glue e.g. the content of an environment > variable in front of the usage of the