Fwd: Bug#956931: autopkgtest: Build profiles support for autopkgtest

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Bug#956931: autopkgtest: Build profiles support for autopkgtest

Jiri Palecek




-------- Forwarded Message --------
Subject: Bug#956931: autopkgtest: Build profiles support for autopkgtest
Resent-Date: Thu, 16 Apr 2020 20:42:01 +0000
Resent-From: Jiri Palecek [hidden email]
Resent-To: [hidden email]
Resent-CC: [hidden email], Debian CI team [hidden email]
Date: Thu, 16 Apr 2020 22:38:07 +0200
From: Jiri Palecek [hidden email]
Reply-To: Jiri Palecek [hidden email], [hidden email]
To: Debian Bug Tracking System [hidden email]


Package: autopkgtest
Version: 5.12.2~6.gbp89ad39
Severity: wishlist

Dear Maintainer,

with the latest and greatest changes in dpkg, I think it would be nice
if autopkgtest followed suit. Particularly, it would be advantageous to
support running and building tests in autopkgtest under build profiles
(esp. nodoc!). This would allow for smaller test footprint, less
packages to pull (ie. you don't need texlive on the testbed), and faster
building of the packages.

I prepared a patch implementing such a change here:
https://salsa.debian.org/jpalecek-guest/autopkgtest/-/commit/6275da59305d6e836cb3558f9f442479eb24fc95

The patch is functional, albeit incomplete due to missing documentation.

The real issue is the control file format. In my patch, I use an extra
stanza to specify build profiles, like this:

Build-Profiles: nodoc

Tests: run-some-tests
<<<

I chose this format, because adding the specification to some of the
tests would be IMHO misleading: the build profile applies to all of the
tests indiscriminately, not to any particular one. Also, I chose to
apply them to all @builddep@ dependencies as well.

However, there is a problem about this: it makes the control file format
non-backwards-compatible. Particularly, dpkg needs to be patched or it
will croak on packages with such d/t/control. Maybe, some artificial
Tests: line like

Tests: *

could be added? That would make the change backwards compatible. Dpkg
still needs to be patched, but the change would be rather minimal.

What do you think about this proposal? Please comment here or on
salsa. I'm also CC-ing the dpkg developers, since it concerns them.

Regards
Jiri Palecek

-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: i386 (i686)
Foreign Architectures: amd64

Kernel: Linux 5.5.0-rc5-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autopkgtest depends on:
ii apt-utils 2.0.1
ii libdpkg-perl 1.20.0+nmu2~1.gbpcd9614
ii procps 2:3.3.16-4
ii python3 3.8.2-2
ii python3-debian 0.1.36

Versions of packages autopkgtest recommends:
pn autodep8 <none>

Versions of packages autopkgtest suggests:
pn lxc <none>
pn lxd <none>
pn ovmf <none>
pn qemu-efi-aarch64 <none>
pn qemu-efi-arm <none>
pn qemu-system <none>
ii qemu-utils 1:4.2-2
ii schroot 1.6.10-9
pn vmdb2 <none>

-- no debconf information
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Bug#956931: autopkgtest: Build profiles support for autopkgtest

Julian Andres Klode-4
On Thu, Apr 16, 2020 at 11:04:02PM +0200, Jiri Palecek wrote:

>
>
>
> -------- Forwarded Message --------
> Subject: Bug#956931: autopkgtest: Build profiles support for autopkgtest
> Resent-Date: Thu, 16 Apr 2020 20:42:01 +0000
> Resent-From: Jiri Palecek <[hidden email]>
> Resent-To: [hidden email]
> Resent-CC: [hidden email], Debian CI team <[hidden email]>
> Date: Thu, 16 Apr 2020 22:38:07 +0200
> From: Jiri Palecek <[hidden email]>
> Reply-To: Jiri Palecek <[hidden email]>, [hidden email]
> To: Debian Bug Tracking System <[hidden email]>
>
>
>
> Package: autopkgtest
> Version: 5.12.2~6.gbp89ad39
> Severity: wishlist
>
> Dear Maintainer,
>
> with the latest and greatest changes in dpkg, I think it would be nice
> if autopkgtest followed suit. Particularly, it would be advantageous to
> support running and building tests in autopkgtest under build profiles
> (esp. nodoc!). This would allow for smaller test footprint, less
> packages to pull (ie. you don't need texlive on the testbed), and faster
> building of the packages.
>
> I prepared a patch implementing such a change here:
> https://salsa.debian.org/jpalecek-guest/autopkgtest/-/commit/6275da59305d6e836cb3558f9f442479eb24fc95
>
> The patch is functional, albeit incomplete due to missing documentation.
>
> The real issue is the control file format. In my patch, I use an extra
> stanza to specify build profiles, like this:
>
> Build-Profiles: nodoc
>
> Tests: run-some-tests
> <<<
>
> I chose this format, because adding the specification to some of the
> tests would be IMHO misleading: the build profile applies to all of the
> tests indiscriminately, not to any particular one. Also, I chose to
> apply them to all @builddep@ dependencies as well.
>
> However, there is a problem about this: it makes the control file format
> non-backwards-compatible. Particularly, dpkg needs to be patched or it
> will croak on packages with such d/t/control. Maybe, some artificial
> Tests: line like
>
> Tests: *
>
> could be added? That would make the change backwards compatible. Dpkg
> still needs to be patched, but the change would be rather minimal.
>
> What do you think about this proposal? Please comment here or on
> salsa. I'm also CC-ing the dpkg developers, since it concerns them.

I understand the motivation for testing in-archive, but this creates
a problem for local testing of unbuilt packages. We want to test as
close to the archive as possible, meaning that the packages we test
should be built with the same build profile as in the archive.

I'm not sure how this is currently handled, but I'd really not
want to go through the trouble of building twice, once without
profiles to get the .debs, and then with build profiles for tests
with build-needed.

And of course, I don't want to just build with those build profiles,
because then it's different from the archive, and I don't get the
guarantees I want (namely, I want to be reasonably certain that
if I run autopkgtest on my .dsc, that it will built and test
successfully in the archive as well; including docs, obviously).

So, in summary, I think it's not a good idea.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Reply | Threaded
Open this post in threaded view
|

Re: Bug#956931: Fwd: Bug#956931: autopkgtest: Build profiles support for autopkgtest

Antonio Terceiro-3
On Fri, Apr 17, 2020 at 09:56:29AM +0200, Julian Andres Klode wrote:

> On Thu, Apr 16, 2020 at 11:04:02PM +0200, Jiri Palecek wrote:
> >
> >
> >
> > -------- Forwarded Message --------
> > Subject: Bug#956931: autopkgtest: Build profiles support for autopkgtest
> > Resent-Date: Thu, 16 Apr 2020 20:42:01 +0000
> > Resent-From: Jiri Palecek <[hidden email]>
> > Resent-To: [hidden email]
> > Resent-CC: [hidden email], Debian CI team <[hidden email]>
> > Date: Thu, 16 Apr 2020 22:38:07 +0200
> > From: Jiri Palecek <[hidden email]>
> > Reply-To: Jiri Palecek <[hidden email]>, [hidden email]
> > To: Debian Bug Tracking System <[hidden email]>
> >
> >
> >
> > Package: autopkgtest
> > Version: 5.12.2~6.gbp89ad39
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> > with the latest and greatest changes in dpkg, I think it would be nice
> > if autopkgtest followed suit. Particularly, it would be advantageous to
> > support running and building tests in autopkgtest under build profiles
> > (esp. nodoc!). This would allow for smaller test footprint, less
> > packages to pull (ie. you don't need texlive on the testbed), and faster
> > building of the packages.
> >
> > I prepared a patch implementing such a change here:
> > https://salsa.debian.org/jpalecek-guest/autopkgtest/-/commit/6275da59305d6e836cb3558f9f442479eb24fc95
> >
> > The patch is functional, albeit incomplete due to missing documentation.
> >
> > The real issue is the control file format. In my patch, I use an extra
> > stanza to specify build profiles, like this:
> >
> > Build-Profiles: nodoc
> >
> > Tests: run-some-tests
> > <<<
> >
> > I chose this format, because adding the specification to some of the
> > tests would be IMHO misleading: the build profile applies to all of the
> > tests indiscriminately, not to any particular one. Also, I chose to
> > apply them to all @builddep@ dependencies as well.
> >
> > However, there is a problem about this: it makes the control file format
> > non-backwards-compatible. Particularly, dpkg needs to be patched or it
> > will croak on packages with such d/t/control. Maybe, some artificial
> > Tests: line like
> >
> > Tests: *
> >
> > could be added? That would make the change backwards compatible. Dpkg
> > still needs to be patched, but the change would be rather minimal.
> >
> > What do you think about this proposal? Please comment here or on
> > salsa. I'm also CC-ing the dpkg developers, since it concerns them.
>
> I understand the motivation for testing in-archive, but this creates
> a problem for local testing of unbuilt packages. We want to test as
> close to the archive as possible, meaning that the packages we test
> should be built with the same build profile as in the archive.
>
> I'm not sure how this is currently handled, but I'd really not
> want to go through the trouble of building twice, once without
> profiles to get the .debs, and then with build profiles for tests
> with build-needed.
>
> And of course, I don't want to just build with those build profiles,
> because then it's different from the archive, and I don't get the
> guarantees I want (namely, I want to be reasonably certain that
> if I run autopkgtest on my .dsc, that it will built and test
> successfully in the archive as well; including docs, obviously).
>
> So, in summary, I think it's not a good idea.
Agreed.

FWIW, I would like autopkgtest to be less involved, not more, with
building packages at all. I think build-needed tests are a terrible
idea, and I would not like to add any involved mechanism to control how
autopkgtest builds packages - I think it being able to build packages in
the simplest way possible is already too much.

If one wants to optimize testing time, they should fix their package so
that it can be tested without requiring another build.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#956931: Fwd: Bug#956931: autopkgtest: Build profiles support for autopkgtest

Paul Gevers-4
Control: tags -1 wontfix

Hi,

On 18-04-2020 02:05, Antonio Terceiro wrote:
> FWIW, I would like autopkgtest to be less involved, not more, with
> building packages at all. I think build-needed tests are a terrible
> idea, and I would not like to add any involved mechanism to control how
> autopkgtest builds packages - I think it being able to build packages in
> the simplest way possible is already too much.

I agree, so I have marked this bug as wontfix.

> If one wants to optimize testing time, they should fix their package so
> that it can be tested without requiring another build.

I fully agree with this as well.

Paul


signature.asc (499 bytes) Download Attachment