On Wed, Aug 11, 2021 at 08:11:27PM -0600, Ross Vandegrift wrote:
> > > 2. I will implement a temporary change to our bullseye images to revert
> > > the
> > >sudoers file to use the old syntax that cloud-init will detect.
> >
> > This is implemented by
> >
On Wed, Aug 11, 2021 at 02:05:39PM -0700, Noah Meyerhans wrote:
> 2. I will implement a temporary change to our bullseye images to revert the
>sudoers file to use the old syntax that cloud-init will detect.
This is implemented by
https://salsa.debian.org/cloud-team/debian-cloud-
On Sat, Aug 07, 2021 at 08:30:17PM -0600, Ross Vandegrift wrote:
> > > > In the sudoers file there is a duplicate includedir
> > > > statement; at the end of the file you will find the following contents:
> > > >
> > > > """
> > > > # See sudoers(5) for more information on "@include" directives:
Control: severity -1 important
Please see https://www.debian.org/Bugs/Developer#severities
On Wed, Jul 28, 2021 at 05:22:43PM +0200, Thomas Goirand wrote:
> After spawning a VM, it takes a long time to get networking (output from
> the console):
>
> cloud-init[281]: Cloud-init v. 20.2 running
On Fri, Jul 23, 2021 at 10:51:57AM +0200, Bastian Blank wrote:
> > In commit 522055bf, I added
> > config_space/files/etc/cloud/cloud.cfg.d/01_debian_cloud.cfg/GENERICCLOUD
> > and
> > config_space/files/etc/cloud/cloud.cfg.d/01_debian_cloud.cfg/GENERIC, in
>
> Why did you decide that you can do
On Thu, Jul 22, 2021 at 10:51:19PM +0200, Thomas Goirand wrote:
> >> In commit 522055bf, I added
> >> config_space/files/etc/cloud/cloud.cfg.d/01_debian_cloud.cfg/GENERICCLOUD
> >> and
> >> config_space/files/etc/cloud/cloud.cfg.d/01_debian_cloud.cfg/GENERIC, in
> >> the hope to get
On Thu, Jul 22, 2021 at 11:15:23AM +0200, Thomas Goirand wrote:
> In commit 522055bf, I added
> config_space/files/etc/cloud/cloud.cfg.d/01_debian_cloud.cfg/GENERICCLOUD
> and
> config_space/files/etc/cloud/cloud.cfg.d/01_debian_cloud.cfg/GENERIC, in
> the hope to get
Package: amazon-ec2-utils
Version: 1.3+git20200518-2
Severity: normal
The primary purpose of the amazon-ec2-utils package is to install some udev
rules to configure various hardware conveniences. For example, these
install symlinks providing compatibility symlinks for block devices such
that
Control: severity -1 wishlist
Control: forwarded -1 https://github.com/aws/aws-cli/issues/6186
awscli v2 remains quite difficult to package, but it seems that upstream
is looking to address this. See
https://github.com/aws/aws-cli/issues/6186 for details and tracking.
We'll continue to track
On Thu, Jun 17, 2021 at 05:54:03AM +, Yuhua Zou wrote:
>The version of package cloud-init in official repository of Debian 10.9 is
>20.2.
>This version 20.2 is far behind the latest released version 21.2.
>Please check [1]https://github.com/canonical/cloud-init
>
>With
On Tue, Jun 08, 2021 at 08:39:45AM +0200, Bastian Blank wrote:
> docker-machine is a product by Docker upstream, but is not longer
> developed, without any replacement. Currently GitLab upstream makes
> heavy use of it, so I have no idea what they are going to do about it.
> But we don't need to
On Mon, Jun 07, 2021 at 11:00:42PM +0200, Vladimir Tiukhtin wrote:
> I use "ca-certs" to supply additional certificates. With just one certiticate
> everything
> works as expected, however when provided more than one, cloud-init adds them
> into a single
> file which causes "openssl rehash" to
On Wed, Jun 02, 2021 at 09:45:05AM -0700, Ross Vandegrift wrote:
> > Let us start with a discussion where the sdk itself should be
> > team-maintained - cloud or med or java?
> >
> > Personally, I'd opt for Java, since this seems like to be the core
> > challenge for us. If this drags in other
On Tue, Jun 01, 2021 at 01:03:11PM +0200, Steffen Möller wrote:
> > > The biggest tasks would be to package the SDK of AWS [0] (which would also
> > > benefit igv) and of Microsoft Azure [1]. We would also need to package
> > > Apache Ignite [2].
> > > After the freeze I shall discuss this on the
On Sun, May 23, 2021 at 10:08:24AM -0400, Tong Sun wrote:
> I know there are many reasons not to use Debian testing in production.
> But now that Bullseye is in freezing, I think it is time for early adapters to
> start testing it in Azure.
>
> I for one am willing to do that. So I propose that
I recently finished adding buster-backports AMIs to the AWS Marketplace
along with the ѕtandard buster AMIs. These AMIs are basically іdentical
to the buster AMIs except that they use the buster-backports kernel
(currently Linux 5.10).
These may be useful for you if you require features only
On Mon, May 17, 2021 at 12:46:20PM -0700, Jeremy Drake wrote:
>
>
> On Mon, 17 May 2021, Noah Meyerhans wrote:
>
> > They work, they just take a long, long time to boot. Figure about 10-15
> > minutes or so.
>
> Thanks, it did eventually boot. It's hard to
On Mon, May 17, 2021 at 11:35:42AM -0700, Jeremy Drake wrote:
> I am attempting to launch a c6g.metal instance in us-west-2, but it hangs up
> and never seems to boot, with:
> ami-0a773686fc288ee18
> ami-054ec2aaf512d49c5
> ami-0bb3ac1447646faf5
They work, they just take a long, long time to
On Fri, May 14, 2021 at 07:43:05PM +0200, Emmanuel Kasper wrote:
> > i noticed that the bullseye64 Vagrant libvirt box does not use
> > predictable network interface names. It is explicitely disabled with
> > 'net.ifnames=0 biosdevnames=0' in the grub configuration. Is there a
> > special reason
On Thu, May 13, 2021 at 10:07:13PM -0700, Ross Vandegrift wrote:
> nm-cloud-setup uses systemd-networkd, but offers support for ipv6 prefix
> delegation, secondary ips, and per-interface policy routing. It provides a
> set
> of systemd services so that administrators can modularly enable and
On Tue, May 11, 2021 at 12:44:49PM +0200, Dick Visser wrote:
> Then we sort this list by CreationDate and pick the last one, meaning
> we always use the latest image, which is released roughly every month.
> This worked well - so far.
> I just noticed that my dev environment was running on a fancy
On Mon, May 10, 2021 at 09:00:34PM +0200, Moritz Mühlenhoff wrote:
> > Hi, since this package was brought into Debian in ~2018, there have been
> > several transformations in the GCE guest software stack and thus the
> > current landscape is very different. Google doesn't actually maintain the
> >
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.
Definitely an
Hi Thomas.
> Since Waldi, unilaterally, decided to close again the Octavia image
> patch for a 2nd time (for new reasons he didn't tell since we met
> Boston... yeah, just a new reason he found out!), I wonder where the
> cloud team would advise that I upload my work. It doesn't seem that
>
On Tue, Apr 20, 2021 at 10:30:04PM +0100, Jelmer Vernooij wrote:
> > Did you ask the DPL for funding this?
> Yeah, there's an ongoing thread - though it would be ideal if this was
> part of an ongoing GCP billing account directly associated with Debian
> (and even nicer if Google sponsored it!)
On Wed, Apr 14, 2021 at 10:36:27PM -0700, Ross Vandegrift wrote:
> Stable Cloud Images for Bullseye (stable)
> -
>
> The Debian Project will release it's new stable release 11 (code name
> Bullseye) along with images for various cloud providers. Images
On Wed, Apr 14, 2021 at 10:36:27PM -0700, Ross Vandegrift wrote:
> The Debian Project will release it's new stable release 11 (code name
> Bullseye) along with images for various cloud providers. Images will
nit: We don't typically capitalize the release codename in this context.
> * when
On Thu, Apr 08, 2021 at 11:01:26PM +0200, Bastian Blank 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
On Thu, Apr 08, 2021 at 04:32:37PM +, Jarosław Wygoda wrote:
>I tried to add complete key on debian 10 and it turns out it requires
>gnupg. Here's a relevant cloud-init config and error.
>apt:
> preserve_sources_list: true
> sources:
> docker.list:
>
On Mon, Mar 22, 2021 at 01:52:11PM -0400, Theodore Ts'o wrote:
> Perhaps it would make sense to make an image for Bullseye in
> debian-cloud-testing, so it doesn't accidentally get picked up and
> used in production environments before Bullseye gets released as
> Debian Stable?
The situation is
Package: cloud-init
Version: 20.4-1
Severity: grave
Tags: security upstream patch
Justification: user security hole
X-Debbugs-Cc: Debian Security Team
cloud-init has the ability to generate and set a randomized password for
system users. This functionality is enabled at runtime by passing
We should be publishing release images for OpenStack and at least two
commercial cloud services approximately simultaneously with the bullseye
release. I'd like to include a short notice about cloud image
availability in the release notes, but it's not entirely clear where it
should go.
On Fri, Feb 26, 2021 at 07:41:28AM -0500, David H. Rhodes Clymer wrote:
> I have been building my own AMI for use at AWS because reasons.
> However, in order to make my images acceptable, I end up having to
> install the linux-image-3.16.0-.. image from Debian 8 (I think?). Any
> other kernel I
On Tue, Jan 26, 2021 at 07:32:35AM -0800, Noah Meyerhans wrote:
> Unfortunately, I believe it's too late to update botocore in bullseye. 1.19
> seems to break compatibility with 1.17, meaning it would require a transition.
> Per the bullseye release policy and timeline [1], tr
On Tue, Jan 26, 2021 at 01:33:18PM +0300, Alexander Gerasiov wrote:
> New version (1.19) of python-botocore were releases last fall and
> brought some new API features we lack off.
>
> Would you mind to update package in bullseye?
Unfortunately, I believe it's too late to update botocore in
On Mon, Jan 04, 2021 at 09:53:52AM +0900, Charles Plessy wrote:
> I am used to start building Singularity (https://sylabs.io/) images
> starting from Docker images, but the Debian images on Docker have not
> been updated for a while...
The Docker images should be actively maintained. CCing
Control: tags -1 + moreinfo
On Sun, Nov 29, 2020 at 03:04:20PM -0300, eingousef wrote:
> I followed the documentation here :
> https://www.scaleway.com/en/docs/object-storage-with-aws-cli/
These have you installing python packages using pip. That's not part of
Debian. What are the exact steps
I just uploaded cloud-init 20.4 to unstable. It'll be included in the
nightly sid cloud image builds that we publish in the next day or so.
If you can, please try launching one of them in whatever cloud
environment you can, with whatever bits of userdata configuration you
can throw at them. File
On Wed, Oct 28, 2020 at 04:58:55PM -0700, Paul Graydon wrote:
> Okay, I'm getting confused here. These restrictions don't seem to match
> with the previous message, so I'm assuming I misunderstood something. I
> think this may hinge around what is meant by "official" images.
Official images are
On Tue, Oct 27, 2020 at 12:00:54PM -0700, Paul Graydon wrote:
> > If you want to build derivitive images that are based on our
> > configuration and associated tooling but have additional software
> > installed, you are free to use our tooling and configuration as a
> > starting point. This is,
On Tue, Oct 27, 2020 at 09:58:05AM -0700, Paul Graydon wrote:
> > If you are considering installations directly from the Deb package, how
> > do you consider the client software update procedure when the virtual
> > machine has been running for a while? Snapd has a built-in mechanism for
> >
Control: block -1 by 972721
> File "/usr/lib/python3/dist-packages/httpretty/core.py", line 438, in
> makefile
> if t.isAlive():
> AttributeError: 'Thread' object has no attribute 'isAlive'
This looks like #972721
I don't think we need to do anything in python-boto to fix this.
On Tue, Oct 06, 2020 at 03:00:43PM +0200, Matteo Croce wrote:
> Also, the mailto link on https://image-finder.debian.net/provider/3
> doesn't work,
> it seems there are two extra slashes:
>
> mailto://debian-cloud@lists.debian.org;>
Reported as
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:
>
> error: symbol 'grub_file_filters' not found.
> Entering rescue mode...
> grub rescue>
>
> I see the error in the HyperV graphic console,
> I
I've confirmed that the Marketplace UI still doesn't let us enable t4g.*
and opened a support request with AWS to see if they can enable this for
us.
For now, use the AMIs listed at
https://wiki.debian.org/Cloud/AmazonEC2Image/Buster
On Thu, Oct 01, 2020 at 05:40:02PM -0500, Ryan Thoryk wrote:
> I've been wanting to run Debian on Amazon's new T4g instances, which utilize
> the ARM-based Graviton2 processor. The current AMI's don't appear to support
> this, and I assumed it would be fixed as part of the 10.6 update, which it
>
On Thu, Oct 01, 2020 at 05:16:36PM +0200, tkoeck wrote:
> is there an AMI image ID that is always the recent one?
>
> As far as I have seen the AMI image ID always changes for every
> subversion (e.g. Debian 10.0 to 10.1)?
>
> It would be interesting to have an AMI image ID which would always
>
I've looked at this a little more. From what I can tell, the dependency
on botocore v2 is really going to make this hard to package. We can't
simply update the botocore packages to version 2, since it is not
backwards compatible with v1. Existing packages that depend on botocore
would need to
On Wed, Sep 23, 2020 at 10:57:50AM -0400, Daniel Watkins wrote:
> cloud-init uses gnupg in two ways: directly, to fetch and export keys
> (when specified by ID, see [0]), and via apt-key to add keys to the system
> (whether specified via ID or in full, see [1]). (Even once we remove
> apt-key
On Sat, Sep 12, 2020 at 06:19:55AM +0200, Herbert Groot Jebbink wrote:
>It would be great if a wsl (windows subsystem for linux) image is added to
>the could images
>Something like [1]https://cloud-images.ubuntu.com/focal/current/
>Also a directory current or latest would be great,
On Tue, Sep 08, 2020 at 07:33:13PM +0100, Sudip Mukherjee wrote:
> > Short of communicating with a remote service, I'm not sure how we can
> > get more meaningful functional test coverage in this package, but it
> > would be nice to do so.
>
> There is also another "Restrictions: needs-internet"
On Tue, Sep 08, 2020 at 10:38:18AM +0100, Sudip Mukherjee wrote:
> The test done in the autopkgtest of 'awscli' does not provide
> significant test coverage and it should be marked with "Restrictions:
> superficial".
The current test merely invokes "/usr/bin/aws help". Is there any
actual value
On Wed, Sep 02, 2020 at 07:55:41PM +0200, Thomas Goirand wrote:
> We discussed it before, and I wasn't sure about the status of $subject
> in OpenStack. However, now I know. After this patch was merged (6 hours
> ago), OpenStack is now capable of providing instance metadata over IPv6:
>
>
A first take at this is at
https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/222
Also, at least for the cloud-team's image generation, we should probably
switch to using "source /etc/network/interfaces.d/*", similar to what
d-i does and ifupdown will do. It won't help in this case, because the
provider that encountered the problem is using some other tooling to
generate their
On Tue, Aug 18, 2020 at 08:46:01PM +0100, Adam D. Barratt wrote:
> > https://github.com/canonical/cloud-init/commit/a6faf3acef02bd8cd4d46ac9efeebf24b3f21d81
>
> I must admit that I'm slightly confused by that commit.
>
> The rationale is that the default file written by ifupdown uses
>
Package: cloud.debian.org
Severity: important
Tags: buster
User: cloud.debian@packages.debian.org
Usertags: aws image
Current buster images (release and daily) fail to boot on AWS arm64
bare-metal instance types, e.g. m6g.metal. The instance never reports as
healthy in the AWS instance
On Tue, Aug 11, 2020 at 06:42:24PM +0100, Phil Endecott wrote:
> I've just rebooted an AWS instance running buster and it
> has failed to restart, with the message "symbol 'grub_calloc'
> not found" shown on the console screenshot.
This situation has been encountered by at least one other person
I spent a little bit of time on this today. Here are my findings so
far.
First, awscli v2 depends on a python-botocore v2, which isn't yet
officially released upstream. It does seem reasonable to package it,
but the blast radius is large enough that it's important to be careful
to avoid
Control: tags -1 + confirmed
On Tue, Aug 04, 2020 at 12:31:53PM -0400, Roberto C. Sanchez wrote:
> It seems that a newer python3-botocore package (at least 1.13.8) is
> required with newer versions of awscli. References:
Confirmed that it doesn't work with the version in buster. It doesn't
On Sun, Aug 02, 2020 at 05:48:32PM +0200, Thomas Goirand wrote:
> > It makes sense to keep it, because
> > updating packages to test newer releases is easier then uploading new
> > ones.
>
> Do you mean we will probably upload a newer version of cloud-init to
> buster-backports? If so, ok, it
Our daily image builds include this fix as of yesterday. I've confirmed
that it resolves the issue there.
I'll close this bug once we've published "release" images containing the
fix, which should occur with the buster update scheduled for this
weekend.
noah
On Thu, Jul 30, 2020 at 11:39:13PM +0200, Bastian Blank wrote:
> > IMO we should not be taking down published images except in cases where
> > we need to for some compelling reason like legal obligations. Doing so
> > risks confusion for our users, or worse, outright breakage, and that
> > leads
On Thu, Jul 30, 2020 at 10:12:54PM +0200, Franck Hamelin wrote:
>
> Installation the amazon way is easy but probably not in line with the idea of
> Debian packaging system. So my question is : what are the plan for AWS CLI V2
> on Debian ?
>
You're the second one to ask about this recently,
On Thu, Jul 30, 2020 at 09:08:15PM +0200, Geert Stappers wrote:
> > Thank you for information Bastian.
> > I understand that there will be no new Debian 8 cloud images releases
> > but is there any chance that previous cloud images releases for Debian 8
> > will be available in Azure for some
On Wed, Jul 29, 2020 at 08:04:54AM +0200, Bastian Blank wrote:
> | # /run/systemd/generator/systemd-growfs@-.service
> | # Automatically generated by systemd-fstab-generator
> |
> | [Unit]
> | BindsTo=%i.mount
> | After=%i.mount
> | Before=shutdown.target local-fs.target
>
> So it is an artefact
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.
I've confirmed impact on amd64 instances as well as the arm64 instances
on which originally observed it. It
Having done a bit of testing, this definitely seems to be a regression.
I've launched 63 instances of the 10.3 AMI in us-east-1
(ami-031d1abcdcbbfbd8f) and 63 of the current 10.4 AMI
(ami-0bb15d03913335eae) on a variety of 6g arm64 instance types. Exacly
zero of the 10.3 launches ended up in
Package: cloud.debian.org
Severity: important
User: cloud.debian@packages.debian.org
Usertags: aws image
Testing the current buster releases for [mcr]6gd.* instance type support
reveals an issue that leads the instances to boot to "degraded" state in
systemd. The failing unit is
On Mon, Jul 27, 2020 at 01:37:14PM +0100, Steve McIntyre wrote:
> >Recent directories in https://cloud.debian.org/images/cloud/buster/daily/
> >became inaccessible. E.g.
> >
> > https://cloud.debian.org/images/cloud/buster/daily/20200717-330/
> >
> >still works, but
>
> Scratchpad/napkin suggestions, needs ipv6 routing:
>
> auto $INTERFACE
> allow-hotplug $INTERFACE
>
> iface $INTERFACE inet dhcp
> post-up ip route add default via $GATEWAY dev $DEVICE table $TABLE
> post-up ip route add $CIDR dev $DEVICE proto kernel scope link src
Control: tags -1 + moreinfo
> The buster arm64 images in us-east-2 don't seem to come online - ping and ssh
> fail. The ec2 status checks pass, but take unusually long to get there. I
> tried a1 and c6g instances. There's nothing in the system log output, and no
> screenshots on arm64.
>
> I
Control: tags -1 + pending
> I think it's reasonable to add a check in
> /usr/local/sbin/inet6-ifup-helper for future revisions of the stretch
> AMI to exit successfully if IPv6 is disabled on $IFACE.
We recently merged some changes that will do this on newly launched
instances. It won't help
On Thu, Jul 09, 2020 at 12:09:44PM +0200, Martin Olsson wrote:
>Severity: major
JFYI, "major" is not a valid severity. The complete list of severities
is listed at https://www.debian.org/Bugs/Developer#severities In the
case of this bug, since the behavior is only triggered by customization
On Sat, Jul 04, 2020 at 01:20:05PM +0900, Hideki Yamane wrote:
> Just a question, is there any plan to provide awscli ver.2?
Nothing firm. It contains quite a few breaking changes from v1, so care
should be taken when updating to it. v1 still receives bug fixes and
updates to support AWS API
On Wed, Jul 01, 2020 at 12:56:17PM +0100, Adam D. Barratt wrote:
> > Let's try to finally get something done with this cloud-init update.
> > The request is to update to upstream version 20.2 in buster. This
> > version is currently in both testing and buster-backports. It has
> > been tested by
Control: reassign -1 general
On Tue, Mar 26, 2019 at 12:25:12PM +0100, Lucas Nussbaum wrote:
> On https://hub.docker.com/_/debian, there's:
>
> > Where to file issues:
> > https://github.com/debuerreotype/docker-debian-artifacts/issues
>
> Are those official images? I'm surprised by official
Hi! On behalf of the Debian cloud team, I want to let you know that we
intend to continue publishing updates to our stretch VM images on
various popular cloud services after the handoff to the LTS team. This
includes Amazon EC2, Microsoft Azure, and OpenStack. We understand that
Google will
On Tue, Jun 23, 2020 at 08:35:53PM -0300, Emmanuel Arias wrote:
> > Please don't. Please ask them to be moved properly by opening a ticket
> > if you don't find another way.
>
> I agree with Bastian, This is not a fork itself, Is the same project moving to
> another team.
Yes.
> IMO, If we
On Tue, Jun 23, 2020 at 12:40:38PM +, Thomas Stringer wrote:
>It looks like the azure-cli is also not part of the Debian Cloud Team. It
>seems like it should also be under the cloud-team namespace, right?
Yes, it's also currently maintained by the python modules team. It
makes sense
On Sat, Jun 20, 2020 at 08:36:33PM +0200, Bastian Blank 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 adjusting the various packaging
> > metadata in the next day or two.
>
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 adjusting the various packaging
metadata in the next day or two.
noah
As discussed in last week's team meeting, I have been testing cloud-init
20.2-2~bpo10+1 with the goal of gathering confidence to request that the
stable release term permit us to update that package buster. My focus
has been on Amazon EC2, as Azure and OpenStack are being tested by
others.
I've
Hello. I'd like to propose moving the awscli and python-botocore
packages from DPMT maintenance to cloud-team maintenance. Both of these
packages are specifically focused on cloud services, and I believe that
maintaining them under the cloud-team's umbrella will help us further
the cloud-team's
On Sun, Jun 14, 2020 at 09:45:36PM -0700, Ross Vandegrift wrote:
> > This feels like a bug in the debian cloud image, but I could certainly be
> > doing something wrong here. The first thing I noticed is that the version
> > of cloud-init on the genericcloud image is ~2 years old (version 18.3).
On Thu, Jun 11, 2020 at 01:54:37PM -0700, Zach Marano wrote:
>If the consensus is that we should continue supporting Debian 9 through
>LTS, then GCE will as well. Do we have information about the mechanism for
>updates? Is it going to just be part of the regular stretch repos or is
>
On Mon, Jun 08, 2020 at 10:33:43PM +0200, Thomas Goirand wrote:
> > 1900 UTC works for me. The next meeing will be coming right up, on June
> > 10, right?
>
> This week, on Wednesday, is going to be difficult for me. I'll probably
> be on the road back from Geneva, then there's some network
On Mon, Jun 08, 2020 at 10:33:18AM +0200, Thomas Lange wrote:
> > 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.
Done. I also added a small bit of text to
> 1. Security, not from cloud providers themselves, but from other cloud
> customers via sidechannel attacks such as meltdown. The risk is small,
> but IMO greater than the risk of the cloud provider itself doing
> anything nefarious. (Keep in mind that all major cloud providers have
> taken
On Sat, Jun 06, 2020 at 08:28:30PM +0900, Charles Plessy wrote:
> > AFAIK there is general consensus amongst us that we want the cloud
> > images to be built on the Debian infrastructure, not on the cloud
> > provider infrastructure.
>
> just for the record, here is what you added:
>
> * '''E.
On Thu, Jun 04, 2020 at 11:16:10AM +0200, Thomas Goirand wrote:
> I very much prefer a conversation along the line of "we have no choice,
> there's nobody else" rather than denying any possible conflict of
> interest. Even more, if we were to say: let's break the rule
> temporarily, until we have
On Wed, Jun 03, 2020 at 11:22:26PM +, Luca Filipozzi wrote:
> > > We're afraid of conflict of interest. There's been multiple times where
> > > we saw it could happen, and by having the delegates not involved with a
> > > provider, we're hoping to reduce that risk.
> >
> > Can you cite a
On Thu, Jun 04, 2020 at 02:41:40AM +0200, Thomas Goirand wrote:
> >> We're afraid of conflict of interest. There's been multiple times where
> >> we saw it could happen, and by having the delegates not involved with a
> >> provider, we're hoping to reduce that risk.
> >
> > Can you cite a
On Thu, Jun 04, 2020 at 12:42:47AM +0200, Thomas Goirand wrote:
> > IMHO, this requirement makes more difficult to find as someone from the
> > people, as AFAIK many of us are working in a way for a cloud provider,
> > or a partner.
> >
> > What are we actually afraid of here ? As far as the
The amazon-ec2-utils package is currently in the NEW queue and will
provide the necessary tools for examining the instance NVME
configuration and creating the requested links.
Details of that package are tracked in the ITP at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959066.
On Fri, May 29, 2020 at 05:14:39PM +, Brian King wrote:
> That is correct; in Rackspace cloud, DNS is set 'automatically' via
> cloud-init and the config-drive's network-data.json on Ubuntu and the
> RHEL family distros (RHEL, Fedora, CentOS) using their stock Openstack
> images.
>
> >> I
On Sat, May 23, 2020 at 11:50:10PM +0200, Eric Kom wrote:
>Can any one assist or direct me with the login details for:
>
>debian-10-genericcloud-amd64-20200511-260.qcow2
>
>I have booted but can’t login.
>
>Tried admin, root & Debian with and without password.
There are no
On Tue, May 19, 2020 at 10:08:53AM +0300, Alexander Gerasiov wrote:
> > The cloud team is now maintaining the python-boto source package. I
> > think it similar makes sense for the team to maintain python-boto3 as
> > well. Do people agree that this makes sense?
> I don't mind.
OK, given that
On Fri, Apr 03, 2020 at 03:54:34PM +0200, Bastian Blank wrote:
> 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
(Updating the CC list)
On Tue, Mar 31, 2020 at 11:40:27AM -0500, Eric Evans wrote:
> > > If it's going to move, might I suggest maintaining it within the
> > > cloud-team instead? Among other things, the cloud team has an interest
> > > in providing feature updates to cloud-oriented packages,
101 - 200 of 348 matches
Mail list logo
