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 <ber...@debian.org> wrote: > ❦ 18 août 2013 22:53 CEST, Tom Lee <deb...@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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakwfpq8azx1xzqbdjotyhcf63eruk4u8y_zixtvo91jhoxm...@mail.gmail.com
