Tools for testing LTS updates
Hi, I have just patched ratt to allow automatic rebuilding of reverse build dependencies in distributions other than unstable: https://github.com/Debian/ratt/pull/8 Sbuild running on jessie (building for wheezy) still emits errors like: ... dpkg-deb: error: failed to read archive `libming1_0.4.4-1.1+deb7u1_amd64.deb': No such file or directory E: read_command failed to execute dpkg-deb Use of uninitialized value $arch in scalar chomp at /usr/share/perl5/Sbuild/Build.pm line 1295. Use of uninitialized value $arch in string ne at /usr/share/perl5/Sbuild/Build.pm line 1298. Use of uninitialized value $arch in string ne at /usr/share/perl5/Sbuild/Build.pm line 1298. Use of uninitialized value $arch in concatenation (.) or string at /usr/share/perl5/Sbuild/Build.pm line 1300. W: Extra package libming1_0.4.4-1.1+deb7u1_amd64.deb of architecture cannot be installed in the chroot ... , but the extra packages install fine later: ... Get:1 copy:/<>/resolver-W8JG9E/apt_archive/ ./ libming1 1:0.4.4-1.1+deb7u1 [186 kB] ... Selecting previously unselected package libming1. Unpacking libming1 (from .../libming1_1%3a0.4.4-1.1+deb7u1_amd64.deb) ... ... It is pretty useful for testing updates for Wheezy LTS (and for coming Jessie LTS :-)). The other tool I would love to use for LTS work is a private https://ci.debian.net/ installation for running autopkgtests or reverse dependencies. To make it happen I'm thinking about spending a few hours on creating a puppet module for it to automate installation in a VM. What do you think? Cheers, Balint
Re: Tools for testing LTS updates
On 2017-01-23 18:41:25, Bálint Réczey wrote: [ratt: cool! though i am not sure when i should use that...?] > The other tool I would love to use for LTS work is a private > https://ci.debian.net/ installation for running autopkgtests or > reverse dependencies. > > To make it happen I'm thinking about spending a few hours on creating > a puppet module for it to automate installation in a VM. What do you > think? regarding ci... i am not sure how useful that would be for me. right now, i just run a wheezy VM inside qemu and install stuff by hand in there. since i need a clean VM every time, setting up the whole CI env would seem to be a significant overhead, no? besides, i expect the build process to run tests.. autopkgtest i usually run by hand later, if at all - i am usually more concerned about testing with the POC data from advisories... but it would be great to have a more standard and, more importantly, documented setup, as I have spent quite a bit of personal time finding the right workflow for that kind of stuff here (which mostly revolves around pdebuild, cowbuilder, vmdebootstrap and qemu right now). i'd be happy to participate in such a documentation / standardization effort in any case. a. -- Drowning people Sometimes die Fighting their rescuers. - Octavia Butler
Re: Tools for testing LTS updates
On Mon, Jan 23, 2017 at 02:01:41PM -0500, Antoine Beaupré wrote: > regarding ci... i am not sure how useful that would be for me. right > now, i just run a wheezy VM inside qemu and install stuff by hand in > there. since i need a clean VM every time, setting up the whole CI env > would seem to be a significant overhead, no? it's wheezy/oldstable, so by definition it's not changing much, thus it's probably sufficient to only create that clean VM once every week or month and then preserve that as a "snapshot" image and run triggered CI tests based on a copy of that image… -- cheers, Holger signature.asc Description: Digital signature
Re: Tools for testing LTS updates
On Mon, Jan 23, 2017 at 02:01:41PM -0500, Antoine Beaupré wrote: > On 2017-01-23 18:41:25, Bálint Réczey wrote: > [ratt: cool! though i am not sure when i should use that...?] > > > The other tool I would love to use for LTS work is a private > > https://ci.debian.net/ installation for running autopkgtests or > > reverse dependencies. > > > > To make it happen I'm thinking about spending a few hours on creating > > a puppet module for it to automate installation in a VM. What do you > > think? > > regarding ci... i am not sure how useful that would be for me. right > now, i just run a wheezy VM inside qemu and install stuff by hand in > there. since i need a clean VM every time, setting up the whole CI env > would seem to be a significant overhead, no? > > besides, i expect the build process to run tests.. autopkgtest i usually > run by hand later, if at all - i am usually more concerned about testing > with the POC data from advisories... > > but it would be great to have a more standard and, more importantly, > documented setup, as I have spent quite a bit of personal time finding > the right workflow for that kind of stuff here (which mostly revolves > around pdebuild, cowbuilder, vmdebootstrap and qemu right now). I'm using /usr/share/doc/pbuilder/examples/B20autopkgtest to run the tests within pbuilder (that does not help with reverse dependencies testing). Cheers, -- Guido > > i'd be happy to participate in such a documentation / standardization > effort in any case. > > a. > > -- > Drowning people > Sometimes die > Fighting their rescuers. > - Octavia Butler >
Re: Tools for testing LTS updates
On Mon, Jan 23, 2017 at 06:41:25PM +0100, Bálint Réczey wrote: > Hi, > > I have just patched ratt to allow automatic rebuilding of reverse > build dependencies in distributions other than unstable: > https://github.com/Debian/ratt/pull/8 > > Sbuild running on jessie (building for wheezy) still emits errors like: > ... > dpkg-deb: error: failed to read archive > `libming1_0.4.4-1.1+deb7u1_amd64.deb': No such file or directory > E: read_command failed to execute dpkg-deb > Use of uninitialized value $arch in scalar chomp at > /usr/share/perl5/Sbuild/Build.pm line 1295. > Use of uninitialized value $arch in string ne at > /usr/share/perl5/Sbuild/Build.pm line 1298. > Use of uninitialized value $arch in string ne at > /usr/share/perl5/Sbuild/Build.pm line 1298. > Use of uninitialized value $arch in concatenation (.) or string at > /usr/share/perl5/Sbuild/Build.pm line 1300. > W: Extra package libming1_0.4.4-1.1+deb7u1_amd64.deb of architecture > cannot be installed in the chroot > ... > > , but the extra packages install fine later: > ... > Get:1 copy:/<>/resolver-W8JG9E/apt_archive/ ./ libming1 > 1:0.4.4-1.1+deb7u1 [186 kB] > ... > Selecting previously unselected package libming1. > Unpacking libming1 (from .../libming1_1%3a0.4.4-1.1+deb7u1_amd64.deb) ... > ... > > It is pretty useful for testing updates for Wheezy LTS (and for coming > Jessie LTS :-)). > > The other tool I would love to use for LTS work is a private > https://ci.debian.net/ installation for running autopkgtests or > reverse dependencies. That would indeed be awesome! -- Guido > > To make it happen I'm thinking about spending a few hours on creating > a puppet module for it to automate installation in a VM. What do you > think? > > Cheers, > Balint >
Re: Tools for testing LTS updates
On Mon, Jan 23, 2017 at 07:22:30PM +, Holger Levsen wrote:
> On Mon, Jan 23, 2017 at 02:01:41PM -0500, Antoine Beaupré wrote:
> > regarding ci... i am not sure how useful that would be for me. right
> > now, i just run a wheezy VM inside qemu and install stuff by hand in
> > there. since i need a clean VM every time, setting up the whole CI env
> > would seem to be a significant overhead, no?
>
> it's wheezy/oldstable, so by definition it's not changing much, thus
> it's probably sufficient to only create that clean VM once every week or
> month and then preserve that as a "snapshot" image and run triggered CI
> tests based on a copy of that image…
I'm probably stating the obvios but it can be done with:
SNAPSHOT=wheezy-2017-01-13
IP=192.168.122.17
PKG=$(dpkg-parsechangelog -Ssource)
VERSION=$(dpkg-parsechangelog -SVersion)
set -x
set -e
virsh destroy autopkgtest || true
virsh snapshot-revert autopkgtest $SNAPSHOT
virsh start autopkgtest
autopkgtest -B ../*_${VERSION}_*.deb ../${PKG}_${VERSION}.dsc -- ssh -H $IP
-P
(in case running inside pbuilder is not sufficient (eg. because it needs
daemons running, etc.). Not very elaborate but does the job.
Cheers,
-- Guido
Re: Tools for testing LTS updates
On 2017-01-23 20:46:28, Guido Günther wrote:
> On Mon, Jan 23, 2017 at 07:22:30PM +, Holger Levsen wrote:
>> On Mon, Jan 23, 2017 at 02:01:41PM -0500, Antoine Beaupré wrote:
>> > regarding ci... i am not sure how useful that would be for me. right
>> > now, i just run a wheezy VM inside qemu and install stuff by hand in
>> > there. since i need a clean VM every time, setting up the whole CI env
>> > would seem to be a significant overhead, no?
>>
>> it's wheezy/oldstable, so by definition it's not changing much, thus
>> it's probably sufficient to only create that clean VM once every week or
>> month and then preserve that as a "snapshot" image and run triggered CI
>> tests based on a copy of that image…
>
> I'm probably stating the obvios but it can be done with:
>
> SNAPSHOT=wheezy-2017-01-13
> IP=192.168.122.17
>
> PKG=$(dpkg-parsechangelog -Ssource)
> VERSION=$(dpkg-parsechangelog -SVersion)
>
> set -x
> set -e
>
> virsh destroy autopkgtest || true
> virsh snapshot-revert autopkgtest $SNAPSHOT
> virsh start autopkgtest
> autopkgtest -B ../*_${VERSION}_*.deb ../${PKG}_${VERSION}.dsc -- ssh -H $IP
> -P
>
> (in case running inside pbuilder is not sufficient (eg. because it needs
> daemons running, etc.). Not very elaborate but does the job.
this is exactly the kind of stuff that should be documented, because
that's not obvious to me at all.
there are so many virtualizations solutions out there, I don't even
think i can guess what that one is: virsh is just libvirt, right? so is
that xen, kvm, virtualbox or qemu or what? in any case, isn't there some
setup to be done first there?
On 2017-01-23 20:42:35, Guido Günther wrote:
> I'm using
>
> /usr/share/doc/pbuilder/examples/B20autopkgtest
>
> to run the tests within pbuilder (that does not help with reverse
> dependencies testing).
i'm lazy - how do you actually hook that up in pbuilder?
a.
Re: Tools for testing LTS updates
On Mon, Jan 23, 2017 at 03:06:31PM -0500, Antoine Beaupré wrote:
> On 2017-01-23 20:46:28, Guido Günther wrote:
> > On Mon, Jan 23, 2017 at 07:22:30PM +, Holger Levsen wrote:
> >> On Mon, Jan 23, 2017 at 02:01:41PM -0500, Antoine Beaupré wrote:
> >> > regarding ci... i am not sure how useful that would be for me. right
> >> > now, i just run a wheezy VM inside qemu and install stuff by hand in
> >> > there. since i need a clean VM every time, setting up the whole CI env
> >> > would seem to be a significant overhead, no?
> >>
>> >> it's wheezy/oldstable, so by definition it's not changing much, thus
> >> it's probably sufficient to only create that clean VM once every week or
> >> month and then preserve that as a "snapshot" image and run triggered CI
> >> tests based on a copy of that image…
> >
> > I'm probably stating the obvios but it can be done with:
> >
> > SNAPSHOT=wheezy-2017-01-13
> > IP=192.168.122.17
> >
> > PKG=$(dpkg-parsechangelog -Ssource)
> > VERSION=$(dpkg-parsechangelog -SVersion)
> >
> > set -x
> > set -e
> >
> > virsh destroy autopkgtest || true
> > virsh snapshot-revert autopkgtest $SNAPSHOT
> > virsh start autopkgtest
> > autopkgtest -B ../*_${VERSION}_*.deb ../${PKG}_${VERSION}.dsc -- ssh -H $IP
> > -P
> >
> > (in case running inside pbuilder is not sufficient (eg. because it needs
> > daemons running, etc.). Not very elaborate but does the job.
>
> this is exactly the kind of stuff that should be documented, because
> that's not obvious to me at all.
>
> there are so many virtualizations solutions out there, I don't even
> think i can guess what that one is: virsh is just libvirt, right? so is
> that xen, kvm, virtualbox or qemu or what? in any case, isn't there some
> setup to be done first there?
I'm using a qemu VM bootstrapped via
http://honk.sigxcpu.org/con/Preseeding_Debian_virtual_machines_with_virt_install.html
Note that there's also autopkgtest-virt-qemu but since it doesn't use
libvirt I'd have to handle it differently so I'm using the above.
>
> On 2017-01-23 20:42:35, Guido Günther wrote:
> > I'm using
> >
> > /usr/share/doc/pbuilder/examples/B20autopkgtest
> >
> > to run the tests within pbuilder (that does not help with reverse
> > dependencies testing).
>
> i'm lazy - how do you actually hook that up in pbuilder?
See HOOKDIR in "man pbuilderrc"
Cheers,
-- Guido
Re: Tools for testing LTS updates
On 2017-01-24 08:37:05, Guido Günther wrote: > I'm using a qemu VM bootstrapped via > > > http://honk.sigxcpu.org/con/Preseeding_Debian_virtual_machines_with_virt_install.html > > Note that there's also autopkgtest-virt-qemu but since it doesn't use > libvirt I'd have to handle it differently so I'm using the above. Cool, that's great. I discovered this project recently, from another DD (smvc): https://github.com/smcv/vectis Really interesting and promising... In any case, it seems to me this should be documented *somewhere*. The LTS/Development page in the wiki may be a good place, but I wonder if that shouldn't be more "upstream" in the docs pages... Any ideas? -- La propriété est un piège: ce que nous croyons posséder nous possède. - Alphonse Karr
