I just git a "broken dependencies" notice for a package that I maintain.
The reason is that "pdftk" got retired just the other day.
I may have missed a corresponding post on fedora-devel, but I think a
heads up notice to maintainers of depending packages may be in order
before you retire a package, as a general idea.
You see, unretiring a package is so much more work than changing
As for pdftk: I see 2 failed builds for version 1.45 and none for the
current version 2.02 (which probably breaks the api anyways). What are
the plans? Retire pdftk completely? Start fresh with pdftk2?
pdflabs, the maker of pdftk, provide binary as well as source rpms for
pdftk 2.02, by the way. I might even look into packaging it but don't
want to duplicate any existing efforts.
Recently I've reported some Big Endian related test failures to an
upstream project .
I was asked by an upstream project maintainer, whether I know some free
Continuous Integration services where they can easily run their
testsuite on Big Endian.
* Upstream uses Travis CI to test on x86_64 Linux (Ubuntu)
* Upstream uses AppVeyor to test on Microsoft Windows
* It's a pure Python project, noarch, but some changes need to be done
when loading/saving binary data (LE) with NumPy on BE system.
What I've considered:
* COPR (but there is no big endian arch)
* (Ab)using Koji (I guess that would be considered a bad practice?)
* using QUEMU on Travis CI 
Any better tips? Thanks
I just had to setup a new machine, and new ssh keys.
I chose my new id_rsa.pub to upload.
But I get:
git push --verbose
Pushing to ssh://email@example.com/mercurial
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
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.
In libvirt we recently deleted a driver for the legacy Xen toolstack.
This was shipped in a libvirt-daemon-driver-xen RPM.
I am able to add an "Obsoletes: libvirt-daemon-driver-xen < 4.3.0"
line to the libvirt-daemon-driver-libxl RPM, which gives clean
upgrade path for users.
If they have the libvirt-daemon-driver-xen-debuginfo RPM installed
though that still breaks the upgrade.
How can I get the auto-generated libvirt-daemon-driver-libxl-debuginfo
RPM to have an "Obsoletes: libvirt-daemon-driver-xen-debuginfo < 4.3.0"
statement ? It seems impossible, meaning users with debuginfo have a
broken upgrade path. An unfortunate consequence of switching to seprate
-debuginfo per sub-RPM.
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
I would like to draw some attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: startx unsets DBUS_SESSION_BUS_ADDRESS, which result in launching another D-Bus session which breaks communicating with user systemd services (and any D-Bus services started before launching X) from X session via D-Bus, since they use two different D-Bus daemons. I would really like this bug to be fixed.