[EPEL-devel] Re: Incompatible update of llhttp from 9.1.3 to 9.2.1 in EPEL9

I have pushed this update to stable. On 4/11/24 8:18 PM, Ben Beasley wrote: I have just submitted for testing https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-ce142428af, which updates llhttp in EPEL9 from 9.1.3 to 9.2.1 and fixes CVE-2024-27982[1], an HTTP request smuggling

Re: LLVM Packaging Ideas for Fedora 41

Similarly, python-llvmlite requires llvm14, and the upcoming upstream release will require llvm15 (with a medium-term plan to get to llvm17). For complex projects that are tightly coupled to the LLVM implementation like this, there is generally *absolutely nothing* that downstream packagers

Heads-up: rapidyaml 0.6.0 and c4core 0.2.0 coming to Rawhide

In one week (2024-05-06), or slightly later, I plan to update the rapidyaml package to 0.6.0[1] and the c4core package to 0.2.0[2] in F41/Rawhide. This includes an SONAME version bump in both cases, with specific breaking changes documented in the upstream release notes[3][4]. An impact check

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

, further details follow below. – Ben Beasley (FAS music) I double-checked the packages that were in your original list but not in the output of "fedrq wrsrc -s openexr":     - The CTL package BuildRequires the compat package openexr2 instead, so it did not need to

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

8:13 AM, Ben Beasley wrote: I rebuilt openvdb. I am finding that the dependency chains in this set of packages are even longer than I expected. Considering that, and how “heavy” some of these packages are – and in the interest of not keeping this side tag open for too long – I am going to go

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

provenpackager privilege to carefully work through the packages that can be rebuilt with a simple release bump. (Hopefully that means all of them!) On 4/23/24 7:21 PM, Ben Beasley wrote: I get a slightly larger list with fedrq: $ fedrq wrsrc -s openexr -F name CImg Field3D ImageMagick OpenColorIO

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

advocate for delaying it by at least one week. Thanks, Ben Beasley (FAS music) On 4/22/24 8:14 AM, Josef Řídký wrote: Hi folks, this is in advance notice about the upcoming rebase of the openexr package in Fedora Rawhide and f40. List

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

You can use: https://koji.fedoraproject.org/koji/builds?order=-tag_name=88169=1=1 So far it looks like we have openexr, gegl04, and jpegxl. On 4/23/24 7:13 AM, Tomas Smetana wrote: Dne Mon, 22 Apr 2024 19:02:07 + Gwyn Ciesla via devel napsal(a): I tried to so synfig and

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

now, it will have very messy interactions with other updates in other side tags, e.g. https://bodhi.fedoraproject.org/updates/FEDORA-2024-45862e3ed9 for blender. Even if this update is truly required in F40, I would advocate for delaying it by at least one week. Thanks, Ben Beasley (FAS music

[EPEL-devel] Incompatible update of llhttp from 9.1.3 to 9.2.1 in EPEL9

I have just submitted for testing https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-ce142428af, which updates llhttp in EPEL9 from 9.1.3 to 9.2.1 and fixes CVE-2024-27982[1], an HTTP request smuggling vulnerability. Version 9.2.0 also included a number of bug fixes[2]. This is an

Re: Rust Stack Spring Cleaning - 2024 Edition

The rust-circular-buffer crate was packaged as a dependency for bpftop, https://github.com/Netflix/bpftop. I won’t necessarily be packaging bpftop myself, but I know several parties are interested in doing so, and I expect it will happen soon one way or the other. A few existing

Re: Idea: pynose as drop-in replacement for nose

For a proposed nose successor, pynose doesn’t seem to have gained much community traction so far: it has seven stars on GitHub[1] (compared to 770 for nose2, which itself was never that widely adopted and has fewer than ten dependent packages in Fedora); and the imperfect but fairly useful

Heads-up: python-typer 0.12.1 coming to Rawhide with a significant reorganization

In 0.12.1, Typer was significantly reorganized. - `typer-slim` is the library (for `import typer`) - `typer-slim[standard]` adds optional dependencies (currently `rich` and `shellingham`, basically equivalent to the old `typer[all]`) - `typer-cli` is the `typer` command-line tool - `typer` is

