Best/proper way to configure TW like KDE neon dev unstable?

Hi SUSEians!

I’m attempting the transition from a KDE Neon Dev Git-Unstable installation to this here Tumbleweed setup. I’m a new and (very) minor KDE contributor, so I’m kinda hooked on those nightly builds of the KDE & Plasma framework libraries. It saves me the headache of keeping current on them manually.

I’m trying to recreate the Neon experience using the OpenBuildService daily builds instead. I think I’m getting there, but it still seems I’ve gotten things only partially right.

I added all 4 of the “unstable” repos immediately after installation:

I set the priority for all of these to “95”, and left the default repos at 99. My understanding is that the 95-ranked repos will take priority over the 99’s.

How do I go about setting these up for regular (at least daily) checking for updates? Plasma’s Discover app is terribly confused - it doesn’t seem to install anything, even apps I manually search for. The “Updates Available” widget kicked on and offered me a bunch of updates, but one of it’s planned tasks was to uninstall “plasma-desktop”. Since there wasn’t an update to plasma-desktop in the pipeline, I canceled that before it nuked my system.

Any suggestions on how I can get this running smoothly? I did a bunch of framework updates this morning, by hand. I filtered YaST by repository and worked through the “Unstable Frameworks” repo, picking each library one by one and telling it to change vendors and install the update. I did the same with all the relevant others. But I’d like this to be more automated, if possible.


Don’t mess with the priorities, it won’t have the result you want. What you need is a vendor change to the repos you want the KDE packages from ( and the corresponding repos for Qt and KDE Frameworks and KDE Applications. Works like this;

zypper dup --from 'REPO_NAME_HERE' --allow-vendor-change

I do understand this. But how is he supposed to do a TW update in the future? The recommended

zypper dup

will include the --allow-vendor-change on TW and thus might switch back a lot of what he has from those other repos. And not allowing vendor change will not bring him a stable new TW I assume (or am I wrong here?).

Ah. Okay. I’ll un-fix my fix.

That’s what I get for thinking I know what I’m doing.

In the end, though, All Hail the mighty Open Build Service!

Uh oh.

*takes finger off the ‘sudo’ button

We appear to have a split decision.

I’ll wait for a final answer before re-un-changing anything. :slight_smile:

Nope. On Tw zypper defaults to --no-allow-vendor-change, the opposite is needed to achieve the vendor change. From that moment on ‘zypper dup’ will do the job. But, admitted: it is a bit odd. Tw simply is created to pick everything from it’s stock repos. If one does not perform the vendor-change a mix of packages from Tw and the added repo is likely to take place and well, we know what the results can be. In the olden days I would have suggested the OP to run Factory.
@OP: be aware that what you’re trying to do may seriously break things.

Sorry, my misinterpretation. Got confused by the no-allow-change, same as allow no-change and more permutations :frowning:

:D. That’s why I said ‘a bit odd’. In Leap zypper defaults to --allow-vendor-change, in Tw the opposite. Well, one thing has improved in the last year: when attempting to run ‘zypper up’ on Tw, zypper states that dup should be used.

Yeah. Um. It’s a hazard. I already tripped over it using Neon Dev Unstable (submitted a patch using a pre-release version of a library).

It’s a tricky thing, and a real PITA. I’m a self-taught hacker, used to coding in simpler things like Python and web services. Never before worked on a desktop environment, not to mention the one I’m also trying to run as a normal user.

One of the senior KDE devs is working on getting all the development libraries installed in a Docker container, so you could easily switch environments without risking your system stability - or having to monkey around with a bunch of environment variables and session settings. Until then, though…

I think I’ll err on the side of caution and skip this whole “automated” part. If I need to install updated libraries, I’ll add them as I go, rather than trying to blast-update my whole system.

Things in KDE-dev-land will settle down for a while real soon - today’s the freeze for the next release of all the applications (coming in April). It’ll be bugfixes only for a few weeks, giving me time to get my system set up correctly. And safely.

Thanks again.

(I have to keep posting here. I like the little trivia questions at the top of each post.)

JFYI, there are also the openSUSE Argon and Krypton LiveCD’s that are based on the latest Leap (Argon) or Tumbleweed with the latest unstable KDE packages on top:

You can boot them directly (and if you wrote them to a writable USB stick you could also update them), and they are also installable which will give you a Leap or TW system with the additional repos preconfigured (and no need to switch to them first).


Sounds like Krypton may be what I’m looking for. It sounds an awful lot like what I was trying to accomplish myself, but with the kinks worked out by Smarter People™.

I’ll burn it to a stick and look it over.

Thanks for the suggestion!

I do like the kde neon approach - a default install just installs the minimum apps (no email family, no libreoffice etc.) I find it easier to add the additional packages required rather than to remove packages. That said, in these days of massive storage why bother.

Neon is nice and lean, but it’s based on Ubuntu 16.04, and is dated in a few ways. For example, the KDE Jenkins system runs GCC 7.3, but there’s no GCC-7 package for 16.04. You can get it from someone’s personal repository (backported from 17.10), but it’s not ideal. I’d like the official KDE developer release to be pre-loaded with the current-gen compiler that matches the CI system.

I’m working on getting Krypton set up now. I hope it’s a good compromise.