packaging May 2017

packaging@lists.fedoraproject.org

15 participants
15 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

It is legitimate to refer to a third-party repository
by Martin Gansser 02 Jun '17

02 Jun '17

I am working on a package review of nuvola-app-amazon-cloud-player [1] It is legitimate to refer to a 3rd party repository i.e. # https://www.if-not-true-then-false.com/2010/install-adobe-flash-player-10-o… Recommends: flash-plugin [1] https://bugzilla.redhat.com/show_bug.cgi?id=1455886 Thanks for any response.

2 3

Schedule for Thursday's FPC Meeting (2017-06-01 16:00 UTC)
by James Antill 31 May '17

31 May '17

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2017-06-01 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2017-06-01 09:00 PDT US/Pacific 2017-06-01 12:00 EDT --> US/Eastern <-- 2017-06-01 16:00 UTC UTC 2017-06-01 17:00 BST Europe/London 2017-06-01 18:00 CEST Europe/Paris 2017-06-01 18:00 CEST Europe/Berlin 2017-06-01 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2017-06-02 00:00 +08 Asia/Singapore 2017-06-02 00:00 HKT Asia/Hong_Kong 2017-06-02 01:00 JST Asia/Tokyo 2017-06-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 = New business = #topic #686 Avoid using names with `python-` prefix in requires .fpc 686 https://pagure.io/packaging-committee/issue/686 #topic #687 Repository config/COPr policy conflicts with FESCo policy .fpc 687 https://pagure.io/packaging-committee/issue/687 #topic #688 Council banned weak fwd deps to third party repos .fpc 688 https://pagure.io/packaging-committee/issue/688 = 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://fedorahosted.org/fpc, 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: Reminder: GitHub etc. auto-generated archives are not stable in time
by Jan Pokorný 25 May '17

25 May '17

On 25/05/17 00:28 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, May 24, 2017 at 05:22:43PM +0200, Jan Pokorný wrote: >> On 24/05/17 09:58 -0500, Jorge Gallegos wrote: >>> On Wed, May 24, 2017 at 04:19:05PM +0200, Jan Pokorný wrote: >>>> today, I've accidentally attested there are no stability guarantees >>>> with the on-demand archives from common git hosting sites when preparing >>>> a new pacemaker update, redownloading "spectool -s 0 pacemaker.spec" >>>> of the original (-0.1.rc1, from 2 weeks ago) spec and comparing the >>> >>> Are you pointing to a _tag_ (or as github likes to call them: release) ? >>> As far as I know tags can be re-created, isn't that what is happening >>> here? >> >> Nope, the point is that nothing has changed in the codebase or, for >> that matter, tags. It must have been GitHub that changed how its >> equivalent of "git archive" behaves. >> >>>> hashes, which (surprisingly to me) didn't match (they were at any similar >>>> test in the past). Then I looked at the adiff output: >>>> >>>>> diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac >>>>> --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200 >>>>> +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200 >>>>> @@ -1159,7 +1159,7 @@ >>>>> AC_PATH_PROGS(GIT, git false) >>>>> AC_MSG_CHECKING(build version) >>>>> >>>>> -BUILD_VERSION=0459f40 >>>>> +BUILD_VERSION=0459f40958 >>>>> if test != ":%h$"; then >>>>> AC_MSG_RESULT(archive hash: ) >>>> >>>> for configure.ac that indeed has export-subst git attribute set >>>> and the change itself arises from "$Format:%h$" substitution. >>>> This likely means GitHub was internally updated to use equivalent >>>> of git 2.11 feature of abbreviation length autoscaling within >>>> last 14 days. >>> >>> This is the other bit that makes me think it was actually the >>> maintainers hand that moved this, I don't believe github does anything >>> special to the code once it's stored there. There is no way for github >>> to alter code afaik? >> >> Once more, see "git help archive", ATTRIBUTES section, export-subst >> in particular. That exactly stands for the varying part, which is >> implementation-specific, and GH implementation has apparently changed, >> leading to changed contents of numerous archives to be downloaded from >> that very point. > > Well, the title of your mail implies that *any* archive changed. Of course, any such archives can change bitwise in between two arbitrary moments, simply because some variable in the archiving process can change (is even file list linearization assuredly stable?). I've left that, obvious for some, aspect aside in the email body, because a changed content is what seems to be entirely new, at least to me. It means that also alternative checksuming approaches (zcat archive | sha512sum) are disqualified from the attempts to deal with such instabilities. > What changed in fact is an archive with %h subst. But %h is > inherently unstable: when commits are added to the archive, git will > extend the generated abbreviation length to maintain uniqueness. This is how the original git implementation was changed recently, but it doesn't mean any implementation has to behave that way, and who knows what these proprietary services use. > I think the error here is in relying on stability %h substitution > over time. I'd say more broadly that the error is to rely on stability of auto-generated archives as such. In that light, Colin's git-evtag project looks appealing for upstreams that do not provide their own stable tarballs. -- Jan (Poki)

