Set course for 3.03 release

Also, people attending TC meeting exchanged their opinions about next major release based on cooker.
“3.1” or “4.0”?
Mostly agreed with 4.x. Reasons are discussed and explained in the meeting log - around 18:40:xx or such.
@TPG Your inputs on the topic will be welcome.

Yep, and also to go with 4.0, 4.1, 4.x and have no more like 3.0x, 4.0x. Basically this is all to avoid (we hope) naming confusion.

1 Like

4.x sounds better for release based on cooker :slight_smile:

1 Like

I’d like to see the netinstall feature of Calamares made available. I’m happy to help with this.
Colin

1 Like

Iirc there was a reason behind, the package numbering (distepoch or whatever is the name), but I can’t remember exactly which one.

It’s reasonable to call 4.x a release based on cooker to me too.

But imo a new major version should bring some big changes visible to the normal user or she/he will have no reason to upgrade a still working system (I think it’s the reason some people is still using 2014.x). So I suggest to wait for a new major release until the new om-control-center and yum will be rady for everyday use.

Also some users complained about the absence of a tool for migrating a system from version to the next one without re-install the whole system each time (and loosing configs, installed packaged, etc…). So it could be really useful to have a tool for this (I head about such a tool based on online upgrade in Mageia, but I’ve never tried it).

1 Like

True !

I meant dnf (and not yum), of course.

Hi,

i’ve started updating Kde Frameworks and Plasma to latest stable versions. It is not done yet.
Second i’ve pushed couple of updates related to system core packages.

Currently most of updates are waiting in main/testing repository.

I’m trying to build kernel-release 4.12.x with a zstd support. Unfortunately it does not build because some files are shared between subpackages. @bero can you help here ?

3 Likes
....
While some packages may have been installed, there were failures.
The following packages have to be removed for others to be upgraded:
lib64keffects10-5.9.5-1-omv2015.0.x86_64
(due to unsatisfied kwin == 5.9.5-1:2015.0,
due to missing libkwinxrenderutils.so.10()(64bit))
lib64kwinglutils10-5.9.5-1-omv2015.0.x86_64
(due to unsatisfied kwin == 5.9.5-1:2015.0)
lib64kwinxrenderutils10-5.9.5-1-omv2015.0.x86_64
(due to unsatisfied kwin == 5.9.5-1:2015.0)
urpmi --test lib64keffects10
The following package cannot be installed because it depends on packages
that are older than the installed ones:
lib64keffects10-5.9.5-1
Continue installation anyway? (Y/n) n
$ rpm -qa|grep kwin-
kwin-5.10.4-1-omv2015.0.x86_64
kwin-x11-5.10.4-1-omv2015.0.x86_64
kwin-wayland-5.10.4-1-omv2015.0.x86_64

I have seen this happen before, and it is most confusing to users. I think that for some reason, upstream changed the name of a couple of packages - in this case lib64kwinglutils and lib64kwinxrenderutils. It is safe for lib64kwinglutils10 and lib64kwinxrenderutils10 to be removed since they are replaced by lib64kwinglutils11 and lib64kwinxrenderutils11.

The same thing happened with lib64effects.

Regards,

Chris

1 Like

I’ll try to fix it. Anyways update is done. Tomorrow a 3.03 Iso should be available for testing :+1:

2 Likes

In facts may be a false warning as the *10 packages actually got removed and the *11 installed

$ rpm -qa|grep lib64keffects1
lib64keffects11-5.10.4-1-omv2015.0.x86_64

$ rpm -qa|grep lib64kwinglutils1
lib64kwinglutils11-5.10.4-1-omv2015.0.x86_64

$ rpm -qa|grep lib64kwinxrenderutils1
lib64kwinxrenderutils11-5.10.4-1-omv2015.0.x86_64

I can confirm dbus and systemd working here on 2 computers. With no problems noted.

Same here.

Not ignoring the Plasma (5.10.4) or Kframeworks (5.36.0) packages. They are installed, just takes longer to test these for me. So far no problems noted with them.

I’ve tested most of the core packages TPG mentioned votes on these to kahinah please. Let’s get them into the main update repo asap.
Best,
Colin

1 Like

There seem to be some things missing in the KDE packages. In this screen shot we can see on the left missing category icons in Application Launcher (Kickoff) and on the right it complains of missing “wallpaper.knsrc”. ‘KNewStuff’ complains of a missing ‘.knsrc’ file. Granted these aren’t big issues but we might want to get corrected before putting in stable repos right?

Edit: KNewStuff missing .knsrc files. Bug report here.

Edit2: Some missing icons after update to FF 5.36.0/Plasma 5.10.4. Bug report here.

Darn, I forgot to include the screen shot in above post…

again missing icons on right and missing ‘KNewStuff’ ‘.knsrc’ file on right.

Edit: Created seperate thread for Knewstuff here.

Confirming.