packaging October 2018

packaging@lists.fedoraproject.org

17 participants
15 discussions

obsolete JavaScript packaging guidelines
by Greg Sheremeta 03 Dec '18

03 Dec '18

Hi, This page https://fedoraproject.org/wiki/Packaging:JavaScript is terribly outdated. Even when it was created years ago, IMO the advice was questionable. Today, it's definitely bad advice. Modern web applications use webpack for JavaScript. With webpack, JavaScript is minified and bundled, and sometimes assets are even injected. I realize bundling libraries is bad for an old-school RPM-based application. But no one packages JavaScript into RPMs (try to find react and friends), and the page is leading to confusion on my team. To prevent confusion, acceptable options would be: either simply deleting the page, or placing a giant "don't follow this outdated advice" banner at the top. Best wishes, Greg -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

8 18

Schedule for Thursday's FPC Meeting (2018-11-01 16:00 UTC)
by James Antill 31 Oct '18

31 Oct '18

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2018-11-01 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2018-11-01 09:00 PDT US/Pacific 2018-11-01 12:00 EDT --> US/Eastern <-- 2018-11-01 16:00 GMT Europe/London 2018-11-01 16:00 UTC UTC 2018-11-01 17:00 CET Europe/Berlin 2018-11-01 17:00 CET Europe/Paris 2018-11-01 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2018-11-02 00:00 HKT Asia/Hong_Kong 2018-11-02 00:00 +08 Asia/Singapore 2018-11-02 01:00 JST Asia/Tokyo 2018-11-02 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 #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 = 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

Summary/Minutes from today's FPC Meeting (2018-10-15 16:00 - 17:00 UTC)
by James Antill 25 Oct '18

25 Oct '18

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 16:00:20 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2018-10-25/fpc.2018- 10-25-16.00.log.html . Meeting summary --------------- * Roll Call (geppetto, 16:00:20) * Schedule (geppetto, 16:05:21) * LINK: https://lists.fedoraproject.org/archives/list/packaging@lists.fedor aproject.org/message/TCDBEO25XN5P3EX66REKMSWC3DPBP47H/ (geppetto, 16:05:25) * #719 Simplify packaging of forge-hosted projects (geppetto, 16:08:40) * ACTION: ignatenkobrain will look at the draft, so tibbs can spend some time on ~ ticket ;) (geppetto, 16:17:34) * #398: Tilde in version (geppetto, 16:18:17) * LINK: https://github.com/rpm-software-management/dnf-plugins-extras/blob/ master/plugins/system_upgrade.py#L298-L301 (ignatenkobrain, 16:50:43) * LINK: https://en.opensuse.org/openSUSE:Package_naming_guidelines (ignatenkobrain, 16:58:01) * Open Floor (geppetto, 17:00:00) Meeting ended at 17:02:02 UTC. Action Items ------------ * ignatenkobrain will look at the draft, so tibbs can spend some time on ~ ticket ;) Action Items, by person ----------------------- * ignatenkobrain * ignatenkobrain will look at the draft, so tibbs can spend some time on ~ ticket ;) * tibbs * ignatenkobrain will look at the draft, so tibbs can spend some time on ~ ticket ;) * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * tibbs (101) * geppetto (61) * decathorpe (39) * ignatenkobrain (22) * zodbot (14) * redi (7) * limburgher (5) * eclipseo (3) * coremodule (1) * mizdebsk (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Fixing wrong Bootstrapping part in Guidelines
by Jun Aruga 23 Oct '18

23 Oct '18

