Fedora eln compose report: 20250208.n.0 changes

[Fedora ELN Report]

OLD: Fedora-eln-20250207.n.0
NEW: Fedora-eln-20250208.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   3
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   1.72 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   586.47 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ceph-2:19.2.1-1.eln146
Old package:  ceph-2:19.2.0-2.eln144
Summary:  User space components of the Ceph file system
RPMs: librados-devel librados2 libradospp-devel librbd-devel librbd1
Size: 27.66 MiB
Size change:  546.41 KiB
Changelog:
  * Fri Feb 07 2025 Kaleb S. KEITHLEY  - 2:19.2.1-1
  - ceph-19.2.1 GA


Package:  filesystem-3.18-38.eln146
Old package:  filesystem-3.18-36.eln145
Summary:  The basic directory layout for a Linux system
RPMs: filesystem filesystem-srpm-macros
Size: 5.35 MiB
Size change:  -10 B
Changelog:
  * Thu Feb 06 2025 Zbigniew J??drzejewski-Szmek  - 3.18-38
  - Obsolete basesystem package


Package:  kernel-6.14.0-0.rc1.20250207gitbb066fe812d6.19.eln146
Old package:  kernel-6.14.0-0.rc1.20250205git5c8c229261f1.17.eln146
Summary:  The Linux kernel
RPMs: kernel kernel-64k kernel-64k-core kernel-64k-debug 
kernel-64k-debug-core kernel-64k-debug-devel kernel-64k-debug-devel-matched 
kernel-64k-debug-modules kernel-64k-debug-modules-core 
kernel-64k-debug-modules-extra kernel-64k-devel kernel-64k-devel-matched 
kernel-64k-modules kernel-64k-modules-core kernel-64k-modules-extra 
kernel-64k-uki-virt kernel-64k-uki-virt-addons kernel-abi-stablelists 
kernel-core kernel-cross-headers kernel-debug kernel-debug-core 
kernel-debug-devel kernel-debug-devel-matched kernel-debug-modules 
kernel-debug-modules-core kernel-debug-modules-extra kernel-debug-uki-virt 
kernel-debug-uki-virt-addons kernel-devel kernel-devel-matched kernel-doc 
kernel-headers kernel-modules kernel-modules-core kernel-modules-extra 
kernel-rt kernel-rt-core kernel-rt-debug kernel-rt-debug-core 
kernel-rt-debug-devel kernel-rt-debug-kvm kernel-rt-debug-modules 
kernel-rt-debug-modules-core kernel-rt-debug-modules-extra kernel-rt-devel 
kernel-rt-kvm kernel-rt-modules kernel-rt-modules-core kernel-rt-modules-extra 
kernel-tools kernel-tools-libs kernel-tools-libs-devel kernel-uki-virt 
kernel-uki-virt-addons kernel-zfcpdump kernel-zfcpdump-core 
kernel-zfcpdump-devel kernel-zfcpdump-devel-matched kernel-zfcpdump-modules 
kernel-zfcpdump-modules-core kernel-zfcpdump-modules-extra libperf perf 
python3-perf rtla rv
Size: 1.68 GiB
Size change:  40.07 KiB
Changelog:
  * Thu Feb 06 2025 Fedora Kernel Team  
[6.14.0-0.rc1.92514ef226f5.17]
  - Linux v6.14.0-0.rc1.92514ef226f5

  * Fri Feb 07 2025 Fedora Kernel Team  
[6.14.0-0.rc1.bb066fe812d6.18]
  - fedora: enable USB device USB5744 (Peter Robinson)
  - Linux v6.14.0-0.rc1.bb066fe812d6

  * Fri Feb 07 2025 Fedora Kernel Team  
[6.14.0-0.rc1.bb066fe812d6.19]
  - Add -fzero-init-padding-bits to bindgen_skip_cflags (Justin M. Forbes)
  - apply -Wno-error=unterminated-string-initialization temporarily (Thorsten 
Leemhuis)
  - x86/boot: Use '-std=gnu11' to fix build with GCC 15 (Nathan Chancellor)
  - include/linux: Adjust headers for C23 (Jakub Jelinek)
  - x86/insn_decoder_test: allow longer symbol-names (David Rheinsberg)



= DOWNGRADED PACKAGES =
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Java update notices on Fedora 41

[Mateus Rodrigues Costa]

Em sex., 7 de fev. de 2025 às 18:56, Chris Adams  escreveu:
>
> Why is updating a Fedora 41 system with java-11-openjdk installed
> getting deprecation notices for a Fedora 42 change?  I got:
>
> The java-11-openjdk package is deprecated and may no longer receive 
> updates. Since f42 install adoptium-temurin-java-repository and install 
> temurin-11-jre
> 
> https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#adoptium-temurin-java-repository
> It currently lacks rpm-based debuginfo, fastdebugs and slowdebugs and 
> headless subpackage. It also lacks offline javadocs and jdk duplicates jre
>
> The link is to a Fedora 42 change.
>

From my understanding from reading that change it seems that:

* Fedora wants to only ship the latest LTS OpenJDK instead of shipping
several versions
* If the user wants a specific Java version they should instead
download from some third-party provider such as Adoptium's Temurin

