Description of problem: The upgrade from F28 to F29 using the interface of the update doesn't update correctly all libraries. Version-Release number of selected component (if applicable): Fedora 29 uname : 4.18.16-300.fc29.x86_64 How reproducible: try to start gedit after update from F28 to F29 Steps to Reproduce: 1.[mythcat@desk fasm]$ gedit gedit: error while loading shared libraries: libpeas-gtk-1.0.so.0: cannot open shared object file: No such file or directory 2.[root@desk mythcat]# dnf install gedit Last metadata expiration check: 0:16:04 ago on Wed 07 Nov 2018 06:22:34 PM EET. Package gedit-2:3.30.2-1.fc29.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete! Actual results: gedit: error while loading shared libraries: libpeas-gtk-1.0.so.0: cannot open shared object file: No such file or directory Expected results: to run the gedit editor Additional info:
dnf install libpeas-gtk , doesn't solve this for you ? if yes we need add Requires:libpeas-gtk to gedit .
I'm also interested to get this properly fixed. Obviously, we missed a freeze exception. Gedit seems to be a widely used and generally usual editor.
Can you post the output of: rpm -q libpeas-gtk gedit ls -l /usr/lib64/libpeas-gtk-1.0.so* rpm -V libpeas-gtk ? I don't think this is an issue with gedit packaging but something gone wrong with the libpeas-gtk installation. Perhaps the file trigger that's supposed to run ldconfig failed for some reason? Does 'sudo ldconfig' fix this? (Please run the commands above first and post the output here before trying this.)
I have the same problem, so I will just post my output from the listed debug commands. $ gedit gedit: error while loading shared libraries: libpeas-gtk-1.0.so.0: cannot open shared object file: No such file or directory $ rpm -q libpeas-gtk gedit libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 gedit-3.30.2-1.fc29.x86_64 $ ls -l /usr/lib64/libpeas-gtk-1.0.so* ls: cannot access '/usr/lib64/libpeas-gtk-1.0.so*': No such file or directory $ rpm -V libpeas-gtk (last command does not output anything and exit code is 0)
Aha! So it turns out you've somehow gotten libpeas-gtk module, not regular package. Can you try if 'dnf distro-sync libpeas*' fixes this? I suspect that there may have been an issue with repos where modular content appeared in regular repos briefly during F29 development period and then you may have gotten the wrong package installed. I've added Steven Gallagher to CC, he may be able to debug it further why you seem to have gotten wrong libpeas-gtk.
I am not able to fix this with distro-sync, but it seems like I have gotten a lot of module packages installed during F28 -> F29 upgrade. $ dnf distro-sync libpeas* $ dnf distro-sync libpeas-gtk $ dnf distro-sync
Bruno or Cătălin, can you show us the output of `dnf module list` please? I'm not sure why you'd have gotten a module version of libpeas-gtk unless you were running the feedreader:master module on F28 before the upgrade?
Hmm.. I don't recall installing feedreader but you are right I have it installed. $ dnf list | grep -i "feedreader" feedreader.x86_64 2.2-2.fc29 fedora feedreader.x86_64 2.2-2.fc29 fedora $ dnf module list Last metadata expiration check: 0:52:07 ago on fre 16 nov 2018 14:00:36 CET. No matching Modules to list $ dnf list | grep -F ".module_" | wc -l 294 $ dnf list | grep -F ".module_" > dnf_modules.txt
Created attachment 1506437 [details] List of modular packages Complete list of installed packages from fedora-modular and updates-modular that got installed.
Something has definitely gone wildly wrong here. It looks like DNF chose to install modular versions of a LOT of content that it should not have. My best guess is that you upgraded using a mirror that didn't include the module metadata properly and as a result, DNF just treated all of the module content as available for the transaction and installed any RPM package that happened to have a higher ENVR value. I don't suppose you have any logs that show which mirror you connected to? I'm betting they don't do a proper sync of the module metadata.
How did you do the upgrade to F29? Was it through DNF or gnome-software? I wonder if it can be F28 dnf/libdnf/packagekit somehow enabling the modular repos during the system upgrade to F29.
(In reply to Kalev Lember from comment #11) > How did you do the upgrade to F29? Was it through DNF or gnome-software? > > I wonder if it can be F28 dnf/libdnf/packagekit somehow enabling the modular > repos during the system upgrade to F29. Hmm, does `dnf system-upgrade` or the gnome-software upgrade use the target system's DNF for the upgrade?
(In reply to Stephen Gallagher from comment #12) > Hmm, does `dnf system-upgrade` or the gnome-software upgrade use the target > system's DNF for the upgrade? No, they both use the host system's DNF.
OK, then it's entirely possible that the upgrade happened with a version of DNF that doesn't understand the modular metadata. OUCH. I'm moving this to DNF; we probably need to backport F29's DNF to F28 to ensure that the upgrade transaction is done properly. I wonder how we missed this during upgrade testing.
(In reply to Stephen Gallagher from comment #14) > I wonder how we missed this during upgrade testing. I guess it's because the upgrade testing was done using F28 Workstation installs that didn't have the fedora-repos-modular package installed (it was split off to a subpackage in F28 and only installed by default on Server, AFAIK).
I did the system upgrade using command line after running `dnf upgrade --refresh` and rebooting the system. It's possible that the issue was caused by a RPM mirror as my Fedora 28 was using a custom `baseurl` in `fedora.repo`, `fedora-updates.repo` and `fedora-updates-testing.repo`. As we use Artifactory Pro 6.5.2 as a RPM mirror so multiple Fedora Workstations can get updates with faster downloads and less load on public mirrors. Artifactory upstream RPM mirrors: https://mirrors.dotsrc.org/fedora/ https://mirror.netsite.dk/fedora/ http://ftp.uni-bayreuth.de/linux/fedora/ https://archives.fedoraproject.org/pub/archive/fedora/ I was testing Fedora Workstation 29 in a virtual machine to make sure artifactory baseurl was configured correctly. But looking at the timestamp on repo files, it looks like I might have installed the wrong repo files from git before executing the upgrade. So the *modular*.repo files was present during upgrade from 28. Doh.
I have found a way to fix my installation. $ rm /etc/yum.repos.d/*modular* $ dnf distro-sync Seems like dnf 4.0.4 still can't handle modular packages correctly.
Please can you provide outputs from following commands? # dnf repolist # dnf module list Please can you ensure that Fedora repo files have original content? Then run both commands again.
[mythcat@desk ~]$ gedit gedit: error while loading shared libraries: libpeas-gtk-1.0.so.0: cannot open shared object file: No such file or directory [mythcat@desk ~]$ su Password: [root@desk mythcat]# dnf repolist Last metadata expiration check: 0:05:23 ago on Tue 27 Nov 2018 11:18:58 PM EET. repo id repo name status adobe-linux-x86_64 Adobe Systems Incorporated 3 code Visual Studio Code 49 *fedora Fedora 29 - x86_64 58,207 *fedora-modular Fedora Modular 29 - x86_64 8 *rpmfusion-free RPM Fusion for Fedora 29 - Free 596 *rpmfusion-free-updates RPM Fusion for Fedora 29 - Free - Updates 97 *updates Fedora 29 - x86_64 - Updates 12,321 *updates-modular Fedora Modular 29 - x86_64 - Updates 9 [root@desk mythcat]# dnf module list Last metadata expiration check: 0:05:48 ago on Tue 27 Nov 2018 11:18:58 PM EET. Fedora Modular 29 - x86_64 Name Stream Profiles Summary ant 1.10 default [d] Java build tool avocado latest minimal, defaul Framework with tools and librari t es for Automated Testing avocado stable minimal, defaul Framework with tools and librari t es for Automated Testing container-tools 2017.0 default Common tools and dependencies fo r container runtimes container-tools 2018.0 default Common tools and dependencies fo r container runtimes cri-o 1.11 default Kubernetes Container Runtime Int erface for OCI-based containers cri-o 2017.0 default Kubernetes Container Runtime Int erface for OCI-based containers cri-o 2018.0 default Kubernetes Container Runtime Int erface for OCI-based containers django 1.6 python2_develop A high-level Python Web framewor ment, default [ k d] docker 2017.0 default Module for docker runtime and do cker-distribution dwm 6.0 user, default [ Dynamic window manager for X d] dwm 6.1 [d] user, default [ Dynamic window manager for X d] dwm latest user, default [ Dynamic window manager for X d] eog master default Eye of GNOME Application Module flatpak-runtime f29 sdk-base, build Flatpak Runtime root, sdk, runt ime, runtime-ba se gcsf master default FUSE file system based on Google Drive gimp 2.10 devel, default GIMP [d] golang 1.10 default The Go Programming Language golang-ecosystem 2017.0 default The ecosystem of packages for th e Go programming language golang-ecosystem 2018.0 default The ecosystem of packages for th e Go programming language hub pre-release default A command-line wrapper for git w ith github shortcuts kubernetes 1.10 default Container cluster management kubernetes openshift-3.10 default OpenShift Container Management libgit2 0.26 Library implementation of Git libgit2 0.27 Library implementation of Git lizardfs devel Distributed, fault tolerant file system mariadb 10.1 client, server, MariaDB Module default maven 3.5 default [d] Java project management and proj ect comprehension tool meson master default The Meson Build system mongodb 3.4 client, server, MongoDB Module default mongodb 3.6 client, server, MongoDB Module default mysql 5.7 client, server, MySQL Module default ninja master default Small build system with a focus on speed nodejs 10 development, mi Javascript runtime nimal, default nodejs 8 development, mi Javascript runtime nimal, default [d] perl 5.24 minimal, defaul Practical Extraction and Report t Language perl 5.26 minimal, defaul Practical Extraction and Report t Language perl-bootstrap 5.24 Perl bootstrap module for bootra pping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootra pping Perl module pki 10.6 default Dogtag PKI postgresql 9.6 client, server, PostgreSQL module default reviewboard 2.5 server, default A web-based code review tool [d] reviewboard 3.0 server, default A web-based code review tool [d] ripgrep master default Line oriented search tool using Rust's regex library scala 2.10 default A hybrid functional/object-orien ted language for the JVM stratis 1 [d] default [d] Stratis Storage stratis master default Stratis Storage testmodule master default A test module in all its beautif ul beauty Fedora Modular 29 - x86_64 - Updates Name Stream Profiles Summary ant 1.10 default [d] Java build tool avocado latest minimal, defaul Framework with tools and librari t es for Automated Testing avocado stable minimal, defaul Framework with tools and librari t es for Automated Testing bat latest [d] default [d] cat(1) clone with wings container-tools 2017.0 default Common tools and dependencies fo r container runtimes container-tools 2018.0 default Common tools and dependencies fo r container runtimes cri-o 1.11 default Kubernetes Container Runtime Int erface for OCI-based containers cri-o 2017.0 default Kubernetes Container Runtime Int erface for OCI-based containers cri-o 2018.0 default Kubernetes Container Runtime Int erface for OCI-based containers django 1.6 python2_develop A high-level Python Web framewor ment, default [ k d] docker 2017.0 default Module for docker runtime and do cker-distribution dwm 6.0 user, default [ Dynamic window manager for X d] dwm 6.1 [d] user, default [ Dynamic window manager for X d] dwm latest user, default [ Dynamic window manager for X d] eog master default Eye of GNOME Application Module flatpak-runtime f29 sdk-base, build Flatpak Runtime root, sdk, runt ime, runtime-ba se gcsf master default FUSE file system based on Google Drive ghc 8.4 minimal, small, Haskell GHC 8.4 default gimp 2.10 devel, default GIMP [d] golang 1.10 default The Go Programming Language golang-ecosystem 2017.0 default The ecosystem of packages for th e Go programming language golang-ecosystem 2018.0 default The ecosystem of packages for th e Go programming language hub pre-release default A command-line wrapper for git w ith github shortcuts kubernetes 1.10 default Container cluster management kubernetes openshift-3.10 default OpenShift Container Management libgit2 0.26 Library implementation of Git libgit2 0.27 Library implementation of Git lizardfs devel Distributed, fault tolerant file system mariadb 10.1 client, server, MariaDB Module default maven 3.5 default [d] Java project management and proj ect comprehension tool meson master default The Meson Build system mongodb 3.4 client, server, MongoDB Module default mongodb 3.6 client, server, MongoDB Module default mysql 5.7 client, server, MySQL Module default ninja master default Small build system with a focus on speed nodejs 10 development, mi Javascript runtime nimal, default nodejs 11 development, mi Javascript runtime nimal, default nodejs 8 development, mi Javascript runtime nimal, default [d] perl 5.24 minimal, defaul Practical Extraction and Report t Language perl 5.26 minimal, defaul Practical Extraction and Report t Language perl-bootstrap 5.24 Perl bootstrap module for bootra pping Perl module perl-bootstrap 5.26 Perl bootstrap module for bootra pping Perl module pki 10.6 default Dogtag PKI postgresql 9.6 client, server, PostgreSQL module default reviewboard 2.5 server, default A web-based code review tool [d] reviewboard 3.0 server, default A web-based code review tool [d] ripgrep latest default Line oriented search tool using Rust's regex library ripgrep master default Line oriented search tool using Rust's regex library scala 2.10 default A hybrid functional/object-orien ted language for the JVM skychart devel additional-dso, Planetarium software for the adv additional-sta anced amateur astronomer rs, full, defau lt stratis 1 [d] default [d] Stratis Storage stratis master default Stratis Storage testmodule master default A test module in all its beautif ul beauty Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
(In reply to Bruno Thomsen from comment #8) > Hmm.. I don't recall installing feedreader but you are right I have it > installed. > > $ dnf list | grep -i "feedreader" > feedreader.x86_64 > 2.2-2.fc29 fedora > > feedreader.x86_64 > 2.2-2.fc29 fedora > > > $ dnf module list > Last metadata expiration check: 0:52:07 ago on fre 16 nov 2018 14:00:36 CET. > No matching Modules to list > > $ dnf list | grep -F ".module_" | wc -l > 294 > > $ dnf list | grep -F ".module_" > dnf_modules.txt I think this comment exactly describes what happen. We know that there are module packages, but no modular metadata. It means that there is a mirror that rebuild modular repo without including modular data. It means there is no problem in DNF. The problem was in repodata. I don't know who was an owner of the repository, but lets try distribution.
I think you misread that comment... the feedreader there is NOT the feedreader module, but the rpm. There is no feedreader module, just a flatpak that is appearing in the modular repos. So, perhaps this was when flatpaks were showing up in the modular repo? Yes, this is https://pagure.io/releng/issue/7827 which we really need to fix. If any flatpak was enabled as a module, it's rpms will (sometimes) override the bare rpms.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.