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

Hello community,

I am happy to announce another Unstable Update.

This update holds the following changes:

  • We updated most of our kernels. Also we removed all EOL kernels: 318, 420 & 50
  • texlive got it's first 2019 release
  • UI updates and new features landed in our Pamac v8.0 Beta
  • The usual Firefox updates
  • Python updates broke JAK. Therefore launchers such as ms-office-online currently don't work
  • Manjaro Juhraya ISOs got updated, including snap support pre-activated: XFCE, KDE, Gnome

Give us the usual feedback and let us know what you think about this update.

Current supported Kernels

  • linux316 3.16.69
  • linux44 4.4.183 (no legacy nvidia-340 module!)
  • linux49 4.9.183
  • linux414 4.14.129
  • linux419 4.19.54
  • linux51 5.1.13
  • linux52 5.2-rc5 (few extramodules build, but not all yet!)
  • linux419-rt 4.19.50_rt22
  • linux50-rt 5.0.14_rt9

Package Updates (Sat Jun 22 09:55:58 CEST 2019)

A detailed list can be found here.

  • No issue, everything went smoothly
  • Yes there was an issue. I was able to resolve it myself.(Please post your solution)
  • Yes i am currently experiencing an issue due to the update. (Please post about it)

0 voters

Check if your mirror has already synced:


can you add this or add the patch ?


Seems like Manjaro's 5.1.13 is built with that patch applied:

I have an issue with smb.service on 5.1.13, but not on 5.2-rc5:

● smb.service - Samba SMB Daemon
   Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor preset: disabled)
   Active: failed (Result: timeout) since Sun 2019-06-23 00:30:03 +10; 3min 32s ago
     Docs: man:smbd(8)
  Process: 1688 ExecStart=/usr/bin/smbd --foreground --no-process-group $SMBDOPTIONS (code=killed, signal=TERM)
 Main PID: 1688 (code=killed, signal=TERM)

Jun 23 00:28:33 reiwa systemd[1]: Starting Samba SMB Daemon...
Jun 23 00:29:33 reiwa smbd[1688]: [2019/06/23 00:29:33.606973,  0] ../../lib/util/become_daemon.c:135(daemon_ready)
Jun 23 00:29:33 reiwa smbd[1688]:   daemon_ready: daemon 'smbd' finished starting up and ready to serve connections
Jun 23 00:30:03 reiwa systemd[1]: smb.service: Start operation timed out. Terminating.
Jun 23 00:30:03 reiwa systemd[1]: smb.service: Main process exited, code=killed, status=15/TERM
Jun 23 00:30:03 reiwa systemd[1]: smb.service: Failed with result 'timeout'.
Jun 23 00:30:03 reiwa systemd[1]: Failed to start Samba SMB Daemon.

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?


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:
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?


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


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.


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.



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!

Forum kindly sponsored by