[Piuparts-devel] distro.conf and chroot setup for puiparts testing

[Andreas Beckmann]

Hi,

On 2013-05-31 10:25, Zdenek Crha wrote:
> Hi,
> 
> In our company we are developing Debian packages for our software and I've
> been trying to setup testing using distributed version of piuparts. I've
> read the documentation, did few experiments but I still have some questions.

I assume that this is a larger project consisting of more than one
source package and/or you plan to test arbitrary upgrade paths later on.
Otherwise writing a script wrapping a call to piuparts might be easier
than setting up master+slave.

> I'm trying to setup piuparts to create base chroot for test from Debian
> Wheezy, but install and test packages from different archive and
> distribution (containing our local packages).

So you don't have a wheezy section in piuparts.conf (nor do you you plan
to run the wheezy tests). That makes is difficult for the master to
resolve the state of the dependencies. Looks like we should add
something like a assume-unavailable-are-installable setting for
piuparts.conf section. (A wishlist bug should be filed for this.)

> I was able to do that with command line version by creating pbuilder chroot
> tar and supplying sources using --extra-repo and --mirror switches.

add a dummy wheezy section to your piuparts.conf and manually run
piuparts on this section to create a wheezy tarball:

[global]
...
max-tgz-age = 0

[wheezy]
piuparts-flags = <whatever you like>
distro = wheezy
# 1 month (60*60*24*30)
max-tgz-age = 2592000

/path/to/piuparts-slave wheezy

and Ctrl-C once it has created the tarball

> I though I could replicate the setup in distributed version using partial
> distributions:
> 
> [application]
> uri = http://localrepo/application
> distribution = master
> components = non-free
> depends = wheezy

looks good

in your sources.list you would have

  deb http://localrepo/application master non-free

(if it is 'deb http://localrepo/application ./' instead, that format is
currently not supported by master+slave)

> and specifying custom section in piuparts.conf
> 
> [application]
> distro = application
> piuparts-flags = --no-symlinks
> upgrade-test-distros =

here you would either need a
  depends = wheezy
or the (unimplemented)
  assume-unavailable-are-installable = True

> The slave run always failed because it tried to create chroot from
> http://localrepo/application which contains only application packages and
> not Debian system.

see above

> I suspect that
> a) I'm not correctly linking configuration about [application] section with
> [application] partial distribution

A partial distribution needs a parent full distribution to resolve
dependencies (or a way to ignore unavailable ones)

> b) I'm trying to use two mirrors which might not be possible

since we have distros.conf, you can do nearly everything (even
Debian->Ubuntu upgrades or vice versa)

> c) both reasons are valid and some more :-)
> 
> When I've just used distro=wheezy in section config, I was able to create
> chroot without hitch, slave was running and periodically checking master
> but nothing was being tested.

The slave should connect to the master frequently, ask for more work and
print a status line before processing packages or going to sleep
(maybe delete the idle stamp in the master directory)

> I tried to find out from documentation how is the piuparts master getting
> information about packages to test, but without luck. The only hint I found
> was in master cron.d file:

you can run the master manually:

/path/to/piuparts-master
and thereafter enter these two commands, quit with Ctrl-C:
    section wheezy
    status

> # generate reports twice a day
> #  (dinstall runs 1|7|13|19:52, so this is long after mirror pushes...)
> #
> 0  0,12 * * * /usr/share/piuparts/master/generate_daily_report

that creates the webpages only

> which might or might not be related. Did I miss something in docs or
> configuration?

Thanks for using piuparts. Your use case (running partial distros in
standalone mode i.e. without a full parent) sounds sensible, but it may
need some further support from our side. And probably documentation
improvements.

Status output from slave (or manual master) might be helpful for further
debugging, it will only disclose package status + counts.

For now I expect all your packages are in dependency-does-not-exist.


Andreas