packaging November 2021

packaging@lists.fedoraproject.org

14 participants
8 discussions

RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
by Ben Cotton 13 Aug '22

13 Aug '22

https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog… == Summary == redhat-rpm-config will be updated so users of the auto framework get automated release and changelog bumping. == Owner == * Name: [[User:nim| Nicolas Mailhot]] * Email: <nicolas.mailhot at laposte.net> == Detailed Description == This is a system-wide change because all packages build with redhat-rpm-config, but it only concerns packages that opted to use this part of redhat-rpm-config (auto framework). The change will make those packages auto-bump and auto-changelog at the rpm level, in an infrastructure-independent way. == Benefit to Fedora == Autobumping removes a huge packager shore and makes timestamping in changelogs more reliable. == Scope == * Proposal owners: The feature is coded and works at the rpm level. Unfortunately, mock filters away the srpms containing the bump state, so it does not work in upper layers. * Other developers: The feature requires buy-in by mock developers (and probably koji developers) to lift the restrictions that block it above the rpm level. Also, it requires a mechanism to pass the user name and email that will be used in bumped changelogs (defining two variables in ~/.rpmmacros is sufficient at rpm level) * Mock issue: https://github.com/rpm-software-management/mock/issues/599 * Release engineering: https://pagure.io/releng/issue/9567 * Policies and guidelines: maybe eventually if things work out on the technical level * FPC issue: https://pagure.io/packaging-committee/issue/998 * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This is a pure build tooling update, it changes how things are built not what is built. == How To Test == A redhat-rpm-config packages with the changes and some example packages are available in https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-… Since the mock/copr layer is currently blocking the feature, you need to install the redhat-rpm-config and forge macro packages available in this repo locally. Afterwards you can take any of the example packages in the repo and rebuild them with rpmbuild -ba to your heart content, and see the releases bump and the changelogs being updated accordingly. To get beautiful changelogs, you also need to add <pre> %buildsys_name Your name %buildsys_email Your email </pre> in ~/.rpmmacros == User Experience == N/A Packager experience change only == Dependencies == The change is a spin-off of https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macro… Therefore, it depends on the success of that other change and will probably need rebasing if the code in this other change evolves during the redhat-rpm-config merge. It also depends on mock / copr/ koji buy-in and changes, that may add their own requirements. == Contingency Plan == There is no contingency plan because the change will happen or not at all. == Documentation == There is as much documentation as the average redhat-rpm-config change (ie comments in the macro files themselves) == Release Notes == N/A Packager productivity change only -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

12 23

how I test %if %else %endif conditions in shell command line
by Sérgio Basto 29 Nov '21

29 Nov '21

Hi, How a make I can check what the result of for example : %if 1 echo 1; %else echo 0; %endif Best regards, -- Sérgio M. B.

2 2

Thanksgiving sneak preview of something cool....
by Matthew Miller 26 Nov '21

26 Nov '21

Ever wanted to search across all Fedora spec files for some pattern? Now you can! https://sourcegraph.com/search?q=context:global+r:src.fedoraproject.org+fil… -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

3 5

How do I get the source package _name_ from an RPM?
by Matthew Miller 23 Nov '21

23 Nov '21

rpm -qa --qf '%{sourcerpm}\n' gives me a list of source RPM names, but it's in filename format. I don't want to have to try to parse that to figure out the actual source package base name (i.e. the dist-git name). Is there something I'm missing? Probably there is. :) -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

8 13

Should we have rpm package policies tying extension packages to the GNOME versions they'll work with?
by Matthew Miller 22 Nov '21

22 Nov '21

See this Ask Fedora topic: https://ask.fedoraproject.org/t/fedora-34-extensions-installed-from-dnf-dis… In short, some rpm-packaged GNOME Shell extensions don't work with the GNOME Shell we are shipping, but this isn't expressed in the dependencies. I looked at the package which triggered the question, and: $ rpm -qRp gnome-shell-extension-sound-output-device-chooser-39^1.8c90ed0-1.fc35.noarch.rpm gnome-shell-extension-common python3 rpmlib(CaretInVersions) <= 4.15.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 and $ rpm2cpio gnome-shell-extension-sound-output-device-chooser-39^1.8c90ed0-1.fc35.noarch.rpm |cpio -i --quiet --to-stdout './usr/share/gnome-shell/extensions/*/metadata.json'|jq '."shell-version"' [ "3.32", "3.34", "3.36", "3.38", "40" ] Would it make sense to have an automatic dependency generator which requires gnome-shell to be one of those versions? (Or conflicts with gnome-shell which is _not_ those versions?) -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

