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
Hello all, I was using gvsig (www.gvsig.com) and want to package it for
fedora.
gvSIG uses maven for compile and building process, this tool download some
dependencies that already packaged for fedora (groovy for example). The
question is: Can I use the original pom.xml file or I need patch it to use
the fedora packaged dependencies?
Regards
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2017-08-23 17:00 UTC in #fedora-meeting-2 on
irc.freenode.net.
Local time information (via. uitime):
================= Day: Wednesday =================
2017-08-23 10:00 PDT US/Pacific
2017-08-23 13:00 EDT --> US/Eastern <--
2017-08-23 17:00 UTC UTC
2017-08-23 18:00 BST Europe/London
2017-08-23 19:00 CEST Europe/Berlin
2017-08-23 19:00 CEST Europe/Paris
2017-08-23 22:30 IST Asia/Calcutta
--------------- New Day: Thursday ----------------
2017-08-24 01:00 HKT Asia/Hong_Kong
2017-08-24 01:00 +08 Asia/Singapore
2017-08-24 02:00 JST Asia/Tokyo
2017-08-24 03: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
= 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.
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:05 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2017-08-17/fpc.2017-08-1…
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:06)
* Schedule (geppetto, 16:09:23)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject…
(geppetto, 16:09:25)
* #654 glibc file triggers (geppetto, 16:10:23)
* ldconfig -Nr %{buildroot} … seems like it should be the command to
run. (geppetto, 16:26:28)
* #696 Packages not following the Guidelines for bundled libraries
(geppetto, 16:28:45)
* ACTION: Update for Guidelines on bundled libs. (+1:5, 0:0, -1:0)
(geppetto, 16:34:25)
* Open Floor (geppetto, 16:34:41)
Meeting ended at 16:41:10 UTC.
Action Items
------------
* Update for Guidelines on bundled libs. (+1:5, 0:0, -1:0)
Action Items, by person
-----------------------
* **UNASSIGNED**
* Update for Guidelines on bundled libs. (+1:5, 0:0, -1:0)
People Present (lines said)
---------------------------
* geppetto (42)
* zodbot (10)
* orionp (10)
* limburgher (5)
* mbooth (4)
* racor (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2017-08-17 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
================= Day: Thursday ==================
2017-08-17 09:00 PDT US/Pacific
2017-08-17 12:00 EDT --> US/Eastern <--
2017-08-17 16:00 UTC UTC
2017-08-17 17:00 BST Europe/London
2017-08-17 18:00 CEST Europe/Berlin
2017-08-17 18:00 CEST Europe/Paris
2017-08-17 21:30 IST Asia/Calcutta
---------------- New Day: Friday -----------------
2017-08-18 00:00 HKT Asia/Hong_Kong
2017-08-18 00:00 +08 Asia/Singapore
2017-08-18 01:00 JST Asia/Tokyo
2017-08-18 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 #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 #696 Packages not following the Guidelines for bundled libraries
.fpc 696
https://pagure.io/packaging-committee/issue/696
= 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.
Hi all,
I need reviewer who is good at golang rpm packages because its
reviewer asks me to have more reviewers who is good at golang rpm
packages in Fedora.
Could someone help review the following RPM packaging?
https://bugzilla.redhat.com/show_bug.cgi?id=1463492
Regards,
Tomo
Scenario: A previously shipping RPM has the capability to be built with
diagnostic and other debugging features. This has always been turned off
and should be turned off for any production deployment. However the
ability to install a version of the package with these features enabled
would be immensely useful.
Here is how I thought I would do this: add a "diagnostic" subpackage
that includes only the binary with the diagnostic build. There will be a
file conflict only on the binary and users will have to look for the
diagnostic subpackage to ascertain which build is executing.
What is the best way to add alternate builds in an RPM? Do we have
existing precedent? I didn't find any guidance in the packaging
guidelines, the closest I could find was the "Conflicts" doc
(https://fedoraproject.org/wiki/Packaging:Conflicts) which didn't really
address the issue.
--
John