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