s390x kernel disabled on Fedora rawhide
by Laura Abbott
gcc9 exposed an underlying issue with some inline asm on s390x. I've emailed
upstream about the issue but it's still not fixed. In the interest of
continuing to test kernels, I've disabled this arch in rawhide kernels
for now. I'll be keeping an eye on this and plan to turn this arch back
on as soon as I can.
Thanks,
Laura
5 years, 3 months
libicu 63 update with soname bump in rawhide/F30
by Pete Walter
Hi,
I'm updating icu to 63.1 in rawhide and rebuilding anything that links with libicu. We'll also have a compat package with libicu 62 soname, so I don't expect much rawhide breakage: anything that is currently built with libicu 62 but fails to build with libicu 63 should just continue using the compat package.
Thanks,
Pete
5 years, 3 months
systemd unit file not updated on new package update
by Germano Massullo
Hello, I am testing various changes in boinc-client systemd unit file.
At every RPM package update, it happens really often that on a machine
that installs the new RPM version, does not get the new systemd unit
file version, so it is not updated. To successfully update the file, I
have to remove the old one from
/etc/systemd/system/
and reinstall the RPM file.
How can this happen? Perhaps manual edits (on localhost) can prevent
the file to be updated?
Thank you
5 years, 3 months
Listing maintainers vs packages vs dependencies
by Dridi Boukelmoune
Greetings,
I'm planning to work on the python packages I maintain to move them to
python 3 only as per the python 2 deprecation in f30.
I would like to find all the dependencies of my packages of interest,
but couldn't find an off-the-shelf script I would feed SRPM names that
would recursively repoquery their resulting RPMs provides to finally
find whatever requires them. Do we have that in stock? It's not that I
can't script it out myself but I'd rather not waste time and so far
browsing the wiki/docs and the releng pagure repository yielded
nothing.
I know that at least one package I maintain has a dependency, and I'm
curious where the script to get maintainers per package and then
packages per maintainer lives. Since multiple people posted on this
list with that kind of output I assume such a script exists somewhere.
Thanks,
Dridi
5 years, 3 months
rpmbuild: File listed twice (but only build-ids)
by Richard Shaw
I'm working on the recent release of mythtv and everything compiled fine
until I got to the rpm packaging part which I got the following output:
File listed twice:
/usr/lib/.build-id/01/02700911bb4fe728258f16703a35d816ddb31f
File listed twice:
/usr/lib/.build-id/5f/dc725022956f8f935afc0d29ad91594f57ee6e
File listed twice:
/usr/lib/.build-id/67/82796d2132f1b0dc2f865d208297340b1e7005
File listed twice:
/usr/lib/.build-id/83/30ab4fd5e920cc992a734b234d62fc7895db0f
File listed twice:
/usr/lib/.build-id/94/1a02be6311015e5b7f7b1778d463475925b5bc
File listed twice:
/usr/lib/.build-id/ae/d6aef663c2c17307251cb23e598212ad41d3d8
File listed twice:
/usr/lib/.build-id/d9/dfc4a918c04b597302215241b783a1fb0ca84d
File listed twice:
/usr/lib/.build-id/e6/306d3c48dc40e9927d9408900cb773dda95c48
---
For one, the output isn't very useful so I shelled into the mock and looked
up the "offending files":
02700911bb4fe728258f16703a35d816ddb31f ->
../../../../usr/lib64/libmythavformat.so.58.12.100
dc725022956f8f935afc0d29ad91594f57ee6e ->
../../../../usr/lib64/libmythavdevice.so.58.3.100
82796d2132f1b0dc2f865d208297340b1e7005 ->
../../../../usr/lib64/libmythavcodec.so.58.18.100
30ab4fd5e920cc992a734b234d62fc7895db0f ->
../../../../usr/lib64/libmythswscale.so.5.1.100
1a02be6311015e5b7f7b1778d463475925b5bc ->
../../../../usr/lib64/libmythavutil.so.56.14.100
d6aef663c2c17307251cb23e598212ad41d3d8 ->
../../../../usr/lib64/libmythpostproc.so.55.1.100
dfc4a918c04b597302215241b783a1fb0ca84d ->
../../../../usr/lib64/libmythswresample.so.3.1.100
306d3c48dc40e9927d9408900cb773dda95c48 ->
../../../../usr/lib64/libmythavfilter.so.7.16.100
---
I looked through the spec file and can't find where it's being included
twice, and why only the build-ids are listed twice, not the libraries
themselves.
$ grep "%{_libdir}" rpmbuild/mythtv/SPECS/mythtv.spec
%dir %{_libdir}/mythtv
%{_libdir}/mythtv/filters/
%dir %{_libdir}/mythtv/plugins
%exclude %{_libdir}/libmythav*.so.*
%exclude %{_libdir}/libmythpostproc.so.*
%exclude %{_libdir}/libmythswscale.so.*
%exclude %{_libdir}/libmythswresample.so.*
%{_libdir}/*.so.*
%{_libdir}/*.so
%{_libdir}/libmythav*.so.*
%{_libdir}/libmythpostproc.so.*
%{_libdir}/libmythswscale.so.*
%{_libdir}/libmythswresample.so.*
%{_libdir}/mythtv/plugins/libmytharchive.so
%{_libdir}/mythtv/plugins/libmythbrowser.so
%{_libdir}/mythtv/plugins/libmythgallery.so
%{_libdir}/mythtv/plugins/libmythgame.so
%{_libdir}/mythtv/plugins/libmythmusic.so
%{_libdir}/mythtv/plugins/libmythnews.so
%{_libdir}/mythtv/plugins/libmythweather.so
%{_libdir}/mythtv/plugins/libmythzoneminder.so
%{_libdir}/mythtv/plugins/libmythnetvision.so
Is the %exclude just not working for the build-ids? That's all I can come
up with.
Help appreciated.
Thanks,
Richard
5 years, 3 months
Call for zchunk repodata testers
by Jonathan Dieter
Just a heads up Rawhide has had zchunked metadata for almost three
weeks, and I'd greatly appreciate some more testing on the client side
before we finish pushing the client changes to Rawhide.
If you're running Rawhide, are willing to test, and have backups of
libdnf and librepo, please enable the COPR by running:
dnf copr enable jdieter/dnf-zchunk
dnf update librepo libdnf
At this point all tools using libdnf will default to zchunked metadata
if it's available.
If the second day's repository download size for Rawhide is less than
54MB, you'll know everything's working correctly.
--- Details, feel free to ignore ---
I've been testing it on Rawhide for the last three weeks or so, and the
minimum I've downloaded has been about 1.2MB (updating every day),
while the max today was about 7.9MB (haven't updated for over a week).
So far, I haven't hit any bugs, but I've only been regularly testing
DNF in the terminal. I did do initial testing with PackageKit and
microdnf, and they worked fine too.
Currently only primary.xml, filelists.xml and other.xml are zchunked,
but I've just finished extending zchunk support to all metadata types
in createrepo_c, and the changes should be making their way to Rawhide
sometime in the not-to-distant future.
Again, a huge thank you to everyone who's helped with this, and
especially to Daniel Mach for reviewing the large invasive patches
required to make all this work, Neal Gompa for helping push this
change, and Kevin Fenzi for flipping the switch to start generating
zchunked metadata in Rawhide.
Jonathan
5 years, 3 months