[00:28] <slangasek> sigh, why is all of suitesparse in main
[00:28]  * slangasek slowly unpicks the migration knot
[00:43] <mwhudson> slangasek: thanks (or at least i assume that was you :-p)
[00:44] <slangasek> mwhudson: you're welcome ;)
[00:52] <elopio> slangasek: any idea why am I not getting snapcraft after adding proposed from the main archive to the sources?
[00:53] <elopio> http://paste.ubuntu.com/17106219/
[01:38] <elopio> arges: are you around?
[01:54] <jbicha> elopio: snapcraft is in the new queue because snapcraft-parser is a new binary
[01:55] <jbicha> https://launchpad.net/ubuntu/xenial/+queue
[02:14] <elopio> jbicha: damn. How can we move it forward?
[02:15] <jbicha> any new package has to be manually approved by one of https://launchpad.net/~ubuntu-archive
[02:19] <elopio> wgrant: hello :)
[02:20] <elopio> thanks for the info jbicha. I had no idea about that.
[02:22] <cjwatson> elopio: accepted
[02:22] <elopio> cjwatson: \o/ thank you!
[02:24] <mwhudson> where did queuebot go?
[02:26] <teward> it went to bed for the evening?  :P
[02:47] <elopio> is there anything else needed to get snapcraft into proposed? or just wait for the servers to sync?
[03:06] <cjwatson> elopio: just wait a bit
[03:06] <cjwatson> but anyway, I really really must stop optimising postgresql queries and GO TO BED
[03:15] <elopio> cjwatson: good night!
[11:26] <ChrisTownsend> slangasek: No, https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html still never completed.  I saw in the log on http://autopkgtest.ubuntu.com/running.shtml while it was running that it looked like it set up some sort of lxd(?), then it rebooted, then saw a bunch of lines that said something like "ssh: Cannot make secure connection.  Retry in 3 seconds..." and it seems to have timed out and failed.
[13:55] <sergiusens> infinity or bdmurray I was directed to you. I uploaded a package to SRU into xenial. Everything has been verified except for one small bug I'd rather have fixed before releasing. My question is about debian/changelog, -proposed has 2.10 with its changelog, should I upload 2.10.1 with a changelog entry of the fix only or should I replicate 2.10's changelog into 2.10.1. I am asking to know what to do that the infra would handle
[13:57] <ogra_> if you do that you most likely want to use -v2.10 when building the sroucne package so both changelog entires show up in the upload
[13:58] <cjwatson> You shouldn't replicate the changelog entry.  It used to be that you needed to do what ogra_ says (except he meant -v2.9 I think), but that should no longer be necessary.
[13:58] <cjwatson> I think you'll be fine with just a changelog entry describing the thing you're fixing in 2.10.1.
[13:58] <sergiusens> ogra_ yeah, 2.10.1 would go on top of 2.10 ... but last time I did that, the infra only marked the latest changelog for verification
[13:59] <ogra_> yeah, sorrym living in the past here :)
[13:59] <cjwatson> But if you want to be extra-safe, build with -v2.9.
[13:59] <sergiusens> cjwatson great I'll go with extra safe. Thanks
[14:00] <cjwatson> sergiusens: FWIW I believe I fixed the infrastructure to traverse all -proposed versions since the most recent in release/-updates in January 2013
[14:01] <cjwatson> Well I say infrastructure, it's not very infra, it's the web report generator, but anyway
[14:01] <sergiusens> cjwatson I will need to look into this issue I ran into then and report back :-)
[14:03] <cjwatson> It may depend on whether you think it's appropriate for all the bugs fixed in 2.10 to be marked for reverification even if they were already verified.
[14:03] <cjwatson> If the answer is yes, use -v2.9; if the answer is no, don't.
[15:57] <slashd> morning arges, LP: 1484740  affects "Trusty ", can you please nominate it for Trusty ?
[15:59] <arges> slashd: done
[15:59] <slashd> arges, tks
[16:31] <slangasek> ChrisTownsend: fwiw whatever problem landing-051 had with autopkgtesting, I see results on that excuses page now
[16:32] <ChrisTownsend> slangasek: Yeah, thanks, pitti helped me out.
[16:33] <slangasek> ChrisTownsend: ah - what was the problem?
[16:34] <ChrisTownsend> slangasek: I'm not really sure, but it was supposedly related to the PS outae yesterday.
[17:16] <ginggs> slangasek: hi, the test case for LP: #1556685 is in the SRU bug LP: #1556680
[18:40] <slangasek> ginggs: ok; did you see the previous message from pitti on bug #1556685?  it had been marked incomplete 8 days ago and was awaiting feedback
[18:41] <slangasek> ginggs: if you could please put a relevant test case in each bug linked from the SRU changelog, that would let the process run more smoothly
[18:41] <ginggs> slangasek: no sorry, i only saw it now, i didn't get subscribed to that bug
[18:41] <ginggs> the bug where pitti commented
[18:41] <slangasek> ginggs: thus, rejecting the SRU has the right effect of triggering action ;)
[18:42] <ginggs> slangasek: :)
[18:43] <slangasek> meanwhile, let's deal with the octave g++5 abi transition, which was done in Debian last September but never merged into Ubuntu until yakkety opened, hnnngh
[18:54] <ginggs> slangasek: i saw you promoted metis, thanks, so now suitesparse (which is mixed up with octave) is good to go
[18:54] <ginggs> i'm still having trouble decyphering http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[18:55] <ginggs> to me it looks like fsl might be one of the problems
[18:55] <ginggs> and in its buid log it looks like two different versions of suitesparse were used
[18:56] <ginggs> i'm not sure why fsl doesn't appear in the transition tracker though
[19:05] <slangasek> hmm I haven't checked transition trackers for it frankly
[21:14] <sergiusens> arges mind looking at https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=snapcraft really small one related to the conversation from earler
[21:24] <sergiusens> much appreciated
[21:26] <sergiusens> slangasek if you are still around, mind looking at ^
[21:27] <slangasek> sergiusens: looking
[21:29] <slangasek> sergiusens: please note that listing all of these bug references in your changelog for an SRU is going to slow you down; you're not using the exception process when you list individual bugfixes like this
[21:30] <slangasek> SRUs don't move until all of the referenced bugs are marked verification-done
[21:42] <sergiusens> slangasek I really don't mind the creating a bug for each item and I am certain elopio prefers this mechanism as well to make sure we never regress. The slow part for me is getting out of the unapproved queue :-)
[21:43] <slangasek> sergiusens: interestingly, I see that all the bugs referenced in 2.10 just flipped to verification-done... even though there's a regression that you're fixing with 2.10.1
[21:46] <sergiusens> slangasek yes, elopio decided to create a new bug which is the one mentioned in 2.10.1 I added the original bug that caused the bug to exist as a coment https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1590256
[21:46] <sergiusens> slangasek I could mark it as a dup if it satisfies SRU requirements
[21:47] <slangasek> sergiusens: well, to avoid accidental publication of SRUs that are verification-done, please make sure that one of the bugs for the SRU that you *don't* want published gets marked verification-failed instead :)
[21:49] <sergiusens> slangasek done
[21:49] <slangasek> ok
[21:50] <slangasek> once 2.10.1 shows up on http://people.canonical.com/~ubuntu-archive/pending-sru.html you can safely reset it
[22:10] <sergiusens> slangasek btw, should snapcraft be MIRed, I was under the impression it shouldn't but oversaw a question of the type "has it been done yet"
[22:33] <slangasek> sergiusens: things that we care about supporting ought to go into main, which means going through the MIR process
[22:41] <sergiusens> slangasek thanks I'll ask ogra_ for help on that as he's been doing a lot of those lately ;-)
[22:48] <elopio> slangasek: sergiusens: verification done for that bug. Should I mark as verification-done also the one that failed?
[22:49] <elopio> oh, Sergio already did that.
[22:49] <sergiusens> yup
[22:50] <sergiusens> now we wait I guess :-)
[23:37] <slangasek> elopio, sergiusens: if you're happy with snapcraft 2.10.1 (which is suggested by all the bugs being v-done), I can release it now
[23:48] <elopio> slangasek: yes, please.
[23:52] <slangasek> elopio: done
[23:58] <sergiusens> ty