1 0

Re: Reminder: GitHub etc. auto-generated archives are not stable in time
by Jan Pokorný 24 May '17

24 May '17

On 24/05/17 09:58 -0500, Jorge Gallegos wrote: > On Wed, May 24, 2017 at 04:19:05PM +0200, Jan Pokorný wrote: >> today, I've accidentally attested there are no stability guarantees >> with the on-demand archives from common git hosting sites when preparing >> a new pacemaker update, redownloading "spectool -s 0 pacemaker.spec" >> of the original (-0.1.rc1, from 2 weeks ago) spec and comparing the > > Are you pointing to a _tag_ (or as github likes to call them: release) ? > As far as I know tags can be re-created, isn't that what is happening > here? Nope, the point is that nothing has changed in the codebase or, for that matter, tags. It must have been GitHub that changed how its equivalent of "git archive" behaves. >> hashes, which (surprisingly to me) didn't match (they were at any similar >> test in the past). Then I looked at the adiff output: >> >>> diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac >>> --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200 >>> +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200 >>> @@ -1159,7 +1159,7 @@ >>> AC_PATH_PROGS(GIT, git false) >>> AC_MSG_CHECKING(build version) >>> >>> -BUILD_VERSION=0459f40 >>> +BUILD_VERSION=0459f40958 >>> if test != ":%h$"; then >>> AC_MSG_RESULT(archive hash: ) >> >> for configure.ac that indeed has export-subst git attribute set >> and the change itself arises from "$Format:%h$" substitution. >> This likely means GitHub was internally updated to use equivalent >> of git 2.11 feature of abbreviation length autoscaling within >> last 14 days. > > This is the other bit that makes me think it was actually the > maintainers hand that moved this, I don't believe github does anything > special to the code once it's stored there. There is no way for github > to alter code afaik? Once more, see "git help archive", ATTRIBUTES section, export-subst in particular. That exactly stands for the varying part, which is implementation-specific, and GH implementation has apparently changed, leading to changed contents of numerous archives to be downloaded from that very point. Is/will the pagure.io be immune to this sort of retroactive changes once/if such tarball extraction is implemented (see https://pagure.io/pagure/issue/861)? > This would suggest to me the maintainer: > > a) Modified the code (either via script or otherwise) > b) Deleted the tag (and thus, the github "release") > c) Submitted a new tag (and created a new gh release) > > Of course if the .spec is pointing to an archive url pointing to a git > SHA my theory is busted. > >> >> Hope this will be useful for some (e.g. fedora-review tool >> has a check to redownload and diff sources against SRPM content, >> IIRC). -- Poki

1 0

Reminder: GitHub etc. auto-generated archives are not stable in time
by Jan Pokorný 24 May '17

24 May '17

Hello, today, I've accidentally attested there are no stability guarantees with the on-demand archives from common git hosting sites when preparing a new pacemaker update, redownloading "spectool -s 0 pacemaker.spec" of the original (-0.1.rc1, from 2 weeks ago) spec and comparing the hashes, which (surprisingly to me) didn't match (they were at any similar test in the past). Then I looked at the adiff output: > diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac > --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200 > +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 00:55:15.000000000 +0200 > @@ -1159,7 +1159,7 @@ > AC_PATH_PROGS(GIT, git false) > AC_MSG_CHECKING(build version) > > -BUILD_VERSION=0459f40 > +BUILD_VERSION=0459f40958 > if test != ":%h$"; then > AC_MSG_RESULT(archive hash: ) for configure.ac that indeed has export-subst git attribute set and the change itself arises from "$Format:%h$" substitution. This likely means GitHub was internally updated to use equivalent of git 2.11 feature of abbreviation length autoscaling within last 14 days. Hope this will be useful for some (e.g. fedora-review tool has a check to redownload and diff sources against SRPM content, IIRC). -- Jan (Poki)

1 0

Summary/Minutes from today's FPC Meeting (2017-05-18 16:00 - 16:40 UTC)
by James Antill 18 May '17

