Closing as wontfix, as it's not complete.

I think we'll want to chmod -Rc 0770 /root during baselayout creation (to be consistent with /home/foo permissions), since it looks like the wrapped mkdir command _is_ indeed using a default umask of 0755 like I idly speculated a day or two ago.

It definitely has been changed (on my system) by the update I run today (where btw. baselayout was updated from 1.8.0-64-1-x86_64 to 1.8.0-67-1-x86_64).

GJ @Harvey

It works now :)

In T10549#201980, @Harvey wrote:

Hey Chax.

Which DE and shell are you using? I assumed Plasma with fish or zsh. If so could you check if the update I just pushed to unstable resolves your issue:
R3469:3a8a78aef7f9e5540ac73e62cdca647a0213eab1

Cheers.

Hey Chax.

As this is still an issue, I'll take a stab at actually fixing it soon™.

If we are planning to begin offering (optional) Wayland sessions, this is high priority IMO.

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")))

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?

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).

@ermo Yes, this is still an issue

Closing per reporter's request.

Is this still an issue for you?

Looks like the commented out HOME MODE 0700 setting in /etc/login.defs is indeed the issue:

Research notes:

Gonna take a stab at this; we likely need this fixed before spinning 4.4 ISOs.

Over to you Joey.

If someone who uses ne cares enough to step up to add the default editor stuff, they're welcome to do so at a later date.

Suggested changes for micro have been made D14068

I'll get these moved to github when I set up the new repo

I need to go through this and split things out as appropriate.

qt6-5compat landed in the repo.

epiphany - deprecated
gnome-clocks - deprecated

This was fixed with v1.0.6 of abi-wizard and in the latest yabi.

Dropping this to Normal since it was already reverted.

All of the patches we have are intentional and need to be rebased, likely on top of an updated arcanist.

After discussing this with @silke in #Solus-dev, I'm assigning this to Josh with tentative Priority and Project Tags as he's the one who handles OpenSSL.

@serebit No need to draw this out.

I wrote a large post of a reply but I've deleted it. Instead I'm just going to say this.

Let me be perfectly clear. This is a very low priority issue that you are making sound far worse than it actually is. That rule is working exactly as Josh intended when it was implemented. If something truly needs to be patched with regard to having the word eopkg in it, I can 99% guarantee that it's a patch that should probably be applied to an upstream repository and not one hosted on Phab.

Chiefly package repository priorities need to work correctly in mixed and layered repositories through a well designed system, something that eopkg currently lacks.
Given the amount of engineering effort required to make this nice in solbuild, and the obvious limitations in eopkg it would work around, the ROI is practically nil compared
to integrating directly with the Makefile system (which could do with overhauling)

OK, but its not working as intended at all. Mentioning eopkg in a package patch does and has happened (I literally am the voice of experience here.)
The rule is clearly too crude. As for solbuild having the functionality I don't directly object, but the entire process needs review tbqh.

The rule is working exactly as intended. It doesn't allow upload of any eopkg files, or files containing the word eopkg, as this should never be a requisite for a package-related patch.