Re: [Summary]: Supporting alternative zlib implementations

* Guillem Jover [2024-11-22 12:29]: [...] > * There were concerns (from Fay) about whether given same input the > output changes per arch or hw setup, we'd need to check this; I'd > expect this not to be the case for different arches, but it might > be an issue with number of cores f

Re: [Summary]: Supporting alternative zlib implementations

On Fri, Nov 22, 2024 at 12:29:51PM +0100, Guillem Jover wrote: > [ I'll try to summarize the current discussion and status, what might > be blockers, and a potential incremental way forward. ] You CCed some people but not me so I only saw this today... > On Wed, 2024-09-25 at 10:48:50 +0200, M

Re: [Summary]: Supporting alternative zlib implementations

On Sun, Nov 24, 2024 at 02:06:37AM +0100, Fay Stegerman wrote: > For example, if it can be made easy to install both and choose between zlib > and > zlib-ng at runtime, so it's easy to build APKs using either zlib or zlib-ng as > needed, downstream breakage can be avoided. Considering whether th

Re: [Summary]: Supporting alternative zlib implementations

On 2024-11-25 22:03:32 [+0100], To debian-devel@lists.debian.org wrote: > On 2024-11-24 21:36:25 [+0100], To debian-devel@lists.debian.org wrote: > … > > I've been looking at cdebootstrap. It is one of the failing. This > happens in the rules files: > | ( echo -n "misc:Built-Using="; dpkg-query -

Re: [Summary]: Supporting alternative zlib implementations

On 2024-11-24 21:36:25 [+0100], To debian-devel@lists.debian.org wrote: … I've been looking at cdebootstrap. It is one of the failing. This happens in the rules files: | ( echo -n "misc:Built-Using="; dpkg-query -f='${source:Package} (= | ${source:Version}), ' -W libc6-dev libdebian-installer4-de

Re: [Summary]: Supporting alternative zlib implementations

Le Fri, Nov 22, 2024 at 12:56:17PM +, Simon McVittie a écrit : > Switching from IJG > libjpeg to libjpeg-turbo, both went through similar processes. Independently of the merit of your proposal, this is not historically correct. Cheers, -- Bill.

Re: [Summary]: Supporting alternative zlib implementations

On 2024-11-23 00:05:48 [+0100], To debian-devel@lists.debian.org wrote: > On 2024-11-22 12:29:51 [+0100], Guillem Jover wrote: > > Hi! > Hi, Hi, > > WIP package at . > > just built that. … One thing I didn't debug and it might be expecte

Re: [Summary]: Supporting alternative zlib implementations

* Chris Hofstaedtler [2024-11-23 20:56]: > * Fay Stegerman [241123 19:58]: > > I agree that it *should not* be Debian's responsibility to ensure > > compatibility > > with Fedora/Windows/etc., but the reality is that if "you need the same > > tools to > > generate the same output" -- which righ

Re: [Summary]: Supporting alternative zlib implementations

* Fay Stegerman [241123 19:58]: > I agree that it *should not* be Debian's responsibility to ensure > compatibility > with Fedora/Windows/etc., but the reality is that if "you need the same tools > to > generate the same output" -- which right now means using the same JDK and > Android toolchain

Re: [Summary]: Supporting alternative zlib implementations

* Guillem Jover [2024-11-22 12:29]: [...] > * There were concerns (from Fay) about the output stream changing due > to a potential implementation switch and that affecting external > reproducibility. Personally I think while I can see how this is > annoying for the involved parties,

Re: [Summary]: Supporting alternative zlib implementations

On 2024-11-22 12:29:51 [+0100], Guillem Jover wrote: > Hi! Hi, … > WIP package at . just built that. … > * To consider a switch we'd need to do a mass rebuild of the > archive. Ideally running autopkgtests and similar to exercise th

Re: [Summary]: Supporting alternative zlib implementations

On Fri, 22 Nov 2024 at 12:29:51 +0100, Guillem Jover wrote: > depending on the outcome of this discussion, I think other > (probably better) options would be to perhaps name the compat packages > something like libz-ng-compat*, or drop them completely? You might find the history of the sdl12-compa

[Summary]: Supporting alternative zlib implementations

Hi! [ I'll try to summarize the current discussion and status, what might be blockers, and a potential incremental way forward. ] On Wed, 2024-09-25 at 10:48:50 +0200, Mark Brown wrote: > On Tue, Sep 24, 2024 at 05:45:49PM +0200, Guillem Jover wrote: > > On Tue, 2024-09-24 at 15:58:10 +0200, Ma

Re: Supporting alternative zlib implementations

One minor moment: zlib-ng doesn't seem to be fully backward compatible. E.g. Angie (nginx's fork with enhancements) is unable to perform gzip compression [1] if built against zlib-ng. It's highly likely that nginx is affected too. [1] https://t.me/angie_support/4205 пт, 4 окт. 2024 г. в 03:13, Fa

Re: Supporting alternative zlib implementations

* Sebastian Andrzej Siewior [2024-10-03 22:03]: > On 2024-09-26 01:35:45 [+0200], Fay Stegerman wrote: > > For example, ZIP files or Android APKs built on a Debian system will have a > > different compressed stream, like the test files you mention. Which will > > likely > > break Reproducible Bu

Re: Supporting alternative zlib implementations

On 2024-09-26 01:35:45 [+0200], Fay Stegerman wrote: > For example, ZIP files or Android APKs built on a Debian system will have a > different compressed stream, like the test files you mention. Which will > likely > break Reproducible Builds tooling like apksigcopier [1] and > reproducible-apk-t

Re: Supporting alternative zlib implementations

* Guillem Jover [2024-09-25 01:55]: > Hi! > > On Wed, 2024-09-25 at 00:39:10 +0200, Fay Stegerman wrote: > > * Guillem Jover [2024-09-24 17:45]: > > > Personally, I think fully migrating from zlib to zlib-ng would sound > > > great (even for trixie), but I guess we can take it slow if you do not

Re: Supporting alternative zlib implementations

On Wed, Sep 25, 2024 at 01:55:17AM +0200, Guillem Jover wrote: > The problem though is, that because the compressed stream is going to > change, that can make certain test suites fail if we perform this > switch, which I think would be the main fallout that we'd see from > this and would need manu

Re: Supporting alternative zlib implementations

On Tue, Sep 24, 2024 at 05:45:49PM +0200, Guillem Jover wrote: > On Tue, 2024-09-24 at 15:58:10 +0200, Mark Brown wrote: > > Obviously it's far too late to do anything with the default for trixie, > > we might want to evaluate doing something after the release but for now > > it's too late. > P

Re: Supporting alternative zlib implementations

On Wed, Sep 25, 2024 at 09:36:31AM +0900, Charles Plessy wrote: > Le Tue, Sep 24, 2024 at 03:58:10PM +0200, Mark Brown a écrit : > >zlib-ng: https://github.com/zlib-ng/zlib-ng > Hi Mark, just out of curiosity, would the carbon footprint of Debian be > lower or higher after replacing zlib wit

Re: Supporting alternative zlib implementations

Le Tue, Sep 24, 2024 at 03:58:10PM +0200, Mark Brown a écrit : > >zlib-ng: https://github.com/zlib-ng/zlib-ng Hi Mark, just out of curiosity, would the carbon footprint of Debian be lower or higher after replacing zlib with zlib-ng? Have a nice day, Charles -- Charles Plessy

Re: Supporting alternative zlib implementations

On Wed, Sep 25, 2024 at 01:55:17AM +0200, Guillem Jover wrote: > Hi! > > On Wed, 2024-09-25 at 00:39:10 +0200, Fay Stegerman wrote: > > * Guillem Jover [2024-09-24 17:45]: > > > Personally, I think fully migrating from zlib to zlib-ng would sound > > > great (even for trixie), but I guess we can

Re: Supporting alternative zlib implementations

Hi! On Wed, 2024-09-25 at 00:39:10 +0200, Fay Stegerman wrote: > * Guillem Jover [2024-09-24 17:45]: > > Personally, I think fully migrating from zlib to zlib-ng would sound > > great (even for trixie), but I guess we can take it slow if you do not > > feel confident or have concerns over this. >

Re: Supporting alternative zlib implementations

* Guillem Jover [2024-09-24 17:45]: [...] > Personally, I think fully migrating from zlib to zlib-ng would sound > great (even for trixie), but I guess we can take it slow if you do not > feel confident or have concerns over this. As using an alternative zlib implementation could impact Reproduci

Re: Supporting alternative zlib implementations

Hi! On Tue, 2024-09-24 at 15:58:10 +0200, Mark Brown wrote: > In the past I've pushed back on doing anything here since zlib is > essential and it seemed better to be consistent over the ecosystem than > to use a more niche implementation, and some of the early optimisation > efforts had not worke

Supporting alternative zlib implementations

A recurrning question with the zlib package in Debian is interest in the various alternative zlib implementations that are out there. There was a long period where upstream zlib development seemed very stalled, during that period people who wanted improvements started forking their own projects.