18 May '17

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 15:59:47 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2017-05-18/fpc.2017- 05-18-15.59.log.html . Meeting summary --------------- * Roll Call (geppetto, 15:59:47) * Schedule (geppetto, 16:08:52) * LINK: https://lists.fedoraproject.org/archives/list/packaging@lists.fedor aproject.org/message/Y4VNSV76Z45ZZ4CFNKB73FI7YAP3RYMQ/ (geppetto, 16:08:54) * #685 Enforce new naming scheme for Python binary packages (geppetto, 16:09:01) * Open Floor (geppetto, 16:17:53) * ACTION: Enforce new naming scheme for Python binary packages (tibbs change) (+1:5, 0:0, -1:0) (geppetto, 16:35:12) * ACTION: Exemption from review, for affected python packages being changed with the help of Python SIG (+1:5, 0:0, -1:0) (geppetto, 16:38:13) Meeting ended at 16:40:44 UTC. Action Items ------------ * Enforce new naming scheme for Python binary packages (tibbs change) (+1:5, 0:0, -1:0) * Exemption from review, for affected python packages being changed with the help of Python SIG (+1:5, 0:0, -1:0) Action Items, by person ----------------------- * tibbs * Enforce new naming scheme for Python binary packages (tibbs change) (+1:5, 0:0, -1:0) * **UNASSIGNED** * Exemption from review, for affected python packages being changed with the help of Python SIG (+1:5, 0:0, -1:0) People Present (lines said) --------------------------- * geppetto (55) * tibbs (32) * limburgher (13) * zodbot (11) * mbooth (8) * orionp (3) * cstratak (2) * Kellin (2) * langdon_ (2) * pviktori_ (1) * ishcherb (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Schedule for Thursday's FPC Meeting (2017-05-18 16:00 UTC)
by James Antill 17 May '17

17 May '17

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2017-05-18 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): ================= Day: Thursday ================== 2017-05-18 09:00 PDT US/Pacific 2017-05-18 12:00 EDT --> US/Eastern <-- 2017-05-18 16:00 UTC UTC 2017- 05-18 17:00 BST Europe/London 2017-05-18 18:00 CEST Europe/Paris 2017-05-18 18:00 CEST Europe/Berlin 2017-05-18 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2017-05-19 00:00 +08 Asia/Singapore 201 7-05-19 00:00 HKT Asia/Hong_Kong 2017-05-19 01:00 JST Asia/Tokyo 2017-05-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 = New business = #topic #685 Enforce new naming scheme for Python binary packages .fpc 685 https://pagure.io/packaging-committee/issue/685 = 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://fedorahosted.org/fpc, 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

Should I remove firmwares from source?
by Mattia Verga 16 May '17

16 May '17

I'm packaging PHD2 [1] and I already removed a lot of pre-built libraries which are only needed for Mac or Win. My doubts are for cameras/qhyccdlibs/*.a, cameras/qhyccdlibs/qhyfirmware.zip and cameras/zwolibs/*.a: should I remove them, and so remove support for those cameras under Fedora? Thanks Mattia [1] https://github.com/OpenPHDGuiding/phd2

2 2

Summary/Minutes from today's FPC Meeting (2017-05-11 16:00 - 16:45 UTC)
by James Antill 11 May '17

11 May '17

====================== #fedora-meeting-1: fpc ====================== Meeting started by geppetto at 16:00:09 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2017-05-11/fpc.2017- 05-11-16.00.log.html . Meeting summary --------------- * Roll Call (geppetto, 16:00:09) * Schedule (geppetto, 16:06:18) * LINK: https://lists.fedoraproject.org/archives/list/packaging@lists.fedor aproject.org/message/W7KCY7FUUTKIHAAUGDMEYCIMIOOEFSDB/ (geppetto, 16:06:21) * #684 Fix bootstrap guidelines (geppetto, 16:06:32) * ACTION: Fix bootstrap guidelines (+1:5, 0:0, -1:1) (geppetto, 16:40:48) * Open Floor (geppetto, 16:42:18) Meeting ended at 16:45:03 UTC. Action Items ------------ * Fix bootstrap guidelines (+1:5, 0:0, -1:1) Action Items, by person ----------------------- * **UNASSIGNED** * Fix bootstrap guidelines (+1:5, 0:0, -1:1) People Present (lines said) --------------------------- * geppetto (48) * racor (11) * tibbs (10) * zodbot (10) * orionp (8) * mbooth (5) * limburgher (3) * ignatenkobrain (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging May 2017