[07:02] <pete-woods> cjwatson: hi, as the guy who tends to push my HUD uploads into proposed, I just wondered if you could take a look at the HUD upload in the trusty queue? (the current version in proposed has a stupid crash bug in it)
[07:03] <pete-woods> alternatively (as someone who is pretty new to the process) if I'm supposed to wait longer, that's also fine
[07:47] <cjwatson> pete-woods: am I?  I think I did it once or twice :)
[07:48] <cjwatson> pete-woods: but sure, I can have a look
[07:48] <pete-woods> cjwatson: you are that guy :) and it has been much appreciated in the past
[07:52] <cjwatson> pete-woods: the changelog delta looks like http://paste.ubuntu.com/7534921/ and doesn't actually correspond to the changes in the package in any way ...
[07:53] <cjwatson> pete-woods: would it be possible to redo this in a way that actually branches from the previous version in trusty?  this is really confusing
[07:53] <cjwatson> and then specifically describes what changes in this upload
[07:54] <cjwatson> pete-woods: http://paste.ubuntu.com/7534932/ is the full diff I'm seeing here, and I would expect to see a changelog that describes that
[08:09] <pete-woods> cjohnston: sure, I can include that change, I hadn't realised we'd had a non-ci-train upload to trusty
[08:09] <pete-woods> cjwatson: ^ whoops
[08:10] <pete-woods> obviously this is going to add a couple of days on for me to get the whole thing all the way through ci-train again
[08:12] <cjwatson> pete-woods: ok, thanks, rejected for now then, sorry for the inconvenience/delay
[08:13] <cjwatson> hopefully it won't be as bad as a couple of days, depending on silo availability
[08:13] <pete-woods> cjwatson: I think the reason that it's really confusing is that I was basically told my the CI guys just to imagine that the proposed upload never happened
[08:13] <cjwatson> but I don't think that upload would have worked with our SRU tracking tools
[08:13] <pete-woods> *by
[08:13] <cjwatson> well, maybe, but the changelog needs to describe what's changed!
[08:13] <pete-woods> sure, will make sure that happens
[08:13] <cjwatson> reading that changelog diff, the only interpretation I can derive from it is that it's a no-change rebuild
[08:13] <cjwatson> which clearly wasn't the case
[08:35] <didrocks> cjwatson: http://people.canonical.com/~ubuntu-archive/cicopy.log FYI
[08:36] <didrocks> cjwatson: stgraber: also, I restricted the copy list to the silos ppas and reject otherwise any other source
[08:36] <didrocks> cjwatson: any errors/reject from latest run will show up there, at least, it will enable to know for now if the process is stuck
[08:37] <didrocks> sil2100: FYI ^
[08:44] <cjwatson> didah, cool, thanks
[08:44] <cjwatson> oh, he left
[08:44] <cjwatson> DIDAH
[09:20] <cjwatson> Laney: trying an ubuntu-desktop-next image build now
[09:20] <cjwatson> let's see how excitingly it fails :)
[09:26] <Laney> cjwatson: oh, cool
[09:26] <Laney> did that second cdimage branch get merged?
[09:35] <cjwatson> Laney: oh ... er, cough, I might have forgotten that
[09:36] <Laney> :)
[09:36] <cjwatson> NOPE
[09:36] <Laney> do you understand the failure?
[09:36] <cjwatson> haven't looked yet, will do
[09:36]  * Laney uploads livecd-rootfs
[09:37] <Laney> s/metapackage/task/
[09:37] <cjwatson> was that the failure, or something else?
[09:38] <Laney> E: Unable to locate package linux-mx5
[09:38] <Laney> E: Unable to locate package linux-omap
[09:38] <Laney> not sure where that comes from
[09:38] <infinity> Laney: In which build?
[09:38] <Laney> -desktop-next
[09:39] <cjwatson> perhaps wrong --linux-flavours or however it's spelled
[09:39] <cjwatson> since
[09:39] <cjwatson> /usr/share/live/build/functions/defaults.sh:                    LB_LINUX_FLAVOURS="${LB_LINUX_FLAVOURS:-mx5 omap}"
[09:39] <infinity> Hrm, if this log existed somewhere, that would help.
[09:39] <infinity> Anyhow, yeah, we always specify ARM flavours by hand.
[09:40] <cjwatson> so I think livecd-rootfs needs an ubuntu-desktop-next block that sets KERNEL_FLAVOURS
[09:41] <ogra_> well
[09:41] <cjwatson> ubuntu-touch sets KERNEL_FLAVOURS=none so that's not an issue there
[09:41] <ogra_> it shouldnt go down that code path for x86 builds at all
[09:41] <cjwatson> should we actually be building ubuntu-desktop-next for armhf at all?
[09:41] <cjwatson> ogra_: this is an ubuntu-desktop-next/armhf failure
[09:41] <cjwatson> we possibly just shouldn't build that
[09:41] <ogra_> definitely not
[09:41] <ogra_> we wouldnt have any drivers anyway
[09:42] <cjwatson> -ubuntu-desktop-next    *                       *                       amd64 armhf i386
[09:42] <cjwatson> +ubuntu-desktop-next    *                       *                       amd64 i386
[09:42] <cjwatson> right, so that?
[09:42] <ogra_> ++
[09:42] <cjwatson> Laney: ?
[09:42] <cjwatson> (just to double-check)
[09:42] <Laney> works for me
[09:43] <cjwatson> ok, committed
[09:43] <cjwatson> trying the non-livefs bit again
[09:48] <cjwatson> volid too long, figures
[09:49] <cjwatson> Laney: can we s/Ubuntu-Desktop-Next-Preview/Ubuntu-Desktop-Next/?
[09:49] <cjwatson> I think the Next in there is enough
[09:49] <cjwatson> and it would make the volume ID fit
[09:51] <Laney> cjwatson: okay, seems fine - I was cribbing from touch there
[09:51] <Laney> could you document the size limit?
[09:52] <cjwatson> It varies a lot but I can at least explain the general parameters
[09:52] <cjwatson> well, a bit
[09:55] <cjwatson> Laney: documented in a comment
[09:55] <cjwatson> and retrying
[09:57] <Laney> vielen dank
[10:00] <cjwatson> KeyError: "Product 'Ubuntu Desktop (Unity 8) amd64' not found"
[10:00] <cjwatson> is that on the tracker?
[10:00] <Laney> iso tracker I guess
[10:00] <Laney> let me try to make that
[10:00] <cjwatson> indeed, I thought it had been created
[10:03] <Laney> does that look okay?
[10:06] <cjwatson> Laney: yep, posted
[10:07] <cjwatson> Laney: though no download links
[10:08] <cjwatson> Laney: http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/current/ but you'll need to look from outside the sprint network
[10:08] <cjwatson> for now
[10:09] <Laney> I think I'm not being proxied because I can see that :)
[10:09] <Laney> cheers
[10:09] <cjwatson> ok, cool
[10:09] <cjwatson> will leave the rest to you then
[10:10] <Laney> should be enough to get going
[10:13] <RAOF> infinity: Going to book a time for AA training for arges and me?
[10:16] <mlankhorst> Anonymous Alcoholics?
[10:18] <infinity> RAOF: Maybe.  Are you quite meetingy?
[10:19] <RAOF> infinity: I have moderate meetingyness.
[10:19] <RAOF> A couple of meetings a day.
[10:20] <stgraber> AA training meeting, location: the bar :)
[10:20] <ogra_> ++
[10:20] <infinity> RAOF: Kay, shouldn't be too hard for us to meet up, then.
[10:20] <RAOF> Yeah.
[13:14] <xnox> stgraber: or cjwatson: can you run britney manually? (to kick the adt job result refresh and possible migration?!)
[13:20] <cjwatson> xnox: running
[13:21] <xnox> ta
[13:22] <cjwatson> final: libunicode-collate-perl,miniupnpd
[13:22] <cjwatson> doesn't sound like what you wanted, but :)
[13:24] <cjwatson> nut's still saying regression?
[13:24] <xnox> cjwatson: strange http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lsb yet nut is green in both public and private
[13:24] <xnox> cjwatson: and openvswitch should be ignored.
[13:25] <cjwatson> how about I try rerunning that job
[13:25] <cjwatson> sometimes it fails to notice
[13:25] <xnox> cjwatson: nut, is very very flaky
[13:25] <cjwatson> "should be ignored" - as in you want somebody to force it?
[13:25] <xnox> cjwatson: it already has been, by stgraber
[13:25] <cjwatson> err
[13:25] <cjwatson> not shown as such
[13:26] <cjwatson> stgraber: wrong openvswitch version
[13:27] <cjwatson> I've retried nut, let's hope
[13:27] <cjwatson> adt-britney is still a bit buggy sometimes :-/
[13:28] <xnox> cjwatson: stgraber: probably mid-air collision. =) i did binNMU upload just after stgraber commited the ignore =(
[13:28] <cjwatson> the versions are pretty radically different
[13:28] <cjwatson> so unless you binNMUed 2.1.2-0ubuntu1 as 2.0.1+git20140120-0ubuntu2
[13:29] <cjwatson> in which case I may have to hurt you
[13:29] <xnox> force-badtest openvswitch/2.1.2-0ubuntu1 vs 2.1.2-0ubuntu2
[13:29] <xnox> cjwatson: does one skip version in -release, or in -proposed?
[13:29] <cjwatson> "autopkgtest for openvswitch 2.0.1+git20140120-0ubuntu2: Regression (Jenkins: public, private)"
[13:29] <xnox> cjwatson: oh, that's from the times when britney used to "forget" the tests.
[13:29] <cjwatson> I'd say release unless openvswitch is migrating at the same time
[13:29] <cjwatson> oh, but that's the trusty version
[13:29] <cjwatson> wtf
[13:30] <cjwatson> I have no idea, maybe we'll have to force-skiptest lsb once the rest is ready
[13:30] <stgraber> cjwatson: oh, I copy/pasted from rmadison, I wonder how I messed that up...
[13:30] <apw> cjwatson, that .html has been getting the wrong version in those lines recently, i think jibel is aware
[13:31] <cjwatson> stgraber: don't think you did, looks like an infra failure
[13:31] <apw> (if we are talking about test versions in failures)
[13:31] <cjwatson> apw: yeah.  oww.  thanks
[13:31] <apw> cjwatson, i believe if you look at the result it is for the right version, just the text
[13:31] <cjwatson> yeah but that would also confuse force versioning
[13:32] <xnox> cjwatson: given that all tests are fine, can we whitelist sysv to go in, please?
[13:32] <xnox> (to unblock building in the ppas)
[13:32] <cjwatson> we need to get lsb done for that
[13:32] <xnox> yeap, both lsb + sysv.
[13:33] <cjwatson> stgraber: could you hack the version to match the wrong thing in excuses?
[13:33] <cjwatson> under http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lsb
[13:33] <cjwatson> maybe even add that version as another hint line
[13:34] <cjwatson> it's not helping that http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-openvswitch/lastBuild/ARCH=amd64,label=adt/console is still running, but ...
[13:34] <stgraber> cjwatson: sure
[13:34] <cjwatson> ta
[13:36] <cjwatson> rerunning
[13:36] <pitti> stgraber: oops, I've been meaning to be there, I blame my server reboot a few days ago; sorry
[13:36] <stgraber> :)
[13:37] <pitti> stgraber: I can also edit the history file, if that helps
[13:37] <cjwatson> too late (hopefully)
[13:37] <cjwatson> let's see about this run
[13:38] <xnox> "Overriding force-badtest[openvswitch] = ('2.1.2-0ubuntu1', 'stgraber', 'None') with ('2.0.1+git20140120-0ubuntu2', 'stgraber', 'None')"
[13:39] <xnox> \o/ lsb accepted.
[13:40] <cjwatson> very slow for some reason but it is working on lsb
[13:40] <cjwatson> and friends
[13:40] <pitti> it's got a lot of friends by now :)
[13:40] <pitti> cjwatson: thanks
[13:42] <cjwatson> final: acpid,at,autofs,avahi,bluez,console-setup,cryptsetup,cups,gdm,ifupdown,lightdm,lsb,munin,openssh,openvswitch,procps,pulseaudio,rpcbind,rsyslog,slim,systemd,sysvinit
[13:42] <pitti> so mysql and friends are straggling due to taking long to build, but the above looks good already
[13:51] <xnox> \o/
[13:51] <xnox> cron would be nice, no?!
[14:10] <RAOF> bregma: The unity diff would have been smaller if you didn't have nonfunctional changes in it.
[14:21] <rcj> infinity, Would you be able to review the SRU in bug #1275656?  Stephane helped me with this last week but is unavailable.
[14:34] <infinity> rcj: He's about as available as I am..
[14:35] <infinity> stgraber: If you have recent context on the above, can you help out?
[14:35] <rcj> infinity, no problem.  I didn't see stgraber online (because I can't read).
[14:46] <rcj> stgraber, I corrected the version for the precise package and changed the naming from *hwe to *lts-trusty for SRU in bug #1275656
[15:12] <xnox> Verifying ubuntu/utopic-desktop-i386.iso
[15:12] <xnox> !!! Verification failed !!!
[15:12] <xnox> that's pulling current/ image.
[15:13] <cjwatson> sassenfrassen
[15:13] <xnox> ditto server
[15:13] <cjwatson> will look properly later
[15:13]  * xnox ponders to add static image/shasum verification to utah to catch these in qa
[15:14] <xnox> oh, proposed are fine, and static validation doesn't run against current/ probably.
[15:44] <tgm4883> Is 12.10 still supported? It's marked as such on launchpad
[15:44] <tgm4883> specifically, it got changed from obsolete to supported
[15:55] <cjwatson> tgm4883: there's going to be one last kernel publication, which is why I changed it back to supported; and then it will be obsolete after that.
[15:55] <tgm4883> cjwatson: ah ok, when is that going to happen?
[15:55] <cjwatson> though I see that kernel was published yesterday, apparently
[15:55] <cjwatson> I'll check with Adam on that
[15:55] <cjwatson> tgm4883: why does it matter though? :)
[15:55] <cjwatson> the short answer is you can stop caring about quantal
[15:56] <cjwatson> regardless of the LP status
[15:56] <tgm4883> cjwatson: it's not a big thing, but we have a graphic that gets updated via the launchpad API when our MythTV daily builds happen and it's publically available at   http://www.mythbuntu.org/repos
[15:56] <cjwatson> well, please don't ask in #launchpad for this again, it broke us :P
[15:57] <infinity> Very soon.
[15:57] <tgm4883> cjwatson: is this just a one off or something that is going to happen for future releases as well?
[15:57] <cjwatson> I don't know
[15:58] <cjwatson> hopefully a one-off
[15:58] <tgm4883> cjwatson: fair enough. I'll just stick with how we're pulling the data. I dug into it because I thought somehow our build scripts were wrong
[17:04] <zul> can a SRU team member please look at https://bugs.launchpad.net/nova/+bug/1297962 please
[23:34] <gaughen> infinity, slangasek, cjwatson, somebody?  could we get some love on zul's SRU request for nova compute ( https://bugs.launchpad.net/nova/+bug/1297962). pretty please?