packaging August 2019

packaging@lists.fedoraproject.org

23 participants
8 discussions

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

Schedule for Thursday's FPC Meeting (2019-08-29 16:00 UTC)
by James Antill 28 Aug '19

28 Aug '19

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-08-29 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2019-08-29 09:00 PDT US/Pacific 2019-08-29 12:00 EDT --> US/Eastern <-- 2019-08-29 16:00 UTC UTC 2019-08-29 17:00 BST Europe/London 2019-08-29 18:00 CEST Europe/Berlin 2019-08-29 18:00 CEST Europe/Paris 2019-08-29 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2019-08-30 00:00 HKT Asia/Hong_Kong 2019-08-30 00:00 +08 Asia/Singapore 2019-08-30 01:00 JST Asia/Tokyo 2019-08-30 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 = Pull Requests = #topic #894 Add rules for Cython https://pagure.io/packaging-committee/pull-request/894 #topic #903 Update Python guidelines for Fedora 31 https://pagure.io/packaging-committee/pull-request/903 #topic #915 Modernize python spec file example https://pagure.io/packaging-committee/pull-request/915 = 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

[RFC] %configure macro when missing a ./configure script
by Japheth Cleaver 28 Aug '19

28 Aug '19

I seem to recall discussion on this in the ancient past, but I couldn't find anything in the archive, nor on the current Fedora Packaging Guidelines docs. There exist upstreams out there that are written in C/C++ but don't ship with a "configure" script. In some cases, I've seen this addressed by simply not running the %configure macro and then make-ing as normal, or by manually using %optflags somewhere. This is the suggestion in some tutorials for addressing this, e.g.: https://rpm-packaging-guide.github.io/#cello-working-with-spec-files The %build section is where we tell the system how to actually build the software we are packaging. Since wrote a simple Makefile for our C implementation, we can simply use the GNU make command provided by rpmdev-newspec. However, we need to remove the call to %configure because we did not provide a configure script I'd like to propose the addition of a "Configuration" section in the FPG (probably right under https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler ) that addresses the importance of using %configure. It ensures flags are properly exported into the environment, but could also do other arbitrary, distro-dependent things at some point, so it's still better to run the macro than not. There are two possible workarounds, depending on the whether %_configure (with underscore) is available, or if more control is needed for simulating a script. Safer: %build # source has no configure script; use macro anyway echo "#!/bin/sh" > configure ; chmod +x configure %configure make %{?_smp_mflags} Recent versions; simple case: %build # source has no configure script; use macro anyway %define _configure /bin/true %configure make %{?_smp_mflags} I submitted https://github.com/redhat-developer/rpm-packaging-guide/issues/75 for that doc, but it seems like something about whether/how to work around this should be in these guidelines too, since they're used so much as a general reference. Regards, -jc

6 11

RFC: systemize packaging that manipulates implicit XML catalog
by Jan Pokorný 22 Aug '19

22 Aug '19

Hello, it was brought to my attention that unlike in Fedora, openSUSE has taken care of the (relatively niche) area of dealing with packages' entries to what other SW consumes (directly or via transitive chain of catalogs) from /etc/xml/catalog file: https://en.opensuse.org/openSUSE:Packaging_XML_Schemas_and_Stylesheets What follows is a natural consideration whether it would, for once, make sense for Fedora to follow this example, for ~3 reasons: 0. less imperative, more declarative is issually somewhat more relaxed at both "produce" and "grok" directions 1. it's easy to forget about the removal part when using explicit procedural form of registering a custom catalog in pre/post scriptlets (it happened to me with upstream, thanks to the reviewer for spotting it, and actually also for pointing the openSUSE advancement in this packaging territory per above) 2. unified path for the custom catalogs to allow for immediately groking the delegations without even reviewing /etc/xml/catalog file in detail 3. sticking with what openSUSE already does means less of a wide RPM ecosystem fragmentation Now, if this received a positive feedback, I am not sure how to go about rewriting update-xml-catalog executable from scratch vs. just adopting theirs, regarding proper license compatibility, attributions, in which package to put it, etc. But I guess, that'd be secondary, so what I want to know at this point is whether: - such a packaging related "enablement" would make sense, with an outlook to eventually (given the proper Fedora change process if eligible here) mandate the use of this new mechanism for hooking custom XML catalogs in, perhaps to the extent that /etc/xml/catalog would be assumed immutable, with only the pre-delegated catalog eligible for changes - there is a precedent of Fedora adopting parts of openSUSE packaging practices, like it would be the case here Thanks -- Jan (Poki)