However:

* IIRC there were some backward compatibility issues with Java in the
Java 6/7/8 era, but nowadays I guess that is not as much of a concern,
so no reason to not run latest LTS
* Even if the older LTS OpenJDKs are removed, the change itself
mentions a `adoptium-temurin-java-repository` package so you can
install the Temurin versions if you really need Java 11

All in all, the most concern would be that it says they aren't
updating that specific package, moving to the latest LTS or Temurin is
the correct solution.

The change also mentions the Minecraft concern. I personally am not
sure why running with latest LTS wouldn't work except maybe for older
versions?

> --
> Chris Adams 
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libarrow (Apache Arrow) and liborc (Apache ORC) SONAME bumps in rawhide

[Jerry James]

On Thu, Feb 6, 2025 at 4:03 PM Kaleb Keithley  wrote:
> side-tag f43-build-side-105129 has been created for rebuilding the dependent 
> packages:
[snip]
>  * myst-nb

I have built myst-nb in the side tag.  Do you plan to do this for F42
also, or is this F43 only?
-- 
Jerry James
http://www.jamezone.org/
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libarrow (Apache Arrow) and liborc (Apache ORC) SONAME bumps in rawhide

[Kaleb Keithley]

I've already updated f42 once to libarrow-18.0.0. (liborc was at 2.0.x
already from f41.) I wasn't really planning on doing it again.

I dunno, I suppose I could be persuaded otherwise if there's a compelling
reason.

On Fri, Feb 7, 2025 at 4:37 PM Jerry James  wrote:

> On Thu, Feb 6, 2025 at 4:03 PM Kaleb Keithley  wrote:
> > side-tag f43-build-side-105129 has been created for rebuilding the
> dependent packages:
> [snip]
> >  * myst-nb
>
> I have built myst-nb in the side tag.  Do you plan to do this for F42
> also, or is this F43 only?
> --
> Jerry James
> http://www.jamezone.org/
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Kaleb
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Java update notices on Fedora 41

[Fabio Valentini]

On Fri, Feb 7, 2025 at 10:56 PM Chris Adams  wrote:
>
> Why is updating a Fedora 41 system with java-11-openjdk installed
> getting deprecation notices for a Fedora 42 change?  I got:
>
> The java-11-openjdk package is deprecated and may no longer receive 
> updates. Since f42 install adoptium-temurin-java-repository and install 
> temurin-11-jre
> 
> https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#adoptium-temurin-java-repository
> It currently lacks rpm-based debuginfo, fastdebugs and slowdebugs and 
> headless subpackage. It also lacks offline javadocs and jdk duplicates jre
>
> The link is to a Fedora 42 change.

This should also really not be printed in RPM scriptlets, that's a
quite obvious anti-pattern ...

Fabio
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

mdds/libixion/liborcus updates

[Gwyn Ciesla via devel]

In order to fix various FTBFS bugs and bring these packages current, I'll be 
bulding these along with their consumers, libetonyek, LapPlot and libreoffice, 
since they have soname bumps.  I'll be doing this in rawhide and f42. I don't 
anticipate any drama but will use side tags just in case.

-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.

signature.asc
Description: OpenPGP digital signature
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: retiring basesystem package

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 07, 2025 at 04:54:36PM +0100, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
> 
> > Indeed. Apparently I was too hasty with the retirement. The package is
> > being unretired, so this be resolved soon.
> 
> Do we need to add back the glibc dependency?

I don't think so. Unless we observe problems without it…
It was added in https://bugzilla.redhat.com/show_bug.cgi?id=1757267,
but that was long time ago. So maybe we'll be fine with the new dnf
and a better resolver?

Zbyszek


-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libarrow (Apache Arrow) and liborc (Apache ORC) SONAME bumps in rawhide

[Kaleb Keithley]

liborc-2.1.0 and libarrow-19.0.0 are now built in the side tag
(f43-build-side-105129).

On Thu, Feb 6, 2025 at 6:02 PM Kaleb Keithley  wrote:

