OpenMandriva 4.1 Released With Clang'ed LTO+PGO Packages, Linux 5.5 + More

[Charlie68]

By the way, I very much welcome their user-facing improvements, like the Chromium build with VAAPI, changing to ZSTD compression and all of their performance work. I will test it out once the benchmarks show that it performs better or equal to other distros.

For information only, VAAPI is enabled in Chromium by default also in openSUSE Leap and Tumbleweed, it works very well on Wayland, while on Xorg I find some problems.
It is strange, however, to see Plasma 5.17. * And not Plasma 5.18.

[berolinux]

I've tried it again on a fresh install, but unfortunately I still get ['\n Problem: gdk-pixbuf2.0-2.40.0-1.i686 has inferior arichtecture\n - cannot install both gdk-pixbuf2.40.0-1.i686 and gdk-pixbuf2.0-2.40.0.-1.zenver1\n - package steam-1.0.0.61-9.zenver1 requires gdk-pixbuf2.0(x86-32), but none of the providers can be installed\n - conflictings requests].

And I do have i686 and non-free repos enabled. Update channel is: Rock.

I've tried the Steam flatpack, and it installs and opens correctly but complains about an invalid ssl certificate. But the important part seems to work.

We've isolated the problem and we have a workaround currently being tested in cooker (the development tree).

We've traced the problem to a seemingly unrelated change: Enabling support for encrypted partitions in util-linux. So how did that break steam?
Steam uses libmount (from util-linux) for unknown reasons [likely to get information about available space]. With encryption enabled, libmount links to libcryptsetup, which in turn linked to OpenSSL.
Steam comes with its own copy of OpenSSL that is apparently a few versions behind and not fully ABI compatible - so with the new util-linux, steam sees 2 sets of OpenSSL symbols and freaks out in a few different ways.
The proper fix is on steam's side (they're aware of the problem, but haven't released a fix yet). In the mean time, our workaorund is to use kernel encryption instead of OpenSSL in libcryptsetup. That makes sure libmount doesn't pull in OpenSSL so steam only sees its own OpenSSL again, and works.

We'd like to put OpenSSL back into libcryptsetup for performance reasons, and will likely do that once steam has been fixed.

But this is a very good example of why non-free stuff is simply not supportable.

[ms178]

I can't reproduce this...
$ rpm -qa |grep pixbuf
libgdk_pixbuf2.0_0-2.40.0-1.i686
lib64gdk_pixbuf2.0-devel-2.40.0-1.znver1
lib64gdk_pixbuf-gir2.0-2.40.0-1.znver1
lib64gdk_pixbuf2.0_0-2.40.0-1.znver1
lib64gdk_pixbuf_xlib2.0-devel-2.40.0-1.znver1
gdk-pixbuf2.0-2.40.0-1.znver1
lib64gdk_pixbuf_xlib2.0_0-2.40.0-1.znver1

You don't need any i686 versions beyond libgdk_pixbuf2.0_0 (which you should get automatically if you "dnf install steam" after enabling the i686 and non-free repos).

I've tried it again on a fresh install, but unfortunately I still get ['\n Problem: gdk-pixbuf2.0-2.40.0-1.i686 has inferior arichtecture\n - cannot install both gdk-pixbuf2.40.0-1.i686 and gdk-pixbuf2.0-2.40.0.-1.zenver1\n - package steam-1.0.0.61-9.zenver1 requires gdk-pixbuf2.0(x86-32), but none of the providers can be installed\n - conflictings requests].

And I do have i686 and non-free repos enabled. Update channel is: Rock.

I've tried the Steam flatpack, and it installs and opens correctly but complains about an invalid ssl certificate. But the important part seems to work.

[berolinux]

Thanks for the hint, and my bad - I didn't think about Flatpack as an alternative option. Concerning the repos, if I remember correctly I did exactly that (using Cooker for zenver1 and also enabling i686) but unfortunately there was a conflict between the i686 version of gdk-pixbuf with the zen variant of that package which could not live side-by-side.

I can't reproduce this...
$ rpm -qa |grep pixbuf
libgdk_pixbuf2.0_0-2.40.0-1.i686
lib64gdk_pixbuf2.0-devel-2.40.0-1.znver1
lib64gdk_pixbuf-gir2.0-2.40.0-1.znver1
lib64gdk_pixbuf2.0_0-2.40.0-1.znver1
lib64gdk_pixbuf_xlib2.0-devel-2.40.0-1.znver1
gdk-pixbuf2.0-2.40.0-1.znver1
lib64gdk_pixbuf_xlib2.0_0-2.40.0-1.znver1

You don't need any i686 versions beyond libgdk_pixbuf2.0_0 (which you should get automatically if you "dnf install steam" after enabling the i686 and non-free repos).

Also an older steam version (x.59) could be installed for the i686 variant, it just crashed after showing the login screen. [...]
I certainly hoped that issues like this get caught and fixed during testing

And it was caught during testing. We've had a look and decided the problem was caused by the latest steam update that's forced on you on steam startup. There seems to be an ABI difference between what we have and what they expect to find.
We found no indication of a bug on our side, we don't have the steam source to fix it, and we generally don't let a non-free application block our releases.
While of course we hope it will eventually work again (and if it turns out to be a problem on our side, we'll certainly push an update to the 4.1 tree), we've decided it's not a release blocker.

Another tip for the next release would be to push the ISOs to all of your mirrors first before launching the release,

We can't push to our mirrors -- they pull form us, and we have no influence on when that happens. We can usually wait, but the 4.1 release was a bit special: We wanted to have the release done in time for FOSDEM (where we didn't want to present vaporware).

But I'll keep an eye on openMandriva from now on, it certainly showed a lot of promise.

Thanks - let us know how it goes.

[ms178]

You can install Steam from Flatpak. Anyway to install steam from system repo, you need enable two repo, non-free and i686 (stream is 32bit app), then app libs should be installed.

Thanks for the hint, and my bad - I didn't think about Flatpack as an alternative option. Concerning the repos, if I remember correctly I did exactly that (using Cooker for zenver1 and also enabling i686) but unfortunately there was a conflict between the i686 version of gdk-pixbuf with the zen variant of that package which could not live side-by-side. If the latter was installed, you couldn't install steam. Also an older steam version (x.59) could be installed for the i686 variant, it just crashed after showing the login screen. I also tried to resolve this with dnf on the command line with the autoresolve option, but this conflict couldn't be solved.

I certainly hoped that issues like this get caught and fixed during testing, as desktop gaming usage is quite a thing on a performance/desktop oriented distro and encountering such an issue in a release build doesn't inspire a lot of confidence that the rest of the system is stable to use or well tested at all. Another tip for the next release would be to push the ISOs to all of your mirrors first before launching the release, I had trouble downloading the ISOs from your primary source and all of the mirrors weren't up to date yet [and wasn't keen to use bittorrent as an alternative for that matter].

But I'll keep an eye on openMandriva from now on, it certainly showed a lot of promise.

[xpris]

Unfortunately, I have noticed a different dealbreaker for me, somehow Steam (zen version) refused to install due to some unresolvable conflicts with gdk-pixbuf. Please fix it.

You can install Steam from Flatpak. Anyway to install steam from system repo, you need enable two repo, non-free and i686 (stream is 32bit app), then app libs should be installed.

[berolinux]

It's dead

Our hoster has been causing a few problems. Even while the website is down, you can download the isos from the download mirror at https://sourceforge.net/projects/ope...s/release/4.1/.

[ms178]

Further testing revealed that either my USB stick or the USB flash tool I used was the culprit, with a different stick and Etcher as flash tool, I got the GCC zenver1 ISO to install. Unfortunately, I have noticed a different dealbreaker for me, somehow Steam (zen version) refused to install due to some unresolvable conflicts with gdk-pixbuf. Please fix it.

The desktop experience was pretty good apart from that, I really like the performance and their dark theme. They still need a bit more testing plus a bit of polish of their default Plasma settings. I'd also like to grab their customized kernel sources from github to further customize it myself and build it with the kernel rpm-pkg build target, they currently don't offer any releases there that would let me do it the way I am used to, but I haven't explored other options too hard...

[ms178]

By the way, the Zen build with Clang just errors out early with a lot of "dracut-initque[442] timeouts" right after booting the live iso. Trying out the GCC build next, but this doesn't look promising so far. Update: The same problem exists with the GCC zenver1 build. I've got an NVMe SSD as my primary device, and some dmesg entries about bogus values from them. But nothing too serious, I've seen them on other distros, too.

[Etherman]

The chance is better from older > newer architecture of the same manufacturer, as they normally don't remove ISA extensions (except Bulldozer > Zen, FMA4 and other AMD-specific instructions were deprecated).

I got hit by that incompatibility when i upgraded from Amd Piledriver to Zen. Some AUR packages stopped working on my system because I had compiled them with "native".