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
4 years, 7 months
Summary/Minutes from today's FPC Meeting (2018-07-26 16:00 - 17:05 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:17 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-07-26/fpc.2018-07...
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:17)
* Schedule (geppetto, 16:05:17)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/3F6PPWY22VAWUBZ5ITUJIBD6SN3RLVE2/
(geppetto, 16:05:20)
* #784 forbid globs for shared libraries as it conceals sonames
(geppetto, 16:05:36)
* LINK: https://pagure.io/packaging-committee/issue/784 (tibbs,
16:06:45)
* ACTION: forbid globs for shared libraries as it conceals sonames
(+1:6, 0:0, -1:0) (geppetto, 16:32:53)
* ACTION: Need examples added to the proposal voted on. (geppetto,
16:33:17)
* #782 Forbid %{pythonX_site(lib|arch)}/* in %files (geppetto,
16:34:41)
* LINK: https://pagure.io/packaging-committee/issue/782 (mhroncok,
16:35:14)
* ACTION: Recommend not listing %{pythonX_sitelib}/* (and sitearch)
in files (+1:7, 0:0, -1:0) (geppetto, 16:48:09)
* #719 Simplify packaging of forge-hosted projects (geppetto, 16:48:40)
* LINK: https://pagure.io/packaging-committee/issue/719 (geppetto,
16:48:48)
* LINK:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/24
(mhroncok, 16:50:05)
* Open floor (geppetto, 16:53:46)
* LINK: https://pagure.io/packaging-committee/issue/703 (tibbs,
16:54:18)
* ACTION: tibbs will draft a more comprehensive change to say "use
lowercase" for 703 (geppetto, 17:04:25)
Meeting ended at 17:05:46 UTC.
Action Items
------------
* forbid globs for shared libraries as it conceals sonames (+1:6, 0:0,
-1:0)
* Need examples added to the proposal voted on.
* Recommend not listing %{pythonX_sitelib}/* (and sitearch) in files
(+1:7, 0:0, -1:0)
* tibbs will draft a more comprehensive change to say "use lowercase"
for 703
Action Items, by person
-----------------------
* tibbs
* tibbs will draft a more comprehensive change to say "use lowercase"
for 703
* **UNASSIGNED**
* forbid globs for shared libraries as it conceals sonames (+1:6, 0:0,
-1:0)
* Need examples added to the proposal voted on.
* Recommend not listing %{pythonX_sitelib}/* (and sitearch) in files
(+1:7, 0:0, -1:0)
People Present (lines said)
---------------------------
* tibbs (85)
* mhroncok (69)
* geppetto (62)
* ignatenkobrain (49)
* redi (30)
* decathorpe (22)
* zodbot (18)
* limburgher (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
4 years, 10 months
Python Bundled Wheels package
by Miro Hrončok
Hi Pythonistas and Fedora packagers.
Recently I've realized we bundle too much wheels with our pythons +
virtualenv package. That is unfortunate:
* we don't build those. stricly seeking, it's just a zip with python
files in it, yet this is not permitted in Fedora
* we only sometimes list it as Provides: bundled(...) and when we do,
it is tedious
* we never list bundled deps in those bundled wheels (pip bundles a lot)
* we never adapt the license tag to include license of bundled wheels
(and bundled deps in those) - it would be even more tedious, as pip
License tag can be very complicated
* we duplicate those across packages
I went ahead and prepared a concept in:
https://bugzilla.redhat.com/show_bug.cgi?id=1605156
This is one package that builds all the required wheels. It might be a
bit weird that it's only one package, but I think it can lower the
maintenance burden. Also, we won't update any wheel package, we only add
or remove them, so there is no "life cycle". Later we can decide that
there are simply too many thing sin one package and split it).
This package makes sure the license tag is right and all the virtual
bundled provides are in place.
Even as one package, I think it's a big improvement comparing to current
state of things.
Could you please review the decisions made in the spec? Namely:
* naming (main package, subpackages)
* virtual provides
* that the spec is generated by a script and how that script works
* the method of usage described in the package review request
I've also decided not to run tests, as for them to mean something, we
would need to run them against all relevant Python versions. Also, it
would complicate the package a lot.
The package is approved thanks to Robert-André Mauchin, yet I won't
request the repo until it's settled that we want this.
Also, once we start using this, maybe we can stop doing rewheel and just
use wheels from here in the python3 package as well?
Thanks.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 10 months
Summary/Minutes from today's FPC Meeting (2018-07-19 16:00 - 17:35 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:01 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-07-19/fpc.2018-
07-19-16.00.log.html
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:02)
* Schedule (geppetto, 16:04:51)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedor
aproject.org/message/GSUKP4G7KFIJAH2DYHMI5H6VOJTEEVYJ/
(geppetto, 16:04:53)
* #759 Don't require editing of Source0 in Python spec template
(geppetto, 16:05:03)
* ACTION: Don't require editing of Source0 in Python spec template
(+1:7, 0:0, -1:0) (geppetto, 16:08:08)
* #774 Reword "Addon Packages" a bit (geppetto, 16:08:27)
* #775 Allow to have %{?suse_version} condition in spec
file (geppetto,
16:10:15)
* #777 Improved text for default services page (geppetto, 16:19:40)
* ACTION: Improved text for default services page (+1:7, 0:0, -1:0)
(geppetto, 16:55:49)
* #781 Wiki:Packaging:Java Guidelines Update (one-liner) (geppetto,
16:55:59)
* ACTION: Wiki:Packaging:Java Guidelines Update (+1:6, 0:0, -1:0)
(geppetto, 17:03:06)
* #782 Forbid %{pythonX_site(lib|arch)}/* in %files (geppetto,
17:03:18)
* ACTION: Forbid %{pythonX_site(lib|arch)}/* in %files (+7, 0:0,
-1:0)
(geppetto, 17:19:18)
* Open Floor (geppetto, 17:19:24)
Meeting ended at 17:35:22 UTC.
Action Items
------------
* Don't require editing of Source0 in Python spec template (+1:7, 0:0,
-1:0)
* Improved text for default services page (+1:7, 0:0, -1:0)
* Wiki:Packaging:Java Guidelines Update (+1:6, 0:0, -1:0)
* Forbid %{pythonX_site(lib|arch)}/* in %files (+7, 0:0, -1:0)
Action Items, by person
-----------------------
* **UNASSIGNED**
* Don't require editing of Source0 in Python spec template (+1:7,
0:0,
-1:0)
* Improved text for default services page (+1:7, 0:0, -1:0)
* Wiki:Packaging:Java Guidelines Update (+1:6, 0:0, -1:0)
* Forbid %{pythonX_site(lib|arch)}/* in %files (+7, 0:0, -1:0)
People Present (lines said)
---------------------------
* tibbs (88)
* geppetto (80)
* redi (46)
* zodbot (22)
* decathorpe (22)
* ignatenkobrain (19)
* sgallagh (19)
* mhroncok (17)
* orionp (7)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
4 years, 10 months
Potential conflict in package names - bear-devel and bear
by Dan Čermák
Hi everyone,
I have recently tried to package the utility called Bear (Build EAR),
a tool that generates a clang compilation database for build systems
that cannot generate one themselves.
I tried to submit the package and during review I was made aware of the
package bear-devel, which is already in the fedora repository. This
package are the development files for a game engine and are completely
unrelated to Bear. However, I can see a potential confusion for users,
when bear-devel and bear have nothing in common.
My question is: how should I address this issue? Renaming my proposed
package to Build-ear would be an option, but the binary should still be
called bear, to avoid confusion for users. Should I ask the upstream
author about their opinion concerning renaming?
Thanks in advance,
Dan
4 years, 10 months
