I will soon push a change to the z3 package, in Rawhide only, which
will result in an soname bump. The actual contents of libz3 will not
change, however. The only Fedora consumer outside of the z3 package
itself is cppcheck, which currently fails to build due to the recent
cmake change. If the cppcheck maintainers want me to try to fix that,
I will do so; otherwise, I am happy to let them fix it themselves.
The gory details for those interested:
The z3 project has two build systems: an old one, based on generating
Makefiles with python scripts, and a new one based on cmake. We have
been using the old one, because the cmake build system does not
support building z3's OCaml interface. However, the old build system
has a number of ... features ... that we had to work around, leading
to a fair amount of uncleanness in the spec file.
I have decided to take the plunge and switch to using the cmake build
system, with manual steps afterward to build the OCaml interface. The
old build system gave the z3 library an soname of "libz3.so", which
the spec file modified to be "libz3.so.0", with a versioned library
libz3.so.0.0.0. The cmake build system gives the library an soname of
"libz3.so.4.8" (where 4 and 8 are the major and minor version numbers,
respectively), with a versioned library libz3.so.188.8.131.52. This lets
me throw out a bunch of cruft, while introducing a much smaller amount
of cruft due to the OCaml interface. I think it's a win.
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.
I just noticed that a lot my packages got a FTBFS because of
failing to build on s390x. The first set of rebuilds failed with:
"BuildrootError: Requested repo (1785390) is DELETED"
The second set of rebuilds failed with:
"rpm.error: error reading package header"
The last error was also seen quite a bit during the F32 mass rebuid ...
I just checked 3 semi-random packages of the 9 FTBFS bugs filed
sofar, still at the later a only and I already got 9! And all 3
have this issue rather then being true FTBFS errors.
Now I can try to resubmit these, and resubmit again and resubmit
again, until they succeed as I did for a bunch of packages
(but not this much) during the previous mass-rebuild, but that
seems like a significant waste of mine and other contributors time.
With me Red Hat off and my Fedora contributor head on, I really
think we need to get these s390x build issues escalated. 99%
of the reasons to support s390x is because of a certain downstream
derivative of Fedora. If they care so much about this, they really
ought to fix these s30-x build issues, which seem to have been
plaguing us for at least a full cycle now (at least the second
problem mentioned above).
Alternatively, maybe we need to re-introduce secondary arches and
make s390x build failures non fatal? I dunno but IMHO we need to
do something continuing as usual with this is IMHO not a good
I have just orphaned these two packages:
I have not been able to provide them with the care they deserve.
If you are interested in the packages, please pick them up. Here's some
additional information that you may find useful if you are interested in
The original upstream for dbus-java and libmatthew-java is dead. The
last commit on dbus-java was 10 years ago . libmatthew-java doesn't
even have a source repository .
dbus-java has a new fork now which is being maintained . However, the
fork is not source or binary compatible with the original dbus-java. It
also uses a completely different build system. The fork doesn't use
libmatthew-java, but instead uses jnr-socket, among other maven
Switching to the fork would require the spec file to be mostly
It probably makes sense to retire libmatthew-java and update dbus-java
to the (incompatible) new upstream version.
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
I was using my desktop system when I got logged out. After logging back in, I found this message in my logs:
Aug 1 13:08:22 x2 journal: UID 1000 exceeded its 'bytes' quota on UID 1000.
which was then followed by:
Aug 1 13:08:22 x2 dbus-broker: Peer :1.200 is being disconnected as it does not have the resources to perform an operation.
Aug 1 13:08:22 x2 dbus-broker: Peer :1.176 is being disconnected as it does not have the resources to receive a signal it subscribed to
Aug 1 13:08:22 x2 /usr/libexec/gdm-x-session: cinnamon-session: WARNING: t+7310.22685s: Lost name on bus: org.gnome.SessionManager
Aug 1 13:08:22 x2 /usr/libexec/gdm-x-session: cinnamon-session: CRITICAL: t+7310.22738s: We failed, but the fail whale is dead. Sorry....
Aug 1 13:08:22 x2 cinnamon-session: WARNING: t+7310.22685s: Lost name on bus: org.gnome.SessionManager
Aug 1 13:08:22 x2 cinnamon-session: CRITICAL: t+7310.22738s: We failed, but the fail whale is dead. Sorry....
Aug 1 13:08:23 x2 /usr/libexec/gdm-x-session: Cinnamon warning: CurrentTime used to choose focus window; focus window may not be correct
Aug 1 13:08:23 x2 cinnamon-session: WARNING: t+7310.45021s: Playing logout sound '/usr/share/cinnamon-control-center/sounds/logout.ogg'
Does anyone have any idea what this quota message is about? I don't use quotas on my system since it's not shared.
I'm looking through F33 FTBFS issues, and I see an increasing number
of packages that fail to build because their test suites (using check)
fail to build with errors like this:
/usr/include/check.h:502:27: note: declared here
502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, int line,
path_utils/path_utils_ut.c:698:3: error: too few arguments to function
For example, gsignond-plugin-oauth, gsignond-plugin-sasl,
libaccounts-glib, signon-glib, ding-libs fail with these issues.
Any idea if that's a problem with the "check" 0.15.x builds
themselves, or if packages need to adapt to changed API here?
tl;dr - if your package [build]requires python3-dns, please test it with
python-dns from COPR  and let me know in case of any troubles.
I'm slowly getting ready to update python-dns to 2.0.0 which drops
Python 2 support. dnspython is still a release candidate but the final
release should be available soon.
Only mailman and trac-spamfilter-plugin depend on python2-dns. A new
version of trac-spamfilter-plugin should be released soon  so we can
update both together but I have no idea about plans for mailman. Is
there any ETA for Python 3 support there?
It seems that all packages with build-dependency on python3-dns build
fine  except python-ryu but the issue there seems to be caused by
Have a nice day.