> Arrow packages include libarrow*.rpm parquet*.rpm (libparquet*), and
> python-pyarrow*.rpm.   Updating to Arrow 19.0.0
>
> ORC packages include liborc2*.rpm.  Updating to ORC 2.1.0
>
> side-tag f43-build-side-105129 has been created for rebuilding the
> dependent packages:
>  * ceph (for which I am the maintainer
>  * gdal
>  * groonga
>  * myst-nb
>  * python-dask
>  * python-dask-expr
>  * python-distributed
>  * python-formulaic
>  * python-fsspec
>  * python-geopandas
>  * python-pandas
>  * python-papermill
>  * python-pyogrio
>  * root
> etc.
>
> I will be building liborc, libarrow, and ceph soon. (I'm not a proven
> packager, I can't build the other packages.)
> Tentatively I plan on merging whatever is built in the side tag on or
> after 20 Feb 2025.
>


-- 

Kaleb
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Determining i686 "leaf" packages - python-cramjam dropped with i686 deps

[Orion Poplawski]

I think it's fairly easy to simply drop snappy support from pymongo, 
which I have done in my pull requests here:


https://src.fedoraproject.org/rpms/python-pymongo/pull-request/9

so I think we're all set.  No worries.

On 2/7/25 08:18, Ben Beasley wrote:
It turns out that I didn’t make an error, per se: the version of python- 
pymongo that was actually built, 4.2.0, didn’t have a dependency on 
python3-snappy when I dropped i686 support in python-cramjam, and this 
is still the case in Rawhide today. No amount of careful checking would 
have allowed me learn about the new dependency on python3-snappy in the 
committed-but-not-built update to python-pymongo 4.9.1, since it’s not 
possible to query dependencies for packages that have never been built.


Still, it seems to be no great hardship to just re-enable i686 support 
in this case, 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 support 
in python-cramjam starting in Fedora 41.


The case of a package considering dropping i686 (python-cramjam) 
having an indirect dependency from another arched package (python- 
pymongo) via one or more noarch packages (python-snappy) is the 
hardest one to check for. It’s something that I know I need to look 
for, but it has to be done manually, and it’s easy to make a mistake.


Since python-cramjam 2.9.0 added a dependency on isa-l, which doesn’t 
support i686 at all, it’s not quite trivial for me to restore i686 
support in Fedora 41, but it looks like it will be possible:


https://src.fedoraproject.org/rpms/python-cramjam/pull-request/4

If you depend on python-cramjam, you should probably be aware of new, 
concerning test failures that have appeared with recent python- 
hypothesis versions in Fedora 42 and later:


https://github.com/milesgranger/cramjam/issues/201

After some consideration, I’ve decided to skip the affected tests for 
now because I don’t see any reason to believe there is a new problem 
in cramjam itself. There *might* be a newly-*revealed* problem, and 
I’m still not sure whether I should 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 i686 with this:

commit 3ebdbdac596b6f01c97b89d3b67635519b10b944
Author: Benjamin A. Beasley 
Date:   Mon Sep 30 19:24:11 2024 -0400

 F41+: Drop i686 support (leaf package on that architecture)

 While many packages depend on this one, we believe we have 
correctly
 verified that all directly or indirectly dependent packages 
either are

 noarch or already exclude i686.

However, we are now seeing a build failure on i686 for python-pymongo:

DEBUG util.py:459:  Problem: conflicting requests
DEBUG util.py:459:    - nothing provides python3.13dist(cramjam) 
needed by python3-snappy-0.7.2-4.fc42.noarch from build


So, apparently this determination was in error, or pymongo grew some 
deps.


At this point it would be nice to drop i686 from pymongo, but how can 
one make the determination that this is a "leaf" i686 package? 
Especially since it appears that some determinations of this were 
incorrect.



--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/ 
devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora- 
infrastructure/new_issue







--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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.fedo

Re: retiring basesystem package

[Adam Williamson]

On Fri, 2025-02-07 at 18:13 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Feb 07, 2025 at 04:54:36PM +0100, Florian Weimer wrote:
> > * Zbigniew Jędrzejewski-Szmek:
> > 
> > > Indeed. Apparently I was too hasty with the retirement. The package is
> > > being unretired, so this be resolved soon.
> > 
> > Do we need to add back the glibc dependency?
> 
> I don't think so. Unless we observe problems without it…
> It was added in https://bugzilla.redhat.com/show_bug.cgi?id=1757267,
> but that was long time ago. So maybe we'll be fine with the new dnf
> and a better resolver?

I would suggest it might be wise to replace it with a dependency on
filesystem. It at least clearly needs a Requires(pre) on filesystem, as
it has a %pre script which does stuff that assumes the filesystem is in
place. Per the discussion on that bug, it seems like there was also an
intent to have a run-time dependency on setup via basesystem; removing
the basesystem dependency without replacement means glibc no longer has
a runtime dependency on setup, which seems like the problem we wanted
to fix in that bug.

So I'd say instead of just removing these lines:

Requires(pre): basesystem
Requires: basesystem

as the current commit did, we should change them to:

Requires(pre): filesystem
Requires: filesystem

That both seems defensibly "correct", and pragmatically like it should
be closest to current behaviour.

setup is denoted as a 'protected' package in dnf, which means it's hard
to remove it with dnf, but that doesn't ensure it gets installed (or
gets installed before glibc during initial deployment), and you could
still in theory do `rpm -e setup`. This would ensure that doing so
makes *rpm* complain about you doing that (i.e. protection at rpm level
as well as dnf level).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Java update notices on Fedora 41

[Chris Adams]

Why is updating a Fedora 41 system with java-11-openjdk installed
getting deprecation notices for a Fedora 42 change?  I got:

The java-11-openjdk package is deprecated and may no longer receive 
updates. Since f42 install adoptium-temurin-java-repository and install 
temurin-11-jre

https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#adoptium-temurin-java-repository
It currently lacks rpm-based debuginfo, fastdebugs and slowdebugs and 
headless subpackage. It also lacks offline javadocs and jdk duplicates jre

The link is to a Fedora 42 change.

-- 
Chris Adams 
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libarrow (Apache Arrow) and liborc (Apache ORC) SONAME bumps in rawhide

[Jerry James]

On Fri, Feb 7, 2025 at 2:52 PM Kaleb Keithley  wrote:
> I've already updated f42 once to libarrow-18.0.0. (liborc was at 2.0.x 
> already from f41.) I wasn't really planning on doing it again.
>
> I dunno, I suppose I could be persuaded otherwise if there's a compelling 
> reason.

