packaging April 2023

packaging@lists.fedoraproject.org

11 participants
5 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

RPM 4.19: Dynamic subpackages with Python extras
by Miro Hrončok 23 May '23

23 May '23

Hello Python packagers. RPM 4.19 introduces this feature: https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html I decided to write this email to gather my thoughts. I believe that with this, we can turn manual Python extras subpackages like this: %package -n python3-... Summary: %{summary} %description -n python3-... %_description %pyproject_extras_subpkg -n python3-xxx extra1 extra2 (See https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Extras for what that means.) Into something like this: %package -n python3-... Summary: %{summary} %description -n python3-... %_description ... %install %pyproject_install ... %pyproject_generate_extras_subpkgs -n python3-xxx The %pyproject_generate_extras_subpkgs macro would parse the installed .dist-info directory to find out what extras are available and generate subpackages for all of them. (Obviously, the macro name is open up for discussion.) ---------------- An API would be required to exclude extras: - that are not useful for other packages (for example build/development requirements, commonly named dev, doc or test) - that have requirements that are not packaged in Fedora For example (mimicking the API of %pyproject_check_import): %pyproject_generate_extras_subpkgs -n python3-xxx -e test -e 'nonfree*' ---------------- However, extras are also currently manually passed to %pyproject_buildrequires: %generate_buildrequires %pyproject_buildrequires -x extra1 -x extra2 -x test It should already be possible to implement automatic extras discovery in %pyproject_buildrequires with older RPM versions and allow it to be used this way: %generate_buildrequires %pyproject_buildrequires <FLAG_TO_ENABLE_ALL_EXTRAS> -X 'nonfree*' RPM macros can only accept short flags, so <FLAG_TO_ENABLE_ALL_EXTRAS> can either be -x '*' (if we start treating -x values as globs, which is backwards compatible and probably generally useful), or a single-letter switch such as -a (but honestly we are running out of meaningful letters). (When -X is used, <FLAG_TO_ENABLE_ALL_EXTRAS> can probably be implied. However, an explicit form needs to exist for packages that don't need to exclude any extras at all.) Eventually, I'd like to make <FLAG_TO_ENABLE_ALL_EXTRAS> the default, once RPM 4.19 is omnipresent. ---------------- Combined, this would mean that the packager needs to: 1. specify extras that are not supposed to be used as BRs 2. specify extras that are not supposed to be packaged In the ideal word (2) is a superset of (1). Should %pyproject_generate_extras_subpkgs somehow inherit the -Xes from %pyproject_buildrequires? When a package has extra1, extra2, nonfree1, nonfree2 and test extras, one could do: %generate_buildrequires %pyproject_buildrequires <FLAG_TO_ENABLE_ALL_EXTRAS> -X 'nonfree*' ... %pyproject_install ... %pyproject_generate_extras_subpkgs -X test That would mean: - extra1 is BRed and packaged - extra2 is BRed and packaged - test is BRed but not packaged - nonfree1 is neither - nonfree2 is neither ---------------- Alternatively the information could be supplied by %globals: %global _python_ignored_extras nonfree* %global _python_unpackaged_extras test However, I somehow dislike this approach. ---------------- I'd appreciate your thoughts on the matter. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

5 8

New %{ld_ldflags} macro?
by Dridi Boukelmoune 25 Apr '23

25 Apr '23

Greetings, This weekend I played with the Hare [1] toolchain and ran into an interesting case. The build system assumes an LDFLAGS variable for direct invocation, not through GCC or Clang. Ironically, the hare(1) command will also hide the ld(1) command just like GCC or Clang, but it doesn't support the -Wl,flag syntax to pass flags to the linker. So I came up with a macro derived from %{build_ldflags} that I called %{ld_ldflags} to have a similar naming convention and convey the idea of direct ld execution: > %global ld_ldflags %{lua: > sep='' > for gcc_flag in string.gmatch(macros.build_ldflags, '%S+') do > if gcc_flag:match '^\-Wl,' then > ld_flag=string.gsub(gcc_flag, '\-Wl,', '') > print(sep..string.gsub(ld_flag, ',', ' ')) > sep=' ' > end > end} Please note that I'm not a proficient Lua developer, nor an advanced RPM macro author, so I took the path of least resistance to reach the WorksOnMyMachine™ point. I attached the current work-in-progress spec file where I used this macro, but you won't be able to test it without a compatible harec package. I quickly hacked a harec refresh together [2] but I don't have the bandwidth to maintain that kind of stack. I have yet to submit my trivial patch upstream, maybe next weekend I will make more progress on Hare packaging. I thought it was an interesting case of inadequate LDFLAGS and that the macro I came up with could help in that regard. I didn't take the time to see whether other packages were running into the need for "non GCC" ld flags, so even before someone picks hare up, it could be useful for existing packages. Best, Dridi [1] https://harelang.org/ [2] https://src.fedoraproject.org/rpms/harec/pull-request/1

5 11

Bugzilla component for reporting comps.xml issues
by Jan Stodola 14 Apr '23

14 Apr '23

Hi, https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gr… says to use the comps component when reporting a bug. This component cannot be selected when reporting a new Fedora bug. What is the right component? Could the wiki page be updated? Thanks, Jan

2 1

Schedule for Thursday's FPC Meeting (2023-04-06 16:00 UTC)
by James Antill 06 Apr '23

06 Apr '23

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2023-04-06 16:00 UTC in #fedora-meeting-1 on irc.libera.chat. Local time information (via. uitime): ================= Day: Thursday ================== 2023-04-06 09:00 PDT US/Pacific 2023-04-06 12:00 EDT --> US/Eastern <-- 2023-04-06 16:00 UTC UTC 2023-04-06 17:00 BST Europe/London 2023-04-06 18:00 CEST Europe/Berlin 2023-04-06 18:00 CEST Europe/Paris 2023-04-06 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2023-04-07 00:00 HKT Asia/Hong_Kong 2023-04-07 00:00 +08 Asia/Singapore 2023-04-07 01:00 JST Asia/Tokyo 2023-04-07 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 Issues = #topic #1159 Ban use of %configure in %prep .fpc 1159 https://pagure.io/packaging-committee/issue/1159 #topic #1193 Clarify packaging guidelines for .NET applications .fpc 1193 https://pagure.io/packaging-committee/issue/1193 #topic #1236 Specfile scripting .fpc 1236 https://pagure.io/packaging-committee/issue/1236 = Followup Pull Requests = #topic #pr-1097 Use caret in Obsoletes to simplify https://pagure.io/packaging-committee/pull-request/1097 #topic #pr-1207 Ruby: update instructions for checking out excluded tests https://pagure.io/packaging-committee/pull-request/1207 = 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.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging April 2023