I am ready to support this stack of packages. Are there any comments or comments on this package build?

In T10486#200864, @stalebrim wrote:

Target Giara for 5.0 when Serpent tooling support is available, since it supports repos and not just tarballs

Solbuild also supports syncing with Git if that's what you're after.

source     :
    - git|<URL>.git : <commit-hash>

So, to be clear, have you also activated the additional options mentioned here: https://github.com/elFarto/nvidia-vaapi-driver#firefox ?

I' still seeing an error in console when I launch Firefox in a Wayland session
nVidia GPU

This might be it: https://github.com/systemd/systemd/issues/24960

It could also be due to systemd-xdg-autostart-generator not loading from the path anymore as part of the systemd update.

This the kde autostart paths

AutostartModel::AutostartModel(QObject *parent)
    : QAbstractListModel(parent)
    , m_xdgConfigPath(QStandardPaths::writableLocation(QStandardPaths::GenericConfigLocation))
    , m_xdgAutoStartPath(m_xdgConfigPath.filePath(QStringLiteral("autostart")))

Closed as invalid as it's an upstream issue, specific to private windows.

Oh. I understand.

Okay, can confirm that this systemd patch fixes the second part of the issue with X-GNOME-Autostart-Phase=
(both for spice-vdagent and solus-update-checker)

• Plasma no longer seems to load .desktop files from /usr/share/xdg/autostart/
• The X-GNOME-Autostart-Phase=WindowManager line in the .desktop file seems to prevent it launching under Plasma altogether

I would honestly just copy the edited spice-vdagent.desktop file to ~/.config/autostart/ directory in the VM as a workaround, until proper stateless support is restored for reading from /usr/share/xdg/autostart in whatever part of KDE is responsible for this?

If I understand your issue correctly then that is expected behaviour, but can be disable with a config option, see here: https://support.mozilla.org/bm/questions/1339296

Okay, so after some investigation this is a combination of two things

[slowly dumping stuff from my phone]
According to a comment in the Endeavour forums this might be related to a gnome-session condition in /usr/share/xdg/autostart/spice-vdagent.desktop

I may have found something useful. Of course, spice-vdagent is installed on both host and guest. (It had to have been, this worked before).

please disregard, thanks

As you can see on the project's website there is no newer version available: https://sourceforge.net/projects/pwgen/files/

... since you're already working on it!

VRR has worked fine for me for quite a while now.

@ermo Yes, this is still an issue

Closing per reporter's request.

Is this still an issue for you?

@aleksvor Many thanks from several users.

@bmivzkrp After the next sync there will be a new option in Audacious to switch to GTK interface. Launch Audacious, then navigate to File -> Settings, and there will be a new button "Switch to GTK (legacy) mode". Press it, and after a restart Audacious will use GTK3 instead of Qt5.

In T9922#200947, @TClark77 wrote:

FWIW there is nothing currently in the Akonadi docs saying you shouldn't use sqlite. It was there in the past. https://techbase.kde.org/KDE_PIM/Akonadi#Why_not_use_sqlite.3F
Here is where they removed it: https://techbase.kde.org/index.php?title=KDE_PIM/Akonadi&curid=6207&diff=106967&oldid=106854

Thank you very much @algent for the very fast fix. I am happily confirming, that digikam is starting up again.

@knilch This will be available at next sync. I you need it now you can install with this command:
sudo eopkg it https://packages.getsol.us/unstable/d/digikam/digikam-8.0.0-39-1-x86_64.eopkg

I get the same error immediately after installing digikam on unstable

@aleksvor Thanks

Audacious now supports GTK3, so I can look into enabling it. Maybe we can even support both Qt5 and GTK3 to have the best from both worlds.

I have a feeling this can be closed, seeing as there's likely not enough information to reproduce the issue, we're probably not going to get more info since it's a year old, and whatever it is may have been solved by an update since then.

Hmm, there's some weird versioning in the tags on jitsi. The building document didn't even exist at 5633, and the only two versions tagged past that are in a different format r2.14.695 and r2.14.721, these two versions do have the build doc claiming it can use jdk11. Definitely looks like a project on the tail end of it's lifecycle though as stated previously, in the ReadMe it states:

Jitsi Desktop is the heritage of Jitsi Meet. While some components are still used in e.g. Jigasi, the project is not actively developed anymore. Improvements, bugfixes and builds are entirely based on community contributions.

Looks like the icedtea-web in the repository is now up to jdk17 and if we update to the newest version of jitsi (https://github.com/jitsi/jitsi/blob/master/docs/building.md) it is now using jdk11. We can probably update that and close this task I would think.

This documents where the change from MariaDB to SQLite can be configured by the user without changing the defaults:

FWIW there is nothing currently in the Akonadi docs saying you shouldn't use sqlite. It was there in the past. https://techbase.kde.org/KDE_PIM/Akonadi#Why_not_use_sqlite.3F
Here is where they removed it: https://techbase.kde.org/index.php?title=KDE_PIM/Akonadi&curid=6207&diff=106967&oldid=106854

Appears resolved with the current dmd and ldc compilers. Closing.

I just did a quick test using ldc2:

The sambashares related issue was resolved in R2842:8108ccd2b475.

Target Giara for 5.0 when Serpent tooling support is available, since it supports repos and not just tarballs

I'm working on an update to samba in the 4.16.x series that will attempt to fix this issue.

The error relating to apparmor seems to be gone but I still cannot share folders and this error is displayed in Dolphin (my approximative translation):

Plasma has this implemented via: https://phabricator.kde.org/D3451

Note: We will need to do some version detection logic too.
PRIME Offload is only correctly supported on 435+ NVIDIA drivers, otherwise
we're back to the old approach.

vulkaninfo is provided by vulkan-tools. waylandinfo should be provided by wayland-utils, which isn't in the repos, but shouldn't be too hard to build.