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

Oh yea of little faith... :stuck_out_tongue:

Give me a moment to upload.

I will provide a new ISO based on unstable branch shortly - this weekend the latest.

3 Likes

eep. 5.1 is EOL ...
hm .. my media keys dont work in 5.2+ ...
hmmm :thinking:

EDIT - scratch that. they didnt last time. they do now. yippee. :partying_face:

I am currently uploading an unstable ISO (miminal) build with latest packages included.
Files will be available here as soon as upload is finished.

3 Likes

Sorry to say, there's conflicts again with linux419-ndiswrapper 1.62-3:

:: Retrieving packages...
 linux419-4.19.63-1-x86_64                                    75.7 MiB   245K/s 05:17 [#################################################] 100%
 linux419-ndiswrapper-1.62-3-x86_64                          182.2 KiB  99.4K/s 00:02 [#################################################] 100%
(2/2) checking keys in keyring                                                        [#################################################] 100%
(2/2) checking package integrity                                                      [#################################################] 100%
(2/2) loading package files                                                           [#################################################] 100%
(2/2) checking for file conflicts                                                     [#################################################] 100%
error: failed to commit transaction (conflicting files)
linux419-ndiswrapper: /usr/bin/loadndisdriver exists in filesystem (owned by ndiswrapper-utils)
linux419-ndiswrapper: /usr/bin/ndiswrapper exists in filesystem (owned by ndiswrapper-utils)
linux419-ndiswrapper: /usr/bin/ndiswrapper-buginfo exists in filesystem (owned by ndiswrapper-utils)
linux419-ndiswrapper: /usr/share/man/man8/loadndisdriver.8.gz exists in filesystem (owned by ndiswrapper-utils)
linux419-ndiswrapper: /usr/share/man/man8/ndiswrapper.8.gz exists in filesystem (owned by ndiswrapper-utils)
Errors occurred, no packages were upgraded.

What changed in the PKGBUILD which is leading to conflicts now?

Edit: Ah, there was a split of the extramodule package and ndiswrapper-utils

Edit 2: I'm working on a fix, PKGBUILD changes are uploaded for the split packages, uploads coming "soon".

Edit 3:

extra/x86_64/linux316-ndiswrapper-1.62-3-x86_64.pkg.tar.xz
extra/x86_64/linux414-ndiswrapper-1.62-3-x86_64.pkg.tar.xz
extra/x86_64/linux419-ndiswrapper-1.62-4-x86_64.pkg.tar.xz
extra/x86_64/linux44-ndiswrapper-1.62-3-x86_64.pkg.tar.xz
extra/x86_64/linux49-ndiswrapper-1.62-3-x86_64.pkg.tar.xz

Other module packages haven't been split (yet?).

1 Like

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://archived.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

Forum kindly sponsored by