| tsmithe | Hi, I spent yesterday trying to debug a mysterious build failure on amd64: "Session terminated, terminating shell ... after 150 minutes of inactivity". It turned out that it was because the memory requirements of my source under g++ were too high (around ~3.9GiB), so I refactored it to use at peak ~1.1GiB. Is there somewhere where limitations such as these are listed? The build log says "Build needed 02:31:09, 12892k disk space" -- it might help if it | 09:26 |
|---|---|---|
| tsmithe | could measure peak RAM usage. Or at least die in a more meaningful way..! | 09:26 |
| tsmithe | (NB, this was only in a PPA) | 09:26 |
| wgrant | tsmithe: It's not really feasible to give a better error message. In that case the build probably just timed out because it was thrashing. | 09:42 |
| wgrant | The normal buildd VM configurations have 2 or 4GiB of RAM allocated. | 09:43 |
| tsmithe | wgrant, hmm. OK. Thrashing swap, you mean? Couldn't there be an OOM killer and specific log message? Though I suppose mine is probably a fairly unusual case. | 09:47 |
| tsmithe | (And luckily, I had some suspicion as to its cause anyway) | 09:48 |
| wgrant | It never actually OOMed | 09:49 |
| wgrant | If it OOMed you'd get a nice Killed | 09:49 |
| wgrant | It was just swapping heavily | 09:49 |
| wgrant | And yeah, quite unusual that things get that big | 09:49 |
| wgrant | webkit's crept over the limit a couple of times, but then they have to split it up to make it buildable in the 3GiB address space available on x86. | 09:50 |
| tsmithe | wgrant, I think it's a gcc thing; it built fine on i686. | 10:00 |
| tsmithe | I do a lot of similar C++ template instantiations over various different types | 10:00 |
| tsmithe | and the library I'm using is header-only. So there's a lot of stuff for gcc to think about.. I just split the template instantiations out into other object files, and it's fine. | 10:01 |
| === tsmithe is now known as tsmithe_away | ||
| === tsmithe_away is now known as tsmithe | ||
| === tsmithe is now known as tsmithe_away | ||
| dpm | wgrant, the Launchpad Translations Coordinators team recently got a bunch of e-mails relating to translation import failures. Looking at them, they seem genuine failures due to syntax errors that weren't caught upstream. These are reported by gettext. However, when running gettext 0.18.1 on my machine, it does not actually report those errors. What version of gettext is Launchpad using for checking errors in imported .po files? | 13:51 |
| wgrant | dpm: the servers that that code is running on use gettext 0.17 | 13:52 |
| wgrant | I think that's probably what's in use. | 13:52 |
| dpm | wgrant, ah, that might explain it then. It seems that was the version that was shipped in Lucid. Is there any reason why we haven't updated gettext? | 13:53 |
| wgrant | dpm: The servers are still running lucid | 14:08 |
| wgrant | We'll hopefully fix that early next year | 14:08 |
| dpm | wgrant, ok, not a big issue, thanks | 14:11 |
| cjwatson | dpm: (that's https://rt.admin.canonical.com/Ticket/Display.html?id=62272) | 14:18 |
| cjwatson | who's working on that ticket now, btw? there've been no updates on it since the IS squad rotation | 14:18 |
| cjwatson | pjdc used to update it weekly or so | 14:19 |
| dpm | ack, thanks cjwatson | 14:19 |
| === jamespag` is now known as jamespage_realme | ||
| === Saviq_ is now known as Saviq | ||
| === nhandler_ is now known as nhandler | ||
| === Saviq_ is now known as Saviq | ||
| === Daviey_ is now known as Daviey | ||
| ricotz | hello, maybe an admin can take a look at this build while it is active which will get stuck on every qemu based builder https://launchpad.net/~gstreamer-developers/+archive/ppa/+build/5341252 | 16:46 |
| === hggdh_ is now known as hggdh | ||
| === lamont` is now known as lamont | ||
| TrinitronX | what is the recommended way to have launchpad build a package against multiple distributions of Ubuntu? | 18:49 |
| TrinitronX | I've uploaded a package for 13.10 (saucy) to a PPA, and I want to add the same package for 12.04 (precise). So I've changed 'saucy' to 'precise' in the debian/changelog file, rebuilt source package & uploaded via dput to my PPA but am getting an error: | 18:53 |
| TrinitronX | File mypackage_1.2.3-0ubuntu1.debian.tar.gz already exists in <LOCATION>, but uploaded version has different contents. | 18:53 |
| dobey | you should append ~$UBUNTUVERSION.1 to the version in debian/changelog. | 18:55 |
| dobey | such as 1.2.3-0ubuntu1~12.04.1 and 1.2.4-0ubuntu1~13.10.1 | 18:56 |
| TrinitronX | ok thanks! Is this convention documented anywhere? | 18:57 |
| dobey | on the PPA help page, yes | 18:57 |
| TrinitronX | ok, I managed to find it: https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning | 19:14 |
| apevec | hi, I was running script setting OpenStack Havana 2013.2.1 bugs to FixReleased and LP said to me: At least 4 queries/external actions issued in 0.98 seconds OOPS-13500bba52a398e7e948fa66cc85e298 | 21:08 |
| ubot5 | https://oops.canonical.com/?oopsid=OOPS-13500bba52a398e7e948fa66cc85e298 | 21:08 |
| apevec | hmm, I cannot access oops site | 21:09 |
| lifeless | wgrant: / StevenK: - you guys up yet ? :) | 21:09 |
| apevec | do I need to fix the script? | 21:09 |
| apevec | I've been using https://github.com/markmc/openstack-lp-scripts/blob/master/process-fixcommitted-bugs.py | 21:10 |
| lifeless | apevec: its 0800 their time, may need to be a little patient | 21:11 |
| apevec | lifeless, sure, I'll try that other script in the meantime | 21:12 |
| apevec | 2200 here :) | 21:12 |
| apevec | this one: https://github.com/openstack-infra/release-tools/blob/master/process_bugs.py | 21:13 |
| dobey | apevec: adding a little throttling to your script probably wouldn't hurt | 21:17 |
| apevec | dobey, so it does think I'm DoSing it | 21:17 |
| apevec | dobey, thanks, I'll try that | 21:17 |
| lifeless | dobey: apevec: there isn't any default throttling on LP | 21:18 |
| lifeless | unless things have changed massively | 21:18 |
| === Ursinha-afk is now known as Ursinha | ||
| apevec | lifeless, dobey - so time.sleep(1) doesn't help, and it looks like it's failing on bug 1257293 which has lots of tasks, maybe that's the issue? | 22:19 |
| ubot5 | bug 1257293 in Keystone havana "[messaging] QPID broadcast RPC requests to all servers for a given topic" [High,In progress] https://launchpad.net/bugs/1257293 | 22:19 |
| lifeless | apevec: possibly, but once we get the trace from the OOPS it will be trivially clear. | 22:20 |
| lifeless | anything else is black box guessing | 22:20 |
| dobey | apevec: are you tryi8ng to close all the tasks? | 22:20 |
| apevec | dobey, no, script runs per projects, this run was for nova | 22:20 |
| apevec | fyi, skipping two fat bugs 1257293 1257293 enabled script to process other bugs | 22:43 |
| ubot5 | bug 1257293 in Keystone havana "[messaging] QPID broadcast RPC requests to all servers for a given topic" [High,In progress] https://launchpad.net/bugs/1257293 | 22:43 |
| === Logan__ is now known as Logan_ | ||
| lifeless | StevenK: ^ | 22:51 |
| apevec | funnily enough, changing them through web ui worked | 22:59 |
| apevec | oops, above was double-paste error, fat ones are 1257293 and 1251757 | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!