Re: non-standard TCP tunings in EC2 images

>>>>> On Mon, 25 Jul 2016 15:59:18 +0200, Thomas Goirand <z...@debian.org> said: > On 07/20/2016 11:26 AM, Thomas Lange wrote: >> Using tasksel we already have different flavours of Debian >> installations. Why not see the cloud images as another

Re: non-standard TCP tunings in EC2 images

> On Tue, 19 Jul 2016 23:17:15 +0200, Lucas Nussbaum > said: > I noticed because #830353, #830452 and #831249 are triggered by this. > One could argue that those test suites are a bit fragile, but on the > other hand, I would expect an image labelled as

Re: Call For Participation Debian Cloud Sprint

I've add myself to the wiki for the sprint. I'm interested in attending. I have seen a lot of installation, configuration tools, live-builder and CD imaging tools in the past years (and do my own FAI project since 16 years) which all do similar things under the hood. I also think that a coherent

My comments on existing cloud tools

It should be easy for the users to create customized images, that may for e.g. non-Debian packages or configurations. User should use the same tools for their customized images as Debian will use for the official ones. IMO putting configuration into packages (as Neil suggests) is not an option,

Re: my progress

> On Sun, 6 Nov 2016 11:38:33 -0800, Noah Meyerhans said: > 3. Mount generated image locally and perform filesystem-level tests. Hi Noah, this can be done inside FAI itself. You can put some scripts into the tests/ subdirectory and name them after a class, see

Re: new FAI beta version

>>>>> On Wed, 9 Nov 2016 14:57:09 +0100, Thomas Lange >>>>> <la...@informatik.uni-koeln.de> said: > fai-diskimage -vN -u gnomehost -S3G -cGCE /tmp/disk-small.raw Do not use the hostname gnomehost, otherwise the sources.list will be wrong, because th

new FAI beta version

Hi all, the new FAI 5.3 beta version now supports definig classes using -c and additionally executing the scrips in class/. Before -c and -N could not used at the same time. This fixes the wishlist bug #843209. You can now call fai-diskimage -vN -u gnomehost -S3G -cGCE /tmp/disk-small.raw

order of classes in fai 5.3~beta4

With the current FAI version 5.3~beta4 we get a list of classes which selects the wrong disk partitioning config file. When you call # fai-diskimage -vN -u small -S5G -cGCE /tmp/disk.raw you get List of all classes: DEFAULT GCE AMD64 CLOUD FAIBASE DEBIAN DEMO GRUB_PC small LAST and

Re: order of classes in fai 5.3~beta4

When moving class/02-classes to class/80-classes we get another problem: List of all classes: DEFAULT GCE FAIBASE DEBIAN DEMO AMD64 CLOUD small LAST As you see the class GRUB_PC is missing. This is because the class AMD64 was defined in 80-classes but class/60-misc needs this class for defining

Re: Please make it easier to detect fai-diskimage

> On Thu, 10 Nov 2016 06:00:50 -0500, Sam Hartman said: > * I run fai on a running system to install onto a second disk and then > later reboot into that disk. Since it's a running system I would not > have DO_INIT_TASKS set. I guess you could use

Re: my progress

Hi Sam, today we've managed to produced an GCE image which was also tested with success. It boots, and we can log into this machine. We had to do some changes in the config space. Everything is now available in the examples of FAI on github. I plan to make a new FAI release in the middle of next

fai-diskimage, yet another disk image building tool

I've just released FAI 5.2, the new version of the Fully Automatic Installation tool set, which now supports creating cloud^Wdisk images ;-) It uses the normall FAI process and it's very fast. Using a small set of packages the image can be created in less than 50 seconds. A first version of a

Re: fai-diskimage, yet another disk image building tool

> On Tue, 18 Oct 2016 14:47:32 +0200, Emmanuel Kasper > said: > Is Fai using deboostrap or the debian-installer in the background ? (or > another approach) FAI does not use the debian-installer at all. It's using debootstrap but also creates a base.tar.xz so

Re: vmdebootstrap plans

My point was not about shell in particular, but about that every programming language could provide the same functionality without the need of YAML and Jinja2 in this example. For me, here YAML is just an overhead for calling function with some parameters, and it does not add any kind of

Re: vmdebootstrap plans

