Release rpkg-1.58 fedpkg-1.37
by Ondrej Nosek
Hi all,
a new version rpkg-1.58 and fedpkg-1.37 is released.
Currently, Fedora 30 packages are in the stable repository, feel free to
try other waiting distributions in Bodhi.
Numerous features and improvements (as well as bugfixes) includes:
(For "rpkg")
- Improvements for scratch module builds
- Allow passing arguments to “mbs-manager build_module_locally”
- Remove the ability to parse a module’s branch
- Permit setting arbitrary rpm macros during build
- Ignore specific files in a cloned repository
- Pass specific arguments to “mock”
- Added “depth” argument to "git clone"
- Watch multiple module builds
- Show module build links in output from command module-build
- Add the ability to configure multiple regex expressions
- Add “retire” command supporting both packages and modules
- Import srpm without uploading sources
- Ignore any specified profile when finding the Flatpak build target
- Added update-docs script
- And other fixes and small improvements
(For "fedpkg")
- Ignore files in a cloned repository
- Enable shell completion for module scratch builds
- Show hint when Pagure token expires
- Include possible distprefix in “–define dist” for Forge-based packages
- Other small fixes
More specific changelog (web documentation):
https://docs.pagure.org/rpkg/releases/1.58.html
https://docs.pagure.org/fedpkg/releases/1.37.html
Updates:
https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.58-1.el6&builds=rp...
Alternative link:
https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1
rpkg is available from PyPI.
Thanks to all contributors.
Regards
2 years, 2 months
OCaml 4.10.0 build in Fedora 32 and 33
by Richard W.M. Jones
OCaml 4.10.0 was released over the weekend.
We currently have OCaml 4.10.0 beta 1 in Rawhide. It's not that far
away from 4.10.0. Unfortunately since building beta 1, Fedora 32 was
forked from Rawhide so we now have the beta 1 build in Fedora 32 as
well.
Hopefully the plan is as follows:
(1) Rebuild OCaml 4.10.0 in a side tag then move it to Rawhide. I
don't expect any difficulties here since all the hard work was already
done when I built beta 1.
(2) Merge all those changes into the f32 branches of the ocaml*
packages.
(3) (This is where it gets more speculative because my mass rebuild
script has only ever been run against Rawhide ...) Rebuild in a side
tag of Fedora 32, and if that goes well then merge the side tag in
F32.
This should start happening this afternoon / tomorrow.
There are some packages which are still failing to build:
* coccinelle - Uses -unsafe-string, still waiting resolution upstream.
* nbdkit - Caused a crash in goals, all my code so I will try to
debug it this time
* plplot - FTBFS for unrelated reasons last time
* z3 - https://bugzilla.redhat.com/show_bug.cgi?id=1792740
coq and friends failed last time, but I believe they should work now.
Latest status is in this thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
opam should be fixed now (was
https://bugzilla.redhat.com/show_bug.cgi?id=1792770)
Mass rebuild script:
http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=summary
Talk about mass rebuilding technique:
https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-whic...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
2 years, 2 months
Fonts packaging policy rewrite proposal
by Nicolas Mailhot
Hi,
A fonts packaging policy rewrite proposal has been pushed to FPC today:
https://pagure.io/packaging-committee/pull-request/934
It should be clearer, more opinionated, and take into account:
– updates of The OpenType standard
– variable fonts
– web fonts
– upstream depreciation of non OpenType formats: final stages of the
Harfbuzz consolidation decided at the 2006 Text Layout summit
https://www.freedesktop.org/wiki/TextLayout/
– appstream & fonts
– weak dependencies
– and probably more I forget here
It is based on the new fonts-rpm-macros project for automation:
This project builds on tooling enhancements in redhat-rpm-config and rpm
itself, done during the past two years for the Forge and Go sets of
packaging macros. It started 2 years ago as a fork of fontpackages,
which is the core of our current fonts packaging guidelines.
It will require putting the fonts-srpm-macros package in the default
build root, like is done for other domain-specific packaging macro
sets.
Major additions:
– better documentation (clearer and more complete)
– better automation (less packager hassle for better and more complete
results)
Major removals:
– tools and scripts
– fixing metadata with ttname
Mostly because no one seems willing to maintain those scripts, or port
ttname to python 3.
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
showcases the new policy on 62 real-world source packages, generating
139 installation packages. Some of those are badly delayed updates to
Fedora packages, others are brand-new packages ready for Fedora
inclusion. They include major font packages such as Stix, DejaVu, Droid,
IBM Plex.
Existing Fedora packages will continue to build, the old fontpackages
macros are grandfathered in fonts-rpm-macros for now. They will be
removed in a few years to give packagers time to apply the new
guidelines.
Regards,
--
Nicolas Mailhot
2 years, 2 months
Package uses Gradle (retired) to build: what to do?
by Ankur Sinha
Hello,
netcdf-java[1] uses the Gradle build system, and is required to update
hdfview[2] to the latest version. Gradle, however, was retired[3] as
"out of date, broken, fails to build, basically unmaintainable".
Now, I know that following our system, one must package Gradle first but
given the retirement comment, packaging and then maintaining it does not
appear a simple task, and for one dependency only, it seems overkill.
Is there perhaps a way of bypassing that somehow? For example, is there
a way to use good old Maven to build a Gradle based project?
[1] https://docs.unidata.ucar.edu/netcdf-java/5.2/userguide/building_from_sou...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1797361
[3] https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
2 years, 2 months
Orphaning most of the ancient Gnome 1 stack
by Paul Howarth
Hi all,
I've been looking after the ancient Gnome 1 library stack for the last
decade as I had a local use for the libraries. That is no longer the
case so I'm planning to orphan the following packages, none of which
appear to be used by anything else in Fedora (Rawhide):
* libglade
* gnome-libs
* ORBit
* imlib
* libxml
* libpng10
(tested using:
dnf repoquery --repo=rawhide{,-source} --whatrequires XXX
)
I expect that nobody will pick them up and they'll get retired along
with other orphaned packages in due course. If anyone actually has an
interest in these packages, let me know and I'll transfer them.
I'll still take care of the bottom two packages in the stack as they
still have several users in Rawhide:
* gtk+
* glib
Regards, Paul.
2 years, 2 months
Self Introduction: Dan Shoemaker
by Daniel Shoemaker
Hi, my name is Dan Shoemaker. I have been using Fedora since Fedora Core 6
for both personal and professional use. About five years ago I started
developing bash scripts in order to start automating tasks I was doing
while maintaining Linux servers for various clients. Last year I started
taking Todd McLeod's Udemy class Learning Go and I found much to my delight
that Fedora has a very active Go SIG. As a result I would love to become a
package maintainer for the Go packages on Fedora.
Dan
2 years, 2 months
Automatic close of bugs for retired packages?
by Pavel Raiskup
I today tried to mimic something that random Fedora user can do, and I
submitted bug against one of our long-time retired components. I haven't
been warned at all that the package is dead.
As user, it is easy to pick a wrong component when filling a bug - but the
problem with orphaned/retired packages is that nobody listens there
usually. Only 'Orphan Owner <extras-orphan(a)fedoraproject.org>'.
Should such reports be kindly closed automatically by some bot, so user
can reopen against different component? Or should we drop the component
from bugzilla?
Pavel
2 years, 2 months
Ideas and proposal for removing changelog and release fields from
spec file
by Pierre-Yves Chibon
Good Morning Everyone,
This topic has already been discussed a few times over the past month, but Adam
Saleh, Nils Philippsen and myself have had the opportunity to invest some time
on it with the hope of making the packager's life simpler as well as making it
easier to build automation around our package maintenance.
We have investigated a few ideas, the full list with their pros and cons can be
found in this document: https://hackmd.io/8pSwJidhTYel9euQqMEKpw?viev
If you have any questions about some of these, please ask them, we'll be happy
to answer them and potentially complete this document.
For both the release and the changelog fields we believe using RPM macros would
satisfy the requirements we have for opting-in/out:
- You can easily opt-in by using the macros
- You can easily opt-out by removing the macros from your spec file
For the changelog, we believe we have a potential good solution:
- The changelog will be automatically generated using an external `changelog`
file as well as the commit history
- When you opt-in, you will simply move the existing changelog to an external
file `changelog`, which is placed in the dist-git repo and add the
appropriate macro.
- Upon building, the macro will generate the changelog using all the commits
of the repo up to the last commit touching the `changelog` file. Of all
these commits it will only consider the commits following these rules:
- There are generally two approaches regarding what to include by default:
1. commits touching only the `sources`, `.gitignore`, `dead.package`
files, `tests` folder will be ignored by default, i.e. a blacklist
2. only commits touching the spec file or patches will be included by
default, i.e. a whitelist
==> Which approach do you think is better/will work in most cases?
- empty commits (not touching any files) will be included on the assumption
that this is their purpose
- commits containing "magic keyword" (#changelog_exclude,
#changelog_include?) will be ignored or included as the case may be
- Finally the content of the changelog file specified will be appended to the
changelog generated from the git history
If you wanted to edit the changelog, you would:
- Generate the changelog locally via a command like:
`fedpkg generate-changelog > changelog`
- Edit `changelog` as desired
- Commit and push the changes
Since the macro will only consider the commits up to the first commit touching
`changelog` (in other words, the macro will only consider the commits after this
one) and include `changelog` file as is, your edits will appear in the RPM
changelog as you want.
One thing to note is that rebuilds from the same commit will have the same
%changelog, they will not get a new entry. If you want a new changelog entry,
you have to create a new commit with the desired changelog entry as commit
message (the commit itself can be empty).
However, for the release field, we are struggling a little bit more, two options
are more appealing to us:
A) The release field is automatically generated using two elements:
- the number of commits at this version
- the number of builds at this commit
- the dist-tag being added after them
The release field would thus look like:
``<number of commit at version>.<number of build at commit>%{dist}``
So we could have: (A, B, C and D being different commits)
A -- version: 0.9 -- release: ?
|
B -- version: 1.0 -- release: 1.0
|
C -- version: 1.0 -- release: 2.0
|
D -- version: 1.1 -- release: 1.0
A rebuild of the commit D, would lead to a release 1.1 (assuming the first one
succeeded)/
Pros:
- Easy to replicate locally
- Every changelog entry can be mapped to a `version-release` (No changes to the
packaging guidelines)
- Allows triggering two builds from the same commit without any manual change
(simplifies mass-rebuilds)
- Easy to link a certain build with a specific commit
- Easy to “guess” the next release value before triggering the build
Cons:
- Old packages which are no longer receiving upstream releases may need
special care (for example if they are at the release -48 but only had 45
commits leading to this)
- Relies on information from the build system for the build number (but can
be closely simulated locally since the <n_build> info is only used for
rebuilds)
- Upgrade path may be problematic if Fn is upgraded to version X with one
commit while Fn-1 is upgrade to version X with 2 commits (or more)
B) The release field is automatically generated taking existing builds in all
current Fedora releases (ie: rawhide, Fn, Fn-1...) into account. This means for
builds of the same epoch:version, find a new release that (if at all possible)
ensures upgradability from older Fedora versions to newer ones, adhering to the
structure of a release tag documented in the Versioning Guidelines[1]. Going
from the (RPM-wise) "latest build" that the new one should surpass, this can
mean bumping in the front (`pkgrel`) or the back (`minorbump`).
This allows packages from "very stable" upstreams who haven't released in years
to still benefit from automatically generated releases.
The following examples would use a macro for the release field as outlined in a
separate document[2].
Example #1 ("normal" release progression):
Rawhide has: 2.0-1.fc32
F31 has: 1.0-1.fc31
F30 has: 1.0-1.fc30
Next release in F31: 1.0-2.fc32
Example #2 ("hotfix" in an older release, selected by an alternative macro (or
option) in the spec file):
Rawhide has: 2.0-1.fc32
F31 has: 1.0-1.fc31
F30 has: 1.0-1.fc30
Next release in F30: 1.0-1.fc30.1
Example #3 (pre-release, selected by an alternative macro (or option) in the
spec file):
Rawhide has: 2.0-1.fc32
F31 has: 1.0-1.fc31
F30 has: 1.0-1.fc30
Next release in Rawhide: 3.0-0.1.20200224git1234abcd
Pros:
- Allows triggering two builds from the same commit without manual
intervention
- Emulates what many maintainers do manually today for most use cases
- Can cater for pre-releases (e.g.: by offering different macros or macro
options for the different use cases)
Cons:
- Needs the build system for information about builds in this and other Fedora
versions
- Not easy to reproduce locally because we don’t have machine-consumable
knowledge about other builds in e.g. the dist-git repo
- Does not allow to generate changelog entries with `version-release`
information for all commits (and this will require a change in our packaging
guidelines)
So these are the results of our current investigations, we are very much eager
to get your feedback on them and even more eager if you have ideas on how to
approach/solve some of the challenges mentioned here.
Looking forward for the discussion,
Pierre
For Adam, Nils and myself
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
[2]: https://hackmd.io/kuXOPe74RfepuztBz7pBsg
2 years, 2 months
Re: Non-responsive maintainer: pocock
by Dakota Williams
On 2/26/20 6:59 PM, Daniel Pocock wrote:
>
>
> On 26/02/2020 22:56, Dakota Williams wrote:
>> On 2/24/20 5:57 PM, Daniel Pocock wrote:
>>>
>>>
>>> On 24/02/2020 20:47, Dakota Williams wrote:
>>>> Does anyone know how to contact maintainer pocock?
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1806708
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1790674
>>>
>>>
>>> Like most developers, I have a backlog of things to deal with and I try
>>> to coordinate fixes for packaging issues into the right part of the
>>> release cycle
>>>
>>
>> Would you like help? I'd be willing to be a co-maintainer to make the
>> branch.
>
> Yes, I would welcome help with these packages
>
> But there is also an increasing problem of making decisions about trust
>
> In the case of developers who I haven't met or worked with, I don't
> really know how to proceed
>
> I've seen several extraordinary examples of developers doing things that
> undermine my confidence in them over the last couple of years. The
> fighting within GNU and FSF right now is the latest iteration of that.
>
> Now, whenever I receive a request from somebody I don't know, there is
> an extra effort for me to decide how to proceed.
>
> Maybe I can simply resign from maintaining the asio package and then opt
> out of the process of choosing a new maintainer.
>
> Please don't take this personally: it is a reflection of the overall
> state of free software communities today.
>
I don't know about the situation with the GNU project and the FSF, but
if there's something you'd like me to do to prove trust, I could do it.
2 years, 2 months
