packaging November 2020

packaging@lists.fedoraproject.org

5 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

Schedule for Thursday's FPC Meeting (2019-08-15 16:00 UTC)
by James Antill 19 Jul '21

19 Jul '21

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-08-15 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2019-08-15 09:00 PDT US/Pacific 2019-08-15 12:00 EDT --> US/Eastern <-- 2019-08-15 16:00 UTC UTC 2019-08-15 17:00 BST Europe/London 2019-08-15 18:00 CEST Europe/Berlin 2019-08-15 18:00 CEST Europe/Paris 2019-08-15 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2019-08-16 00:00 HKT Asia/Hong_Kong 2019-08-16 00:00 +08 Asia/Singapore 2019-08-16 01:00 JST Asia/Tokyo 2019-08-16 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #902 Cleanup & enhance spec files .fpc 902 https://pagure.io/packaging-committee/issue/902 #topic #904 Caret versioning .fpc 904 https://pagure.io/packaging-committee/issue/904 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 #topic #914 Automatic R runtime dependencies .fpc 914 https://pagure.io/packaging-committee/issue/914 = 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.

3 2

Odd problem with obsoletes in EPEL8
by Martin Jackson 19 Jul '21

19 Jul '21

Hello, I'm having a problem I don't understand how to fix, and I would appreciate some guidance. I'm maintaining nagios-plugins, which bundles a number of different "check" plugins and has some metapackages that include different subsets of those check plugins. In the EL 8.2 release cycle, one of the dependencies of one of those plugins was moved from EPEL into EL proper, which broke new installs of that plugin and the -all metapackage. A user filed a bug, so as a temporary workaround, I stopped building the plugin package with that dependency (nagios-plugins-ssl_validity, and had that version (nagios-plugins-2.3.3-3) obsolete the ssl_validity plugin, since leaving it around caused it to want to keep the base package in conflict with other packages that were upgrading. Now that CentOS 8.2 is released, and the dependency is available, I've issued an update (https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-70bcfe5382) that builds ssl_validity again, and also adds it back to the -all subpackage. I can upgrade it sucessfully (which installs the ssl_validity plugin again, as expected), but subsequent calls to dnf upgrade give this error: Obsoleting Packages nagios-plugins.x86_64 2.3.3-3.el8 epel nagios-plugins-ssl_validity.x86_64 2.3.3-4.el8 @epel-testing nagios-plugins 2.3.3-3 is not installed anymore, and there are no explicit Obsoletes: in the ssl_validity package. I'm not sure what needs to be done here, but whatever it is I'm willing to make the change. Also wondering if this is expected behavior. Thanks, Marty

2 1

On becoming a packager
by Mattia Verga 16 Nov '20

16 Nov '20

I think the process for becoming a packager is really rusty. We currently require to submit a valid package review submission AND to find a sponsor AND to prove them you're able "to convince an existing sponsor-level member that you understand and follow the project's guidelines and processes". The latest part seems quite subjective to me. Moreover, it's becoming harder and harder for the few sponsors to follow all the requests: look at the approved package submissions list [1] where a lot of those are stuck waiting for a sponsor. So, what about moving the sponsorship part to use an entry test? We could setup a standard test with a bunch of questions about the packaging process, the package maintaining process and some flawed .spec files that the applicant should fix. I don't think we would need an app to run this, just a place from where the applicant can download the test and maybe an email address with limited access to sponsors where the applicant submits their answers. What do you think? Mattia [1] https://fedoraproject.org/PackageReviewStatus/in_progress.html

2 1

Orphaning python-blindspin
by Andy Mender 15 Nov '20

15 Nov '20

Hello, This is a heads-up that I'm orphaning python-blindspin: https://src.fedoraproject.org/rpms/python-blindspin The project is a fork of python-click-spinner, which has recently been approved: https://src.fedoraproject.org/rpms/python-click-spinner (but somehow not yet imported) The fork had very little traction and didn't seem to enhance the upstream project significantly. Also, it's not used by anything: [amender@localhost SPECS]$ rpm -q --whatrequires python3-blindspin no package requires python3-blindspin Cheers, Andy

