rpms / python3.12

Clone
Source Code
GIT

#63 Use bundled libb2 in RHEL builds
Merged 2 years ago by churchyard. Opened 2 years ago by yselkowitz.
rpms/ yselkowitz/python3.12 rawhide  into  rawhide

file modified
+13 -2 
@@ -17,7 +17,7 @@ 
 

  #global prerel ...
 

  %global upstream_version %{general_version}%{?prerel}
 

  Version: %{general_version}%{?prerel:~%{prerel}}
 

- Release: 1%{?dist}
 

+ Release: 2%{?dist}
 

  License: Python-2.0.1
 

  

  
@@ -255,7 +255,9 @@ 
 

  BuildRequires: gmp-devel
 

  BuildRequires: gnupg2
 

  BuildRequires: libappstream-glib
 

+ %if %{undefined rhel}
 

  BuildRequires: libb2-devel
 

+ %endif
 

  BuildRequires: libffi-devel
 

  BuildRequires: libnsl2-devel
 

  BuildRequires: libtirpc-devel
 
@@ -484,15 +486,21 @@ 
 

  

  %if %{with rpmwheels}
 

  Requires: %{python_wheel_pkg_prefix}-pip-wheel >= 23.1.2
 

+ # Bundled libb2 is CC0, covered by grandfathering exception
 

+ License: Python-2.0.1 AND CC0-1.0
 

  %else
 

  Provides: bundled(python3dist(pip)) = %{pip_version}
 

  %pip_bundled_provides
 

  # License manually combined form Python + pip
 

- License: Python-2.0.1 AND MIT AND Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND ISC AND LGPL-2.1-only AND MPL-2.0 AND (Apache-2.0 OR BSD-2-Clause)
 

+ License: Python-2.0.1 AND CC0-1.0 AND MIT AND Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND ISC AND LGPL-2.1-only AND MPL-2.0 AND (Apache-2.0 OR BSD-2-Clause)
 

  %endif
 

  

  %unversioned_obsoletes_of_python3_X_if_main libs
 

  

+ # Bundled internal headers are used even when building with system libb2
 

+ # last updated by https://github.com/python/cpython/pull/6286
 

+ Provides: bundled(libb2) = 0.98.1
 

+ 

  # There are files in the standard library that have python shebang.
 

  # We've filtered the automatic requirement out so libs are installable without
 

  # the main package. This however makes it pulled in by default.
 
@@ -1658,6 +1666,9 @@ 
 

  # ======================================================
 

  

  %changelog
 

+ * Thu Oct 05 2023 Yaakov Selkowitz <yselkowi@redhat.com> - 3.12.0-2
 

+ - Use bundled libb2 in RHEL builds
 

+ 

  * Mon Oct 02 2023 Miro Hrončok <mhroncok@redhat.com> - 3.12.0-1
 

  - Update to 3.12.0 final

Standalone libb2 is unwanted in RHEL.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/2f99e6aa74074ef7bd167e38ba677163

Is this https://github.com/python/cpython/tree/main/Modules/_blake2/impl ?

If so, I have a couple of questions:

Isn't the bundled libb2 used even in Fedora...

I've opened https://src.fedoraproject.org/rpms/python3.12/pull-request/64 to know.

Should this be reflected in the License tag as CC0-1.0 (which is no longer allowed for code in Fedora)?

I've asked on the legal list, but my message has not yet reached the archives.

Standalone libb2 is unwanted in RHEL.

https://tiny.distro.builders/view-srpm--view-eln--libb2.html does not indicate that. I also cannot find libb2 in https://github.com/minimization/content-resolver-input

Should this be reflected in the License tag as CC0-1.0 (which is no longer allowed for code in Fedora)?

I've asked on the legal list, but my message has not yet reached the archives.

https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/WFW3FFCBDHDBSHBPD4EQZDX7TMVRTZDA/

Should this be reflected in the License tag as CC0-1.0 (which is no longer allowed for code in Fedora)?

I've asked on the legal list, but my message has not yet reached the archives.

https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/WFW3FFCBDHDBSHBPD4EQZDX7TMVRTZDA/

"""
I'd treat this as CC0-1.0 (I don't think that is altered by the form
of license notice on individual source files). Presumably it's covered
by the grandfathering exception
https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/data/CC0-1.0.toml?ref_type=heads#L11-14
"""

Is this https://github.com/python/cpython/tree/main/Modules/_blake2/impl ?

Yes.

If so, I have a couple of questions:

  • Should the bundled() Provides be in the libs subpackage?

That seems overly pedantic, and would make it less obvious that this is a tradeoff situation.

Thanks for the links; added.

  • Isn't the bundled libb2 used even in Fedora, for /usr/lib64/python3.12/lib-dynload/_blake2.cpython-312-*so? If so, the bundled provides should probably not be conditionalized.

Why do you think that? When libb2-devel is present at runtime, _blake2 just binds it:

