Re: Ardour3 architecture list
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
Re: Ardour3 architecture list
Quoting Reinhard Tartler (2014-07-12 15:21:42) 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 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 [w]here is is possible to use. [...] 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! [...] 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 Sounds promising! Fingers crossed that it was the right fix... :-) 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. For the record, I am fine with that as well: It is not that I strongly believe that Ardour is suitable for MIPS specifically, but that porters should decide, not us. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Ardour3 architecture list
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 This appears to have worked, although we may have gotten a more powerful buildd this time. Time will tell if this fixes the problem for good -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Ardour3 architecture list
On Fri, Jul 11, 2014 at 3:06 AM, Jonas Smedegaard d...@jones.dk wrote: [resent - to list this time, as intended] 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 :) -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Ardour3 architecture list
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. 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. ...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!). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Ardour3 architecture list
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. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Ardour3 architecture list
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. I just realized I didn't post the link before. Sorry! Here it is: https://buildd.debian.org/status/logs.php?pkg=ardour3ver=3.5.380~dfsg-2suite=sid -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Ardour3 architecture list
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 -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Ardour3 architecture list
Hi all, 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? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
