this now, rather than in a future
patch release, by removing and Obsoleting the pngcheck-extras subpackage
that contained them, beginning with Rawhide/F43. I am quite certain that
nothing depended on the removed subpackage.
– Ben Beasley (FAS: music)
[1] https://src.fedoraproject.org/rpms
to find some time to help with impact checks.
– Ben
On 4/11/25 12:19 PM, Richard Shaw wrote:
> On Tue, Apr 8, 2025 at 3:38 PM Ben Beasley wrote:
>> On Tue, Apr 8, 2025, at 7:41 AM, Richard Shaw wrote:
>> > On Tue, Apr 8, 2025 at 6:35 AM Ben Beasley wrote:
>> >&g
SONAME version bump.
I used local mock builds to verify API compatibility. I will rebuild all
dependent packages (c4fs and c4log for c4core, jsonnet for rapidyaml) in
a side tag, working as maintainer for the c4* packages and as
provenpackager for jsonnet.
– Ben Beasley (FAS: music)
[1
On Tue, Apr 8, 2025, at 7:41 AM, Richard Shaw wrote:
> On Tue, Apr 8, 2025 at 6:35 AM Ben Beasley wrote:
>> In one week, 2025-04-15, or slightly later, I plan to update
>> openshadinglanguage from 1.13.12.0 to 1.14.5.0 in F43/Rawhide[1].
>
> I've slept too many times
changes, as proven in COPR[3].
I will rebuild both dependent packages (usd and blender) in a side tag,
working as a co-maintainer of each package.
– Ben Beasley (FAS: music)
[1] https://src.fedoraproject.org/rpms/openshadinglanguage/pull-request/8
[2]
https://github.com
I don’t think there is enough information to understand what this
proposal actually means, even in general terms. What kind of graphics
need upscaling, and to whom do they belong? When would they be upscaled,
and why? Who would benefit, and how?
On 4/6/25 2:16 PM, Ryan Bach via devel wrote:
T
guiding principles, and to provide concrete guidance for
common cases, but it’s also important to acknowledge that Fedora packagers have
to deal with a wide variety of upstreams and ecosystems, some of them deeply
idiosyncratic.
- Ben Beasley (FAS: music
On 3/11/25 1:29 AM, Ben Beasley wrote:
In one week, 2025-03-18, or slightly later, in collaboration
with Scott Logan (FAS: cottsay), I plan to update spatialindex from
1.9.3 to 2.1.0 in F43/Rawhide[1].
I just merged this side tag[1].
It turns out that qgis started to FTBFS after I announced
planned because it doesn’t seem justified at this point in the release
cycle.
– Ben Beasley (FAS: music)
[1] https://src.fedoraproject.org/rpms/spatialindex/pull-request/3
[2] https://github.com/libspatialindex/libspatialindex/releases/tag/2.0.0
[3] https://github.com/libspatialindex
I had the hsakmt-devel problem too, so I opened
https://src.fedoraproject.org/rpms/rocm-runtime/pull-request/11.
On Tue, Mar 4, 2025, at 2:54 PM, Przemek Klosowski via devel wrote:
> On 3/4/25 10:24 AM, Miroslav Suchý wrote:
>> Do you want to make Fedora 42 better? Please spend 1 minute of your t
On Mon, Mar 3, 2025, at 12:28 PM, Petr Pisar wrote:
> RPM poorly handles changing symlinks to directories (or vice versa?). This
> shortcoming can be mitigated with an RPM scriptlet, but scriptlets are frown
> by OSTree distribution systems.
>
> In case you will need to revert the symlink, your cou
It looks like the vtk build for F43[1] failed due to [2] (which is now
hopefully resolved), but the side tag was still merged[3], so quite a
few things that depend directly on VTK now fail to install in Rawhide. I
kicked off a fresh build[4], which I hope will succeed and resolve the
problem.
The credentials-fetcher package was also rebuilt for the
abseil-cpp-20250127.0 update, which just landed in Rawhide a couple of
hours ago. I didn’t build this version for F42, only Rawhide. Depending
on timing, you may find it necessary to do an additional rebuild of
credentials-fetcher in your
On 2/23/25 7:14 PM, Alexander Ploumistos wrote:
That is what I ended up doing and it is indeed unfortunate, we don't
have that many packages with so thorough testing. I will get in touch
with upstream about a couple of regressions and I will bring up the
issues with the tests when I do. Do you w
Note that as long as we’re on Pagure, it’s impossible to make a PR for
an empty commit.
On 2/20/25 8:51 AM, Cristian Le via devel wrote:
On 2025/02/20 13:17, Miro Hrončok wrote:
What if we allowed all packagers to push empty commit to any package?
That should eliminate *some* need for proven
opportunity is there.
On 2/20/25 8:54 AM, Ben Beasley wrote:
Note that as long as we’re on Pagure, it’s impossible to make a PR for
an empty commit.
On 2/20/25 8:51 AM, Cristian Le via devel wrote:
On 2025/02/20 13:17, Miro Hrončok wrote:
What if we allowed all packagers to push empty commit to any
On 2/20/25 8:02 AM, Neal Gompa wrote:
What does that number look like when we exclude rust2rpm managed packages?
$ rg -l '%\{?autorelease' | while read -r spec; do if ! grep -Fq
'Generated by rust2rpm' "${spec}"; then echo "${spec}"; fi; done | wc -l
6559
$ find . -name '*.spec' | while rea
Neither python-yarl nor python-uvloop is currently in EPEL10, so these
would fall under the normal EPEL package request process,
https://docs.fedoraproject.org/en-US/epel/epel-package-request/. I do
agree that EPEL10 branching should be based on the latest versions in
Rawhide in these cases.
In one week, 2025-02-27, I plan to update python-aiohttp from 3.10.11 to
3.11.12 in F43/Rawhide[1]. I impact-checked this update in COPR and
found no regressions, but it does have documented breaking changes, so
I’m going through the announcement process.
I would like to do the same update in
- https://src.fedoraproject.org/rpms/spacebar/pull-request/4
– Ben Beasley (FAS: music)
[1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/26
[2] https://github.com/abseil/abseil-cpp/releases/tag/20250127.0
[3] https://copr.fedorainfracloud.org/coprs/music/abseil-cp
t looks like the difficulty of getting them working in the current
release is high enough that simply omitting the tests would be
justifiable. You’ll want to maintain the %pyproject_check_import "smoke
test," of course.
- Ben Beasley (FAS: music)
On 2/17/25 7:55 PM, Alexander Ploumisto
ities. For stable releases Fedora
41 and 40, this update is permitted under a permanent exception to the
Updates Policy[3].
– Ben Beasley (FAS: music)
[1] https://src.fedoraproject.org/rpms/uv/pull-request/37
[2] https://github.com/astral-sh/uv/releases/tag/0.6.0
[3] https://pagure.io/fesco/issue
In one week (2025-02-22), or slightly later, I plan to update the
rapidyaml package to 0.8.0[1] in F43/Rawhide and F42/Branched. This is
an ABI-breaking update with an SONAME version bump; there are also some
API-breaking changes, some of which might be behavioral (only detectable
by runtime te
All three builds completed successfully. If I haven’t missed anything,
it should be safe to merge the side tag at any time.
On 2/13/25 10:03 PM, Ben Beasley wrote:
I’ve used provenpackager privilege to kick off rebuilds of gdal,
groonga, and root in the side tag (f43-build-side-105129
://koji.fedoraproject.org/koji/taskinfo?taskID=129216944
I’ll keep an eye on these builds to make sure they all complete
successfully. I think those should be the last three necessary rebuilds.
On 2/13/25 4:40 PM, Ben Beasley wrote:
I think and hope that I’ve analyzed this correctly.
It looks like
I think and hope that I’ve analyzed this correctly.
It looks like these packages have already been rebuilt:
- ceph
- myst-nb
https://koji.fedoraproject.org/koji/builds?order=-tag_name&tagID=105129&inherited=1&latest=1
It looks like these packages still need to be rebuilt:
- gdal
- groonga
It’s time for another flatbuffers update,
https://src.fedoraproject.org/rpms/flatbuffers/pull-request/15. As
always, this is ABI-incompatible and bumps the SONAME version.
I am impact-checking the dependent package hyperhdr, onnxruntime, and
qdigidoc in COPR,
https://copr.fedorainfracloud.org
, rather than saying “too bad, I dropped i686 support before
you added the dependency.” Expect updates later today, after I finish
some additional testing and the Rawhide buildroot is usable again.
On 2/7/25 8:12 AM, Ben Beasley wrote:
Yes, it looks like I probably made an error in dropping i686
You can see the problem in this attempted build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=128944651
The buildSRPMFromSCM task fails with:
DEBUG util.py:459: Failed to resolve the transaction:
DEBUG util.py:459: Problem 1: package dnf5-plugins-5.2.10.0-1.fc43.aarch64
from build req
trust cramjam to be fully reliable or
whether I should keep maintaining it in the long term, but for the time
being I still need to be able to do rebuilds and ship fixes like this one.
- Ben Beasley (FAS: music)
On Thu, Feb 6, 2025, at 8:08 PM, Orion Poplawski wrote:
python-cramjam dropped
I’ve suggested https://src.fedoraproject.org/rpms/openexr/pull-request/9
to restore i686 support and skip the failing test, at least for the time
being.
On 2/6/25 7:15 PM, Fabio Valentini wrote:
On Thu, Feb 6, 2025 at 11:37 PM Richard Shaw wrote:
It seems to be the only reason for FTBFS. A s
It seems like the inclusion of rust-smallvec on this list might have
been an error, since "fedrq wr rust-smallvec*-devel" gives a very large
number of results that aren’t subpackages of rust-smallvec itself.
-
I know that members of the AI/ML SIG are interested in packaging
python-safeten
It’s time for another flatbuffers update,
https://src.fedoraproject.org/rpms/flatbuffers/pull-request/14. As
always, this is ABI-incompatible and bumps the SONAME version. This
update will land after F42 branching, so it will be for F42/Branched and
F43/Rawhide.
I impact-checked the dependent
ng-free all the time across all branches is a lot to ask.
– Ben Beasley (FAS: music)
On 1/28/25 9:38 PM, Sérgio Basto via devel wrote:
On Tue, 2025-01-28 at 10:06 +0100, Jakub Jelinek wrote:
On Mon, Jan 27, 2025 at 07:31:35PM +, Sérgio Basto via devel
wrote:
I just want check, if I'm
hi.fedoraproject.org/updates/FEDORA-2025-5041b6b575
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=128368059
On 1/23/25 1:31 AM, Milan Crha wrote:
On Wed, 2025-01-22 at 21:35 +0100, Ben Beasley wrote:
I just merged the side tag as:
https://bodhi.fedoraproject.org/updates/FEDORA-2025-7d
nk I missed anything else.
On 1/22/25 2:28 PM, Ben Beasley wrote:
I understand the suggestion to build directly in Rawhide since things
are already broken. On the other hand, I’ve already started building
in f42-build-side-104083. I’ll compromise as follows: I will finish
building everything but
Results in COPR are promising enough so far that I’m going to go ahead
and start rebuilding the affected packages in a side tag,
f42-build-side-104083. Some of these packages take a long time to build,
so I probably won’t be able to actually merge the side tag until tomorrow.
- Ben Beasley
rawhide, since ceph is by far the slowest rebuild involved.
That should speed things up by many hours.
On 1/22/25 2:22 PM, Sérgio Basto wrote:
On Wed, 2025-01-22 at 13:35 -0500, Ben Beasley wrote:
Correction: the breaking update was built into side tag
f42-build-side-99460 soon after it was
Correction: the breaking update was built into side tag
f42-build-side-99460 soon after it was committed, but the side tag was
never merged. And it’s possible that the update was coordinated three
months ago, and I just don’t remember.
On 1/22/25 1:31 PM, Ben Beasley wrote:
It looks like the
It looks like the breaking update in question was committed three months
ago,
https://src.fedoraproject.org/rpms/gtest/c/24e4a26153b73a97db5c86109363662636235452?branch=rawhide
but never announced, coordinated, or built until the mass rebuild came
along.
I’m going to do a quick COPR test in
In one week, 2025-01-29, or slightly later, I plan to update usd to
25.02 in Rawhide[1][2].
As usual, this is an ABI-incompatible update with an SONAME version bump.
I will rebuild the sole dependent package, blender, in the same side
tag, and this will actually fix Blender’s failure to build
In one week, 2025-01-28, or slightly later, I plan to update
python-trimesh to 4.6.0 in Rawhide[1].
Per the release notes[2], it looks like this contains some
potentially-incompatible changes. I’ve impact-checked this as well as I
can[3], but it’s possible that there could be some issues that
, and I feel like
it is time to let them go. Still, I have added the maintainers of the
packages that use them to the CC list, and it’s certainly technically
possible for someone to keep them around a little longer.
- Ben Beasley (FAS: music
-security-c and
brewtarget. Both appear to be leaf packages in Rawhide, and their
maintainers have been CC’d on this email in case someone wants to put in
the effort to fix xalan-c and keep it around a bit longer.
- Ben Beasley (FAS: music)
[1] https://lists.apache.org/thread
I just wanted to draw attention to the orphaned coin-or-* packages,
which implement a variety of optimization algorithms for things like
linear, nonlinear, and integer programming. I’m curious if anyone is
planning to pick them up or if they are truly at risk of retirement.
Several interesting
In one week, 2025-01-02, or slightly later, I plan to merge and build
https://src.fedoraproject.org/rpms/flatbuffers/pull-request/12 to update
flatbuffers to 24.12.24 in Rawhide. As always, this is an
ABI-incompatible update that bumps the SONAME version.
I impact-checked the dependent package
I agree with the plan, but I wanted to note that deprecating a package
that other packages depend on requires a FESCo-approved Change[1].
(It is weird that the deprecation policy is so much more bureaucratic
than the retirement policy. By comparison, I don’t know of any policy
that would forbi
In one week, 2024-11-21, or slightly later, I plan to update libfplll to
version 5.5.0[1] in Rawhide. This is an ABI-incompatible update that
bumps the SONAME version from 8 to 9.
The following packages depend directly on libfplll and will need to be
rebuilt in a side tag. I will rebuild them
In one week, 2024-11-21, or slightly later, I plan to update usd to
version 24.11[1] in Rawhide. As usual, this is an ABI-incompatible
update. The sole dependent package is blender; I already verified
compatibility in a local mock build, and I will handle rebuilding it in
the same side tag.
[
Unfortunately, building large projects that use Rust with full debuginfo
tends to push the memory limits of our builders. The peak memory usage
is usually at link time, so reducing the number of parallel jobs isn’t
helpful. For now, reducing the debuginfo level as suggested seems to be
the best
As a follow-up to my email about orphaning python-opentelemetry and
related packages, I have discovered that python-http-server-mock is only
needed as a test dependency for python-opentelemetry-contrib, so I am
orphaning it as well.
The package is trivial, and it should require very little eff
On Sat, Nov 9, 2024, 1:44 PM Ben Beasley wrote:
I’m orphaning python-opentelemetry and the following related packages:
- python-opentelemetry-contrib
- python-opentelemetry-propagator-aws-xray
- python-opentelemetry-resource-detector-azure
- python
I’m orphaning python-opentelemetry and the following related packages:
- python-opentelemetry-contrib
- python-opentelemetry-propagator-aws-xray
- python-opentelemetry-resource-detector-azure
- python-opentelemetry-sdk-extension-aws
The packages are inherently messy, but are i
Kevin’s observation about floating-point rounding and runtime dispatch is an
excellent one in general.
Those two CPU’s should, as far as I can tell, be dispatched to the same SIMD
implementations in this case.
Skimming
https://github.com/qt/qtbase/blob/v6.8.0/src/gui/painting/qimagescale_sse4.
I can’t add much detail about why this is different between Rawhide and
EPEL10, but I can get a successful EPEL10 build by adding
export LD_LIBRARY_PATH="$RPM_BUILD_ROOT/%{_libdir}"
at the beginning of %check. It’s probably good enough to just add that
(unconditionally, since it does no ha
-ulid update. I believe that no other packages should
be affected.
- Ben Beasley (FAS: music)
[1] https://src.fedoraproject.org/rpms/python-python-ulid/pull-request/5
[2] https://github.com/mdomke/python-ulid/releases/tag/3.0.0
[3] https://github.com/pydantic/pydantic-extra-types/pull/222
[4
On Fri, Oct 4, 2024, at 9:51 AM, Zbigniew Jędrzejewski-Szmek wrote:
>> Problem 4: package python3-fb-re2-1.0.7-18.fc41.x86_64 from fedora
>> requires libre2.so.9()(64bit), but none of the providers can be installed
>> - problem with installed package python3-fb-re2-1.0.7-15.fc40.x86_64
>> -
The list of packages without SPDX,
packages-without-spdx-final-maintainers.txt, seems suspicious. It has
quite a few packages I maintain that seem perfectly fine to me.
NiaAML-GUI has:
# SPDX
License: MIT
and a commit/changelog in its history entitled “Clarify that Licens
Personally, I think this is a great approach for files that already have
verbose license breakdown comments above the License tag. Such
breakdowns are technically no longer required[1], but I find they are
still a great help when maintaining or auditing packages with complex
licensing. I will p
Both python-graph-tool and python-llvmlite also use the %{shrink: …}
macro in their spec files. You’ve demonstrated how they can be validated
correctly by first allowing RPM to form the License expression in a
single line, rather than grepping the spec file directly.
On 9/6/24 7:19 AM, Ankur S
There are still packages in this list that appear to have valid license
expressions, but aren’t amenable to spec-file grepping because they use
the %shrink macro to split long license expressions across multiple
lines. Looking at this list:
music c4core fcitx5-mozc gi-docgen libpri lumina
On 9/5/24 12:06 PM, Przemek Klosowski via devel wrote:
Do you think that is a technical decision, based e.g. on dependencies
they need, or a business decision to use the app store? It's their
right to choose, but I'm curious whether it reflects the broader
developer sentiment towards flatpaks.
I am orphaning harvey[1], a graphical application that calculates and
visualizes color contrast, checking a given set of colors for WCAG
contrast compliance. The Fedora package is in excellent condition, but
upstream has asked me politely not to maintain it in Fedora[2],
preferring for users to
It looks like most or all of these issues come from the third-party
signal-libringrtc package, which I think must have come from
https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/x86_64/.
It would have to be rebuilt for Fedora 41. It doesn’t look like there is
a
https://
I have opened a non-responsive maintainer check for fbo (Fabien
Boucher)[1]. This email is part of that process.
Besides the email in their FAS profile (fbouc...@redhat.com), does
anyone know how to contact Fabien?
Fabien has not responded to FTBFS bugs on python-fb-re2 in F41[2] and
F42[3],
I think the correct solution here will be to build the “official” Python
bindings in the re2 source distribution, which are actively maintained and
which also provide a somewhat-compatible “import re2,” but are distributed on
PyPI as google-re2 rather than fb-re2.
As the new maintainer of the r
indirect one via e.g. python-requests),
then you should have received this email directly via cc or bcc.
– Ben Beasley (FAS: music)
[1] https://src.fedoraproject.org/rpms/python-urllib3/pull-request/22
[2] https://github.com/urllib3/urllib3/blob/2.2.2/CHANGES.rst#200-2023-04-26
[3] https
ystem]| would use the legacy setuptools build backend by default.
– Ben Beasley (FAS: music)
[1] https://src.fedoraproject.org/rpms/uv/pull-request/10
[2] https://github.com/astral-sh/uv/releases/tag/0.4.0
[3] https://pagure.io/fesco/issue/3262
On 8/23/24 3:33 PM, Ben Beasley wrote:
I’ve been asked[
In one week (2024-09-05), or slightly later, I plan to update the
rapidyaml package to 0.7.2[1] in F42/Rawhide and F41/Branched; I will
also update its support library c4core to 0.2.2[2]. Both are
ABI-breaking updates with SONAME version bumps. I will also update the
unversioned support library
In one week, 2024-09-02, I plan to update the usd package from 24.03 to
24.08[1] in F42/Rawhide and F41/Branched (where it will not reach the
repositories until the end of the Beta Freeze). As always, this is an
ABI-incompatible update with an SONAME version bump.
The sole dependent package is
-cpp, so it did not need to be rebuilt.
Let me know if you run into any trouble.
On 8/18/24 10:52 PM, Ben Beasley wrote:
In one week (2024-08-25), I plan to update the abseil-cpp package to
20240722.0[1] (Abseil LTS branch, July 2024) in F42/Rawhide and
F41/Branched. This release breaks ABI
affect F40 and F39, which will
still wait for the full week and for a FESCo decision.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2307495#c1
On 8/23/24 8:18 AM, Ben Beasley wrote:
In one week, 2024-08-30, I plan to update the Python package manager
uv from 0.2.37 to 0.3.x (currently 0.3.2
In one week, 2024-08-30, I plan to update the Python package manager uv
from 0.2.37 to 0.3.x (currently 0.3.2)[1]:
- in Fedora 42/Rawhide,
- in Fedora 41/Branched (where availability will be delayed by the
Beta Freeze),
- and – if approved by FESCo[2] – in Fedora 40 and Fedora 39
This is just a notice[1] that I intend to unretire rust-tabwriter[2],
which was retired because it became a leaf package. It is a test
dependency for https://crates.io/crates/jiff, which I need to package in
order to update uv[3] to 0.3.0.
– Ben Beasley (FAS: music)
[1]
https
In one week (2024-08-25), I plan to update the abseil-cpp package to
20240722.0[1] (Abseil LTS branch, July 2024) in F42/Rawhide and
F41/Branched. This release breaks ABI with an SONAME version bump, and
there are some small breaking API changes documented in the upstream
release notes[2].
An
In one week, 2024-08-25, I plan to update python-aiohttp from 3.9.5 to
3.10.3[1] in F42/Rawhide and in F41/Branched. As noted in [2], there are
some breaking API changes from 3.9.x to 3.10.x, so I have no plans to
update F40, F39, or EPEL9.
A COPR impact check[3] did not reveal any incompatibi
I noticed that the python-case package was orphaned with a message,
Unmaintained upstream -- last commit upstream 7 years ago. No
dependent package
Now, this is not strictly true. Nothing depends on python-case at
runtime, but it is a BuildRequires for four packages. However, all of
thes
At some point we added a rule,
“A license should normally appear only once in the License: tag license
expression. But if the license expression includes an OR sub-expression, that
OR sub-expression is treated as though it were a single license for purposes of
this rule. *As an exception to
I offered a simple patch via
https://src.fedoraproject.org/rpms/qt5-qtwebengine/pull-request/18 for
the initial error Sandro encountered in COPR, but I didn’t manage to get
all the way to a successful build (even when python2 was available). The
bundled chromium is built as C++14, and having ab
I just picked up re2.
- Ben Beasley (FAS: music)
On 8/14/24 10:49 PM, maxw...@gtmx.me wrote:
Report started at 2024-08-15 02:00:06 UTC
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the
Given the timing and the complexity of the dependency chains involved
here, I used provenpackager privilege to start rebuilding grpc in both
F42 and F41, which will unblock many of the other packages that need to
be rebuilt.
To do so, I added a BuildRequires on openssl-devel-engine[1] as a
sh
I am confident this is not your fault, but I’m not sure exactly what’s going
wrong. Please consider filing an issue at
https://pagure.io/fedora-infrastructure/issues to the effect that
synchronization of Fedora components to Bugzilla appears to be delayed or
broken.
On Tue, Aug 13, 2024, at 6:
that this
accounts for a number of the packages that are flagged as problematic or hard
to parse.
On Tue, Jul 30, 2024, at 1:57 PM, Miroslav Suchý wrote:
> Dne 30. 07. 24 v 7:40 odp. Ben Beasley napsal(a):
>> Could you please take a look at rust-oxipng to see exactly what the tooli
Could you please take a look at rust-oxipng to see exactly what the tooling is
complaining about? Everything in the spec file,
https://src.fedoraproject.org/rpms/rust-oxipng/blob/rawhide/f/rust-oxipng.spec,
looks like a valid SPDX expression to me. Thanks!
On Tue, Jul 30, 2024, at 10:07 AM, Mir
For further context, the enum in question is defined in Rust and
exported to Python via PyO3[1]. These enums are similar to, but not
interoperable with, Python’s IntEnum[2], and the relevant PyO3
documentation[3] suggests by example that == is the expected comparison
operator.
[1]
https://gi
Thanks to some recent upstream work in openshadinglanguage, I was able to
rebuild it with LLVM 18 in Rawhide, so it should no longer be impacted.
The latest upstream release of python-llvmlite now has “experimental” support
for LLVM 15, and the package is now built with LLVM 15 in Rawhide. Upstr
Considering this, I am also orphaning my package python-ZConfig. It is a
dependency for python-ZEO and python-ZODB, which you orphaned, and for
python-zdaemon, which (without python-ZEO) will become a leaf package.
On 6/26/24 12:11 PM, Jerry James wrote:
I have orphaned some packages I no long
Please note that switching to x86_64-v2 does *not* give you access to
AVX2 or even AVX. It stops at SSE4.2 with POPCNT.
AVX2 means x86_64-v3, which both excludes a lot more hardware and allows
(in some cases) much more significant performance gains.
On 6/19/24 3:29 AM, Vitaly Zaitsev via deve
This never made it to the packaging guidelines, but FESCo made a
relevant decision a few years ago:
Libraries packaged in Fedora may require ISA extensions, however any
packaged application must not crash on any officially supported
architecture, either by providing a generic fallback implemen
About three years ago, I picked up the grpc package after it was
orphaned. I put quite a bit of work into it – migrating from autotools
to CMake, enabling tests, and packaging the latest version – and I kept
it up to date for a while, until further updates were blocked by the
need for a major p
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 can
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 i
, 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 be rebuilt.
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
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
would 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.
You can use:
https://koji.fedoraproject.org/koji/builds?order=-tag_name&tagID=88169&inherited=1&latest=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 synf
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
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 dependencies
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 n
1 - 100 of 378 matches
Mail list logo
