Fedora 35 template

[marmarek]

The problem you're addressing (if any)
Fedora 35 is going out soon.

Describe the solution you'd like
We should have a Fedora 35 template.

Where is the value to a user, and who might that user be?
Users of the Fedora template who prefer to upgrade their templates by reinstalling will have a new template to upgrade to.

Tasks:

• build all packages
• build the template
• add to relevant qubes-builder/example-configs (including templates.conf)
• document
• upload to testing repo
• migrate to stable repo
• announce

If any issue affects Fedora 35 template (build failures, things that worked fine before etc), please add reference to this issue too.

[DemiMarie]

We need to add support for PipeWire in the audio code someday.

[marmarek]

Yes, we do.

[marmarek]

The template is in stable repo for R4.1 already. It will be soon in R4.0 too, just after current test run completes.
@andrewdavidwong can you prepare announcement?

[andrewdavidwong]

The template is in stable repo for R4.1 already. It will be soon in R4.0 too, just after current test run completes. @andrewdavidwong can you prepare announcement?

Opened: QubesOS/qubes-posts#96

I notice that "document" is still unchecked in the list in the OP. Is there actually still something left to document, @marmarek?

[marmarek]

Is there actually still something left to document,

I haven't found anything really. It was about upgrade documentation, but those we have version-agnostic already.

[resulin]

Is the update out yet? I seem to be getting these errors (even after doing sudo qubes-dom0-update to refresh the packages):

[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35
Redirecting to 'qvm-template install  fedora-35'
Downloading 'qubes-template-fedora-35-0:4.0.6-202205081759'...
qubes-template-fedora-35-0:4.0.6-202205081759:   0%| | 0.00/1.75G [00:00<?, ?B/sError canonicalizing file: not an RPM package
qubes-template-fedora-35-0:4.0.6-202205081759:   0%| | 0.00/1.75G [00:01<?, ?B/s
ERROR: [Errno 2] No such file or directory: '/root/.cache/qvm-template/tmp6nuswhpi/qubes-template-fedora-35-0:4.0.6-202205081759.rpm.UNTRUSTED'

[marmarek]

Looks like an issue with a repository mirror (the package is not yet at https://mirrors.edge.kernel.org/qubes/repo/yum/r4.1/templates-itl/rpm/, but theoretically it's past the mirror sync time already). I'll check why an alternative wasn't chosen automatically.

[Nurmagoz]

Got this on first run of Fedora-35-minimal: (downloaded from qubes testing repo)

[marmarek]

Looks about right - keys are imported by dnf on first use.

[marmarek]

Uploaded to R4.0 repos too.

[fireneat]

Currently it seems like Fedora 35 hasn't been added to https://github.com/QubesOS/qubes-builder/blob/master/example-configs/templates.conf so it isn't shown when you want to build it with qubes-builder

[andrewdavidwong]

Currently it seems like Fedora 35 hasn't been added to https://github.com/QubesOS/qubes-builder/blob/master/example-configs/templates.conf so it isn't shown when you want to build it with qubes-builder

@marmarek, should this be added to the standard checklist for new officially-supported template releases?

[marmarek]

@marmarek, should this be added to the standard checklist for new officially-supported template releases?

Good idea.

[ejose19]

Got this on first run of Fedora-35-minimal: (downloaded from qubes testing repo)

Looks about right - keys are imported by dnf on first use.

Is there any particular reason on why the key is not already imported in the pristine template? When I also saw that my first thought was that there's something off, especially when previous minimal templates didn't ask to import any new key (and one needs to verify the fingerprint shown there, which adds burden to the user)

[andrewdavidwong]

(and one needs to verify the fingerprint shown there, which adds burden to the user)

Technically, the user does not have to authenticate this fingerprint, since the key is already inside the template and is being imported locally (not from the internet). Since the entire template package containing this key was already authenticated when the template was installed (or the update packages when the template was upgraded in-place), one could argue that the fingerprint has already been authenticated by other means.

[ejose19]

(and one needs to verify the fingerprint shown there, which adds burden to the user)

Technically, the user does not have to authenticate this fingerprint, since the key is already inside the template and is being imported locally (not from the internet). Since the entire template package containing this key was already authenticated when the template was installed (or the update packages when the template was upgraded in-place), one could argue that the fingerprint has already been authenticated by other means.

If the key is already assumed to be trusted (based on these arguments, which I also agree), then it's another point in favor of having the key already added to dnf to save user time, unless there's a compelling reason to not do so.

[DemiMarie]

(and one needs to verify the fingerprint shown there, which adds burden to the user)

Technically, the user does not have to authenticate this fingerprint, since the key is already inside the template and is being imported locally (not from the internet). Since the entire template package containing this key was already authenticated when the template was installed (or the update packages when the template was upgraded in-place), one could argue that the fingerprint has already been authenticated by other means.

If the key is already assumed to be trusted (based on these arguments, which I also agree), then it's another point in favor of having the key already added to dnf to save user time, unless there's a compelling reason to not do so.

DNF should not be asking for the key to be imported. That it does is a bug in DNF when repo_gpgcheck=1 is enabled, as it is for Qubes repositories.

[ejose19]

(and one needs to verify the fingerprint shown there, which adds burden to the user)

Technically, the user does not have to authenticate this fingerprint, since the key is already inside the template and is being imported locally (not from the internet). Since the entire template package containing this key was already authenticated when the template was installed (or the update packages when the template was upgraded in-place), one could argue that the fingerprint has already been authenticated by other means.

If the key is already assumed to be trusted (based on these arguments, which I also agree), then it's another point in favor of having the key already added to dnf to save user time, unless there's a compelling reason to not do so.

DNF should not be asking for the key to be imported. That it does is a bug in DNF when repo_gpgcheck=1 is enabled, as it is for Qubes repositories.

There seems to be a reported bug that looks like this issue (https://bugzilla.redhat.com/show_bug.cgi?id=1768206), can something be done on Qubes side in the meanwhile? It was reported 3 years ago with no hints that it will be fixed anytime soon.

[DemiMarie]

(and one needs to verify the fingerprint shown there, which adds burden to the user)

Technically, the user does not have to authenticate this fingerprint, since the key is already inside the template and is being imported locally (not from the internet). Since the entire template package containing this key was already authenticated when the template was installed (or the update packages when the template was upgraded in-place), one could argue that the fingerprint has already been authenticated by other means.

If the key is already assumed to be trusted (based on these arguments, which I also agree), then it's another point in favor of having the key already added to dnf to save user time, unless there's a compelling reason to not do so.

DNF should not be asking for the key to be imported. That it does is a bug in DNF when repo_gpgcheck=1 is enabled, as it is for Qubes repositories.

There seems to be a reported bug that looks like this issue (https://bugzilla.redhat.com/show_bug.cgi?id=1768206), can something be done on Qubes side in the meanwhile? It was reported 3 years ago with no hints that it will be fixed anytime soon.

It will be fixed in DNF 5 hopefully. Upstream is not interested in fixing it for DNF 4.