[Unstable Update] March 2024 Edition

:grey_question:

pamac search -i pamac

Summary

libpamac 11.6.3-1 extra
Library for Pamac package manager based on libalpm
pamac-gtk 11.7.1-1 extra
A Package Manager based on libalpm with AUR and Appstream support (GTK4)
pamac-cli 11.6.0-3 extra
A CLI Package Manager based on libalpm with AUR support

pamac search pamac

Summary

pamac search pamac
libpamac-snap-plugin 11.6.3-1 extra
Snap plugin for Pamac
libpamac-nosnap 1:11.6.4-1 AUR
Pamac package manager library based on libalpm. Without Snap support
libpamac-git 11.6.4.r0.g9108cba-1 AUR
Library for Pamac package manager based on libalpm - git version
libpamac-full-git 1:11.4.1.r0.g29d7180-1 AUR
Library for Pamac package manager based on libalpm - flatpak and snap support enabled
libpamac-full 1:11.6.4-1 AUR
Library for Pamac package manager based on libalpm - flatpak and snap support enabled
libpamac-flatpak-plugin 11.6.3-1 extra
Flatpak plugin for Pamac
libpamac-debug 11.6.3-1 extra
Detached debugging symbols for libpamac
libpamac-aur 11.6.4-1 AUR
Pamac package manager library based on libalpm
libpamac 11.6.3-1 [Installed] extra
Library for Pamac package manager based on libalpm
pamac-tray-icon-plasma 0.1.3-3 AUR
Pamac tray icon for plasma users
pamac-tray-icon-plasma 0.1.3-2 extra
Pamac tray icon for Plasma users
pamac-nosnap 11.7.1-2 AUR
A Gtk3 frontend, Package Manager based on libalpm with AUR and Appstream support
pamac-gtk3-debug 10.6.0-3 extra
Detached debugging symbols for pamac-gtk3
pamac-gtk3 10.6.0-3 extra
A Package Manager based on libalpm with AUR and Appstream support (GTK3)
pamac-gnome-integration 11.7.1-1 extra
Pamac GNOME integration (GTK3)
pamac-debug 11.7.1-1 extra
Detached debugging symbols for pamac
pamac-cli-debug 11.6.0-3 extra
Detached debugging symbols for pamac-cli
pamac-classic 7.3.0-2 AUR
A Gtk3 frontend for libalpm - classic version
pamac-aur-git 11.7.1.r0.g73cef1d-1 AUR
A Gtk3 frontend for libalpm - git version
pamac-aur 11.7.1-3 AUR
A Gtk3 frontend, Package Manager based on libalpm with AUR and Appstream support
pamac-appstream-hook 1-1 AUR
Pacman hook for cleaning up Appstream data from tags that Pamac can’t handle.
pamac-all-git 1:10.4.3.r0.gd314d70-1 AUR
A Gtk3 frontend for libalpm (everything in one package - snap, flatpak, appindicator)
pamac-all 11.7.1-1 AUR
A GUI frontend for libalpm (everything in one package - snap, flatpak, appindicator, aur, appstream)
pamac-gtk 11.7.1-1 [Installed] extra
A Package Manager based on libalpm with AUR and Appstream support (GTK4)
pamac-cli 11.6.0-3 [Installed] extra
A CLI Package Manager based on libalpm with AUR support

The installed packages are in “Extra” … i.e. in the repos. Some of the other packages are in AUR.

If the ones shown in the first “Summary” are not present, sudo pacman -S pamac

1 Like

Obviously, pamac is from the Manjaro repositories. Apparently, it crashes when using a third-party repo. Removing the unsupported third-party repo is a good workaround for the issue.

Another obviously, it probably is a bug in pamac which should be fixed.

It has been fixed already, there’s an announcement 5 posts above, literally, by philm

1 Like

plasma 6.0.3 not yet in unstable?

Arch Linux - plasma-desktop 6.0.2-4
Flagged out-of-date on 2024-03-26
Version 6.0.3-1 in testing

1 Like

You can have this screenshot in the meantime:

