Fedora 30 approaching EOL, Fedora 31 TemplateVM available, Fedora 32 TemplateVM in testing

[Andrew David Wong]

Dear Qubes Community,

This announcement includes several updates regarding Fedora TemplateVMs.

Fedora 30 approaching EOL
=========================

With the release of Fedora 32 on April 28, Fedora 30 is expected to
reach EOL (end-of-life) [1] on May 26, 2020.


Fedora 31 TemplateVM available
==============================

A new Fedora 31 TemplateVM is now available for both Qubes 4.0 and 4.1.
Instructions are available for upgrading Fedora TemplateVMs. [2] We
also provide a fresh Fedora 31 TemplateVM package through the official
Qubes repositories, which you can get with the following commands (in
dom0).

Standard [3] Fedora 31 TemplateVM:

$ sudo qubes-dom0-update qubes-template-fedora-31

Minimal [4] Fedora 31 TemplateVM:

$ sudo qubes-dom0-update qubes-template-fedora-31-minimal

After upgrading to a Fedora 31 TemplateVM, please remember to switch all
qubes that were using the old template to use the new one. [5]


Fedora 32 TemplateVM in testing
===============================

For advanced users, a new Fedora 32 TemplateVM is currently available in
the `qubes-templates-itl-testing` repository for both Qubes 4.0 and 4.1.
We would greatly appreciate testing and feedback [6] from the community
regarding this template.


[1] https://fedoraproject.org/wiki/End_of_life
[2] https://www.qubes-os.org/doc/template/fedora/upgrade/
[3] https://www.qubes-os.org/doc/templates/fedora/
[4] https://www.qubes-os.org/doc/templates/minimal/
[5] https://www.qubes-os.org/doc/templates/#switching
[6] https://www.qubes-os.org/doc/testing/#providing-feedback

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2020/04/30/fedora-31-template-available/

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

[seshu]

One question that just occured to me about upgrading the template VM's. Many of the comments and posts in this forum are assuming Qubes is installed on a laptop. I have it installed on a desktop, and my keyboard / mouse uses sys-usb. I need to have this appVM running to use the peripheral obviously. But, since the appVM is running, I can't update the templateVM?

Is their any workaround, or do I need to go get a ps/2 keyboard and then turn off sys-usb, update the template and then restart it? Is that the only option I have? IT seems like there could be a better way?

Thanks!

[Insurgo Technologies Libres / Open Technologies]

You can update the templatevm while dependant vm is running. Appvms are using a read only version of last updated templatevm, which is why you see recycling arrows on appvms in qubesos vms tray icon after applying template upgrades.

As long as your sys-usb stays alive you will keep alive your keyboard and mouse. Follow instructions for upgrade, launch another appvm depending on template for safeguard testing, and reboot yiur machine and you should be good to go!

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[brenda...@gmail.com]

On Friday, May 1, 2020 at 12:39:54 AM UTC-4, seshu wrote:

One question that just occured to me about upgrading the template VM's. Many of the comments and posts in this forum are assuming Qubes is installed on a laptop. I have it installed on a desktop, and my keyboard / mouse uses sys-usb. I need to have this appVM running to use the peripheral obviously. But, since the appVM is running, I can't update the templateVM?

Is their any workaround, or do I need to go get a ps/2 keyboard and then turn off sys-usb, update the template and then restart it? Is that the only option I have? IT seems like there could be a better way?

If you have a desktop, you probably have at least one pcie slot available for an additional USB controller, yes? Some laptops already have multiple pci controllers for usb, and some have expresscard slots that can accept an additional usb controller. This works for all these cases:

Clone the template.

Do the update in the clone of the template.

If successful continue, otherwise stop.

Create a sys-usb2 based on the cloned/updated template.

Attach your secondary USB controller to it.

Make sure a backup keyboard/mouse is properly seen in that controller.

If that works:

-Set up your system autostart both sys-usb (using primary usb) and sys-usb2 (using secondary usb).

-Set up your system to allow keyboard/mouse from both sys-usb and sys-usb2 (see qubes documentation)

