User1: hmm
User1: if i add a ppa as a dependency to another ppa then will adding just the 2nd one, pull the 1st one?
User1: like it does for the build?
User2: User1 PPA dependencies only affect builds.
User1: rats
User1: backporters are pissing me off
User1: they arent backporting java8
User1: or tomcat8
User1: those are big packages
User1: so what chance does my puny package have
User2: Big packages are much harder to backport, particularly things with very complex reverse dependencies like Java.
User1: what is a reverse dependency?
User1: i saw that but didnt understand it
User2: If A depends on B, A is a reverse dependency of B.
User1: so just a dependency?
User2: The same relation, just from the opposite direction.
User3: but in reverse to the way that the system declares them
User2: eg. if I backport libc6, the reverse dependency tree includes just about everything, so it's very very risky
User1: well i have a library and a pam_module that uses it
User1: i dont think there are any reverse dependencies are there?
User2: 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.
User2: Backporting something like Java is very high risk, as it could easily break anything that used Java.
User2: Which is why things like Java don't get backported so readily.
User1: i guess i dont understand
User1: they are talking about java8
User1: which is separate from java7 or 6
User1: from the backport request it seemed like the issue was finding "testers" for all the security updates java has
User4: I keep seeing build failures like this: https://launchpad.net/~oxide-builds/+archive/ubuntu/oxide-trunk/+build/9761370
User4: collect2: fatal error: ld terminated with signal 9 [Killed]
User4: Any idea why?
User2: User4 Knowing WebKit, it'll probably be running out of RAM.
User4: well, blink. But yeah, probably
User2: User4 Can you reduce the concurrency of the link stage?
User4: 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
User4: I guess this ties in with another problem - we're regularly hitting the 32-bit address-space limit again on i386/armhf
User4: We've already turned off debug symbols for blink, and we pass some options to gold to make it use a bit less memory
User4: but we're close to having an unbuildable webengine on 32-bit architectures :(
User4: eg, https://launchpadlibrarian.net/260075153/buildlog_ubuntu-xenial-armhf.oxide-qt_1.15.2-0ubuntu91.69.162.6~overlay1_BUILDING.txt.gz
User2: User4 Right, you can't split the link, but I wonder if you're running multiple concurrent links.
User2: It seems unlikely that you're exhausting both RAM and swap with a single ld invocation.
User4: wgrant, in this case, we're not
User2: Unless KHTML's latest incarnation has become seriously more over-impressive than it was a year ago.
User2: If you need more than 8GiB for a single linker process I really don't know what to suggest.
User2: That's sorta crazy.
User2: That can't come close to linking on i386.
User4: wgrant, the x86-64 link uses just over 10GB ;)
User2: I miss the old days when software lived within its means.
User4: Heh
User4: 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
User4: (which I already do locally anyway)
User5: User6 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
User5: this time its gcc-default but another time it was perl
User6: User5 can you save me some time and give me a link to the build on launchpad.net?
User5: User6 sure
User6: should end with /+build/978 or similar
User5: User6 https://code.launchpad.net/~snappy-hwe-team/+snap/modem-manager
User5: https://code.launchpad.net/~snappy-hwe-team/+snap/modem-manager/+build/978
User6: that's the one, thanks
User6: ok, so it's not the timeout class of bugs that I fixed a while back
User5: yeah
User6: User5 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.
User5: User6 can do that, against which project?
User6: User5 launchpad-buildd will do
User6: it's probably technically rutabaga but whatever
User5: ok
User6: s390x builders will be going down in about 25 minutes for maintenance; expected downtime about an hour
launchpad
Ubuntu IRC