[07:39] <oSoMoN> trainguards, chrisccoulson: the armhf build of oxide for xenial failed again in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-003/+packages (linker was OOM), not sure why, could we do a binary copy of the packages from https://launchpad.net/~oxide-builds/+archive/ubuntu/oxide-next-for-stable-phone-overlay/+packages instead?
[07:39] <oSoMoN> (and that would get us an updated version of oxide, too(
[07:45] <chrisccoulson> Hmmm, this is bad
[07:54] <sil2100> eh
[07:54] <sil2100> oSoMoN: the question is - why is it failing so frequently when building in the silo
[07:55] <sil2100> oSoMoN: also, I see the version number in the PPA being a bit ugly... I guess we could live with that though
[07:56] <sil2100> oSoMoN, chrisccoulson: is that PPA building against the overlay? I suspect it does?
[07:57] <oSoMoN> sil2100, yes it does
[07:57] <oSoMoN> sil2100, I have no idea why it fails to build in the silo, it used to build just fine
[07:57] <chrisccoulson> sil2100, it's failing because we're exhausting the 32-bit address space
[07:57] <chrisccoulson> we're on thin ice for all 32-bit builds
[07:59] <sil2100> Another problem is, well, I don't remember if we can work-around this but since the PPA binaries have a lower version number, not sure I can put those in the PPA
[07:59] <sil2100> I suppose I could try deleting the packages and then copying, but I remember launchpad being fuzzy about such things
[07:59] <bzoltan> sil2100:  When will you have few minutes to discuss about the ubuntu-sdk meta package corrections in the seed?
[08:14] <bzoltan> sil2100: ^
[08:19] <sil2100> bzoltan: hey! We could hangout tomorrow if needed - could you maybe send me an e-mail with your detailed proposition in the meantime? :)
[08:19] <bzoltan> sil2100: are morning hours like 9-12 good for you?
[08:21] <sil2100> Yeah, 11-12 would be the best I suppose
[08:28] <dbarth_> hey guys
[08:28] <dbarth_> so we need an archive admin to review the new packages in silo 21
[08:28] <dbarth_> ref: https://requests.ci-train.ubuntu.com/#/ticket/1219
[08:29] <dbarth_> can you help us?
[08:31] <sil2100> Oh, slangasek checked them out yesterday, not sure what his final verdict was
[08:31]  * sil2100 tries to check the logs
[08:34] <sil2100> dbarth_: ok, we have an ACK
[08:34] <bzoltan> sil2100:  you have got an invitation with a super detailed description of what we need :)
[08:34] <sil2100> Wooo, yeah, love the hangout title ;)
[08:35] <sil2100> dbarth_: publishing
[08:51] <dbarth_> sil2100_: thank you
[09:05] <pstolowski> jibel, hello, the autopkg test failure in silo 8 is unrelated to the changes in this silo, it's a flaky unity8 test and ltinkl has a fix for that (https://code.launchpad.net/~lukas-kde/unity8/stabilizeFlakyWizardTest/+merge/293999); can you add this silo to your testing queue?
[09:26] <jibel> pstolowski, done
[09:26] <pstolowski> jibel, thanks
[11:38] <rvr> popey: Can you take a look to this? There are three different bug reports (one is mine, just discovered them) https://bugs.launchpad.net/reminders-app/+bug/1582169
[13:45] <tedg> sil2100: I'm looking at this link, is that all the packages in a xenial image? http://people.canonical.com/~lzemczak/landing-team/xenial-transition/staging.pkglist
[13:47] <dobey> tedg: those are source packages, not binary packages
[13:49] <tedg> dobey: Hmm, okay, I guess my question was more about "all" than the type :-) There seems to be some missing.
[13:50] <dobey> tedg: like what?
[13:50] <tedg> dobey: lxcfs
[13:50] <dobey> there's no lxcfs on my mako
[13:51] <tedg> dobey: Yes, it only exists in Xenial.
[13:51] <tedg> That's untrue, it did exist earlier.
[13:51] <dobey> tedg: you mean it's on the pocket-desktop images?
[13:52] <tedg> But I think it is only needed with lxc 2.0 and libpam-cgfs
[13:53] <tedg> dobey: No clue if it's on the pd images. More worried about the android container right now.
[13:55] <dobey> tedg: i think that's the list of source packages that are required to build the preinstalled image, as far as is currently known. if some other packages need to be added, then maybe something is wrong in the dependency tree; though i'm not sure how that list was generated exactly
[13:56] <tedg> dobey: Yeah, trying to figure out what it is a list of first :-)
[13:56] <tedg> Could have other filters applied to it.
[13:58] <dobey> looks like it is just the source packages for what is in the preinstalled image
[13:59] <Saviq> jibel, sil2100, pmcgowan, ACK on https://requests.ci-train.ubuntu.com/#/ticket/1409
[14:08] <jibel> Saviq, silo 68 will trigger a rebuilt of 71?
[14:09] <jibel> rebuild*
[14:09] <Saviq> jibel, no
[14:09] <jibel> ok
[14:09] <Saviq> 68 only has mir, ABI compatible
[14:09] <jibel> davmor2, rvr silo 71 is for OTA11, it'd be great to land it today if possible
[14:10] <dobey> sil2100: can you retry the two failed unity8 test builds on https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-047/excuses.html please?
[14:10] <rvr> Ok
[14:11] <Saviq> mterry, can you help dobey ↑ - and we really need to land the flaky fixes...
[14:11] <mterry> cimi, ok
[14:11] <mterry> whoops
[14:11] <mterry> Saviq, ok  :)
[14:14] <dobey> thanks mterry
[14:29] <sil2100> Saviq: \o/
[14:30] <sil2100> rvr: what's the status of testing 68?
[14:30] <sil2100> jibel: I suppose I'll do the triple landing switch once both land, since I already dragged this out till today
[14:31] <rvr> sil2100: Tested in frieza, doing a quick check in arale and krillin
[14:31] <sil2100> Wanted to have 68 landed, now seeing the other silo ready, well...
[15:22] <slangasek> sil2100: my verdict was +1 for it... has anyone published it yet? you didn't give me a link to the silo and I didn't go digging :)
[15:22] <slangasek> sil2100: ah, you found that in the logs, great :)
[15:23] <sil2100> slangasek: yes, found the logs and published :)
[15:23] <sil2100> Thanks!
[15:29] <Saviq> rvr, are you ok with duping your mouse bug to bug #1521518 ?
[15:29] <Saviq> ah there's ubot5
[15:30]  * rvr reads
[15:30] <rvr> "The login screen is not usable with mouse connected" Exactly this.
[15:30] <rvr> Saviq: Yup
[15:31] <Saviq> hmm I wonder
[15:31] <Saviq> nope
[15:31] <Saviq> rvr, we really can't do anything automagically, as if we fix this, then we could break kbd + touchpad combos
[15:31] <Saviq> if we said we ignore keyboards on mice
[15:48] <rvr> sil2100: Saviq: Silo 68 approved
[15:49] <sil2100> \o/
[15:49] <sil2100> Publishing
[16:03] <robru> slangasek: hey I'm a little bit blocked, can you take a look at the email I sent last night?
[16:04] <slangasek> robru: it'll be later this morning
[16:14] <renatu> trainguards, why silo 36 is saying "Automated Signoff	Failed". Where I can check the reason?
[16:15] <robru> renatu: click excuses
[16:16] <robru> renatu: unity8 regression in vivid
[16:17] <renatu> robru, ok then we need to wait unitl it get fixed. Right?
[16:18] <robru> renatu: no, you need to investigate if the failure is caused by your branch and then either fix it yourself, or if not, just ask qa to override the failure and review anyway
[16:19] <tedg> sil2100: How does this list get built? http://people.canonical.com/~lzemczak/landing-team/xenial-transition/staging.pkglist
[16:19] <sil2100> tedg: a script is scanning all packages in the touch armhf manifests and checks if arm64 binaries are present - if not, it tries to determine the reason why they're not there
[16:19] <sil2100> Ah
[16:19] <sil2100> Wait
[16:19] <sil2100> You mean the pkglist
[16:20] <sil2100> tedg: so that's basically the first part of the thing I mentioned above
[16:20] <sil2100> i.e. runs through the armhf manifest and fetches the source-package names for each binary we have in the manifest
[16:21] <tedg> sil2100: Is it looking at the vivid manifests? I think it should have lxcfs from libpam-cgfs?
[16:21] <sil2100> tedg: no, it's xenial
[16:21] <tedg> sil2100: Can you point me to the xenial armhf manifest?
[16:21] <sil2100> tedg: staging is xenial based
[16:25] <tedg> sil2100: It seems that libpam-cgfs is here, but lxcfs (it's source package) isn't in the migration list: http://cdimage.ubuntu.com/ubuntu-touch/xenial/daily-preinstalled/current/xenial-preinstalled-touch-armhf.manifest
[16:26] <sil2100> Yeah, it should be, I see it in the output of my script here as well
[16:26] <sil2100> Let me double check the scrip instance
[16:32] <sil2100> tedg: anyway, trying to see why I get different script output locally on my PC and on the remote instance - for now I put the output I generated
[16:33] <tedg> sil2100: Cool, it solves my problem, I was worried we didn't have it in the image, but it seems to be there.
[16:33] <sil2100> Yeah, well, it should be since the binaries were always there
[16:34] <sil2100> Dunno what happened
[17:07] <sil2100> jibel, rvr, davmor2: how far is silo 71 testing?
[17:09] <davmor2> sil2100: it is being tested
[17:13] <dobey> https://autopkgtest.ubuntu.com/request.cgi?release=vivid&arch=amd64&package=unity8&trigger=unity-scopes-shell%2F0.5.7%2B15.04.20160516-0ubuntu1&ppa=ci-train-ppa-service%2Fstable-phone-overlay&ppa=ci-train-ppa-service%2Flanding-047 <- sigh
[18:07] <dobey> mterry, kenvandine: if you're around, would you mind? https://autopkgtest.ubuntu.com/request.cgi?release=vivid&arch=amd64&package=unity8&trigger=unity-scopes-shell%2F0.5.7%2B15.04.20160516-0ubuntu1&ppa=ci-train-ppa-service%2Fstable-phone-overlay&ppa=ci-train-ppa-service%2Flanding-047
[18:11] <kenvandine> dobey, sure
[18:12] <dobey> kenvandine: thanks
[18:12] <kenvandine> dobey, done
[20:58] <mterry> robru, it would be neat if the "Merge Proposal URLs" section allowed comments (like with #)
[20:58] <mterry> robru, (in citrain)
[20:59] <robru> mterry: hmmm
[21:01] <robru> mterry: probably not workable, because the train re-sorts the order of the MPs based on prereqs, and I have a massive overhaul branch which actually saves the new order back to the ticket so you can see what order is actually used. so even if it supported comments they'd be lost after the reordering.
[21:02] <mterry> robru, ew :(  I know in u8 silos, we actually like ordering them conceptually -- like all the u8 branches together, sometimes sorted by owner.  Or for a silo I'm working on now, I have a section at the top that includes the content of a whole other silo that will land before mine, so that I can test for conflicts and such
[21:03] <mterry> robru, if the train reordered those on me, it would be a big pain
[21:03] <robru> mterry: if you don't define prereqs, or if you put them in order of prereqs anyway, then the ordering is stable.
[21:04] <mterry> robru, yeah... but that's not going to happen all the time
[21:04] <robru> mterry: anyway the reordering has been in production for 3 years, so it obviously hasn't been a problem for you. the new bit is that it saves the ordering back to the ticket so you can see what order is actually being used. that was a complaint some people had, they couldn't see the result of the sorting.
[21:05] <mterry> robru, yeah I get the complaint.  I don't share it and the new way will bum me out is all
[21:05] <mterry> robru, see https://requests.ci-train.ubuntu.com/#/ticket/1426 for example
[21:05] <mterry> robru, top section is other silo
[21:05] <robru> mterry: I don't think this is a problem? you're asking to be able to have one branch define a prereq but then merge the dependant branch before the depended-upon branch?
[21:06] <mterry> robru, and I've had to stuff comments about MPs I am consideringn for the silo but not adding in the Description instead of the Merge URLs section like I would want (if we had comments)
[21:06] <mterry> robru, no no, I just want the order of the Merge URLs section not to change visibly  :)
[21:06] <mterry> But it sounds like other people are asking for the exact opposite
[21:07] <robru> mterry: fight it out with dobey, he was the one who complained that the train was changing the order of his MPs and he wanted to see the order the train was using.
[21:08] <mterry> it's especially annoying because this reordering would seemingly stop an obviously useful feature (comments)
[21:08] <robru> mterry: you're the first person to ask for comments in the 3 years I've been maintaining this.
[21:09] <mterry> Doesn't mean I'm wrong  :)
[21:10] <mterry> dobey's the first person in three years to ask for reordering  :)
[21:10] <robru> mterry: file a bug I guess, perhaps there's some way that it can display the results of the sort in the log instead of in the ticket.
[21:10] <robru> mterry: no no it's been reordering all along. dobey just wants to see it
[21:10] <mterry> I know
[21:10] <mterry> I  meant the first person to ask for visible reordering
[21:11] <dobey> do what?
[21:12] <mterry> dobey, you wanted to see the order of the MPs in citrain after it resorts them
[21:12] <mterry> apparently
[21:12] <robru> dobey: this was a while back, you had a merge conflict in a silo and you couldn't reproduce it locally, train was merging in a different order than you expected.
[21:13] <robru> dobey: so I'm working on a big overhaul of the train here, one of the sexy new features is that it saves the result of the sort back to the ticket, so you can see the order it merges in.
[21:13] <dobey> oh right
[21:13] <dobey> mterry: well it's not a problem to change the ordering for the unity8 silos, because you can't have prerequisties on branches for other projects in launchpad
[21:14] <dobey> ie, you can't have a unity-scopes-shell branch with a prereq on a unity8 branch that has a prereq on uitk or something
[21:14] <mterry> dobey, yeah maybe.  Depending on whether we have an interesting internal sorting.  But see https://requests.ci-train.ubuntu.com/#/ticket/1426 where I have multiple u8 sections (because one is a copy of another silo)
[21:15] <mterry> dobey, also apparently it means we'll be unlikely to add the ability to have comments in that field
[21:15] <dobey> crikey that's a lot of MPs
[21:15] <mterry> dobey, we're running a backlog
[21:15] <dobey> well comments in that field makes no sense
[21:15] <mterry> heh, that's judgy
[21:15] <robru> dobey: why not? I can sort of see the value in having groups of MPs with little notes about them.
[21:16] <mterry> dobey, see the end of the Description field for that silo?  It would be nice to have those in the MP field instead
[21:16] <mterry> And be able to comment/uncomment MPs individually if they're being added/removed from the silo
[21:17] <dobey> robru: because the implementation isn't designed that way. comments would make sense if it were a actually a list of things, rather than a text field that is treated as a list, so that you could comment on individual items in the list, or select multiple; ie, like a google spreadsheet does
[21:18] <mterry> So dobey would never use comments, fine.  I would
[21:18] <robru> mterry: also I hadn't considered commenting out MPs as a temporary thing, hm
[21:18] <dobey> mterry: i didn't say i would never use comments. i said wedging more and more features into a single text field only makes things more complex and a pain to maintain
[21:19] <robru> dobey: "line.split('#')[0].strip()" isn't so bad really.
[21:19] <mterry> robru, yeah that's what I want comments for -- commenting out MPs and saying a blurb about why
[21:19] <mterry> robru, maybe sorting order doesn't matter, I could live with all comments having to be on same line?
[21:19] <robru> mterry: initially I thought you meant like having a little comment header before each section of MPs
[21:19] <mterry> robru, I mean I could imagine that being useful too
[21:19] <dobey> robru: well, sorting doesn't preclude having #-comments
[21:20] <robru> dobey: the new thing is that it takes the sorted list and dumps it back into the field, overwriting what's there, so you'd lose comments
[21:20] <dobey> robru: just maintain comment position relative to the thing below it, when reordeering
[21:20] <dobey> robru: gettext does it, you can too :)
[21:20] <mterry> And I'm still against reordering on other grounds.  :)  It would make it harder for me to organize branches on silos like this
[21:21] <mterry> *now* you want fancy features for the text field  :)
[21:21] <robru> dobey: I don't see how that would work, because it changes the order of stuff, so you might have a comment preceding a paragraph, but after sorting there'd be one mp, then a comment, then a bunch more. it'd look weird.
[21:22] <dobey> robru: no more weird than /etc/apt/sources.list looks by default
[21:22] <dobey> mterry: i don't want fancy features for a text field. just suggesting possible compromise
[21:23] <dobey> mterry: i still think this is pretty hacky :)
[21:23] <mterry> I'm betting I'm not the only person that has weird organizations of the field.  It should be simple to grep all silo jobs and see if there are interspersed groupings of MPs (like u8 MPs, followed by qtmir MPs, followed again by u8 MPs).  Any instances of that would be (presumed-by-me) annoyed by reordering
[21:23] <mterry> dobey, well I want no modifications of that field ever.  That's my push
[21:24] <robru> mterry: yeah I've seen groupings before, eg where one feature must be implemented in several projects simultaneously, you'll see the "foo-feature" branches for u8 + mir + whatever, then the "bar-feature" branches for the same projects in a second stanza
[21:25] <robru> mterry: can you file a bug against lp:bileto? just say you want comments ignored and to have the field preserved. I guess the sorted order can be printed in the logs.
[21:26] <dobey> anyway, i'm not adamant about it either way. my issue was that train was doing something unexpected, and created a weird merge conflict issue that was a bit hard to figure out, because it's hard to see what exactly the train is doing at that point, with minimal verbosity
[21:26] <mterry> robru, ok will file
[21:27] <dobey> the weird parsing of URLs makes the request page a bit hard to read anyway, especially when there are that many branches
[21:28] <mterry> robru, https://bugs.launchpad.net/bileto/+bug/1583352
[21:28] <robru> mterry: thanks
[21:29] <mterry> robru, despite me sounding strident, this is not a life or death feature  :)
[21:29] <robru> dobey: noooooo the url shortening makes it easier to read! spaces instead of slashes and underscores removes a ton of punctuation
[21:30] <robru> mterry: yeah it'll have to wait a bit, I'm trying to land a massive overhaul, really brutal branch here. 3k lines!
[21:30] <mterry> robru, :)
[21:30] <mterry> robru, sounds good!
[21:30] <dobey> robru: just translate it to german then. it'll remove all the spaces too!
[21:32] <mterry> ooh yeah.  /me files bug