Re: possible MBF: automatically detecting unused build dependencies
Hi Holger and everybody else,
writing you and including debian-qa as discussed on #debian-qa :)
Quoting Holger Levsen (2014-07-08 00:59:05)
> On Montag, 7. Juli 2014, Johannes Schauer wrote:
> > I did not plan to run this script more often yet. I'll probably do another
> > run after having added a detection for meta packages as suggested by you
> > below.
> >
> > Running it more regularly might not require any big discussion because the
> > "problem size" might be small enough that maintaining a white list would be
> > enough.
>
> I'd be happy to assist you getting it to run on jenkins.d.n, which is now a 15
> core / 30gb host, which can easily get a job configured testing this every
> three months (or whenever) on half the ressources or so....
>
> Please read the existing documentation (about link etc) and ping me (best via
> (#)debian-qa) for further kickstarting help..!
I become more and more convinced that it would be nice to run these checks more
regularly than I was initially planning to (and also for more source packages).
Every three months or half a year seems to be a good measure.
Unfortunately I'm moving twice within the next month so I will not be able to
do a re-computation with more recent sources very soon. I hope the current
re-computation of the July status (but with fixed meta package detection)
finishes before I have to unplug the machine it's currently running on. To
avoid all this trouble it would indeed be better to run this code on some
Debian remote host instead of my fragile local setup where I also do other
stuff.
You offered to run it on jenkins.d.n and its specs are surely enough to
regularly crunch through a couple of hundred (or more) source packages. But
after having consulted Helmut Grohne on how jenkins works I'm not so sure
anymore whether it's the right place to implement something like this. If one
chooses one job per source package, then one ends up with hundreds if not
thousands of jobs and that doesnt seem to work well? If one choose one job for
the whole procedure then the problem is that it must be possible for the job to
be running uninterrupted for weeks. Even with one job per source package, one
job might be running for several days. For example each compilation of
src:llvm-toolchain needs 3.5 h here and since 14 compilations have to be done,
that would amount to more than two days. I was told that long running jobs can
be a problem because network occasionally fails or because -ENOSPC errors come
up frequently.
Or do you see a way to make this kind of QA measure work with jenkins
nevertheless?
If it turns out that jenkins is not the best place to run such a job from time
to time then there is also AWS and I heard there are still plenty of credits to
burn. Though I have no clue at all about cloud stuff so if AWS is the better
option then I'd need somebody who'd show me the ropes.
Thank you!
cheers, josch
Reply to: