Re: Help requested: Packages which FTBFS randomly
On Tue, Feb 21, 2017 at 11:50:15AM +0800, Paul Wise wrote:
> On Tue, Feb 21, 2017 at 6:36 AM, Christoph Biedl wrote:
>
> > This is a charming idea altough I have doubt it will work out: As
> > usual the information has to be kept up-to-date, so unless it is
> > collected and verified every now and then automatically, it will
> > become unsuable pretty soon.
>
> FYI the buildds are automatically collecting disk usage information,
> see the last line of each build log.
>
> Of course, that information isn't parsed and stored anywhere yet.
So here's my data, from multiple rebuilds since Sep 2014:
https://angband.pl/tmp/builds.sql.xz
(Postgres, but it should be easy to edit the schema for any SQL dialect)
It's all from one machine, running the same kernel line (3.8 vendor for
Odroid-U2), on the same filesystem (btrfs noatime,compress=lzo,ssd), sameish
sbuild settings (eatmydata; regularly upgraded with unstable though).
The data is not ideal -- I run multiple sbuild instances which with only 2GB
memory notoriously ends in swappeathons, thus a package's build time is
affected by what was running concurrently.
Obviously you want only records with status='successful'; I haven't removed
failures in case someone is interested -- for example, there's a bunch of
FTBFSes I haven't yet investigated/filed.
Note that the disk space data is misleading -- sbuild notes only the final
size of the build dir after finished build, peak size may differ. For
example, ceph ENOSPCes with 51GB free despite sbuild saying only 21GB.
> I guess collecting memory usage would be much harder, especially if
> multiple packages are built in parallel.
Packages being built in parallel are not a problem -- neither overlayfs nor
btrfs support sharing pages yet even if they use the same on-disk blocks.
Getting peak usage for a set of processes is a very tricky task, though:
if a process uses 50MB then forks, each copy taking 20MB more, the usage
is 90MB not 140MB. Processes come and go, executable/library pages are
shared, and so on.
The only tool that _looks_ like it gets it right seems to be cgmemtime, not
packaged in Debian yet and requiring some setup.
Having peak memory data from builds would be awesome.
Meow!
--
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
./configure --host=zx-spectrum --build=pdp11
Reply to: