packaging January 2018

packaging@lists.fedoraproject.org

24 participants
14 discussions

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

Proposed Fedora packaging guideline: More Go packaging
by nicolas.mailhot＠laposte.net 04 Mar '18

04 Mar '18

Hi, I am proposing for inclusion a set of rpm technical files aimed at automating the packaging of forge-hosted projects. - Packaging draft: https://fedoraproject.org/wiki/More_Go_packaging - https://pagure.io/packaging-committee/issue/734 - go-srpm-macros RFE with the technical files: https://bugzilla.redhat.com/show_bug.cgi?id=1526721 This proposal is integrated with and depends on the https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft It builds on the hard work of the Go SIG and reuses the rpm automation of https://fedoraproject.org/wiki/PackagingDrafts/Go when it exists, and produces compatible packages. What it does: - drastically shorter spec files, up to 90% in some cases, often removing hundreds of lines per spec. - simple, packager-friendly spec syntax - automated package naming derived from the native identifier (import path). No more packages names without any relation with current upstream naming. - working Go autoprovides. No forgotten provides anymore. - working Go autorequires. No forgotten requires anymore. - strict automated directory ownership (used by autorequires and autoprovides). - centralized computation of source URLs (via Forge-hosted projects packaging automation). No more packages lacking guidelines. No more broken guidelines no one notices. - easy switch between commits, tags and releases (via Forge-hosted projects packaging automation). No more packages stuck on commits when upstream starts releasing. - guidelines-compliant automated snapshot naming, including snapshot timestamps (via Forge-hosted projects packaging automation). No more packages stuck in 2014. - guidelines-compliant bootstraping. - systematic use of the Go switches defined by the Go maintainer. Easy to do changes followed by a mass rebuild. - flexibility, do the right thing transparently by default, leave room for special cases and overrides. - no bundling (a.k.a. vendoring) due to the pain of packaging one more Go dependency. - centralized Go macros that can be audited and enhanced over time. - aggressive leverage of upstream unit tests to detect quickly broken code. Please consult packaging draft for full information. The proposal has been tested in Rawhide and EL7 over a set of ~ 140 Go packages. This set is a mix of current Fedora packages, bumped to a more recent version, rewrites of Fedora packages, and completely new packages. I hope posting the second part of the automation will answer some questions people had on the https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation draft Regards, -- Nicolas Mailhot

8 34

Maintaining Package Branches (on COPR)
by Evan Klitzke 12 Feb '18

12 Feb '18

Hi, I have a couple of packages on Fedora COPR, and right now I am just building the same version of the RPM for all the Fedora releases I support. Upstream for one of these projects has released a release candidate, and I would like to package the release candidate for Rawhide only. Is it possible to set this up in an automated way? If so, how? The way I intuitively expect this to work is based on y experience with Debian where I would use different git branches in my package repo for different Debian releases. I didn't see anything like this in the COPR build options, but I'm pretty new to the Fedora packaging ecosystem so this might just be PEBCAK? And how is this typically managed for the "real" Fedora package repos? Thanks, Evan

2 1

help with first package (extractpdfmark, bug 1520922)
by Federico Bruni 05 Feb '18

05 Feb '18

