devel March 2024

devel@lists.fedoraproject.org

148 participants
212 discussions

Execute RPM dependency generators on the .spec file which ships them
by Vít Ondruch 27 Sep '24

27 Sep '24

I am still playing with idea of executing RPM dependency generators on the .spec file which ships them. I have created RPM RFE ticket quite a while ago here: https://github.com/rpm-software-management/rpm/issues/782 So for no luck with having this implemented. However, I think there is reasonable way. It would be enough to have some generic attr file around. I have create small test package exploring this idea and you can find it in my Copr repo: https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/ https://copr-dist-git.fedorainfracloud.org/cgit/vondruch/rpm-local-generato… On the same place, you can also find package leveraging this concept: https://copr-dist-git.fedorainfracloud.org/cgit/vondruch/rpm-local-generato… Would somebody else benefit from this idea/package or can somebody spot some issue with it? Thx for feedback. Vít

5 13

Heads-up: llhttp 9.0.1 coming to Rawhide
by Ben Beasley 19 Aug '24

19 Aug '24

In one week, 2023-08-29, I plan to update llhttp from 8.1.1 to 9.0.1 in F40/Rawhide[1]. This update contains some breaking API changes and breaks the ABI, bumping the SONAME version[2][3]. Most significantly, the compile-time LLHTTP_STRICT_MODE option is replaced with three new runtime flags. The sole dependent package is python-aiohttp; I will rebuild it myself in a side tag, using a patch for llhttp 9.x support backported from an unreleased upstream commit[4]. I don’t plan to apply the python-aiohttp patch and the llhttp 9.0.1 update to F39 at this time, with the understanding that this will constrain future python-aiohttp updates in F39: I would prefer to avoid getting ahead of upstream. I might reconsider this if an upstream release of python-aiohttp using llhttp 9.x happens by the end of the beta freeze, or if someone convinces me that keeping llhttp at 8.1.1 is the wrong approach. Input is welcome. [1] https://src.fedoraproject.org/rpms/llhttp/pull-request/15 [2] https://github.com/nodejs/llhttp/releases/tag/release%2Fv9.0.0 [3] https://github.com/nodejs/llhttp/releases/tag/release%2Fv9.0.1 [4] https://src.fedoraproject.org/rpms/python-aiohttp/pull-request/27

1 1

Porting Fedora for the LoongArch architecture.
by 孙海勇 17 Aug '24

17 Aug '24

Hi everyone, I am Sun Haiyong, from China. I want to port Fedora for the LoongArch architecture. LoongArch is a RISC ISA released by Loongson Technology Corporation Limited, and has supported a series of (Binutils, GCC, Linux, Glibc, LLVM, QEMU, etc.) core open source projects. Currently, there are many linux distributions that can run on LoongArch machines, they are OpenEuler, OpenAnolis, UOS, Kylin. I am good at cross-compiling operating systems and often build Linux systems using something like LFS or CLFS. I have built Linux distributions using rpm package management from scratch several times since 2015 (some systems are not publicly available): 1 Fedora 21, 28, 32 based on MIPS64EL architecture; 2 CentOS 7 based on MIPS64EL architecture; 3 CentOS 7 based on Power8 architecture; 4 CentOS 8.3 based on LoongArch architecture; 5 OpenEuler 2109 based on LoongArch architecture. And I have published a book on porting Fedora systems to new architectures. I want to add LoongArch to the official Fedora support architecture, and I've been doing so for some time, here's some of what I've done so far： To verify the feasibility of building a LoongArch architecture branch for Fedora, I have used the software version from the rawhide git repository, and have now compiled a large number of base packages and built a temporary repository that can be accessed at https://mirrors.wsyu.edu.cn/fedora/ I have compiled and generated more than 45,000 installable rpm files (of course there are a lot of perl, Python, rust and texlive files), and the number is still expanding, the scope of the package is enough to build a LiveCD system, for which I have built LXDE, MATE, WorkStation ( Gnome3) of the LiveCD and the installation of the ISO, you can get in the following address: https://github.com/fedora-remix-loongarch/releases-info Of course, there are still a lot of problems with LoongArch's Fedora system, for example, some software is not yet fully supported by the upstream community, but I believe the power of the community can gradually improve them, so I am sending out an email here to get more people to support this new LoongArch architecture. I have recruited some developers who are interested in this and they are： Wu Xiaotian Chen Huacai Shi Pujin Si Yanteng Chen Feiyang Of course, there are many other users who are interested in Fedora systems. I'm currently a newbie in the Fedora community, so I need help from community developers, and would like someone to guide me on what to do next, such as what would be a better time to submit necessary patches to packages in the Fedora repository, how to develop in a collaborative manner, what other systems to be used for management, etc. In short, any information would be useful. Could I get help here? :) Again, thanks for reading this email. Best Regards Sun Haiyong

