Obsoleting zlib in Fedora Rawhide

[Tulio Magno Quites Machado Filho]

Following the recent approval from Fesco, I'm planning to distribute
zlib-ng-compat packages for Rawhide later this week. 
I hope this will give us enough time to work on the issues before
Fedora 40 is released. 🤞

So, keep in mind this will *obsolete zlib in Rawhide*.

This update is also known to trigger test failures in the following
packages:

 - binutils
 - cpp-httplib
 - git
 - jose
 - libpng
 - openexr1
 - openms
 - python-3.12
 - qpdf

In general, the failing tests expect that libz will always have the same
behavior, e.g.
 - same output length
 - identical output
 - same version string format

This will require changes in order to guarantee the tests do succeed.

If you have any questions or need help with these issues, let me know.

-- 
Tulio Magno

[Tulio Magno Quites Machado Filho]

Re-sending to binutils, openexr and python3.12 maintainers.
Sorry, I messed up your email aliases in my first message.

-- 
Tulio Magno


Tulio Magno Quites Machado Filho <tuliom(a)ascii.art.br&gt; writes:

>  Following the recent approval from Fesco, I'm planning to
> distribute
>  zlib-ng-compat packages for Rawhide later this week. 
>  I hope this will give us enough time to work on the issues before
>  Fedora 40 is released. 🤞
>
>  So, keep in mind this will *obsolete zlib in Rawhide*.
>
>  This update is also known to trigger test failures in the following
>  packages:
>
>   - binutils
>   - cpp-httplib
>   - git
>   - jose
>   - libpng
>   - openexr
>   - openms
>   - python3.12
>   - qpdf
>
>  In general, the failing tests expect that libz will always have the same
>  behavior, e.g.
>   - same output length
>   - identical output
>   - same version string format
>
>  This will require changes in order to guarantee the tests do succeed.
>
>  If you have any questions or need help with these issues, let me know.
>
>  -- 
>  Tulio Magno
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Lukas Javorsky]

Also the `minizip-compat` subpackage will be removed as it's part of the
zlib.

There are only two packages that couldn't build with the minizip-ng-compat:
chromium
libdigidocpp

Than, please switch chromium to bundled minizip as we agreed in BZ#2242271.

The change for Minizip is here:
https://fedoraproject.org/wiki/Changes/MinizipNGTransition

On Mon, Dec 4, 2023 at 9:38 PM Tulio Magno Quites Machado Filho <
tuliom(a)ascii.art.br&gt; wrote:

>  Re-sending to binutils, openexr and python3.12 maintainers.
>  Sorry, I messed up your email aliases in my first message.
>
>  --
>  Tulio Magno
>
>
>  Tulio Magno Quites Machado Filho <tuliom(a)ascii.art.br&gt; writes:
>
>  > Following the recent approval from Fesco, I'm planning to distribute
>  > zlib-ng-compat packages for Rawhide later this week.
>  > I hope this will give us enough time to work on the issues before
>  > Fedora 40 is released. 🤞
>  >
>  > So, keep in mind this will *obsolete zlib in Rawhide*.
>  >
>  > This update is also known to trigger test failures in the following
>  > packages:
>  >
>  >  - binutils
>  >  - cpp-httplib
>  >  - git
>  >  - jose
>  >  - libpng
>  >  - openexr
>  >  - openms
>  >  - python3.12
>  >  - qpdf
>  >
>  > In general, the failing tests expect that libz will always have the same
>  > behavior, e.g.
>  >  - same output length
>  >  - identical output
>  >  - same version string format
>  >
>  > This will require changes in order to guarantee the tests do succeed.
>  >
>  > If you have any questions or need help with these issues, let me know.
>  >
>  > --
>  > Tulio Magno
>  > --
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  > Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat <https://www.redhat.com>

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavorsk(a)redhat.com
<https://www.redhat.com>

[Miro Hrončok]

On 04. 12. 23 20:10, Tulio Magno Quites Machado Filho wrote:
>  Following the recent approval from Fesco, I'm planning to
> distribute
>  zlib-ng-compat packages for Rawhide later this week.
>  I hope this will give us enough time to work on the issues before
>  Fedora 40 is released. 🤞
>  
>  So, keep in mind this will *obsolete zlib in Rawhide*.
>  
>  This update is also known to trigger test failures in the following
>  packages:
>  
>    - python-3.12 
Hello.

Do you happen to have a build.log available for this?

It's only python3.12 that fails and not the others?

