[02:22] <pnorman> I'm a maintainer on a PPA which keeps getting virtual memory exhausted errors when it tries to build a package. This isn't surprising, given the huge codebase of heavily templated C++ code that takes half an hour to build. We're looking at switching from g++ to clang++ which might fix this, but in the mean time, is it possible to supply our own VM for building the package so we can get a more recent version up?
[02:26] <wgrant> pnorman: It's not possible to do that. But if you're getting VM exhaustion errors it sounds like you're running out of 32-bit address space, not running out of RAM.
[02:27] <wgrant> A bigger virtual machine won't help won't help on 32-bit architectures if you can't compile within 4GiB of address space.
[02:30] <wgrant> We normally see such problems during linking rather than compilation, though. Are you really managing to exhaust the address space in a single compilation unit?
[02:33] <pnorman> You're right, that was from the 32 bit build. Let me find an error for the 64 bit
[02:36] <pnorman> https://launchpad.net/~mapnik/+archive/ubuntu/nightly-trunk/+build/6304351 is an amd64 and I see virtual memory exhausted: Cannot allocate memory towards the end
[02:39] <wgrant> pnorman: Are you sure something's not very wrong? The builders all now have twice the RAM they did a month ago; this could never have built before then.
[02:41] <pnorman> I'm building a more recent commit at work. Let me check when last build is (the one in the PPA)
[02:53] <pnorman> Let me try that failing build on my server
[03:37] <pnorman> building, but with -j6 so it shouldn't take the hour that the builders do
[03:48] <pnorman> Well 10 minutes in and it's using ~6GB of RAM. How much RAM do the builders have?
[04:33] <wgrant> pnorman: 4GB plus some swap.
[04:33] <wgrant> I don't recall how much swap.
[04:34] <wgrant> But that seems like an implausibly large amount of RAM for a single compilation unit to require, even if it's horrid C++.
[05:07] <pnorman> clang++ does it in about 2.5GB
[07:20] <pnorman> My build log inclues the message clang: error: unable to execute command: Killed and tells me to file a debian bug (https://launchpadlibrarian.net/183499083/buildlog_ubuntu-trusty-i386.mapnik_3.0.0%2Bdev20140829.git.8faa358-2~trusty1_FAILEDTOBUILD.txt.gz)
[07:23] <wgrant> pnorman: It probably got OOM-killed.
[07:24] <pnorman> I also have an amd64 build that's apparently failed, without a build log: https://launchpad.net/~pnorman/+archive/ubuntu/mapnik-testing/+build/6308209
[07:25] <pnorman> Hmm. I'd say it's time to abandon any thought of i386 on the PPAs. Which is probably fine, most users using the nightly trunk builds will have 8GB+ of RAM, and many will have 64GB+, so they're pretty obviously not i386
[07:27] <wgrant> I think your amd64 build might be driving them into swapdeath.
[07:28] <pnorman> Any way to diagnose? It'd surprise me, since clang++ built in <4GB https://github.com/mapnik/debian/issues/2#issuecomment-53838008
[07:28] <wgrant> Are you sure you're using the same version of clang?
[07:30] <pnorman> Ubuntu clang version 3.4-1ubuntu3 on my server, and I'm depending on clang-3.4. Without a build log, I can't be *sure*, but I think I am
[07:45] <pnorman> ah, there we go. someone rebuilt it and I see a buildlog now, which includes the same error as i386. I wonder if I should bisect this, see if something pushed up compile memory usage
[07:47] <wgrant> pnorman: Have you tried building it in a trusty chroot?
[07:47] <wgrant> If this ever built before, there is a serious regression somewhere.
[07:48] <pnorman> I've built it not in a chroot just now
[07:48] <wgrant> On trusty?
[07:49] <pnorman> ya.
[07:54] <geser> btw: your utopic build used g++ while only your trusty test build used clang
[07:56] <pnorman> hmm. while I'm not immediately concerned with utopic (precise and trusty are what's used most), I can't think of anything that would cause that, as there's no release-specific stuff going on
[07:58] <geser> "Build-Depends: g++-4.8" (from https://launchpadlibrarian.net/183497914/buildlog_ubuntu-utopic-amd64.mapnik_3.0.0%2Bdev20140829.git.8faa358-1~utopic1_FAILEDTOBUILD.txt.gz)
[08:03] <pnorman> rules passes CXX=/usr/bin/clang++ to ./configure
[08:03] <pnorman> Oh, that's -1. That was still on g++. -2 is clang++
[09:21] <mpt> Launchpad Janitor claims to have confirmed bug 1308321, but didn’t
[09:22] <mpt> I am confused
[10:05] <geser> change conflict perhaps? according to the activity log you both changed something in the same second
[19:51] <sergio-br2> i put one folder to bazaar ignore
[19:51] <sergio-br2> * i put the folder in the .bzrignore
[19:51] <sergio-br2> but if i delete some file from that folder, it does not ignores...
[19:52] <sergio-br2> what's the magic i need to do?
[19:53] <sergio-br2> i tried
[19:53] <sergio-br2> folder
[19:53] <sergio-br2> folder*
[19:53] <sergio-br2> folder/*
[21:59] <meth> does launchpad have pull requests or is it just bug reports that act like both issues and pull requests?