On Fri, Jul 11, 2014 at 12:58 PM, Felipe Sateler <fsate...@debian.org> wrote: > On Fri, Jul 11, 2014 at 11:19 AM, Felipe Sateler <fsate...@debian.org> wrote: >> On Fri, Jul 11, 2014 at 10:40 AM, Jonas Smedegaard <d...@jones.dk> wrote: >>> Quoting Felipe Sateler (2014-07-11 15:55:34) >>>> On Fri, Jul 11, 2014 at 3:06 AM, Jonas Smedegaard <d...@jones.dk> wrote: >>>>> Quoting Felipe Sateler (2014-07-10 17:12:34) >>>>>> Ardour3 takes a long time to build. The mips and mipsel buildds >>>>>> killed the build after 150 and 300 minutes of inactivity. I managed >>>>>> to build ardour3 in the mipsel porterbox, so I don't think ardour >>>>>> has any real problem on mipsel. I was wondering if maybe we should >>>>>> restrict ardour to the architectures it is likely to be used. >>>>>> Otherwise we might need to ask that ardour be retried until it >>>>>> manages to print output fast enough to avoid getting killed. >>>>>> >>>>>> What do you think? >>>>> >>>>> I think we should not decide based on where it is likely to be used, >>>>> but here is is possible to use. >>>> >>>> In an ideal world, I would agree. But manpower is very short in the >>>> team, so prioritizing is of the essence. Spending time on ensuring >>>> builds on an architecture (close to) nobody uses is not a very good >>>> use of it. >>>> >>>> But, if you have a suggestion to ensure the build doesn't time out, >>>> I'm all ears :) >>> >>> Maybe I failed to understand, but seems to me that asking th ardour >>> build to be retired until not myeriously hanging on porter boxes is not >>> burdening man power (of the Multimedia team) but instead putting the >>> burden on the porting team where it belongs. >> >> The burden is on us due to having to track down a missing build. But >> most importantly it is a burden on our users because until the mipsel >> build is up again, ardour3 cannot migrate to testing. >> >>> >>> I find it wrong of us to try second-guess interests of Debian users. >>> >>> Particularly, looking at popularity contest is wrong here, IMO, as that >>> a) is generally inaccurate (contributions to it is voluntary and only >>> reflects internet-connected hosts) and b) tells only about past usage >>> patterns, not interests-if-available for next release of Debian and the >>> hardware that will then be supported. >> >> In general, I agree. I would love to be able to provide all packages >> in all archs. But it may not be feasible due to time constraints. >> >>> ...but to address your concrete question: I do not have ideas how to >>> reliably avoid builds hanging, but if not already tried I do have a >>> suggestion for that: Ask the porters, as it seems you have narrowed the >>> issue to be architecture-dependent (if not, then so much more reason >>> against treating it as such!). >> >> The problem, as far as I can see, is that the build takes too long. I >> built ardour3 in eder (a mipsel porterbox) successfully, and it took >> over 12 hours! >> >> If you look at the log I linked to, the build daemon killed the build >> after some time without activity. > > It turns out that waf prints its diagnostics on stderr instead of > stdout. For some reason, the buildd does not monitor stderr, so it > thought that the build had not printed anything for 5 hours! I think I > have this fixed by a patch, so lets see how this goes. I;m building > now
If that doesn't work out, what about asking the porters to mark ardour3 as NFS (not-for-as) in the buildd configuration, and have then ftp-master remove the existing binary packages from unstable? This way it is up to the porters to look after the package. Best, Reinhard _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers