What's up with clearly unstable software being marked as stable?

[cmpxchg8b]

Is there some reason why clearly unstable software is being marked as stable in Portage these days?

Over the past few days I've noticed my system pulling in a few packages that I don't think should be marked as stable:

- media-video/vlc-4.0.0_pre20260418

This one in particular seems pretty broken UI wise- just opening up a video in it by double-clicking on a *.mp4 file (or any kind of video really) is guaranteed to break the UI and I have to resize the window just to get it to sorta paint properly. I don't believe VLC 4.0 has been released yet so why is this marked as stable?

- media-gfx/krita-6.0.2_pre20260509

Another "pre" package which clearly isn't ready for the prime time. This one seems to have issues with canvas stability and performance (both of which I've filed bug reports for upstream), but worse the builds for 6.0.1 seem to have already been removed. As far as I know, 6.0.1 was also not marked as a "pre-alpha" (just alpha) yet 6.0.2 is (since it doesn't yet have an official versioned release).

I can only assume this has something to do with pushing qt6 adoption, but... jesus. This software clearly isn't ready for prime time (which upstream makes very clear in either case), yet it's being pushed out to Gentoo boxes as "stable".

What gives?

Is this just going to become a thing from now on with any software that doesn't have a native already-released qt6 version?

-cmpxchg8b

[Spanik]

Ah, so I'm not the only one having issues with VLC 4.0.0_pre. Have been searching the forum and net today for clues what might be wrong. I even see segfaults in the syslog from VLC.

[asturm]

Re vlc-4 stable: No bugs were filed against it during its testing time in ~arch after initial positive reports. The only other alternative was effective destabilisation of the vlc[gui] by dropping USE gui from vlc-3 and only providing it with ~arch vlc-4.

If you're having trouble with vlc-4, please try again with a wiped clean vlc config.

---

- media-gfx/krita-6.0.2_pre20260509

[...] This one seems to have issues with canvas stability and performance (both of which I've filed bug reports for upstream)

Thanks for doing that.

media-gfx/krita-6.0.2_pre20260509 is a definitive improvement (bugfixes only) over 6.0.1, albeit not perfect yet, but then you were talking about "marked stable" software and krita is not that. I made the decision to destabilise it after upstream made a 6.0.0 release "for Linux" that they could not commit to declare as stable themselves. I did not see the point in packaging 5.x anymore when they regard distribution packages that do not rely on their own forked and patched bundled Qt5 as second class citizens anyway, with 5.3 coming with its own fair share of regressions (such as in performance). If you rely on it for your professional day-to-day work, use their upstream provided Appstream or Flatpak instead, a mask message informed you about the plans for well over a month ...

---

Is this just going to become a thing from now on with any software that doesn't have a native already-released qt6 version?

No, since Qt5 is close to removal, there is nothing else left still depending on it.

[Spanik]

Re vlc-4 stable: No bugs were filed against it during its testing time in ~arch after initial positive reports. The only other alternative was destabilisation of the package, while dropping USE gui from vlc-3 (so effectively destabilising vlc[gui]).

If you're having trouble with vlc-4, please try again with a wiped clean vlc config.

Happy to try this. What config exactly do you want wiped? I do not have any package.use of package.mask concerning vlc. Wiped /home/.config/vlc. Anything else?

[asturm]

Wiped /home/.config/vlc. Anything else?

That should be it, it helped with the only negative report in the original stable bug.

[Spanik]

Wiped /home/.config/vlc. Anything else?

That should be it, it helped with the only negative report in the original stable bug.

It has been rebuild. I'll restart the pc and if it continues like what I have now I'll start another thread.

[cmpxchg8b]

If you're having trouble with vlc-4, please try again with a wiped clean vlc config.

Tried this, unfortunately it still seems pretty broken. It's mostly fine if I manually open up VLC first *then* open a video, but launching anything through Dolphin or Plasma just results in a screen missing all of the control widgets (I'm running it in "classic" mode since I'm not a fan of the modern layout). I have to change the window size (which is pretty glitchy while dragging the resizer) to get it to partially paint the widgets, but even then they still don't show up properly.

I've also noticed that playback of 4K content is pretty laggy as well (framerate < 10fps on 30fps content). Not sure what's up with that, I'm sorta wondering if it's related to the widget painting issue though since it seems like it will sometimes go away if I resize the window enough (might have something to do with the weird background blur effect on some widgets that I keep seeing phasing in and out?).

but then you were talking about "marked stable" software and krita is not that

I'd just meant it being marked as amd64 and not ~amd64 within the gentoo repo.

Both 6.0.0 and 6.0.1 seemed reasonably stable to me (despite still clearly being "alpha" versions due to qt6 support not being fully hashed out yet). It kinda caught me off guard to see 6.0.1 get removed and replaced with 6.0.2 so quickly with no easy way to mask off 6.0.2 via package.mask unless you've got a copy of the old 6.0.1 ebuild lying around somewhere. I'm fine with 5.x not being packaged anymore, I've been using 6.x for quite a while now- sometimes it's just nice to have one or two versions going back in Portage so you can easily revert in case things don't work out right away (especially in regards to an alpha release like Krita 6.x).

I've landed up masking off VLC 4.x for now (which I'm guessing is a very temporary solution considering anything qt5 related is on the chopping block) and reverted to Krita 6.0.1. Hopefully both will get fixed sooner rather than later.

I guess I might have been a bit brash with my message and I apologize for that. I was just surprised to see those packages being marked as amd64/stable via their ebuilds when neither have an official stable release from upstream.

-CMPX

[asturm]

If you're having trouble with vlc-4, please try again with a wiped clean vlc config.

Tried this, unfortunately it still seems pretty broken. It's mostly fine if I manually open up VLC first *then* open a video, but launching anything through Dolphin or Plasma just results in a screen missing all of the control widgets (I'm running it in "classic" mode since I'm not a fan of the modern layout). I have to change the window size (which is pretty glitchy while dragging the resizer) to get it to partially paint the widgets, but even then they still don't show up properly.

I can't observe any of these issues, neither modern layout nor classic one. And while I'm struggling to reach for some 4K content right now, neither is it glitchy or laggy when resizing on my 5K screen (including 150% scaling, which has often revealed porting issues in the past) at least. I can attest to the fact that VLC refuses to integrate well with the environment it is started in. But already VLC-3 didn't do that either and was particularly bad in HiDPI setups (let alone Wayland).

I'm not saying you don't have these issues, but maybe they are specific to some condition on your system. Could you try again with media-video/vlc-4.0.0_pre20260515? And could you also try with other Qt6-based video player software like media-video/haruna?

but then you were talking about "marked stable" software and krita is not that

I'd just meant it being marked as amd64 and not ~amd64 within the gentoo repo.

But that's what I meant: There currently is no "amd64" marked version of krita in the gentoo repo, that got dropped with 5.2.x.

Both 6.0.0 and 6.0.1 seemed reasonably stable to me (despite still clearly being "alpha" versions due to qt6 support not being fully hashed out yet). It kinda caught me off guard to see 6.0.1 get removed and replaced with 6.0.2 so quickly with no easy way to mask off 6.0.2 via package.mask unless you've got a copy of the old 6.0.1 ebuild lying around somewhere.

Is there a specific regression you can cite between 6.0.1 and the current snapshot, or is it just the feeling for the latter carrying "_pre<something>" in the name? Because if that's your bug, you make no mention of that, which would be vital information for upstream to fix a regression in a branch that should only contain bug fixes since 6.0.1.

[cmpxchg8b]

I'm not saying you don't have these issues, but maybe they are specific to some condition on your system. Can you try with other Qt6-based video player software like media-video/haruna?

Interesting.

I'm not running a particularly esoteric setup, everything's pretty much a bog standard up-to-date KDE based system with Wayland only (and Xwayland, of course). I do have a secondary Cintiq monitor setup but it's powered down half the time and the UI redraw issues occur on either that or my main screen. About the only thing that's not up to date is my kernel (I'm currently hanging back on 6.12.x/SLTS due to AMD 7900 XTX stability issues with 6.18+).

I guess further debugging is in order. I'll try to create a fresh user account tomorrow and see if it's caused by something in .config/.local/.share.

But that's what I meant: There currently is no "amd64" marked version of krita in the gentoo repo.

Oh wow, I'm an idiot.

I completely forgot I had media-gfx/krita ~amd64 in /etc/portage/package.accept_keywords/*. I guess I must have put that in there when I switched to a pure Wayland setup without x11-base/xorg-server. Derp. Sorry for the confusion, you're correct.

Because if that's your bug...

It is, and I've updated it accordingly. Thanks for pointing that out.

-CMPX

[GoofyX]

Yeah. Same here. Version 4.0.0-pre (all versions tested) is pretty useless. I've opened a bug for this: https://bugs.gentoo.org/975514

I even deleted the config dir, nothing changed.

Garbage.

[GoofyX]

Installed Haruna. It works great. Until the VLC devs fix this useless version.

[sam_]

What gives?

Is this just going to become a thing from now on with any software that doesn't have a native already-released qt6 version?

-cmpxchg8b

The alternative would be them being removed. Qt 5 has been EOL for years for FOSS purposes: Qt upstream maintain backports but only privately for paying customers, and I think even that is on its way out. Our KDE maintainers have been manually cherry-picking fixes from Qt 6 for a long time and are tired of doing it (which gets harder as time goes on), plus KDE software doesn't need it anymore (with the exception of Krita). Who is going to do the work? Qt 5 doesn't keep working by itself, it needs patches to work with newer libraries, and also fix security bugs.

I really don't love the situation ever, and I'm a vocal advocate of not doing this 99.999% of the time, but I don't think we had many other options here.

FWIW, I can highly recommend Haruna.

[rab0171610]

I realize that not everyone's experience is the same. Just because I am not having problems, doesn't mean that others are not. When I first loaded up the new VLC, I thought something was wrong with the interface. It was rather jarring IMO. Comparing it to a pic online of the classic VLC interface when playing a video, I realized all of the buttons were in the same order and location they always were. Something still felt off. A couple of options made it better for me. One was, as mentioned, switching to Classic View. The others were Forcing the Window Style to Oxygen, the Color Scheme to Night, and enabling Show the Menubar. Yes, I am one of those old people that likes to see a traditional menubar visible in every application.
The setting that made the most improvement for me was in Show Settings -> All -> Interface -> Main interfaces -> QT -> Pin Video controls. Pin Video -- Pins video controls "above and below" the video instead of above. I am not sure this is an accurate description but it did move the video controls out of the video frame as an overlay and into the dedicated bar below the video as it was before. The difference was very subtle but I personally do not like using player control buttons (Play, pause, volume etc) when the video is showing through underneath. I also don't like things covering or obstructing the video. To me that's not efficient, it is messy.
Regardless, I do not have any issue when opening videos in Dolphin or playing videos when clicking on a file. Maybe I am just lucky.
I did, as an experiment, change the Interface backend to QT. It defaults to auto but I am rather sure it uses QT anyway. VLC would not open a video and there were segfaults in the terminal output.
I deleted my VLC configuration, restored a backup and it opened files normally again. So I will say that there is a possibility for some, depending on their settings, to have issues with older configuration files. I would definitely recommend removing the configuration files as a first step when troubleshooting issues after updating to the newer VLC.
Maybe I just got lucky.

[Goverp]

I was using VLC to view an old B&W DVD, and it wouldn't work until I switched off VAAPI hardware acceleration. As this was on my desktop machine, I wasn't too bothered, but I'd be annoyed if it were my laptop.
As to its user interface, it's always been horrible. At least they now hide more of it!

[asturm]

@cmpxchg8b please let me know if media-gfx/krita-6.0.2_pre20260521 fixes your problem.

Otherwise, since you're describing performance issues with both VLC and krita, and we haven't heard anything else about trouble with the latter, maybe there was some other update on your system that is causing general performance issues.

[cmpxchg8b]

@cmpxchg8b please let me know if media-gfx/krita-6.0.2_pre20260521 fixes your problem.

Unfortunately it hasn't.

I'm kinda tempted to just rebuild this system from stage3 at this point, though I'm not really using anything esoteric over here. I'm on 6.12.90-r3 with a couple of things (mainly Krita, Blender, liquidctl, Okteta, AMD's HIP stuff, etc) on ~amd64 but that's it. Everything else (including KDE) is on stable. I've got a few backported patches in /etc/portage/patches to fix various bugs in various things (namely virt-viewer and KIO), but nothing that even remotely goes near Wayland or Mesa.

I should probably figure out how to toss a debugger or something on Krita and see what it's doing, because it's entirely consistent and reproducible behavior. It happens every startup without fail, and it seems to go away exactly X seconds after opening a new canvas too. I figured maybe it was related to the memory usage of the canvas (and/or some sort of garbage collection) but it doesn't seem to be. It's like some sort of a timer expires in the background, and then suddenly the canvas just... starts working as expected.

Though, frankly, the fact VLC 4.0 is also giving me troubles with GUI painting/redrawing is starting to make me think that maybe something else is busted with QT6 or my GPU stack somehow. I landed up switching to Haruna for that though, which so far seems to be good enough for what I need.

-CMPX

[asturm]

I've temporarily restored krita-6.0.1 for you to test your theory. Should 6.0.1 now behave the same, then the bug was introduced somewhere else.

Rebuilding from stage3 rarely fixes such bugs.

[cmpxchg8b]

I've temporarily restored krita-6.0.1 for you to test your theory. Should 6.0.1 now behave the same, then the bug was introduced somewhere else.

Yup, 6.0.1 works fine. No weird lag or anything, the canvas is totally smooth from the get-go.

Rebuilding from stage3 rarely fixes such bugs.

I was mostly just wondering about this because I'd changed my CFLAGS a while back, but I'd rebuilt the entire system with --emptytree afterwards. This doesn't seem to have made a difference though since I did a quick stage3 install yesterday using the old CFLAGS and the issue with Krita >=6.0.2 was still present. I also went through most of my USE flags looking for anything that might influence this behavior, but I can't find anything GPU related that would really make a difference.

-CMPX

[asturm]

Since krita-6.0.2 was released several days ago, has the situation changed?

You could then directly compare the Gentoo package with upstream's appstream at both 6.0.2 in case there is any difference in behavior, and report back in the upstream bug.

[cmpxchg8b]

Nope.

I did manage to bisect the issue to a specific commit that has something to do with font handling though (and have updated the bug report accordingly). It seems like the font selector was broken in 6.0.1 and below which subsequently got fixed, but this has created the unintended side effect of causing high CPU usage when Krita initially loads, presumably as it attempts to process the system fonts and do something with them. This is what is causing the laggy canvas- it's Krita pegging a whole core (possibly on the UI thread?) until it finishes whatever it's doing and things settle down.

I figured maybe this was being caused by noto or noto-cjk (as they're both notoriously large font sets), but removing either didn't seem to make any difference.

I'm going to try to figure out how to profile a debug build of Krita tomorrow and see if I can figure out where it's spending all the time after startup. I suppose it could be a bad font somewhere on my system, but since there's nothing in the Krita logs about this I don't really have much to go on.

-CMPX