>  
>  In general, the failing tests expect that libz will always have the same
>  behavior, e.g.
>    - same output length
>    - identical output
>    - same version string format
>  
>  This will require changes in order to guarantee the tests do succeed.
>  
>  If you have any questions or need help with these issues, let me know.
>   
-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Tulio Magno Quites Machado Filho]

Miro Hrončok <mhroncok(a)redhat.com&gt; writes:

>  Do you happen to have a build.log available for this? 
I re-run the tests for all architectures here:
https://copr.fedorainfracloud.org/coprs/tuliom/zlib-ng-compat-mpb/build/6...

Keep in mind that zlib-ng defines the following:
#define ZLIB_VERSION "1.3.0.zlib-ng"

Source upstream: https://github.com/zlib-ng/zlib-ng/blob/develop/zlib.h.in#L61

>  It's only python3.12 that fails and not the others? 
I tested previous versions too, but I didn't analyse their results.
I can re-run them if you believe this is important.
Likewise for python3.13, which was not available when I started this test.

-- 
Tulio Magno

[Miro Hrončok]

On 05. 12. 23 19:21, Tulio Magno Quites Machado Filho wrote:
>  Miro Hrončok <mhroncok(a)redhat.com&gt; writes:
>  
> > Do you happen to have a build.log available for this?
>  
>  I re-run the tests for all architectures here:
>  https://copr.fedorainfracloud.org/coprs/tuliom/zlib-ng-compat-mpb/build/6...
>  
>  Keep in mind that zlib-ng defines the following:
>  #define ZLIB_VERSION "1.3.0.zlib-ng"
>  
>  Source upstream: https://github.com/zlib-ng/zlib-ng/blob/develop/zlib.h.in#L61 
Oh, thanks!

Here is my upstream PR to fix this:

https://github.com/python/cpython/pull/112771

> > It's only python3.12 that fails and not the others?
>  
>  I tested previous versions too, but I didn't analyse their results.
>  I can re-run them if you believe this is important.
>  Likewise for python3.13, which was not available when I started this test. 
No need. They will all fail as well.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Yaakov Selkowitz]

On Mon, 2023-12-04 at 16:10 -0300, Tulio Magno Quites Machado Filho
wrote:
>  Following the recent approval from Fesco, I'm planning to
> distribute
>  zlib-ng-compat packages for Rawhide later this week. 
>  I hope this will give us enough time to work on the issues before
>  Fedora 40 is released. 🤞
>  
>  So, keep in mind this will *obsolete zlib in Rawhide*.
>  
>  This update is also known to trigger test failures in the following
>  packages:
>  
>   - binutils
>   - cpp-httplib
>   - git
>   - jose
>   - libpng
>   - openexr1
>   - openms
>   - python-3.12
>   - qpdf
>  
>  In general, the failing tests expect that libz will always have the
>  same
>  behavior, e.g.
>   - same output length
>   - identical output
>   - same version string format
>  
>  This will require changes in order to guarantee the tests do succeed.
>  
>  If you have any questions or need help with these issues, let me
>  know. 
I would expect these build/test issues to be fixed *BEFORE* the
obsoletion takes place, through COPR test builds and PRs etc.  Please
tell me that FESCo didn't give permissions to break such key packages?

Also, since this is essentially an SONAME change wrt zlib, the initial
build and mini-mass-rebuild of all dependents should occur in a side-
tag.  You're announcement doesn't mention this occurring.

-- 
Yaakov Selkowitz
Principal Software Engineer - Emerging RHEL
Red Hat, Inc.

[Stephen Gallagher]

On Tue, Dec 5, 2023 at 1:28 PM Yaakov Selkowitz <yselkowi(a)redhat.com&gt; wrote:
>  On Mon, 2023-12-04 at 16:10 -0300, Tulio Magno Quites Machado Filho
>  wrote:
>  > Following the recent approval from Fesco, I'm planning to distribute
>  > zlib-ng-compat packages for Rawhide later this week.
>  > I hope this will give us enough time to work on the issues before
>  > Fedora 40 is released. 🤞
>  >
>  > So, keep in mind this will *obsolete zlib in Rawhide*.
>  >
>  > This update is also known to trigger test failures in the following
>  > packages:
>  >
>  >  - binutils
>  >  - cpp-httplib
>  >  - git
>  >  - jose
>  >  - libpng
>  >  - openexr1
>  >  - openms
>  >  - python-3.12
>  >  - qpdf
>  >
>  > In general, the failing tests expect that libz will always have the
>  > same
>  > behavior, e.g.
>  >  - same output length
>  >  - identical output
>  >  - same version string format
>  >
>  > This will require changes in order to guarantee the tests do succeed.
>  >
>  > If you have any questions or need help with these issues, let me
>  > know.
>
>  I would expect these build/test issues to be fixed *BEFORE* the
>  obsoletion takes place, through COPR test builds and PRs etc.  Please
>  tell me that FESCo didn't give permissions to break such key packages?
>
>  Also, since this is essentially an SONAME change wrt zlib, the initial
>  build and mini-mass-rebuild of all dependents should occur in a side-
>  tag.  You're announcement doesn't mention this occurring.
>  
*Puts on FESCo Hat*
Yaakov is exactly right here; this all MUST be worked out in a side
tag before it lands in Rawhide.

