Fixing wrong Bootstrapping part in Guidelines
by Jun Aruga
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
5 years, 1 month
Re: Reminder: GitHub etc. auto-generated archives are not stable in time
by Jan Pokorný
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)
6 years, 6 months
Re: Reminder: GitHub etc. auto-generated archives are not stable in time
by Jan Pokorný
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
6 years, 6 months
Reminder: GitHub etc. auto-generated archives are not stable in time
by Jan Pokorný
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)
6 years, 6 months
Summary/Minutes from today's FPC Meeting (2017-05-18 16:00 - 16:40 UTC)
by James Antill
======================
#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
6 years, 6 months
Schedule for Thursday's FPC Meeting (2017-05-18 16:00 UTC)
by James Antill
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.
6 years, 6 months
Should I remove firmwares from source?
by Mattia Verga
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
6 years, 6 months
Summary/Minutes from today's FPC Meeting (2017-05-11 16:00 - 16:45 UTC)
by James Antill
======================
#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
6 years, 6 months
