Postings by Fabio Valentini

dnf crashes make fedpkg / mock unusable

Hi everybody,

Since about one or two days, I am completely unable to build any
packages with fedpkg locally, and even running dnf on the host system
is really crashy.

It looks like dnf crashes while it's refreshing repository metadata.
ABRT won't let me report the issue due to "low informational value" of
the backtrace, but it looks like SEGFAULT in libcurl:

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fad55077f22 in ?? () from /lib64/

However, there's not been any recent curl update for f29 AFAICT.

Stewardship SIG: Initial report and plans for the future

Hi everybody,

It looks like the first round of orphans has been taken in by our SIG - this
seemed to be a good time to do inventory and think about how to proceed.

Status Report
First of all, I've written a small script [0] that produces a simple HTML page
of the current status of the stewardship-SIG packager group. Pull Requests to
improve the report are welcome.

The current status is available at [1].

Announcing the Stewardship SIG: Maintenance for High-Priority orphans

I've gone ahead with my proposal and created the Stewardship SIG.

This includes the SIGs/Stewardship wiki page [0], the @stewardship-sig
FAS group [1], to which high-priority orphaned packages can be
assigned, and the stewardship-sig mailing list [2].

- Purpose
The purpose of this SIG is to make sure fedora doesn't implode after
package mass orphanings or retirements.

rpmlint: new "executable stack" warnings on rawhide

Hi everybody,

I've noticed that as of some days ago, some packages I build on rawhide are
now triggering the "W: executable-stack" warning for all included
executables and shared libraries.

I'm not sure which change might be the cause of this, but meson 0.50.0
seems to be a good candidate, since all my affected packages are built with
meson and the new version landed six days ago.

Is that new warning something we should worry about?


modular repositories in mock configs: please don't

Hi everybody,

Recently, modular repositories were enabled in the mock configs for fedora 29+.

Now, I can't build at least one of my packages (elementary-music) in
fedora 29 chroots, due to dependency issues within modules.

Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

Hi everybody,

In the past few weeks, it has come up regularly that future
"module-only" packages are orphaned (and hence will soon be retired),
and nobody stepped up to fix this issue - especially for non-leaf
packages. I don't think fedora as a project has a solution for this

I propose to create a "Stewardship" Group / SIG that will take care of
such packages - either until a new main maintainer steps up, or until
modularity matures enough so it won't be necessary anymore.

signon-glib 2.0 soname bump (affects only telepathy-accounts-signon)

Hi everybody,

TL;DR version:

- signon-glib: update from 1.9 → 2.0
- soname bump: →
- affected packages: 1 (telepathy-accounts-signon)
- packages needing patches: 1 (↑), already available upstream

I'll push the update and make the required changes to t-a-s myself in
a week if there's no veto, and I also volunteer to become
(co-)maintainer of t-a-s.

Long version:

I'm planning to update the signon-glib package (upstream name:
libsignon-glib) to version 2.0.
This new version bump the soname from to

Intent to orphan / give to go-sig some unused leaf golang packages

Hi everybody,

I'm cleaning up my packages a bit, and I currently maintain some leaf
packages which aren't used by anything (or anything I use) at this
point in time.

The packages all have the go-sig as co-admin already, but I intend to
drop them from my radar completely.

PSA: builds using forge macros with tags broken on rawhide

Just a heads-up for anyone experiencing build failures like me.

Recently the forge macros were ported to use distprefix on f30. An
unrelated change followed and a new build was pushed to rawhide (maybe
without realising that it would also push the forge macro changes).
This change was introduced with redhat-rpm-config-121-1.fc30.

It looks like the forge macros weren't tested to be backwards
compatible, because packages that build successfully now fail to build
on rawhide (see, for example, build [0]).

The reason: The %{gosource} macro now expands to a different string on

package downgrades from f28 to f29

Hi all,

I tried upgrading my system to f29, and I noticed some packages that
would have been downgraded.

Possibly non-responsive maintainer: hguemar

Hi everybody,

There are many open bugs assigned to hguemar, which he is not
responding to at all.

