devel May 2023

devel@lists.fedoraproject.org

172 participants
231 discussions

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 22 Nov '23

22 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

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

CVE: Python-twisted a.o. needs update for F37 due to matrix-synapse security issue
by Marius Schwarz 31 Aug '23

31 Aug '23

Hi, due to an outdated(afaik) python-twisted version, it's not possible to build matrix-synapse in version 1.8x . Unlucky for all F37 users, matrix-synpase has 3 embargoed CVEs coming, which need fixing asap. As "releng" has shipped the last twisted update, I have no clue who could help here on the python side and upgrade the packages. Kai Hiller tries to cherry pick the required patches for synapse, but it would of course be better to build the newest synapse version for F37 too. ATM we can only workaround this by using the f38 packages for synapse and it's dependencies. AFAICT it's works without issues atm. This brings me to the question: whats the main issue for twisted here? best regards, Marius Schwarz

3 3

Intern Introduction & Goals (Open 3D Engine)
by Nicholas Frizzell 30 Aug '23

30 Aug '23

Hello, My name is Nicholas and I'm working this summer as an intern with Red Hat. My primary objective this summer is to improve support for the O3DE project (https://www.o3de.org/) in Fedora and eventually have it packaged and available for install through the official repositories. If anyone is interested in this topic or has any advice/suggestions to help this project along feel free to reach out.

3 3

Outage Notification - 2009-07-01 01:00 UTC
by Mike McGrath 24 Aug '23

24 Aug '23

There will be an outage starting at 2009-07-01 01:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-07-01 01:00 UTC' Affected Services: Buildsystem CVS / Source Control Unaffected Services: Database DNS Fedora Hosted Fedora People Fedora Talk Mail Mirror System Torrent Translation Services Websites Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1496 Reason for Outage: Final migration step for new cvs server. It will hopefully be offline for only 30-45 minutes. The additional time is for some further tuning if needed and some verification steps. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce

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 2023