devel July 2023

devel@lists.fedoraproject.org

210 participants
230 discussions

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

Documentation for F15's "Remove SETUID" Change?
by Michel Alexandre Salim 18 Nov '23

18 Nov '23

Hi all, The subject of setuid came up in a private conversation recently, and to my surprise we don't seem to have it documented in the packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/ Per https://fedoraproject.org/wiki/Features/RemoveSETUID#Documentation "We should change documentation on packaging guidelines to talk about using file capabilities." but the only mention of capabilities seem to be that, if you use it or suid, PIE must be enabled: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie Should this be documented somewhere, or if it's there but it's lost in the wiki->docs migration, does anyone know where the documentation is? Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

4 4

F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
by Ben Cotton 24 Oct '23

24 Oct '23

https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted. == Owner == * Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl == Detailed Description == {{admon/note|Brief reminder about rpmautospec| The spec file contains: <pre> Version: 1.2.3 Release: %autorelease ... %changelog %autochangelog </pre> Rpmautospec uses git history. Whenever the package is built (`.src.rpm` is generated), rpmautospec tooling will replace the `%autorelease` macro with the number of commits since the last commit that changed the `Version` field, and the `%autochangelog` macro with a text generated from `git log`. For details see the [https://docs.pagure.org/fedora-infra.rpmautospec/principle.html docs]. }} Rpmautospec has been deployed in Fedora since F35 ([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%). But it is still a "second-class citizen": most documentation doesn't mention it, and many packagers know that it exists but don't use it in their packages. We think that it's reasonable to switch to `%autorelease`+`%autochangelog` for almost all packages and that Packaging Guidelines and various packaging howtos should recommend that approach to packagers. The "traditional" approach of manually-managed `Release` and `%changelog` will remain valid and will be documented as a fallback. This change is targeted at Fedora 38, but it will actually apply to all releases. The goal is to update the Packaging Guidelines and other prominent documentation and tools now, and other docs and tools possibly at a later time. Changing packages is out of scope. It is worth mentioning that `rust2rpm` uses `%autorelease`+`%autochangelog` since a few releases, so most rust packages have switched. (Generally, rust spec files are recreated using the generator for each new version, so the switch would happen whenever a new version is packaged unless the packager opts out.) == Feedback == * Thread on fedora-devel in August 2022: [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… rpmautospec by default] ** open issues: a bunch have been fixed. ** maintenance: Nils will add some co-maintainers. ** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see Scope section. == Benefit to Fedora == Various packaging workflows become smoother for packagers and contributors: * packagers don't need to touch the `Release` field on updates * packagers describe changes just once in the git commit message, the `%changelog` entry is autogenerated * patches to the spec file can be cherry-picked between branches without trivial conflicts * pull requests on src.fedoraproject.org can be merged without trivial conflicts * in workflows that regenerate the spec file (rust2rpm, pip2rpm, …) `%changelog` section doesn't need to be copied over == Scope == * Proposal owners: ** provide pull requests to Packaging Guidelines and other docs to make `%autorelease`+`%autochangelog` the default ** implement fixes for issues reported by packagers ** make semi-regular releases of rpmautospec ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… 0.3.1 was released on November 17th, and should be deployed to production in about two weeks]) * Other developers: ** provide pull requests to other docs as appropriate ** accept the changes to documentation ** update other spec file generators (pip2rpm, others?) * Somebody (TBD): ** `fedora-review` — https://pagure.io/rpkg/issue/641 ** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the command will fail. A replacement workflow that instead restores `%autorelease`+`%autochangelog` in the file committed to dist-git needs to be implemented. * Related work ** https://pagure.io/rpkg/c/3087dd7 ** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4 * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: a list of places to be updated ** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs ** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning ** https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial… * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Rpmautospec is already used by a decent number of packages, so any issues are already being seen and need to be fixed anyway. == How To Test == * Convert an existing package: `rpmautospec convert`. Ideally this step is done right before a version bump so that the release numbers restart at `-1`. * Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify correctness of version-release (`rpm -qpi`) and the changelog (`rpm -qp --changelog`). * Do builds in koji. Verify correctness of version-release and the changelog. * For new packages, use `%autorelease`+`%autochangelog`. Repeat all the tests listed above. * Assume you are a newbie packager. Read the packaging docs and check that the workflow is clear and the intructions are sufficient to use rpmautospec tooling correctly. == User Experience == No changes visible to end users. == Dependencies == None. == Contingency Plan == If it turns out that the rpmautospec workflows have unknown problems, we can revert changes to documentation. * Contingency mechanism: Revert changes to documentation by reverting the appropriate commits. This can be done easily by FPC. * Contingency deadline: Any time. * Blocks release? No. == Documentation == This page and any changes to Packaging Guidelines and other documents. == Release Notes == Not needed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

32 95

F39 Change Proposal: Allow Removal of tzdata (System-Wide)
by Aoife Moloney 27 Sep '23

27 Sep '23

https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Allow the removal of tzdata especially on containers in order to minimize size. == Owner == * Name: Patsy Griffin (Franklin) * Email: patsy(a)redhat.com == Detailed Description == This change will allow the removal of tzdata. When tzdata is removed, the system will default to UTC. In order to reduce overhead, many container installations now remove the data associated with tzdata but cannot fully remove the package due to dependencies by other packages. This results in confusion regarding the expected timezone info. In order for this to work, we need packages that use tzdata at run time to switch from Require'ing tzdata to Recommend'ing tzdata. These packages should also gracefully handle instances where tzdata has been removed. For example, this would require recognizing that tzdata is not present and providing an appropriate error, such as recommending that the user install tzdata. == Feedback == In June of 2021, we proposed creating a new tzdata sub-package that would only provide the UTC timezone. As part of the discussion around this proposal, it was recommended that we completely remove tzdata. We appreciated this input and welcome additional feedback. == Benefit to Fedora == This change will allow tzdata to be removed from containers without leaving inconsistent package remnants. == Scope == * Proposal owners: No changes are needed to tzdata. * Other developers: Some packages need to change their spec files from `Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if all packages switched in this way, but it is not required. Supporting optional tzdata installation for as many workloads as possible allows those workloads to minimize their container image size. List of packages which need to be changed: * glibc (glibc-common) * gcc (libstdc++) * python3.XX (3.9, 3.10, 3.11, 3.12) List of packages which would be beneficial to be changed: * python3-dateutil * python3-pytz * libical Upon acceptance of the change request we will file bugs to fix each of these packages for Fedora 39. * Release engineering: No changes needed. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == If tzdata is already installed, then it continues to be installed on the system. Following the Fedora Weak Dependencies Policy dnf will treat the Recommends on tzdata as if it were a Requires and tzdata will always be installed in a default system (https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/) However, the recommends will allow tzdata to be correctly uninstalled in a container build file rather than having to use ‘rm -rf’ to delete the zone files to recover space. == How To Test == Language runtimes were installed and A/B tests carried out with tzdata present and tzdata removed. The intent of these tests was to ensure that the system can use the language frameworks without tzdata present and that when the data was required that meaningful errors were presented to the user. Packages tested were C (glibc), C++ (libstdc++), Python (Python 3.11), using their time and date APIs. This testing led to the correction of the libstdc++ implementation as noted here: https://gcc.gnu.org/cgit/gcc/commit/?id=4abd5bc600193e821fbc41995a0b8d9ea42… Developers can test this by installing Rawhide and uninstalling tzdata and verifying their package operates as expected. If tzdata cannot be uninstalled then we recommend filling a bug against the package that Requires: tzdata and having a discussion with the maintainer to make tzdata optional e.g. Recommends: tzdata. == User Experience == The user can remove tzdata to minimize the container size. With tzdata removed the system is UTC only. == Dependencies == Fixing glibc, gcc, and python3.xx at a minimum to make tzdata Recommends instead of Requires. == Contingency Plan == * Contingency mechanism: Back out the change. Don’t do it. * Contingency deadline: Can be backed out at the last minute since we are only dealing with conversions from Requires to Recommends. * Blocks release? No == Documentation == Document that the tzdata package may be removed if needed to reduce space on containers. With tzdata removed, the system will default to UTC. == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

17 41

Potential changes to systemd RPM macros
by Andrea Bolognani 12 Sep '23

12 Sep '23

Hi, this requires a bit of background, so please bear with me :) Earlier this year, the libvirt project changed its RPM package to be more granular[1] as a step towards a future where the legacy monolithic daemon (libvirtd) is completely gone. This change has happened upstream, but the Fedora package uses the same spec file so it was quickly reflected in Rawhide. As part of this change virtproxyd, a service which has historically been part of the libvirt-daemon package, has been moved to the newly-introduced libvirt-daemon-proxy package. More recently we have realized that, despite our care in trying to ensure smooth upgrades, splitting the package this way has unfortunately caused unintended consequences[2][3]. Specifically, since the libvirt-daemon-proxy package is a completely new one as far as RPM is concerned, all its systemd units will get presets applied during %post. In at least two completely valid deployment scenarios, this results in some amount of brokenness due to local configuration changes made by the admin getting discarded. In order to avoid this problem, I have implemented a new set of RPM macros[4][5] that base the decision of whether presets should be applied for a systemd unit not on whether the package that contains them is being newly installed, but rather on whether the unit itself existed on the system before package installation. This should address not only the scenario of services being split off to separate packages, but also the one where an existing package starts shipping additional services. Now, since this is clearly not a libvirt-specific issue, I believe this approach should be adopted across Fedora by way of these macros (or comparable ones) being added to systemd. Packages would have to migrate from the old macros over time, and at some point it should be possible to get rid of them entirely. Note that openSUSE already has its own distro-specific RPM macros for dealing with systemd units, and in fact the approach that I have implemented is partially inspired by theirs. Ideally, we'd be able to collaborate with them to create a single set of macros that lives in systemd and satisfies the needs of both Fedora and openSUSE. The problem is that Fedora 39 and RHEL 9.3 are fast approaching and, if we don't do anything about this issue before then, a subset of libvirt users will see their deployments broken after upgrade. In the interest of avoiding that, I would prefer to get the libvirt-specific version of the macros merged as soon as possible, and focus on upstreaming the work all the way to systemd as a follow-up. Does this plan sound reasonable to the Fedora community? Are there any serious concerns regarding the approach taken for the macros that would cause them to be considered a complete no-go? Any scenarios that I might have missed while implementing them? Thanks for your patience in reading this far :) and looking forward to your feedback! [1] https://listman.redhat.com/archives/libvir-list/2023-January/237059.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=2210058 [3] https://listman.redhat.com/archives/libvir-list/2023-June/240226.html [4] https://listman.redhat.com/archives/libvir-list/2023-July/240723.html [5] https://listman.redhat.com/archives/libvir-list/2023-July/240729.html -- Andrea Bolognani / Red Hat / Virtualization

3 12

Re: TSS maintainer volunteer
by Petr Pisar 08 Sep '23

08 Sep '23

V Thu, Feb 16, 2023 at 07:29:07PM +0000, Kenneth Goldman napsal(a): > I think I followed all those steps - identifying the package, announcing that > I want to be the packager, making an account, etc. > > What's next? Submit an updated tss2 package for a package review. As far as I can see, there is no review opened for tss2 now <https://bugzilla.redhat.com/buglist.cgi?component=Package%20Review&product=…>. How to do it is described at <https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Pro…>. Especially pay attention to: If you are not member of the packager group, you need a sponsor. Add FE-NEEDSPONSOR to the bugs being blocked by your review request. > Does someone approve me? Based on the FE-NEEDSPONSOR blocker someone from sponsors should notice your review request and start to communicate with you in the review request in Bugzilla. (If that does not happen, approach you a sponsor of your choice as recommended at <https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsor…>) Once the sponsor finds your package looks good and you understand how to maintain a package, he/she will sponsor you, i.e. adds you into a packagers group. Then you will be able to continue from this item on the Package_Review_Process document: When your package passes the review you should use fedpkg to request a Git repository for it. > Move a git repo somewhere? For the purpose of the package review, you need to publish the spec file and the SRPM file somewhere on the Internet. (Once you become a packager, you can also use <https://fedorapeople.org/> server for that purpose.) Once the package review passes, the offical git repository (called dist-git in Fedora) for the tss2 package will be reopened with completing this item: Request a Git repository for the package Then you will commit the new spec file into the reopen dist-git repository. -- Petr

3 3

Bootstrapping package with circular dependencies in koji
by Jaroslav Skarvada 08 Sep '23

08 Sep '23

Hi, I need to bootstrap package which has bootstrap support written according to the [1]. I am able to bootstrap it locally (rpmbuild, mock, ...) with the "--with bootstrap" or "-D '_with_bootstrap 1'". Is there support for it in koji? E.g. something like: koji build SIDE-TAG PACKAGE --bootstrap? Or do I have to manually do: 1. patch: - %bcond_with bootstrap + %bcond_without bootstrap 2. koji build SIDE-TAG SCM 3. update&build the circular dep 4. unpatch: - %bcond_without bootstrap + %bcond_with bootstrap 5. release bump 6. koji build SIDE-TAG SCM Or is there some better way? thanks & regards Jaroslav [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping

8 19

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