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
Proposed Fedora packaging guideline: More Go packaging
by nicolas.mailhot@laposte.net
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
5 years, 9 months
Maintaining Package Branches (on COPR)
by Evan Klitzke
Hi,
I have a couple of packages on Fedora COPR, and right now I am just building the same version of the RPM for all the Fedora releases I support. Upstream for one of these projects has released a release candidate, and I would like to package the release candidate for Rawhide only. Is it possible to set this up in an automated way? If so, how? The way I intuitively expect this to work is based on y experience with Debian where I would use different git branches in my package repo for different Debian releases. I didn't see anything like this in the COPR build options, but I'm pretty new to the Fedora packaging ecosystem so this might just be PEBCAK? And how is this typically managed for the "real" Fedora package repos?
Thanks,
Evan
5 years, 9 months
help with first package (extractpdfmark, bug 1520922)
by Federico Bruni
Hi all
I've recently submitted my first package here:
https://bugzilla.redhat.com/show_bug.cgi?id=1520922
I need some pointer to figure out how to solve a few issues highlighted
by the reviewer. There's a lot of information in Fedora wiki, but it's
quite overwhelming. I've read a lot, but cannot find the information I
need.
The problems still to be solved are:
[!]: Package does not own files or directories owned by other packages.
Note: Dirs in package are owned also by:
/usr/lib/.build-id(iputils,
efivar-libs, gd, gc, libtomcrypt, gdbm, gpgme,
rpm-plugin-selinux,[... cut]
[!]: %build honors applicable compiler flags or justifies otherwise.
[!]: Package contains no bundled libraries without FPC exception.
[!]: Package complies to the Packaging Guidelines
BTW, rpmlint does not spot these errors.
So I've tried fedora-review and run this command in my RPM package
directory:
fedora-review --define DISTTAG=fc27 -p -n extractpdfmark
and I see that above problems are set to "manual review needed". So the
errors were spotted by the reviewer, not by any tool.
Back to above problems, the errors related to the libraries are
probably about the .build-id directory, but I cannot figure out what
should I do.
$ rpm -ql x86_64/extractpdfmark-1.0.2-1.fc27.x86_64.rpm
/usr/bin/extractpdfmark
/usr/lib/.build-id
/usr/lib/.build-id/41
/usr/lib/.build-id/41/8cd205d31cf37c25cec9711715265e6c00726b
/usr/share/doc/extractpdfmark
/usr/share/doc/extractpdfmark/COPYING
/usr/share/doc/extractpdfmark/README.ja.md
/usr/share/doc/extractpdfmark/README.md
/usr/share/licenses/extractpdfmark
/usr/share/licenses/extractpdfmark/COPYING
/usr/share/man/man1/extractpdfmark.1.gz
Thanks in advance
Federico
5 years, 9 months
fedpkg mockbuild and cmake not found
by cedlemo
Hi,
I am trying to build a package that uses cmake and I followed these
documentations:
- https://fedoraproject.org/wiki/How_to_create_an_RPM_package
- https://fedoraproject.org/wiki/Packaging:Cmake
Here is the spec file:
``````````````````````````````````````````````````````````````````````````````````````````````````````
Name: clasp
Version: 3.3.3
Release: 1%{?dist}
Summary: A conflict-driven nogood learning answer set solver
Group: Applications/Engineering
License: MIT
URL: http://www.cs.uni-potsdam.de/clasp/
Source0:
https://github.com/potassco/clasp/releases/download/v%{version}/%{name}-%...
BuildRequires: cmake-rpm-macros
%description
clasp is an answer set solver for (extended) normal and disjunctive logic
programs. It is part of the Potassco project for Answer Set Programming
(ASP).
The primary algorithm of clasp relies on conflict-driven nogood learning, a
technique that proved very successful for satisfiability checking (SAT).
clasp
has been genuinely developed for answer set solving but can also be
applied as
a (Max-)SAT or PB solver or as a C++ library in another program. It provides
different reasoning modes and other advanced features.
%prep
%autosetup -n %{name}-%{version} [GitHub]
%build
%cmake .
%make_build
%install
%make_install
%check
ctest -V %{?_smp_mflags}
`````````````````````````````````````````````````````````````````````````````````````````````````````
In the directory, I get the tarball with:
spectool -g clasp.spec
Then I launch the build with
fedpkg --release f27 mockbuild
But it fails with :
/var/tmp/rpm-tmp.8htWxw: line 38: /usr/bin/cmake: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.8htWxw (%build)
I can not see how to fix it. Any ideas ?
Thanks
Cédric Le Moigne.
5 years, 10 months
Summary/Minutes from today's FPC Meeting (2018-01-24 18:00 - 19:00 UTC)
by James Antill
======================
#fedora-meeting-2: fpc
======================
Meeting started by geppetto at 18:22:59 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2018-01-24/fpc.2018-
01-24-18.22.log.html
.
Meeting summary
---------------
* Roll Call (geppetto, 18:22:59)
* Schedule (geppetto, 18:23:33)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedor
aproject.org/message/HQV64UZOCVCNVAX6H74R7K4PVY337DTS/
(geppetto, 18:23:34)
* #729 How to handle non-informative package reviews? .fpc 729
(geppetto, 18:24:20)
* ACTION: Close as we can't really do much unless the reviewer is
very
obviously doing bad things. (geppetto, 18:28:24)
* Maybe start a discussion on fedora-devel-list (geppetto, 18:28:36)
* #731 Testing guidelines .fpc 731 (geppetto, 18:29:03)
* #731 (geppetto, 18:29:09)
* ACTION: Everything seems fine as it is (geppetto, 18:32:22)
* If you want to create a draft to propose a change feel free to open
a ticket (however we are generally against listing every single
testing framework) (geppetto, 18:32:50)
* #733 'users and groups' should link to prealloc. list (geppetto,
18:33:04)
* ACTION: Link will stay removed, as it doesn't seem useful.
(geppetto, 18:37:07)
* If you have reasons for needing this information, feel free to open
another ticket with a draft policy change. (geppetto, 18:37:34)
* #737 Allocating a soft static uid and gid 389 for dirsrv (geppetto,
18:37:55)
* ACTION: tibbs Will point to the guidlines with the process to do
what they want. (geppetto, 18:42:27)
* #726 Review for SELinux Independent Policy packaging
Draft (geppetto,
18:42:55)
* ACTION: tibbs Will work with you to try to extract the guideline
parts of the document (removing stuff about setting up github etc.)
(geppetto, 18:46:43)
* Open Floor (geppetto, 18:47:48)
* #744 Make packaging guidelines Fedora only (geppetto, 18:49:07)
* +4 on the proposal, geppetto; limburgher; tibbs; mbooth (geppetto,
18:58:22)
Meeting ended at 18:58:32 UTC.
Action Items
------------
* Close as we can't really do much unless the reviewer is very
obviously
doing bad things.
* Everything seems fine as it is
* Link will stay removed, as it doesn't seem useful.
* tibbs Will point to the guidlines with the process to do what they
want.
* tibbs Will work with you to try to extract the guideline parts of the
document (removing stuff about setting up github etc.)
Action Items, by person
-----------------------
* tibbs
* tibbs Will point to the guidlines with the process to do what they
want.
* tibbs Will work with you to try to extract the guideline parts of
the document (removing stuff about setting up github etc.)
* **UNASSIGNED**
* Close as we can't really do much unless the reviewer is very
obviously doing bad things.
* Everything seems fine as it is
* Link will stay removed, as it doesn't seem useful.
People Present (lines said)
---------------------------
* geppetto (52)
* tibbs (43)
* limburgher (28)
* zodbot (14)
* mbooth (7)
* orionp (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
5 years, 10 months
Versioning of packages combining projects
by Miroslav Lichvar
Hi,
I'm trying to package ntp-refclock [1], which is a wrapper for
reference clock drivers from ntpd to make them usable with other NTP
implementations. The package builds code from two projects and I'm not
sure what should be the version and release. The guidelines for
versioning don't seem to cover this odd case.
ntp-refclock-0.1 is combined with ntp-4.2.8p10. The majority of the
code compiled for the package comes from ntp (the drivers and some
code that the drivers need), so I think the version or release needs
to include the ntp version.
Would ntp-refclock-0.1-1.ntp4.2.8p10.fc28 work?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1536565
--
Miroslav Lichvar
5 years, 10 months
Which Fedora/EPEL is targeted by packaging guidelines?
by Vít Ondruch
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.fedoraproje...
[2] https://bodhi.fedoraproject.org/updates/?user=vondruch
[3] https://pagure.io/packaging-committee/issue/710
5 years, 10 months