On Wed, Jan 08, 2020 at 07:18:33PM -0500, Theodore Y. Ts'o wrote:
> I was under the impression that Amazon provided virtio-rng support for
> its VM's? Or does that not apply for their arm64 Vm's? If they do
> support virtio-rng, it might just be an issue of building the cloud
> kernel with that
On Wed, Jan 08, 2020 at 07:18:33PM -0500, Theodore Y. Ts'o wrote:
> Another approach would be to cherry pick 50ee7529ec45 ("random: try to
> actively add entropy rather than passively wait for it"). I'm pretty
> confident that it's probably fine ("it's fine. it's fine. Really,
> it's fine") for
On Fri, Jan 10, 2020 at 03:52:53AM +, Luca Filipozzi wrote:
> Two questions (pretend i'm 6yo):
>
> (1) why can't AWS offer virtio-rng support (other than "we already offer
> a RDRAND on amd64") and should Debian actively encourage their adding
> this support?
We can certainly ask. However,
On Thu, Jan 09, 2020 at 01:18:24PM +0100, Adam Dobrawy wrote:
> >> I'd encourage those of you who are in position to make Amazon listen
> >> to get with the program and support virtio-rng. :-)
> > Noah: chances of AWS supporting virtio-rng?
> I wonder if the correct criterion for the cloud image
On Thu, Jan 09, 2020 at 04:57:24PM +, Luca Filipozzi wrote:
> > > >> I'd encourage those of you who are in position to make Amazon listen
> > > >> to get with the program and support virtio-rng. :-)
> > > > Noah: chances of AWS supporting virtio-rng?
> > > I wonder if the correct criterion
On Thu, Jan 09, 2020 at 05:22:17PM -0500, Noah Meyerhans wrote:
> I've confirmed that 4.19.87 with changes cherry-picked from 50ee7529ec45
> claims to have entropy at boot:
>
> admin@ip-172-31-49-239:~$ cloud-init analyze blame
> -- Boot Record 01 --
> 02.88900s (init-
On Tue, Jan 14, 2020 at 03:01:23PM +, Luca Filipozzi wrote:
> > If we want to extend the cloud kernel to support other services, we need
> > to do more than just enable virtio-rng. Somebody need to come up with a
> > complete list of devices that are needed for the service in question,
> >
On Wed, Jan 22, 2020 at 05:15:55PM -0300, Sergio Morales wrote:
>Where I can find information about the release window for the official
>Debian AMI on AWS?
>Anyone knows of any blocker for this?
The AMIs are available today:
https://wiki.debian.org/Cloud/AmazonEC2Image/Buster
The
On Thu, Jan 09, 2020 at 01:22:30PM -0500, Noah Meyerhans wrote:
> Our 5.4 kernel in sid does not suffer from a lack of entropy at boot on
> arm64 EC2 instances. I guess it could be due to the "random: try to
> actively add entropy rather than passively wait for it" that tytso
The buster arm64 images on Amazon EC2 appear to have insufficient
entropy at boot, and thus take several minutes to complete the boot
process.
There are a couple of potential fixes (or at least workarounds) for this
problem, but none is entirely perfect.
Option 1:
We add haveged to the arm64
On Wed, Jan 08, 2020 at 12:50:04PM -0800, Ross Vandegrift wrote:
> I know of two other options:
> - pollinate
> - jitterentropy-rngd
>
> pollinate downloads seeds remotely, which feels wrong - and itself may
> require random numbers. I've never tried jitterentropy.
IMO these are roughly
On Wed, Jan 08, 2020 at 08:17:13PM +, Luca Filipozzi wrote:
> Every time I propose the use of haveged to resolve entropy starvation, I
> get reactions from crypto folks saying that it's not a valid solution.
> They invariably suggest that passing hardware RNG through to the VM is
> the
On Wed, Jan 08, 2020 at 09:24:25PM +, Jeremy Stanley wrote:
> > I've seen reactions like this, but never an explanation. Has anyone
> > written up the issues? Given that "fail to boot" isn't a workable
> > outcome, it'd be useful to know exactly what risks one accepts when
> > using haveged.
In our most recent meeting, we discussed possibly updating cloud-init in
stable. [1] This would be our first first time performing a
feature-update to a stable release, even though the stable release
managers some time ago indicated a willingness to let us do that.
In order to get that process
On Wed, Dec 25, 2019 at 12:39:19PM +0100, Thomas Goirand wrote:
> >> Though if we're to have a Buster branch, best would probably be to just
> >> call the branch debian/buster, and start the fork from the debian/18.3-6
> >> tag (so we have a meaningful history). I usually have the habit to never
>
On Wed, Dec 25, 2019 at 12:05:08PM +0100, Thomas Goirand wrote:
> I can see it, though I do expect we just work on a single Git
> repository, not with everyone forking everything. I've opened a buster
> branch on Salsa, using the debian/18.3-6 tag the entry point. We can
> start from there.
On Wed, Dec 25, 2019 at 12:42:49AM +0100, Thomas Goirand wrote:
> > In order to get that process started, I have constructed a "buster-p-u"
> > branch on salsa and begun testing cloud-init 19.3 on buster on AWS. [2]
>
> Though if we're to have a Buster branch, best would probably be to just
>
On Sun, Dec 29, 2019 at 11:16:20PM +0100, Thomas Goirand wrote:
> >> Right, both bridge-utils and vlan are required to setup a bridge or
> >> vlan from *within* /etc/network/interfaces.
> >
> > That's not really true. bridge-utils and vlan add some additional
> > syntax, but everything can be
On Fri, Dec 27, 2019 at 02:16:05PM +0100, Christian Tramnitz wrote:
> However, I'm running into multiple problems staging a system through
> cloud-init.
> Without the packages
> - bridge-utils
> - vlan
> - gnupg2
> it is virtually impossible to use the image for cloud-init based deployment:
>
On Fri, Dec 27, 2019 at 11:39:00PM +0100, Thomas Goirand wrote:
> >> it is virtually impossible to use the image for cloud-init based
> >> deployment:
> >> While cloud-init can also install missing packages, the install would
> >> happen *after* package installation and network setup.
On Sat, Dec 28, 2019 at 12:23:04PM +0100, Christian Tramnitz wrote:
> There is no workaround for the lack of vlan and bridge-utils though.
> It would be great it we could get those two included into the base
> image.
Both vlan and bridge-utils are legacy tools that are replaced by ip(8)
on modern
On Fri, Dec 27, 2019 at 10:33:16PM +0100, Christian Tramnitz wrote:
> Right, both bridge-utils and vlan are required to setup a bridge or
> vlan from *within* /etc/network/interfaces.
That's not really true. bridge-utils and vlan add some additional
syntax, but everything can be accomplished
On Sat, Mar 07, 2020 at 05:56:43PM -0800, Noah Meyerhans wrote:
> > > So in case we'd be removing this dependency to satisfy your container
> > > use case (which is IMO very valid), we should carefully re-add a
> > > dependency on cloud-utils in our VM images.
> &g
Package: cloud.debian.org
Severity: wishlist
As documented at
https://opensource.creativecommons.org/blog/entries/2020-04-03-nvmee-on-debian-on-aws/
and https://lists.debian.org/debian-cloud/2020/04/msg00015.html, it
would be helpful if we install meaningful /dev/xvd* or /dev/sd* symlinks
mapping
This is a continuation, in spirit, of a thread from last summer, but I'm
intentionally starting a new one here. [1]
This post will specifically focus on the Debian AWS Marketplace
listings, which are currently split across two AWS accounts [2][3]
We've got some inconsistencies between our
On Sat, Apr 04, 2020 at 10:17:20AM +0200, Thomas Goirand wrote:
> > The first two bugs are about nested virtualization. I like the idea of
> > deciding to support that or not. I don't know much about nested virt,
> > so I don't have a strong opinion. It seems pretty widely supported on
> > our
On Thu, Apr 02, 2020 at 10:55:16AM -0700, Ross Vandegrift wrote:
> I don't think just saying "yes" automatically is the best approach. But
> I'm not sure we can come up with a clear set of rules. Evaluating the
> use cases will involve judgment calls about size vs functionality. I
> guess I
On Fri, Apr 03, 2020 at 02:03:16PM +, Jeremy Stanley wrote:
> And countless OpenStack service providers as well, though whether
> they do usually depends on if they've got new enough hardware, new
> enough host operating system, and what hypervisor backend they're
> using (for example,
On Fri, Apr 03, 2020 at 06:16:33PM +0200, Jonathan Ballet wrote:
> On AWS Nitro instances, EBS volumes are exposed as NVMe block devices by
> the kernel on the /dev/nvme* paths.
>
> The AWS documentation "Identifying the EBS Device" says that the Linux
> kernel doesn't guarantee the creation
On Fri, Apr 03, 2020 at 12:20:32PM +0200, Thomas Lange wrote:
> If adding a new kernel option does not change the boot time and the
> image size a lot and it's reasonable, then just go add it.
What I was trying to do was specifically define "a lot" and "it's
reasonable." I would rather not have
On Wed, Apr 01, 2020 at 03:15:37PM -0400, Noah Meyerhans wrote:
> There are open bugs against the cloud kernel requesting that
> configuration options be turned on there. [1][2][3]
> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952108
> 2. https://bugs.debian.org/cgi-bin/b
For buster, we generate a cloud kernel for amd64. For sid/bullseye,
we'll also support a cloud kernel for arm64. At the moment, the cloud
kernel is the only used in the images we generate for Microsoft Azure
and Amazon EC2. It's used in the GCE images we generate as well, but
I'm not sure
On Mon, Apr 27, 2020 at 01:05:34PM +0100, Wookey wrote:
> > > Someone asked me for a VM image recently, and I discovered we now
> > > make some available at: https://cloud.debian.org/images/cloud/
> >
> > There's new work in progress at: https://image-finder.debian.net/ That page
> > includes
On Mon, Apr 27, 2020 at 01:51:27PM +0200, Bastian Blank 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 Tue, Apr 21, 2020 at 03:42:16PM -0700, Ihor Antonov wrote:
> - I often want to make sure that this is *really* the official AMI, some kind
> of
> link to the debian page that says "yes, this is indeed Debian's account ID
> would make me feel more reassured.
Yes, I agree that this is
On Tue, Apr 21, 2020 at 04:57:22PM +0200, Emmanuel Kasper wrote:
> YMMV, I use the following text in
> https://app.vagrantup.com/debian/
>
> Debian is a free Operating System for your laptop, server or embedded
> device. But it provides more than a pure OS: it comes with over 59000
> packages,
On Thu, Mar 26, 2020 at 09:01:00PM -0300, Antonio Terceiro wrote:
> > the instances were created by hand but their setup is automated.
> >
> > > For some background, the AWS account under which these instances are
> > > running is owned by an individual DD, not SPI/Debian. We have created a
> > >
On Mon, Apr 27, 2020 at 11:41:10PM +0100, Wookey wrote:
> > > > generic is most flexible, genericcloud has physical hardware drivers
> > > > disabled,
> > > > and nocloud is as minimal as possible. The tools, configs, and docs
> > > > are in
> > > > this repo:
On Tue, May 12, 2020 at 06:57:06PM -0500, Ryan Belgrave wrote:
>After doing a bunch more digging it seems to be related to
>[1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947351
It certainly could be.
Can you test a sid or bullseye image? They have cloud-init 20.1.
Try
On Mon, May 11, 2020 at 07:18:08PM -0500, Ryan Belgrave wrote:
>What are the correct images to use for a baremetal cloud? The first ones I
>tried were the Openstack ones but those don't seem to have any drivers for
>physical machines. I couldn't get USB keyboards to work physically or
On Sat, May 02, 2020 at 11:24:59PM +0200, Bastian Blank wrote:
> 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
On Mon, May 18, 2020 at 02:59:50AM +, Cauã Siqueira wrote:
> My name's Cauã (Brazilian) and i use Debian for many years. I'm building a
> new infrastructure inside AWS with terraform. We're migrating from CoreOS to
> Debian (choice me), but we're having a problem with userdata to create
>
(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,
On Mon, Mar 16, 2020 at 10:46:49PM +0100, Thomas Goirand wrote:
> For the release team to accept a new version of 20.1, we need to test
> it. Happyaron already tested it with success on Aliyun, Tencent Cloud,
> and Huawei Cloud. We need to test it with Azure, GCE, AWS and OpenStack,
> with the
Package: cloud-init
Version: 20.1-1
Severity: important
Cloud-init 20.1 attempts to obtain an API token for use with Amazon EC2
instance metadata service (IMDS). On EC2, this operation should always
succeed, whether using IMDSv1 or v2, and cloud-init will always access
IMDS in v2 mode. However,
Control: tags -1 + upstream
> 2020-03-20 18:25:10,332 - url_helper.py[DEBUG]: [0/1] open
> 'http://169.254.169.254/latest/api/token' with {'url':
> 'http://169.254.169.254/latest/api/token', 'allow_redirects': True, 'method':
> 'PUT', 'timeout': 1.0, 'headers': {'User-Agent':
On Sun, Mar 08, 2020 at 02:49:26AM +0100, Thomas Goirand wrote:
> On 3/7/20 11:53 PM, Thomas Goirand wrote:
> > So in case we'd be removing this dependency to satisfy your container
> > use case (which is IMO very valid), we should carefully re-add a
> > dependency on cloud-utils in our VM images.
On Fri, May 08, 2020 at 11:41:55PM +0200, Bastian Blank 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.
I'm not sure I agree. A lot of important details about
At some point, maintaining config for our stable images in the same
repository as our unstable/testing images is going to become
unmanageable. We'd like to be able to make changes targeting unstable
without worrying about breaking our stable builds.
Consider the following simple case. I'm
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
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, 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 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 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 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:
>
>
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
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
A first take at this is at
https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/222
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 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
>
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 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
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 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
>
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
>
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 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
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 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,
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.
> 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
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
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
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
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 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
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).
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 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
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.
>
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 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 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
> 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 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
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 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 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
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 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
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
101 - 200 of 347 matches
Mail list logo