No, that's fine.  I built a new version of myst-nb (1.2.0) into the
side tag and would like to build it for F42 as well.  If you were
going to update libarrow for F42, I would wait and build it in the
next side tag.  If you don't plan to, though, I will just go ahead.

Regards,
-- 
Jerry James
http://www.jamezone.org/
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Java update notices on Fedora 41

[Chris Adams]

Once upon a time, Mateus Rodrigues Costa  said:
> Em sex., 7 de fev. de 2025 às 18:56, Chris Adams  escreveu:
> > Why is updating a Fedora 41 system with java-11-openjdk installed
> > getting deprecation notices for a Fedora 42 change?  I got:
> >
> > The java-11-openjdk package is deprecated and may no longer receive 
> > updates. Since f42 install adoptium-temurin-java-repository and install 
> > temurin-11-jre
> > 
> > https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#adoptium-temurin-java-repository
> > It currently lacks rpm-based debuginfo, fastdebugs and slowdebugs and 
> > headless subpackage. It also lacks offline javadocs and jdk duplicates jre
> >
> > The link is to a Fedora 42 change.
> >
> 
> From my understanding from reading that change it seems that:

You're missing my point - that is a change for Fedora 42, and yet the
message showed up in a package update for Fedora 41.

-- 
Chris Adams 
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Golang Review Swaps

[Neel Chauhan]

Hi,

I have a package awaiting review: 
https://bugzilla.redhat.com/show_bug.cgi?id=2342141


Could someone please review this in exchange for me reviewing another 
package?


I want to package Retro AIM Server but need this in first.

-Neel
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Java update notices on Fedora 41

[Mario Torre]

OpenJDK 11 is EOL in Fedora regardless of the Fedora version, it hasn’t
been updated in January for example.

Jiri may answer about the details of the package itself, but users should
migrate to a version that still receives security updates or use Adoptium
Temurin which is recommended - or of course any other vendor they wish
providing they still actively update their builds.

OpenJDK 11 in Fedora won’t receive further updates.

Btw, these are very old legacy versions, in my opinion is odd that Fedora
still has them by default, especially since there are very simple ways to
get these builds if one’s needs to.

Cheers,
Mario


On Saturday, February 8, 2025, Chris Adams  wrote:

> Once upon a time, Mateus Rodrigues Costa  said:
> > Em sex., 7 de fev. de 2025 às 18:56, Chris Adams 
> escreveu:
> > > Why is updating a Fedora 41 system with java-11-openjdk installed
> > > getting deprecation notices for a Fedora 42 change?  I got:
> > >
> > > The java-11-openjdk package is deprecated and may no longer
> receive updates. Since f42 install adoptium-temurin-java-repository and
> install temurin-11-jre
> > > https://fedoraproject.org/wiki/Changes/
> ThirdPartyLegacyJdks#adoptium-temurin-java-repository
> > > It currently lacks rpm-based debuginfo, fastdebugs and slowdebugs
> and headless subpackage. It also lacks offline javadocs and jdk duplicates
> jre
> > >
> > > The link is to a Fedora 42 change.
> > >
> >
> > From my understanding from reading that change it seems that:
>
> You're missing my point - that is a change for Fedora 42, and yet the
> message showed up in a package update for Fedora 41.
>
> --
> Chris Adams 
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.
> fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-
> infrastructure/new_issue
>


-- 
Mario TorreManager, Software Engineering, OpenJDK9704 A60C B4BE
A8B8 0F30 9205 5D7E 4952 3F65 7898Red Hat GmbH, Registered seat:
Werner von Siemens Ring 12, D-85630Grasbrunn, GermanyCommercial
register: Amtsgericht Muenchen/Munich, HRB 153243,Managing Directors:
Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20250207.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20250206.n.0
NEW: Fedora-Rawhide-20250207.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  3
Dropped packages:0
Upgraded packages:   152
Downgraded packages: 0

Size of added packages:  67.85 MiB
Size of dropped packages:0 B
Size of upgraded packages:   10.72 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -16.68 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20250206.n.0.iso

= ADDED PACKAGES =
Package: docker-buildkit-0.19.0-1.fc43
Summary: Concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
RPMs:docker-buildkit
Size:67.64 MiB

Package: kojan-xml-1.0.1-3.fc43
Summary: Java library for modeling data in XML format
RPMs:kojan-xml kojan-xml-javadoc
Size:145.08 KiB

