[00:06] <doko> xnox, I didn't
[00:07] <xnox> doko, ok. build-essentials are not installable, and dpkg/arch.pm missing and e.g. s390x claims s390x does not exist in "any all" architecutres.
[00:07]  * xnox goes to sleep
[00:07] <xnox> wgrant, are you up?
[00:07] <xnox> https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/8917755
[00:08] <xnox> https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/8917758
[00:14] <xnox> oh, it's not monday yet in autstralia.
[00:14] <xnox> never mind.
[00:22] <xnox> https://launchpad.net/ubuntu/+source/mysql-5.6/5.6.28-1ubuntu2
[00:22] <xnox> chroots and/or xenial-proposed are b0rked
[00:32]  * infinity looks.
[00:42] <cjwatson> Dpkg/Arch.pm being missing is because the first thing the chroot upgrade does is remove build-essential dpkg-dev libdpkg-perl perl perl-modules
[00:42] <infinity> Indeed.
[00:42] <cjwatson> and it's because https://launchpad.net/ubuntu/+source/perl/5.22.1-5/+build/8916841 hasn't finished building yet
[00:42] <infinity> It's likely the perl/amd64 FTBFS.
[00:43] <infinity> Jinx.
[00:43] <cjwatson> so yeah, it's early hours of Sunday, just try not to build too much until perl is done :P
[00:43] <infinity> cjwatson: Hasn't finished because I retried it just now.  It had a testsuite failure that I'm hoping is flappy.
[00:43] <cjwatson> yeah, figured
[00:43] <cjwatson> I'll disable auto-sync temporarily to avoid compounding things
[00:43] <infinity> We're about due for a mass retry anyway.  I'll do the archive.
[00:44] <cjwatson> after perl has finished, I assume
[00:44] <infinity> Not sure I have the energy to do the walk-the-builders hunt for PPA builds.
[00:44] <infinity> Yes, after perl. :P
[00:44] <cjwatson> I have scripts for that kind of thing
[00:45] <infinity> Well, let's see if perl completes.
[00:45] <cjwatson> I basically just adapt http://paste.ubuntu.com/14785867/ for whatever I need for failure-du-jour
[00:45] <cjwatson> it's foul but works
[00:45] <infinity> If the failure is persistent, someone gets to firefight.  Or I'll remove it from proposed and fix on Monday.
[00:45] <infinity> Probably the latter.
[00:46] <cjwatson> do you remember what the test failure was?
[00:46] <cjwatson> I'm guessing it's transient unless it has anything to do with the umask change
[00:46] <infinity> Nope!  Not sober enough to science correctly.
[00:47] <infinity> But it's amd64, the odds of it flapping two different tests over two tries seem slim.
[01:27] <infinity> cjwatson: And second try looks good.
[01:35] <cjwatson> Oh good
[01:35]  * tsimonq2 wonders if this is a better place to report FTBFS findings...
[01:35] <teward> tsimonq2: depends on the fail-to-build issue, usually -devel if it's packages
[01:36] <tsimonq2> teward: ahh okay
[01:36] <teward> (though if it's related to something with the builders, either place will probably pick it up)
[01:36] <teward> tsimonq2: mind if I ask what's failing to build?
[01:36] <teward> :P
[01:36] <teward> (and don't tell me nginx, i will panic-attack if that's the case)
[01:37]  * tsimonq2 checks for nginx
[01:40] <cjwatson> tsimonq2: If it's "everything in xenial on !amd64", see above.
[01:41] <tsimonq2> cjwatson: what do you mean by that?
[01:41] <tsimonq2> !amd54
[01:41] <tsimonq2> !amd64
[01:41] <ubot5> AMD64 and Intel 64 are fully supported architectures on Ubuntu. See https://help.ubuntu.com/community/CommonQuestions#AMD64_Processors and http://en.wikipedia.org/wiki/Amd64 for more information.
[01:41] <cjwatson> "not amd64"
[01:41] <cjwatson> syntax from C or a bunch of other languages
[01:44] <teward> cjwatson: he's poking based on this report for things in main, to ID things that might have easy fixes - http://qa.ubuntuwire.org/ftbfs/
[01:44] <tsimonq2> ^
[01:44] <teward> fortunately, nginx is not on that list, i would have panicked if it were heh
[01:44] <cjwatson> oh, that.
[01:44] <infinity> Oh.  Well, if you want to find things with potentially easy fixes, read the build logs. :)
[01:44] <teward> ^ that
[01:44] <tsimonq2> well yeah that's what I have been doing
[01:45] <infinity> tsimonq2: Well, to put it another way, if someone like me had read the log and determined the easy fix, I would have uploaded it already.
[01:45] <tsimonq2> I look at ones with build-dep errors, try it in a schroot, and if it works it needs to be rebuilt on the archive
[01:45] <tsimonq2> or if the dependency is already resolved
[01:45] <tsimonq2> I have had to file MIRs before as well to solve errors
[01:50] <teward> that MIRs comment reminded me, i have to figure what Lua versions are being kept in Main for Xenial
[01:51] <teward> that's not documented anywhere is it
[01:51] <infinity> teward: "The fewer, the better", and if the number is higher than 1, then a few of us argue about it.
[01:52] <teward> infinity: at a glance, based on packages.ubuntu.com i'm seeing a couple lua 5 versions in Main
[01:52] <teward> 5.1, 5.2, and 5.3; the main reason I ask is if 5.2 or 5.3 are selected I'll have to mess with nginx-extras
[01:52] <teward> and then some people will be sad
[01:53] <teward> (Lua 5.2+ breaks the nginx-extras Lua module, and even though that's in Universe... :/)
[01:53] <teward> s/that's in/that binary package is in/
[01:53] <infinity> teward: I recall, yes.  I remember starting to port it at one point, and then realizing I didn't care and it should be upstream's problem. :P
[01:54] <teward> indeed
[01:54] <teward> and upstream said "Nope" so :P
[01:54] <teward> hence the reason i'm curious
[01:54] <teward> infinity: when is that type of decision usually finalized?  Before FF?
[01:54] <teward> i remember having some discussion on that in -devel i think, a while ago, but eh
[01:54] <infinity> teward: When we get around to looking at things with multiple versions and trying to force the issue.
[01:55] <teward> ok
[01:55] <infinity> teward: Not today. :)
[01:55] <teward> infinity: heheh, didn't think today :)
[01:55] <infinity> Alright, mass give-back (for the archive) is done, I'm going to go find pizza.
[01:56] <teward> infinity: what a coincidence i'm waiting for a pizza delivery heh
[02:23] <cjwatson> I've given back the last nine hours of failures across the board, including PPAs.
[02:23] <cjwatson> Non-amd64 failures, anyway
[02:23] <infinity> cjwatson: Ta.
[02:23] <cjwatson> And it turns out I actually failed to disable auto-sync, but this whole thing didn't span a time when it would have run anyway
[02:26] <infinity> cjwatson: FYI, I've kidnapped z13-028 for some glibc/gcc/binutils debugging, hence it being manual.
[02:26] <infinity> I'm pretty sure I have a host I'm meant to be doing that on, but equally sure I don't recall how to get to it. :P
[02:33] <cjwatson> np
[03:52] <tsimonq2> squashfs-tools needs a build retry, https://launchpadlibrarian.net/235788892/buildlog_ubuntu-xenial-i386.squashfs-tools_1%3A4.3-3_BUILDING.txt.gz is the log from the 18th, and here is the successful log from about 5 minutes ago on a local schroot: http://paste.ubuntu.com/14798469/
[03:52] <tsimonq2> squashfs-tools is in main, and I found it using FTBFS
[04:10] <tsimonq2> same with nmap, https://launchpadlibrarian.net/235788840/buildlog_ubuntu-xenial-i386.nmap_7.01-2_BUILDING.txt.gz and http://paste.ubuntu.com/14798563/
[04:13] <cjwatson> tsimonq2: sorry, no, your local testing is not rigorous enough.  In both cases, the source package in question is in main and the "missing" build-dependency is in universe, which is not currently allowed
[04:13] <cjwatson> tsimonq2: a retry will just fail the same way
[04:15] <tsimonq2> cjwatson: how do I update my schroot then to reflect this?
[04:15] <cjwatson> tsimonq2: to test builds in main, you need to make sure that your sbuild/schroot configuration is only using main, not universe etc.
[04:15] <tsimonq2> ahh okay
[04:15] <tsimonq2> thank you for the fast response, cjwatson :)
[04:15] <cjwatson> I've never bothered setting this up in a particularly fixed way; mostly it's clear enough and if not then I just temporarily hack a chroot's sources.list
[04:16] <cjwatson> could probably use --chroot-setup-commands or so if I could be bothered
[04:16] <tsimonq2> makes sense, thanks :)
[06:11] <tsimonq2> !info glib2.0
[06:11] <ubot5> libglib2.0-tests (source: glib2.0): GLib library of C routines - installed tests. In component universe, is optional. Version 2.46.1-1 (wily), package size 966 kB, installed size 7456 kB
[06:11] <tsimonq2> !info glib2.0 sid
[06:11] <ubot5> 'sid' is not a valid distribution: kubuntu-backports, kubuntu-experimental, kubuntu-updates, partner, precise, precise-backports, precise-proposed, stable, testing, trusty, trusty-backports, trusty-proposed, unstable, utopic, utopic-backports, utopic-proposed, vivid, vivid-backports, vivid-proposed, wily, wily-backports, wily-proposed, xenial, xenial-backports, xenial-proposed
[06:11] <tsimonq2> oh :(
[08:12] <xnox> ppc64el has very little builders... =(
[08:13] <xnox> cjwatson, infinity - thanks for fixing/retrying stuff
[08:16] <wgrant> xnox: Stabbing.
[08:16] <xnox> =)
[08:32] <xnox> could i get sponsoree merged into archive tools please? =)
[08:32] <xnox> https://code.launchpad.net/~xnox/ubuntu-archive-tools/sponsoree/+merge/280554
[08:34] <xnox> fun autopkgtest queue is great =)
[08:34] <xnox> xenial	1449	1648	1310	1588	1158
[15:36] <tsimonq2> flocculant: OH? well OBVIOUSLY I want my branch to be merged into the QA branch, is there a specific merge request where I didn't do this right? :D
[15:36] <tsimonq2> whoops wrong channel :P
=== michihenning is now known as michi