[Tulio Magno Quites Machado Filho]

Yaakov Selkowitz <yselkowi(a)redhat.com&gt; writes:

>  Also, since this is essentially an SONAME change wrt zlib, the
> initial
>  build and mini-mass-rebuild of all dependents should occur in a side-
>  tag.  You're announcement doesn't mention this occurring. 
There are no SONAME changes.

With zlib we have:

$ rpm -qf /usr/lib64/libz.so.1
zlib-1.2.13-5.fc40.x86_64
$ readelf -a /usr/lib64/libz.so.1.2.13 | grep -i soname
 0x000000000000000e (SONAME)             Library soname: [libz.so.1]

With zlib-ng-compat we have:

$ rpm -qf /usr/lib64/libz.so.1
zlib-ng-compat-2.1.3-7.fc40.x86_64
$ readelf -a /usr/lib64/libz.so.1  | grep soname
 0x000000000000000e (SONAME)             Library soname: [libz.so.1]

No mass rebuilds are required. zlib-ng in compat mode aims to be API and
ABI compatible with zlib.

-- 
Tulio Magno

[Yaakov Selkowitz]

On Tue, 2023-12-05 at 16:34 -0300, Tulio Magno Quites Machado Filho
wrote:
>  Yaakov Selkowitz <yselkowi(a)redhat.com&gt; writes:
>  
>  > Also, since this is essentially an SONAME change wrt zlib, the
>  > initial
>  > build and mini-mass-rebuild of all dependents should occur in a
>  > side-
>  > tag.  You're announcement doesn't mention this occurring.
>  
>  There are no SONAME changes. 
Perhaps technically not, but...

>  With zlib we have:
>  
>  $ rpm -qf /usr/lib64/libz.so.1
>  zlib-1.2.13-5.fc40.x86_64
>  $ readelf -a /usr/lib64/libz.so.1.2.13 | grep -i soname
>   0x000000000000000e (SONAME)             Library soname: [libz.so.1]
>  
>  With zlib-ng-compat we have:
>  
>  $ rpm -qf /usr/lib64/libz.so.1
>  zlib-ng-compat-2.1.3-7.fc40.x86_64
>  $ readelf -a /usr/lib64/libz.so.1  | grep soname
>   0x000000000000000e (SONAME)             Library soname: [libz.so.1]
>  
>  No mass rebuilds are required. zlib-ng in compat mode aims to be API
>  and
>  ABI compatible with zlib. 
Except that it's not 100% compatible, since all those packages aren't
building/working with zlib-ng-compat.  At a minimum, you should be able
to show that everything zlib-dependent successfully rebuilds with this,
and since you've already identified some that don't, IMO they should be
fixed *first*.

-- 
Yaakov Selkowitz
Principal Software Engineer - Emerging RHEL
Red Hat, Inc.

[Miro Hrončok]

On 06. 12. 23 0:09, Yaakov Selkowitz wrote:
>  Except that it's not 100% compatible, since all those packages
> aren't
>  building/working with zlib-ng-compat.  At a minimum, you should be able
>  to show that everything zlib-dependent successfully rebuilds with this,
>  and since you've already identified some that don't, IMO they should be
>  fixed*first*. 
I agree in principle.

However, this is not a way we treat other updates/changes in Fedora.

Every year, we let a new GCC version be tossed into rawhide and we deal with 
possibly hundreds of FTBFS packages later.

Every week, we let maintainers update their packages while breaking runtime 
dependencies and we deal with the breakages later.

This zlib thing seems like a minor thing compared to the two above.

(And it certainly does not need a side tag and a mini mass rebuild.)

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Tulio Magno Quites Machado Filho]

Yaakov Selkowitz <yselkowi(a)redhat.com&gt; writes:

