Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format
Oh nice -- I didn't realize that pbuilder/cowbuilder actually created
chroots and all that, thought they were just an alternative to things
like debuild & gbp. Really should RTFM eh? :)
I'm working with the upstream maintainer to address the crash.
I notice that even if I disable the tests all together, the build's
failing because of issues with the symbols file (presumably g++
version changes generating different symbols or something). That wiki
page you linked me to earlier RE: C++ symbols files led me to this
interesting blog post:
http://www.eyrie.org/~eagle/journal/2012-02/001.html
Russ explains in more detail, but the interesting points:
"I wanted to give a final update of my experiment with adding symbols
files to C++ library packages.
In the end, I reverted the changes and have gone back to not providing
a symbols file, and instead just using shlibs. <...>
But there are also tool issues. The biggest that I ran into is that
symbols appear and disappear in the export list with different
versions of the compiler, <...>
<...> but I think that the level of work and remaining fragility
doesn't make sense for a lot of C++ libraries, at least right now
without more direct support in dpkg-gensymbols and other tool
improvements. <...>"
I'm thinking maybe I rip out the symbols file all together for now --
it sounds like the tooling isn't there for it yet. What do you think?
Cheers,
Tom
On Sun, Aug 18, 2013 at 2:04 PM, Vincent Bernat <bernat@debian.org> wrote:
> ❦ 18 août 2013 22:53 CEST, Tom Lee <debian@tomlee.co> :
>
>> Ah, the Debug.Log hang seems like it might relate to a missing
>> /proc/self/exe symlink -- probably because I didn't mount the /proc
>> filesystem. Here's the relevant bit of strace output:
>>
>> [pid 7463] write(3, "[ OK ] Exception.Exception"..., 143 <unfinished ...>
>> [pid 13045] readlink("/proc/self/exe", <unfinished ...>
>> [pid 7463] <... write resumed> ) = 143
>> [pid 13045] <... readlink resumed> 0x7fff11d94460, 512) = -1 ENOENT
>> (No such file or directory)
>> [pid 7463] read(0, "[ RUN ] Debug.Log\n", 8192) = 23
>> [pid 7463] write(1, "[ RUN ] Debug.Log\n", 23[ RUN ] Debug.Log
>> ) = 23
>> [pid 13045] futex(0x2aaaabaa75e0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
>> [pid 7463] write(3, "[ RUN ] Debug.Log\n", 23) = 23
>> [pid 7463] read(0,
>>
>> The last two futex(...) & read(...) calls wait around forever.
>>
>> Might be a silly question, but I'm guessing it's standard practice to
>> mount /proc when doing these chrooted builds?
>>
>> And assuming the build servers are using a chroot, can I also assume
>> they will mount procfs on /proc prior to executing a build?
>>
>> Either way, I'm going to mount /proc in my chroot & try again.
>
> Yes, you can count on /proc being present. And you should really try
> pbuilder or cowbuilder. This is just a matter of doing:
>
> cowbuilder --create
> cowbuilder --update
> cowbuilder --build your.dsc
> --
> panic("Oh boy, that early out of memory?");
> 2.2.16 /usr/src/linux/arch/mips/mm/init.c
--
Tom Lee / http://tomlee.co / @tglee
Reply to: