Ardour3 architecture list

[Reinhard Tartler]

On Fri, Jul 11, 2014 at 12:58 PM, Felipe Sateler <fsateler at debian.org> wrote:
> On Fri, Jul 11, 2014 at 11:19 AM, Felipe Sateler <fsateler at debian.org> wrote:
>> On Fri, Jul 11, 2014 at 10:40 AM, Jonas Smedegaard <dr at jones.dk> wrote:
>>> Quoting Felipe Sateler (2014-07-11 15:55:34)
>>>> On Fri, Jul 11, 2014 at 3:06 AM, Jonas Smedegaard <dr at 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