Package: rust-astral-tokio-tar-0.5.0-1.fc43
Summary: Rust implementation of an async TAR file reader and writer
RPMs:rust-astral-tokio-tar+default-devel rust-astral-tokio-tar+xattr-devel 
rust-astral-tokio-tar-devel
Size:68.78 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  NLopt-2.10.0-1.fc43
Old package:  NLopt-2.9.1-2.fc42
Summary:  Open-Source library for nonlinear optimization
RPMs: NLopt NLopt-devel NLopt-doc guile-NLopt octave-NLopt python3-NLopt
Size: 3.67 MiB
Size change:  81.86 KiB
Changelog:
  * Thu Feb 06 2025 Bj??rn Esser  - 2.10.0-1
  - Update to latest release 2.10.0
Fixes: rhbz#2343834


Package:  Rex-1.16.0-1.fc43
Old package:  Rex-1.15.0-2.fc42
Summary:  The friendly automation framework on basis of Perl
RPMs: Rex
Size: 519.67 KiB
Size change:  170 B
Changelog:
  * Thu Feb 06 2025 Dominic Hopf  - 1.16.0-1
  - Update to 1.16.0 (#2344047)


Package:  anaconda-42.26-1.fc43
Old package:  anaconda-42.24-1.fc42
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui 
anaconda-widgets anaconda-widgets-devel
Size: 17.64 MiB
Size change:  -22.76 KiB
Changelog:
  * Thu Feb 06 2025 Packit  - 42.26-1
  - Add systemd override to make /usr RW in Dracut (mkolman)
  - Update the boot options passed to initrd for dns confgiuration (rvykydal)
  - Fix calls to IsConnecting() (champetier.etienne)
  - Revert "dracut: Remove 'linear' from modules to load" (vtrefny)
  - Revert "Remove 'linear' from list of expected MD RAID levels" (vtrefny)
  - security: add a development note for certificates import in initramfs
(rvykydal)
  - security: do not issue warning on existing certificate file during dump
(rvykydal)


Package:  aom-3.11.0-1.fc43
Old package:  aom-3.9.0-5.fc42
Summary:  Royalty-free next-generation video format
RPMs: aom libaom libaom-devel
Size: 74.19 MiB
Size change:  914.37 KiB
Changelog:
  * Wed Feb 05 2025 Robert-Andr?? Mauchin  - 3.11.0-1
  - Update to 3.11


Package:  authselect-1.5.1-1.fc43
Old package:  authselect-1.5.0-9.fc42
Summary:  Configures authentication and identity sources from supported 
profiles
RPMs: authselect authselect-devel authselect-libs
Size: 1.70 MiB
Size change:  15.95 KiB
Changelog:
  * Wed Feb 05 2025 Packit  - 1.5.1-1
  - Update to version 1.5.1


Package:  buildah-2:1.39.0-2.fc43
Old package:  buildah-2:1.38.1-1.fc42
Summary:  A command line tool used for creating OCI Images
RPMs: buildah buildah-tests
Size: 168.56 MiB
Size change:  1.99 MiB
Changelog:
  * Mon Feb 03 2025 Packit  - 2:1.39.0-1
  - Update to 1.39.0 upstream release

  * Thu Feb 06 2025 Lokesh Mandvekar  - 2:1.39.0-2
  - TMT: initial enablement


Package:  clevis-pin-tpm2-0.5.3-9.fc43
Old package:  clevis-pin-tpm2-0.5.3-8.fc42
Summary:  Clevis PIN for unlocking with TPM2 supporting Authorized Policies
RPMs: clevis-pin-tpm2
Size: 3.59 MiB
Size change:  88 B
Changelog:
  * Thu Feb 06 2025 Fabio Valentini  - 0.5.3-9
  - Rebuild for openssl crate >= v0.10.70 (RUSTSEC-2025-0004)


Package:  containers-common-5:0.62.0-2.fc43
Old package:  containers-common-5:0.61.1-1.fc42
Summary:  Common configuration and documentation for containers
RPMs: containers-common containers-common-extra
Size: 106.31 KiB
Size change:  599 B
Changelog:
  * Fri Jan 31 2025 Packit  - 5:0.62.0-1
  - Update to 0.62.0 upstream release

  * Thu Feb 06 2025 Lokesh Mandvekar  - 5:0.62.0-2
  - remove patch merged upstream


Package:  cp2k-2024.3-4.fc43
Old package:  cp2k-2024.3-3.fc42
Summary:  Ab Initio Molecular Dynamics
RPMs: cp2k cp2k-common cp2k-devel cp2k-mpich cp2k-mpich-devel 
cp2k-openmpi cp2k-openmpi-devel
Size: 2.90 GiB
Size change:  -12.88 MiB
Changelog:

Re: Heads up: openexr dropping i686 arch for F42+

[Fabio Valentini]

On Fri, Feb 7, 2025, 05:20 Richard Shaw  wrote:

> On Thu, Feb 6, 2025 at 6:16 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 single test is failing.
>> Upstream has no interest in supporting 32bit anymore, which I think makes
>> sense.
>> >
>>
>> IMO this is much too late to do in F42, and should be a change proposal
>> for F43.
>>
>> Your list is also incomplete (it only seems to cover one edge in the
>> dependency graph, and not recursive dependencies).
>> It looks like dropping i686 from openexr would affect most of the
>> Plasma Desktop too, for example.
>>
>
> I merged the PR so we're fine for now, but I have to ask, why does this
> affect Plasma/KDE? We don't ship a 32-bit desktop anymore, correct?
>

Fedora doesn't ship images for i686, no, but the packages are still built
for it. Dropping the openexr library there would result in all transitive
dependencies (there are hundreds) being FTBFS (since a build failure on any
architecture fails the whole build).

I am sympathetic to dropping i686 support from packages, but if we want to
do this, it needs to be coordinated - either by adding ExcludeArch: i686 to
dependent packages that are already leaf packages on i686, or by
conditionally disabling OpenEXR support on i686 where that is possible.

Either way, it would require patching at least 40+ packages to avoid a
cascade of FailsToBuild / FailsToInstall issues.

Fabio


> Richard
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F43 Change Proposal: Remove el, jsp and servlet packages from tomcat

[Dimitris Soumis]

Hi Sergio,

I have opened the relevant issue for you at
https://issues.redhat.com/browse/RHEL-78335.
Feel free to add any comments.

Kind regards,
Dimitris

On Thu, Feb 6, 2025 at 11:56 PM Mikolaj Izdebski 
wrote:

> On Thu, Feb 6, 2025 at 7:51 PM Sérgio Basto via devel
>  wrote:
> > BTW I'd like to fix tomcat 9 in RHEL9
> > https://bugzilla.redhat.com/show_bug.cgi?id=2331858
> >
> > how we contact RH maintainer ?
>
> You can open a Jira issue at https://issues.redhat.com/
>
> --
> Mikolaj
>
> >
> >
> > Thank you
> > --
> > Sérgio M. B.
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Determining i686 "leaf" packages - python-cramjam dropped with i686 deps

[Ben Beasley]

Yes, it looks like I probably made an error in dropping i686 support in 
python-cramjam starting in Fedora 41.


The case of a package considering dropping i686 (python-cramjam) having 
an indirect dependency from another arched package (python-pymongo) via 
one or more noarch packages (python-snappy) is the hardest one to check 
for. It’s something that I know I need to look for, but it has to be 
done manually, and it’s easy to make a mistake.


Since python-cramjam 2.9.0 added a dependency on isa-l, which doesn’t 
support i686 at all, it’s not quite trivial for me to restore i686 
support in Fedora 41, but it looks like it will be possible:


https://src.fedoraproject.org/rpms/python-cramjam/pull-request/4

If you depend on python-cramjam, you should probably be aware of new, 
concerning test failures that have appeared with recent 
python-hypothesis versions in Fedora 42 and later:


https://github.com/milesgranger/cramjam/issues/201

After some consideration, I’ve decided to skip the affected tests for 
now because I don’t see any reason to believe there is a new problem in 
cramjam itself. There *might* be a newly-*revealed* problem, and I’m 
still not sure whether I should 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 i686 with this:

commit 3ebdbdac596b6f01c97b89d3b67635519b10b944
Author: Benjamin A. Beasley 
Date:   Mon Sep 30 19:24:11 2024 -0400

 F41+: Drop i686 support (leaf package on that architecture)

 While many packages depend on this one, we believe we have correctly
 verified that all directly or indirectly dependent packages either are
 noarch or already exclude i686.

However, we are now seeing a build failure on i686 for python-pymongo:

DEBUG util.py:459:  Problem: conflicting requests
DEBUG util.py:459:- nothing provides python3.13dist(cramjam) needed 
by python3-snappy-0.7.2-4.fc42.noarch from build


So, apparently this determination was in error, or pymongo grew some deps.

At this point it would be nice to drop i686 from pymongo, but how can 
one make the determination that this is a "leaf" i686 package? 
Especially since it appears that some determinations of this were incorrect.



--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rfc] mass package change to introduce sysusers.d configs

