[Unstable Update] 2019-07-30 - Deepin 5.0, Gimp-Help, Haskell

This was murphy's law :wink:

I've make new build but don't upload the new PKGBUILDs to GitLab yet.
Oberon make the new kernel build for 4.19 with extramoduls.

So :poop: happens :innocent:

As more people work on packages I think we need to stick more rigidly to a workflow (e.g. https://forum.manjaro.org/t/package-update-workflow/88927) and possibly also ping people so they know who is working on what so we don't collide (e.g. two people trying to build and upload the same package). That could be as simple as a note on Telegram ("I'm working on package X... OK package X is uploaded and on GitHub").

Ok!
:slightly_smiling_face:

Just FYI now that I'm back "in the loop" I've updated nim to 0.20.2 and added foliate as it's very awesome.

3 Likes

I got some additional info while installing today's java openjdk, not sure about it...but doesn't look alarming:

(2/8) installing jre11-openjdk-headless [######################] 100%
Default Java environment is already set to 'java-8-openjdk'
See 'archlinux-java help' to change it

(3/8) installing jre11-openjdk [######################] 100%
Default Java environment is already set to 'java-8-openjdk'
See 'archlinux-java help' to change it
when you use a non-reparenting window manager,
set _JAVA_AWT_WM_NONREPARENTING=1 in /etc/profile.d/jre.sh

...btw I also have java-openjfx installed as well.

1 Like

Looks like a libxnvctrl update breaks my conky from starting up:

conky: error while loading shared libraries: libXNVCtrl.so.0: cannot open shared object file: No such file or directory

I'm using conky-lua-nv. Looks like a dropped library and there's already an arch bug on it. For some reason, my conky config doesn't like a modular install: conky + lua51 + tolua++...there's no other dependencies but conky still complains that module cairo is missing, even though it's installed and I also tried reinstalling it. For some reason, conky-lua-nv only works for me, even though I don't use any of the nvidia extensions. @oberon, I requested a rebuild of this package due to a conky version bump...can you possibly look into this again?

Ah yes, seems I missed you comment back then. Will look into it, thanks!

Just pushed conky-luy-nv 1.11.3 to unstable branch. Please test, thank you.

2 Likes

Cool, it's working again without any modification. :+1:

1 Like

I've updated ZFS modules for kernels 4.14, 4.19, 5.1, and 5.2 which adds an upstream patch for SIMD support.

This should help improve performance, especially for encrypted pools.

When upgrading one of my KDE-Dev unstable laptops, I saw a notice that Linux 5.1 was EOL, so I used MSM to install the latest experimental kernel. However, I thought after a re-boot, the experimental kernel would be used by default, but it was not (confirmed by kinfocenter and MSM). Is this normal?

Manjaro always uses the latest installed kernel by default. This is due to the concept of grub. Also new ISOs are now online: KDE-Dev, KDE-Vanilla.

Thank you, in that case, is it possible that in Unstable, when using MSM to install the latest experimental kernel, the /boot/vmlinuz ... was not included along with it.

Since, after a re-boot, I could see it was installed but 5.1 was still running, I made the mistake of using MSM to remove the 5.1 kernel, and after trying to re-boot again, I could not boot, and got a message starting with error: file 'boot/vmlinuz

Edit to add: So, I had to boot my other KDE unstable Manjaro installation on sda, and sudo update-grub from there before my KDE-Dev unstable Manjaro installation would boot with 5.3.0-1-MANJARO

kinfocenter

Operating System: Manjaro Linux
KDE Plasma Version: 5.16.80
KDE Frameworks Version: 5.61.0
Qt Version: 5.13.0
Kernel Version: 5.3.0-1-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Core™ i7 CPU M 620 @ 2.67GHz
Memory: 3.6 GiB of RAM

This is related to another update to libxnvctrl?:

ldconfig: /usr/lib/libXNVCtrl.so.0 is not a symbolic link

@philm, did you forget to update the latest nvidia driver?

Replace lib32-nvidia-utils with multilib/lib32-nvidia-430xx-utils? [Y/n]
Replace mhwd-nvidia with core/mhwd-nvidia-430xx? [Y/n]
Replace nvidia-utils with extra/nvidia-430xx-utils? [Y/n]

error: failed to prepare transaction (could not satisfy dependencies)
:: removing nvidia-utils breaks dependency 'nvidia-utils=2:430.40' required by linux419-nvidia
:: removing nvidia-utils breaks dependency 'nvidia-utils=2:430.40' required by linux52-nvidia

1 Like
Graphics:  Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] vendor: ZOTAC driver: nvidia v: 430.40 bus ID: 01:00.0 
           chip ID: 10de:1c03 
           Display: x11 server: X.Org 1.20.5 driver: nvidia compositor: compton resolution: 3840x2160~60Hz 
           OpenGL: renderer: GeForce GTX 1060 6GB/PCIe/SSE2 v: 4.6.0 NVIDIA 430.40 direct render: Yes

no

System:    Kernel: 5.2.9-2-MANJARO x86_64 bits: 64 compiler: gcc v: 9.1.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-5.2-x86_64 root=UUID=9030b9ef-9aab-4578-92c7-b085e2b31cbb rw 
           Desktop: i3 4.17 info: i3bar dm: LightDM 1.30.0 Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: ASUSTeK model: P8Z77-V DELUXE v: Rev 1.xx serial: <filter> BIOS: American Megatrends v: 2104 

I'm confused. So the replacement nvidia-430xx-utils breaks the dependency required by linux52-nvidia?

I am grateful to all these perturbations for going ahead and installing nvidia-beta-dkms. Switched to bbswitch-dkms too and won't be irritated by manual rebuilding of modules I need.

@philm
The Bubblewrap issue is back on Kernel 4.19.67-1

bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces.

Kernel 5.2.9-2 is not affected!

To reproduce run any Flatpak on Kernel 4.19.67-1

OK, will try to fix it with 4.19.68-1

1 Like

Forum kindly sponsored by Bytemark