Bug#929214: release.debian.org - Add package constraint for cloud images
Hi Ivo On Sat, Mar 13, 2021 at 03:30:39PM +0100, Ivo De Decker wrote: > > The binary package is in testing since some time. Please add it to the > > key packages list. > Added. Thanks. Regards, Bastian -- Our way is peace. -- Septimus, the Son Worshiper, "Bread and Circuses", stardate 4040.7.
Bug#929214: release.debian.org - Add package constraint for cloud images
Hi Sorry that I missed to follow up on that task for some time. On Wed, Jun 12, 2019 at 05:57:00PM +0200, Ivo De Decker wrote: > > | Package: debian-cloud-images-packages > > | Architecture: amd64 > > | Depends: apparmor, awscli, chrony, cloud-init, cloud-initramfs-growroot, > > google-compute-engine, grub-cloud-amd64, grub-pc, libpam-systemd, > > linux-image-amd64, linux-image-cloud-amd64, openssh-server, python, > > python-boto, python3-boto, sudo, unattended-upgrades, waagent > > > > Please acknowledge that such a package would be okay for using as > > constraint. After that I'll upload that change. > If you create such a package, having a binary per architecture as you > describe, should do what you want. It can be added to the list as soon as it > is in testing. The binary package is in testing since some time. Please add it to the key packages list. Regards, Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0
Bug#929214: release.debian.org - Add package constraint for cloud images
On Thu, Jun 13, 2019 at 07:57:58PM +0200, Bastian Blank wrote: > Hi > > On Wed, Jun 12, 2019 at 08:01:08PM +0200, Bastian Blank wrote: > > On Wed, Jun 12, 2019 at 05:57:00PM +0200, Ivo De Decker wrote: > > > If you create such a package, having a binary per architecture as you > > > describe, should do what you want. It can be added to the list as soon as > > > it > > > is in testing. > > Okay, thank you. > > A quick question: > > Will britney choke if we list conflicting packages as dependencies? > > Something like this: > | Depends: exim4, postfix > Depends what you mean by "choke". Such a package wouldn't be installable, obviously. So it would never go in testing, and wouldn't help ensure any other package's presence or installability in testing. Cheers, Julien
Bug#929214: release.debian.org - Add package constraint for cloud images
Hi On Wed, Jun 12, 2019 at 08:01:08PM +0200, Bastian Blank wrote: > On Wed, Jun 12, 2019 at 05:57:00PM +0200, Ivo De Decker wrote: > > If you create such a package, having a binary per architecture as you > > describe, should do what you want. It can be added to the list as soon as it > > is in testing. > Okay, thank you. A quick question: Will britney choke if we list conflicting packages as dependencies? Something like this: | Depends: exim4, postfix Regards, Bastian -- Death, when unnecessary, is a tragic thing. -- Flint, "Requiem for Methuselah", stardate 5843.7
Bug#929214: release.debian.org - Add package constraint for cloud images
On Wed, Jun 12, 2019 at 09:03:04PM +0200, Paul Gevers wrote: > Hi Bastian, > > [CC adding debian-ci@l.d.o, please drop the bug in the next reply as it > starts to become off-topic there.] > > On 12-06-2019 20:52, Bastian Blank wrote: > > On Wed, Jun 12, 2019 at 08:42:27PM +0200, Paul Gevers wrote: > >> On 12-06-2019 20:01, Bastian Blank wrote: > >>> I'm also not sure if the Debian autopkgtest infrastructure would be able > >>> to do that and build images. The actual testing runs via the Gitlab > >>> CI.[1] > >> You could very probably do it. Depending on how long such a build takes, > > > > One build takes 3 minutes if it runs native and 13 minutes if it runs > > via qemu-user. However it needs awefull amount of network and disk IO. > > I don't believe that should be a problem if that is an *or*. However, > qemu will not work properly, right Antonio? qemu-user probably works; qemu-system might work, but not with kvm acceleration. > > Does the Debian autopkgtest instance support "needs-root" and > > "breaks-testbed"? > > Yes and yes. The only thing we currently do not support *yet* is > isolation-machine. > > > The image build uses loop devices, hence > > "needs-root", which can't be cleaned up properly, hence > > "breaks-testbed". > > That's no problem at all. mounting loop devices would not work. (these tests probably also need isolation-machine) signature.asc Description: PGP signature
Bug#929214: release.debian.org - Add package constraint for cloud images
Hi Bastian, [CC adding debian-ci@l.d.o, please drop the bug in the next reply as it starts to become off-topic there.] On 12-06-2019 20:52, Bastian Blank wrote: > On Wed, Jun 12, 2019 at 08:42:27PM +0200, Paul Gevers wrote: >> On 12-06-2019 20:01, Bastian Blank wrote: >>> I'm also not sure if the Debian autopkgtest infrastructure would be able >>> to do that and build images. The actual testing runs via the Gitlab >>> CI.[1] >> You could very probably do it. Depending on how long such a build takes, > > One build takes 3 minutes if it runs native and 13 minutes if it runs > via qemu-user. However it needs awefull amount of network and disk IO. I don't believe that should be a problem if that is an *or*. However, qemu will not work properly, right Antonio? > Does the Debian autopkgtest instance support "needs-root" and > "breaks-testbed"? Yes and yes. The only thing we currently do not support *yet* is isolation-machine. > The image build uses loop devices, hence > "needs-root", which can't be cleaned up properly, hence > "breaks-testbed". That's no problem at all. >> I slightly wonder if you should, but the advantage is that it is >> integrated with the migration software. > > Yes. I think you should do this. Paul signature.asc Description: OpenPGP digital signature
Bug#929214: release.debian.org - Add package constraint for cloud images
Hi Paul On Wed, Jun 12, 2019 at 08:42:27PM +0200, Paul Gevers wrote: > On 12-06-2019 20:01, Bastian Blank wrote: > > I'm also not sure if the Debian autopkgtest infrastructure would be able > > to do that and build images. The actual testing runs via the Gitlab > > CI.[1] > You could very probably do it. Depending on how long such a build takes, One build takes 3 minutes if it runs native and 13 minutes if it runs via qemu-user. However it needs awefull amount of network and disk IO. Does the Debian autopkgtest instance support "needs-root" and "breaks-testbed"? The image build uses loop devices, hence "needs-root", which can't be cleaned up properly, hence "breaks-testbed". > I slightly wonder if you should, but the advantage is that it is > integrated with the migration software. Yes. Regards, Bastian -- Killing is stupid; useless! -- McCoy, "A Private Little War", stardate 4211.8
Bug#929214: release.debian.org - Add package constraint for cloud images
Hi Bastian, On 12-06-2019 20:01, Bastian Blank wrote: > The code in the package is not used to actually build the images we > release for Debian. We use the unreleased code from the git repository > to do all the automated stuff. > > I'm also not sure if the Debian autopkgtest infrastructure would be able > to do that and build images. The actual testing runs via the Gitlab > CI.[1] You could very probably do it. Depending on how long such a build takes, I slightly wonder if you should, but the advantage is that it is integrated with the migration software. Paul signature.asc Description: OpenPGP digital signature
Bug#929214: release.debian.org - Add package constraint for cloud images
Hi On Wed, Jun 12, 2019 at 05:57:00PM +0200, Ivo De Decker wrote: > If you create such a package, having a binary per architecture as you > describe, should do what you want. It can be added to the list as soon as it > is in testing. Okay, thank you. > Also, just as a suggestion: if it is feasible, you could add an autopkgtest to > that source to build (or even test) the cloud images. That would prevent > migration to testing of packages that break your images. The code in the package is not used to actually build the images we release for Debian. We use the unreleased code from the git repository to do all the automated stuff. I'm also not sure if the Debian autopkgtest infrastructure would be able to do that and build images. The actual testing runs via the Gitlab CI.[1] Regards, Bastian [1]: https://salsa.debian.org/cloud-team/debian-cloud-images/pipelines -- Dismissed. That's a Star Fleet expression for, "Get out." -- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"
Bug#929214: release.debian.org - Add package constraint for cloud images
Control: retitle -1 Add key package for cloud images Hi, On Sun, May 19, 2019 at 12:18:31PM +0200, Bastian Blank wrote: > To make your and our work easier, we would like to ask you to add a > package constraint for all the packages included into the official > Debianm cloud images. > > From what I read, the easiest way for you would be to specify a single > package as constraint, a package that depends on all the other binary > package we explicitely include in the images. > > I intend to add one binary package per architecture we currently build > images for: amd64, arm64 and ppc64el. The dependencies will be arch > dependent and auto-generated from our own list. > > The package would look like this: > > | Package: debian-cloud-images-packages > | Architecture: amd64 > | Depends: apparmor, awscli, chrony, cloud-init, cloud-initramfs-growroot, > google-compute-engine, grub-cloud-amd64, grub-pc, libpam-systemd, > linux-image-amd64, linux-image-cloud-amd64, openssh-server, python, > python-boto, python3-boto, sudo, unattended-upgrades, waagent > > Please acknowledge that such a package would be okay for using as > constraint. After that I'll upload that change. Constraints are only used to check installability of packages that britney wouldn't otherwise be able to check. This isn't necessary in this case. What you want is a source package that is added to the key packages list, to prevent auto-removal. If you create such a package, having a binary per architecture as you describe, should do what you want. It can be added to the list as soon as it is in testing. Please note that if some of the packages involved would cause serious issues for the release, we might still notify you that we would be forced to (manually) remove them if the issues aren't fixed. Also, just as a suggestion: if it is feasible, you could add an autopkgtest to that source to build (or even test) the cloud images. That would prevent migration to testing of packages that break your images. Cheers, Ivo
Bug#929214: release.debian.org - Add package constraint for cloud images
Package: release.debian.org Severity: normal Hi release team To make your and our work easier, we would like to ask you to add a package constraint for all the packages included into the official Debianm cloud images. >From what I read, the easiest way for you would be to specify a single package as constraint, a package that depends on all the other binary package we explicitely include in the images. I intend to add one binary package per architecture we currently build images for: amd64, arm64 and ppc64el. The dependencies will be arch dependent and auto-generated from our own list. The package would look like this: | Package: debian-cloud-images-packages | Architecture: amd64 | Depends: apparmor, awscli, chrony, cloud-init, cloud-initramfs-growroot, google-compute-engine, grub-cloud-amd64, grub-pc, libpam-systemd, linux-image-amd64, linux-image-cloud-amd64, openssh-server, python, python-boto, python3-boto, sudo, unattended-upgrades, waagent Please acknowledge that such a package would be okay for using as constraint. After that I'll upload that change. Regards, Bastian -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
