devel May 2022

devel@lists.fedoraproject.org

172 participants
319 discussions

dnf "no match for group package" on upgrade...
by Matthew Miller 02 Jun '25

02 Jun '25

I'm seeing a number of people confused by this message, usually followed by some actual transaction error. I _think_ this is happening because these packages are in comps but do not exist in the distro. Is this correct? I tried to search for it, but the error message is _very_ common in ... well, people who are asking about it because of what I said. (For example: https://unix.stackexchange.com/q/542877/2511) I found https://bugzilla.redhat.com/show_bug.cgi?id=1538346 but not much of a general resolution. It does note that one issue is arch-specific packages (which maybe just need "arch=..." in comps?). I think we should: 1. Have a schedule standarded task to remove any packages listed but non-existent after branch from rawhide. (I assume a Rel-Eng task?) 2. Have DNF make this message less scary. Maybe even move down to a debug message and not show it by default — I am not seeing a situation where they're useful to _most_ end-users. Anything I'm missing? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

5 5

Orphaned magic-wormhole + its python deps
by Fabio Valentini 21 Jan '25

21 Jan '25

Hi everyone, I have just orphaned magic-wormhole (the original one written in Python) and its dependencies. I no longer use it, I have no time to fix the packages for new Python versions, and upstream is pretty much dead since they started porting the project to Rust. - python-magic-wormhole - python-magic-wormhole-mailbox-server - python-magic-wormhole-transit-relay - python-txtorcon - python-spake2 - python-hkdf There is an alternative Go implementation of the "Wormhole Protocol" (wormhole-william), for which eclipseo already submitted a review request. It seems to be better maintained than the Python original, if we want to have a Wormhole client in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1922806 The official port of magic-wormhole to Rust also seems to be progressing, we might want to package that one instead once it's released: https://github.com/magic-wormhole/magic-wormhole.rs Fabio

4 6

Intel's Clear Linux optimizations
by František Zatloukal 21 Nov '24

21 Nov '24

Hi, Phoronix recently release article[1] about Intel's Clear Linux with some cool graphs showing nice performance gain compared to Xubuntu. I didn't have time to dig in and look how it's performing against Fedora, but I'd assume Fedora can be compared to Xubuntu in terms of compiler settings. I think i'll be interesting to look into it and find out if Fedora can't tweak compiler settings (eg use LTO for critical things like Mesa, Kernel, ...). I think it could be interesting fo Fedora users to have this enabled if there are not any disadvantages other than compile time, compile memory usage and so on. What do you think? [1] http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1 -- Best regards / S pozdravem, František Zatloukal Project Coordinator Red Hat

15 50

Packaging Guidelines for Applications using Git Submodules
by Gerald B. Cox 12 Nov '24

12 Nov '24

I'm trying to figure out the best way to handle the situation where a project decides to use submodules in Git. The archive generated doesn't incorporate the submodule files. I've done some searching on this, and haven't really come up with much. I've reviewed: Packaging:Github <https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#G…> ; but that really doesn't address the submodule issue. I looked through some packages that are currently in the Fedora repository and found where a few folks have rebuilt the tarball and referenced that version as the Source in the spec file; then they put in a comment stating: The source of this package was pulled from upstreams' vcs. Use the following commands to generate the tarball: ... - git clone ... - git submodule init - git submodule update ... This approach is the best that I've found. Any other suggestions? Thanks much!

8 11

Applications with AppData and not visible in the software center
by Richard Hughes 14 Oct '24

14 Oct '24

We've been looking at the AppStream extractor issues in Fedora, and we've come across a few broken applications. Broken apps are not visible in the application installer. The apps include: * albumart * apitrace-gui * appstream * asylum * audience * bomber * bovo * calligra-braindump * cervisia * choqok * classified-ads * crrcsim * cube * curblaster * dsi * escape * ettercap * font-manager * freedink-engine * gap-core * gnofract4d * gvrng * hgview * hyperrogue * kaddressbook * key-mon * kgraphviewer * knotes * konqueror * LabPlot * nextcloud-client (maybe fixed in distgit) * openms * openvibe * owncloud-client * pingus * pioneer * portecle * qdigidoc * qjackctl * qsynth * qtikz * recoll * renku * rodent * screengrab * screenruler * simple-ccsm * slashem * spectacle * speed-dreams * tennix * tilp2 * tortoisehg * trophy * tzclock * uzbl-defaults * vdrift * vegastrike * wireshark-gtk * xfce4-power-manager * xfpanel-switch * xskat * yakuake * zanshin * zathura The full list, along with what failed is available here: https://dl.fedoraproject.org/pub/alt/screenshots/f26/failed.html If you want any suggestions or advice, I'm happy to help. Most of the failures are pretty self explanatory, e.g. "No <summary> in AppData" or "icon was too small 24x24" -- our guidelines are here: https://github.com/hughsie/appstream-glib/blob/master/README.md#guidelines-… As a reminder, you can validate AppData files using: appstream-util validate-relax file.appdata.xml Thanks, and comments welcome. I can set up a script that sends email to the package maintainer if this would be helpful, but I thought we might be able to get the majority of these sorted with this email. Richard.

8 14

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

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

Jump to page:

2025

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 2022