12 18

sysusers scriptlets: what to do if upstream includes the config files?
by Adam Williamson 26 Jul '24

26 Jul '24

The guidelines for sysusers packaging: https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_… say: "Create a <package-name>.sysusers file with the user definition and add it to the specfile as a source...use the %sysusers_create_compat macro to consume it in the %pre section: %pre %sysusers_create_compat %{SOURCE3} " but...what are you supposed to do if *upstream* ships the config files? openQA recently added these to its upstream distribution, so it seems wrong to replace the config files upstream ships with ones separately packaged downstream. But if I don't package them as source files, how can I set up the %pre macro? I tried this: %pre %sysusers_create_compat usr/lib/sysusers.d/geekotest.conf where usr/lib/sysusers.d/geekotest.conf is the path to one of the sysusers config file within the upstream source, but it doesn't seem to work. The built package has no %pre script. However, that does work if I eval it locally from an openQA source tree: [adamw@xps13k openQA (master %)]$ rpm --eval "%sysusers_create_compat usr/lib/sysusers.d/geekotest.conf" # generated from geekotest.conf getent group 'geekotest' >/dev/null || groupadd -r 'geekotest' ...etc... so...help? Is there any way to make this work right? Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

8 9

Why branched config pointed to rolling config?
by Mikhail Gavrilov 16 Jul '24

16 Jul '24

Why branched config pointed to rolling config? # ls -ln | grep fedora-40 lrwxrwxrwx. 1 0 135 26 Jan 11 20:46 fedora-40-aarch64.cfg -> fedora-rawhide-aarch64.cfg lrwxrwxrwx. 1 0 135 23 Jan 11 20:46 fedora-40-i386.cfg -> fedora-rawhide-i386.cfg lrwxrwxrwx. 1 0 135 26 Jan 11 20:46 fedora-40-ppc64le.cfg -> fedora-rawhide-ppc64le.cfg lrwxrwxrwx. 1 0 135 24 Jan 11 20:46 fedora-40-s390x.cfg -> fedora-rawhide-s390x.cfg lrwxrwxrwx. 1 0 135 25 Jan 11 20:46 fedora-40-x86_64.cfg -> fedora-rawhide-x86_64.cfg I build every day mesa snapshot, but today `mock -r fedora-rawhide-i386 ...` beginning create packages of 41 branch. And I can't fix it by `mock -r fedora-40-i386 ...` because 40 means rawhide now :(

2 1

Enabling GOPROXY and GOSUMDB in Fedora
by Alejandro Saez Morollon 14 Jul '24

14 Jul '24

Hi everyone. TL;DR: Remove a patch we ship in Go that disables GOPROXY and GOSUMDB and follow upstream defaults, or keep it? Recently, I had a short conversation in a public forum about two Go features that we modified in Fedora. GOPROXY and GOSUMDB. As I prepare the Fedora 40 and Go 1.22 proposal, it is a great time to discuss it. You can see the conversation here, I think they bring really good points that we should consider: https://mas.to/@zekjur/111359951465906642 So first, what are these variables? - GOPROXY sets the server for fetching module-related information and dependencies. - GOSUMDB sets the checksum database URL to verify module downloads and ensure their integrity during module resolution. You can read them more in detail here: - https://go.dev/ref/mod#environment-variables - https://go.dev/ref/mod#authenticating - https://go.dev/ref/mod#module-proxy There are four approaches as I see this: 1. Keep it the way it is right now. 2. Remove the patch and follow upstream. 3. Create a way to ensure the users know that that option can be changed and leave one of the two previous options as default (by creating two packages, one with the default setting and another that applies the patch). 4. Have a GOPROXY service by Fedora. 1 and 2 are the easiest and most logical ones. 3rd is complex, and I'm not sure it brings any value. 4th would be ideal, but that means maintaining a service with all its costs and time.

10 12

Does ccache ever help with kernel mock build?
by Julian Sikorski 29 Jun '24

29 Jun '24

Hello, has anyone successfully managed to get ccache to speed up kernel mockbuilds, be it SRPMS from kernel-ark or from dist-git? I gave it a brief shot but saw no difference, if anything the build was slower. The machine I am building on has 32 GB RAM which is not quite enough to fit everything on a ramdisk, and the drive I am building to is an NVME SSD, "only" PCI Express 3.0. CPU is a Ryzen 5 5600x. A baseonly builds takes about 25 minutes, which is somewhat annoying when one has to bisect something. If ccache can speed this up, how big does it need to be? I understand the default 4 GB is nowhere near enough but what would be needed to actually help? Thanks! Best regards, Julian

3 11

Remove old GPG keys?
by Miroslav Suchý 25 Jun '24

25 Jun '24

I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remov… with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from… And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys? Mirek

16 30

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

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

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 March 2024