+10... er, +1

+1

I don't love this solution at all, but it's better than nothing.

My principal concern remains that I don't want it to look like we're happy with and that we endorse these kinds of broken platforms. If it were possible, I'd like a drop-dead date for this support so that we don't carry this debt around forever.

But at the same time, this is stuff people have and when they become unsupported by Microsoft and the OEM due to the natural order of things, it's nice to have Fedora available for them.

So from me, this is an extremely weak +1.

I haven't had the time to read all the discussion yet and from reading the proposal, I would really want to have an answer to why this would not work with system-stub before we move forward:

Stubble is a fork of systemd-stub there is no reason why the same should not be possible with systemd-stub. Testing has shown that ATM using systemd-stub this way does not work, why this does not work has not been investigated yet. For now we are going with Stubble.

So voting -1 to keep this from being auto-accepted.

I haven't had the time to read all the discussion yet and from reading the proposal, I would really want to have an answer to why this would not work with system-stub before we move forward:

Stubble is a fork of systemd-stub there is no reason why the same should not be possible with systemd-stub. Testing has shown that ATM using systemd-stub this way does not work, why this does not work has not been investigated yet. For now we are going with Stubble.

The answer has been given on the mailing list. It basically boils down to bugs in sd-stub, and there's some ongoing work by @jwrdegoede to collaborate with Ubuntu folks to resolve those issues. But they aren't going to get done this cycle.

+1 based on the explanation for using stubble

Discussion of this topic was postponed to next week's meeting (log starting at ~18:52 UTC).

@siosm wrote:

I haven't had the time to read all the discussion yet and from reading the proposal, I would really want to have an answer to why this would not work with system-stub before we move forward:

This question / objection has also been asked several times in the fedora-devel email thread. So I've been looking into this to see if I can get things to work with systemd-stub.

And I've good news. Generating the "UKI" without an .osrel section in combination with fixing one small systemd-stub bug:

https://github.com/systemd/systemd/pull/40329

allows using systemd-stub.

This bugfix has been merged by systemd upstream and I've submitted a dist-git PR to get this backported which has also been merged:

https://src.fedoraproject.org/rpms/systemd/pull-request/231

So as soon as a new systemd build is done for rawhide we're good to go to use systemd-stub from day 1, rather then the stubble-stub. I'll go and update the change wiki page accordingly.

The wiki page has been updated to reflect that systemd-stub will be used.

I haven't had the time to read all the discussion yet and from reading the proposal, I would really want to have an answer to why this would not work with system-stub before we move forward:

Stubble is a fork of systemd-stub there is no reason why the same should not be possible with systemd-stub. Testing has shown that ATM using systemd-stub this way does not work, why this does not work has not been investigated yet. For now we are going with Stubble.

So voting -1 to keep this from being auto-accepted.

Do you want to change your vote now that the change doc has been updated?

+1

I've finally caught up with the discussion and everything is going in the right direction. Thanks.

+1

Dropped meeting tag as there's no more negative votes.

Vote has been open for 2 weeks, and there's no more -1 so

APPROVED (+6, 0, -0)

Announced in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IXPVJMEORBD34ZVW3C43WTUK6NR3SC6H/