Orphaning vim-editorconfig

I’m orphaning vim-editorconfig. While it’s probably still useful in EPEL8 and EPEL9, it is (according to https://github.com/editorconfig/editorconfig-vim/issues/234) no longer needed by users of recent versions of vim and neovim since those editors now include its functionality. It’s

Re: Three steps we could take to make supply chain attacks a bit harder

On 3/31/24 2:12 PM, Kevin Kofler via devel wrote: But the fact is: What WOULD have stopped this attack: (one or more of:) * Deleting ALL unit tests in %prep (and then of course not trying to run them later). While it’s technically correct that deleting tests would have disrupted this specific

Orphaning python-jose because it is unmaintained upstream

For some time, I have been maintaining python-jose[1] since it is a minor test dependency for python-fastapi. While the Fedora package for python-jose is in good condition, the project has been unmaintained upstream for some time[2][3]. I have just chosen to skip the FastAPI tests that

Heads-up: Updating python-keyring to 25.0.0 in F41/Rawhide

In one week (2024-04-04), or slightly later, I plan to update the python-keyring package to 25.0.0 in F41/Rawhide[1]. Upstream reports[2]: v25.0.0 === Deprecations and Removals - - Removed check for config in XDG_DATA_HOME on Linux systems. (#99) - In platform

Heads-up: updating flatbuffers to 24.3.25 in F41/Rawhide

I know, we just did flatbuffers 24.3.7, but there is a bugfix update, 24.3.25, and the ABI and SONAME version always break, so here we go again! In one week (2024-04-04), or slightly later, I plan to update the flatbuffers package to 24.3.25 in F41/Rawhide[1]. As usual, this includes an

Heads-up: updating flatbuffers to 24.3.7 in F41/Rawhide

In one week (2024-03-25), or slightly later, I plan to update the flatbuffers package to 24.3.7 in F41/Rawhide[1]. As usual, this includes an SONAME version bump. Upstream follows calendar versioning and does not attempt to keep the ABI stable across releases. Unless a maintainer asks me to

Re: SPDX Statistics - Please Please Me edition

Going purely by upstream support status, yes, GConf2 should be retired; it’s been obsolete for a decade. Going by dependent packages, it’s not so simple. Some of these dependencies are no doubt spurious, optional, or otherwise “removable;” others are real hard dependencies from

License change: python-email-validator 2.1.1 is Unlicense (was CC0-1.0)

Beginning with version 2.1.1, the license of python-email-validator has changed from CC0-1.0 to Unlicense. Note that CC0-1.0 is no longer allowed for code in Fedora, but python-email-validator was covered by the exception for pre-existing code in Fedora. Version 2.1.1 will be built as an

Heads-up: Updating python-fastapi to 0.110.0 in F41/Rawhide and F40/Branched

In one week, 2024-03-03, or slightly later, I will update python-fastapi to 0.110.0[1] (or later if another release appears) in F41/Rawhide and F40/Branched. Upstream reports that this release contains a small breaking change[2]. I used local mock builds to verify compatibility with dependent

Heads-up: Updating llhttp to 9.2.0 in F40/Branched and F41/Rawhide

In one week, 2024-02-15, or slightly later, I plan to update llhttp to 9.2.0[1] in (what will then be) F40/Branched and F41/Rawhide. Based on the release notes[2], this release contains some bug fixes, but no security fixes or exceptionally serious bug fixes. Therefore, although this package

Re: google-re2 pacakge update and facebook vs google python bindings ?

I’m not aware of anything in grpc that would require re2 to be held back. If there is, I’d hope it could be resolved. An impact check in COPR would be wise for any update. I’ve CC’d the appropriate aliases to make sure *all* of the maintainers of the re2 and python-fb-re2 packages are aware

Re: Heads-up: abseil-cpp 20240116.0 coming to F40/Rawhide

] https://fedoraproject.org/wiki/Changes/PortingToModernC#Use_of_incompatible_pointer_types_without_a_cast [6] https://koji.fedoraproject.org/koji/taskinfo?taskID=112924642 [7] https://bugzilla.redhat.com/show_bug.cgi?id=2261744#c8 On 1/28/24 13:43, Ben Beasley wrote: In one week, 2024-02-04

Re: HELP! What's up with OpenVDB?

I opened a PR on calligra[1] at the leaf of the remaining i686 dependency chain to start the process of dropping i686, because even if we get openvdb working now, there’s no good reason to keep i686 versions of these packages in the future. The EncourageI686LeafRemoval Change was specifically

Re: Mass change of LicenseRef-KDE-Accepted-* licenses

originally posted, it seems like plasma-phonebook has a similar problem, and kf6-kglobalaccel, kf6-kjobwidgets, and kf6-kservice had filenames in comments replaced, which won’t break their builds but isn’t correct either. I still appreciate that you are cleaning this up! Thanks, Ben Beasley

Heads-up: abseil-cpp 20240116.0 coming to F40/Rawhide

or concerns, please just let me know before 2024-02-04. – Ben Beasley (FAS: music) [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/16 [2] https://github.com/abseil/abseil-cpp/releases/tag/20240116.0 [3] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/ [4] https

Re: HELP! What's up with OpenVDB?

Blender already excludes i686: https://src.fedoraproject.org/rpms/blender/blob/8088da10c20e53ab0e1dd5de6fd3a2344bd288aa/f/blender.spec#_207 So does prusa-slicer: https://src.fedoraproject.org/rpms/prusa-slicer/blob/44359e4b53c503cb61a60842abf991a01d1cb9db/f/prusa-slicer.spec#_68 Packages

Re: Orphaning python-flit

I patched python-signature-dispatch[1] and python-vecrec[2] so that they now use flit-core. I’m glad you pointed out that they were using flit. [1] https://github.com/kalekundert/signature_dispatch/pull/6 [2] https://github.com/kxgames/vecrec/pull/3 On 1/25/24 15:58, Maxwell G wrote: On Thu

Planning to unretire rust-zopfli and rust-oxipng

As required by the Package Retirement Process[1], this email announces that I plan to unretire the rust-zopfli and rust-oxipng packages. Both were retired because they were “no longer needed,” but I would like to package the oxipng command-line tool, which is similar to the existing optipng

Orphaning python-sure (test dependency for python-httpretty)

I’ve decided to orphan python-sure. I have taken care of it for some time, after picking it up the last time it was orphaned, and the package is in good shape. Nevertheless, there are a couple of reasons I don’t want to own it any more:     - Although I have a downstream patch that removes

Re: HEADSUP boost and tbb rebuilds starting in a side tag

aks the dependency chain openvdb → OpenImageIO → openshadinglanguage → usd → blender, which is the reason (or at least the initial/primary reason?) Blender failed in the mass rebuild[1]. I’m posting about this in part just to explain the problem in case anyone else is encountering something similar. –

Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

I attempted a quick check:     $ repoquery -q --repo=rawhide -l -a | tee >(         grep -E '^/usr/bin/[^/]+$' | sort -u | xargs -n 1 basename > bin.txt         ) | grep -E '^/usr/sbin/[^/]+$' | sort -u | xargs -n 1 basename > sbin.txt     $ wc -l bin.txt sbin.txt      31229 bin.txt      

Heads-up: updating python-pynamodb to 6.0.0 in Rawhide

In one week, 2024-01-21, or slightly later, I will update python-pynamodb to 6.0.0 in Rawhide[1]. This is a major version update with breaking changes[2]; however, there should be no impact to other Fedora packagers since python-pynamodb is currently a leaf package. [1]

Planning to unretire rust-libdeflater and rust-libdeflate-sys

As required by the Package Retirement Process[1], this email announces that I plan to unretire the rust-libdeflater and rust-libdeflate-sys packages. Both were retired because they were “no longer needed,” but they will be in the dependency tree of a new python-cramjam package needed for the

License for python-grabbit updated from “MIT” to “MIT AND Unlicense”

The License field for python-grabbit has been updated from “MIT” to “MIT AND Unlicense” to reflect the _version.py file generated by Versioneer 0.29. As described in https://github.com/python-versioneer/python-versioneer#license, the _version.py file generated by Versioneer is under the same

Re: Broken %pyproject_buildrequires parser

I think I would just do something like this in %prep: sed -r -i 's/^file:/# &/' tests/requirements.in On Thu, Dec 28, 2023, at 11:41 AM, Mattia Verga wrote: > While trying to update python-rpds-py I came across this commit: >

[EPEL-devel] Re: EPEL-ANNOUNCE Incompatible update of llhttp in EPEL9

I have pushed this update to stable. This is the final announcement prescribed by the EPEL Incompatible Upgrades Policy, https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ On 12/13/23 08:43, Ben Beasley wrote: I have just submitted for testing https

[EPEL-devel] Incompatible update of llhttp in EPEL9

I have just submitted for testing https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4b1b8b8b25, which updates llhttp from 8.1.1 to 9.1.3 in EPEL9. This is an ABI-incompatible update, and the SONAME version changes. There are also some minor API changes. The only package in EPEL9 that

Orphaning python-markdown-include

I’m orphaning the package python-markdown-include[1]. It is a leaf package in Fedora and EPEL9, and has been for several releases, although it is still used by a number of packages in the wider Python ecosystem[2]. The package is up to date, upstream remains active, and the spec file is

Heads-up: updating python-ujson to 5.9.0 in Rawhide

, or if you know the code so well that you can easily audit for potential issues not covered by the tests in %check, you might want to have a look at it sometime in the F40 release cycle. - Ben Beasley (FAS music) [1] https://src.fedoraproject.org/rpms/python-ujson/pull-request/13 [2] https

[EPEL-devel] Re: Proposed incompatible security update (again) for llhttp in EPEL9

/coprs/music/aiohttp-el9/packages/ On 11/28/23 11:36, Ben Beasley wrote: This email proposes upgrading the llhttp package in EPEL9 from 8.1.1 to 9.1.3, which would break the ABI and bump the SONAME version, under the EPEL Incompatible Upgrades Policy[1]. The llhttp package is a C library

[EPEL-devel] Proposed incompatible security update (again) for llhttp in EPEL9

This email proposes upgrading the llhttp package in EPEL9 from 8.1.1 to 9.1.3, which would break the ABI and bump the SONAME version, under the EPEL Incompatible Upgrades Policy[1]. The llhttp package is a C library (transpiled from TypeScript) that provides the low-level HTTP support for

Heads-up: python-param 2.0.0 coming to Rawhide

In one week, 2023-11-10, or slightly later, I plan to update python-param to 2.0.0 in Rawhide[1]. This is a major release with massive changes, including a number of breaking ones[2]. Nevertheless, all of the dependent packages in Fedora are already compatible[3]. [1]

Heads-up: python-probeinterface 0.2.18 coming to Rawhide

In one week, 2023-11-07, or slightly later, I plan to update python-probeinterface to 0.2.18 in Rawhide[1]. This release contains some small breaking API changes[2]; in particular, the with_channel_index argument is removed from plot_probe. Since python-probeinterface is currently a leaf

Heads-up: python-socketio 5.10.0 coming to Rawhide

In one week, 2023-11-05, or slightly later, I plan to update python-socketio to 5.10.0 in Rawhide[1]. This release contains one documented breaking API change (“async versions of enter_room and leave_room should be coroutines”), but all dependent packages still build from source, and I don’t

Heads-up: usd 23.11 coming to Rawhide

In one week, 2023-11-05, or slightly later, I plan to update usd to 23.11 in Rawhide[1]. This includes ABI changes and a SONAME version bump. There are no documented breaking API changes[2]. The sole dependent package is blender. I verified compatibility in a local mock build, and I will

Heads-up: python-pytest-bdd 7.0.0 coming to Rawhide

In one week, 2023-11-03, or slightly later, I plan to update python-pytest-bdd to 7.0.0 in Rawhide[1]. There is one incompatible change:     - ⚠️ Backwards incompatible: - ``parsers.re`` now does a `fullmatch `_ instead of a partial

Heads-up: python-pyrsistent 0.20.0 coming to Rawhide

In one week, 2023-11-02, or slightly later, I plan to build python-pyrsistent 0.20.0[1] in Rawhide/F40. The list of changes is at [2]. Notably, pyrsistent now freezes defaultdicts, which is considered a backwards-incompatible change. The only dependent package in Rawhide is python-sentry-sdk;

Heads-up: updating python-trimesh to 4.0.0 in Rawhide

In one week, 2023-10-31, or slightly later, I plan to update the python-trimesh package in Rawhide to version 4.0.0[1]. No dependent package upper-bounds its version, and a COPR impact check[2] did not reveal any incompatibilities. [1]

Re: Upgrades of Sundials and PETSc

_64 hasn’t been part of a compose yet, and getdp-3.5.0-9.fc40.x86_64 still requires libpetsc.so.3.19()(64bit), which petsc-0:3.20.0-1.fc40.x86_64 doesn’t provide. But at any other time, that command would reveal getdp as a package that needs rebuilding. Thanks, Ben Beasley (FAS music) On 10/

Re: Python enable dependency generator problem

It looks like you are using “%pyproject_buildrequires -t”, and upstream’s tox.ini gets its dependencies from the file test-requirements.txt, which pins exact versions of everything (==). Obviously, it’s very rare that this will line up with the versions packaged in Fedora. If you’re going to

Heads-up: python-absl-py 2.0.0 coming to Rawhide

In one week, 2023-10-07, or slightly later, I plan to update python-absl-py to 2.0.0 in Rawhide[1]. This release has some potentially breaking changes, described in [2], but it is a leaf package, so there is no impact to other packages in Fedora. [1]

Claiming and unretiring python-pybv

I (FAS: music) plan to adopt the python-pybv package and unretire it in F39 and F40/Rawhide. This email provides the required[1] notice. This package was retired while orphaned today due to FTI/FTBFS. I already have a PR that fixes the FTI/FTBFS[2], so I will be able to deal with that

Re: Orphaned packages looking for new maintainers

the package interactively, but at least it is buildable and installable now. On 9/7/23 7:58 AM, Ben Beasley wrote: It looks like the Electrum build is currently blocked not by protobuf, but by the failure of python-qdarkstyle to rebuild for Python 3.12[1][2]. That dependency is also currently

Re: Blender 3.6.2 failure to build

Thanks for working on this. Are you certain that Blender failed to build in F39? As I reported in [1], the build failure in question is due to openxr 1.0.29, which only happened in F40. Koschei remains green for F39[2], and there is a pending update rebuilt against USD 23.08[3] (so please

Heads-up: python-ezdxf 1.1.0 coming to Rawhide/F40 with incompatible font support

In one week, 2023-09-16, I plan to update the python-ezdxf package in Rawhide/F40 from 1.0.3 to 1.1.0[1]. Upstream warns[2]:     - WARNING: The font support changed drastically in this version, if you use the       `ezdxf.tools.fonts` module your code will break, sorry! Pin the `ezdxf`

Re: Orphaned packages looking for new maintainers

It looks like the Electrum build is currently blocked not by protobuf, but by the failure of python-qdarkstyle to rebuild for Python 3.12[1][2]. That dependency is also currently orphaned. Grepping through the Electrum source, I see:     Electrum-4.3.4/contrib/requirements/requirements.txt    

Re: Orphaned packages looking for new maintainers

Interested parties have been grappling with the problem of getting protobuf updated to v4 (22.x, 23.x, etc.), but the number of impacted packages is tremendous and there are not enough people with time to work on it, so progress has been slow. The following PR represents the state of that

[EPEL-devel] Re: Incompatible security update for llhttp in EPEL9

I just pushed this update to stable. On 8/17/23 9:08 AM, Ben Beasley wrote: This email announces that the llhttp package in EPEL9 will be upgraded from 6.0.10 to 8.1.1[1], which breaks the ABI and bumps the SONAME version, as discussed[2] and approved[3] under the EPEL Incompatible Upgrades

Heads-up: updating python-databases to 0.8.0 in Rawhide/F40 and in F39

In one week, 2023-09-05, I plan to update[1] python-databases to 0.8.0 in Rawhide/F40 and in F39. This release includes some potentially-breaking changes[2]: “In most cases, these changes should not be breaking. However, if using an open transaction across tasks, the active connection

Heads-up: updating usd (OpenUSD) from 23.05 to 23.08 in Rawhide and F39

In one week, 2023-09-01, I plan to update the usd package (OpenUSD) from 23.05 to 23.08 [1][2] in Rawhide/F40 and in F39. There are only very minor API changes, but the ABI is incompatible and the SONAME version is bumped. I will rebuild the sole dependent package, blender, in a side tag for

[EPEL-devel] Incompatible security update for llhttp in EPEL9

This email announces that the llhttp package in EPEL9 will be upgraded from 6.0.10 to 8.1.1[1], which breaks the ABI and bumps the SONAME version, as discussed[2] and approved[3] under the EPEL Incompatible Upgrades Policy[4]. At the same time, python-aiohttp will be upgraded from 3.8.4 to

Heads-up: llhttp 9.0.1 coming to Rawhide

In one week, 2023-08-29, I plan to update llhttp from 8.1.1 to 9.0.1 in F40/Rawhide[1]. This update contains some breaking API changes and breaks the ABI, bumping the SONAME version[2][3]. Most significantly, the compile-time LLHTTP_STRICT_MODE option is replaced with three new runtime flags.

Heads-up: abseil-cpp 20230802.0 coming to F40/Rawhide and F39/Branched

In one week, 2023-08-28, I plan to update abseil-cpp from 20230125.3 to 20230802.0 (Abseil LTS branch, Aug 2023)[1] in side tags for F40/Rawhide and F39/Branched. Like all new calendar versions of abseil-cpp, this breaks ABI compatibility and bumps the SONAME version. There are no intentional

[EPEL-devel] Proposed incompatible security update for llhttp in EPEL9

This email proposes upgrading the llhttp package in EPEL9 from 6.0.10 to 8.1.1, which would break the ABI and bump the SONAME version, under the EPEL Incompatible Upgrades Policy[1]. The llhttp package is a C library (transpiled from TypeScript) that provides the low-level HTTP support for

Re: Orphaned python-testing.postgresql

, but I do want to run the tests that require them, and they are simple enough that I expect I can keep them working for as long as necessary without much effort. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2189323 On 7/18/23 11:02, Ben Beasley wrote: In response, I have also orphaned python

License change: python-h5io is now simply BSD-3-Clause

Prior to release 0.1.8, python-h5io used a bundled, amalgamated versioneer.py under CC0-1.0 to generate a _version.py file under the same license, so the package was licensed (BSD-3-Clause AND CC0-1.0). With release 0.1.8, upstream no longer uses Versioneer, so the package license is now

Re: Orphaned python-testing.postgresql

for these packages has been inactive for 4-5 years I think it’s probably best to let these packages go, but anyone considering picking them up should know that both packages have spec files that use modern practices and are in a good “state of repair.” - Ben Beasley (FAS: music) On 7/18/23 2:47 AM

Re: Non-responsive maintainer check for Athos Ribeiro,(athoscr)

Thanks for your response! Of course, I understand that free time is a scarce and unpredictable commodity. Please do let me know if you need someone to co-maintain, or just make a few PR’s for, any of the font-related Python packages. Best wishes, Ben Beasley (FAS music) On Mon, Jul 17, 2023

Non-responsive maintainer check for Athos Ribeiro,(athoscr)

Does anyone know how to contact Athos Ribeiro (FAS: athoscr)? This email is part of the non-responsive maintainer process (https://bugzilla.redhat.com/show_bug.cgi?id=2223422). The following PR and bug/NEEDINFO have received no response in 7-9 months:

Re: getattr default value evaluation

The assertRaisesRegexp alias was removed in Python 3.12, along with a number of other previously-deprecated TestCase method aliases. You can search for it in https://docs.python.org/3.12/whatsnew/3.12.html. Upstream should just use assertRaisesRegex unconditionally unless they are trying to

Re: Package deprecation policy

On 6/30/23 04:34, Benson Muite wrote: There is at present no policy on when and why packages should be deprecated. Have made a proposal to allow deprecation of packages only when they fail to build or are a security concern. In other cases, orphaning and retirement should be done. Comments and

Heads-up: python-typeguard 4.0.0 coming to Rawhide

I plan to update python-typeguard from 2.12.3 to 4.0.0[1] in Rawhide. Version 3 of typeguard included a number of breaking changes[2], and 4.0.0 included a few as well[3]. Directly-dependent package compatibility with version 4.0.0 is as follows:     - python-nptyping is compatible     -

Heads-up: flatbuffers 23.5.26 coming to Rawhide

In one week (2023-06-06), or slightly later, I plan to build flatbuffers 23.5.26 in Rawhide[1]. Because flatbuffers offers no ABI stability, it will be necessary to rebuild the sole dependent package, hyperhdr. Since I don’t currently have access to that project, there are three possibilities:

Re: Bypassing setuptools_scm

On Sun, May 28, 2023, at 8:03 PM, Orion Poplawski wrote: > Is there a canonical way to bypass setuptools_scm? Sometimes one would > like to build from a github tarball (e.g. for test data) but then > setuptool_scm fails to detect a version. Setting the environment variable

Re: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a license change

On 5/27/23 08:33, Fabio Valentini wrote: This doesn't explicitly mention statically linked binaries / header-only libraries, but it's clear that this rule applies to these situations as well (after all, binaries *are* built from project sources that have distinct licenses). I don't see how

Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a license change

This is a “heads-up” email about a (non-breaking) major version update with a (non-disruptive) license change in the fast_float package in Rawhide. Once I have a successful scratch build in the PR[1], I plan to update fast_float from 4.0.0 to 5.0.0. ABI changes are impossible because this is

Re: Status of the forge macros?

On 5/25/23 03:02, Panu Matilainen wrote: On 5/24/23 18:26, Zbigniew Jędrzejewski-Szmek wrote: Minor comment:    %(c=%{commit}; echo ${c:0:7}) is a bit nicer because it doesn't require 'cut', it just uses 'echo', which is a shell builtin. Or in rpm >= 4.19 (just landed in rawhide), you can

Re: Status of the forge macros?

In your example, the forge macros simplify the spec file only because a snapshot is involved; but the forge macros put the snapshot info in the Release field, which is still permissible but deprecated[1]. Without the forge macros, the spec file would admittedly be a little more complex. I

Re: more distinct default bash prompt?

In my experience, “colorblindness” is generally understood to include a range of color vision “anomalies.” I have the most common form, deuteranomaly. Green does not look as bright as other colors to me, and I have a hard time distinguishing greenish colors from reddish colors when they are

Re: changing the name of a package

On Sat, May 6, 2023, at 10:58 AM, Sandro wrote: > Moreover, pdf-stapler package itself should probably be renamed to > python-stapler to comply with the PyPI parity requirements [2] of the > packaging guidelines. The package is published on PyPI as 'stapler'. > > [1]

Re: Numpy version pinned despite numpy>=1.22.3

You’re right that project.dependencies has numpy>=1.22.3[1], but upstream is also pinning numpy versions in the build-system.requires section[2] in the same manner as oldest-supported-numpy[3]. This is for PyPI distribution purposes; we don’t need to build wheels that support numpy versions

Heads-up: edflib 1.24 coming to Rawhide

In one week (2023-04-30), or slightly later, I plan to update edflib to 1.24, which includes a .so version bump. The shared library versioning was previously added downstream; now upstream is handling it. The package is currently a leaf, so there should be no impact.

Re: Heads-up: USD 23.02 coming to Rawhide

Since I announced the update to USD 23.02, USD 23.05 was released, so I will update to that version instead. The schedule and the other details remain the same. On 4/17/23 10:58, Ben Beasley wrote: Now that Blender 3.5 has landed, I can update the usd package in Rawhide to version 23.02[1]. I

[EPEL-devel] Retiring flintqs in EPEL7/8/9

As previously proposed on the epel-devel mailing list, and in accordance with the EPEL Retirement Policy: Process: Security Reasons[1], I will be retiring the flintqs package in EPEL7, EPEL8, and EPEL9 today. When I took over maintenance of the flintqs package[2]—which contains William Hart’s

Heads-up: USD 23.02 coming to Rawhide

Now that Blender 3.5 has landed, I can update the usd package in Rawhide to version 23.02[1]. I plan to build it in one week, 2023-04-24, or slightly later. The .so version is bumped (as with every release) and the monolithic library is renamed from libusd_usd_ms.so to libusd_ms.so. I am also

[EPEL-devel] Intent to retire flintqs in EPEL7, EPEL8, and EPEL9 for security reasons

When I took over maintenance of the flintqs package[1]—which contains William Hart’s quadratic sieve implementation, as modified for sagemath—I built it for EPEL7, EPEL8, and EPEL9. My thoughts were, “Why not? Someone might find it useful.” It was recently pointed out[2][3] that the flintqs

Re: Heads-up: fast_float 4.0.0 coming to Rawhide

Thanks; you’re correct. At least I got the year right! On Sat, Apr 1, 2023, at 8:47 AM, Luna Jernberg wrote: > Should this be 2023-04-07? 2023-03-07 has been weeks ago ? > > On 3/31/23, Ben Beasley wrote: >> In one week (2023-03-07), or slightly later, I plant to update >>

Heads-up: fast_float 4.0.0 coming to Rawhide

In one week (2023-03-07), or slightly later, I plant to update fast_float to 4.0.0[1] in Rawhide. This new major release contains one small but technically incompatible change: errc::result_out_of_range is now set on over/underflow. A PR[2] is ready, and I have already verified (by local mock

Re: Anyone interested in packaging nim-lang?

This is just a note that nim was packaged in Fedora at one point[1], but was orphaned and eventually retired. There is a process[2] for reviving such a package; it will be similar to the process for adding a new package. [1] https://src.fedoraproject.org/rpms/nim [2]

Re: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39

ve a much better understanding of what is happening, how, and why, and I’m still happy to consider any proposals to proceed differently. On 3/15/23 6:29 PM, Jonathan Wakely wrote: On Wed, 15 Mar 2023 at 22:17, Jonathan Wakely wrote: On Wed, 15 Mar 2023 at 22:14, Ben Beasley

Re: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39

already technically needed C++17, and it is mere happenstance that this particular release is revealing incompatibilities. On Wed, Mar 15, 2023, at 10:01 AM, Jonathan Wakely wrote: > On Wednesday, March 15, 2023, Ben Beasley wrote: >> In one week (2023-03-22), or slightly later, I plan

Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39

In one week (2023-03-22), or slightly later, I plan to update abseil-cpp[1] in Rawhide/F39 to the latest LTS release, which is currently 20230125.1. Release notes are available[2]. The most significant breaking change is that dependent packages are required to compile with C++14 or later, and

Re: Let's deprecate the %{pyproject_build_lib} macro... ?

Considering the rationale you’ve laid out, I don’t have any complaints about deprecating %{pyproject_build_lib}. I’m indifferent to the possible addition of a setuptools-specific macro, assuming the setuptools build directory is expected to stop changing frequently. I tested the proposed

License change: python-versioneer, python-ncclient

Since python-versioneer was updated to 0.28 in Rawhide, its license changed from Public Domain (which really should have been CC0-1.0) to Unlicense. This reflects an upstream relicensing decision in version 0.24. While the comments in versioneer-generated _version.py files mention only that

Heads-up: flatbuffers 23.3.3 coming to F39/Rawhide and F38/Branched

In one week (2023-03-11), or slightly later, I plan to update flatbuffers to 23.3.3 in F39/Rawhide and F38/Branched[1]. This is an incompatible update because the libraries offer no ABI stability—the .so version is bumped to 23.3.3—and because the --proto option was removed from the flatc

Updating libbraiding from 1.1 to 1.2 in F39/Rawhide

In one week (2023-03-09), or slightly later, I plan to update libbraiding from 1.1 to 1.2 in F39/Rawhide. Upstream says, “Minor changes for compatibility with newer C++.” https://github.com/miguelmarco/libbraiding/compare/1.1...1.2 This is not supposed to be an incompatible update, and the .so

Heads-up: python-shapely 2.0.1 coming to Fedora Rawhide/39 (with updated License)

In one week (2023-03-02), or slightly later, I plan to update the python-shapely package from 1.8.5.post1 to 2.0.1 in Rawhide/F39 by merging the linked PR[1]. There are incompatible changes[2], but after some patching and some waiting for upstream releases, all dependent packages now build

  1   2   3   4   >