If that doesn't work:

-Stop

Set your sys-usb template to the updated clone, so both sys-usb (with primary usb controller) and sys-usb2 (with secondar usb controller) can provide keyboard and mouse to the system, including LUKS password.

Reboot.

Once you are sure everything works, you can get rid of your secondary sys-usb2 if you want.

B

[Miguel Barbosa Gonçalves]

On 2020-05-01 17:48, brenda...@gmail.com wrote:
> On Friday, May 1, 2020 at 12:39:54 AM UTC-4, seshu wrote:
>
> One question that just occured to me about upgrading the template
> VM's. Many of the comments and posts in this forum are assuming
> Qubes is installed on a laptop. I have it installed on a desktop,
> and my keyboard / mouse uses sys-usb. I need to have this appVM
> running to use the peripheral obviously. But, since the appVM is
> running, I can't update the templateVM?

Hi!

Before I had an additional USB controller for my keyboard and mouse,
which by the way is a great idea as good PS/2 devices are are to find
new, I used the following commands in dom0

$ qvm-stop --wait sys-usb; \
qvm-prefs sys-usb template fedora-31; \
qvm-start sys-usb

This stops the sys-usb qube, changes the template and starts it again.

Be careful and do not make any mistakes because if the sys-usb qube does
not start you might be locked out.

Hope this helps.

Cheers,
Miguel

[Olaf Klinke]

I am on a desktop, too, and would not know where another USB controller
should be on the machine, whence Brendan's suggestions are not feasible
for me. I take it the above commands replace the template rather than
upgrading the same template? I think swapping out the templates might
be a safer route for a qubes-newbie like me.

I do not have a sys-usb, since I installed Qubes OS while using a USB
keyboard. Which domain are my USB devices attached to? The Qubes
documentation is not explicit about that, it only says removing the
sys-usb qube will attach the devices directly to dom0. Is that the way
Qubes configures itself when installing without PS/2 keyboard?

Is it possible to amend the above commands with an automatic revert?
I'm thinking of the way one changes display settings in Windows. After
a change, a diaglogue box is presented asking whether you want to keep
the new settings. If the user does not acknowledge in a few seconds,
the old state is restored. Could the following work?

Thanks
Olaf

#!/bin/bash
qvm-stop --wait $QUBE_WITH_USB
qvm-prefs $QUBE_WITH_USB template fedora-${NEW_VERSION}
qvm-start $QUBE_WITH_USB
echo "hit Ctrl-C to keep the new fedora $NEW_VERSION"
sleep 10
# if keyboard still works, the user will be able to interrupt here.
qvm-stop --wait $QUBE_WITH_USB
qvm-prefs $QUBE_WITH_USB template
fedora-${OLD_VERSION}
qvm-start $QUBE_WITH_USB
echo "failed to upgrade to fedora-${NEW_VERSION}"

[Catacombs]

Will there be a new release of QUBEs to avoid a new release of iso?

[dhorf-hfre...@hashmail.org]

On Fri, May 01, 2020 at 10:33:08PM +0200, Olaf Klinke wrote:
> > > and my keyboard / mouse uses sys-usb. I need to have this appVM
> > > running to use the peripheral obviously. But, since the appVM

> > > running, I can't update the templateVM?

if you really _need_ sys-usb (== only keyboard is USB), i would
recommend disabling sys-usb autostart anyways.
then replacing the template can be done on next reboot before
starting sys-usb.

or do that scripted shutdown/prefs/start dance.
but that can be a bit tricky for various reasons.
and i would recommend to try it with autostart disabled anyways,
just in case.

> I do not have a sys-usb, since I installed Qubes OS while using a USB
> keyboard. Which domain are my USB devices attached to? The Qubes

you should configure a sys-usb anyways.
https://www.qubes-os.org/doc/usb-qubes/
just two qubesctl calls. (plus one qvm-prefs to disable autostart)

> documentation is not explicit about that, it only says removing the
> sys-usb qube will attach the devices directly to dom0. Is that the way
> Qubes configures itself when installing without PS/2 keyboard?