>  Except that it's not 100% compatible, since all those packages
> aren't
>  building/working with zlib-ng-compat.  At a minimum, you should be able
>  to show that everything zlib-dependent successfully rebuilds with this, 
I'm afraid I was not clear enough.
Packages built with zlib continue to work after replacing zlib with
zlib-ng-compat.

However, a small list of packages have tests that were written without
considering that one day we would have many different implementations of
zlib.
These tests need to be modified. In some cases, I believe they should be
disabled as they aim to test the zlib implementation instead of testing
their own code.

With that said, I haven't identified a compatibility issue with zlib-ng
yet. If you have, please let me know.

-- 
Tulio Magno

[Daniel Alley]

>  Except that it's not 100% compatible, since all those packages
> aren't
>  building/working with zlib-ng-compat.  At a minimum, you should be able
>  to show that everything zlib-dependent successfully rebuilds with this,
>  and since you've already identified some that don't, IMO they should be
>  fixed *first*. 
He didn't say the packages weren't working, he said the tests failed, typically
because they hardcoded assumptions about the exact behavior of the compression library. 
That's a different issue.

As a concrete example, a while back I wanted to add zlib-ng as a build time option to the
createrepo_c package, and one such test failed because the zlib-ng gzip output was not
identical to zlib gzip output, despite the fact that it *was* correct and decompresses
correctly:
https://github.com/rpm-software-management/createrepo_c/pull/339/commits/...

It so happened that within days there was another reporter who needed the same fix but for
different reasons - because that test was broken on z390 where gzip compression is
hardware-accelerated: https://github.com/rpm-software-management/createrepo_c/pull/336

So any tests that are breaking because they expected some exact gzipped output as opposed,
were likely fragile anyway, and worked only because zlib has changed very little for a
very long time - no new compression strategies, no adjustment of which strategies are used
by which levels, etc.

[Tulio Magno Quites Machado Filho]

Tulio Magno Quites Machado Filho <tuliom(a)ascii.art.br&gt; writes:

>  Following the recent approval from Fesco, I'm planning to
> distribute
>  zlib-ng-compat packages for Rawhide later this week. 
>  I hope this will give us enough time to work on the issues before
>  Fedora 40 is released. 🤞
>
>  So, keep in mind this will *obsolete zlib in Rawhide*.
>
>  This update is also known to trigger test failures in the following
>  packages:
>
>   - binutils
>   - cpp-httplib
>   - git
>   - jose
>   - libpng
>   - openexr1
>   - openms
>   - python-3.12
>   - qpdf 
With the help from upstream and downstream, all these packages already
have a solution available.
Some had fixes upstream and a few of them had changes applied only downstream.

With that said, I'm finally moving forward with the zlib-ng rebuilt that
will obsolete zlib.

Again, if you have any questions or find any issues, let me know.

Thanks to all maintainers upstream and downstream that helped with this!

-- 
Tulio Magno

[Daniel P. Berrangé]

On Mon, Dec 04, 2023 at 04:10:18PM -0300, Tulio Magno Quites Machado Filho wrote:
>  Following the recent approval from Fesco, I'm planning to
> distribute
>  zlib-ng-compat packages for Rawhide later this week. 
>  I hope this will give us enough time to work on the issues before
>  Fedora 40 is released. 🤞
>  
>  So, keep in mind this will *obsolete zlib in Rawhide*. 
snip

>  If you have any questions or need help with these issues, let me
> know. 
I've just tried to build latest QEMU in rawhide. We have

  BuildRequires: zlib-devel
  BuildRequires: zlib-ng-static

and when building koji fails to install the build root deps

DEBUG util.py:446:  Error: 
DEBUG util.py:446:   Problem: problem with installed package
zlib-ng-compat-2.1.5-1.fc40.x86_64
DEBUG util.py:446:    - package zlib-ng-compat-2.1.5-1.fc40.x86_64 from @System conflicts
with zlib(x86-64) provided by zlib-1.2.13-5.fc40.x86_64 from build
DEBUG util.py:446:    - installed package zlib-ng-compat-2.1.5-1.fc40.x86_64 obsoletes
zlib < 1.3 provided by zlib-1.2.13-5.fc40.x86_64 from build
DEBUG util.py:446:    - package zlib-ng-compat-2.1.5-1.fc40.x86_64 from build conflicts
with zlib(x86-64) provided by zlib-1.2.13-5.fc40.x86_64 from build
DEBUG util.py:446:    - package zlib-ng-compat-2.1.5-1.fc40.x86_64 from build obsoletes
zlib < 1.3 provided by zlib-1.2.13-5.fc40.x86_64 from build
DEBUG util.py:446:    - package zlib-devel-1.2.13-5.fc40.x86_64 from build requires
zlib(x86-64) = 1.2.13-5.fc40, but none of the providers can be installed
DEBUG util.py:446:    - package zlib-static-1.2.13-5.fc40.x86_64 from build requires
zlib-devel(x86-64) = 1.2.13-5.fc40, but none of the providers can be installed
DEBUG util.py:446:    - conflicting requests
DEBUG util.py:448:  (try to add '--allowerasing' to command line to replace
conflicting packages or '--skip-broken' to skip uninstallable packages)

