[Unstable Update] 2021-01-17 - Kernels, Powerline-Go, Mutter, Python

It’s now fixed with 3.35.1-2.

No idea. I just used the AUR PKGBUILD to update it. @jonathon maintains it.

1 Like

All looks good:
UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

Just updated to this version, taking a look over the behavior from now.

Apparently it’s Phil:

Oh wait, no, that’s the ARM package.

Fixes to the upstream project are welcome.

Cannot update this morning. I have the following;

conflicting files:
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-am-et.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-broadway.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-cedilla.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-cyrillic-translit.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-inuktitut.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-ipa.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-multipress.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-thai.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-ti-er.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-ti-et.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-viqr.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-wayland.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-waylandgtk.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/immodules/im-xim.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-cloudprint.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-cups.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-file.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-lpr.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/libgailutil-3.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/libgailutil-3.so.0 already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/libgailutil-3.so.0.0.0 already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/libgdk-3.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/libgdk-3.so.0 already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/libgdk-3.so.0.2404.23 already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/libgtk-3.so already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/libgtk-3.so.0 already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/libgtk-3.so.0.2404.23 already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/pkgconfig/gail-3.0.pc already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/pkgconfig/gdk-3.0.pc already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/pkgconfig/gdk-broadway-3.0.pc already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/pkgconfig/gdk-wayland-3.0.pc already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/pkgconfig/gdk-x11-3.0.pc already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/pkgconfig/gtk+-3.0.pc already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/pkgconfig/gtk+-broadway-3.0.pc already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/pkgconfig/gtk+-unix-print-3.0.pc already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/pkgconfig/gtk+-wayland-3.0.pc already exists in filesystem (owned by gtk3)
- lib32-gtk3: /usr/lib/pkgconfig/gtk+-x11-3.0.pc already exists in filesystem (owned by gtk3)
1 Like

I would have thought, a lib32* package would place it’s files in usr/lib32 instead of usr/lib :man_shrugging:

Yes, that’s it. When I held back lib32-gtk3, my system updated and survived a reboot. I grabbed lib32-gtk3-3.24.27-2-x86_64.pkg.tar from Arch and all is well.

oups… my system broke with todays update…

(13/17) Probing GTK3 input method modules…
/usr/bin/gtk-query-immodules-3.0: error while loading shared libraries: libgtk-3.so.0: wrong ELF class: ELFCLASS32
error: command failed to execute correctly
(14/17) Probing 32-bit GTK3 input method modules…
Cannot load module /usr/lib/gtk-3.0/3.0.0/immodules/im-scim.so: /usr/lib/gtk-3.0/3.0.0/immodules/im-scim.so: wrong ELF class: ELFCLASS64
/usr/lib/gtk-3.0/3.0.0/immodules/im-scim.so does not export GTK+ IM module API: /usr/lib/gtk-3.0/3.0.0/immodules/im-scim.so: wrong ELF class: ELFCLASS64
error: command failed to execute correctly

any application I start it gives this error

[wolfyrion@wpc ~]$ brave
/usr/lib/brave/brave: error while loading shared libraries: libgtk-3.so.0: wrong ELF class: ELFCLASS32

any solution?

I have installed gtk3-classic and it worked

1 Like

I’ll wait for a package fix in manjaro branch.

philm has pushed to unstable

I think my mirror is not synced yet

lib32-gtk3 issue fixed here. $50 just donated to manjaro US opencollective. Thanks team.

2 Likes

With linux512-headers package i got this error:

errore: impossibile eseguire l’operazione richiesta (file in conflitto)
linux512-headers: /usr/lib/modules/5.12.0-1-MANJARO/build/scripts/dtc/.yamltree.o.cmd è già presente nel filesystem
linux512-headers: /usr/lib/modules/5.12.0-1-MANJARO/build/scripts/dtc/yamltree.o è già presente nel filesystem

Will GNOME 40 appear in unstable branch tomorrow or will you wait until most important extensions can work with it?

This is unstable branch - there is/should be no holding back packages.
How else should anyone determine proper working?

No. Arch Staging > Arch Stable > Manjaro Unstable takes a couple of weeks usually.

3 Likes

You don’t want it believe me. Even in Fedora a vanilla Gnome without extensions at all is prone to crashing with a message like “sorry something went wrong” on a white screen of death still without obvious means of restarting it.
I’d rather wait for a stable release.

You are right, I don’t want GNOME without extensions. :slightly_smiling_face: And I’m glad to hear, that it won’t appear in Manjaro Unstable right in the release day.

@openminded
Yes, have seen that on a recent Fedora installation.