[Dan Horák]

On Tue, 04 Feb 2025 09:20:24 -0500
"Colin Walters"  wrote:

> 
> 
> On Sat, Jan 25, 2025, at 4:05 AM, Zbigniew Jędrzejewski-Szmek wrote:
> 
> > So yeah, having a package with a sysusers file and files owned by the
> > users or groups defined therein works fine. (This was already possible
> > before, but required careful creation of a %pre scriptlet. The new
> > mechanism is much nicer.)
> 
> Yes, but it is *much* better if you can to avoid having files owned by 
> floating users in packages, because it greatly increases compatibility with 
> image-based update systems.
> More on this in e.g. 
> https://docs.fedoraproject.org/en-US/bootc/building-containers/#_invoking_useradd_as_part_of_a_container_build
> 
> If for example you're doing the work to add sysusers right now and you happen 
> to also have e.g. `/var/lib/foo` in your RPM owned by that user, please also 
> take the opportunity to drop that entry (with `%ghost` if you want) and 
> create it via systemd-tmpfiles instead.

isn't there a "best practices" document how to handle services, users,
config files, runtime dirs, etc stuff in a modern world? I think one
can find the individual pieces, but I am missing the global picture.


Dan
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: retiring basesystem package

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 06, 2025 at 01:49:57PM +0100, Ondrej Vasik wrote:
> Hi Zbigniew,
> yes, basesystem is there just to ensure installation order and it could
> probably be achieved by that PR.
> There is one more benefit from the retirement - as there are
> occasionally bug reports (that should be filed against distribution)
> reported as basesystem issues (similarly to setup package being target for
> installation issues and filesystem package for issues with the partition
> layout). Retirement could reduce the confusion for people...