2 2

libfoo.$major requirements/guidelines
by Brian J. Murrell 22 Aug '19

22 Aug '19

I've been unable to locate any packaging guidelines/requirements that indicate that a source package providing shared libraries should have those shared libraries packaged into a sub-package with the major version of library appended to the sub-package name (i.e. libfoo1, libfoo2, etc.) -- to facilitate concurrent installation of the differing major versions of the library. Is there no such guideline/requirement?

6 14

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

22 Aug '19

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-08-22 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2019-08-22 09:00 PDT US/Pacific 2019-08-22 12:00 EDT --> US/Eastern <-- 2019-08-22 16:00 UTC UTC 2019-08-22 17:00 BST Europe/London 2019-08-22 18:00 CEST Europe/Berlin 2019-08-22 18:00 CEST Europe/Paris 2019-08-22 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2019-08-23 00:00 HKT Asia/Hong_Kong 2019-08-23 00:00 +08 Asia/Singapore 2019-08-23 01:00 JST Asia/Tokyo 2019-08-23 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 = Pull Requests = #topic #894 Add rules for Cython https://pagure.io/packaging-committee/pull-request/894 #topic #903 Update Python guidelines for Fedora 31 https://pagure.io/packaging-committee/pull-request/903 #topic #915 Modernize python spec file example https://pagure.io/packaging-committee/pull-request/915 = 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

Using Minisign for source file verification
by François Kooman 13 Aug '19

13 Aug '19

Hi all, In doing my part in getting us away from PGP, at least in areas where its use is overkill or a bad idea [1], I packaged Minisign [2] for Fedora and CentOS [3]. It is currently available in the stable repositories on Fedora >= 30 and EPEL. The wiki currently describes the procedure to verify source downloads using PGP (GnuPG) [4]. I'd like to propose an added section/extension to also mention Minisign as a means to accomplish that. I wrote a blog post [5] on how I think it can be added to RPM spec files. Is this something that we can add to the official Packaging documentation? I'd be willing to work on this! Any ideas, feedback? Regards, François [1] https://latacora.micro.blog/2019/07/16/the-pgp-problem.html [2] https://github.com/jedisct1/minisign [3] https://apps.fedoraproject.org/packages/minisign [4] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_ver… [5] https://www.tuxed.net/fkooman/blog/minisign.html

9 23

Policy regarding packages modifying firewall rules
by Christopher Engelhard 13 Aug '19

13 Aug '19

Hi, what is the policy regarding software that requires modifications to the firewall in order to run? Specifically, I'm packaging sshguard (a brute-force blocking software similar to fail2ban, I've asked about it here before [1]), which maintains a list of blocked ips/subnets in ipsets. When using firewalld and nftables, these ipsets are created automatically when the program first runs, but for iptables the user has to set them up beforehand. - should the (iptables sub-)package set these up during first install instead? If not, should the user be notified of the required steps in e.g. a scriptlet? - for all backends, should the ipsets be removed when the package is uninstalled? I think similar arguments as for user creation/deletions apply, so would go for create-automatically-and-never-delete, but maybe there already is an existing policy on this? I had a look at the fail2ban spec, but fail2ban seems to take care of firewall configuration entirely on its own. Best, Christopher [1] https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2019