Screenshot_20240329_183826

2 Likes

Oh come on now, you know that this is only available in the btw edition of Arch. :crazy_face:

3 Likes

[Security] [Exploit] [IMPORTANT]

Looks like xz 5.6.1 have big issues which is currently shipping with manjaro

https://www.openwall.com/lists/oss-security/2024/03/29/4

Could we return back to v5.4.6 until a new version got released ? Is it have any hard dependencies [ which manjaro needs ] ?

There is no emergency. If you’re up to date, you already have xz / lib32-xz 5.6.1-2 which addresses the issue.

4 Likes

A post was merged into an existing topic: [Stable Update] 2024-03-13 - Plasma 5.27.11, Firefox, Thunderbird, AMDVLK, Qemu

Hi,

I built a kde stable image, lib32-xz-5.6.1-2 and xz-5.6.1-2 are present.

imho, there is no actual statement if 5.6.1-2 is safe. the actual position is that “it is supposedly fixed”. i expect that this easter-egg will last some longer.

https://www.openwall.com/lists/oss-security/2024/03/29/17
https://bbs.archlinux.org/viewtopic.php?pid=2160793#p2160793

it’s a good idea to disable and mask the sshd-service for these how are scared or concerned.
this is a uncommon and in fact very vulnerable security issue by the way how it works and how it was spreaded.

1 Like

Especially (but not only) because of the (now fixed) problem with pamac, where using certain third-party repositories like mesa-nonfree led to a lockup (my post on this problem was mentioned as off-topic here!), I cloned (not deleted) my Manjaro installation and converted the clone to Arch. So, among other things I no longer need mesa-nonfree-repo because arch has not disabled accelerated hardware decoding in mesa, yet. - But thats not my point, here.

After same testing my new system i found out that any problems described here several times regarding mounting NTFS filesystems with kernel 6.8 does not exist in Archlinux.
Both, a normal NTFS-partition mounted with fstab and also some older veracrypt-containerfiles formatted with NTFS can be mounted/opened without any problem with the current Archlinux kernel (6.8.2-arch2-1). In Manjaro this was only possible up to kernel 6.7.

With manjaro-kernel 6.8 (6.8.2-1-MANJARO) for NTFS-partition (fstab)

UUID=01D590002XXXXXX	/home/XXXXX/.mnt/Sys_Progs	ntfs	iocharset=utf8,uid=1000,gid=100,umask=000,nofail	0	0

i get:

Mär 31 20:28:59 Peterputer systemd[1]: home-XXXXX-.mnt-Sys_Progs.mount: Failed with result 'exit-code'.
Mär 31 20:28:59 Peterputer systemd[1]: Failed to mount /home/XXXXX/.mnt/Sys_Progs.
Mär 31 20:28:59 Peterputer kernel: /dev/sda3: Can't open blockdev

and for a veracrypt-containerfile formatted with NTFS (tried to open with veracrypt):

fuse: mount failed: Das Gerät oder die Ressource ist belegt
Mär 31 20:36:50 Peterputer kernel: /dev/mapper/veracrypt1: Can't open blockdev
Mär 31 20:36:50 Peterputer kernel: /dev/mapper/veracrypt1: Can't open blockdev
4 Likes

I mean, cloning an existing installation of Manjaro to Arch, and having it boot up is a success on its own merit.

1 Like

Is there a pacman command to see why a new package will be installed? I see the new updates are going to install libimobiledevice-glue which I shouldn’t need?

Without using a local command, it would appear that
libimobiledevice-glue is required by libusbmuxd, which in turn is required by libimobiledevice, which is required by

gvfs-afc
ifuse
kio-extras
kio5-extras
libgpod
solid
upower
usbmuxd 

Does any of that match?

Using kernels 6.8 and 6.9rc2
“tune2fs” (part of e2fsprogs (1.47) ) does not work any longer (kernels 6.1 and 6.8 o.K.)
How do you check disks with the new kernels?

It does, Ive got kio-extras. I guess they’re pulling in an extra package for funsies then. Thanks.

Its April here, time for a change!