I'm Riccardo Schirone, I live in Italy and I've been a Fedora user for many
years. I joined Red Hat less than a year ago and I have been contributing
to radare2 project (https://github.com/radare/radare2.git) for several
My first contribution to the Fedora project is the introduction of the
radare2 package in Fedora, because I think it will benefit both Fedora
users and radare2 project as well (
I hope to not stop there,
Just a quick headsup for users following Fedora 29, the
dbus 1.12.10-1.fc29 build is missing the systemd dbus.service
file, breaking almost everything.
Instead it contains a dbus-daemon.service file, but the
dbus.socket file expects a matching dbus.service, not
So either hold of on applying updates until this is fixed
or exclude dbus.
The current idea
A Flatpak is a module. The way that the module is deployed is by creating a
Flatpak container from the module. (Other modules might be deployed by
installing by RPMs directly or creating a server container.)
Because Flatpaks are a module, they share the modules/ namespace on
src.fedoraproject.org with other modules.
Flatpaks are also containers - but to keep things simpler, we don't require
a separate git project in the container/ namespace - the container.yaml is
kept in the same git project and OSBS builds the Flatpak container directly
Each flatpak needs to be tagged into two koji tags:
f29-modular-updates (this is the destination for the module build)
f29-flatpak (this is the destination for the Flatpak container build)
The package list for each koji tag is populated from pagure by the
owner-sync-pagure script (*). But that script has no way of knowing what
repositories under modules/ in src.fedoraproject.org are just modules and
what modules are also Flatpaks, so it has no way to populate the
f29-flatpak tag package list correctly.
Solution 1 - separate namespace
We could put flatpaks into their own namespace in src.fedoraproject.org.
The MBS configuration would have to be changed to also allow building
modules from the flatpaks/ namespace, the Bodhi code that just landed would
need to change, and there are doubtless other places where we'd need to
change things to extend the list of namespaces, but it would mostly be
Upsides: would make the handling of flatpaks in the infrastructure code a
bit more regular, and also make it easy to see a list of all Flatpaks.
Downsides: obscures the relationship between Flatpaks and other modules.
Solution 2 - project tags
The owner-sync-koji code could be adapted so that to find the set of
packages for f29-flatpak it looks for projects in modules/ with a project
tag of 'flatpak'.
Upsides: have to change nothing but owner-sync-koji and the fedpkg
request-repo/fedscm_admin code path.
Downsides: obscure. project tags are modifiable by the owner - so things
could get out of sync.
Solution 3 - look at module contents
If a branch under src.fedoraproject.org/modules has a container.yaml file
with a flatpak: key at the toplevel, then we know it's a flatpak module.
owner-sync-koji could potentially just check this.
Upsides: nothing else to worry about beyond what has to be set up for
Downsides: per-branch - not per-repository, would be wrong on initial
repository creation, which is when owner-sync-koji is run.
Solution 4 - ????
[ your proposal goes here]
== Summary ==
Remove the Group: tag from over 9000 source packages.
== Owner ==
* Name: Jason Tibbitts (tibbs)
* Email: tibbs(a)math.uh.edu
== Detailed Description ==
I will remove the Group: tag from all specfiles in Fedora dist-git
which still have it, verify that the result is syntactically correct,
then commit and push the change. Since this is a relatively minor
changeI am not planning to bump Release: or add %changelog entries,
but I do that if it is deemed necessary.
I am proposing this as an official change instead of just doing it (as
with other low risk packaging cleanups) because:
* It would be by far the largest mass package change we would ever
* It does technically cause a visible change in the resulting package.
If queried, rpm will show the group as "Unspecified" for every binary
package in the distribution instead of just the majority of them. It
is theoretically possible that someone could have a tool which uses
this information, although that tool most already be mostly useless.
* People would yell at me even more loudly if I posted the full 9000+
package and maintainer listing.
Since this changes many, many packages and has small but nonzero end
user visibility I am filing this as a system-wide change.
== Benefit to Fedora ==
9420 source packages (43% of the total count) come closer to
compliance with Fedora's packaging guidelines. The Group: tag has
been in a "should not use" state since March of 2017.
More useless cruft is removed from specfiles. This provides a slight
benefit to ease of maintenance and eliminates yet another bizarre
historical relic which confuses new packagers. Cargo cult behavior is
rampant and removing the cruft in one go will be another step towards
having system-wide clean specfiles.
The Group: tag is not required in any live Fedora or EPEL release.
RHEL5 did need it, but EPEL5 did not as it was supplied automatically
via magic in the epel-rpm-macros package. The
[[Packaging:Guidelines#Tags_and_Sections|Packaging Guidelines]] have
indicated that the Group: tag should not be used since March of 2017.
The tag is not used by Fedora currently; the concept was replaced long
ago by comps which permits a far more flexible classification of
packages. dnf has a "group" subcommand but this operates on comps
groups, not anything defined by the Group: tag. dnf does not display
information from Group: tag. If a package does include a Group: tag,
a direct rpm query will display it but otherwise will show
There was never any strong standard for the contents of the Group:
tag. Older versions of rpm (still present in RHEL7 but not in any
live Fedora release) contained a documentation file named GROUPS with
a list and rpmlint would check this, but it was never strongly adhered
to. The current package set has some quality examples like a Group
tag containing the string "Group:" and one containing only
"evelopment/Languages". It seems relatively obvious that nobody is
paying attention or making use of that data.
Among the tags which are at least in the recommended set which rpm
used to have, most do not convey particularly useful information. Of
the Group: tags which remain, 5438 contain "Development/Libraries",
1871 have "System Environment/Libraries" and 1346 are
== Scope ==
* Proposal owners: Whip up a quick script, test it well to ensure that
it doesn't have unintended side effects, and handle outliers or
special cases manually. Then wait a few hours to push commits to
* Other developers: Nothing besides dealing with any commit emails they receive.
* Release engineering: There should be no releng involvement. There
is no real need for any packages to be rebuilt. If there is an F30
rebuild scheduled, it would be advantageous for this change to be made
before that happens. I filed [https://pagure.io/releng/issue/7627] in
of deliverables]]: There should be no change to deliverables besides
the fact that the packages no longer have Group: tags.
* Policies and guidelines: This is implementing a requirement of the
current packaging guidelines. The specific change mandating this
happened in March of 2017.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
There is no effect on upgrades. Packagers have always been free to
remove Group: tags, even within a stable release. This will simply
result in the rest of them going away.
== How To Test ==
There is not much to test. The change is simple and so if done with a
modicum of care it will not cause syntax errors in the packages.
Testers and maintainers can of course do local or koji builds after
the changes have been pushed to ensure that there are no problems, and
rpm -qip run on the resulting binary packages should only show Group:
tags of "Unspecified".
== User Experience ==
There should be no change to the end user experience unless there is
an expectation that the Group: tags of the changed packages will show
something other than "Unspecified".
== Dependencies ==
There are no dependencies.
== Contingency Plan ==
If there is some issue, it is simply possible to do nothing, or to
change only a subset of packages.
If changes are committed and it turns out that there is some
unforeseen negative effect, the changes can simply be reverted.
* Contingency mechanism: Either do nothing, or revert the changes in
the unlikely event that they cause issues.
* Contingency deadline: Before the mass rebuild.
* Blocks release? No
* Blocks product? N/A
== Documentation ==
The process is generally obvious and should not require much in the
way of involvement of anyone else.
== Release Notes ==
There should be no need to note this change in any release notes, as
it is merely the completion of a change which has been ongoing since
the time of Fedora 12.
Fedora Program Manager
Tinyproxy just released a new version 1.10 which is has been overdue
and containes 2 CVE fixes apart from several enhancements.
I created builds for rawhide already.
I was wondering if it is still possible to get tinyproxy to this important
update in f29, since no other packages depend on it, afaict.
If so, what do I do? Just update the scm branch and bring it in through
Thanks - Michael
I am faced with a problem that's due to the update of mutter / GNOME to
version 3.30: The gala window manager - which is used by the Pantheon DE
(primary DE of elementaryOS) - is broken by the API bump from libmutter-2
I reported this "issue" with the fedora mutter package on bugzilla:
The API changes are quite invasive, and it looks like upstream developers
(who are - rightly - focused on elementaryOS 5.0, based on GNOME 3.28,
right now) will take some time to get around to fixing gala with mutter
This results in the unfortunate situation that right now, gala - and by
extension, the Pantheon DE - can't be installed on fedora 29+ due to broken
dependencies, and gala can't be rebuilt, because it's not compatible with
mutter 3.30 yet.
I wrote a blog post with more details on my website:
Basically, the gala upstream developers and I need some help from people
who are versed in vala to port gala to the new mutter APIs, or the Pantheon
DE will not be installable on fedora 29 at launch, and will probably be
removed from existing users' fedora installations on upgrading to f29.
Another possible short-to-mid-term solution would be to introduce a
mutter328 compat package on fedora 29 (along with necessary adaptations to
the mutter package), or to bundle mutter 3.28 with gala itself (since it's
the only package using mutter directly, apart from gnome-shell, AFAICT).
However, those paths would probably require quite some changes to mutter
code and build system (autotools).
Any help and / or guidance on how to deal with a situation like this is
Bugs have been filed asking packagers to build with openblas instead
of atlas. But there are multiple openblas libraries. I can link with
any of the following:
If I understand correctly, the default is a library that cannot
tolerate multiple threads, uses 32-bit integers in the interface, and
does not use "a symbol name suffix", whatever that means. The various
o = use OpenMP (instead of serial)
p = use pthreads (instead of serial)
64 = use 64-bit integers in the interface
_ = use "a symbol name suffix"
The bugs that have been filed have not made any mention of how to
select which of these libraries to link against. I'm looking at how
to switch the sagemath stack over. Since suitesparse sits at the
bottom of the stack, I just followed that package's example at first
and linked with -lopenblas. But now sagemath says:
OpenBLAS : Program will terminate because you tried to start too many threads.
And kills it dead. I think this switch from atlas to openblas was not
planned well. The entire sagemath stack, for example, will need to be
linked with the *same* openblas library. The serial library with the
32-bit integer interface is not the right choice, and I'm going to
need suitesparse to make the same choice as the rest of the stack.
Some of the elements of that stack are OpenMP-enabled, so that may be
the right choice, but I'm not sure. Suitesparse, for example, uses
TBB, which suggests that the thread alternative may be the right
choice for that package. The serial option is definitely not right
for suitesparse, anyway.
How do we select which packages get linked against which openblas
library? That question should have been answered *before* filing all
of these bugs.
Also, I see this in /usr/include/openblas/openblas_config.h:
That suggests that SSE3 and SSSE3 instructions have been built into
one or more of the openblas libraries, which means that users with
machines that do not support those instruction sets will get illegal
instruction errors if they try to use anything linked with openblas.