$ ldd /usr/lib64/python3.12/lib-dynload/_blake2.cpython-312-x86_64-linux-gnu.so         linux-vdso.so.1 (0x00007fffc9790000)
    libb2.so.1 => /lib64/libb2.so.1 (0x00007f8716f51000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f8716d73000)
    libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f8716d21000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8716cfd000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8716f74000)

Also, the ELN _blake2...so is larger than Fedora's.

  • Should this be reflected in the License tag as CC0-1.0 (which is no longer allowed for code in Fedora)?

Added with comment.

rebased onto eb1378253d6a01acae9378b10a2380bdedfce057
2 years ago

Why do you think that?

Becasue when I delete the bundled library, it no longer builds.

But perhaps that is just a problem with unused Makefile-level dependencies.

What is the motivation for doing this in the first place? I still don't see libb2 marked as unwanted. As we will likely be the ones who will maintain it, shouldn't this be our call? (I am not saying whether we want to do it or not, I am merely confused that this has been decided without us.)

Anyway, when the bundled libb2 isn't used, the license should not have CC0-1.0 in it. That way, we need to conditionalize at at least two places so perhaps it might be better to use a bcond rather than if rhel here and there in the spec.

I can take this as an opportunity to convert the spec file to the new bcond syntax if you don't want to deal with that.

That seems overly pedantic, and would make it less obvious that this is a tradeoff situation.

The different License string will make it less obvious anyway, but the bcond should make that more clear.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/76f5e0b3c1f2442bb5502d85c67c41fc

Anyway, when the bundled libb2 isn't used, the license should not have CC0-1.0 in it. That way, we need to conditionalize at at least two places so perhaps it might be better to use a bcond rather than if rhel here and there in the spec.

Per discussion in #64 it turns out one of the bundled internal headers are used even with the system libb2, so CC0-1.0 should be unconditional.

I can take this as an opportunity to convert the spec file to the new bcond syntax if you don't want to deal with that.

I'll leave that to you.

That seems overly pedantic, and would make it less obvious that this is a tradeoff situation.

The different License string will make it less obvious anyway, but the bcond should make that more clear.

Per the above, the License addition should be unconditional, so that leaves only one condition unless we add the (modified) #64 .

rebased onto c01aa4c3dfdd2d57b783ad12c5423d5b70c54502
2 years ago

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/6e9de6eda6f746cb87c2b3e645ba53dc

The diff looks good now, thanks.

I discussed this with my team. We would like to know the answer to:

What is the motivation for doing this in the first place? I still don't see libb2 marked as unwanted.

rebased onto 72ae4d30a61403e246e31352bd0c094524048aee
2 years ago

It has been decided that we do not want to support libb2 as a standalone library in RHEL.

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/971ba674fe6741bb8c4c20453781cafb

It has been decided that we do not want to support libb2 as a standalone library in RHEL.

Who decided that and why? If you cannot disclose this information publicly, feel free to send an internal email to python-maint@redhat.com. If you can disclose that information, please track it in the content resolver input, so we can link it in the commit message and/or spec file comment.

Hello,
RHEL does some complicated stuff with the crypto libs; will need rather big changes in this area later.
We'd like to keep most of these changes out of Fedora, but it would help a lot if this one -- removal of the libb2 dependency -- was in ELN now, to help with the dependency analysis. Is that reason OK?

BTW, the licence change and Provides: bundled might be good, as this stuff can leak into the build.

Is that reason OK?

I guess it is, but I still don't understand why libb2 is unwanted yet not marked as unwanted in https://tiny.distro.builders/view-rpm--view-eln--libb2.html -- if it was marked as unwanted in ELN, we would have the reason.

rebased onto 1fc39f600c78bdb22e6b214fd8f8e6db2c685be5
2 years ago

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/fdcec486257e4c5fa72b13dd01846404

Well, to me it seems that Python maintainers aren't the right team to "own" libb2's unwanted-ness. If someone else gets it into ELN (and though the crypto compliance hoops), we could use it.

But I don't know how to encode that in YAMLs and specs.

Exactly, that's why I am reluctant to go and mark libb2 as unwanted myself -- instead I asked who decided it is unwanted and I want them to do it. Unfortunately, my question remains unanswered for a while now.

rebased onto 261b6e4
2 years ago

Can this be merged so that I don't have to keep rebasing it?

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/3a2ed31309224482b15a1bea6dc60578

There was no reason to keep rebasing this until the question was answered which only happened less than 2 days ago. I waited a month to get the answer, so I don't really appreciate your pressure to get this merged now.

Yes, this will be merged, but I want to skim over the diff once more, and I simply haven't got to it yet.

(Apparently, we do not want libb2 in RHEL because blake2 hashes are available in libgcrypt and openssl. Instead, we will use a bundled libb2. Honestly, that does not really make sense to me at all, but I give up.)

Pull-Request has been merged by churchyard
2 years ago

Building python3.12-3.12.0-2.fc40 for rawhide
Created task: 107089323
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=107089323

(To avoid only building it in ELN and have builds with different commit hashes.)
Metadata
None
No Tags
Changes Summary 1
+13 -2
file changed
python3.12.spec
Powered by Pagure 5.14.1
Documentation • File an Issue • About this Instance • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.