[02:22] 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] 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] 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] 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] You're right, that was from the 32 bit build. Let me find an error for the 64 bit [02:36] 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] 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] I'm building a more recent commit at work. Let me check when last build is (the one in the PPA) [02:53] Let me try that failing build on my server === s8321414_ is now known as s8321414 [03:37] building, but with -j6 so it shouldn't take the hour that the builders do [03:48] Well 10 minutes in and it's using ~6GB of RAM. How much RAM do the builders have? [04:33] pnorman: 4GB plus some swap. [04:33] I don't recall how much swap. [04:34] 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] clang++ does it in about 2.5GB [07:20] 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] pnorman: It probably got OOM-killed. [07:24] 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] 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] I think your amd64 build might be driving them into swapdeath. [07:28] Any way to diagnose? It'd surprise me, since clang++ built in <4GB https://github.com/mapnik/debian/issues/2#issuecomment-53838008 [07:28] Are you sure you're using the same version of clang? [07:30] 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] 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] pnorman: Have you tried building it in a trusty chroot? [07:47] If this ever built before, there is a serious regression somewhere. [07:48] I've built it not in a chroot just now [07:48] On trusty? [07:49] ya. [07:54] btw: your utopic build used g++ while only your trusty test build used clang [07:56] 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] "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] rules passes CXX=/usr/bin/clang++ to ./configure [08:03] Oh, that's -1. That was still on g++. -2 is clang++ [09:21] Launchpad Janitor claims to have confirmed bug 1308321, but didn’t [09:21] bug 1308321 in unity (Ubuntu) "Can't open app from unity panel twice, only first time works" [Undecided,New] https://launchpad.net/bugs/1308321 [09:22] I am confused === Trevinho_ is now known as Trevinho === vidplace7_ is now known as vidplace7 === Quintasan_ is now known as Quintasan === daker_ is now known as daker [10:05] change conflict perhaps? according to the activity log you both changed something in the same second === semiosis_ is now known as semiosis === elijah__ is now known as elijah === zoktar_ is now known as zoktar === popey_ is now known as popey === FourDollars_ is now known as FourDollars === cprov__ is now known as cprov === dch_ is now known as dch === ctracey_ is now known as ctracey === jjox` is now known as jjox === FloSoft_ is now known as FloSoft === heroux_ is now known as heroux === ral_ is now known as ral === BradCrittenden is now known as bac === beuno_ is now known as beuno === Pici` is now known as Pici === mthaddon` is now known as mthaddon === dobey_ is now known as dobey === TRB143__ is now known as TRB143 === cjwatson_ is now known as cjwatson [19:51] i put one folder to bazaar ignore [19:51] * i put the folder in the .bzrignore [19:51] but if i delete some file from that folder, it does not ignores... [19:52] what's the magic i need to do? [19:53] i tried [19:53] folder [19:53] folder* [19:53] folder/* === RagingComput is now known as RagingComputer === jjox` is now known as jjox === NikitaKonovalov2 is now known as NikitaKonovalov === Quintasan_ is now known as Quintasan [21:59] does launchpad have pull requests or is it just bug reports that act like both issues and pull requests? === lifeless1 is now known as lifeless