It appears that the zlib-ng replacement is not providing a
zlib-static replacement. So rpm ends up trying to install
bot zlib (for zlib-static) and zlib-ng (for zlib-devel) and
this all fails.

AFAICT, this will only work if zlib-ng provides a -static
package.

We can't build QEMU without zlib static, as it is a mandatory
dependancy of the QEMU userspace emulators which are static
linked in order to work as linux binary translators in chroots.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Yaakov Selkowitz]

On Tue, 2024-01-09 at 18:53 +0000, Daniel P. Berrangé wrote:
>  On Mon, Dec 04, 2023 at 04:10:18PM -0300, Tulio Magno Quites Machado
>  Filho wrote:
>  > Following the recent approval from Fesco, I'm planning to
>  > distribute
>  > zlib-ng-compat packages for Rawhide later this week. 
>  > I hope this will give us enough time to work on the issues before
>  > Fedora 40 is released. 🤞
>  > 
>  > So, keep in mind this will *obsolete zlib in Rawhide*.
>  
>  snip
>  
>  > If you have any questions or need help with these issues, let me
>  > know.
>  
>  I've just tried to build latest QEMU in rawhide. We have
>  
>    BuildRequires: zlib-devel
>    BuildRequires: zlib-ng-static
>  
>  and when building koji fails to install the build root deps
>  
>  DEBUG util.py:446:  Error: 
>  DEBUG util.py:446:   Problem: problem with installed package zlib-ng-
>  compat-2.1.5-1.fc40.x86_64
>  DEBUG util.py:446:    - package zlib-ng-compat-2.1.5-1.fc40.x86_64
>  from @System conflicts with zlib(x86-64) provided by zlib-1.2.13-
>  5.fc40.x86_64 from build
>  DEBUG util.py:446:    - installed package zlib-ng-compat-2.1.5-
>  1.fc40.x86_64 obsoletes zlib < 1.3 provided by zlib-1.2.13-
>  5.fc40.x86_64 from build
>  DEBUG util.py:446:    - package zlib-ng-compat-2.1.5-1.fc40.x86_64
>  from build conflicts with zlib(x86-64) provided by zlib-1.2.13-
>  5.fc40.x86_64 from build
>  DEBUG util.py:446:    - package zlib-ng-compat-2.1.5-1.fc40.x86_64
>  from build obsoletes zlib < 1.3 provided by zlib-1.2.13-5.fc40.x86_64
>  from build
>  DEBUG util.py:446:    - package zlib-devel-1.2.13-5.fc40.x86_64 from
>  build requires zlib(x86-64) = 1.2.13-5.fc40, but none of the
>  providers can be installed
>  DEBUG util.py:446:    - package zlib-static-1.2.13-5.fc40.x86_64 from
>  build requires zlib-devel(x86-64) = 1.2.13-5.fc40, but none of the
>  providers can be installed
>  DEBUG util.py:446:    - conflicting requests
>  DEBUG util.py:448:  (try to add '--allowerasing' to command line to
>  replace conflicting packages or '--skip-broken' to skip uninstallable
>  packages)
>  
>  It appears that the zlib-ng replacement is not providing a
>  zlib-static replacement. So rpm ends up trying to install
>  bot zlib (for zlib-static) and zlib-ng (for zlib-devel) and
>  this all fails.
>  
>  AFAICT, this will only work if zlib-ng provides a -static
>  package.
>  
>  We can't build QEMU without zlib static, as it is a mandatory
>  dependancy of the QEMU userspace emulators which are static
>  linked in order to work as linux binary translators in chroots. 
Please try with
https://src.fedoraproject.org/rpms/zlib-ng/pull-request/8

-- 
Yaakov Selkowitz
Principal Software Engineer - Emerging RHEL
Red Hat, Inc.