[06:02] <robru> Mirv: heads up, did a minor train rollout last night, no new features or anything just a minor pylint cleanup. let me know if anything explodes, I'll be around for a couple hours to fix it
[06:13] <Mirv> robru: ok
[06:15] <Mirv> robru: I'm not sure why but I'm not seeing action logs for example https://requests.ci-train.ubuntu.com/#/ticket/843 and https://requests.ci-train.ubuntu.com/#/ticket/851
[06:20] <robru> Mirv: you have to click 'show audit logs', by defaults only human-written comments are displayed
[06:20] <Mirv> robru: ah..
[06:21] <Mirv> robru: I remember the announcement now :)
[06:22] <Mirv> -> more morning coffee
[06:47] <morphis> Mirv: ping
[06:48] <morphis> or others can help me as well: I am currently splitting things out of libhybris into platform-api
[06:48] <morphis> which gives me a new libandroid-compat binary pkg build by platform-api
[06:49] <morphis> all other packages wanting those things which were in libhybris before depend on libhybris, is it now correct to put a Depends from libhybris on libandroid-compat1?
[07:02] <Mirv> morphis: technically if libhybris itself doesn't need libandroid-compat1 to function alone, the other packages should additionally depend on libandroid-compat1 instead
[07:02] <Mirv> if it's just them that need it in addition to libhybris
[07:03] <morphis> Mirv: ok, so the better thing would be to adjust all packages
[07:03] <morphis> which can be quite some work
[07:20] <Mirv> morphis: I guess status quo would be kept with the dependency though, so if time is of essence one could file a bug about it but land it as is.
[07:21] <morphis> Mirv: you mean the dependency from libhybris on libandroid-compat1?
[07:22] <Mirv> morphis: yeah, I mean that if it's nicer to do it in two steps, there could be another "no op" landing that just handles all the packaging stuff
[07:22] <Mirv> but first have the dependency in there
[07:23] <morphis> ok
[10:04] <sil2100> jibel, davmor2: tarball seems to have been prepared, I'll try to import it manually to the -proposed channels
[10:08] <davmor2> sil2100: it needs testing before it is pulled into -proposed
[10:14] <sil2100> davmor2: no no, I mean the other -proposed
[10:14] <sil2100> davmor2: the -proposed -proposed
[10:14] <davmor2> sil2100: ah with you now sorry
[10:14] <davmor2> sil2100: yeap please if it is available
[10:40] <rvr> Saviq: ping
[10:40] <Saviq> rvr, hey
[10:41] <rvr> Saviq: Happy new year :D
[10:42] <rvr> Saviq: Silo 8...
[10:42] <Saviq> rvr, yes
[10:42] <rvr> Saviq: I'm not sure how HiDPI support is supposed to be tested.
[10:43] <Saviq> rvr, that silo alone should cause no visible change, and that's the test
[10:43] <Saviq> rvr, we do want to land it though to enable people to find issues when they enable it manually
[10:44] <Saviq> rvr, the description has info on how to actually enable it if you want to see where it does break
[10:47] <Saviq> rvr, so really, verifying that silo is just spending some time looking at the UI to see that nothing looks broken
[10:58] <rvr> Saviq: We'll block silo 8 until OTA9 has landed, if not needed in the image.
[10:58] <Saviq> rvr, ohkay
[11:00] <Saviq> greyback, ↑↑
[11:03] <Saviq> rvr, to avoid wasting time, our next silo is rather big (https://requests.ci-train.ubuntu.com/#/ticket/784) as we had to wait for all kinds of things, what's our current landing policy?
[11:05] <Saviq> rvr, basically, I'm asking what kind of changes should I refrain from landing
[11:07] <rvr> Saviq: I'm asking too, as the release date was moved one week forward.
[11:08] <rvr> Saviq: Ok, so we are still in string and feature freeze, so just bug fixes should land.
[11:08] <jibel> Saviq, only bug fixes for ota9 allowed. we won't land such big silos.
[11:09] <Saviq> jibel, ack, will slim it down
[11:09] <jibel> or split it in smaller chunks with bug fixes only
[11:09] <jibel> right
[11:15] <Saviq> jibel, so these are just bug/test fixes https://requests.ci-train.ubuntu.com/#/ticket/854, would you want it split up into even smaller bits (meh for testing overhead) or is that OK?
[11:22] <jibel> Saviq, can it be ready for qa today?
[11:22] <Saviq> jibel, yes, totally
[11:24] <jibel> Saviq, okay then, but last one this large for ota9. It's too hard to identify regressions in such big change sets.
[11:24] <Saviq> jibel, ack
[11:25] <Saviq> jibel, we would have landed that long ago, but all kinds of things blocked us before xmas and last week
[11:25] <Saviq> so the MPs piled up
[11:29] <morphis> sil2100, Mirv: time for another upload?
[11:31] <jibel> Saviq, np, I know what you mean
[11:36] <sil2100> morphis: yeah
[11:39] <sil2100> jibel, davmor2: new custom tarball imported to the -proposed/*-proposed channels
[11:39] <davmor2> sil2100: nice thanks
[11:39] <sil2100> morphis: wazzup?
[11:40] <davmor2> morphis: no no more uploads aloud you've had one this month ;)
[11:40] <davmor2> allowed even
[11:41] <morphis> davmor2: really, you want me stopping my work? :-)
[11:41] <jibel> sil2100, thanks. We'd need requests too
[11:41] <jibel> sil2100, are they on bileto?
[11:42] <sil2100> jibel: not sure, penk said he'll be preparing the release notes so I thought he actually put up the request too
[11:42] <sil2100> hmmm
[11:42] <jibel> I didn't find anything
[11:42] <jibel> sil2100, we'll test when the test request is complete
[11:54] <sil2100> jibel: thanks
[12:07] <Saviq> robru, hey, I abandoned this request and it barfed a while after https://requests.ci-train.ubuntu.com/#/ticket/784
[12:40] <morphis> sil2100, Mirv: is there any way I can see why my silo packages are staying for a long time in the publication queue?
[12:46] <cjwatson> morphis: details?
[12:46] <morphis> cjwatson: just wondering why it takes so long this time at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-000/+packages
[12:46] <cjwatson> morphis: how long has it taken so far?
[12:46] <morphis> build finished 44 min ago
[12:47] <cjwatson> that is indeed atypical, let's see
[12:48] <cjwatson> 2016-01-11 12:36:38 DEBUG   publish-distro ran in 3239.511709s (excl. load & lock)
[12:48] <cjwatson> morphis: it looks like there was an extremely long run of the previous cron cycle - nothing specific to your uploads, it'll catch up shortly
[12:49] <cjwatson> seems to have spent a long time processing ppa:kubuntu-ppa/ubuntu/backports-landing
[12:49] <morphis> cjwatson: ah
[12:49] <morphis> cjwatson: where do you see that?
[12:49] <cjwatson> morphis: server logs
[12:50] <morphis> ah
[12:54] <morphis> cjwatson: thanks, all published now!
[13:48] <sil2100> seb128: hey! Sorry to always poke you about binNEW requests, but in case you have a free moment - silo 26 introduces 2 new packages (debug packages): https://ci-train.ubuntu.com/job/ubuntu-landing-026-2-publish/7/
[13:48] <sil2100> seb128: one for hybris, one for android
[13:50] <sil2100> morphis: hmm, checking the diffs for silo 26, I don't like that there's no mention of the -dbg package addition in the changelog...
[13:51] <sil2100> seb128: actually it's just one new binary apckage ;)
[13:51] <morphis> sil2100: fine for me to add it to the changelog
[13:51] <cjwatson> sil2100: Why is it explicitly generating a debug package rather than just relying on the automatic ones?
[13:52] <sil2100> cjwatson: dunno! morphis ^ ?
[13:52] <sil2100> I just started the review
[13:52] <cjwatson> Also libvibrator stuff is duplicated in two cases in ubuntu/libhybris/debian/libhybris-dev.install
[13:52] <cjwatson> and ubuntu/libhybris/debian/libhybris.install.in
[13:52] <cjwatson> It's not *wrong*, but it is not usual and it's suboptimal
[14:09] <seb128> sil2100, same question as cjwatson
[14:15] <sil2100> morphis: ^
[14:16] <morphis> cjwatson: why is a -dbg package wrong?
[14:19] <morphis> sil2100, seb128, cjwatson: shouldn't each package have one so you can install dbg symbols?
[14:19] <cjwatson> morphis: it's not *wrong*, but we already generate one automatically, *-dbgsym
[14:19] <seb128> morphis, we have ddebs autogenerated that's why usually adding a dbg is just duplicating
[14:20] <morphis> I see
[14:20] <cjwatson> morphis: and they're pushed off to ddebs.ubuntu.com to avoid using space in the primary archive
[14:20] <morphis> seems to be a very hidden detail I never came across yet
[14:21] <cjwatson> https://wiki.ubuntu.com/DebuggingProgramCrash
[14:21] <morphis> cjwatson: and what is duplicated between libhybris.install.in and libhybris-dev.install.in?
[14:21] <morphis> cjwatson: -dev one installs the .so file where the other one installs all .so.* files
[14:22] <cjwatson> morphis: no, not *between* the two files, that's not what I said
[14:22] <cjwatson> morphis: in each file, you have each of libvibrator.so and libvibrator.pc listed twice
[14:22] <morphis> uups
[14:22] <morphis> seems to be due to a git merge as it looks like
[14:23] <morphis> cjwatson, seb128, sil2100: are you fine with me dropping the -dbg package and double entries in the next upload?
[14:23] <cjwatson> fine by me
[14:24] <morphis> don't want to risk this not being landed for ota9
[14:24] <cjwatson> I'm happy to archive-admin-ack what's there, it's just odd :)
[14:27] <morphis> cjwatson, sil2100, seb128: https://code.launchpad.net/~morphis/libhybris/+git/libhybris-ubuntu/+merge/282175
[14:29] <cjwatson> right, lgtm
[14:30] <sil2100> o/
[14:48] <Saviq> robru, got some unexpected autopkgtest results here https://requests.ci-train.ubuntu.com/#/ticket/854, mentions old unity8 versions
[14:49] <Saviq> like it didn't wait for the new versions to build, even though this is the first build of that req
[14:49] <Saviq> oh actually
[14:49] <Saviq> those are results for unity-scope-click
[14:49] <Saviq> even weirder :P
[15:25] <morphis> sil2100, Mirv: should citrain builds use what is already in the silo?
[15:31] <Mirv> morphis: sure, what builds in silo always uses the content in that silo
[15:31] <Mirv> (for that series)
[15:31] <morphis> Mirv: hm, https://ci-train.ubuntu.com/job/ubuntu-landing-015-1-build/14/console doesn't seem to do that
[15:38] <Mirv> morphis: oh right you're asking about citrain source preparation before it's uploaded to PPA..
[15:38] <morphis> Mirv: right
[15:40] <Mirv> morphis: that would be a question to robru then, about whether the citrain could also have the silo enabled during that phase so that https://ci-train.ubuntu.com/job/ubuntu-landing-015-1-build/14/console wouldn't happen. I can't directly think of any workaround.
[15:42] <morphis> Mirv: hm ok
[15:42] <morphis> Mirv: let me drop him a mail then
[15:47] <rvr> renatu: ping
[15:49] <renatu> rvr, pong
[15:49] <rvr> renatu: Hey
[15:49] <rvr> renatu: I'm testing silo 55
[15:50] <rvr> renatu: We found some potential issues
[15:50] <rvr> renatu: jibel reported that "Esc" doesn't work in Contacts, when it's launched from messaging and dialer app
[15:50] <rvr> and I confirmed
[15:51] <renatu> rvr, how do you lunch contacts from dialer?
[15:51] <rvr> renatu: Clicking on the Contacts icon
[15:52] <renatu> rvr, this is not contact app, you still on dialer or messaging, the shortcuts will not work
[15:52] <renatu> rvr, dialer and messaging will implement shortcuts on the next sprint
[15:53] <rvr> renatu: I see
[15:54] <rvr> renatu: What's the difference between the old and new headers? I can't see any change visible to the user.
[15:55] <renatu> rvr, only the internal API has changed, the visual still the same
[15:55] <rvr> renatu: Ok
[15:55] <renatu> rvr, one visible change is the order of the action on the top right
[15:55] <rvr> renatu: Edit contact, share, etc, works fine.
[15:56] <renatu> rvr, they will be inverted
[15:56] <renatu> rvr, for example search use to be the first (left->right), but now it is the last one
[15:57] <rvr> renatu: Yes, I can see
[16:11] <jhodapp> sil2100, what happened here? https://ci-train.ubuntu.com/job/ubuntu-landing-045-0-status/2617/consoleFull
[16:11] <jhodapp> sil2100, I changed the landing from xenial/vivid to just vivid...is that the reason?
[16:57] <sil2100> jhodapp: hmm, not sure, let me try investigating in a minute
[16:57] <jhodapp> sil2100, thanks
[18:15] <sil2100> slangasek, robru: do you guys have anything for me on the landing internal meeting?
[18:16] <slangasek> sil2100: nothing new from my side
[18:18] <robru> slangasek: sil2100: nah same old here. britney stage 2 is progressing nicely, just testing it now
[18:19] <sil2100> slangasek, robru: \o/ ok then, so I recommend skipping, have some packages in the fly right now
[18:19] <robru> slangasek: sil2100: i'm ok to skip
[18:45] <slangasek> robru, sil2100: copy that, cancelled
[18:45] <robru> Thanks
[20:18] <popey> jibel, http://reqorts.qa.ubuntu.com/reports/qa/touch-version-decoder-ring/ is crying out for ubuntu font! :)
[20:42] <Saviq> robru, hey, you around?
[20:43] <robru> Saviq: hiya
[20:44] <Saviq> robru, is there any place I can look for silo autopkgtests progress? https://requests.ci-train.ubuntu.com/#/ticket/854 seems to show some weird collection of results
[20:45] <Saviq> (I only just made it QA-Ready, so that shouldn't matter)
[20:45] <robru> Saviq: the status is "not started yet"
[20:45] <robru> Saviq: you'll see the status on the excuses page once it starts
[20:45] <robru> Saviq: the fact that you're looking at the excuses page and seeing an unrelated package means that's the leftover state from the last request in your silo and yours hasn't started yet
[20:46] <Saviq> robru, so they only run after QA ready now?
[20:46] <robru> Saviq: autopkgtests have only ever run after silos marked 'ready for qa' since the feature was implemented.
[20:47] <robru> Saviq: that'll hopefully be changing this week but there's been some setbacks
[20:47] <Saviq> robru, nw, that explains things, I thought they run on all packages, and don't update after ready for QA, I remember a conversation like that
[20:47]  * Saviq waits for results then
[20:48] <robru> Saviq: by next week you'll have a separate field for "lander signoff" where you can approve the silo & then autopkgtests run. that's the goal. for the first iteration we just shoehorned it in to run after 'Ready for QA' though
[20:48] <Saviq> ack
[20:49] <Saviq> robru, do you know, btw, if it's possible to run autopilot tests on device via autopkgtest?
[20:50] <robru> Saviq: uh, as far as I'm aware (admittedly I'm not an expert in that area), you can run autopilot tests via autopkgtest but there's no way to specify what device. they just run on "the autopkgtest hardware" which offers a range of arches but it's all just server hardware.
[20:51] <Saviq> robru, ack, I know it was a plan at some point, not sure where it's at
[20:51] <Saviq> thanks
[20:51] <robru> yw
[20:53] <robru> brb
[21:53] <dobey> Saviq, robru: you can run autopkgtests on a device, but i don't recall the exact invocation for doing so
[21:53] <dobey> ah
[21:53] <dobey> adt-run ... --- ssh -l joe -h testhost.example.com
[21:53] <dobey> Saviq: https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html
[21:54] <Saviq> dobey, well, right, more interesting is how to declare a test so that it only runs on device, running it manually is one thing
[21:54] <dobey> Saviq: in autopilot? or for autopkgtests?
[21:55] <Saviq> dobey, in debian/tests
[21:55] <Saviq> there are some adb-specific comments supposedly
[21:55] <dobey> Saviq: right, but are you tryign to do something like "only run the autopilot tests if we're on a device" or "these specific tests inside the autopilot tests are only useful to run on a device" ?
[21:56] <Saviq> the first, a whole debian/tests/foo would need to run only when we have a device to ssh to
[21:57] <robru> dobey: I think he wants to say "go provision me a device to run these tests on right now" ;-)
[21:57] <dobey> Saviq: got a link to the test you want to do that with?
[21:58] <Saviq> dobey, unity8's autopilot tests is what I'm thinking of, no autopkgtest for those yet
[21:59] <dobey> Saviq: are they only runnable under mir or something?
[21:59] <Saviq> dobey, yeah, most of them only make sense under an actual unity8 session - they launch apps and such
[22:03] <dobey> Saviq: ok, i was looking at stuff related to this similarly a while back, and i thought i implemented something, but i can't recall where. i'll have to poke through a few things, but i'm pretty sure i have a solution you can use
[22:08] <Saviq> dobey, I'm all ears if you find something
[22:12] <dobey> Saviq: as a very quick workaround, you could i suppose check for $MIR_SOCKET being set in the environment, and only run the autopilot tests when that is set