Thanks. Martin has merged the PR and built filesystem.
I retired basesystem now.

Zbyszek
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: retiring basesystem package

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

> On Thu, Feb 06, 2025 at 01:49:57PM +0100, Ondrej Vasik wrote:
>> Hi Zbigniew,
>> yes, basesystem is there just to ensure installation order and it could
>> probably be achieved by that PR.
>> There is one more benefit from the retirement - as there are
>> occasionally bug reports (that should be filed against distribution)
>> reported as basesystem issues (similarly to setup package being target for
>> installation issues and filesystem package for issues with the partition
>> layout). Retirement could reduce the confusion for people...
>
> Thanks. Martin has merged the PR and built filesystem.
> I retired basesystem now.

glibc depends on basesystem:

Requires(pre): basesystem
Requires: basesystem

So the buildroot is currently broken.

I'm going to rebuild glibc in a side tag without the dependency.

Thanks,
Florian

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: retiring basesystem package

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 07, 2025 at 03:53:04PM +0100, Florian Weimer wrote:
> glibc depends on basesystem:
> 
> Requires(pre): basesystem
> Requires: basesystem
> 
> So the buildroot is currently broken.

It shouldn't be. filesystem has 'Provides: basesystem'.
Do you have more details about the issue?

Zbyszek
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: retiring basesystem package

[Florian Weimer]

* Florian Weimer:

> * Zbigniew Jędrzejewski-Szmek:
>
>> On Thu, Feb 06, 2025 at 01:49:57PM +0100, Ondrej Vasik wrote:
>>> Hi Zbigniew,
>>> yes, basesystem is there just to ensure installation order and it could
>>> probably be achieved by that PR.
>>> There is one more benefit from the retirement - as there are
>>> occasionally bug reports (that should be filed against distribution)
>>> reported as basesystem issues (similarly to setup package being target for
>>> installation issues and filesystem package for issues with the partition
>>> layout). Retirement could reduce the confusion for people...
>>
>> Thanks. Martin has merged the PR and built filesystem.
>> I retired basesystem now.
>
> glibc depends on basesystem:
>
> Requires(pre): basesystem
> Requires: basesystem
>
> So the buildroot is currently broken.
>
> I'm going to rebuild glibc in a side tag without the dependency.

Nope:

2025-02-07 15:55:00,516 [ERROR] koji: TagError: Package basesystem blocked in 
f43-build-side-105153

I pushed the change to glibc:



But somehow else has to figure out how to build it.

Thanks,
Florian

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: retiring basesystem package

[Ben Beasley]

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 requires ld-linux-aarch64.so.1()(64bit), but none of the providers 
can be installed
DEBUG util.py:459:- package dnf5-plugins-5.2.10.0-1.fc43.aarch64 from build 
requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but none of the providers 
can be installed
DEBUG util.py:459:- package dnf5-plugins-5.2.10.0-1.fc43.aarch64 from build 
requires rtld(GNU_HASH), but none of the providers can be installed
DEBUG util.py:459:- package dnf5-plugins-5.2.10.0-1.fc43.aarch64 from build 
requires libc.so.6(GLIBC_2.38)(64bit), but none of the providers can be 
installed
DEBUG util.py:459:- conflicting requests
DEBUG util.py:459:- nothing provides basesystem needed by 
glibc-2.40.9000-35.fc42.aarch64 from build
DEBUG util.py:459:   Problem 2: package dnf5-5.2.10.0-1.fc43.aarch64 from build 
requires ld-linux-aarch64.so.1()(64bit), but none of the providers can be 
installed
DEBUG util.py:459:- package dnf5-5.2.10.0-1.fc43.aarch64 from build 
requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but none of the providers 
can be installed
DEBUG util.py:459:- package dnf5-5.2.10.0-1.fc43.aarch64 from build 
requires rtld(GNU_HASH), but none of the providers can be installed
DEBUG util.py:459:- package dnf5-5.2.10.0-1.fc43.aarch64 from build 
requires libc.so.6(GLIBC_2.38)(64bit), but none of the providers can be 
installed
DEBUG util.py:459:- conflicting requests
DEBUG util.py:459:- nothing provides basesystem needed by 
glibc-2.40.9000-35.fc42.aarch64 from build


On 2/7/25 9:55 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Feb 07, 2025 at 03:53:04PM +0100, Florian Weimer wrote:

glibc depends on basesystem:

Requires(pre): basesystem
Requires: basesystem

So the buildroot is currently broken.

It shouldn't be. filesystem has 'Provides: basesystem'.
Do you have more details about the issue?

