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

On Wed, Feb 5, 2014 at 11:06 AM, Stephen Sinclair <rad...@gm...> wrote:
> 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 ;-)

There is some information at the following links, but I once tried to
replicate the buildd setup and failed... because the build daemon only
builds, it does not schedule.

The buildd setup, plus inspecting buildd-watcher script to figure out
how to schedule builds may get you up and running.

Note that there is also a chance that the host setup might affect
builds (say, firewall rules).

https://wiki.debian.org/buildd
https://buildd.debian.org/docs/buildd-setup.txt

The standard setup is debian stable host, with the chroot of the
target distribution (usually unstable).

>
>>>> 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.

Lets try patching the debian package first. I have no problem adding
patches that are part of the next release, and no need to
inconvenience everyone else.

>
>>>> [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.

It appears you have some confusion about the buildd network. I
cannot[1] use the buildd network directly. I have to upload to debian,
where the system will pickup the new uploads and schedule the builds.
So I have no choice but to upload and hope the latest change fixed it
:(.

On prereleases, I could upload to experimental to minimize problems
(ie, unstable users will not auto-upgrade to the prerelease version),
but there is still a public upload involved (ie, people can still
install it if they so desire).

[1] Now, there are plans to create personal archives for developers
precisely for this kind of pre-test, but not implemented yet.


> 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?

Besides the documents listed above, I don't think there is much else
about the build environment. AFAIK, there are no virtual machine
images.


-- 

Saludos,
Felipe Sateler