Re: curl

[Wouter Verhelst <wouter@debian.org>]

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" <cts@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.