devel May 2024

devel@lists.fedoraproject.org

180 participants
209 discussions

Heads up: planning to retire libgee06
by Michel Lind 13 Jun '24

13 Jun '24

Dear all, Just a heads up that the legacy libgee06 package is FTBFS for F40/F41: https://bugzilla.redhat.com/show_bug.cgi?id=2261317 and only has one dependent, libfep: ``` ❯ fedrq whatrequires libgee06-devel libfep-0.1.0-24.fc40.src ❯ fedrq whatrequires libgee06-devel -b f39 libfep-0.1.0-22.fc39.src ❯ fedrq whatrequires libfep-devel -b f39 ibus-fep-1.4.4-23.fc39.src libskk-1.0.4-12.fc39.src ``` Since libfep itself has dependents, I checked and it looks like it does not actually need libgee06 (or libgee) - or not anymore - and rebuilding it with the BR dropped succeeds with virtually the same Requires and Provides in the generated RPMs: https://src.fedoraproject.org/rpms/libfep/pull-request/1 I'm cc:ing the libfep maintainers; if I don't hear back in a few days I'll merge and build this and retire the package. Best regards, -- Michel Lind identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

2 1

libtiff-4.6.0-2.fc40 continues to ship old .so.5* libraries
by David Abdurachmanov 12 Jun '24

12 Jun '24

Andrea (in CC) recently pointed me to libtiff installation warnings on Fedora/RISCV side: [..] Installing : libtiff-4.6.0-2.fc40.riscv64 5/5 Running scriptlet: libtiff-4.6.0-2.fc40.riscv64 5/5 /usr/sbin/ldconfig: /lib64/lp64d/libtiffxx.so.5 is not a symbolic link /usr/sbin/ldconfig: /lib64/lp64d/libtiff.so.5 is not a symbolic link [..] 7 months ago libtiff was updated to 4.5.0 [0] with a bunch of CVEs listed in commit. This added: [..] # Copy old soname %{_libdir}/libtiff.so.5 # Copy old soname %{_libdir}/libtiffxx.so.5 cp %{_libdir}/libtiff.so.5* $RPM_BUILD_ROOT%{_libdir} cp %{_libdir}/libtiffxx.so.5* $RPM_BUILD_ROOT%{_libdir} [..] I assume this was added instead of doing a proper compat package before SOVERSION bump, or maybe one-time-thing for a side tag while everything gets rebuilt for a new libtiff. This is from Fedora Rawhide (today) after installing libtiff-0:4.6.0-2.fc40.x86_64 (via DNF). # readelf -p .note.package /usr/lib64/libtiff.so.5 String dump of section '.note.package': [ 4] | [ 8] ~^Z�DO [ 10] {"type":"rpm","name":"libtiff","version":"4.4.0-8.fc40","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:39"} This seems to come from 4.4.0-8.fc40. Random check suggests there are a bunch of CVEs with "LibTIFF 4.4.0" string. The old "*.so.5*" should be removed from this package, as we keep carrying them over to the next build. david - - - [0] https://src.fedoraproject.org/rpms/libtiff/c/cfa398260d7055fd80951b4c73d9b8…

3 4

Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
by Florian Festi 11 Jun '24

11 Jun '24

Hi everyone, RPM has deprecated the %patchN syntax in favor of %patch -PN where N is the patch number for a year now. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely in the upcoming RPM 4.20 release. As it will be added in Fedora soon [2] it is time to switch over to the new syntax now. There are around 1800 packages that still use the old syntax. Later this week/next week, we will run this script [3] over the affected packages [4][5] to update them to the modern patch syntax. For example, the script will change: %patch0 -p1 → %patch -P0 -p1 %patch0005 -p2 → %patch -P0005 -p2 If anyone has any objections or would like to exclude a package, please let me know. As this change does not affect the resulting binary packages an immediate rebuild is not needed. The change will "only" ensure the packages still build with the new version of RPM. This is the change with the highest compatibility (back to RPM 3.x). There are more modern options (like %autosetup) that packagers are encouraged to use but are out of scope here. Florian [1] https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1 [2] https://fedoraproject.org/wiki/Changes/RPM-4.20 [3] https://fedoraproject.org/wiki/File:User-Ffesti-new_patch_syntax.sh [4] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-packages.txt [5] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-package-owners.txt

13 25

Re: OCaml 5.2 rebuild
by Richard W.M. Jones 10 Jun '24

10 Jun '24

The OCaml 5.2 build is ongoing. flocq FTBFS on ppc64le (only) with a stack overflow: https://koji.fedoraproject.org/koji/buildinfo?buildID=2458620 I tried increasing the stack size in case it was just marginal, but to no effect. I have reserved a ppc64le system so I can take a look at this tomorrow. Let's see if I can at least get a stack trace. This unfortunately affects several other packages: - gappalib-coq - why3 - frama-c Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

2 3

[HEADS UP] Fedora 41 Python 3.13 rebuilds to start in a side tag (hopefully) next week
by Karolina Surma 10 Jun '24

10 Jun '24