yes, your usb will be directly attached to dom0 currently.
and that is not a recommended configuration.
otoh, it means you dont have to worry about replacing the template. ;)


some hints regarding the whole scripted replacement plan though...

> qvm-stop --wait $QUBE_WITH_USB

... there is no qvm-stop.


> sleep 10

10sec is _very_ optimistic for a full sys-usb boot and settling
the USB situation. i would recommend something like 120sec.

[Sven Semmler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, May 01, 2020 at 11:02:56PM +0200, dhorf-hfre...@hashmail.org wrote:
> you should configure a sys-usb anyways.
> https://www.qubes-os.org/doc/usb-qubes/
> just two qubesctl calls. (plus one qvm-prefs to disable autostart)

WARNING! Read the instructions carefully! Running the script will add
parameters to your boot config that tell dom0 to ignore USB. In your
case (only USB keyboard) that can end in disaster (meaning you are
locked out).

So make sure to remove those from your grub/EFI config before rebooting!
The USB qube will work anyway but if it's not running dom0 will have
USB. If you skip this step you won't be able to control your computer
after reboot.

We have a tragic case of this every other month in this list.

/Sven

- --
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl6slcIACgkQ2m4We49U
H7a/HA/8DH8OdIVlzk/q4mp4y2XSym41G7bQGtPsuTxQNz61Eq9lrKTd3tXY6C/H
ZpuXox5WVRp4Th1kYPb5zAme+GQtCGrJnrkaEag82OkEr4B0NJ+/rg3IGNIYaLQv
44yFGgPHftCsneYNPV0iBKphKhmLV+UQMg8bahXEsi5OY+7T8tnQO4yyYnJA/i4l
wduLTM80t77gL4qqAaO4mTORhHve5EOaA3UN89z0B/t46myz/8Zm5QMMRsDNw9qC
0s97ff+n5aDa9LZuMa/k2FTf6vKeVOpVxMG2+D0bXsW6fBK4u4Ia/+5krFmyq+7d
wtwypXyicbcb2eeF9R9qqzCuUTzCrtxVIf3DTE8YTlCRnQS0zuvGEr3429t5nsq1
J+nfsWuyrumZNCT4tkaYmmVwao/0cjgeDVu7P+hqxKOUuRNLLIYDCbmlKASgntrH
WmmX/m8WUtNTRK2ZOggR2IJCOqnvuz1DQjeq0zy/uqR3imBFTSoWjA8VUB+tC4P/
qYpewKxUg8mCCKplS19r3sppldCbfEpCFrpPCwcZCGec1WwlOLRo8Krrx9Iifh0O
2udkYjDm89h4FO2ZQETPTVDksgX/KT41NEN08IM7wag5DE1zPnkrf3ZTfOlw6b4P
NyqZR9JCwx5ds/vSsOOYoqPCDiWSSu8J/LplmVFjxRREncaA/iE=
=av9E
-----END PGP SIGNATURE-----

[dhorf-hfre...@hashmail.org]

On Fri, May 01, 2020 at 04:33:55PM -0500, Sven Semmler wrote:

> So make sure to remove those from your grub/EFI config before rebooting!

yes, that would be what the second qubesctl call does.
there should be no need for manual config editing during this.

> The USB qube will work anyway but if it's not running dom0 will have
> USB. If you skip this step you won't be able to control your computer
> after reboot.

only during / right after reboot.
once sys-usb tried to start, the controller will not return to dom0
until next reboot (or you do some ritual dancing that requires a kbd...)

thats what my "disable sys-usb autostart if you rely on a USB kbd"
recommendation is about.
so you actualy have a kbd to fix things if you manage to wreck your
sys-usb ... config, template, filesystem damage, so many ways ...

[Sven Semmler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Cool. Just making sure ... ;-)

/Sven

- --
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl6smGQACgkQ2m4We49U
H7bCNQ//RokYdCPy4h3dN343FIMmKpCJY2LX3VNEOgoVy2PJ1If0al2R39vscXMO
LhXllFA5ERsEyx8X43lu76pEP73cXYJFrR0d1LUNflqkL6AzxThysjfcgd7VC+eu
mENVF9LDvxI9FDyOxhWii5HOH34LZIaoNRFIWOfQ6Qhf84oILOlxI/nFKNrIm0HN
rSaeOabGweu2E+etlaPTaWRp9ziTSAXU+h9abzOIfbHmgArqar9JYUgRyAPtfTTQ
7zjKLgnoHtkc/QuTXDk/sxbO9Zht1ILwOcy2pmoZaSZwsvm3m+bRoLwc8ppysVN/
41z2a9V6pghO5Sfl62nHtfCrklISFfzbxT1KKpmwNMXYkVGH/bHrepZNWNGrKaTx
/yZusE0OF3C533tsBYiA+WvVz54jsqenSwYwEWDFqWwOeQl/Fj6tALb1jyFuNuKs
1sHvGMtmKkF7w7T5uWY27GTWUWkoon6jtkxAFVSxRioVHJTq7MF9N5YThV2vwn0n
dN8Mn64+R6eZ0MTvAC/pYCdH0mnxTY44vlxXDesis4QFncbMEXus/JPWk9vin+6R
6sXChTgGt6fzeQr4DuttiweVre0LKf4UNjIf2IoeqvBEHnwRwZPoEzEj5O8aXGrQ
Gelu2aM8+yO/IKUg5AHeTh/UadJtjDe0cUontZvOHklk3KPXK7I=
=tdli
-----END PGP SIGNATURE-----

[seshu]

@Miguel  thanks!

and thanks to everyone who provided feedback, this was really educational for me. I'm not quite a qubes newbie, but I'm not an expert either.

The idea from Brend was too sophisticated for me and so I was nervous about it. I decided to go with Miguel's approach and that was great. One change though. The qvm-stop is now qvm-shutdown, so the instructions I needed to use are:

$ qvm-shutdown --wait sys-usb; \

qvm-prefs sys-usb template fedora-31; \
qvm-start sys-usb

it all work quick and painlessly. This really should be added to the instructions for updating a templateVM.  I'll see if I can add that into the documentation.

Thanks again everyone!

On Friday, May 1, 2020 at 5:22:42 PM UTC, Miguel Barbosa Gonçalves wrote:

[Olaf Klinke]

On Fri, 2020-05-01 at 21:24 -0700, seshu wrote:
> @Miguel thanks!
>
> and thanks to everyone who provided feedback, this was really
> educational
> for me. I'm not quite a qubes newbie, but I'm not an expert either.
>
> The idea from Brend was too sophisticated for me and so I was nervous
> about
> it. I decided to go with Miguel's approach and that was great. One
> change
> though. The qvm-stop is now qvm-shutdown, so the instructions I
> needed to
> use are:
>
> $ qvm-shutdown --wait sys-usb; \
> qvm-prefs sys-usb template fedora-31; \
> qvm-start sys-usb
>
> it all work quick and painlessly. This really should be added to the
> instructions for updating a templateVM. I'll see if I can add that
> into
> the documentation.
>
> Thanks again everyone!
>

That's good to know. I shall complete this into a script that reverts
the change if anything goes wrong.

Sven wrote:
> So make sure to remove those from your grub/EFI config before
> rebooting!

> The USB qube will work anyway but if it's not running dom0 will have
> USB. If you skip this step you won't be able to control your computer
> after reboot.
>

> We have a tragic case of this every other month in this list.

Hearing this, I will postpone following dhorf's advice to create a sys-
usb until I am more familiar with the inner workings of Qubes OS. If it
was really unrisky and straightforward scripting, why did the Qubes OS
installer not offer this choice, let alone just do it?

Olaf

[dhorf-hfre...@hashmail.org]

> was really unrisky and straightforward scripting, why did the Qubes OS
> installer not offer this choice, let alone just do it?

a mix of historic reasons and expecting users to do their homework.

without a sys-usb, you can not really use usb devices with qubes.
and _trying_ to use them will connect them to dom0, which is a decent
sized can of worms.
as in: usb keyboard is bad. no sys-usb is worse.

and yes, it might be time to change what the installer does when seeing
a usb keyboard.

[lik...@gmx.de]

> Fedora 32 TemplateVM in testing
> ===============================
>
> For advanced users, a new Fedora 32 TemplateVM is currently available in
> the `qubes-templates-itl-testing` repository for both Qubes 4.0 and 4.1.
> We would greatly appreciate testing and feedback [6] from the community
> regarding this template.

What's the expectation for Fedora 32 to reside in testing templates before it's moved to official repos?
I'm asking because it might be worth waiting for Fedora 32 before moving first to Fedora 31. This is of course only reasonable if it will be before EOL of Fedora 30.

[Catacombs]

I used Iphone as a hot spot. After I had WiFi working I started Whonix. Went to System/terminal used the update command with —clean in the middle of it. At some point it switched to a second server or repository.

I have now used up 4.4 GB of my ten GB HotSpot with thirty days left. I also did an update of dom0 and Whonix.

I thought I should come back and explain one way the update works. After I got several error messages.

And again. Thanks to our developers who keep this OS working.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

You can track template testing here:
https://github.com/QubesOS/qubes-issues/issues/5761
(especially see issues linked there)
Sadly, Python 3.8 in there breaks few things (including updates via
salt), so it may not be ready before Fedora 30 EOL.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl6va54ACgkQ24/THMrX
1yxPSQf/aI95paVe0x++hEsYicKLduDxbcr4BaFlWOtyhKEPjoiU/OJwTevKIafe
jjHms5DOfRwRzasbgDm5fUV4JJad4V5L+B5I9PdB/9a6qL3nalIxOAgOD//OwHNQ
ZG1IytW1aGh+u5zmqGhEMysWep0mfnbf5g8NIZogaGo0HOpBy71tjBfu8FT0nvb+
3s9Nq1yyZdwdQgkU/xOZJ558OmrjPSsgpVYQzpf55JfJt3x1EYjC918CZC7HqCeC
VfhUAAiwS4FsTITxx/RESdp8Ax4JIke5/vs/7JjaVe0BH70MYi96/iIDbSltSUzS
KHAJAl/vbHA9R7xSIiE+qxtP+8v++Q==
=4Rct
-----END PGP SIGNATURE-----

[Sven Semmler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sat, May 02, 2020 at 10:23:45AM +0200, Olaf Klinke wrote:
> Hearing this, I will postpone following dhorf's advice to create a sys-
> usb until I am more familiar with the inner workings of Qubes OS. If it
> was really unrisky and straightforward scripting, why did the Qubes OS
> installer not offer this choice, let alone just do it?

The installer does offer the option, it simply isn't selected by
default. After reading and understanding this page in its entirety
you should be fine:

https://www.qubes-os.org/doc/usb-qubes/

/Sven

- --
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl6we1EACgkQ2m4We49U
H7YPzw//Z1jEG3abV31dz84hkqB1lfNHTB4ZN0MUnkV9bInfVbzZTYHPt3jtqFrw
CAZOD21JMntKcSHJTNuMn7WBSf/2WXuqWLrTazbHpYzZSCLUULHVK9FNcnboF8WH
DI4cQ9F4g2m4Ig1NIuNeJ52TXr1/ZyWR9nMGsMSEoAtrY0zN6TgjuKvjujrtFdPQ
1NfrQ9H3gAq4e54qpEmeINsmfX485dTOxw7OCIFi+7Yq7Ltmm57v9PCn30povq2W
kwx5sK5iH6pBSepcZtRGN7qeiTizzOnI5PHDqTTA0FmArK/etVuYWawRiJuxuEFt
yHLStNIHwJSCacEKVm4XID0m+nf1eb69gWaDztv2ENVcEPHHLkpKt393JgKE6w81
CTjj5ZkG2zI7pUyYpDddnmgAu8YKGmo4XjQivZLds8FFN074+v1AIbE7kAaHLBju
y8hk9gUxt3lRHboZB1vz+IwE56qVUOtWp1WHxsSjXG6uXa/n+WLmQ4idOqT5cfWn
L0NveKvvgHnEkZ/vrRKlGw4R/Tohv3nGaMj9XQn3BO/0bHzFASrJWDUZh/wMpWcg
MfqtfNyHyUZYYUQnRcyWcDmFJ1xppybJxVJXBOcnayp7ce/r4CVkL90fZoozs3UF
PchF2v661eFl2qu2ymFWjToKAgAUWtvrwiKzlWXBmuivw03eOBU=
=4ouS
-----END PGP SIGNATURE-----

[Sven Semmler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, May 04, 2020 at 03:30:05PM -0500, Sven Semmler wrote:
> On Sat, May 02, 2020 at 10:23:45AM +0200, Olaf Klinke wrote:
> > usb until I am more familiar with the inner workings of Qubes OS. If it
> > was really unrisky and straightforward scripting, why did the Qubes OS
> > installer not offer this choice, let alone just do it?
>
> The installer does offer the option, it simply isn't selected by
> default.

I see now, this was in relation to the USB keyboard specifically. I
think at some point the idea was that Qubes would be primarily used with
laptops (having internal keyboards). But it would certainly be nice if
someone had the skills and time to improve the installer in this regard.
I fear though that's non-trivial.

/Sven

- --
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl6wfGgACgkQ2m4We49U
H7ZbHBAAvoQtAGPCJHMO6knT4ltDPPXfq8zi8eYMV4MWBTRejyr9fs5djYkJCygA
JW98goa07NGC07aUGf5Dw4lLO/V1ZAxHYNmzK0VUasksADTz7B7nriUpqihaQS9z
vzG5iJIs5GEVDlx54UxV7RM3Jspy4o1R/55sOd6oyGHVHd9x2lnvoDct+vsXFgXX
6XyyvXKEQdzzPjwFui4nx949uZHxFEPxXYGvwnb9K8bIiWuyBe70Y+DQaVASV352
Pa1CySN9ebtTKzlQemeJxkdne2V3HpoqvrfisUQawOyPeN6pdnDCMDLlAt+7HZpF
f4kqd589gTFKO4hEWlxOhQBbcnjWuPOUyEQ7HVw0xWkuiJ7rYlyiXwJFt9KTJL4s
0KcQmS6+cgyHJy8A7jDIMw9XZm8M1H60CP7yXNzXxKmQ3Fl76H9TH1whAY09KLYl
y5psgpiyvDhFpGlfEzaGN4gy53t6Tj4rBC7Q8R2zw8HSZDAlulWM0cO5icla5lBs
csU6GKYATY2VNSQPq6J0MBR6AcWghudYBZxCgjiujpkjQF7JyLBIQVdUKMrMiC9/
03Md9NZWA4CwTf8Ehens7mWLSnr7Pu2FRaHnnpPurxlpCeDR0Na7dmMmnT827cb0
AcXLESmiRTrF/zT5DTWkGZPQLk1jUPesZAHPburE8B2U8hBS5q4=
=t0Zh
-----END PGP SIGNATURE-----

[Lorenzo Lamas]

I noticed that the Fedora 32 template is in the stable repo, but no announcement yet.

[Stumpy]

On 2020-06-28 14:40, Lorenzo Lamas wrote:
> I noticed that the Fedora 32 template is in the stable repo, but no
> announcement yet.
>

> --
> You received this message because you are subscribed to the Google
> Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to qubes-users...@googlegroups.com
> <mailto:qubes-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/2ff4a47e-5fc5-49db-966d-4727fdd46fdco%40googlegroups.com
> <https://groups.google.com/d/msgid/qubes-users/2ff4a47e-5fc5-49db-966d-4727fdd46fdco%40googlegroups.com?utm_medium=email&utm_source=footer>.

I'd really be interested in this as this might make my fed31 repo
updates moot.