Hi Lars, I'm really wondering why you want to use YAML for this? Your examples look like things you could easily implement in shell, if you provide some functions, subroutines or external programs that implement your steps. Then your DSL would just be a shell script that the user has to write.

Re: my progress

> On Sun, 13 Nov 2016 06:42:37 -0800, Noah Meyerhans > said: > I based my work on jessie initially because we have JEB's high quality > jessie images to use as a baseline for comparison, and I found that > useful. +1 We agreed that we want to use fai for

Give FAI a try

Hi folks, if want to give FAI a try, here are some hints: - read the man page fai-diskimage(8) - create a config space for FAI by using the examples from the fai-doc package - mkdir -p /srv/fai/config - cp -a /usr/share/doc/fai-doc/examples/simple /srv/fai/config - either download a Jessie 64bit

Re: Converting an Internal Installer to FAI

Hi Sam, thanks a lot for the detailed report of your FAI experience. This is like an advertisement for FAI. You are right. The code for grub handling would better be in a library (or in lib/subroutines) or in an external script. After doing this we cloud call something like fai_setup_grub

Re: Converting an Internal Installer to FAI

> On Wed, 30 Nov 2016 15:21:02 -0500, Sam Hartman > said: > the rest of the project. As an example, FAI leaves installed systems > mounting disks nobarrier with unsafe dpkg IO enabled. That's really Hi Sam, Thanks for the long and detailed report.

FAI 5.3.3 and new ISO images

I've released FAI 5.3.3 and built new ISO images. fai-diskimage can now be used on a host which is using LVM, so more people can use it for building their cloud images. -- regards Thomas

fai-diskimage

The new test version of FAI (5.3.3~beta1) has now support for running fai-diskimage if the host uses lvm. This closes #845428. Please do not use a LVM configuration in disk_config. I'm not sure, if this will work. Use this line in sources.list to get the newest FAI version: deb

FAI 5.4 released

The new version 5.4 of FAI is available. It can now create cross-architecture disk images, but I guess this feature is not needed for the cloud sprint next week. You will find the release announcement here: https://lists.uni-koeln.de/pipermail/linux-fai/2017-October/011829.html -- regards Thomas

Cloud sprint

I'll arrive on sunday 15th oct around 4pm in Seattle Tacoma airport. Anyone else? I would like to have some hints from a local how to travel from Tacoma to Bellevue. Which options do you recommend? -- regards Thomas

Re: Generating a cloud / VM kernel package

For security reasons we could use the default Debian kernel and generate a long list of kernel modules which are blacklisted in the cloud environment. -- regards Thomas

Re: Summary of the Cloud Team BoF at DC17

> On Fri, 29 Sep 2017 07:22:15 +0100, Steve McIntyre > said: > Building > > any further. We will need to look into tools for making new VMs. I wonder what is meant by "making new VM". You do mean creating the disk image for the VM or starting the

Re: Error setting the repository list while build openstack images

> On Fri, 24 Nov 2017 17:38:57 +0100, Emmanuel Kasper > said: > OK , I see in your patch that your removed the call to the preinst > scripts to use the fcopy -S option. > But shouldn't have been > ./config_space/files/etc/apt/sources.list/preinst called

Re: Error setting the repository list while build openstack images

> On Fri, 24 Nov 2017 11:26:25 +0100, Emmanuel Kasper > said: > E: Malformed entry 1 in list file /etc/apt/sources.list (URI parse) > E: The list of sources could not be read. This is because of incompability of FAI 5.4 and 5.5 with the config space. I've

Re: [PATCH 3/4] Add support for building for other architectures

> On Fri, 10 Nov 2017 00:43:12 +1300, Andrew Ruthven > said: > Hmm, this didn't actually work, as it turns out. I'd only ever used > this method for building i386 on amd64, which does work. Trying to use > it for other architectures blew up. FAI already

chrony.conf file for GCE

Since https://github.com/GoogleCloudPlatform/compute-image-packages/issues/505 is now fixed we can use chrony in the GCE image. Is there a precreated chrony.conf for GCE, or does cloud-init or another package creates a chrony.conf? In the fai config space we use fcopy /etc/chrony.conf which

Re: Building cloud images using Debian infrastructure

Hi Bastian, I'm not sure if you know that we have this new repository: https://salsa.debian.org/cloud-team/qemu-vm This is what luca set up for openstack to create new clean VMs. We may want to use this for calling fai-diskimage inside the VMs when building the images. I want to avoid that

