[Unstable Update] 2019-06-22 - Kernels, Pamac, Firefox, Python, Texlive

A pretty important regression with Pamac 8.0.0-beta: when you ask Pamac to install a AUR package with Pamac GTK, it builds the package, but does not install it right after as it used to.

It was reported by someone that isn't on Manjaro, but I verify it on Manjaro XFCE 18.1.0 RC2 (Unstable branch) and managed to reproduce it.

This issue is fixed in git now.

I was with a problem in systemd-networkd that was solved with this update :slight_smile:

All laptops upgraded fine in the konsole, but I tried one (KDE-Dev) and pamac-qt hung after showing me the packages to be removed and upgraded (I wonder the root cause was that pamac-qt wanted to remove ms-office-online, while pacman wanted to Replace ms-office-online with community/microsoft-office-online-jak?). so after maybe 20 minutes, I
$ sudo rm /var/lib/pacman/db.lck
And upgraded that one in the konsole as well

I updated needed packages as in Pamac-Dev and JAK.

1 Like

Is anyone else having problems installing RC 2 of KDE? Currently trying with Virtualbox. Also no Pamac or Octopi?

Screenshot_20190622_214019

This is now confirmed to work, just tested.

I just tried it and it wont let me complete the install.
This is the screenshot, I will investigate and get back if possible:
error
These are my specs:
Operating System: Manjaro Linux
KDE Plasma Version: 5.16.1
KDE Frameworks Version: 5.59.0
Qt Version: 5.12.4
Kernel Version: 5.1.12-1-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-7200U CPU @ 2.50GHz
Memory: 11.6 GiB of RAM

OK I've found what to blame for that, but I don't know how to resolve it properly. It is Apparmor, which I enabled (out of curiousity) with kernel parameters. As soon as I removed them, smb service started. The difference between 5.1.14 and 5.2-rc6 with regard to Apparmor is Ubuntu Apparmor patches used for 5.1.14.
I think this problem should have some Samba-related solution rather than kernel-related one.
@philm As I understand Apparmor will be used in newer installs by default right? This means some further adjustments are necessary.

Hi everyone!
I am now on manjaro deepin testing, using pamac-aur 8.0.0-beta1
I see that on this unstable announcement there are:
pamac-cli-dev - 8.0.0beta-1
pamac-common-dev - 8.0.0beta-1
pamac-gtk-dev - 8.0.0beta-1
pamac-tray-appindicator-dev - 8.0.0beta-1
Once this update reach testing, which package name should I use?

EDITED:
Also,

If I clicked on the icon of package details right side on pamac-aur it stops and didn't respond during some seconds.

:thinking:

Well, the one that is on Manjaro official repositories. :man_shrugging:

Hi @Frog,

Yes indeed, we will know it in some days .
Till then same version package have different names on two different repos branches.
( I am curious about it).

*-dev means "in development", *.beta- means it is "in tests", when they get ready for use, when get stable, they loose some of this names. They are using this names for people to experiment with them, to help developers in the development, if they show some problem you should inform about.

2 Likes

audit-2.8.5-3 wants # chmod 700 /var/log/audit/ -- mostly irrelevant anyway since we've disabled audit at the grub linux line...:hugs: for @grinner:

I'm getting a weird issue since today when I try to run the Atom Flatpak. Tested on Kernel 4.19 and 5.2

~ >>> flatpak run io.atom.Atom                                                 
bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.

Can anyone else confirm this?

This happens with all flatpaks for me, so it looks like there is something broken.

Work

?

New security settings?

1 Like

Well yes, it works after setting it up manually.

As far as I understand it, user_namespaces are configured when a Kernel gets build, so I assume there was a change "restriction" recently which now affects Flatpak.

Please correct me if I'm wrong!

The user namespaces restriction does affect gnome-control-center too.
This is what I get when I try to set a local picture for the user account.

gnome-control-center -v

20:19:40.0120                      GLib:    DEBUG: posix_spawn avoided (fd close requested) (child_setup specified) 
20:19:40.0124              GnomeDesktop:    DEBUG: Failed to launch script: bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.

Hadn't updated my Unstable VM for a few/several days, but did it today. Amongst other packages this nicely took me from Plasma 5.16.1 to 5.16.2. After reboot it still all seems good.

The only issue i noted, which is NOT unique to today's update but has been happening for months, is that after the post-reboot login, as the plasma desktop is still building, this warning typically flashes up:

Filesystem mounted at '/home' is not responding

That does not occur afaik in my Testing & Stable VMs, nor in my real Testing & Stable PCs. Given i can always navigate through all my files in Dolphin, i've never really worried about this transient message.

https://bbs.archlinux.org/viewtopic.php?pid=1850094#p1850094
You are right.Arch patched their kernels too(to make them more vanilla)So Debian way should work in Manjaro
(sysctl kernel.unprivileged_userns_clone=1)

Forum kindly sponsored by