I'm not part of DSA but it looks like quantz is suitable...

On Fri, Feb 21, 2014 at 10:11 PM, Ralf Treinen wrote:

> 1 the Packages files on which we run our analysis in their latest version
>   (the ones that you find as dists/sid/main/binary-<ARCH>/Packages on a 
> mirror):
>     sid, testing, stable;
>     all release architectures (plus possible some more, like hurd-i386)
>     at least main, if possible also non-free and contrib
>   it would be great if these were already available on the machine so that we
>   don't have to fetch them ourselves.

quantz has access to a local Debian mirror on NFS in
/srv/mirrors/debian{-security,-backports}.

For Skolelinux and Emdebian I guess you would need to download them
manually. If you wanted to run the analysis on more derivatives, the
derivatives census could provide a way to access those.

> 2 Particular packages installed: dose-distcheck. It would be great if there
>   were a way to upgrade that package if necessary (through backports?)

Send a patch for the debian.org-qa.debian.org package to DSA to get
new packages installed. IIRC DSA find backports to be acceptable.

http://anonscm.debian.org/gitweb/?p=mirror/debian.org.git;a=blob;f=debian/control;hb=HEAD#l513

> 3 Computing power: The script would run once per day. On my desktop amd64
>   machine I would estimate a total running time of 10 to 15 minutes for that.

Looks like there are some periods of low load about that long:

https://munin.debian.org/debian.org/quantz.debian.org/load.html
https://dsa.debian.org/ (login here)

> 4 Disk space (for the static web pages that hold the results): this depends
>   on the number of days for which we will hold old results. A rough estimate 
> is
>   10M * number_of_days. The old edos-debcheck used number_of_day=7, which 
> seems
>   to be a reasonable compromise. Better not be too tight on disk space since
>   the need might increase on a bad day when we have lots of non-installable
>   packages.

The partition holding /srv has 31G available. I expect the results of
this should not be backed up? Adding a .nobackup file in the relevant
directories will do that.

> Principle contact could be me, but there are two people who have already
> expressed interest in helping out.

Great.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: 
http://lists.debian.org/caktje6f6yqd5tu3e8d-4ha_bccsk3542cy6ehjt_oa5ro_l...@mail.gmail.com

Reply via email to