Hello, To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.13 Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available. TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13. Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build <nvr> It takes time to build all the essential packages, so don't expect all your dependencies to be available right away. Any attempts to build your packages in the side tag before we do will likely fail due to missing dependencies. When in trouble, ask here or on Fedora's Matrix - Fedora Python room (https://matrix.to/#/#python:fedoraproject.org) Ping me (ksurma) or Miro (mhroncok) if you need to talk to us. Builds will appear here: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f41-python&order=… Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks! Karolina

6 11

pipenv removal in F40
by Mattia Verga 10 Jun '24

10 Jun '24

I vaguely remember that pipenv retirement was briefly discussed here on the ML, yet I was surprised that F40 doesn't have pipenv anymore. IMO, this would have been announced more prominently as a self contained change, as I expect more python developers to find out this too late. Also, the official guide on https://developer.fedoraproject.org/tech/languages/python/pipenv.html should have been updated as well. Mattia

4 4

FAS login not possible
by Marius Schwarz 05 Jun '24

05 Jun '24

Hi, ATM FAS Login is not possible. The ironic part is: you need to login to take part in the infrastructure ticket about not able to login ;) https://pagure.io/fedora-infrastructure/issue/11949 You get this message: "400 - Bad Request - Invalid transaction id" when you try to login via the website or api. Direct messages to "infrastructure(a)lists.fedoraproject.org" are also not possible, you need to be on the list to do that. best regards, Marius Schwarz

5 8

F35 Change: Debuginfod By Default (Self-Contained Change proposal)
by Ben Cotton 05 Jun '24

05 Jun '24

https://fedoraproject.org/wiki/Changes/DebuginfodByDefault == Summary == Fedora users / developers who need to debug/trace distro binaries can make use of the recently activated elfutils-debuginfod servers to automatically fetch debugging data and source code, instead of having to use `# sudo dnf` commands. == Owner == * Name: [[User:fche| Frank Ch. Eigler]] * Email: fche(a)redhat.com == Detailed Description == Numerous fedora debugging-type tools have built-in capabilities to use the [https://sourceware.org/elfutils/Debuginfod.html debuginfod] protocol to fetch debuginfo/source code automatically. We would like to activate a setting so that Fedora's debuginfod servers are automatically used, rather than requiring hand-editing individual users' dot files. == Feedback == There has existed [https://www.spinics.net/lists/fedora-devel/msg279002.html broad interest] in a Fedora debuginfod server since the project was proposed / announced in 2020, and several distros already operate public servers of this nature. Some of the distros configure their installations by default to talk to those servers, some do not. Turning on this by default has some limited privacy implications. Some Debian users have [https://lists.debian.org/debian-devel/2021/02/msg00262.html expressed concerns] that this facility "calls home" during debugging, so it may expose a limited amount of information about what a user is debugging. The information is limited to the build-id and source code file names of programs being debugged, and is only sent to the servers if their machine lacks locally installed debuginfo. Whether this should be opt-in or opt-out and how has been resolved there via an install-time query to the sysadmin. In contrast, on OpenSUSE Tumbleweed, it is [https://build.opensuse.org/request/show/879926 simply defaulted-on], and we have heard of no controversy. We anticipate discussing this topic on the mailing list, and noting it in the release notes either way. == Benefit to Fedora == This will improve developers' experience. It may reduce download server burden, as only individual ELF/DWARF/source files are downloaded rather than entire `-debuginfo` and `-debugsource` RPMs. It would help Fedora catch up to other distros who put up `debuginfod` servers already. :-) == Scope == * Proposal owners: The work could consist one extra parameter in the `elfutils.spec` `%configure`. Its effect is to arrange for the `elfutils-debuginfod-client` RPM to install an `/etc/profile.d` file that sets the `DEBUGINFOD_URLS` environment variable automatically to `https://debuginfod.fedoraproject.org/`. (At the time of this writing, the _staging_ server is getting ready for testing: `https://debuginfod.stg.fedoraproject.org/`.) * Other developers: None - relevant code has been previously upstreamed! * Release engineering: None - our team is operating the `debuginfod[.stg].fedoraproject.org` VMs. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == None. Note that these servers index all active Fedora releases (32-), all architectures, so users of those versions can already set `DEBUGINFOD_URLS` manually to take advantage. == How To Test == * Install `elfutils-debuginfod-client` * Open arbitrary fedora binary via gdb. ** Admire the immediate downloading of debuginfo and source code. * Run `eu-stack -v -p $pid` for an arbitrary process. ** Admire the immediate downloading of debuginfo to give precise file:line data. == User Experience == Primarily: users running debuggers, profilers, tracing tools on internet-capable machines can work immediately, without switching to privileged users and fragile manual `dnf` commands to install this data. == Dependencies == The `debuginfod` servers at `fedora-infra` need to be up. == Contingency Plan == * Contingency mechanism: change the elfutils-debuginfod-client subrpm to not set the default `DEBUGINFOD_URLS` environment variable for all users. In the case of a server outage, the debugger tools revert to debuginfo-less operation, prior to this feature. * Contingency deadline: shortly before freeze * Blocks release? No == Documentation == There is upstream documentation in the debugging tools as well as associated with the client code / cli tooling. What our Release Notes would focus on however is the _automatic activation_ of this facility via the environment variable. == Release Notes == TBD. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

16 43

soname bump: mupdf 1.24.2 coming to rawhide and F40
by Michael J Gruber 03 Jun '24

03 Jun '24

Hi there mupdf 1.24.x release branch received another mostly bugfix release which bumped soname nonetheless. Fixes are confirmed good to go for rawhide and F40. I built mupdf in a side-tag, will rebuild dependencies myself or via PRs (qpdfview). Note: Since this necessitates a rebuild of zathura-pdf-mupdf and there are pending updates for the girara-zathura ecosystem (on which zathura-pdf-mupdf depends) I'll use one side-tag for all of these (coordinated with respective maintainers) to reduce update churn. Michael f41-build-side-90203 f40-build-side-90205

2 3

[Fedocal] Reminder meeting : ELN SIG
by sgallagh＠redhat.com 03 Jun '24

03 Jun '24

Dear all, You are kindly invited to the meeting: ELN SIG on 2024-05-31 from 12:00:00 to 13:00:00 US/Eastern At fedora-meeting(a)irc.libera.chat The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/10568/

5 8

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel May 2024