4 7

Re: Should we have rpm package policies tying extension packages to the GNOME versions they'll work with?
by Matthew Miller 21 Nov '21

21 Nov '21

On Mon, Nov 15, 2021 at 01:40:39PM +0100, Frantisek Zatloukal wrote: > On the other hand though, I barely remember that the compatibility check by > GNOME was re-introduced with GNOME 40 and it may be disabled by default in > the future again. > > Matthew, can you ask the GNOME folks if they have any plans about this? If > the compatibility enforcement was to be disabled again, this "may not" (I > am not 100 % sure about this) be necessary at all (the extensions worked > throughout different GNOME versions before 40 just fine in the most cases, > without any fixing and tweaking)? It seems like the upstream consensus* is that it's better to keep the check, so that someone at least looks and does the update. And honestly, I think that's completely reasonable for extensions that we've chosen to specifically make available in RPM form as part of the Fedora Linux distro. But it'd be nice to have tooling (both upstream and in Fedora) to help extension developers and maintainers. I don't know how much capacity we have for openqa testing of something like this, or what GNOME can offer. * https://discourse.gnome.org/t/plans-for-extension-validation-setting/8107 and https://discourse.gnome.org/t/unable-to-download-updates-from-extentions-gn… -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

1 0

Re: Should we have rpm package policies tying extension packages to the GNOME versions they'll work with?
by Matthew Miller 16 Nov '21

16 Nov '21

On Mon, Nov 15, 2021 at 01:40:39PM +0100, Frantisek Zatloukal wrote: > Matthew, can you ask the GNOME folks if they have any plans about this? If > the compatibility enforcement was to be disabled again, this "may not" (I > am not 100 % sure about this) be necessary at all (the extensions worked > throughout different GNOME versions before 40 just fine in the most cases, > without any fixing and tweaking)? Sure, or some of the folks on the desktop list here who might be already in the know could chime in. :) I kind of think it'd be useful to at least _alert_ maintainers and ask them to test and update (either to a new version, or just patch the compat list if the current one works), no matter what that setting ends up as. -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

1 0

Schedule for Thursday's FPC Meeting (2021-11-11 17:00 UTC)
by James Antill 10 Nov '21

10 Nov '21

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2021-11-11 17:00 UTC in #fedora-meeting-1 on irc.libera.chat. Local time information (via. uitime): ================= Day: Thursday ================== 2021-11-11 09:00 PST US/Pacific 2021-11-11 12:00 EST --> US/Eastern <-- 2021-11-11 17:00 GMT Europe/London 2021-11-11 17:00 UTC UTC 2021-11-11 18:00 CET Europe/Berlin 2021-11-11 18:00 CET Europe/Paris 2021-11-11 22:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2021-11-12 01:00 HKT Asia/Hong_Kong 2021-11-12 01:00 +08 Asia/Singapore 2021-11-12 02:00 JST Asia/Tokyo 2021-11-12 03:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Actions = #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot = Followup Issues = #topic #886 Enable BRP for detecting RPATH .fpc 886 https://pagure.io/packaging-committee/issue/886 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #1058 How to handle %lang files in package owned directories? .fpc 1058 https://pagure.io/packaging-committee/issue/1058 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 #topic #pr-1045 WIP: Add discussion of macro names beginning with underscores. https://pagure.io/packaging-committee/pull-request/1045 #topic #pr-1046 Improve separate test suite sourcing instructions https://pagure.io/packaging-committee/pull-request/1046 #topic #pr-1071 Overhaul the RPATH section of the guidelines. https://pagure.io/packaging-committee/pull-request/1071 #topic #pr-1077 Introduce %sysusers_create https://pagure.io/packaging-committee/pull-request/1077 #topic #pr-1094 Add documentation for build constraints macro https://pagure.io/packaging-committee/pull-request/1094 #topic #pr-1097 Use caret in Obsoletes to simplify https://pagure.io/packaging-committee/pull-request/1097 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging November 2021