1 0

Summary/Minutes from today's FPC Meeting (2020-11-12 17:00 - 17:35 UTC)
by James Antill 12 Nov '20

12 Nov '20

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 17:00:13 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2020-11-12/fpc.2020-11-1… . Meeting summary --------------- * Roll Call (geppetto, 17:00:14) * Schedule (geppetto, 17:05:34) * LINK: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject… (geppetto, 17:05:37) * Open Floor (geppetto, 17:05:47) * LINK: https://pagure.io/copr/copr/issue/1483 (King_InuYasha, 17:22:38) Meeting ended at 17:38:24 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * geppetto (27) * mhroncok (24) * zodbot (15) * tibbs (13) * King_InuYasha (6) * nirik (3) * defolos (3) * limburgher (2) * praiskup (1) * carlwgeorge (1) * copperi (1) * decathorpe (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Is acceptable to package non-bootable kernels?
by Sergio Lopez 12 Nov '20

12 Nov '20

Hi, The document "What can be packaged" from "Fedora Packaging Guidelines", in the section "Only one kernel package" [1], states that "Fedora allows only a single kernel package; packages containing alternate kernels are not allowed in the distribution." While not explicitly stated there, I suspect (please correct me if I'm wrong) that statement was written with the idea of preventing alternate kernels that could be used to boot the system. With this premise in mind, I was wondering if packaging non-bootable kernels (that is, kernels is a binary format that's not accepted by a conventional boot loader) would be accepted for packaging. I'm asking this because I would like to package "libkrunfw" [2], a dynamic library that bundles an slightly modified minimalist Linux kernel. The library doesn't really link against the kernel (in the sense that it doesn't resolve any symbols nor calls to any of its code), it just bundles it in a binary format that allows it to be directly injected in a KVM memory region, so it's quite similar to a compressed image format, but for a different use case. "libkrunfw" is consumed by "libkrun" [3], another dynamic library that allows programs to acquire virtualization-based process isolation capabilites. The main user of "libkrun" is "crun", when built with "--with-libkrun", an OCI runtime used by "podman". When all pieces are in place, users can easily run containers with virtualization-based isolation by adding some additional flags to the "podman" command line. I have a COPR repository with pre-built alternative packages as a demonstration [4]. There are a number of reasons why we can't use the kernel that ships with Fedora: - We carry a small number of patches with minor changes that modify the behavior of the kernel for this particular use case. Without them, we can't provide an streamlined UX for running isolated processes. - We need an aggressive minimalist configuration to reduce the memory footprint of each container/isolated process. - We need it to be bundled in a dynamic library, so their contents are mapped into the process memory, enabling programs to switch between namespaces without the need to carry the kernel binary with them. The binary object also needs to be properly aligned to allow direct injection into the KVM memory region without additional copies. Given that "libkrunfw" bundles a kernel image that can't be used for booting the system, would it be acceptable to package it in Fedora? Thanks, Sergio. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packa… [2] https://github.com/containers/libkrunfw [3] https://github.com/containers/libkrun [4] https://copr.fedorainfracloud.org/coprs/slp/crun-krun/

2 2

Schedule for Thursday's FPC Meeting (2020-11-12 17:00 UTC)
by James Antill 12 Nov '20

12 Nov '20

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2020-11-12 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2020-11-12 09:00 PST US/Pacific 2020-11-12 12:00 EST --> US/Eastern <-- 2020-11-12 17:00 GMT Europe/London 2020-11-12 17:00 UTC UTC 2020-11-12 18:00 CET Europe/Berlin 2020-11-12 18:00 CET Europe/Paris 2020-11-12 22:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2020-11-13 01:00 HKT Asia/Hong_Kong 2020-11-13 01:00 +08 Asia/Singapore 2020-11-13 02:00 JST Asia/Tokyo 2020-11-13 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-954 * King_InuYasha talk to copr to get config. turned on * tibbs talk to releng to get config. turned on #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot #topic Open Floor * decathorpe look through non-meeting tickets, see if any are stuck/need to be discussed = Followup Issues = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 = 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 2020