On 29-04-13 10:11, Christian T. Steigies wrote: > On Mon, Apr 29, 2013 at 09:44:27AM +0200, Wouter Verhelst wrote: >> On 28-04-13 19:12, Christian T. Steigies wrote: >>> On Mon, Apr 22, 2013 at 12:21:17PM +0200, Andreas Schwab wrote: >>>> "Christian T. Steigies" <c...@debian.org> writes: >>>>> how do I lower the file limit? >>>> ulimit(1) >>> Thanks, that has actually worked in a manual build: ulimit -n 512 >>> >>> I don't understand why it works, >> Presumably the test checks if it can actually open enough files to do >> its thing, and will exit with exit state 77 if not (which signals to >> automake that the test was skipped) > Where do I get one of those crystal balls? > :-)
That was just an educated guess... >>> but would it improve the performance of the >>> buildds if we set this by default? >> Highly unlikely. It's more likely that other builds will just start >> failing instead, because they can't open files. >> >> It made sense in this one particular case, but that doesn't mean it will >> be a good idea always. > So how would be handle that in a propper way? The test suite should be fixed so it doesn't time out on m68k. Then we don't need to set file limits anymore. > Is there a buildd option to change the ulimit per package? I don't think so. > Otherwise it would just fail again the next > time a buildd gets the package, after trying to build it for two days... > Or should this be set in debian/rules somewhere if arch==m68k? It shouldn't be set at all. Yes, we built it this way now, which is interesting, but it's really a workaround for what the real problem is. We should fix the real problem, not mess with workarounds. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517e4d2c.7040...@debian.org