Hi all I've recently submitted my first package here: https://bugzilla.redhat.com/show_bug.cgi?id=1520922 I need some pointer to figure out how to solve a few issues highlighted by the reviewer. There's a lot of information in Fedora wiki, but it's quite overwhelming. I've read a lot, but cannot find the information I need. The problems still to be solved are: [!]: Package does not own files or directories owned by other packages. Note: Dirs in package are owned also by: /usr/lib/.build-id(iputils, efivar-libs, gd, gc, libtomcrypt, gdbm, gpgme, rpm-plugin-selinux,[... cut] [!]: %build honors applicable compiler flags or justifies otherwise. [!]: Package contains no bundled libraries without FPC exception. [!]: Package complies to the Packaging Guidelines BTW, rpmlint does not spot these errors. So I've tried fedora-review and run this command in my RPM package directory: fedora-review --define DISTTAG=fc27 -p -n extractpdfmark and I see that above problems are set to "manual review needed". So the errors were spotted by the reviewer, not by any tool. Back to above problems, the errors related to the libraries are probably about the .build-id directory, but I cannot figure out what should I do. $ rpm -ql x86_64/extractpdfmark-1.0.2-1.fc27.x86_64.rpm /usr/bin/extractpdfmark /usr/lib/.build-id /usr/lib/.build-id/41 /usr/lib/.build-id/41/8cd205d31cf37c25cec9711715265e6c00726b /usr/share/doc/extractpdfmark /usr/share/doc/extractpdfmark/COPYING /usr/share/doc/extractpdfmark/README.ja.md /usr/share/doc/extractpdfmark/README.md /usr/share/licenses/extractpdfmark /usr/share/licenses/extractpdfmark/COPYING /usr/share/man/man1/extractpdfmark.1.gz Thanks in advance Federico

6 16

fedpkg mockbuild and cmake not found
by cedlemo 30 Jan '18

30 Jan '18

Hi, I am trying to build a package that uses cmake and I followed these documentations: - https://fedoraproject.org/wiki/How_to_create_an_RPM_package - https://fedoraproject.org/wiki/Packaging:Cmake Here is the spec file: `````````````````````````````````````````````````````````````````````````````````````````````````````` Name: clasp Version: 3.3.3 Release: 1%{?dist} Summary: A conflict-driven nogood learning answer set solver Group: Applications/Engineering License: MIT URL: http://www.cs.uni-potsdam.de/clasp/ Source0: https://github.com/potassco/clasp/releases/download/v%{version}/%{name}-%{v… BuildRequires: cmake-rpm-macros %description clasp is an answer set solver for (extended) normal and disjunctive logic programs. It is part of the Potassco project for Answer Set Programming (ASP). The primary algorithm of clasp relies on conflict-driven nogood learning, a technique that proved very successful for satisfiability checking (SAT). clasp has been genuinely developed for answer set solving but can also be applied as a (Max-)SAT or PB solver or as a C++ library in another program. It provides different reasoning modes and other advanced features. %prep %autosetup -n %{name}-%{version} [GitHub] %build %cmake . %make_build %install %make_install %check ctest -V %{?_smp_mflags} ````````````````````````````````````````````````````````````````````````````````````````````````````` In the directory, I get the tarball with: spectool -g clasp.spec Then I launch the build with fedpkg --release f27 mockbuild But it fails with : /var/tmp/rpm-tmp.8htWxw: line 38: /usr/bin/cmake: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.8htWxw (%build) I can not see how to fix it. Any ideas ? Thanks Cédric Le Moigne.

2 1

Summary/Minutes from today's FPC Meeting (2018-01-24 18:00 - 19:00 UTC)
by James Antill 24 Jan '18

24 Jan '18

====================== #fedora-meeting-2: fpc ====================== Meeting started by geppetto at 18:22:59 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2018-01-24/fpc.2018- 01-24-18.22.log.html . Meeting summary --------------- * Roll Call (geppetto, 18:22:59) * Schedule (geppetto, 18:23:33) * LINK: https://lists.fedoraproject.org/archives/list/packaging@lists.fedor aproject.org/message/HQV64UZOCVCNVAX6H74R7K4PVY337DTS/ (geppetto, 18:23:34) * #729 How to handle non-informative package reviews? .fpc 729 (geppetto, 18:24:20) * ACTION: Close as we can't really do much unless the reviewer is very obviously doing bad things. (geppetto, 18:28:24) * Maybe start a discussion on fedora-devel-list (geppetto, 18:28:36) * #731 Testing guidelines .fpc 731 (geppetto, 18:29:03) * #731 (geppetto, 18:29:09) * ACTION: Everything seems fine as it is (geppetto, 18:32:22) * If you want to create a draft to propose a change feel free to open a ticket (however we are generally against listing every single testing framework) (geppetto, 18:32:50) * #733 'users and groups' should link to prealloc. list (geppetto, 18:33:04) * ACTION: Link will stay removed, as it doesn't seem useful. (geppetto, 18:37:07) * If you have reasons for needing this information, feel free to open another ticket with a draft policy change. (geppetto, 18:37:34) * #737 Allocating a soft static uid and gid 389 for dirsrv (geppetto, 18:37:55) * ACTION: tibbs Will point to the guidlines with the process to do what they want. (geppetto, 18:42:27) * #726 Review for SELinux Independent Policy packaging Draft (geppetto, 18:42:55) * ACTION: tibbs Will work with you to try to extract the guideline parts of the document (removing stuff about setting up github etc.) (geppetto, 18:46:43) * Open Floor (geppetto, 18:47:48) * #744 Make packaging guidelines Fedora only (geppetto, 18:49:07) * +4 on the proposal, geppetto; limburgher; tibbs; mbooth (geppetto, 18:58:22) Meeting ended at 18:58:32 UTC. Action Items ------------ * Close as we can't really do much unless the reviewer is very obviously doing bad things. * Everything seems fine as it is * Link will stay removed, as it doesn't seem useful. * tibbs Will point to the guidlines with the process to do what they want. * tibbs Will work with you to try to extract the guideline parts of the document (removing stuff about setting up github etc.) Action Items, by person ----------------------- * tibbs * tibbs Will point to the guidlines with the process to do what they want. * tibbs Will work with you to try to extract the guideline parts of the document (removing stuff about setting up github etc.) * **UNASSIGNED** * Close as we can't really do much unless the reviewer is very obviously doing bad things. * Everything seems fine as it is * Link will stay removed, as it doesn't seem useful. People Present (lines said) --------------------------- * geppetto (52) * tibbs (43) * limburgher (28) * zodbot (14) * mbooth (7) * orionp (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Versioning of packages combining projects
by Miroslav Lichvar 24 Jan '18

24 Jan '18

Hi, I'm trying to package ntp-refclock [1], which is a wrapper for reference clock drivers from ntpd to make them usable with other NTP implementations. The package builds code from two projects and I'm not sure what should be the version and release. The guidelines for versioning don't seem to cover this odd case. ntp-refclock-0.1 is combined with ntp-4.2.8p10. The majority of the code compiled for the package comes from ntp (the drivers and some code that the drivers need), so I think the version or release needs to include the ntp version. Would ntp-refclock-0.1-1.ntp4.2.8p10.fc28 work? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1536565 -- Miroslav Lichvar

3 5

Schedule for Wednesday's FPC Meeting (2018-01-24 18:00 UTC)
by James Antill 24 Jan '18

24 Jan '18

Following is the list of topics that will be discussed in the FPC meeting Wednesday at 2018-01-24 18:00 UTC in #fedora-meeting-2 on irc.freenode.net. Local time information (via. uitime): ================= Day: Wednesday ================= 2018-01-24 10:00 PST US/Pacific 2018-01-24 13:00 EST --> US/Eastern <-- 2018-01-24 18:00 GMT Europe/London 2018- 01-24 18:00 UTC UTC 2018-01-24 19:00 CET Europe/Berlin 2018-01-24 19:00 CET Europe/Paris 2018-01-24 23:30 IST Asia/Calcutta --------------- New Day: Thursday ---------------- 2018-01-25 02:00 HKT Asia/Hong_Kong 20 18-01-25 02:00 +08 Asia/Singapore 2018-01-25 03:00 JST Asia/Tokyo 2018-01-25 04: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 #654 glibc file triggers .fpc 654 https://pagure.io/packaging-committee/issue/654 #topic #691 noarch *sub*packages with arch-specific dependencies .fpc 691 https://pagure.io/packaging-committee/issue/691 #topic #693 Wiki:Packaging:RPMMacros .fpc 693 https://pagure.io/packaging-committee/issue/693 #topic #694 Packaging guidelines for application independence .fpc 694 https://pagure.io/packaging-committee/issue/694 #topic #708 Allocating a static uid and gid for openvswitch .fpc 708 https://pagure.io/packaging-committee/issue/708 #topic #710 Ruby packaging guidelines update .fpc 710 https://pagure.io/packaging-committee/issue/710 #topic #713 Forward-looking conditionals by default .fpc 713 https://pagure.io/packaging-committee/issue/713 #topic #714 let's kill file deps! .fpc 714 https://pagure.io/packaging-committee/issue/714 #topic #715 Separately building package documentation .fpc 715 https://pagure.io/packaging-committee/issue/715 #topic #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 #topic #720 Easy way of changing/removing shebangs .fpc 720 https://pagure.io/packaging-committee/issue/720 #topic #723 Guidelines for handling deprecated dependencies during review .fpc 723 https://pagure.io/packaging-committee/issue/723 #topic #726 Review for SELinux Independent Policy packaging Draft .fpc 726 https://pagure.io/packaging-committee/issue/726 = New business = #topic #729 How to handle non-informative package reviews? .fpc 729 https://pagure.io/packaging-committee/issue/729 #topic #731 Testing guidelines .fpc 731 https://pagure.io/packaging-committee/issue/731 #topic #733 'users and groups' should link to prealloc. list .fpc 733 https://pagure.io/packaging-committee/issue/733 #topic #737 Allocating a soft static uid and gid 389 for dirsrv .fpc 737 https://pagure.io/packaging-committee/issue/737 = 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, or 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

Which Fedora/EPEL is targeted by packaging guidelines?
by Vít Ondruch 22 Jan '18

22 Jan '18

Hi all, Reading logs from yesterdays FPC meeting [1], I think we should discuss what is actually purpose of packaging guidelines and which version of Fedora/EPEL/RHEL they actually targets. Apparently, there are two camps of packagers in Fedora/EPEL. Those who want: 1) single version of .spec file to cover the whole Red Hat ecosystem. 2) clean .spec file following the latest and greatest packaging practices. I personally belong to the group (2) and that is for several reasons: a) I use Rawhide on daily basis and I develop only for Rawhide. If I do changes in older Fedoras, then it is typically just bug fixes and honestly, that does not happen often (I am POC of ~200 packages and I submitted just 40 updates during last year [2]). And in fact, this is official philosophy of updates [3], not just mine. b) I spent time developing features which should simplify packaging (for example in F27+, the RPM %setup macro can expand the .gem packages) and I want to use these technologies to simplify my life and life of others. c) As a proven packager and person who typically does rebuild of Ruby packages, I really hate the branched .spec files where nobody knows what was the purpose of the branches, most of the branches are for obsolete and unsupported releases etc. It is quite hard to apply any improvements into such packages. Moreover it is not realistic to test them. If they were maintained, it would be different story, but the reality is different. Don't get me wrong, I understand that there are packagers who has just handful of packages and it is better for them to maintain just single .spec file with all the branches and I don't mind them as long as the packages are really actively maintained. But this approach just don't scale and should be exception and not recommended practice. To sum this up, my take on packaging guidelines is that *the guidelines should document the most recent practices available in Rawhide and this should be documented*. Covering all the exceptions necessary for older Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable and what is worse, they slow down entire development of Fedora. Vít [1] https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject… [2] https://bodhi.fedoraproject.org/updates/?user=vondruch [3] https://pagure.io/packaging-committee/issue/710

6 11

Documenting C/c++ build flags
by Florian Weimer 19 Jan '18

19 Jan '18

Would it be appropriate to document the various build flags we use (mostly via redhat-rpm-config) in this page? <https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B> This would be the natural place to include this information, but the process for updating this page seems to be a bit complicated. Can you suggest any alternatives? Thanks, Florian

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging January 2018