packaging December 2017

packaging@lists.fedoraproject.org

21 participants
17 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

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

golang + glide guideline?
by Jonh Wendell 02 Jan '18

02 Jan '18

Hi folks. I'm playing with RPM packaging for the first time, managed to package a golang software: https://copr.fedorainfracloud.org/coprs/jwendell/helm/ (SPEC: https://github.com/jwendell/copr-helm/blob/master/helm.spec). However I have a question: This software in particular uses glide at build time to download its dependencies (glide install), so I did the same at my SPEC file. Is there anything I could do to be able to do an offline build? Thanks.

2 1

Splitting the "sustmi" GNOME Shell extensions into separate packages
by Andrew Toskin 19 Dec '17

19 Dec '17

I originally posted this to the Devel mailing list. I'm working on splitting the "sustmi" GNOME Shell extension subpackages into their own packages. I've opened an issue on the releng pagure page: https://pagure.io/releng/issue/7124 I've also executed `fedpkg retire ...` for the old package on EPEL7, f27, and master. And the package review requests for the newly split packages have passed. The Bugzilla threads are here: * HistoryManager Prefix Search -- https://bugzilla.redhat.com/show_bug.cgi?id=1506428 * WindowOverlay Icons -- https://bugzilla.redhat.com/show_bug.cgi?id=1506429 I *think* I might be done with my part of the process, but I haven't gotten any feedback in a little while. Is there anything else I need to do? Thanks, ~ Andrew Toskin / terrycloth

1 0

Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation
by nicolas.mailhot＠laposte.net 18 Dec '17

18 Dec '17

De: "Adam Williamson" On Sat, 2017-12-09 at 13:34 +0100, nicolas.mailhot(a)laposte.net wrote: >> I don't have a good history with %autosetup :) It tends to hate the patches I produce. > Did you know you still can/have to pass it a prefix level? That tripped > me up for a while. For most cases, you want: > %autosetup -p1 That's probably what I needed last time, but it was faster to add a %patch line than to investigate :). I find out nowadays there are lots of things I could do better if only I had the time to look them up. > If you have patches that apply at different levels, you can't use it, > unless there's a trick I don't know about. My patches are all -p1 as taught by ancient rpm lore, but sometimes I mix patches from other origins and those can be anything. Thanks for the tip, I will try to remember it Regards, -- Nicolas Mailhot

1 2

Summary/Minutes from today's FPC Meeting (2017-12-13 18:00 - 19:00 UTC)
by James Antill 13 Dec '17

13 Dec '17

====================== #fedora-meeting-2: fpc ====================== Meeting started by geppetto at 18:00:17 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2017-12-13/fpc.2017- 12-13-18.00.log.html . Meeting summary --------------- * Roll Call (geppetto, 18:00:17) * Open Floor (geppetto, 18:09:14) * Schedule (geppetto, 18:09:51) * LINK: https://lists.fedoraproject.org/archives/list/packaging@lists.fedor aproject.org/message/3XJ4QVXTJTT4TGLURHJFENNRYEJLQGYW/ (geppetto, 18:10:00) * #726 Review for SELinux Independent Policy packaging Draft (geppetto, 18:10:40) * FPC generally agree we don't want to be documenting selinux policy files. (geppetto, 18:16:32) * #723 Guidelines for handling deprecated dependencies during review (geppetto, 18:16:55) * We generally agree with adding the provides, at least. Need a draft though. (geppetto, 18:24:03) * #720 Easy way of changing/removing shebangs (geppetto, 18:24:21) * #719 Simplify packaging of forge-hosted projects (geppetto, 18:26:29) * Macros need more thought, cleaned up and how to handle corner cases. Maybe look at using parameters. (geppetto, 18:42:02) * It might just be trying to be too smart in general though. (geppetto, 18:42:39) * Open Floor (geppetto, 18:58:48) Meeting ended at 19:02:42 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * tibbs (54) * geppetto (52) * Rathann (43) * zodbot (12) * mbooth (7) * orionp (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Schedule for Wednesday's FPC Meeting (2017-12-13 18:00 UTC)
by James Antill 12 Dec '17

12 Dec '17

Following is the list of topics that will be discussed in the FPC meeting Wednesday at 2017-12-13 18:00 UTC in #fedora-meeting-2 on irc.freenode.net. Local time information (via. uitime): ================= Day: Wednesday ================= 2017-12-13 10:00 PST US/Pacific 2017-12-13 13:00 EST --> US/Eastern <-- 2017-12-13 18:00 GMT Europe/London 2017-12-13 18:00 UTC UTC 2017-12-13 19:00 CET Europe/Berlin 2017-12-13 19:00 CET Europe/Paris 2017-12-13 23:30 IST Asia/Calcutta --------------- New Day: Thursday ---------------- 2017-12-14 02:00 HKT Asia/Hong_Kong 2017-12-14 02:00 +08 Asia/Singapore 2017-12-14 03:00 JST Asia/Tokyo 2017-12-14 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 = 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.

1 0

Re: <DKIM> Re: <DKIM> Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation
by nicolas.mailhot＠laposte.net 12 Dec '17

12 Dec '17

Hi all, Since most participants seems to be in favor of explicit %setup handling, I've updated the wiki and the macro file Regards, -- Nicolas Mailhot

2 1

Proposed Fedora packaging guideline: Forge-hosted projects packaging automation
by nicolas.mailhot＠laposte.net 11 Dec '17

11 Dec '17

Hi, I am proposing for inclusion a macro set aimed at automating the packaging of forge-hosted projects. — Packaging draft: https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation — FPC ticket: https://pagure.io/packaging-committee/issue/719 (without the “hasdraft” tag because I don't know how to add it in pagure) — fedora-rpm-macros RFE with the macro file: https://bugzilla.redhat.com/show_bug.cgi?id=1523779 What it does: conversion of a forge url, version, tag, commit set to the values expected in rpm specfiles, in optional rpm variables. Computation of the corresponding %{dist}. Objective: centralize forge structure know-how in a single technical place, deprecate all the complex manual forge URL handling spread over many Fedora spec files, simplify packaging and spend time on more interesting stuff. What's currently implemented: definitions for github.com and code.googlesource.com (I didn't want to propose stuff I didn't use myself. Adding more definitions is trivial. The macros are in Lua which is change-friendly, no arcane rpm syntax knowledge is needed). Please consult packaging draft for full information. This is a spin-off of the work I'm currently doing on Go packaging, as Go is heavily forge-oriented. I took the time to extract the generic non-Go-specific forge knowledge in a separate macro file. The macros have been heavily tested on real-life Go projects with quite a lot of variance, on EL7 and rawhide. That's why they come with built-in error handling. Regards, -- Nicolas Mailhot

5 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging December 2017