Hi
On Sun, May 23, 2021 at 03:16:49PM -0400, Tong Sun wrote:
> $ az vm image show --urn debian:debian-11-daily:sid:latest
> (NotFound) Artifact: VMImage was not found.
Should be: debian:debian-sid-daily:sid:latest
> $ az vm image show --urn debian:debian-11-daily:bullseye:latest
> (NotFound)
Hi Thomas
On Wed, Apr 28, 2021 at 09:53:02AM +0200, Thomas Lange wrote:
> 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.
We don't
Hi
On Wed, Apr 28, 2021 at 09:38:31AM +0200, Thomas Lange wrote:
> > 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
Hi Thomas
On Tue, Apr 27, 2021 at 02:57:23PM +0200, Thomas Goirand wrote:
> At this point, publishing my work has been denied twice, so I believe it
> is very legitimate to ask the team what it think I should do.
Where was your work denied? It was in review and you had ample
opportunity to fix
Hi Jelmer
On Tue, Apr 20, 2021 at 02:59:51PM +0100, Jelmer Vernooij wrote:
> Are there any GCP resources that Debian-related projects can use?
We don't have any GCP resources ready for Debian-related projects.
Regards,
Bastian
--
Leave bigotry in your quarters; there's no room for it on the
On Wed, Apr 14, 2021 at 10:34:02PM -0700, Ross Vandegrift wrote:
> - there isn't a stable URL for the latest image. Both the directory and the
> image filename contain the date & build number.
https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/249
Bastian
--
Intuition,
On Wed, Apr 14, 2021 at 10:36:27PM -0700, Ross Vandegrift wrote:
> Here is my draft following today's discussion. Please send along any
> feedback.
Sounds good.
Bastian
--
Knowledge, sir, should be free to all!
-- Harry Mudd, "I, Mudd", stardate 4513.3
On Thu, Apr 08, 2021 at 11:33:31AM -0700, Noah Meyerhans wrote:
> In order for that to work, though, the
> key needs to be available in *binary* format. So we still do need gpg
> to do the conversion.
No, apt does not require a binary key file. Just give it the
Hi Winn
On Thu, Mar 04, 2021 at 01:51:30PM +, Winn Johnston wrote:
> I am interested in learning how to verify the cloud images in Azure.
What are you trying to verify? In theory you can verify that you get
the same image as we publish on our own storage, but it's not easy.
There is no real
On Mon, Feb 15, 2021 at 09:21:30AM +0100, Thomas Lange wrote:
> One solution would be to not set it for cloud images, but during first
> boot check if it's unset and then try to determine the device name and
> fill debconf to make grub happy.
The cloud images don't use grub-pc at all since
Hi Matteo
On Tue, Oct 06, 2020 at 02:58:22PM +0200, Matteo Croce wrote:
> The official Debian Buster image breaks when upgrading to bullseye.
> GRUB fails like:
I can't reproduce this. Which image did you use? What did you do?
Bastian
--
Landru! Guide us!
-- A Beta 3-oid,
Hi Michael
On Tue, Jan 12, 2021 at 09:12:11AM +0100, Michael Kesper wrote:
> I had that issue on images where grub was meant to use paravirtualized drives
> (/dev/vda) but used virtual scsi (/dev/sda) instead. (KVM on an old
> Cloudstack which didn't
> recognize the Debian version...
That might
On Tue, Oct 27, 2020 at 04:54:13PM +0100, Thomas Goirand wrote:
> Testing to start the OpenStack image (well, the "genericcloud" image), I
> couldn't login into it, because there isn't any metadata service configured
> in it.
This is incorrect. The package uses
Hi Thomas
On Sat, Sep 12, 2020 at 11:27:27PM +0200, Thomas Goirand wrote:
> 2/ Get the Octavia images pushed (as well as the raw image, without a
> wrapping format like tar...)
Please extract the things that actually need discussion, not
implementation.
The first one waits on responses from
On Thu, Sep 10, 2020 at 10:06:25PM -0700, Ross Vandegrift wrote:
> Format ideas
>
>
> I doubt that 2 days of video calls will be feasible. So we need some ideas
> for
> acceptable formats. How much time are you willing to commit? How should that
> time be scheduled? How should
Hi Ross
On Thu, Aug 13, 2020 at 11:02:55PM -0700, Ross Vandegrift wrote:
> Could it be the GPT partition table at the end of the disk? Even truncating
> off 1M breaks it. Nothing will use the copy at the start of the disk, I
> wonder
> what the point of it is.
Yes. GPT got a copy of it's
On Tue, Aug 11, 2020 at 10:47:20PM -0700, Ross Vandegrift wrote:
> I think 15:00UTC was good for everyone except me. If that's the best time for
> everyone else, and if someone takes over organizing, it'd be okay with me to
> reschedule.
I'm usually not able to make 1500. It's end of business
On Sun, Aug 09, 2020 at 06:57:05PM +0200, Bastian Blank wrote:
> Maybe someone can just implement that properly in our tool? The file
> is:
> https://salsa.debian.org/cloud-team/debian-cloud-images/-/blob/master/src/debian_cloud_images/images/public/image.py
> There are existing metho
Hi Thomas
On Fri, Aug 07, 2020 at 01:55:31PM +0200, Thomas Lange wrote:
> IMO we can easily provide raw uncompressed Openstack images for our
> users right now.
> Can't we just run a script on petterson after each release (not on the
> dailys) to untar the disk image, rename it (because it's
On Sun, Aug 02, 2020 at 12:49:43PM +0200, Thomas Goirand wrote:
> The last point release of Buster was released with cloud-init
> 20.2-2~deb10u1. So it doesn't make sense to keep 20.2-2~bpo10+1 in
> official backports anymore.
Does it's existence break anything? It makes sense to keep it,
On Fri, Jul 31, 2020 at 12:43:27AM +, Luca Filipozzi wrote:
> Doesn't archive.debian.org remain available for EOL releases?
Yes. It remains on a different mirror, not readily available. To
actually use it, you need to change several things, manually. Once the
signature key expires it get's
Hi Oleksandr
On Thu, Jul 30, 2020 at 09:49:01AM +, Oleksandr Sozanskyi wrote:
> Recently some Debian Jessie images were removed from Azure. The latest
> available Debian 8 image has version is 8.0.201901221 from Jan 22 2019. Can
> you tell if Debian 8 images which were built after Jan 22
On Tue, Jul 28, 2020 at 12:33:48PM -0400, Noah Meyerhans wrote:
> Jul 28 16:14:54 debian systemd-growfs[271]: Partition size 8455699968 is not
> a multiple of the blocksize 4096, ignoring 3584 bytes
That's normal, we may fix the initramfs grow stuff to make better
decisions.
> Jul 28 16:14:54
On Tue, Jul 28, 2020 at 03:40:14PM -0700, Noah Meyerhans wrote:
> Actually, the problem seems to have been caused by
> https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/192/
> Prior to that MR, we weren't using systemd-growfs at all.
Prior to that we did not have any grow
On Sat, Jul 25, 2020 at 09:07:46AM +0200, Renzo Davoli wrote:
> On Fri, Jul 24, 2020 at 12:37:09PM +0200, Renzo Davoli wrote:
> > > I am confident that it will not happen tomorrow as you
> > > have fixed the problem.
> ... this morning the directories 20200725-??? have been
On Tue, Jun 23, 2020 at 08:21:45AM -0700, Noah Meyerhans wrote:
> OK, that makes sense. Thanks. Can you go ahead and move awscli and
> python-botocore from
> https://salsa.debian.org/python-team/modules/awscli and
> https://salsa.debian.org/python-team/modules/python-botocore to the
> cloud-team
On Sat, Jun 20, 2020 at 12:53:01PM -0700, Noah Meyerhans wrote:
> On Sat, Jun 20, 2020 at 08:36:33PM +0200, Bastian Blank wrote:
> > > Thank you. I've forked both of these salsa projects into the cloud-team
> > > namespace. I'll prepare sid uploads adjusting the various pac
On Sat, Jun 20, 2020 at 10:49:24AM -0700, Noah Meyerhans wrote:
> On Thu, Jun 18, 2020 at 03:37:09PM +0900, TANIGUCHI Takaki wrote:
> > I agree your proposal. It's a good idea.
> Thank you. I've forked both of these salsa projects into the cloud-team
> namespace. I'll prepare sid uploads
On Tue, Jun 09, 2020 at 02:57:14PM +0200, Thomas Goirand wrote:
> In OpenStack, there's the possibility to rescue instances with a special
> image made for it.
You mean this? https://docs.openstack.org/nova/latest/user/rescue.html
According to the documentation, the default behaviour is to use
On Sat, Jun 06, 2020 at 07:16:59PM +0200, Bastian Blank wrote:
> That's exactly what this change does:
> https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/203
Now the remaining question is: GNU or BSD style checksum files?
GNU: "checksum filename"
- No i
On Mon, May 18, 2020 at 11:56:15AM +0200, Thomas Lange wrote:
> I've checked some other distributions in may 2020. They all use hex.
Well, they ship a single file for consumption by "sha512sum", which we
currently don't.
> Maybe provide base64 and hex in our manifest but also sha{265,512}sum
>
On Sat, Jun 06, 2020 at 11:16:42PM +1200, Andrew Ruthven wrote:
> Those are examples, and it notes that the formats available are
> configurable and none of them are specified as "must be available". The
> CLI docs also have a similar note.
> "Disk and container formats are configurable on a
On Wed, May 27, 2020 at 12:16:32PM +0100, kuLa wrote:
> Are you thinking about doing it within FAI or outside of it using new
> tool set for this?
Outside. FAI would in any case only create the directory tree, not the
filesystem is lives in or the image. So what it does would look the
same in
On Thu, Jun 04, 2020 at 01:06:29PM +0200, Thomas Lange wrote:
> >>>>> 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
Hi Marcin
On Sun, Apr 26, 2020 at 06:37:38PM +0100, Marcin Kulisz wrote:
> On 2020-04-22 16:35:25, Bastian Blank wrote:
> > What do you mean with "formating"? "GNU/Linux" is now irrelevant.
> But IMO a nice gesture to non Linux parts of our community and costs
Hi Thomas
I clearly does not help that you ignore one my questions several times.
Maybe you want to stop that.
On Wed, May 27, 2020 at 09:43:01AM +0200, Thomas Goirand wrote:
> On 5/26/20 9:26 PM, Bastian Blank wrote:
> > Please show me this existing 512MB image you are talk
On Wed, May 27, 2020 at 10:13:43AM +1200, Andrew Ruthven wrote:
> That may be the case, but not all *backends* can use qcow2 images.
Can you please show OpenStack documentation detailing this all? I fail
to find anything. And if the documentation does not tell clearly, I
have to assume that
On Sat, Jun 06, 2020 at 11:00:36AM +0200, Emmanuel Kasper wrote:
> Unfortunately the 250MB limit of artifacts prevent building a pipeline
> with multiple stages like
> create .box from raw -> test -> upload
> as I hit the artifact limit size between each of these stages.
Please take a deeper look
Hi
On Wed, Jun 03, 2020 at 10:40:05AM +0200, Martin Zobel-Helas wrote:
> We might need to explain this to Jonathan: Two or three years back the
> Debian Cloud team agreed on an internal policy during a face-to-face in
> Seattle that delegates should neither be employees of the cloud
> providers
fter the call to tasksel, waagent is not longer installed
and therefor not running. You can install waagent again afterwards.
I don't see a solution right now within the currently existing
constraints of dependencies and recommendations, with the way tasksel
uses apt.
Regards,
Bastian
--
Bastian Blank
B
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 for genriccloud
> images. It should be easy to set this to maybe 550M.
Sadly it is not that easy. A whole
On Tue, May 26, 2020 at 07:50:26PM -0700, Ross Vandegrift wrote:
> We'd either need to find the common requirements for all providers (eg AWS
> requires 256MiB free), or limit the reduction to the generic images.
Free, when and where? Our file-system grow stuff runs pretty early in
the boot
as artifact on Salsa. Maybe this log will
enlighten you how it is created and stored:
https://salsa.debian.org/cloud-admin-team/debian-cloud-images-daily/-/jobs/765786
Regards,
Bastian Blank
--
Spock: We suffered 23 casualties in that attack, Captain.
On Mon, May 25, 2020 at 02:21:48AM +0200, Thomas Goirand wrote:
> >> So I was wondering if we could:
> >> 1/ Make the resulting extracted disk smaller. That'd be done in FAI, and
> >> I have no idea how that would be done. Thomas, can you help, at least
> >> giving some pointers on how we could
On Sun, May 24, 2020 at 11:26:40PM +0200, Thomas Goirand wrote:
> Currently, our scripts are generating files named for example:
> debian-11-genericcloud-amd64-daily-20200524-273.tar.xz
No, they generate this one:
somehow:
- credativ:Debian:9:9.20200210.1
- Debian:debian-10:10:0.20200511.260
I did another publication run to restore them, so they are back now.
Regards,
Bastian
--
Bastian Blank
Berater
Telefon: +49 2166 9901-194
E-Mail: bastian.bl...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
On Fri, May 08, 2020 at 04:29:16PM -0400, Noah Meyerhans wrote:
> Consider the following simple case. I'm working on packaging
> amazon-ec2-utils, which I'd like to add to the default installation once
> it's available. To do that today, I'll need to add release specific
> configs to
On Tue, May 05, 2020 at 04:18:36PM -0400, Noah Meyerhans wrote:
> By fallback datasource, you mean "None"?
Yes.
> We could always reintroduce the use of debconf for datasource selection,
> and avoid depending on ds-identify at all. The nice thing about that is
> that we could then pre-fill that
On Fri, May 08, 2020 at 04:29:16PM -0400, Noah Meyerhans wrote:
> Does this seem sane? Any other ideas?
Nope, it is not really. The daily and release projects needs to use
current tools, without it diverging between the branches.
So we need to split tools and config space then and solve the
Package: cloud-init
Version: 20.1-2
Severity: wishlist
cloud-init does some basic tasks, like
- network config (currently completely shadowed by our own),
- ssh host keys.
I think the most sensible setup would always enable cloud-init, and if
it only runs with the fallback datasource.
Currently
Hi Thomas
On Fri, Apr 03, 2020 at 11:04:06PM +0200, Thomas Goirand wrote:
> As much as I remember, there was a consensus of everyone against one
> (ie: Bastian himself) that it was ok to build a specific Octavia image.
> At the end of the discussion, either Bastian finally agreed or gave up
>
On Wed, Apr 22, 2020 at 02:19:48PM -0400, list+deb...@dishaw.org wrote:
> It appears that a Debian AMI released by the Debian cloud team does not exist
> on AWS GovCloud. While several options are provided in the AWS GovCloud
> Marketplace by commercial vendors, having an AMI provided by the
On Mon, Apr 20, 2020 at 07:57:19PM -0400, Noah Meyerhans wrote:
> Product title: For older releases, the title is listed as (e.g.) "Debian
> GNU/Linux 9 (Stretch)". For buster, it is "Debian 10 Buster". I prefer
> the formating used for stretch, and would like to update buster to
> match.
What
Package: cloud-init
Version: 20.1-X
Severity: important
Currently running debian/rules clean from git repository fails:
| % ./debian/rules clean
| py3versions: no X-Python3-Version in control file, using supported versions
| dh clean --with python3,systemd --buildsystem pybuild
|
On Fri, Apr 03, 2020 at 09:32:01AM +0200, Emmanuel Kasper wrote:
> IIRC Digital Ocean and AWS have it, but for instance Vultr does not.
- DO
- AWS
- Azure
- Google on request
(https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances)
Bastian
--
Vulcans
Control: reassign -1 debian-cloud-images
Control: severity -1 minor
Control: tags -1 ipv6,help
Hi Bas
On Fri, Mar 20, 2020 at 09:00:08AM +0100, Bas Zoetekouw wrote:
> On these machines, ipv6 is disabled by setting
> /proc/sys/net/ipv6/conf/all/disable_ipv6 to 1. This causes the network
> to
Package: cloud-init
Version: 20.1-1
Severity: serious
cloud-init 20.1-1 fails to provision Azure:
| 2020-03-19 14:31:48,840 - util.py[DEBUG]: Running module disk_setup () failed
| Traceback (most recent call last):
| File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 848, in
On Sat, Mar 07, 2020 at 01:40:53AM +0100, Marco d'Itri wrote:
> Nowadays (since Debian 10) systemd can automatically grow file systems
> and swap partitions just by adding the x-systemd.growfs flag to fstab.
Thanks for letting us know.
I added the flag and as announced it works fine:
Hi folks
Next step in our quest to have usable AWS accounts is user handling.
I looked into the available options. Those are local account or
federation via SAML or OpenID Connect. Federation needs both an
external user source and some glue, due to the internal handling in AWS.
Local users
Control: severity -1 important
On Tue, Jan 28, 2020 at 09:25:28PM +0100, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package failed the piuparts
> upgrade test because dpkg detected a conffile as being modified and then
> prompted the user for an action. As there is no
Hi
On Thu, Feb 06, 2020 at 08:10:52PM +0100, Andreas Tille wrote:
> [Sorry for the delay. I'm not reading the list and just found it now in the
> archive.]
I sent the original to andr...@an3as.eu too. It was properly received
by mail.an3as.eu[88.198.124.37]:25, replying with
"250 OK
On Fri, Jan 31, 2020 at 08:59:36PM +0100, Andreas Tille wrote:
> I admit I'm not educated about those technical details. All I know is
> that time for blends.debian.net is running out today. A simple answer
> like: "We can not provide any VM to replace blends.debian.net" or "We
> could provide
On Wed, Oct 16, 2019 at 06:32:31PM +0200, Thomas Lange wrote:
> When creating the generic image using
> files/etc/apt/sources.list.d/backports.list/BACKPORTS
This file stays in this image.
> files/etc/apt/sources.list/BUSTER_BUILD
This file is overriden later by:
On Mon, Oct 14, 2019 at 05:47:04PM +0200, Thomas Goirand wrote:
> The /etc/hosts isn't getting updated by cloud-init.
> Normally, the hostname of the VM should appear there
> after boot.
Please explain what the /etc/hosts update fixes. All the environments
do DNS for exactly this name.
Bastian
On Mon, Oct 14, 2019 at 07:13:34PM +0200, Thomas Goirand wrote:
> On 10/14/19 5:58 PM, Bastian Blank wrote:
> > Which exact image did you use? What is the log output?
> Both the daily generic and genericcloud image have the issue.
> Logs attached.
The log shows:
> 2019-
Control: reassign -1 cloud-init
On Mon, Oct 14, 2019 at 05:47:04PM +0200, Thomas Goirand wrote:
> The /etc/hosts isn't getting updated by cloud-init.
> Normally, the hostname of the VM should appear there
> after boot.
This is handled by cloud-init.
Which exact image did you use? What is the
Hi
On Thu, Sep 26, 2019 at 01:11:56PM +0900, NOKUBI Takatsugu wrote:
> I think it is not helpful, is this description is intentional things?
It's a bug in the upload script.
It is reported here
https://salsa.debian.org/cloud-team/debian-cloud-images/issues/10
but not yet fixed.
Regards,
Moin
If no-one shouts I will do the first release of Buster for AWS with both
amd64 and arm64 tomorrow. Azure needs to be done anyway.
Bastian
--
Fascinating, a totally parochial attitude.
-- Spock, "Metamorphosis", stardate 3219.8
Hi Thomas
I don't see how your response relates to my original question. This is
the second time in a short while you decided to work this way.
On Sun, Sep 01, 2019 at 04:21:23PM +0200, Thomas Goirand wrote:
> If I understand well, you're moving ahead with having all done by the
> Salsa CI.
Hi folks
As mentioned during the last meeting, I would like to move the daily
builds out of the main debian-cloud-images project. The new project
reponsible for them would exist in a different group, so we don't longer
need to guard access to the main cloud-team group that strict.
Disadvantages
Moin
Do we have a list of stuff that runs on our old AWS account? As we need
to migrate all of this to our new engineering account, it would be nice
to actually know what runs there. It would be even better if we know
how this is all setup.
Regards,
Bastian
--
Witch! Witch! They'll burn
Hi folks
A small update on the current state.
On Fri, Jul 05, 2019 at 11:12:53AM +0200, Bastian Blank wrote:
> For AWS this change could not be finished in time for the Buster
> release. We have contracts and accounts ready. However Amazon did not
> yet manage to associate this
Hi Sven
On Thu, Jun 27, 2019 at 02:38:53PM +0200, Sven Bartscher wrote:
> The specified network-config doesn't seem to have any actual effect on
> what actually happens when the system boots. From what I see,
> cloud-init generates a configuration file from my specified
> configuration in
On Tue, Aug 06, 2019 at 03:35:35PM +0200, Thomas Goirand wrote:
> On 8/6/19 10:30 AM, Bastian Blank wrote:
> > There is a "checksum" field. However I don't see what kind of checksum
> > this should be or what this checksum is calculated from (I uploaded a
> > qcow2)
On Mon, Aug 05, 2019 at 01:33:26PM +, Jeremy Stanley wrote:
> You mentioned Kubernetes (which I haven't really used so have yet to
> notice), but who else's "current" software encodes checksums in
> base64 besides the Kubernetes ecosystem?
ssh for example:
| 256
On Mon, Aug 05, 2019 at 10:07:46AM +0200, Thomas Goirand wrote:
> Unfortunately, OpenStack Glance only shows SHA512, not SHA3, so even if
> we do both, we must keep SHA2 512.
What does Glance show and how does this relate on what we use to allow
verification of the downloaded images?
My (old)
On Sun, Aug 04, 2019 at 10:05:32PM +0100, Chris Boot wrote:
> On 04/08/2019 17:29, Bastian Blank wrote:
> > Only one of them. And I would go directly to SHA3 for new stuff.
>
> Buster doesn't have any SHA3 tools in coreutils. While I don't have
> anything against calculat
On Sat, Aug 03, 2019 at 09:23:58PM +0100, Chris Boot wrote:
> Currently the build tools generate the raw image using FAI, then wrap it
> into a tarball. The tarball is then xz compressed outside
> debian-cloud-images in the GitLab CI job.
> Is there any reason to keep it that way? Why don't we
On Sat, Aug 03, 2019 at 03:06:39PM +0100, Chris Boot wrote:
> - Which checksums should we include? Our Apt repos use MD5 and SHA-256,
> and our ISOs use MD5, SHA-1, SHA-256 and SHA-512. I'd be inclined to
> suggest SHA-256 and SHA-512 only, personally.
Only one of them. And I would go directly
On Fri, Jul 12, 2019 at 03:34:14PM +0200, Laura Arjona Reina wrote:
> Feel free to commit there your review/update proposals for the values of
> those fields afterwards, or ping if you'd like us to provide the initial
> proposal.
I updated it a bit, added some comments.
Please provide a
Hi Laura
On Sat, Jul 06, 2019 at 08:49:49AM +0200, Laura Arjona Reina wrote:
> I think the best probably is that you open a collaborative pad or create
> a txt file in the "publicity" repo [1] where we can see the different
> fields we can tweak for each cloud provider (I guess we cannot
Hi folks
I'd would like some input on how to present Debian at some of the cloud
providers, namely Microsoft Azure and Amazon Web Services.
The current state:
On Azure we never really made an effort on how to present it. The
Marketplace page is pretty empty:
Hi folks
I would like to share with you the state of our new cloud provider
relations and accounts for Debian.
At the last cloud team sprint, we decided to switch how we want to
handle contractual relations with cloud providers. In the past they
where either held by individuals (for AWS) or
Hi Zach
On Wed, Jul 03, 2019 at 09:53:07AM -0700, Zach Marano wrote:
> I noticed that the cloud kernel build in Buster/Sid does not include an RTC
> module (or rather it was stripped out). We use this to set the kernel clock
> to the host clock after VM migration events. Can we get this put back
Hi
Do we want to release ppc64el cloud images with Buster?
They work for me but only got minimal test coverage.
Regards,
Bastian
--
Our way is peace.
-- Septimus, the Son Worshiper, "Bread and Circuses",
stardate 4040.7.
Hi folks
We have the famous random stall problem in our cloud images as well.
cloud-init and our other provisioning tools will generate ssh keys and
need randomness for that, so block for several minutes on initial boot.[1]
For now we have two recipes against this:
- amd64 trusts RDRAND, but the
Hi
On Thu, May 02, 2019 at 07:43:15PM +0200, Bastian Blank wrote:
> On Thu, May 02, 2019 at 04:39:58PM +0200, Bastian Blank wrote:
> > Publisher Unique Name (PublisherId): Debian
> > Display Name: Debian
> > Owner Email: debian-cloud-accounts+az...@spi-inc.org
Our Azure p
Hi Arthur
Welcome and gratulations for your selection as GSoC student.
I have to appologize for disappearing a bit too much lately.
Regards,
Bastian
--
Deflector shields just came on, Captain.
On Thu, May 02, 2019 at 04:39:58PM +0200, Bastian Blank wrote:
> Publisher Unique Name (PublisherId): Debian
> Display Name: Debian
> Owner Email: debian-cloud-accounts+az...@spi-inc.org
The MPN ID is 5432502, still unverified though.
Regards,
Bastian
--
I have never understood t
Hi
On Wed, Apr 24, 2019 at 05:27:31PM -0400, Jimmy Kaplowitz wrote:
> Sorry for the slow replies and preparations on my end. The info you need
> to create the Azure Marketplace account is:
Please use:
Publisher Unique Name (PublisherId): Debian
Display Name: Debian
Owner Email:
Hi
On Wed, Apr 24, 2019 at 09:46:36PM +0200, Bastian Blank wrote:
> On Wed, Apr 24, 2019 at 03:30:20PM -0400, Jimmy Kaplowitz wrote:
> > Next steps for AWS: Anyone who will be doing the AWS work can feel free
> > to create the AWS accounts on Debian & SPI's behalf using the n
Hi
On Wed, Apr 24, 2019 at 09:46:36PM +0200, Bastian Blank wrote:
> I can do that, if I can find zobel.
I was unable to get hold of zobel this week.
Regards,
Bastian
--
The best diplomat I know is a fully activated phaser bank.
-- Scotty
On Wed, Apr 24, 2019 at 04:12:25PM -0400, Jimmy Kaplowitz wrote:
> Did you at least verify that the address extensions (plus-addressing)
> work okay on the SPI side, since you need them for the multiple AWS and
> Azure accounts? They seem to work from what I can tell.
It does not work on the
Hi Jimmy
On Wed, Apr 24, 2019 at 03:30:20PM -0400, Jimmy Kaplowitz wrote:
> Next steps for Azure: I have a meeting in a few minutes but I will reply
> to Stephen Zarkos's email within the next 1-2h to unblock Azure.
Thanks
> Next steps for AWS: Anyone who will be doing the AWS work can feel
On Wed, Apr 03, 2019 at 08:54:58AM +, Kenn Leth Hansen wrote:
> I've discovered the CloudStack datasource causes cloud-init to wait for 120
> seconds before continuing to the next datasource if no service is responding
> on port 80 on the DHCP server address. As I am using an Ec2-style
On Fri, Jan 25, 2019 at 02:56:53PM +0100, Bastian Blank wrote:
> Currently the legacy Azure and at least some of the OpenStack images
> install locales-all.
And actually all the other images don't install any of the locales
packages.
Regards,
Bastian
--
Our way is
I implemented it a bit different now:[1]
- Introducing generic, with a full kernel package, usable on all
openstack targets and a lot more.
- Introducing genericcloud, with a cloud kernel package.
Regards,
Bastian
[1]: https://salsa.debian.org/cloud-team/debian-cloud-images/merge_requests/78
Hi
On Sun, Apr 07, 2019 at 01:49:59PM -0400, Jimmy Kaplowitz wrote:
> I or another SPI debit card holder can be involved as necessary to get
> past "you must provide a debit card" hurdles, assuming my email archives
> already show DPL approval or assuming the DPL gives his approval.
I don't
Hi Jimmy
On Sun, Apr 07, 2019 at 01:49:59PM -0400, Jimmy Kaplowitz wrote:
> Please send any concerns by end of day UTC on Friday, April 12. In the
> absence of any blocking concerns by then, I will reply here that evening
> (Montreal time) or weekend giving the all-clear for whoever is going to
>
Hi
On Sun, Apr 07, 2019 at 11:10:45PM +0200, Bastian Blank wrote:
> > I've found the relevant part of our puppet config and it's clearly
> > straightforward, so I can get this address added to SPI's mail config as
> > soon as Debian confirms which debian.org addresses (r
101 - 200 of 314 matches
Mail list logo