Zbyszek-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: retiring basesystem package

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 07, 2025 at 10:04:25AM -0500, Ben Beasley wrote:
> 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 requires ld-linux-aarch64.so.1()(64bit), but none of the providers 
> can be installed
> DEBUG util.py:459:- package dnf5-plugins-5.2.10.0-1.fc43.aarch64 from 
> build requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but none of the 
> providers can be installed
> DEBUG util.py:459:- package dnf5-plugins-5.2.10.0-1.fc43.aarch64 from 
> build requires rtld(GNU_HASH), but none of the providers can be installed
> DEBUG util.py:459:- package dnf5-plugins-5.2.10.0-1.fc43.aarch64 from 
> build requires libc.so.6(GLIBC_2.38)(64bit), but none of the providers can be 
> installed
> DEBUG util.py:459:- conflicting requests
> DEBUG util.py:459:- nothing provides basesystem needed by 
> glibc-2.40.9000-35.fc42.aarch64 from build
> DEBUG util.py:459:   Problem 2: package dnf5-5.2.10.0-1.fc43.aarch64 from 
> build requires ld-linux-aarch64.so.1()(64bit), but none of the providers can 
> be installed
> DEBUG util.py:459:- package dnf5-5.2.10.0-1.fc43.aarch64 from build 
> requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but none of the providers 
> can be installed
> DEBUG util.py:459:- package dnf5-5.2.10.0-1.fc43.aarch64 from build 
> requires rtld(GNU_HASH), but none of the providers can be installed
> DEBUG util.py:459:- package dnf5-5.2.10.0-1.fc43.aarch64 from build 
> requires libc.so.6(GLIBC_2.38)(64bit), but none of the providers can be 
> installed
> DEBUG util.py:459:- conflicting requests
> DEBUG util.py:459:- nothing provides basesystem needed by 
> glibc-2.40.9000-35.fc42.aarch64 from build

Indeed. Apparently I was too hasty with the retirement. The package is
being unretired, so this be resolved soon.

Zlopez and yselkowitz: thanks for handling this and sorry for causing
the problem.

Zbyszek
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: retiring basesystem package

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

> On Fri, Feb 07, 2025 at 03:53:04PM +0100, Florian Weimer wrote:
>> glibc depends on basesystem:
>> 
>> Requires(pre): basesystem
>> Requires: basesystem
>> 
>> So the buildroot is currently broken.
>
> It shouldn't be. filesystem has 'Provides: basesystem'.
> Do you have more details about the issue?

The basesystem retirement was effective immediately, be for the new
filesystem build was tagged.

Thanks,
Florian

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Determining i686 "leaf" packages - python-cramjam dropped with i686 deps

[Ben Beasley]

It turns out that I didn’t make an error, per se: the version of 
python-pymongo that was actually built, 4.2.0, didn’t have a dependency 
on python3-snappy when I dropped i686 support in python-cramjam, and 
this is still the case in Rawhide today. No amount of careful checking 
would have allowed me learn about the new dependency on python3-snappy 
in the committed-but-not-built update to python-pymongo 4.9.1, since 
it’s not possible to query dependencies for packages that have never 
been built.


Still, it seems to be no great hardship to just re-enable i686 support 
in this case, 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 support 
in python-cramjam starting in Fedora 41.


The case of a package considering dropping i686 (python-cramjam) 
having an indirect dependency from another arched package 
(python-pymongo) via one or more noarch packages (python-snappy) is 
the hardest one to check for. It’s something that I know I need to 
look for, but it has to be done manually, and it’s easy to make a 
mistake.


Since python-cramjam 2.9.0 added a dependency on isa-l, which doesn’t 
support i686 at all, it’s not quite trivial for me to restore i686 
support in Fedora 41, but it looks like it will be possible:


https://src.fedoraproject.org/rpms/python-cramjam/pull-request/4

If you depend on python-cramjam, you should probably be aware of new, 
concerning test failures that have appeared with recent 
python-hypothesis versions in Fedora 42 and later:


https://github.com/milesgranger/cramjam/issues/201

After some consideration, I’ve decided to skip the affected tests for 
now because I don’t see any reason to believe there is a new problem 
in cramjam itself. There *might* be a newly-*revealed* problem, and 
I’m still not sure whether I should 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 i686 with this:

commit 3ebdbdac596b6f01c97b89d3b67635519b10b944
Author: Benjamin A. Beasley 
Date:   Mon Sep 30 19:24:11 2024 -0400

 F41+: Drop i686 support (leaf package on that architecture)

 While many packages depend on this one, we believe we have 
correctly
 verified that all directly or indirectly dependent packages 
either are

 noarch or already exclude i686.

However, we are now seeing a build failure on i686 for python-pymongo:

DEBUG util.py:459:  Problem: conflicting requests
DEBUG util.py:459:    - nothing provides python3.13dist(cramjam) 
needed by python3-snappy-0.7.2-4.fc42.noarch from build


So, apparently this determination was in error, or pymongo grew some 
deps.


At this point it would be nice to drop i686 from pymongo, but how can 
one make the determination that this is a "leaf" i686 package? 
Especially since it appears that some determinations of this were 
incorrect.



--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: retiring basesystem package

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

> Indeed. Apparently I was too hasty with the retirement. The package is
> being unretired, so this be resolved soon.

Do we need to add back the glibc dependency?

Thanks,
Florian

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue