July 2022 - packaging - Fedora Mailing-Lists

Automatic virtual provides for RPM macros?

by Miro Hrončok

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

1 week, 5 days

4
4
0 / 0

RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

by Ben Cotton

https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changel... == 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-aut... 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_mac... 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

7 months, 1 week

12
23
0 / 0

Important changes to software license information in Fedora packages (SPDX and more!)

by Matthew Miller

On behalf of all of the folks working on Fedora licensing improvements, I have a few things to announce! New docs site for licensing and other legal topics -------------------------------------------------- All documentation related to Fedora licensing has moved to a new section in Fedora Docs, which you can find at: https://docs.fedoraproject.org/en-US/legal/ Other legal documentation will follow. This follows the overall Fedora goal of moving active user and contributor documentation away from the wiki. Fedora license information in a structured format ------------------------------------------------- The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are now stored in a repository, using a simple structured file format for each license (it’s TOML). You can find this at: https://gitlab.com/fedora/legal/fedora-license-data This data is then presented in easy tabular format in the documentation, at: https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ New policy for the License field in packages — SPDX identifiers! ---------------------------------------------------------------- We’re changing the policy for the "License" field in package spec files to use SPDX license identifiers. Historically, Fedora has represented licenses using short abbreviations specific to Fedora. In the meantime, SPDX license identifiers have emerged as a standard, and other projects, vendors, and developers have started using them. Adopting SPDX license identifiers provides greater accuracy as to what license applies, and will make it easier for us to collaborate with other projects. Updated licensing policies and processes ---------------------------------------- Fedora licensing policies and processes have been updated to reflect the above changes. In some cases, this forced deeper thought as to how these things are decided and why, which led to various discussion on Fedora mailing lists. In other cases, it prompted better articulation of guidance that was implicitly understood but not necessarily explicitly stated. New guidance on “effective license” analysis -------------------------------------------- Many software packages consist of code with different free and open source licenses. Previous practice often involved “simplification” of the package license field when the packager believed that one license subsumed the other — for example, using just “GPL” when the source code includes parts licensed under a BSD-style license as well. Going forward, packagers and reviewers should not make this kind of analysis, and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach is easier for packagers to apply in a consistent way. When do these changes take effect? ---------------------------------- The resulting changes in practice will be applied to new packages and licenses going forward. It is not necessary to revise existing packages at this time, although we have provided some guidance for package maintainers who want to get started. We’re in the process of planning a path for updating existing packages at a larger scale — stay tuned for more on that! Thank you everyone! ------------------- A huge thanks to some key people who have worked tirelessly to make this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav Suchý. Behind the scenes support was also provided by David Levine, Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable feedback from Fedora community members in various Fedora forums. Please have a look at the updated information. If you have questions, please post them to the Fedora Legal mailing list: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

7 months, 3 weeks

4
5
0 / 0

inclusion of kernel module sources in a package

by Zbigniew Jędrzejewski-Szmek

Hi, this question is for https://bugzilla.redhat.com/show_bug.cgi?id=2099771: 'Review Request: wult - Tool for measuring Intel CPU C-state wake latency'. The full project consists of user-space tooling and a kernel driver that is under development. The package wants to include the kernel drivers sources to make it easier for users to compile the driver on the end-user machine. Is this OK according to our guidelines? Zbyszek

7 months, 3 weeks

6
10
0 / 0

Schedule for Thursday's FPC Meeting (2022-07-28 16:00 UTC)

by James Antill

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2022-07-28 16:00 UTC in #fedora-meeting-1 on irc.libera.chat. Local time information (via. uitime): ================= Day: Thursday ================== 2022-07-28 09:00 PDT US/Pacific 2022-07-28 12:00 EDT --> US/Eastern <-- 2022-07-28 16:00 UTC UTC 2022-07-28 17:00 BST Europe/London 2022-07-28 18:00 CEST Europe/Berlin 2022-07-28 18:00 CEST Europe/Paris 2022-07-28 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2022-07-29 00:00 HKT Asia/Hong_Kong 2022-07-29 00:00 +08 Asia/Singapore 2022-07-29 01:00 JST Asia/Tokyo 2022-07-29 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 = 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.

7 months, 4 weeks

1
0
0 / 0

Fedora adoption of SPDX ids and changes to packaging guidelines

by Jilayne Lovejoy

Hi Fedora packaging committee, I see that FESCO has approved the Change Proposal for the adoption of SPDX ids, moving license lists off wiki to a data repo, and updating the licensing documentation https://pagure.io/fesco/issue/2799 We are aiming to "go live" with the new Fedora-legal documentation on Wednesday, July 27th. A key piece of that will be getting the PR to update the packaging guidelines for license info merged https://pagure.io/packaging-committee/pull-request/1142 Can someone merge that PR on Tuesday evening or Wednesday morning (US time)? That way if there are formatting issues, typos, etc, we can try to get them fixed so everything is live and pretty by Wednesday afternoon. Thanks! Jilayne (sending this here, and made comment in PR)

7 months, 4 weeks

2
2
0 / 0

other licensing guidance

by Jilayne Lovejoy

Hi Fedora packagers and legal, As Richard and I have been going through the wiki licensing documentation and creating the new Fedora-legal Docs pages (soon to be published!!!) - we have been trying to make sure we have all license-related guidance in one place. This way, Fedora community members know there is one place to go for this kind of information, instead of various places. This will also help in ensuring things stay current. We noticed there are a couple language-specific bits on licensing in the package guidelines. Is anyone opposed to moving those to the Fedora-legal docs pages on licensing? The pages we found were: - https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_license_... - https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_library_... - https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/ Are there any other such pages? Thanks! Jilayne

7 months, 4 weeks

7
14
0 / 0

Schedule for Thursday's FPC Meeting (2022-07-21 16:00 UTC)

by James Antill

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2022-07-21 16:00 UTC in #fedora-meeting-1 on irc.libera.chat. Local time information (via. uitime): ================= Day: Thursday ================== 2022-07-21 09:00 PDT US/Pacific 2022-07-21 12:00 EDT --> US/Eastern <-- 2022-07-21 16:00 UTC UTC 2022-07-21 17:00 BST Europe/London 2022-07-21 18:00 CEST Europe/Berlin 2022-07-21 18:00 CEST Europe/Paris 2022-07-21 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2022-07-22 00:00 HKT Asia/Hong_Kong 2022-07-22 00:00 +08 Asia/Singapore 2022-07-22 01:00 JST Asia/Tokyo 2022-07-22 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 = 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.

8 months

1
0
0 / 0

What way of opting out form a particular Python shebang flag do you prefer?

by Miro Hrončok

Hello Pythonistas, packagers. In the context of this change: https://fedoraproject.org/wiki/Changes/PythonSafePath Python shebangs will have be: #! /usr/bin/python3 -sP In order to remove certain flags, packagers have the following tool: # Unset -s on python shebang - ensure that extensions installed with pip # to user locations are seen and properly loaded %global py3_shebang_flags %(echo %py3_shebang_flags | sed s/s//) Or: # Don't add -P to Python shebang # This package only works when /usr/bin is in sys.path %global py3_shebang_flags %(echo %py3_shebang_flags | sed s/P//) In the implementation PR, Maxwell suggested a different approach: https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/141#com... Basically, packagers would do something like this: # Unset -s on python shebang - ensure that extensions installed with pip # to user locations are seen and properly loaded %global _python3_shebang_nousersite %{nil} Or: # Don't add -P to Python shebang # This package only works when /usr/bin is in sys.path %global _python3_shebang_safepath %{nil} The macro names are not set in stone, it could even be %_python3_shebang_s and %_python3_shebang_P. The previous sed-based way would still work and packages that already use it would not need to change immediately. Do you consider the macro based approach better (worth it)? And if so, do you prefer actual flag letters in the macro names, or the verbose names? Thanks for your input. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

8 months

4
4
0 / 0

QEMU info

by Jilayne Lovejoy

Hi all, As Richard and I go through the legal/licensing related wiki pages, we've come across some info that is clearly not legal or licensing related. The info on QEMU (pasted below) is one example. Seems like this would be more appropriately suited for a page related to technical requirements for packaging? I'm not sure where that would be - could someone maybe take the info below and make sure it gets to a proper location in packaging (or other) docs?? Thanks! Jilayne "QEMU ROMs Whenever possible, ROMS implementing BIOS or Firmware for QEMU system targets must be built from source on the intended architecture. However, in many situations, this is not practical or possible. As a special exception for those situations where it is not practical or possible, prebuilt binary ROMS implementing BIOS or Firmware for QEMU system targets may be included in Fedora Packages, as long as the corresponding source code is also included in the Source RPM package.?

8 months, 1 week

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2022