[02:49] <karstensrage> hmm
[02:50] <karstensrage> if i add a ppa as a dependency to another ppa then will adding just the 2nd one, pull the 1st one?
[02:50] <karstensrage> like it does for the build?
[03:06] <wgrant> karstensrage: PPA dependencies only affect builds.
[03:07] <karstensrage> rats
[03:07] <karstensrage> backporters are pissing me off
[03:07] <karstensrage> they arent backporting java8
[03:07] <karstensrage> or tomcat8
[03:07] <karstensrage> those are big packages
[03:08] <karstensrage> so what chance does my puny package have
[03:08] <wgrant> Big packages are much harder to backport, particularly things with very complex reverse dependencies like Java.
[03:09] <karstensrage> what is a reverse dependency?
[03:09] <karstensrage> i saw that but didnt understand it
[03:10] <wgrant> If A depends on B, A is a reverse dependency of B.
[03:10] <karstensrage> so just a dependency?
[03:11] <wgrant> The same relation, just from the opposite direction.
[03:11] <lifeless> but in reverse to the way that the system declares them
[03:11] <wgrant> eg. if I backport libc6, the reverse dependency tree includes just about everything, so it's very very risky
[03:12] <karstensrage> well i have a library and a pam_module that uses it
[03:12] <karstensrage> i dont think there are any reverse dependencies are there?
[03:13] <wgrant> Right, a package with few reverse dependencies is much lower risk, as it's unlikely to break other things. So it's easier to backport.
[03:13] <wgrant> Backporting something like Java is very high risk, as it could easily break anything that used Java.
[03:13] <wgrant> Which is why things like Java don't get backported so readily.
[03:14] <karstensrage> i guess i dont understand
[03:14] <karstensrage> they are talking about java8
[03:14] <karstensrage> which is separate from java7 or 6
[03:18] <karstensrage> from the backport request it seemed like the issue was finding "testers" for all the security updates java has
[07:45] <chrisccoulson> I keep seeing build failures like this: https://launchpad.net/~oxide-builds/+archive/ubuntu/oxide-trunk/+build/9761370
[07:45] <chrisccoulson> collect2: fatal error: ld terminated with signal 9 [Killed]
[07:45] <chrisccoulson> Any idea why?
[07:49] <wgrant> chrisccoulson: Knowing WebKit, it'll probably be running out of RAM.
[07:49] <chrisccoulson> well, blink. But yeah, probably
[07:49] <wgrant> chrisccoulson: Can you reduce the concurrency of the link stage?
[07:50] <chrisccoulson> wgrant, not really. Chromium has a build configuration that splits it up in to dozens of components (our chromium-browser package uses that), but it incurs an unacceptable startup time penalty on the phone and is an unsupported, developer-only option
[07:51] <chrisccoulson> I guess this ties in with another problem - we're regularly hitting the 32-bit address-space limit again on i386/armhf
[07:51] <chrisccoulson> We've already turned off debug symbols for blink, and we pass some options to gold to make it use a bit less memory
[07:51] <chrisccoulson> but we're close to having an unbuildable webengine on 32-bit architectures :(
[07:53] <chrisccoulson> eg, https://launchpadlibrarian.net/260075153/buildlog_ubuntu-xenial-armhf.oxide-qt_1.15.2-0ubuntu0.16.04.1~overlay1_BUILDING.txt.gz
[07:53] <wgrant> chrisccoulson: Right, you can't split the link, but I wonder if you're running multiple concurrent links.
[07:53] <wgrant> It seems unlikely that you're exhausting both RAM and swap with a single ld invocation.
[07:53] <chrisccoulson> wgrant, in this case, we're not
[07:54] <wgrant> Unless KHTML's latest incarnation has become seriously more over-impressive than it was a year ago.
[07:54] <wgrant> If you need more than 8GiB for a single linker process I really don't know what to suggest.
[07:54] <wgrant> That's sorta crazy.
[07:55] <wgrant> That can't come close to linking on i386.
[07:57] <chrisccoulson> wgrant, the x86-64 link uses just over 10GB ;)
[07:58] <wgrant> I miss the old days when software lived within its means.
[07:59] <chrisccoulson> Heh
[07:59] <chrisccoulson> wgrant, at some point, the only way we're going to be able to produce builds for 32-bit targets is to cross-compile it
[07:59] <chrisccoulson> (which I already do locally anyway)
[13:36] <morphis> cjwatson: any idea what is going on with the snap builds on launchpad today? getting failures while fetching running packages from the archive: https://launchpadlibrarian.net/260185417/buildlog_snap_ubuntu_xenial_arm64_modem-manager_BUILDING.txt.gz
[13:36] <morphis> this time its gcc-default but another time it was perl
[13:46] <cjwatson> morphis: can you save me some time and give me a link to the build on launchpad.net?
[13:46] <morphis> cjwatson: sure
[13:47] <cjwatson> should end with /+build/978 or similar
[13:47] <morphis> cjwatson: https://code.launchpad.net/~snappy-hwe-team/+snap/modem-manager
[13:47] <morphis> https://code.launchpad.net/~snappy-hwe-team/+snap/modem-manager/+build/978
[13:47] <cjwatson> that's the one, thanks
[13:47] <cjwatson> ok, so it's not the timeout class of bugs that I fixed a while back
[13:48] <morphis> yeah
[15:01] <cjwatson> morphis: I'm afraid this is probably going to be somewhat involved (logs don't indicate anything obvious, we'll need to set up a reproducer on dogfood and crank up debugging levels) and I don't have time to dig into it at the moment.  Best file a bug with what details you have so far.
[15:01] <morphis> cjwatson: can do that, against which project?
[15:02] <cjwatson> morphis: launchpad-buildd will do
[15:03] <cjwatson> it's probably technically rutabaga but whatever
[15:03] <morphis> ok
[23:15] <cjwatson> s390x builders will be going down in about 25 minutes for maintenance; expected downtime about an hour