Comments
mtasaka
Problem 2: package glycin-loaders-2.0~rc-3.fc43.i686 from updates-testing requires libheif.so.1, but none of the providers can be installed
- package libheif-1.20.1-2.fc43.i686 from fedora requires libopenh264.so.8, but none of the providers can be installed
- package libheif-1.20.2-3.fc43.i686 from updates-testing requires libopenh264.so.8, but none of the providers can be installed
- package glycin-libs-2.0~rc-3.fc43.i686 from updates-testing requires glycin-loaders(x86-32) = 2.0~rc-3.fc43, but none of the providers can be installed
- installed package openh264-2.6.0-2.fc43.x86_64 conflicts with openh264 provided by noopenh264-2.6.0-2.fc43.i686 from fedora
- installed package openh264-2.6.0-2.fc43.x86_64 obsoletes noopenh264 < 1:0 provided by noopenh264-2.6.0-2.fc43.i686 from fedora
- package gdk-pixbuf2-2.43.5-2.fc43.i686 from updates-testing requires libglycin-2.so.0, but none of the providers can be installed
- cannot install the best update candidate for package openh264-2.6.0-2.fc43.x86_64
- cannot install the best update candidate for package gdk-pixbuf2-2.43.3-7.fc43.i686
So when previously mozilla-openh264.x86_64 and openh264.x86_64, gdk-pixbuf2-2.43.3-7.fc43.i686, and gdk-pixbuf2-2.43.3-7.fc43.x86_64 are installed:
- New gdk-pixbuf2-2.43.5-2.fc43.i686 requires new dependency libglycin-2.so.0 <- which tries to pull in glycin-loaders-2.0~rc-3.fc43.i686
- So newly dependency glycin-loaders-2.0~rc-3.fc43.i686 requires libheif.i686, which tries to pull in libopenh264.so.8
- But this fails because openh264-2.6.0-2.fc43.x86_64 obsoletes noopenh264 < 1:0 (epoch is here, and obsoletes happends regardless of arch), and even noopenh264.i686 explicitly conflicts with openh264 (again regardless of arch)
- So dnf gives up...
In short, when previously mozilla-openh264.x86_64 and gdk-pixbuf2-2.43.3-7.fc43.x86_64 are installed, upgrade fails.
bodhi updates query --mine --status=testing is now working again (ref: bug 2389200)
Unpushing for now.
Works
Now this can be pushed to stable (as 2 weeks has passed in testing) ?
Works with python3.13 on Fedora 41.
xvfb-run now works with this mesa.
At least now abrt seems to catch segv.
Confirmed this breaks sssd.
This breaks python3-pynn.
This breaks python3-pynn.
Error:
Problem: package python3-pynn-0.11.0-1.fc39.x86_64 from fedora requires libnestkernel.so.3()(64bit), but none of the providers can be installed
- package python3-pynn-0.11.0-1.fc39.x86_64 from fedora requires libnestutil.so.3()(64bit), but none of the providers can be installed
BTW kernel-tools.src is retired on F40, commit message says that now kernel-tools on F40 are to be built from kernel.src:
But the corresponding new kernel.src (including kernel-tools-libs.x86_64 or so) is not pushed into F40 compose or koji buildroot yet. Now This is causing some dependency breakage, and Live spin compose failure on Fedora-MATE_Compiz-Live and Fedora-Jam_KDE-Live:
https://koji.fedoraproject.org/koji/taskinfo?taskID=112865990 https://koji.fedoraproject.org/koji/taskinfo?taskID=112866006
Can new kernel.src be pushed into compose soon, or can kernel-tools be revived temporarily?
This update will install lots of additional dependencies:
=========================================================================================================================================
Package Architecture Version Repository Size
=========================================================================================================================================
Upgrading:
libdecor i686 0.2.1-2.fc39 updates-testing 60 k
libdecor x86_64 0.2.1-2.fc39 updates-testing 58 k
Installing dependencies:
at-spi2-atk i686 2.50.0-1.fc39 fedora 92 k
at-spi2-core i686 2.50.0-1.fc39 fedora 378 k
atk i686 2.50.0-1.fc39 fedora 82 k
avahi-libs i686 0.8-24.fc39 fedora 73 k
cairo-gobject i686 1.18.0-1.fc39 fedora 17 k
colord-libs i686 1.4.6-6.fc39 fedora 245 k
cups-libs i686 1:2.4.7-2.fc39 updates 285 k
gdk-pixbuf2 i686 2.42.10-5.fc39 fedora 489 k
gdk-pixbuf2-modules i686 2.42.10-5.fc39 fedora 90 k
gtk3 i686 3.24.38-3.fc39 fedora 5.1 M
jbigkit-libs i686 2.1-26.fc39 fedora 53 k
json-glib i686 1.8.0-1.fc39 fedora 170 k
keyutils-libs i686 1.6.1-7.fc39 fedora 32 k
krb5-libs i686 1.21.2-2.fc39 updates 808 k
lcms2 i686 2.15-2.fc39 fedora 193 k
libXcomposite i686 0.4.5-10.fc39 fedora 23 k
libXcursor i686 1.2.1-4.fc39 fedora 32 k
libXinerama i686 1.1.5-3.fc39 fedora 14 k
libXrandr i686 1.5.4-1.fc39 updates 29 k
libatomic i686 13.2.1-6.fc39 updates 36 k
libcloudproviders i686 0.3.5-1.fc39 updates 49 k
libcom_err i686 1.47.0-2.fc39 fedora 26 k
libepoxy i686 1.5.10-4.fc39 fedora 259 k
libevent i686 2.1.12-9.fc39 fedora 277 k
libgusb i686 0.4.8-1.fc39 updates 67 k
libicu i686 73.2-2.fc39 fedora 11 M
libjpeg-turbo i686 2.1.4-3.fc39 fedora 198 k
liblerc i686 4.0.0-4.fc39 fedora 217 k
libnghttp2 i686 1.55.1-4.fc39 updates 82 k
libpsl i686 0.21.2-4.fc39 fedora 63 k
libsoup3 i686 3.4.4-1.fc39 updates 410 k
libstemmer i686 2.2.0-7.fc39 fedora 156 k
libtiff i686 4.4.0-8.fc39 fedora 219 k
libtracker-sparql i686 3.6.0-1.fc39 fedora 395 k
libusb1 i686 1.0.26-3.fc39 fedora 77 k
libverto i686 0.3.2-6.fc39 fedora 21 k
libwayland-egl i686 1.22.0-2.fc39 fedora 13 k
libwebp i686 1.3.2-2.fc39 fedora 295 k
libxkbcommon i686 1.6.0-1.fc39 updates 147 k
sqlite-libs i686 3.42.0-7.fc39 fedora 718 k
Transaction Summary
=========================================================================================================================================
Install 40 Packages
Upgrade 2 Packages
Can't %{_libdir}/libdecor/plugins-1/libdecor-gtk.so be split to another subpackage?
Looks good. The issue of segfault with touching file with multibyte file name is now fixed.
Now ruby koschei build is successful with this checksec, thank you.
Currently evolution-data-server is messed up with next EDS update by FEDORA-2023-c7966e0bc9 . As F38 testing freeze period still continues, I think it is better to rebuild EDS 3.47.3 with this side tag and include rebuilt EDS into this update request.
This is going to break python-lfpy.
Problem: problem with installed package python3-lfpy-2.2.6-5.fc37.x86_64
- cannot install the best update candidate for package python3-lfpy-2.2.6-5.fc37.x86_64
- package python3-lfpy-2.2.6-5.fc37.x86_64 requires (python3.11dist(lfpykit) < 0.5~~ with python3.11dist(lfpykit) >= 0.4), but none of the providers can be installed
- cannot install the best update candidate for package python3-lfpykit-0.4-3.fc37.noarch
- cannot install both python3-lfpykit-0.5-1.fc37.noarch and python3-lfpykit-0.4-3.fc37.noarch
- cannot install both python3-lfpykit-0.4-3.fc37.noarch and python3-lfpykit-0.5-1.fc37.noarch
The fact is that even if rubygem-racc-1.6.0-205.fc38 is installed, when I change the line of "# stub: racc 1.6.0 ruby lib" line in racc-1.6.0.gemspec to 1.6.1, the above error is reproduced, on the other hand, even if rubygem-racc-1.6.1-200.fc38 is insalled, changing the line "# stub: racc 1.6.1 ruby lib" to 1.6.0 removes the above error.
So I think there is some path search mechanism confusion when default gem and "external" racc gem are both installed: I guess that when rubygem-racc-1.6.1-200.fc38 is installed, activerecord (or some dependency gem or so) tries to search path for 1.6.1 is "default gem" and it is failing, perhaps. Anyway not a fault for this update, so far.
The previous comment was "when previously mozilla-openh264.x86_64 and gdk-pixbuf2-2.43.3-7.fc43.i686 are installed"