Re: [liblo] [ANN] liblo version 0.28 released

On Wed, Feb 5, 2014 at 2:22 PM, Felipe Sateler <fsa...@gm...> wrote:
> On Wed, Feb 5, 2014 at 10:05 AM, Stephen Sinclair <rad...@gm...> wrote:
>> On Wed, Feb 5, 2014 at 12:28 PM, Felipe Sateler <fsa...@gm...> wrote:
>
>>> At the end of the log we see the reason: "Build killed with signal
>>> TERM after 150 minutes of inactivity". Perhaps testlo is waiting for a
>>> message that never gets sent? I have to note that the build daemons
>>> have very restricted internet access so it may well not be possible to
>>> access the computer itself over the external IP address. This failure
>>> is different, as the build daemon killed the build after a timeout,
>>> instead of the build actually failing.
>>
>> Off the top of my head I can't think why the test would stall for 150
>> minutes, but perhaps there's an issue.  I thought I'd programmed
>> testlo with a limited number of tries while waiting for responses from
>> subtest.  I'll have to take a look.  Hard to debug when I can't
>> reproduce it though.
>>
>> (In particular I'm confused by the i386 failure, since I test on my
>> 32-bit laptop all the time. And why is there no x86_64 test?)
>
> The logs are recorded by the build daemons. Because my own machine in
> which I build and upload the packages is x86_64, no log gets recorded
> by the build daemons (there is no need to perform a x86_64 build).
>
> The problem is likely to be due to the restricted environment in which
> the builds are performed, because on my own machine the tests pass
> just fine.

Yes, I agree.  I wish I could reproduce the setup, I suppose there is
some information on how Debian build machines are configured.  It
never occurred to me to try building liblo in a chroot with the
headers from another kernel, for example ;-)

>>> Is it possible to tell testlo to only use localhost? That interface is
>>> known to be usable for builds.
>>
>> I'm not sure what the right approach is.  testlo does in principle
>> depend on a sort of normal networking environment, where it tries to
>> detect the machine's host address and sends messages back to itself.
>> Perhaps such tests could be disabled somehow, though currently testlo
>> and "make test" takes no arguments.  I suppose such a condition could
>> be specified as an option to configure..
>
> If testlo cannot work using only localhost, then perhaps I should just
> disable the tests. But forcing testlo to use localhost perhaps is
> sufficient to make the tests pass in such a restricted environment.

Well, we can make it work that way with an option, if necessary. I
have no problem doing a short-term 0.29 release just for Debian if it
comes to that.

>>> [1] https://buildd.debian.org/status/logs.php?pkg=liblo
>>
>> Thanks for this.  It would be great to be able to do such tests on
>> this Debian system before a release next time.
>
> Yeah, sorry. I never uploaded rc1 to experimental, because the
> testsuite hung even on a normal machine (I believe you fixed this
> shortly after the rc).
>
> I do intend to upload any rc to debian experimental, but I failed this
> time. Sorry.

No it's fine, I wasn't placing any blame, I just didn't fully
understand the resources available to Debian maintainers.  I wish I
had this build farm available at my fingertips for this kind of
testing ;)

I thought about doing an rc2 but since there were no more reports and
it built  and tested fine for me on 2 architectures and 3 OSs I
figured it was okay to just go ahead.

Still, I'm really curious why and where it is stalling during the
test.  Personally I wouldn't upload it until we figure it out.
Admittedly I've been meaning to fix up testlo to output more useful
and consistent logging information for some time.

Any ideas on how I could reproduce the Debian build environment? For
example are there any virtual machine images available for this
purpose?

Steve