=== maclin1 is now known as maclin [08:46] Would someone look at an FFE for me please? LP: #1555586 [08:46] Launchpad bug 1555586 in lazarus (Ubuntu) "FFe: Sync lazarus 1.6+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1555586 [08:49] ginggs, done. please close the issue once built [08:50] doko: danke [09:06] 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] Would someone please look at another FFe to fix FTBFS please? LP: #1557527 [14:19] Launchpad bug 1557527 in doublecmd (Ubuntu) "FFe: Sync doublecmd 0.7.0-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1557527 [16:14] can someone please denew lynx? it's lynx-cur that got renamed [16:14] jdstrand: perhaps you? ^ [16:36] mdeslaur: looking [16:36] jdstrand: thanks [16:39] 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] jdstrand: great, thanks [16:39] 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] mdeslaur: hmm, it seems to be ftbfs [16:40] jdstrand: ah crud, I'll take a look, thanks [16:41] np [18:06] https://bugs.launchpad.net/ubuntu/+source/wxwidgets3.0/+bug/1329779 needs a ffe right? [18:06] Launchpad bug 1329779 in wxwidgets3.0 (Ubuntu) "[ffe] Sync from Debian Unstable | Migrate to gstreamer 1.0" [High,Confirmed] [18:06] it's about migrating wxwidgets3 from gstreamer 0.10 to 1.0 [18:06] which is a non trivial change [18:07] Bryan Quigley argued on the bug that it's a "bugfix" change but it doesn't really sounds like one [18:23] seb128: I would agree that it's FFe material [18:23] slangasek, thanks [18:25] I've updated it to be one [20:12] 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] teward: #? [20:13] it'd help if i weren't putting all my RAM to pending sbuild runs, standby [20:13] https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1549347 [20:13] Launchpad bug 1549347 in nginx (Ubuntu) "[FFe Requested] Please update nginx to 1.9.12" [Undecided,New] [20:13] 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] teward: Commented. [20:16] 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] 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] I'd guess accidental forkbomb. [20:26] hmm [20:26] Indeed, but curious that it would accidentally bomb only one arch. [20:26] The machine looks fine, though. [20:27] Logic error in configure? [20:27] 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] s/redmine/trac/ [20:28] cjwatson: CANNOT UTIME. [20:29] I'm afraid that error message has forever ruined the word "cannot" for me. At least, when it comes from a computer. [20:31] teward: Looks fine on a second pass, so whatever accidental bomb is in there, it's nondeterministic (and probably not arch-specific). [20:31] Whee. [20:32] * teward shrugs [20:32] infinity: it's odd, every other upload appears to get a nondeterministic failure for some odd reason [20:32] and it's never the same arch :/ [20:32] The sign of a quality upstream. [20:32] the nondeterministic failures I've seen are all ddeb related :/ [20:32] never had it blow up in the configure stages [20:33] Oh. The sign of a quality distro? :) [20:33] (or you have improper recipe dependencies in your debian/rules, which is more likely) [20:34] 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] Oh look, that issue just hit your armhf build. [20:34] indeed [20:34] * infinity doesn't retry it. [20:34] heheh [20:34] Not yet anyway. [20:34] i'm going to let the others finish first :) [20:35] they'll either blow up, or succeed, then retry :) [20:35] * teward appears to have a 'retry build' button :) [20:36] Yeah, I'm intentionally not retrying, so I can sucker pitti into looking at it. [20:36] It could well be a race in pkg-create-dbgsym. Or it could be your fault. [20:36] 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] 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] infinity: splitting time across five windows, standbly [20:42] infinity: ack [20:43] I'm curious why Debian is being aggressive with parallel builds, that part's from them [20:43] 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] teward: Nah, I wouldn't worry about it. I think I'm getting a handle on why out tooling sucks. [20:52] s/out/our/ [20:52] indeed. *is watching #-devel himself* === Guest93664 is now known as med_ [23:10] infinity, Any news on Base? [23:11] flexiondotorg: Not yet. Patience (and slightly less pinging). [23:11] infinity, OK. I was only pinging because I thought that was the instruction. I'll back off.