[08:46] <ginggs> Would someone look at an FFE for me please? LP: #1555586
[08:49] <doko> ginggs, done. please close the issue once built
[08:50] <ginggs> doko: danke
[09:06] <doko> when I'm looking at http://archive.ubuntu.com/ubuntu/dists/xenial/Contents-amd64.gz searching for vendor_ruby/2.2, I still see a lot of matches, while most of these packages were updated. why?
[14:19] <ginggs> Would someone please look at another FFe to fix FTBFS please? LP: #1557527
[16:14] <mdeslaur> can someone please denew lynx? it's lynx-cur that got renamed
[16:14] <mdeslaur> jdstrand: perhaps you? ^
[16:36] <jdstrand> mdeslaur: looking
[16:36] <mdeslaur> jdstrand: thanks
[16:39] <jdstrand> mdeslaur: ok it is building in xenial-proposed: https://launchpad.net/ubuntu/+source/lynx/2.8.9dev8-4. I also moved it so main since lynx-cur was in main in wily
[16:39] <mdeslaur> jdstrand: great, thanks
[16:39] <jdstrand> idr if the binaries will have to be moved to main if the source already is. need to keep an eye on that. will need a binNEW as well
[16:40] <jdstrand> mdeslaur: hmm, it seems to be ftbfs
[16:40] <mdeslaur> jdstrand: ah crud, I'll take a look, thanks
[16:41] <jdstrand> np
[18:06] <seb128> https://bugs.launchpad.net/ubuntu/+source/wxwidgets3.0/+bug/1329779 needs a ffe right?
[18:06] <seb128> it's about migrating wxwidgets3 from gstreamer 0.10 to 1.0
[18:06] <seb128> which is a non trivial change
[18:07] <seb128> Bryan Quigley argued on the bug that it's a "bugfix" change but it doesn't really sounds like one
[18:23] <slangasek> seb128: I would agree that it's FFe material
[18:23] <seb128> slangasek, thanks
[18:25] <seb128> I've updated it to be one
[20:12] <teward> so, i've got a pending nginx bug that needs FFe review before I upload; it's been there for about a month, and appears stuck somewhere in the queue, can anyone look at it?
[20:13] <infinity> teward: #?
[20:13] <teward> it'd help if i weren't putting all my RAM to pending sbuild runs, standby
[20:13] <teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1549347
[20:13] <teward> upload is ready to go, but i didn't want to upload without a review done (to avoid getting yelled at).  WOuld have asked earlier, but was ill the past week or so, which prevented it,
[20:15] <infinity> teward: Commented.
[20:16] <teward> infinity: thanks, as soon as the three workflow scripts which are running sbuilds for other things here are done, and extra cycles and RAM released back to the system, i'll upload.  :)
[20:25] <teward> hmm, that's new, infinity can you take a peek at this and give insights?  https://launchpadlibrarian.net/248257573/buildlog_ubuntu-xenial-s390x.nginx_1.9.12-0ubuntu1_BUILDING.txt.gz
[20:25]  * infinity raises his eyebrow.
[20:26]  * teward has never seen a "cannot fork" error in any nginx build on any arch, even in Debian archs
[20:26] <cjwatson> I'd guess accidental forkbomb.
[20:26] <teward> hmm
[20:26] <infinity> Indeed, but curious that it would accidentally bomb only one arch.
[20:26] <infinity> The machine looks fine, though.
[20:27] <cjwatson> Logic error in configure?
[20:27] <infinity> Ima give it another try and hope for random luck.
[20:27]  * teward starts scanning upstream redmine for weird arch config issues, just in case
[20:27] <teward> s/redmine/trac/
[20:28] <infinity> cjwatson: CANNOT UTIME.
[20:29] <infinity> I'm afraid that error message has forever ruined the word "cannot" for me.  At least, when it comes from a computer.
[20:31] <infinity> teward: Looks fine on a second pass, so whatever accidental bomb is in there, it's nondeterministic (and probably not arch-specific).
[20:31] <infinity> Whee.
[20:32]  * teward shrugs
[20:32] <teward> infinity: it's odd, every other upload appears to get a nondeterministic failure for some odd reason
[20:32] <teward> and it's never the same arch :/
[20:32] <infinity> The sign of a quality upstream.
[20:32] <teward> the nondeterministic failures I've seen are all ddeb related :/
[20:32] <teward> never had it blow up in the configure stages
[20:33] <infinity> Oh.  The sign of a quality distro? :)
[20:33] <infinity> (or you have improper recipe dependencies in your debian/rules, which is more likely)
[20:34] <teward> possibly, though it seems to be a recurring issue.  The debian/rules is essentially verbatim from Debian, minus http2 stuff per sec team request
[20:34] <infinity> Oh look, that issue just hit your armhf build.
[20:34] <teward> indeed
[20:34]  * infinity doesn't retry it.
[20:34] <teward> heheh
[20:34] <infinity> Not yet anyway.
[20:34] <teward> i'm going to let the others finish first :)
[20:35] <teward> they'll either blow up, or succeed, then retry :)
[20:35]  * teward appears to have a 'retry build' button :)
[20:36] <infinity> Yeah, I'm intentionally not retrying, so I can sucker pitti into looking at it.
[20:36] <infinity> It could well be a race in pkg-create-dbgsym.  Or it could be your fault.
[20:36] <teward> I wonder if it's a race, or if it's in the way the system runs - at one point I think you said it may be a result of how the rules define how the build should run, but that was long enough ago I lost logs
[20:42] <infinity> teward: See #-devel.  It's a bug in pkg-create-dbgsym that it doesn't have better locking, but could be worked around by not attempting to be so agressively parallel.  *shrug*
[20:42] <teward> infinity: splitting time across five windows, standbly
[20:42] <teward> infinity: ack
[20:43] <teward> I'm curious why Debian is being aggressive with parallel builds, that part's from them
[20:43] <teward> i think I'll poke them, and see if there's a specific reason they did it that way, before adding to the delta further
[20:52] <infinity> teward: Nah, I wouldn't worry about it.  I think I'm getting a handle on why out tooling sucks.
[20:52] <infinity> s/out/our/
[20:52] <teward> indeed.  *is watching #-devel himself*
[23:10] <flexiondotorg> infinity, Any news on Base?
[23:11] <infinity> flexiondotorg: Not yet.  Patience (and slightly less pinging).
[23:11] <flexiondotorg> infinity, OK. I was only pinging because I thought that was the instruction. I'll back off.