packaging August 2022

packaging@lists.fedoraproject.org

4 participants
7 discussions

license of the binary policy
by Jilayne Lovejoy 25 Mar '24

25 Mar '24

Hi Fedora legal and packaging, I'm cross-posting this, as I think it's relevant to both groups. The current policy for filling out the license field of the spec file (as described at https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelin… ) states, "The License: field refers to the licenses of the contents of the binary rpm. When in doubt, ask." As we consider how to improve documentation related to Fedora licensing, it would be helpful to hear people's thoughts on the following: 1) how do you (package maintainers) interpret this policy in practice? 2) what further information/documentation about this policy would be helpful? 3) should this policy be different, and if so, how? 4) any other related thoughts or observations Thanks! Jilayne

12 39

Automatic virtual provides for RPM macros?
by Miro Hrončok 10 Mar '23

10 Mar '23

Hello, today at Nest, somebody said "unfortunately, there is no way to tell what package to install to get a particular RPM macro". I think that having an RPM provides generator for "rpm-macro(__python3)" or similar should be a fairly simple exercise. Would you folks consider that useful? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 4

Need help: Building a package requiring python >= 3.7 on epel8
by Steve Cossette 29 Aug '22

29 Aug '22

Good day to you all! I am still pretty much new at packaging, for fedora or, well, any distro to be frank. I applied to become a co-packager for the lutris package at the beginning of the year and was lucky enough to be co-sponsored and brought on board. Love packaging! Now, I decided to contribute further by building the package for epel8 and epel9. I have been following the guide on https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenanc…, but did not know that doing so does not guarantee installation will be successful (specially if some of the packages set as 'Requires' are not available in the repos.... oops!) So, with Lutris requiring python 3.7 or higher, I decided to go with 3.8. I've set the spec to use python3.8 (By using the "%global __python3 /usr/bin/python3.8" macro) and specified python3.8 packages as much as possible, as the default python for centos stream/epel8 is 3.6. Python38-devel installs fine, but 3 subpackages keep failing, mainly python3.8(evdev), python3.8(pygobject) and python3.8(distro). Distro should work with the python38-pip package (if pkgs.org is to be believed) but the other two seem to be a no-go on epel8. Before we drop that branch, I wanted to post here, to make sure I didn't miss anything. Thanks for your help!

2 1

Fwd: Need help: Building a package requiring python >= 3.7 on epel8
by Maxwell G 28 Aug '22

28 Aug '22

Looping in epel-devel ---------- Forwarded Message ---------- Subject: [Fedora-packaging] Need help: Building a package requiring python >= 3.7 on epel8 From: Steve Cossette <farchord(a)gmail.com> To: packaging(a)lists.fedoraproject.org Good day to you all! I am still pretty much new at packaging, for fedora or, well, any distro to be frank. I applied to become a co-packager for the lutris package at the beginning of the year and was lucky enough to be co-sponsored and brought on board. Love packaging! Now, I decided to contribute further by building the package for epel8 and epel9. I have been following the guide on https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenanc…, but did not know that doing so does not guarantee installation will be successful (specially if some of the packages set as 'Requires' are not available in the repos.... oops!) So, with Lutris requiring python 3.7 or higher, I decided to go with 3.8. I've set the spec to use python3.8 (By using the "%global __python3 /usr/bin/python3.8" macro) and specified python3.8 packages as much as possible, as the default python for centos stream/epel8 is 3.6. Python38-devel installs fine, but 3 subpackages keep failing, mainly python3.8(evdev), python3.8(pygobject) and python3.8(distro). Distro should work with the python38-pip package (if pkgs.org is to be believed) but the other two seem to be a no-go on epel8. Before we drop that branch, I wanted to post here, to make sure I didn't miss anything. Thanks for your help! _______________________________________________ packaging mailing list -- packaging(a)lists.fedoraproject.org To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ----------------------------------------- -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

2 2

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 (2022-08-11 16:00 UTC)
by James Antill 10 Aug '22

10 Aug '22

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2022-08-11 16:00 UTC in #fedora-meeting-1 on irc.libera.chat. Local time information (via. uitime): ================= Day: Thursday ================== 2022-08-11 09:00 PDT US/Pacific 2022-08-11 12:00 EDT --> US/Eastern <-- 2022-08-11 16:00 UTC UTC 2022-08-11 17:00 BST Europe/London 2022-08-11 18:00 CEST Europe/Berlin 2022-08-11 18:00 CEST Europe/Paris 2022-08-11 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2022-08-12 00:00 HKT Asia/Hong_Kong 2022-08-12 00:00 +08 Asia/Singapore 2022-08-12 01:00 JST Asia/Tokyo 2022-08-12 02: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 = New Issues = #topic #1189 Request for soft-static UID/GID for "polkitd" (pkg "polkit") .fpc 1189 https://pagure.io/packaging-committee/issue/1189 #topic #1193 Clarify packaging guidelines for .NET applications .fpc 1193 https://pagure.io/packaging-committee/issue/1193 = 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 #topic #1132 Mark comments as scriplets for Sources (automation) .fpc 1132 https://pagure.io/packaging-committee/issue/1132 #topic #1150 request for clarification wrt. base version / compat package naming .fpc 1150 https://pagure.io/packaging-committee/issue/1150 #topic #1159 Ban use of %configure in %prep .fpc 1159 https://pagure.io/packaging-committee/issue/1159 = 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-1071 Overhaul the RPATH section of the guidelines. https://pagure.io/packaging-committee/pull-request/1071 #topic #pr-1097 Use caret in Obsoletes to simplify https://pagure.io/packaging-committee/pull-request/1097 #topic #pr-1163 Sources: Add section about conditionalization https://pagure.io/packaging-committee/pull-request/1163 = 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

Re: Important changes to software license information in Fedora packages (SPDX and more!)
by Maxwell G 01 Aug '22

01 Aug '22

Kevin Kofler via devel wrote: > Now you have to compare every word of the MIT license > with the very similar templates such as MIT, MIT-CMU, MIT-feh, etc., and > then figure out which one it actually is. If it is even one of these and not > some random mix of several variants (one sentence from here, one sentence > from there, …). You're right. MIT/BSD License variants are a pain to deal with. In practice, they are mostly equivalent, so having to identify is a burden without a lot of benefit. Currently, there's MIT variants such as the HPND that aren't even part of the new license list, despite being explicitly listed on the old list and being used by packages like libX11[1]. As that license deprecated, it's not likely to cause issues when importing new packages, but it is still used by older packages. There are other examples of licenses missing from the new list that are already blocking new packages[2]. [1]: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/1#note_9695733… [2]: https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/12#not… > But that is how things work in practice. It is just impossible to read > through every source file and scan for copied snippets. They can even appear > in the middle of a file, with the license attached right there. So the > packager and the reviewer will both check the COPYING/LICENSE/LICENCE file > provided by upstream, then go exemplarily through a handful source files to > check that the copyright header and/or SPDX REUSE header matches that > license, and then declare that as the one License. This is onerous if you do it manually, but there are tools to make it a bit easier. You can use scancode-toolkit or licencecheck to scan the entire codebase. I believe the RH legal folks recommended the former at some point, but licensecheck is used by fedora-review and actually packaged in Fedora[^1]. The Legal docs recommend SPDX license-diff[3] and [4] to see if a certain license text exists in SPDX. [^1]: I wish luck to anyone who tries to package tries to package scancode. There are quite a few unpackaged dependencies... [3]: https://addons.mozilla.org/en-US/firefox/addon/spdx-license-diff/ [4]: https://tools.spdx.org/app/check_license/ -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2022