Fedora Account System
Red Hat Associate
Red Hat Customer
<html>Internal error:<br/><br/>Error running transaction: file /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/__init__.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/__init__.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64</html> Reproducible: Always Steps to Reproduce: 1) Go for Updates in Discover. 2) Try to update libstdc++. 3) Error message. Actual Results: Error message. Expected Results: Updated, I presume. I have no idea how this website works. I understand filtering out the spam, but I also predicted the "rigid" structure this place has for someone who doesn't know much about the "behind the scenes". I just want my computer to work...
(In reply to deadspaceww from comment #0) > <html>Internal error:<br/><br/>Error running transaction: file > /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.opt-1. > pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from > package libstdc++-14.2.1-1.fc40.x86_64 [many lines snipped] Your problem doesn't seem to have anything to do with the zstr package, so I'm confused why you selected zstr as the component to file this bug against. You probably want to file it against gcc, don't you? You might want to try removing the 32-bit libstdc++, to see if anything depends on it: dnf remove libstdc++.i686 > I understand filtering out the spam, but I also predicted the "rigid" > structure this place has for someone who doesn't know much about the "behind > the scenes". I have no idea what that means. > I just want my computer to work... Don't we all. :-) I will reassign this bug to the gcc package since, as noted above, zstr seems to be uninvolved.
Looks like a dup of Bug 2308663
tl;dr This website can be confusing to the average person, so I filled a bug report as well as I could, anyone who knows what they are doing is free to edit entries or whatever, I have no idea how this deeper, more complex stuff works. I will try out some of the suggestions as soon as I am back on my Fedora PC. Down here I am writing a long text to explain myself fully, so that if anyone is interested in my motivations others than just my current libstdc++ problem they can read it. The important stuff is written in this tl;dr, the stuff below only has additional info which is not crucial to the issue. ---------------------------------------------------------------- I am sorry to not having properly chosen some options, but as I said I have no idea how any of these things work. The only thing I know is that libstdc++ refuses to update in the Discovery app and, to be honest, most people just wouldn't bother with problems like these until their PCs just stop working. I am trying out some Linux stuff because of the October 2025 date, when Windows 10 will no longer be supported, so that I can pretty much put a Linux Distro on all my family's computers. I can handle computers pretty well, but I don't code nor go "touching" stuff in such detail, that's why I chose Fedora over Arch. I am willing to help by filing bug reports when they happen, doing so as best as I can. Tho I also would like that (one day) such things may fix themselves, or may there be easier tutorials to follow. YES, many issues just require to copy/paste the magic_incantation in the Konsole, but many of us do this blindly and hope the problem to be fixed. Regardless of the OS the majority of humanity has no idea how an entire computer works in all its parts, me included. The only true difference between Windows (which does most of the magic behind the scenes since XP) and Linux Distros is that "Linux Distros are either 'stable' but VERY outdated in releases (Debian); stable and modern, but sometime need work to make them function better (Fedora) or are the equivalent of raising a child with how much one has to directly manage it (Arch)". Linux Distros come in many shapes and forms because they target different users (that's good), but almost no Distro replicates what many more popular OSs do: Just work autonomously asking "privacy yes/no" to the user. I am someone who thinkers with stuff, so I am more prone to try tofigure out problems, but some things are "not ok" to me too when, for example, I am in the contest of the OS which I'd daily drive as my personal private desktop. TO NOT MAKE IT EVEN LONGER THAN IT ALREADY IS I will conclude saying this: "My gripe is that stuff like this doesn't just solve itself on its own, and that other things like installing RPM Fusion Nvidia drivers isn't just a checkbox or a 'install yes/no .exe', since the only true difference between these and copy/pasting the magic_incantation in the Konsole, without the End User knowing what is going on, is that the latter takes way more time and steps."
(In reply to Jerry James from comment #1) > (In reply to deadspaceww from comment #0) > > <html>Internal error:<br/><br/>Error running transaction: file > > /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.opt-1. > > pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from > > package libstdc++-14.2.1-1.fc40.x86_64 > > [many lines snipped] > > Your problem doesn't seem to have anything to do with the zstr package, so > I'm confused why you selected zstr as the component to file this bug > against. You probably want to file it against gcc, don't you? > > You might want to try removing the 32-bit libstdc++, to see if anything > depends on it: > > dnf remove libstdc++.i686 > > > I understand filtering out the spam, but I also predicted the "rigid" > > structure this place has for someone who doesn't know much about the "behind > > the scenes". > > I have no idea what that means. > > > I just want my computer to work... > > Don't we all. :-) > > I will reassign this bug to the gcc package since, as noted above, zstr > seems to be uninvolved. I don't know how to crop out parts of your message effectively on this site, so for now I'll just leave them here. Here's what my PC said when I ran your command just now (I aborted the operation, I just copied what it wanted to do): Dependencies resolved. ============================================================================================================================================================ Package Architecture Version Repository Size ============================================================================================================================================================ Removing: libstdc++ i686 14.2.1-1.fc40 @updates 2.8 M Removing dependent packages: fontconfig i686 2.15.0-6.fc40 @updates 760 k freetype i686 2.13.2-5.fc40 @fedora 851 k gtk2 i686 2.24.33-18.fc40 @fedora 13 M gtk3 i686 3.24.43-1.fc40 @updates 23 M libcanberra-gtk2 i686 0.30-35.fc40 @fedora 53 k libtiff i686 4.6.0-2.fc40 @fedora 1.2 M mangohud i686 0.7.2-2.fc40 @updates 5.2 M mesa-dri-drivers i686 24.1.7-1.fc40 @updates 135 M mesa-va-drivers i686 24.1.7-1.fc40 @updates 16 M mesa-vulkan-drivers i686 24.1.7-1.fc40 @updates 94 M pango i686 1.54.0-1.fc40 @updates 1.0 M pipewire i686 1.0.8-1.fc40 @updates 368 k pipewire-alsa i686 1.0.8-1.fc40 @updates 128 k pulseaudio-libs i686 16.1-8.fc40 @updates 3.3 M steam i686 1.0.0.81-1.fc40 @rpmfusion-nonfree-steam 3.9 M Removing unused dependencies: SDL2 i686 2.30.3-1.fc40 @updates 2.0 M at-spi2-atk i686 2.52.0-1.fc40 @fedora 289 k avahi-glib i686 0.8-26.fc40 @fedora 19 k bluez-libs i686 5.78-1.fc40 @updates 198 k cairo i686 1.18.0-3.fc40 @fedora 1.8 M cairo-gobject i686 1.18.0-3.fc40 @fedora 30 k colord-libs i686 1.4.7-3.fc40 @fedora 855 k fdk-aac-free i686 2.0.0-13.fc40 @fedora 599 k flac-libs i686 1.4.3-4.fc40 @fedora 729 k fmt i686 10.2.1-5.fc40 @updates 383 k fribidi i686 1.0.14-2.fc40 @updates 366 k gdk-pixbuf2-modules i686 2.42.10-8.fc40 @fedora 235 k glfw i686 1:3.3.10-1.fc40 @updates 280 k graphite2 i686 1.3.14-15.fc40 @fedora 194 k gsm i686 1.0.22-6.fc40 @fedora 64 k gstreamer1 i686 1.24.8-1.fc40 @updates 5.7 M harfbuzz i686 8.5.0-1.fc40 @updates 2.8 M jbigkit-libs i686 2.1-29.fc40 @fedora 112 k json-glib i686 1.8.0-3.fc40 @fedora 565 k lcms2 i686 2.16-3.fc40 @fedora 459 k libGLEW i686 2.2.0-7.fc40 @fedora 680 k libICE i686 1.1.1-3.fc40 @fedora 184 k libXcomposite i686 0.4.6-3.fc40 @fedora 44 k libXcursor i686 1.2.1-7.fc40 @fedora 49 k libXdamage i686 1.1.6-3.fc40 @fedora 43 k libXft i686 2.3.8-6.fc40 @fedora 164 k libXinerama i686 1.1.5-6.fc40 @fedora 18 k libasyncns i686 0.8-28.fc40 @fedora 59 k libatomic i686 14.2.1-3.fc40 @updates 28 k libcanberra i686 0.30-35.fc40 @fedora 265 k libcanberra-gtk3 i686 0.30-35.fc40 @fedora 69 k libcloudproviders i686 0.3.5-3.fc40 @fedora 123 k libdatrie i686 0.2.13-9.fc40 @fedora 57 k libdecor i686 0.2.2-3.fc40 @fedora 163 k libedit i686 3.1-53.20240808cvs.fc40 @updates 240 k libgusb i686 0.4.9-1.fc40 @updates 161 k libicu i686 74.2-1.fc40 @fedora 35 M liblc3 i686 1.1.1-1.fc40 @updates 170 k libldac i686 2.0.2.3-15.fc40 @fedora 81 k liblerc i686 4.0.0-6.fc40 @fedora 639 k libnsl i686 2.39-22.fc40 @updates 102 k libogg i686 2:1.3.5-8.fc40 @fedora 49 k libsbc i686 2.0-4.fc40 @fedora 93 k libsndfile i686 1.2.2-2.fc40 @fedora 605 k libsoup3 i686 3.4.4-3.fc40 @fedora 1.2 M libstemmer i686 2.2.0-10.fc40 @fedora 527 k libtdb i686 1.4.10-1.fc40 @fedora 100 k libthai i686 0.1.29-8.fc40 @fedora 783 k libtracker-sparql i686 3.7.3-1.fc40 @updates 1.1 M libunwind i686 1.8.0-3.fc40 @fedora 165 k libvorbis i686 1:1.3.7-10.fc40 @fedora 771 k libwayland-cursor i686 1.23.0-2.fc40 @updates 32 k libwayland-egl i686 1.23.0-2.fc40 @updates 16 k libwebp i686 1.3.2-5.fc40 @fedora 834 k llvm-libs i686 18.1.8-2.fc40 @updates 116 M lm_sensors-libs i686 3.6.0-18.fc40 @fedora 81 k mpg123-libs i686 1.31.3-4.fc40 @fedora 830 k opus i686 1.5.1-1.fc40 @fedora 423 k pipewire-libs i686 1.0.8-1.fc40 @updates 6.7 M spdlog i686 1.12.0-4.fc40 @updates 345 k steam-devices i686 1.0.0.81-1.fc40 @rpmfusion-nonfree-steam 14 k webrtc-audio-processing i686 1.3-1.fc40 @fedora 1.3 M Transaction Summary ============================================================================================================================================================ Remove 78 Packages Freed space: 489 M Is this ok [y/N]:
I don't want to spam, but maybe the E-mail passed through the many others. Could someone tell me what is going on here? :(
I'm able to install and libstdc++-14.2.1-3.fc40.x86_64 and libstdc++-14.2.1-3.fc40.i686 on F40 without problems. It looks like Discover is only trying to update the i686 package for some reason, note how the versions differ: file /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 It's 14.2.1-3.fc40.i686 vs 14.2.1-1.fc40.x86_64 If you update both i686 and x86_64 together it should work fine. Please try 'sudo dnf update' on the command line.
(In reply to Jonathan Wakely from comment #2) > Looks like a dup of Bug 2308663 Not a dup, because this is a normal F40 installation, not Atomic.
(In reply to Jonathan Wakely from comment #6) > I'm able to install and libstdc++-14.2.1-3.fc40.x86_64 and > libstdc++-14.2.1-3.fc40.i686 on F40 without problems. > > It looks like Discover is only trying to update the i686 package for some > reason, note how the versions differ: > > file /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.pyc > from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from > package libstdc++-14.2.1-1.fc40.x86_64 > > It's 14.2.1-3.fc40.i686 vs 14.2.1-1.fc40.x86_64 > > If you update both i686 and x86_64 together it should work fine. > > Please try 'sudo dnf update' on the command line. //------------------------------------------------------ sudo dnf update --refresh [PASSWORD INSERTED] Brave Browser 20 kB/s | 2.0 kB 00:00 Fedora 40 - x86_64 46 kB/s | 28 kB 00:00 Fedora 40 openh264 (From Cisco) - x86_64 9.0 kB/s | 989 B 00:00 Fedora 40 - x86_64 - Updates 54 kB/s | 5.7 kB 00:00 Fedora 40 - x86_64 - Updates 2.0 MB/s | 1.8 MB 00:00 RPM Fusion for Fedora 40 - Free 48 kB/s | 7.8 kB 00:00 RPM Fusion for Fedora 40 - Free - Updates 21 kB/s | 7.2 kB 00:00 RPM Fusion for Fedora 40 - Nonfree 21 kB/s | 7.9 kB 00:00 RPM Fusion for Fedora 40 - Nonfree - NVIDIA Driver 66 kB/s | 7.8 kB 00:00 RPM Fusion for Fedora 40 - Nonfree - Steam 20 kB/s | 7.4 kB 00:00 RPM Fusion for Fedora 40 - Nonfree - Updates 73 kB/s | 7.4 kB 00:00 Dependencies resolved. ============================================================================================================================================================ Package Architecture Version Repository Size ============================================================================================================================================================ Upgrading: libstdc++ i686 14.2.1-3.fc40 updates 953 k Transaction Summary ============================================================================================================================================================ Upgrade 1 Package Total size: 953 k Is this ok [y/N]: y Downloading Packages: [SKIPPED] libstdc++-14.2.1-3.fc40.i686.rpm: Already downloaded Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/__init__.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/__init__.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64
(In reply to deadspaceww from comment #8) > sudo dnf update --refresh > [PASSWORD INSERTED] > Brave Browser > 20 kB/s | 2.0 kB 00:00 > Fedora 40 - x86_64 > 46 kB/s | 28 kB 00:00 > Fedora 40 openh264 (From Cisco) - x86_64 > 9.0 kB/s | 989 B 00:00 > Fedora 40 - x86_64 - Updates > 54 kB/s | 5.7 kB 00:00 > Fedora 40 - x86_64 - Updates > 2.0 MB/s | 1.8 MB 00:00 > RPM Fusion for Fedora 40 - Free > 48 kB/s | 7.8 kB 00:00 > RPM Fusion for Fedora 40 - Free - Updates > 21 kB/s | 7.2 kB 00:00 > RPM Fusion for Fedora 40 - Nonfree > 21 kB/s | 7.9 kB 00:00 > RPM Fusion for Fedora 40 - Nonfree - NVIDIA Driver > 66 kB/s | 7.8 kB 00:00 > RPM Fusion for Fedora 40 - Nonfree - Steam > 20 kB/s | 7.4 kB 00:00 > RPM Fusion for Fedora 40 - Nonfree - Updates > 73 kB/s | 7.4 kB 00:00 > Dependencies resolved. > ============================================================================= > ============================================================================= > == > Package Architecture > Version Repository > Size > ============================================================================= > ============================================================================= > == > Upgrading: > libstdc++ i686 > 14.2.1-3.fc40 updates > 953 k > > Transaction Summary > ============================================================================= > ============================================================================= > == > Upgrade 1 Package > > Total size: 953 k > Is this ok [y/N]: y > Downloading Packages: > [SKIPPED] libstdc++-14.2.1-3.fc40.i686.rpm: Already downloaded > > Running transaction check > Transaction check succeeded. > Running transaction test > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: Transaction test error: > file > /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.opt-1. > pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from > package libstdc++-14.2.1-1.fc40.x86_64 I don't know what's happened to your system, but this makes absolutely no sense. Why is it trying to update libstdc++.i686 to 14.2.1-3 but not ALSO trying to update libstdc++.x86_64 to the same version? It looks like you've pinned libstdc++.x86_64 to an older version, which is blocking it from being updated (and that means you can't update the i686 one either). Please try: sudo dnf install libstdc++-14.2.1-3.fc40.i686 libstdc++-14.2.1-3.fc40.x86_64 This should show why the x86_64 package is not being updated. I notice you have a repo called "Brave Browser" which might be blocking the update. You could also try this to get more info: sudo dnf --disablrepo=* --enablerepo=updates install libstdc++-14.2.1-3.fc40.i686 libstdc++-14.2.1-3.fc40.x86_64 (but please try the other suggested command first)
(In reply to Jonathan Wakely from comment #9) /////My comment here.///// > > I don't know what's happened to your system, but this makes absolutely no > sense. > > Why is it trying to update libstdc++.i686 to 14.2.1-3 but not ALSO trying to > update libstdc++.x86_64 to the same version? > It looks like you've pinned libstdc++.x86_64 to an older version, which is > blocking it from being updated (and that means you can't update the i686 one > either). > > Please try: > > sudo dnf install libstdc++-14.2.1-3.fc40.i686 libstdc++-14.2.1-3.fc40.x86_64 > > This should show why the x86_64 package is not being updated. > > I notice you have a repo called "Brave Browser" which might be blocking the > update. > > You could also try this to get more info: > > sudo dnf --disablrepo=* --enablerepo=updates install > libstdc++-14.2.1-3.fc40.i686 libstdc++-14.2.1-3.fc40.x86_64 > > (but please try the other suggested command first) In short: Brave is "Brave Browser", just one of the many cromium ones. Among everything that I did with my PC, the ONLY thing I believe may have done something to it was trying to install newer Nvidia drivers (it was around the 23rd of august) from the website instead than waiting for newer ones to come out in a forever and a half (they were, like, still at 355 or something and Windows already had 360+ or something). IF that was the reason why I am having this issue, then it may be properly reported to anyone who it may has to be reported to, if it ain't then it's a different thing which still needs to be understood. Now, I ran your command and this is what it wrote: $ sudo dnf install libstdc++-14.2.1-3.fc40.i686 libstdc++-14.2.1-3.fc40.x86_64 [LE PASSWORD ZONE]: (edited out my account's name) Fedora 40 - x86_64 - Updates 94 kB/s | 15 kB 00:00 Fedora 40 - x86_64 - Updates 4.4 MB/s | 4.5 MB 00:01 Last metadata expiration check: 0:00:01 ago on Thu 24 Oct 2024 05:08:15 CEST. Package libstdc++-14.2.1-3.fc40.x86_64 is already installed. Dependencies resolved. ============================================================================================================================================================ Package Architecture Version Repository Size ============================================================================================================================================================ Upgrading: libstdc++ i686 14.2.1-3.fc40 updates 953 k Transaction Summary ============================================================================================================================================================ Upgrade 1 Package Total size: 953 k Is this ok [y/N]: y Downloading Packages: libstdc++-14.2.1-3.fc40.i686.rpm 2.3 MB/s | 953 kB 00:00 ------------------------------------------------------------------------------------------------------------------------------------------------------------ Total 1.7 MB/s | 953 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/__init__.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/__init__.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-312.opt-1.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-312.pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from package libstdc++-14.2.1-1.fc40.x86_64 From what I read here "stuff A" conflict with "package in stuff B". I DO NOT know much about Linux, but I have heard that here stuff is not contained under the same directory/folder, and that any developer is free to chuck stuff wherever they want, and sometimes these things also conflict. IF an advice that may be given here will be "try running *sudoapt unintall + reinstall* on libstdc++" then I'd first prefer to be sure to not risk my entire installation. I don't have anything important here, as I said above I am taking advantage of this last year Windows 10 will still be covered, but I also don't want to both reinstall from 0 the OS ;AND; reinstall ALL the software and games from 0, also taking into consideration the minute differences I had to apply on them to make run, ASIDE from their size alone.
Just reminding that this is first Fedora, then it's also KDE, and then ALSO also EVERYONE who doesn't just watche videos at 15FPS on Nvidia cards uses RPM Fusion, which I believe it's the main thing through which I installed stuff like Steam? I don't know, I don't really care also, I shouldn't care, I am an end-user. But I am an end-user which both likes to thinker and HATES Windows 11, so I am open to do my part in helping with these stuff. I can't wait for the day a Linux Distro comes out and will demonstrate itself to be at least AS user friendly as Windows XP.
(In reply to deadspaceww from comment #10) > Package libstdc++-14.2.1-3.fc40.x86_64 is already installed. OK this says you have libstdc++-14.2.1-3.fc40.x86_64 > Error: Transaction test error: > file > /usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.opt-1. > pyc from install of libstdc++-14.2.1-3.fc40.i686 conflicts with file from > package libstdc++-14.2.1-1.fc40.x86_64 And this says you have libstdc++-14.2.1-1.fc40.x86_64 So your system is messed up. Probably by interrupting an update before it finished. You probably have three copies of libstdc++ installed, try 'rpm -q libstdc++' to confirm. I expect it to show: libstdc++-14.2.1-1.fc40.i686 libstdc++-14.2.1-1.fc40.x86_64 libstdc++-14.2.1-3.fc40.x86_64 Try running: sudo dnf erase libstdc++-14.2.1-3.fc40.x86_64 This should erase the newer 64-bit one. Then you should be able to just run 'sudo dnf update' > From what I read here "stuff A" conflict with "package in stuff B". > I DO NOT know much about Linux, but I have heard that here stuff is not > contained under the same directory/folder, and that any developer is free to > chuck stuff wherever they want, and sometimes these things also conflict. That has nothing to do with this problem. You've just managed to get into a broken state with two different copies of the same package installed. The package manager is supposed to avoid that, but if you interrupt it or reboot while it's updating, the update might not finish properly.
$ rpm -q libstdc++ libstdc++-14.2.1-1.fc40.x86_64 libstdc++-14.2.1-1.fc40.i686 libstdc++-14.2.1-3.fc40.x86_64 Ok, so now: sudo dnf erase libstdc++-14.2.1-3.fc40.x86_64 X Dependencies resolved. ============================================================================================================================================================ Package Architecture Version Repository Size ============================================================================================================================================================ Removing: libstdc++ x86_64 14.2.1-3.fc40 @updates 2.8 M Transaction Summary ============================================================================================================================================================ Remove 1 Package Freed space: 2.8 M Is this ok [y/N]: n Operation aborted. AS I SAID BEFORE I'd prefer not to reinstall everything from 0. IF I were to delete it, would it just re-install itself, or would it just get more messed up and need even more work?
Wait... now that I read it better I may understand what you are telling me. Instead of deleting the "older version" you want me to delete the newer one, allowing the older one to upgrade itself, right?
Yes. I'm not asking you to reinstall everything from zero. Just remove that one package which is blocking the updates. Please run that command and delete that package, then just update as normal. When it asks [y/N] say yes.
Update: I did what Jon said, it seems to have worked. I'd keep this Bug 2317917 page open for some more time tho, in case something else happens (to open another help page because a new unpredictable issue arose is, honestly, stupid), but that decision doesn't fall on me. I'd also ask for help on another thing, so that I may open a new help page properly, if needed: It seems to happen on both Windows 10 and Fedora KDE on this one computer I have (both OS are on entirely separate drives). Both sometimes do this, but Linux does it more. Windows 10 stutters video output and all other "actions" when I am on desktop, and the audio sounds like if you were to hold spacebar on YouTube (some months ago this would pause and unpause the video in rapid succession as long as it was held, making the audio sound like a machine gun); on Fedora KDE instead sometimes it completely cuts out the audio, but what most often happens is that all inputs, even the mouse's, are delayed if not completely interrupted, the video output completely freezes (even videos) but the audio goes on normally, then stutters and then resumes normally again - and this can last up to a minute. On Windows 10 it's basically random, I do not know why it happens, while on Fedora KDE it mostly happens if I start up two or more apps as soon as the PC goes to Desktop (like Brave and Steam). Fedora KDE seems to have problems with handling this, for some reason, and obviously it also happens outside of this most common case. It's really bizzare and I don't understand why this would ever happen.
(In reply to deadspaceww from comment #16) > I'd keep this Bug 2317917 page open for some more time tho, in case > something else happens No, this issue is resolved. If something else happens, please open a new bug for the relevant component. For your other issue, a bugzilla bug doesn't seem like the right way to get help with that - the problem isn't specific to Fedora, and is only vaguely described. You might have more luck at https://discussion.fedoraproject.org/
(In reply to Jonathan Wakely from comment #17) > (In reply to deadspaceww from comment #16) > > I'd keep this Bug 2317917 page open for some more time tho, in case > > something else happens > > No, this issue is resolved. If something else happens, please open a new bug > for the relevant component. > > For your other issue, a bugzilla bug doesn't seem like the right way to get > help with that - the problem isn't specific to Fedora, and is only vaguely > described. You might have more luck at https://discussion.fedoraproject.org/ Thanks, I'll see what I have to do.