Re: Building cloud images using Debian infrastructure

> On Thu, 2 Aug 2018 18:33:26 +0200, Bastian Blank said: > Of cause, if you want to build the VM management by hand, you can do it. > But will it integrate or do you need to replace the whole rest of the > stack as well? I do not know how we want to build this whole CI stuff. I'm

Re: FAI Issues and PR's

> On Thu, 23 Aug 2018 14:26:31 -0700, Zach Marano said: > Which forum is everyone using to submit issues and/or get feedback on PR's for FAI configs and I guess FAI generally? There seems to be little conversation on salsa, is there another forum > somewhere? General FAI

Re: Building cloud images using Debian infrastructure

> On Wed, 29 Aug 2018 11:54:48 +0200, Bastian Blank said: > Official builds, which can be uploaded and released, will be built by > the runner on casulana.d.o. This runner is selected on specially > triggered official builds. Is this a runner on casulana or a a runner on salsa

Re: FAI Issues and PR's

> On Thu, 30 Aug 2018 11:42:03 -0700, Zach Marano said: > 2)  There is an extra file in /etc/apt that should probably be cleaned up (sources.list.pre_fcopy). But there may be others around as > well (haven't done an extensive audit). > -rw-r--r-- 1 root root   45 Aug 23 21:05

Re: Package conflicts, breaks, and problematic upgrades... with irqbalance

> On Tue, 27 Feb 2018 19:14:38 +, Zach Marano said: > So, irqbalance is a recommended package not a required package. But because its a recommended package by the kernel package it seems to get > priority to be installed even though it is not installed

FAI.me service now supports creation of VM disk images

A few days ago, the new feature of the FAI.me build service was added. Additionally to creating an installation image, FAI.me can now build bootable disk images. These disk images can be booted in a VM like KVM, Virtualbox or VMware or openstack. You can define a disk image size, select a

Re: Approval for spending money on 2018 cloud sprint please!

> On Sun, 30 Sep 2018 22:23:19 +0200, Tomasz Rybak > said: > I called the hotel and they told me that they are fully booked > for that week. So it looks like we're left with the current state > of reservarions. And I've got no answer at all after sending them two emails. --

Re: Approval for spending money on 2018 cloud sprint please!

>>>>> On Thu, 27 Sep 2018 23:06:54 +0200, Tomasz Rybak >>>>> said: >> 3. Sun-Thu (Thomas Lange and Tomasz sharing) >> > I'm happy to share, although I have King Bed - but I guess > that we can switch it to double beds. So

Re: 2018 Debian Cloud Sprint, 8-10 October, venue is *Seattle*

> I also booked there - and updated wiki. I will also be in the Holiday Inn Express from sunday to thursday. -- regards Thomas

Re: Approval for spending money on 2018 cloud sprint please!

>>>>> On Thu, 27 Sep 2018 02:56:11 +0100, Steve McIntyre >>>>> said: > 1. Sun-Thu (Jimmy and Luca sharing) > 2. Sat-Wed (Thomas Goirand) > 3. Sun-Thu (Thomas Lange and Tomasz sharing) > 4. Sun-Thu (Helen) I've booked a room with

FAI 5.8.1 changes handling of fcopy modes

FAI 5.8.1 will migrate into testing in 10 days. It includes a fix for fcopy bug #918185, which changes the precedence of the fcopy option -m/-M and the file-mode file. -- regards Thomas

cloud providers using openstack

At the DebConf I talked with zigo about cloud providers using openstack that may join the cloud sprint. If anyone has contacts, please ask them if they are interested. -- regards Thomas

Re: SHASUM verification for daily images

> On Mon, 29 Jul 2019 18:16:52 +0200, Faustin Lammler > said: > I can't find any daily images associated SHASUM file, for instance here: > https://cloud.debian.org/images/cloud/buster/daily/20190729-431/ > Is this normal, am I missing something? No. Thes shasum files are

Bug#932943: Missing SHA512 and gpg signature

> On Sun, 4 Aug 2019 18:29:30 +0200, Bastian Blank said: >> In each case I expect the values to be hex strings, effectively the same >> as the first column of the output from sha1sum, sha256sum, sha512sum, >> etc... from coreutils. > No, don't. Use base64 like everyone

Please test creating cloud images in your environment

Currently we have two methods of creating cloud images with our new toolchain. In the gitlab CI we use make and the python script debian-cloud-images which works nicely. Noah blogged about using fai-diskimage directly, which also I'm using for my local environment. Now, people start to use make

Bug#942326: debugging

When creating the generic image using make buster-image-generic the build script calls fai-diskimage --verbose --hostname debian --class DEBIAN,CLOUD,TYPE_DEV,BUSTER,BACKPORTS,GENERIC,AMD64,GRUB_CLOUD_AMD64,LOCALDEBS,LINUX_IMAGE_BASE,LAST FAI copies two files:

Bug#873604: still valid?

Can you please check if this setting is still valid for the buster image. -- regards Thomas

Re: Setting-up the Debian Cloud Image Finder (DCIF ?) in production

Hi zigo, do you think is currently needed to create such HA environment with clustered postgres? This seems to me a bit of overengineering. Shouldn't we first focus on getting real data into the database, and see if people are using this service, before putting so much effort into it? Anyway, I

Re: lack of boot-time entropy on arm64 ec2 instances

> On Wed, 8 Jan 2020 16:40:33 -0500, Noah Meyerhans said: > To be clear, the problem isn't a failure to boot, but rather a several > minute pause during boot. For me such a delay is kind of failure. And as Daniel wrote in his blog "unverified entropy is better than no entropy." --

Re: lack of boot-time entropy on arm64 ec2 instances

JFTR https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html -- regards Thomas

Re: cloud images

> On Tue, 18 Feb 2020 19:08:04 +0100, Vincent Legoll > said: >> > I don't see the checksum files, for example here: >> > https://cloud.debian.org/images/cloud/stretch/daily/20200206-162/ >> > >> > Are they stored elsewhere ? > Anything about that ? > The cloud

Re: Octavia image for OpenStack (merge request closed by Bastian)

Just for finding the relevant sources easier. Here's the link to the MR and the discussion during the sprint: https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/197 https://gobby.debian.org/export/Sprints/CloudSprint2019/2-%20Building%20images -- regards Thomas

Re: Image Finder Updates

Hi Arthur, thanks for your work. I have some minor text changes. - On the frontpage of the cloud finder, we do not need to explain what AWS, Azure,.. is. - We should add the information that for OpenStack users should use our Generic Cloud images. - https://image-finder.debian.net/provider/2

Re: Octavia image for OpenStack (merge request closed by Bastian)

> On Sat, 2 May 2020 22:12:48 +0200, Bastian Blank said: > Maybe we got to a consensus, over six months ago. Why don't you just > add a pointer, because not everyone can remember everything? Hi Bastian, you wrote "I was not able to find what consensus we got out of it...". It's

Bug#932943: hex or base64

Hi Bastian, in aug 2019 you wrote > Use base64 like everyone else. and > Everything current switches to base64. It's shorter and easier to see > changes. Hex only survives where people tend to read it. I've checked some other distributions in may 2020. They all use hex. They also provide

Re: Follow-up on last IRC meeting (ie: 12 Aug 2020)

> On Fri, 14 Aug 2020 09:45:43 +0200, Bastian Blank said: > Yes. GPT got a copy of it's header at the beginning and the end. You > can expand the whole thing and the tools will relocate the header on the > end correctly, but you can't shorten it. One approach might be to delete

Re: Publishing raw generic{,cloud} images without tar, and without compression, plus versionning of point releases

>>>>> On Wed, 27 May 2020 12:01:53 +0200, Bastian Blank said: > On Wed, May 27, 2020 at 10:39:01AM +0200, Thomas Lange wrote: >> fai-diskimage has the option -S which specifies the raw disk size. We >> set this in debian_cloud_images/cli/build.py to 2G

Re: Publishing raw generic{,cloud} images without tar, and without compression, plus versionning of point releases

> On Tue, 26 May 2020 10:29:17 +0200, Thomas Goirand said: > I already linked to how it could be done. I just asked (mostly Thomas) > if FAI was able to do it by itself, let's wait for his answer. Sorry for answering so late. fai-diskimage has the option -S which specifies the raw

Re: smaller cloud images, raw cloud images

> On Fri, 7 Aug 2020 18:49:14 +0200, Thomas Goirand said: > I don't think we need image as small as possible, to the last bits. > Quite the opposite, to make the resize-at-boot possible, we need to > leave a bit of free space. But even like that, we're talking about > saving

Re: Cloud Image Finder Release v0.1.0

> On Thu, 4 Jun 2020 09:17:38 -0300, Arthur Diniz > said: > Visit https://image-finder.debian.net to see this new version with your own eyes. Hi Arthur, the certificate of image-finder.debian.net has expired on June 25, 2020 Maybe you can refresh it. -- regards Thomas

Re: Publishing raw generic{,cloud} images without tar, and without compression, plus versionning of point releases

> On Sat, 6 Jun 2020 12:28:00 +0200, Bastian Blank said: > Also we don't want to specify the size a priori, because it can break to > easily. So we need to deduct the size during the build process. I could improve fai-diskimage using what zigo is using in his

Bug#932943: hex or base64

> On Sat, 6 Jun 2020 19:35:45 +0200, Bastian Blank said: > Now the remaining question is: GNU or BSD style checksum files? Let's use the same as our installer images use. This is GNU style. We should keep a common style on our Debian ISO images both for install and cloud images. --

Re: Debian Cloud Team delegation updates

> On Thu, 4 Jun 2020 13:34:07 -0700, Noah Meyerhans said: > delegates than is ideal? For their official duties, I'm not sure that > the workload is going to increase materially if we operate with only two > people, but I could be wrong. Would the current delegates like to >

Re: Publishing raw generic{,cloud} images without tar, and without compression, plus versionning of point releases

> On Sun, 7 Jun 2020 00:26:10 +0200, Thomas Goirand said: > It'd be really great if you could implement this. I tried quickly to do > that on images produced by the team, but also failed quickly and gave up > quickly too! :) I guess truncating a raw image with GPT fails because

Re: Official cloud image requirements

> On Mon, 8 Jun 2020 10:16:45 +0200, Emmanuel Kasper > said: > Let's see if there are others opinion in this thread, and if the topic > is settled, we can remove the sentence from the Debian Wiki. I agreee. Please remove the last sentence. -- regards Thomas

Re: Publishing raw generic{,cloud} images without tar, and without compression, plus versionning of point releases

> On Wed, 27 May 2020 12:01:53 +0200, Bastian Blank said: >> Sadly it is not that easy. A whole bunch of temporary data is deleted >> in the final stages of the build process. > You mean those bigger ones? > rm -rf $target/var/cache/apt/* > rm -rf

Re: Restarting regular IRC meetings

> On Mon, 8 Jun 2020 22:33:43 +0200, Thomas Goirand said: > Would that work on Thursday evening instead for everyone? This will not work for me, but feel free to do the meeting without me. -- regards Thomas

Re: Access forbidden to disk images in http://cdimage.debian.org/cdimage/cloud/

> On Fri, 24 Jul 2020 12:37:09 +0200, Renzo Davoli said: > Unfortunately this morning the images have not been created at all. Yes. We already saw this. -- regards Thomas

Re: Access forbidden to disk images in http://cdimage.debian.org/cdimage/cloud/

> On Wed, 22 Jul 2020 15:17:24 +0200, Renzo Davoli said: > In the last few days it is not possible to download the latest daily images. > It seems that the daily dirs have been created with the wrong permissions. > The problem began July 18. This is now fixed. We still need to

Re: Debian Jessie images are removed

We can add a link and info about jessie cloud images on https://cdimage.debian.org/images/cloud/ -- regards Thomas

Re: Follow-up on last IRC meeting (ie: 12 Aug 2020)

> On Fri, 14 Aug 2020 09:45:43 +0200, Bastian Blank said: > Yes. GPT got a copy of it's header at the beginning and the end. You > can expand the whole thing and the tools will relocate the header on the > end correctly, but you can't shorten it. After shorten the image or

Re: improving documenation

>>>>> On Wed, 28 Apr 2021 09:53:02 +0200, Thomas Lange >>>>> said: > Hi, > I've created a proposal for updating the header seen in > https://cloud.debian.org/cdimage/cloud/ The text is now updated. -- regards Grüße Thomas

Re: improving documenation

> On Wed, 28 Apr 2021 21:58:29 +0200, Thomas Goirand said: > Is there a git for it? It's this repo https://salsa.debian.org/images-team/setup.git > I would also very much welcome instructions on how to upload these > images. For example, at: >

improving documenation

Hi, I've created a proposal for updating the header seen in https://cloud.debian.org/cdimage/cloud/ You can see it here https://public.cs.uni-koeln.de/lange/images-cloud-HEADER.html Any comments welcome. -- viele Grüße Thomas

Re: Where to upload the Octavia image for Bullseye? Should I continue within the team?

Hi Thomas, (I've started writing this mail yesterday, before I received all the replies to your mail) I can understand your frustation. I'm also not happy about how some thing happen in the cloud team. I share your concerns about the over-engineered tool written in python. During our first

Re: Where to upload the Octavia image for Bullseye? Should I continue within the team?

> On Tue, 27 Apr 2021 22:38:57 -0700, Ross Vandegrift > said: > I think you're probably right on this. Since the cloud team is delegated, zigo > would need to remain a cloud team member to continue publishing official > images. I hadn't considered that in my other mail,

Re: improving documenation

> On Wed, 28 Apr 2021 18:56:55 +0200, Bastian Blank said: > We don't readlly provide GCE images. Some might show up, but we don't > want to advertise that. We build images for GCE, we call them debian-11-gce-amd64-daily-... so we can say we provide images for GCE. > Maybe "All

Re: Next team meeting: Wed Feb 10 @19:00 UTC

>>>>> On Thu, 11 Feb 2021 08:38:44 -0800, Ross Vandegrift >>>>> said: > fai updates > === > Thomas Lange is working on a new fai release. The pending changes do not > affect fai-diskimage, so cloud build tools should be unaf

openstack images for bullseye

> On Thu, 11 Mar 2021 22:14:37 -0800, Ross Vandegrift > said: > - vagrant images will continue to be delivered using a different toolchain, > similar to the docker images. We had no immediate concerns about this. I wonder what the status of the toolchain for openstack images

Re: referencing cloud images in bullseye release notes

Hi Noah, I think Ch. 3 is a good idea also adding a new section 3.2. I would also vote for an entry in the What's new part and adding a note for the Docker images. Our users want to find information about cloud and docker images, so we should not focus on saying "we do not have official docker

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

> On Sun, 14 Feb 2021 23:09:54 +0100, Thomas Goirand said: > (see my example with virtio-blk and virtio-scsi). The safest approach > was to have no default device set, though now it fails... It's very anoying that the grub prople changed this in a point release. One solution would be

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

This behaviour was also reported as #982182 -- viele Grüße Thomas

Re: Resignation as cloud team delegate

> On Thu, 2 Jun 2022 07:48:17 +0100, kuLa said: > Second I'm supporting the idea that people working for cloud providers > shouldn't be excluded from being DPL delegates. To be fair we can't afford to > not do it that way. > I just hope that we can struck a balance where

Link to cloud images on www.d.o/distrib

Hi, on the web page www.debian.org/distrib I've replaces the links like https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2 with -generic-amd64.qcow2 and similar types of images (raw, nocloud, arm64,...) is now defined in the webwml repository in

using zstd for qcow2 cloud images

Hi, in the function __convert_image_to_qcow2 in src/debian_cloud_images/images/__init__.py we convert a raw image to qcow2 and use compression by adding -c. Since qemu 5.1 it support using zstd compression by adding -o compression_type=zstd to the qemu-img convert call. This is much faster than

Re: using zstd for qcow2 cloud images

I've already said since 5.1 >>>>> On Sat, 16 Dec 2023 18:15:43 +0100, Thomas Lange >>>>> said: > Since qemu 5.1 it support using zstd compression by adding

Re: using zstd for qcow2 cloud images

Ooops, you are right Debian included this later. So we would exlcude oldstable users. > On Wed, 20 Dec 2023 22:20:00 +0100, Bastian Blank said: > On Wed, Dec 20, 2023 at 11:45:18AM -0800, Ross Vandegrift wrote: >> > What is the minimum qemu version for using those files? >> 5.1,

Re: Resignation as cloud team delegate

> On Mon, 5 Feb 2024 20:59:56 +0200, Jonathan Carter said: > That said, Is everyone listed below still happy to be part of the > delegation? I'm fine to be part of the delegation. -- regards Thomas

Re: Next team meeting: 2024-04-10 20:00 UTC

> On Wed, 3 Apr 2024 14:29:18 -0700, Noah Meyerhans said: > I'd like to be able to attend, but won't be able to at all during the > week of 8 April. Would folks be open to postponing this one week to > April 17 instead? It's ok from my side. -- viele Grüße Thomas