Dear Packagers who are using Boostrapping logic for the cyclical dependency Need your help to fix wrong Bootstrapping part in Guidelines. This mail is long. Sorry for that in advance. You may be building the cyclical dependency packages by using a variable such as _with_bootstrap, need_bootstrap, bootstrap, enable_test, and etc.. For example, you may build with below ways for that, if you will use mock command. ``` $ mock -r fedora-rawhide-x86_64 --with=bootstrap *.src.rpm => _with_bootstrap can be used as --with=bootstrap $ mock -r fedora-rawhide-x86_64 --define '_with_bootstrap 1' *.src.rpm $ mock -r fedora-rawhide-x86_64 --define 'need_bootstrap 1' *.src.rpm $ mock -r fedora-rawhide-x86_64 --define 'enable_test 1' *.src.rpm ... ``` Here is a document page to unify the Bootstrap logic. You may know it. https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping However I found that below part in the page is wrong. ``` %{!?_with_bootstrap: %global bootstrap 1} ``` Because .. If _with_bootstrap is not set from outside, bootstrap is 1 => bootstrap is True/Enabled if _with_bootstrap is set as 1 from outside, bootstrap's value is not set. => the value is empty if it is not declared in advance. It's a kind of 0. bootstrap is False/Disabled. This situation is opposite meaning of "_with_bootstrap". Below way not using negative operator `!?` is correct. ``` %{?_with_bootstrap: %global bootstrap 1} ``` The reason why I wrote this here is I found that had already been reported 2 years ago for packaging committee, however it was closed without fixing. https://pagure.io/packaging-committee/issue/509 I am not sure that why it is not admitted. You may feel that it does not matter because you may edit the Bootstrapping logic in the RPM spec file manually. But in my case, I am one of the people who use the Bootsrapping logic actively. There are 89 RPM packages that constitutes Ruby on Rails 5.0. To build Ruby on Rails 5.0 completely from scratch, I have to build the packages total 103 times considering bootstrap. I am trying to build those packages automatically by a tool [1] with a configuration file [2] for Ruby on Rails. It is important to fix it due to that. Fortunately today another guy Vit created new ticket for that. So, if YOU like this proposal, please comment in below page of the ticket or reply here. It is helpful for us to move this huge rock. I really want to fix it. "I like it." comment please. => https://pagure.io/packaging-committee/issue/684 Thank you for your help. [1] https://github.com/sclorg/rpm-list-builder [2] https://github.com/sclorg/rhscl-rebuild-recipes/blob/master/ror.yml Kind regards, Jun Aruga

10 27

Package Guidelines: Should config files follow upstream or Fedora defaults?
by Christopher Engelhard 23 Oct '18

23 Oct '18

Hi, I've recently created a package for SSHGuard [1]. SSHGuard is a program to block brute-force attacks on SSH and other services, similar to fail2ban/etc. Now, my issue is the following: - SSHGuard is completely agnostic with respect to the firewall-backend it uses and the logs it reads. Accordingly, it ships with an example config file that does not set either backend or logreader, the user has to do that themselves. There are, however, commented example lines configuring iptables + journald. - Fedora, obviously, by default uses firewalld and journald. What is the guideline for packaging software like this: 1) Leave it as upstream ships it. - user will have to configure the package before it becomes functional - no dependency on any non-essential packages 2) ship example config file as real config file, with upstream's example config activated - package works out-of-the-box - introduces additional, non-default dependency (iptables) 3) ship custom config file preconfigured for Fedora defaults - package works out-of-the-box - introduces dependency on default Fedora packages (firewalld) Granted, option (2) is rather silly, but is (1) or (3) the correct way to go about configuring the package? Best, Christopher [1] https://copr.fedorainfracloud.org/coprs/lcts/sshguard/ [2] https://www.sshguard.net/

5 9

New major version of forge macros in redhat-rpm-config
by Nicolas Mailhot 22 Oct '18

22 Oct '18

Hi, As some of you have noticed a major rework of the forge macros has finally landed in rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1155046 (helpers to package projects hosted on Gitlab, Github, Googlecode, Bitbucket, etc) It adds the ability to process multiple source archives in a single spec. That was the main missing feature, pointed out by reviewers during the initial integration last year. If you do not need the feature there should be no intentional change in the way the macros behave. If you do need it it's now possible via two switches: 1. -z <number>: process the numberth block of definitions in the spec file 2. -a: process every blocks of source definitions in one go, without separate -z calls A contrived spec example that pulls every kind of source the macro supports right now is given in: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35 The last version of the macros was documented through https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation That proved not too successful. The wiki page was a lot of effort to write and maintain, packagers do not read it, FPC never figured how to integrate it in guidelines. And then there is the new docs project. Therefore, I now intend to drop this wiki page. And just ship some example spec templates in a redhat-rpm-config subpackage or somewhere else¹. That should be easier to maintain, to audit, to keep up to date, and to use by Fedora packagers. Calling the same block of macro code several times with different settings, and without side effects, in the same spec, required a huge amount of cleanups and refactoring. Including, bugfixes in rpm itself. Thus, while there is no intentional behaviour change for packagers that only use a single source archive in their spec, the cleanups may change or remove some undocumented and unintended ways to use the macros that were possible in the previous version. For those reasons, while a backport to stable or even epel-rpm-macros is planed, it won't occur immediately. If you are the maintainer of complex packaging macros in Fedora, the whole content of https://src.fedoraproject.org/rpms/redhat-rpm-config/c/c70110c677904a188d66… may be of interest. Implementing this feature required lots of macro infra work which is completely generic and not forge-specific. If you are just a rpm macro user, you can ignore this plumbing. Many thanks to the redhat-rpm-config maintainers that had the thankless task to help me do things that were never done or possible before. Evaluating new code, without a past reference to build upon, is always scary. Best regards, ¹ That mostly depends on what FPC decides in https://pagure.io/packaging-committee/issue/813 -- Nicolas Mailhot

1 0

Schedule for Thursday's FPC Meeting (2018-10-18 16:00 UTC)
by James Antill 18 Oct '18

18 Oct '18

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2018-10-18 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2018-10-18 09:00 PDT US/Pacific 2018-10-18 12:00 EDT --> US/Eastern <-- 2018-10-18 16:00 UTC UTC 2018-10-18 17:00 BST Europe/London 2018-10-18 18:00 CEST Europe/Berlin 2018-10-18 18:00 CEST Europe/Paris 2018-10-18 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2018-10-19 00:00 HKT Asia/Hong_Kong 2018-10-19 00:00 +08 Asia/Singapore 2018-10-19 01:00 JST Asia/Tokyo 2018-10-19 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 #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 = 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

Fonts packaging macros rework early peek
by Nicolas Mailhot 16 Oct '18

16 Oct '18

Hi, To all that may concern (mainly, packagers of things that include font files). I’m currently reworking the font automation I created for Fedora 10 years ago. You can get an early peek at the result here: https://copr.fedorainfracloud.org/coprs/nim/fontpackages-2/ The main objectives of the rework are: * make it easier to use * generate appstream files automatically, and validate the result * you can of course handcraft your own appstream file, or use the one shipped by your upstream, if that thing actually exists * remove more boilerplate code in the specs * move to a more declarative syntax * it is slightly more verbose but you don't need to remember magic macro flags, just to cut and paste a block of variables and fill in their values * remove historical implementation quirks * enforce Fedora naming guidelines some more at the macro level, since reading those is too much work for some packagers * completely cut the relationship between font subpackages and the srpm they’re generated from, so any Fedora package that includes fonts can use those without side effects on the rest of the spec * move to generic macro naming, that can be templated away by rpm in the future So, it's a technical implementation rework, without any change in the packaging principles that exist in current guidelines. At this stage I'm pretty sure the way macros will be used in specs is stabilized, so you can take a look at the specs in copr and comment if there are things you'd like to be done differently. The declaration order is not too intuitive, mostly because it differs from Fedora habits, but each change was driven by rpmbuild, copr or mock requirements, so don't order things back unless you want to discover the hard way why it needs to be like that. Finally, I do realise the proposal, if accepted, will mean rewriting part of existing font specs at one point, which no one wants to do, but: 1. it's less work than writing appstream files and the associated spec code manually (do *you* validate your appstream files correctly today in your specs?), 2. it mostly involves removing spec lines → less lines for packagers to maintain in the future 2. I did this work for my own font packages, and there are lots of them, so believe me I tried to make it as simple as possible, starting for myself 4. I don't think some spec churn every 10 years is too much to ask The remaining todo is mainly to clean up the layout of the macro package itself, write templates, and do some guidelining (and bug fixing, if needed). If you want to rebuild any of the packages or specs on you system you need the redhat-rpm-config and rpm version in copr, as the font macros depend on their changes. Those changes are currently being integrated in rawhide for other reasons, and a backport to stable is also on the agenda. You’ll see in the copr some badly needed updates to some important Fedora font packages (dejavu, stix, droid, etc). I officially suck at updates. I'm reworking things to help me suck less. Also, I took the opportunity to package some font families that should have been packaged quite a long time ago (not necessarily by myself). All this will hit rawhide and reviews once the macro work is done. Regards, -- Nicolas Mailhot

1 0

Schedule for Thursday's FPC Meeting (2018-10-11 16:00 UTC)
by James Antill 11 Oct '18

11 Oct '18

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2018-10-11 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2018-10-11 09:00 PDT US/Pacific 2018-10-11 12:00 EDT --> US/Eastern <-- 2018-10-11 16:00 UTC UTC 2018-10-11 17:00 BST Europe/London 2018-10-11 18:00 CEST Europe/Berlin 2018-10-11 18:00 CEST Europe/Paris 2018-10-11 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2018-10-12 00:00 HKT Asia/Hong_Kong 2018-10-12 00:00 +08 Asia/Singapore 2018-10-12 01:00 JST Asia/Tokyo 2018-10-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 = Followups = #topic #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 = 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

[RFC] Default rpm macro packaging layout and conventions
by Nicolas Mailhot 10 Oct '18

10 Oct '18

Hi, I'd like Fedora and FPC in general to agree to a general layout for macros and their associated material like templates, so the next step can focus on the actual macros and their documentation, and not on how the result is shipped to users. https://pagure.io/packaging-committee/issue/813 The reason being I'm currently wrapping up three sets of rpm macros for Fedora⁰. The coding and first-pass testing for each macro set is mostly done, the next step is packaging, documenting, and guideline-ing. I'd like to do the documenting and guideline-ing for each macro set via standard templates. Wiki (or the new docs site) is a huge time sink to write and update, and most packagers do not read the result, so it's mostly a waste of time. OTOH templates are operational and do work. Thus with hindsight, a short paragraph in guidelines that points to a package of templates, works loads better than a wall of wiki text Here is how I understand today's Fedora best practices. To my knowledge, they are mostly unwritten packager lore. (obviously stuff in redhat-rpm-config is a special case) %<-- A. A single project hosts macros, templates, readmes, so everything is kept in sync B. For macros that process <foo> material, the project is named <foo>-macros or <foo>packages (which one does FPC prefer?) C. The project SHOULD be hosted on Fedora infra, or a cross-distro hosting site (ie pagure.io, even if I find it severely limitating from a forge POW) D. The result is packaged as a <foo>-macros or <foo>packages srpm (whichever FPC chose in B) E. The srpm CAN BuildRequire anything (though usually it will be composed of macros, docs, scripts, that do not need much building, anything binary is likely to end up in its own package that is then BuildRequired) F. This srpm generates the following subpackages (using -n, otherwise you end up with very awkward package names) F.1 A package named <foo>-srpm-macros, sufficient to create <foo> srpms: * this package MUST be in the default build root (buildsys group) * it MUST NOT require anything: we want builds to be fast and efficient, and package ecosystems not to pollute the builds of other package ecosystem * it MUST define a pivot macro expected to be present in every <foo> spec * this macro SHOULD generate a BuildRequires on <foo>-rpm-macros * this package MUST define every other macro or constant needed by rpmbuild to assemble <foo> srpms (mostly, anything dealing with <foo> sources or the SRPM name) F.2 A package named <foo>-rpm-macros, sufficient for the build stage of <foo> packages * this package MUST NOT assume it can be in the default build root * it CAN and SHOULD Require anything typically needed to build <foo> packages. Require restrictions are for <foo>-srpm-macros, not <foo>-rpm-macros * anything used in %prep, %build, %install, %check, or to compute <foo>-style deps * for example: for Go packages, the Golang compiler, for fonts packages, fontconfig * it MUST provide the associated macros and constants (typically the constant defining standard filesystem locations for <foo> stuff) * it MUST require <foo>-filesystem * it SHOULD NOT be necessary to install <foo> packages once built, not be depended on by those packages F.3 A package named <foo>-filesystem * this package MUST materialize and own the filesystem locations defined in <foo>-rpm-macros * this package MUST NOT require anything except other filesystem-style packages * this way it can be depended on by <foo> packages without pulling in all the build infra of <foo>-rpm-macros F.4 A package named <foo>packages-devel ? <foo>-macros-devel ? <foo>packages-templates ? <foo>-macro-templates ? What is the FPC preference? * this package SHOULD depend on rpmdevtools * this package SHOULD provide at least one template in %{_sysconfdir}/rpmdevtools/ showing how <foo> macros are supposed to be used * this package SHOULD contain every other additionnal documentation file, necessary to understand those templates * this package SHOULD NOT be necessary to install <foo> packages once built, not be depended on by those packages F.5 A package named <foo>packages-tools ? <foo>-macros-tools ? What is the FPC preference? * holds anything not strictly necessary to run the macros or understand the templates, but can be useful to some packages, typically convenience scripts %<-- Did I get this right or did i forget something important? Regards, ⁰ 1. "forge macros" v2 (v1 was merged in redhat-rpm-config 9 months ago) macros to map <url,version,tag,commit,branch> metadata to classical rpm Source, URL, %setup, %dist, etc verbs, when a project is hosted on Gitlab, GitHub, etc (*not* Pagure because Pagure is missing needed functionality). There are hundreds if not thousands of packages in the distro that can make use of this. v2 adds the ability to process multiple archives in a single source rpm.¹ 2 "go macros" v2 (v1 was merged in go-compilers and go-srpm macros about the same time as the forge macros) automation for packaging software written in the Go language (Go language). Go is getting huge nowadays, it's the language in which kubernetes, docker, and a lot of cloud infra software is being written today. This is really why I'm doing all this, the forge macros are just a spinoff of generic non-Go-specific functionality that Go macros need. v2 add the ability to process multiple archives in a single source rpm, and Go BuildRequires automation (one of the huge missing bits in the v1)² 3 font macros v2 (v1 + associated guidelines were written by myself around a decade ago) Another spinoff of 1. and 2. Mostly because golang-x-image is the upstream of the Go fonts, which has caused me to revisit the subject. With the framework code written for 1., ten years of hindsight, experience, and rpm improvements, I can and did write macros that remove known problems in the current set, add missing functionalities like appstream handling, and are generally more convenient to use (took me about a week-end of hacking)³ ¹ A first version has already been completed and merged in redhat-rpm-config 9 months ago. Thanks to everyone involved. https://src.fedoraproject.org/rpms/redhat-rpm-config/c/7c4cd330850ee228ca72… It worked and still works fine, you can use it today in your packages, but it has a huge limitation: it assumes you only need to process a single source archive in the specfile. People rightly pointed out in the review that, while it's the general and preferred case, some packages do need to mix source archives (esp. on EL given the hard constrains EL has on not touching existing package layout). Therefore I've prepared a new version that *can* process multiple sources. It's backwards-compatible, multi-source is achieved via new flags, in the absence of those flags it will assume a single source like the current merged code does. https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35 It adds a huge level of complexity macro-side, rpm does not really provide the framework to do this kind of multiplexing, the framework had to be coded from scratch in lua macro code. However, the framework has been coded now, it's generic, and rightly belongs in a generic package like redhat-rpm-config ² Currently in the final stages of technical testing before I document it and send a PR https://github.com/nim-nim/go-macros/commits/dev ³ Currently past the technical testing, need to document it, send myself a PR, send the result to FPC and the Fonts SIG to switch existing packaging guidelines -- Nicolas Mailhot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging October 2018