[04:00] <michi_> cjwatson: ping
[08:40] <apw> michi, always best to include some details for when the pingee does appear
[08:45] <michi> Ah, yes, sorry!
[09:34] <cjwatson> michi: ?
[09:35] <michi> cjwatson: Hi
[09:35] <michi> Just wanted to check about the process for getting failed autopkg tests restarted.
[09:35] <michi> It seems really awkward for me to have to bother a core dev once a day until it finally works again.
[09:35] <cjwatson> sorry, I don't know about the process, I'm just a user of it.
[09:36] <michi> Right.
[09:36] <apw> (now if you had said that originally someone would likely have already answered)
[09:36] <michi> Well, I’m stuck on this one: https://requests.ci-train.ubuntu.com/static/britney/ticket-1670/landing-016-vivid/excuses.html
[09:36] <cjwatson> you might also try finding someone in your timezone rather than somebody as far away from your timezone as it's possible to be ...
[09:36] <michi> :)
[09:36] <michi> I don’t know where all the core devs are. I guess I can trawl through the launchpad team.
[09:36] <cjwatson> michi: retried
[09:36] <michi> Thank you!
[09:37] <apw> michi, i take it you don't have upload rights for that package then ?   i think that is the gating factor.
[09:37] <michi> What, for thumbnailer?
[09:37] <apw> right for that
[09:38] <michi> We own the project, but we can only release via CI train.
[09:38] <apw> right but if you have upload rights for it, that gates retry button access
[09:38] <cjwatson> for person in lp.people['ubuntu-core-dev'].members: print(person.name, person.time_zone)
[09:38] <michi> I tried the retry button and was told that I’m not allowed to :)
[09:38] <apw> you don't have to use them
[09:38] <michi> cjwatson: thanks!
[09:39] <michi> Don’t have to use core devs, you mean?
[09:39] <seb128> you also don't need to ping individuals
[09:39] <michi> The retry button is definitely off limits to me, I tried it yesterday.
[09:39] <seb128> just ask on this channel?
[09:39] <apw> michi, don't have to directly use the upload rights
[09:39] <michi> How so?
[09:39] <apw> right ... if you had asked for that a 5am, i am sure pitti would have done it :)
[09:39] <michi> Sorry, I don’t know how this stuff hangs together.
[09:40] <michi> Ah
[09:40] <michi> Well, I was wondering whether it would be possible to distinguish a failed autopkg test because of a broken dependency vs an actual test failure.
[09:40] <michi> If the former, we could re-start the test once every 24 hours automatically.
[09:41] <michi> That way, I wouldn’t have to get on someone’s nerves every day until the problem is fixed.
[09:42] <apw> that cirtainly sounds like something which could be reasonably filed as a bug against the tests, against the autopkgtest project i would guess
[09:42] <michi> OK, I’ll give that a shot. Thanks!
[10:08] <pitti> michi: well, "the problem" is that repowerd is broken -- getting on someone's nerves to fix *that* might be more fruitful :)
[10:09] <michi> pitti: :)
[10:09] <michi> I had a look for it in ci train.
[10:09] <michi> Apparently, it’s landed.
[10:10] <michi> pitti: https://requests.ci-train.ubuntu.com/#/ticket/1487
[10:11] <michi> pitti: Just spotted the email from Lukasz
[10:11] <michi> Very timely...
[10:11] <pitti> hah
[10:28] <rbasak> infinity: even with no known CVEs, and a bunch of bugfixes? I'd prefer for users following xenial-proposed for SRU verification. Not sure ~ubuntu-security-proposed has the same number of testers. Shall I split the SRU then - bugfixes first through updates pocket, "MRE" later through security pocket?
[11:45] <cjwatson> slangasek: FYI you really need to work in dependency order for Haskell - http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
[11:45] <cjwatson> slangasek: I'm working my way up that now
[11:48] <cjwatson> (or down.  whatever)
[14:24] <slangasek> cjwatson: right, I knew the packages wouldn't all build on the first go, but find it efficient to batch-trigger the uploads this way and sort out the failures in -proposed afterwards
[14:29] <cjwatson> slangasek: IME this can end up having to do duplicated uploads as everything settles
[14:29] <cjwatson> also you missed some :-)
[14:29] <slangasek> :)
[14:37] <infinity> rbasak: ubuntu-security-proposed then feeds into series-proposed.  The only difference is that it's not built against updates/proposed.
[14:37] <infinity> rbasak: But splitting packaging fixes from upstream updates is probably right anyway.
[14:53] <seb128> hey there
[14:53] <infinity> Hi.
[14:53] <seb128> is LTS .1 on track? could somebody reply to my email on ubuntu-devel@
[14:53] <seb128> until when can we get proposed packages moved to updates for .1?
[14:55] <infinity> seb128: I'll probably respin on Monday to let more packages in.  But things accepted today don't stand a good chance of making it unless the regression potential is low.
[14:56] <seb128> but things in proposed for a week and verified can be copied over to updates on monday and still be in then?
[14:56] <seb128> when you say accepted today it's thing that are let in proposed and are not aged yet?
[14:57] <infinity> seb128: Right.
[14:57] <seb128> good
[14:57] <seb128> thanks
[14:58]  * infinity notes a new unity above...
[14:58] <seb128> I guess the compiz/unity stack update needs more discussion/consideration
[14:58] <seb128> right, that's a bit tricker
[14:58] <seb128> that would be good to get in .1 but it's getting tight
[14:59] <infinity> If arguments can be made for them being boot/install critical, and a good regression test shown, they can happen, but they don't need to be on the media if they don't really fit that.
[14:59] <seb128> if somebody could approved the unity in the queue?
[14:59] <willcooke> Trevinho, ^^
[14:59] <seb128> that would be a first step
[14:59] <seb128> it revert a change from the current proposed version which was creating a regression
[15:00] <seb128> I think the case for behind on the media is that they make unity much nicer to use in software rendering
[15:00] <seb128> which means in vms
[15:00] <seb128> and often the image is what users boot/interact with in the vm
[15:00] <infinity> Oh, if it's just a revert, that should be fine.
[15:00] <willcooke> there is also a commercial OEM reasons for getting it in to the image
[15:00] <Laney> It's a revert of part of the SRU
[15:01] <Laney> which is in -proposed currently
[15:01] <slangasek> infinity: I'm happy to review the unity upload (my SRU day)
[15:01] <infinity> slangasek: Ta.
[15:02] <willcooke> thanks slangasek
[15:02] <Trevinho> good
[15:03] <Trevinho> Unity bugs were all already verified...  There's just this regression which was part of the only bug not verified.
[15:03] <Laney> Rushing it out is scary, as that's the second regression in this series
[15:03] <Trevinho> Then we can easily have the things checked
[15:03] <Laney> but, as was said above, there are some extenuating circumstances
[15:04] <Trevinho> I would have preferrede more relaexed times too...
[15:04] <slangasek> is there meant to be another compiz upload also, or does the compiz bug go green once the new unity is in?
[15:04] <slangasek> (I see that it's the same bug)
[15:05] <Trevinho> slangasek: no, unity and compiz are related there.. No need for a new upload for compiz
[15:05] <Trevinho> we already did it yesterday to fix a crash  in lowgfx mode
[15:14] <infinity> slangasek: I assume you test-built that binutils upload and the result appeared sane?
[15:15] <slangasek> infinity: I test-built the yakkety one, yes
[15:20] <rbasak> infinity: can you reject mysql-5.7 from xenial then please, and I'll upload a replacement that does not bump the upstream version?
[15:21]  * rbasak is running a build test now, and will do a local dep8 test after, before uploading.
[15:24] <rbasak> Thanks. A build+dep8 test will take about an hour.
[15:27] <infinity> rbasak: Kay.  I'm heading to the doctor, so you'll be done before I'm back (probably).
[15:57] <Trevinho> slangasek: any blocker for the unity dequeue?
[15:58] <slangasek> Trevinho: it took quite a while for the download from the queue to finish (since it's a sync and has to download all the binaries, gee it would be nice to have diffs in the queue for syncs)
[15:58] <slangasek> Trevinho: reviewing the very small delta now
[15:59] <Trevinho> slangasek: ah, nice. Thanks
[16:00] <slangasek> Trevinho: accepted
[16:00] <Trevinho> Thanks
[16:01] <Trevinho> slangasek: there's no need to re-do the verification in all the other bugs I think
[16:01] <slangasek> Trevinho: I think that's fair, the sru scripts may mean you have to reset some tags manually
[16:01] <Trevinho> ok, I'll do that
[16:38] <rbasak> infinity: well, it failed, for inexplicable reasons. I'm trying again to see if it's deterministic.
[17:03] <jbicha> anyone know why today's xenial daily iso still has gnome-maps when it includes ubuntu-gnome-desktop 0.58.1 which does not recommend it any more?
[17:03] <jbicha> http://cdimage.ubuntu.com/ubuntu-gnome/xenial/daily-live/current/xenial-desktop-i386.manifest
[17:03] <Trevinho> slangasek: all bugs are green now, so... Feel free to put things in proposed
[17:03] <jbicha> https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-gnome.xenial/desktop
[17:11] <infinity> jbicha: Because it's installing using tasks, not metapackages.
[17:12] <infinity> jbicha: I might have to fix that today.
[17:13]  * infinity didn't notice that slangasek switched ubuntu to metapackages, but left the rest.
[17:21] <jbicha> infinity: thanks, it did work for yakkety though
[17:21] <infinity> jbicha: Sure, because the tasks in yakkety were updated.
[17:22] <infinity> jbicha: The release pocket in xenial is static, so the gnome-maps package still has the 'Task: ubuntu-gnome-desktop' header.
[17:32] <rbasak> infinity: ^ finally got a dep8 pass. I had to bump the RAM being given to qemu. Oddly, this isn't necessary with 5.7.13.
[17:47] <jderose> infinity: any way for me to know which xenial packages in http://people.canonical.com/~ubuntu-archive/pending-sru.html are expected to land before the final 16.04.1 ISO? also, in testing today's xenial daily, everything seems shiny so far
[18:15] <infinity> jderose: Likely most of the verified ones.
[18:17]  * infinity goes to find breakfast.
[18:51] <jderose> infinity: okay, thanks
[19:10] <infinity> ^-- self-accepting, just a kernel ABI bump.
[19:55] <slangasek> cjwatson: race ya ;-P
[20:22] <cjwatson> slangasek: heh


[09:17] <Death_Sargent> Hey I am having major acpi issues
[09:17] <Death_Sargent> can anoyn help
[09:18] <Death_Sargent> please
[09:22] <Death_Sargent> Help?
[09:23] <crimsun> it'd be useful if you provided `dmesg` in a pastebin entry and pasted the url in #ubuntu
[09:24] <Death_Sargent> um how do I do that
[09:24] <Death_Sargent> im assuming I just run that in the command line correct?
[09:31] <Death_Sargent> http://paste.ubuntu-nl.org/16300/
[09:33] <Death_Sargent> after the mysterious crash my second cpu is not being scalled
[09:33] <Death_Sargent> toshset has never worked the way it should
[09:33] <Death_Sargent> or at all
[09:34] <Death_Sargent> from what I can tell atleast
[09:34] <Death_Sargent> what should I do