Call for Help: gala + Pantheon DE on fedora 29+

Hi everybody,

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
to libmutter-3.

I reported this "issue" with the fedora mutter package on bugzilla:
<a href="" title=""></a>

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

broken package needs attention: libgda


The "libgda" package is quite broken in fedora, which is impacting
dependent programs.

- The last successful build of libgda was for the fedora 24 (!) mass
rebuild. No more recent builds succeeded, and the packages was reported as
- Not even the latest version is packaged (5.2.2 instead of 5.2.4).

This is leading to problems in all current releases of fedora.

Intent to update granite to 5.0 (includes an soname bump)

Hi everybody,

The elementary project has recently released version 5.0 of their granite
toolkit extensions library, which includes an soname bump, and some
deprecated APIs were removed.

I intend to update the granite package in rawhide next week, and I am
fairly confident that this won't cause (m)any issues because I already
basically run CI builds of all currently packaged elementary projects on
fedora (in COPR), and I don't see any compatibility issues with the latest
granite snapshots.

Affected packages
According to a repoquery, the packages affected by this so

Valid use case for modularity or not?

Hi all,

I think I finally found a scenario where building some of my (and others')
packages as modules would be beneficial.

The situation is:

- The syncthing package has a lot of golang dependencies.
- Some of them are too old in fedora, even in fedora rawhide, and some of
them have not been touched in years.
- However, some other packages may depend on those older versions, or the
packagers don't have time to check for compatibility.

The idea for a solution I came up with:

- Build syncthing as a module.
- Add "syncthing" branches to all incompatible dependencies (I guess I have
to reques

rubygem-liquid update to 4.0.0

Hi all,

I am planning to update the rubygem-liquid package (which was orphaned, and
then taken by me) to the latest upstream release, 4.0.0.

This will break the current (really outdated) rubygem-jekyll package, which
depends on liquid < 4. I have reached out to rubygem-jekyll-owner (which
should be besser82) to help with bringing jekyll up-to-date (or to take
over maintaining the package, because it looks kind of abandoned) two weeks
ago (April 23), but I have not heard back since.

What is the procedure to follow here? I don't want to just push the update
and break stuff.


fedora infrastructure problems?

Hi everybody,

Is anybody else experiencing problems with the fedora infrastructure right

- I was barely able to build a package with koji due to errors
- fedmsg messages seem to be delayed up to 20 minutes
- I can't comment on issues on right now
- fedpkg request-repo is hitting a timeout, but requests seem to get through
- git/fedpkg push hits "remote: sh:
/usr/lib/python2.7/site-packages/pagure/hooks/files/ No such
file or directory" error, and I don't get commit notifications for my repos
because of that


What to do when test gating in bodhi fails (no test results found)?


I've got two updates sitting in F26 and F27 updates-testing:

<a href="" title=""></a>
<a href="" title=""></a>

I can't push either of them to batched or stable (despite them being in
-testing for over 10 days now), because "no test results found".

Which is really annoying and the error message is ...

Spring cleaning my golang packages (orphaning now unused stuff)

Hi everybody,

I'm going to orphan some of my golang packages that were initially pulled
in by syncthing as dependencies, but have been dropped as dependencies
again (... don't ask. golang people produce dependencies like rabbits make

Most of them are fairly low maintenance packages, with only a few commits
per year (if even that), and decent coverage with unit tests.

Trying out More Go Packaging: Bugs and Questions

Hi everybody,

I've been following the (long overdue) improvements concerning go packaging
in fedora, and since I saw that packages are starting to make use of the
new mechanisms, I wanted to finally check it out and started "converting"
one of my own (one of ~50) golang packages

unannounced soname bump: gnome-desktop3 / libgnome-desktop-3

FYI, the .so version of libgnome-desktop-3 was bumped from 12 to 17
with the build of gnome-desktop3-3.27.90-1.fc28 without previous

Packages that will have to be rebuilt - if it hasn't happened already
(I didn't check individual changelogs, so no guarantee for correctness
or completeness of this list):


golang-github-chmduquesne-rollinghash license change (MIT -> MIT and BSD) with 3.0.0

The license changes from "MIT" to "MIT and BSD" as of the newly released
version 3.0.0, which has been built for rawhide and will make it to f27 and
f26 if no problems with dependent packages (syncthing) arise.

This has no real effect for fedora, since the changed license tag only
arises from a newly introduced BSD-licensed golang subpackage (the
rabinkarp64 algorithm), which is used nowhere yet - and all other parts of
the package remain MIT-licensed. So I'm just sending this notice as
required (<a href="" title=""></a>).


How to handle broken dependencies in F27?


I've got two packages (gala, wingpanel) that have broken dependencies in
F27 because of unfortunate timing:

1. GNOME 3.24 prerelease broke builds just in time for the mass rebuild,
2. upstream took a few days to come up with fixed support for GNOME 3.24,
3. I built fixed packages and they have been in rawhide and
f27-updates-testing for some time now,

Any plans for completing the go 1.9 rebase (to stable 1.9)?

According to the Change for F27 [0], all golang packages have been rebuilt
against golang 1.9beta2. In the meantime, go 1.9 stable has been released
upstream (Aug. 24, 2017) [1].

I suspect that some of the issues I am having with go / my golang packages
in fedora would be fixed by the update to the final release, since upstream
test suites targeting go 1.9 stable in travis aren't hitting any of those

What's the plan for rebasing golang to the stable release?

pagure-over-dist-git: traceback in receive-hook when pushing to new repo

I've just pushed an import commit to my first repository that was created
with fedrepo_req on pagure, and I got the following traceback from the
remote when it obviously failed to run a post-receive hook:

remote: Traceback (most recent call last):
remote: File "./hooks/post-receive.default", line 19, in <module>
remote: import pagure # noqa: E402
remote: File "/usr/lib/python2.7/site-packages/pagure/", line
60, in <module>
remote: APP.config.from_envvar('PAGURE_CONFIG')
remote: File "/usr/lib/python2.7/site-packages/flask/", line
108, in from_envvar

fedpkg new-sources broken?

Right now, I can't build updates or new packages, because "fedpkg
new-sources" is getting stuck (for more than 15 minutes) without error
message (other than the bodhi deprecation warning) and it doesn't do
anything until I kill it ...

I can't pin down the exact date it stopped working (since I don't use it
every day), but I first noticed it yesterday after installing updates from
f26-updates-testing (although those updates probably didn't cause the bug,
because downgrading to f26 stable packages didn't help).

Am I the only one affected by this bug or has nobody else been building

Review Swaps: Simple golang packages (for syncthing)

Hi everybody,

I need somebody to take on the Review Requests of the only 3 golang
dependencies that are still blocking a syncthing package:

<a href="" title=""></a>
<a href="" title=""></a>
golang-github-cznic-ql: <a href="" title=""></a>

They need to be reviewed in that order (because dependencies).

Review Swaps: (mostly) very simple golang packages

Hi everybody,

I've been putting together package Review Requests for all the golang
package dependencies of syncthing (an open source file synchronization
service). Some of them have already been reviewed (thank you, Jan! I feel
much more confident about my golang packaging now), but there are still 16
packages left.

The packages are (mostly) very simple (standard golang specs generated by
gofed), and I've added explanatory comments where they differ from the
automatically generated gofed output for the repository in question.

becoming a co-maintainer of plank

Hello Wesley,

I am working on getting all the elementary apps and pantheon desktop
components into fedora and wondered if you could approve my ACL Requests
for becoming a co-maintaner of plank (since that package is obviously also
part of a Pantheon DE and ties in with the other packages I am maintaining
already, see <a href="" title=""></a>).


becoming a co-maintainer of elementary-icon-theme

Hello Johannes,

I am working on getting all the elementary apps and pantheon desktop
components into fedora and wondered if you could approve my ACL Requests
for becoming a co-maintaner of elementary-icon-theme (since that package
obviously ties in with the other packages I am now maintaining, see
<a href="" title=""></a>).