devel June 2023

devel@lists.fedoraproject.org

202 participants
202 discussions

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

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

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

future of dual booting Windows and Fedora, redux
by Chris Murphy 29 May '24

29 May '24

Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result: 1. Fedora's installer, Anaconda, can't resize Bitlocker volumes. We could use better documentation to help the user perform the volume resize in Windows, before proceeding to booting our installation media. The documentation probably should be explicitly referenced by the Windows version of Fedora Media Writer. 2. The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR. When shim+GRUB are in the boot chain, as is the case in our default dual boot installation, the measurements are wrong, and this means the GRUB menu entry to boot Windows won't work. The user is dropped to a Windows Bitlocker recovery page. If they have their backup encryption key handy, it will work but to say the least this condition is unexpected and not user friendly - not least of which is many users won't have this backup key handy since they didn't take the action to enable Bitlocker in the first place. The bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=2049849 It was a Fedora 36 final release blocking bug, but considered a "difficult to fix" exceptional case, moving it to Fedora 37 final. Some of the options for consideration: a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it. b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader. And also remove the Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.) c. Change the release criterion. https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dua… Current: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora. Replacement: The installer must be able to install into free space alongside an existing clean Windows installation, install and configure a bootloader that will boot Fedora. d. Consider the problem sufficiently difficult to fix that we need an extension to the exceptional case allowance, and wave the bug for another release. Thoughts? -- Chris Murphy

29 93

Golang bundled() Provides generator
by Maxwell G 02 Apr '24

02 Apr '24

Hi Fedorians, A recent PR reminded me that I never properly announced the new (well, four months old) bundled() Provides generator for Golang projects[1]. This can be used to simplify generating these Provides when bundling is justified in Fedora[2] or for (EP)EL. Simply mark the vendor/modules.txt file generated by `go mod vendor` with `%license` and the generator will take care of the rest. This removes the need for long lists of Provides that clutter specfiles and have to be updated after each upstream release. It's up to package maintainers to inspect the Provides for correctness when opting in to this generator. Please let us know if you find any bugs. The generator is available in all Fedora branches and on EPEL 9 (part of go-rpm-macros-epel that shadows RHEL's go-rpm-macros). go-rpm-macros has been updated in c9s, so I'll remove the generator from go-rpm-macros-epel when the next RHEL 9 minor release comes out. [1]: https://pagure.io/go-rpm-macros/c/226596177c63c3dc180b5aeda45fe3b18706e877?… and https://pagure.io/go-rpm-macros/c/c32fbbd25bbcedee8c0b898d3653255b18a0d30e?… [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundled_… -- Maxwell G (@gotmax23) Pronouns: He/Him/His

3 2

some man pages have bugs, can't be grep'd
by Chris Murphy 27 Mar '24

27 Mar '24

I've been seeing this since clean installing Fedora 30. I don't recall ever seeing it before, including on a Fedora 29 -> Fedora 30 upgraded system (is now the clean installed system). [chris@flap ~]$ man rpm | grep -C 10 rpmverbosity <standard input>:176: warning [p 3, 0.8i]: cannot adjust line [chris@flap mantest]$ man rpm >rpm.stdout 2>rpm.stderr [chris@flap mantest]$ ll -rw-rw-r--. 1 chris chris 62 Jul 16 14:24 rpm.stderr -rw-rw-r--. 1 chris chris 28498 Jul 16 14:24 rpm.stdout Is this a bug that should be reported against rpm or something else? I'm certain I've seen it in other man pages, but offhand I can't find another example. -- Chris Murphy

4 6

Unretire ulogd (or another NFLOG logger?)
by Chris Adams 21 Feb '24

21 Feb '24

I'd like to use NFLOG to log firewall drops (so that the kernel message log isn't spammed by them), but it doesn't appear there's anything currently in Fedora that can read that other than "tcpdump -i nflog". It looks like ulogd was retired a while back because it only had a SysV init script and nobody stepped up to convert it to systemd (which should be really simple, since the old init script is pretty much a textbook template of a SysV init script). Am I missing anything? Is that all it needs? Is there another NFLOG logger daemon? -- Chris Adams <linux(a)cmadams.net>

2 1

fedrq - new repoquerying tool
by Maxwell G 08 Feb '24

08 Feb '24

Hi Fedorians, I've been working on a repoquerying tool called fedrq [1] that I'd like to share with you. Here's the elevator pitch: fedrq provides a friendly interface to query the Fedora repositories. It makes it really easy to query across Fedora and EPEL branches. It uses the dnf Python bindings (libdnf5 backend is almost done) and doesn't shell out to dnf repoquery. Amongst other things, fedrq allows querying for reverse dependencies, packages that contain a certain Provide or file, subpackages of an SRPM, and general package metadata. My favorite features are the easy branch switching, `fedrq subpkgs` (there's no real equivalent in dnf repoquery), and the ability to dump package metadata as JSON. The many threads about how to properly query for dependencies when doing SO name bump rebuilds and my own frustrations with dnf repoquery inspired this tool. You can install fedrq from PyPI or from gotmax23/fedrq [2] on Copr. The EXAMPLES section of fedrq(1) [3] provides a good intro and demonstration of fedrq's functionality. The tool is very much a WIP and any feedback is appreciated. For reverse dependency rebuilds, you probably want the following command: ``` $ fedrq whatrequires -X -F source $(fedrq subpkgs SRCNAME) # equivalent $ fedrq subpkgs SRCNAME | fedrq whatrequires -X -i -F source # equivalent ``` This accounts for any package that depends on any subpackage/binary RPM produced by SRCNAME at buildtime and/or runtime, and spits out the names of the source packages that need to be rebuilt. For simple packages that output only one RPM, `fedrq whatrequires -F source PKGNAME` is sufficient. [1] https://sr.ht/~gotmax23/fedrq/ [2] https://copr.fedorainfracloud.org/coprs/gotmax23/fedrq/ [3] https://gotmax23.srht.site/fedrq/fedrq.1.html#EXAMPLES -- Thanks, Maxwell G (@gotmax23) Pronouns: He/They

6 13

Co-maintainers for my ham packages
by Matt Domsch 23 Nov '23

23 Nov '23

Due to an impending move to NYC and related downsizing of my house into a 2-bedroom apartment, I'm selling all my ham radio gear. Therefore I won't be able to test any of the Fedora packages I maintain with actual hardware. Would anyone be interested in maintaining or co-maintaining these? - direwolf - Sound Card-based AX.25 TNC - CubicSDR - Cross-Platform Software-Defined Radio Panadapter - liquid-dsp - Digital Signal Processing Library for Software-Defined Radios - sdrpp - SDRPlusPlus bloat-free SDR receiver software - SoapySDR - A Vendor Neutral and Platform Independent SDR Support Library - soapy-rtlsdr - SoapySDR module for RTL-SDR hardware Thanks, Matt N5MLD

3 5

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 June 2023