[04:30] <Mirv> morning
[05:10] <Mirv> I wonder what abyss now is in question
[05:10] <robru> Mirv: abyss means the packages are nowhere but the original ppa
[05:11] <robru> Mirv: indeed I've busted publication. I'm on it
[05:12] <robru> or... actually...
[05:12] <Mirv> robru: yes, I know what it means, but I also know it didn't go into any queue etc
[05:12] <Mirv> robru: busted publication might explain it (but that "or..." does not)
[05:13] <Mirv> my first thought was that someone has accidentally converted Feature Freeze into All Stop Freeze :)
[05:13] <robru> Mirv: sorry this always bites me. jenkins runs exclusively python3 but publishing runs in python2 and so it always explodes when I commit python3isms to trunk
[05:13] <Mirv> robru: no problem, I'm happy that I caught this early
[05:14] <robru> Mirv: ok I think I have a fix but it's just a guess for now. we'll find out within 5 minutes.
[05:15] <Mirv> so it seems (opened the commit log) ok, let's see
[05:16] <robru> Mirv: uhhhhh... not sure what's happening now. I fixed the original traceback it seems but now some expected output is missing, not sure what it's doing.
[05:18] <robru> Mirv: oh ok, it looks good now. that was a really strange delay though
[05:18] <robru> veebers: yeah the last autopilot silo never landed
[05:18] <Mirv> robru: right, now it's there
[05:19] <veebers> robru: oh what, really? I thought it had (I'm sure we had a convo about it landing)
[05:19] <robru> veebers: we had a convo about me publishing it. it's been stuck in proposed since then
[05:20] <veebers> robru: ah I see, me misunderstanding then. What actions do I need to take at this poinr about that
[05:20] <Mirv> right there's a regression on autopilot-gtk autopkgtest claimed http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#autopilot
[05:20] <veebers> point*
[05:20]  * veebers looks
[05:21] <robru> veebers: yeah what Mirv said. it's possible the failure is unrelated, if so you may want to poke somebody in #ubuntu-release to see if they can wave you through. if not you need to fix the bug and republish
[05:23] <veebers> robru, Mirv: Ah right, it appears that something has changed in wily that autopilot-gtk needs to take into account now. I'll have to look into that
[05:24] <robru> veebers: alright I'm way EOD, Mirv should be able to publish for you when you're ready
[05:26] <veebers> robru: ack thanks
[05:26] <robru> you're welcome
[05:27] <veebers> Mirv: FYI, I'm about to EOW and head to an appointment so It's unlikely that I'll be able to do anything about this until Monday
[05:39] <Mirv> veebers: alright
[07:17] <pstolowski> hey trainguards, may i ask for a silo for request 216?
[07:17] <robru> pstolowski: you can assign your own now
[07:18] <pstolowski> robru, ah, I didn't know that; indeed, thanks :)
[07:18] <robru> pstolowski: you are empowered! ;-)
[07:18] <robru> pstolowski: I'm not here. Mirv can help if you hit any issues
[07:19] <pstolowski> robru, sure, thanks!
[07:19]  * pstolowski feels truly empowered
[07:22] <robru> pstolowski: you're welcome
[07:25] <Mirv> pstolowski: congrats on your first own assigning :)
[07:26] <Mirv> robru fails at convincing that he's not here
[07:30] <robru> Mirv: ssshhh I'm sleeping
[07:30] <robru> Zzzzzzzzz
[07:31] <Mirv> :)
[07:31] <robru> Mirv: OK goodnight!
[07:42] <Mirv> hmm, I should automate this "wipe device clean" a bit more.. setting writable, skipping intros etc
[08:15] <Mirv> pete-woods: does dual landing for hud make any sense? I know libhud2 is on the images but probably not used for anything?
[08:16] <pete-woods> Mirv: yeah that's a fair point. I guess we could just land for wily
[08:17] <Mirv> pete-woods: alright. reconfiguring and publishing for wily only.
[08:17] <pete-woods> Mirv: thanks :)
[08:17] <Mirv> otherwise QA will get shivers from something landing on an image without their approval
[08:17] <pete-woods> they already said they aren't interested in this silo (https://trello.com/c/9tB8Royf/2209-211-ubuntu-landing-030-hud-pete-woods) FYI
[08:18] <pete-woods> I obviously ran my own checks (i.e. ran the test plan myself) that it still works
[08:18] <Mirv> pete-woods: ah :) but it's of no benefit on the phone anyway?
[08:18] <pete-woods> indeed
[08:18] <Mirv> right, better not touch the overlay then
[08:19] <pete-woods> I hadn't realised that QA weren't interested in the legacy desktop, tbh
[08:19] <pete-woods> that's changed since last time I landed HUD
[08:19] <pete-woods> wonder if this means we don't check if any of the indicators (which are used on both desktop and touch) work on desktop when landing
[08:19] <Mirv> pete-woods: well they are not interested in the legacy desktop if the package is being landed to overlay PPA which is not in use there
[08:20] <Mirv> pete-woods: yeah more generally too you're probably correct, this would change towards 16.04 LTS probably. the traditional desktop development has been mostly "upstream assures it's good"
[08:21] <pete-woods> Mirv: well of course I never break anything ;)
[08:21] <jibel> Mirv, my point was if it's for the legacy desktop on vivid it should be an SRU
[08:21] <Mirv> pete-woods: well that's a given! :)
[08:22] <Mirv> jibel: yes, I understood that and that's correct
[08:22] <jibel> and follow the SRU process
[08:22] <Mirv> but not worth it as such
[08:22] <pete-woods> indeed
[08:22] <pete-woods> it's not actually got any serious bugfixes
[08:22] <pete-woods> there's a small memory leak of a string or two
[08:22] <pete-woods> but not worth an SRU
[08:23] <Mirv> ogra_: are you around to ack hud removing unity-voice dependency and some valgrind changes? https://ci-train.ubuntu.com/job/ubuntu-landing-030-2-publish/lastSuccessfulBuild/artifact/hud_packaging_changes.diff
[08:23] <jibel> if it's the legacy desktop on wily, just land it if it doesn't require a FFe
[08:29] <ogra_> sil2100, sorry, we're getting a new washing machine and they just called they will deliver in 10-15min so i have to skip today ...
[08:29] <ogra_> Mirv, ^^^ after that :)
[08:29] <sil2100> ogra_: ACK
[08:29] <Mirv> ogra_: I WISH I had my new washing machine, ordered last Sunday, clothes are piling up!
[08:29] <Mirv> ogra_: I so envy you!
[08:31] <popey> need a wifi enabled laundrette
[08:31] <popey> You can then guard against this happening while you're there:- https://www.youtube.com/watch?v=8-V8wd_aGPI
[09:44] <pstolowski> Mirv, hey, may I ask you kick the build for ppc64el only? occasional test failure on ppc bites us from time to time
[09:45] <pstolowski> Mirv, in silo 31
[10:20] <Mirv> pstolowski: ok
[10:20] <Mirv> building, let's see if it needs a couple of retries
[10:21] <Mirv> pstolowski: it's also possible for you to skip ppc unit tests, it's not we're going to need running scopes on ppc hardware extremely soon
[10:21] <Mirv> pstolowski: example at http://anonscm.debian.org/cgit/pkg-kde/qt/qtdeclarative.git/tree/debian/rules?h=ubuntu
[10:22] <Mirv> line 15 + 71-75
[10:23] <pstolowski> Mirv, yeah, that's a good idea, thanks for that
[10:24] <Mirv> or mostly just 15 + 71 + endif
[10:36] <cjwatson> Mirv: simpler and more robust (because it won't break if one architecture name is a substring of another): ifeq (,$(filter $(DEB_HOST_ARCH),$(testskip_architectures)))
[10:37] <cjwatson> Mirv: whoops, I mean   ifeq (,$(filter $(testskip_architectures),$(DEB_HOST_ARCH)))   I think
[10:42] <Mirv> cjwatson: right, thank you for improving on it
[10:44] <pstolowski> thanks cjwatson!
[10:46] <Mirv> ogra_: how's the washing machine and the requested ack? :)
[10:46] <sil2100> Damn those not working shortcuts
[10:50] <ogra_> Mirv, can you re-post the link, i dont have the backlog on this machine
[10:50] <Mirv> ogra_: https://ci-train.ubuntu.com/job/ubuntu-landing-030-2-publish/lastSuccessfulBuild/artifact/hud_packaging_changes.diff
[10:51] <ogra_> and the washing machine is still sitting cuddly wrapped in its styroform dress at the top of my basement stairs :)
[10:52] <Mirv> sil2100: do you have history if archive admins agree that something was in queue before FF if the CI Train package was requested a binNEW review before FF? the problem is I've been trying now 5-6 times asking for review on Wed, Thu and today, but now the FF is in and it would be a bit silly to require FFe. it's just unfortunate technical problem that the CI Train publishings can't be done since they ov
[10:52] <Mirv> ercome binary NEW queue
[10:52] <Mirv> ogra_: ok :) I finally got SMS that no washing machine for me today, only on Monday evening
[10:52] <ogra_> hah, you too ?
[10:53] <Mirv> ogra_: after 10 years of serving well, it ceased to be...
[10:53] <ogra_> lol, what a coincidence
[10:53] <Mirv> indeed
[10:54] <cjwatson> Mirv: feature freeze has always been interpreted as "if you got it in before FF and then it's sat in a queue, the delay is not your problem"
[10:54] <Mirv> cjwatson: yes, the definition of the queue is the problem, since with CI Train the queue means "ask on #ubuntu-release to look over at the PPA, then publish bypassing the queue"
[10:55] <ogra_> Mirv, ACK, looks ok to me
[10:55] <Mirv> ogra_: thanks!
[10:55] <cjwatson> Mirv: I'll look shortly anyway
[10:55] <cjwatson> I don't think it needs an FFe, it was ready beforehand, but we should avoid taking too long
[10:56] <ogra_> funny to have valgrind as build dep ... poor builders :)
[10:56] <cjwatson> (shortly => after the people currently trying to get out of this house to go on holiday have finished, since it's a bit noisy right now)
[10:57] <Mirv> cjwatson: thank you, and no pressure, I'll just keep on asking once or twice a day until I get hold of someone who more routinely does the reviews
[10:57] <Mirv> in case something else comes up
[11:31] <Mirv> sil2100: bzoltan_: with Mir 0.15 in wily the 009 silo should be made vivid only (if it'd to be landed). UITK can still be merged and Mir'd be made a source only upload at which point Mir team would handle themselves the vivid overlay 0.14 patch <-> wily 0.15 release delta
[11:32] <Mirv> of course, the emulator is not trivially usable at its current state even with 009
[11:39] <tsdgeos> kgunn: you handling silo 17? ↑↑
[11:41] <Mirv> sil2100: bzoltan_: I see #elsewhere that Kevin is already executing that plan to make it vivid only
[11:48] <kgunn> tsdgeos: yeah, i think gerry is actually fiddling with it...he just updated an mp
[11:48] <tsdgeos> oki
[11:49] <sil2100> Mirv, kgunn: ok, just be sure to at least prep a landing that will have the wily changes staged somewhere
[11:50] <sil2100> Mirv: still investigating the no-shortcuts bug in appmenu-qt5, but so far it seems we might need to distro-patch (and forward to Qt5) a modification that would help us forwarding shortcut execution to the platform theme
[11:51] <jibel> sil2100, we should probably land 25 even if the string is not perfect then we'll iterate if the translation is too incorrect in some languages
[11:51] <sil2100> Yeah, +1 on that
[11:51] <sil2100> The sooner this lands, the sooner we get the translations
[11:52] <jibel> rvr, I'm approving 25
[11:52] <jibel> it's difficult to find the right line in bileto from an silo number
[11:53]  * greyback has to search
[11:53] <sil2100> I usually use the dashboard and click on the ID to get me to the bileto landing
[11:53] <rvr> jibel: Ack
[11:54] <sil2100> Publishing
[11:54] <rvr> sil2100: So, do you know have powers to generate langpacks?
[11:54] <jibel> it'd be more natural to sort by silo number instead of request id IMO
[11:55] <sil2100> bfiller, kenvandine: could you guys later create a wily silo with the same translation change?
[11:55] <sil2100> rvr: well, I could, but not entirely - there are different steps here and there
[11:55] <sil2100> First we need to get the translations in
[11:55] <sil2100> Then I can poke the right people
[11:58] <Mirv> jibel: the number in dashboard could actually easily be a link to an anchored line in the bileto
[11:58] <Mirv> filing a wishlist item
[11:58] <Mirv> jibel: oh, actually it is already a link
[11:59] <Mirv> ..like sil said
[11:59] <Mirv> good that I found about it too, I didn't know :)
[12:03] <jibel> Mirv, yeah same on the trello board, I added a link from the card to the request. But for both cases it requires to open 2 applications just to find a request in bileto
[12:03] <jibel> or user ctrl+f
[12:03] <jibel> use*
[12:04] <jibel> and bileto and the dashboard are a bit redundant, should be the same app
[12:09] <sil2100> I suppose that's the plan for the nearest future
[12:24] <ogra_> Mirv, bah, empty changelog in unity-system-compositor
[12:24] <ogra_> (train bug ??)
[12:33] <Mirv> ogra_: must be, and same for qtmir. both of the MP:s do have a commit message.
[12:35] <ogra_> hmm, i thought it would block on that
[12:37] <kenvandine> sil2100, yeah, wily had a manual upload that was never synced back to trunk, we need to get that merged back into trunk first
[12:56] <bfiller> kenvandine, sil2100 : seeing errors with silo 25 publish, do we know how to fix this?
[12:56] <sil2100> bfiller: it copied the packages correctly at least, let me take a look at it
[12:56] <kenvandine> sil2100, thx
[12:57] <kgunn> sil2100: if i remove an mp/project from a silo but what is left behind is still good...does it _have_ to be rebuilt?
[12:57] <kgunn> silo 9 uitk still good, but i need to pull mir out as it's a dual landing...
[12:58] <sil2100> kenvandine, bfiller: looks like it was a one-off issue, now it's all good
[12:59] <kenvandine> sil2100, great, thanks
[12:59] <sil2100> kgunn: hey, if you remove a whole project then it shouldn't require a rebuild - besides the case where the other packages built against the project you want to remove and might not work with some other versions
[12:59] <sil2100> But I suppose that's not the case here
[12:59] <bfiller> sil2100: thanks
[12:59] <kenvandine> bfiller, sil2100: to land it in wily, i need to merge the changelog changes from wily into trunk and do a new dual landing
[13:00] <sil2100> kenvandine: ok, so it's still dual landable?
[13:00] <kenvandine> it's a major version bump, so i was avoiding doing that until we knew vivid was good to go
[13:00] <kenvandine> yeah
[13:00] <kgunn> sil2100: do i just remove and then do a reconfig? or do you need to manunally remove the old packages?...or is it all just magic?
[13:00] <kenvandine> sil2100, during the gcc5 transition they bumped the major version to match the soname
[13:01] <kenvandine> i think
[13:01] <kenvandine> no code changes, just changelog i believe
[13:01] <kenvandine> sil2100, i just didn't want to do that to get the one fix in ota6
[13:01] <sil2100> kenvandine: good choice I suppose
[13:02] <kenvandine> sil2100, so is it safe to fix that now?
[13:02] <kenvandine> i guess i should wait until you spin an image
[13:02] <sil2100> kgunn: remove them from bileto and reconfigure the silo (with the assign button) and I'll remove the leftover packages from the PPA
[13:02] <sil2100> kgunn: what silo is it?
[13:02] <kgunn> it'll be silo 9
[13:02] <kgunn> sil2100: ^
[13:02] <sil2100> kenvandine: wait a bit, we never know if we won't require a trust-store fix or something :)
[13:03] <sil2100> kenvandine: but I suppose a silo can be prepared beforehand
[13:03] <sil2100> kgunn: on it - removing mir
[13:03] <kenvandine> yeah, but i was going to push the changelog change right to trunk
[13:03] <kenvandine> so if we need another fix, it would include that
[13:03] <kenvandine> sil2100, i think if i included the version bump in a MR citrain would get angry, right?
[13:04] <sil2100> kenvandine: hm, no, it might actually just work, we allow modifications of the changelog, although there are certain cases that can cause it to go highwire
[13:04] <kenvandine> i thought the version bump would mess up the generated version
[13:05] <kenvandine> i can give it a try I guess :)
[13:08] <sil2100> No, when you bump the version number in a MP for the train, it will try to interpret its upstream version and append the CI Train bits to it
[13:08] <sil2100> As long as it's UNRELEASED of course ;)
[13:47] <cyphermox> sil2100: robru: are there plans to handle git for merge proposals leading to uploads via ci-train? does that already work?
[13:47] <cyphermox> morphis: ^
[13:48] <sil2100> cyphermox: currently only bzr works sadly, CI Train has a hard-assumption that everything is in bzr
[13:48] <cyphermox> ok
[13:48] <sil2100> But I know there are plans to include git support
[13:48] <cyphermox> just curious :)
[13:48] <ogra_> yeah, colin mentiojed plans
[13:48] <ogra_> -j
[13:48] <cyphermox> I'm asking about ci train, not LP
[13:48] <sil2100> But, as you know, there are plans for like 200 other things too ;p
[13:48] <cyphermox> yes.
[13:49] <ogra_> hehe, yeah
[13:49] <sil2100> So sadly not sure when we'll get to that ;/
[13:49] <cyphermox> no worries, just trying to get a picture of things
[13:49] <ogra_> cyphermox, well, MP support in LP is a prerequisite for the train
[13:49] <cyphermox> ogra_: sure.
[13:50] <cyphermox> ogra_: I already see a button on pages so, I figure some things exist; not that it's critical for me.
[13:51]  * ogra_ still prefers bzr over git ... but i guess i cant stay forever in the past :) 
[13:53] <Mirv> I still prefer bzr as a handy distro tool whenever I need to quickly do something, but I've managed to migrate my normal packaging workflow to git otherwise
[13:56] <sil2100> I used git a lot in the past so I like it, but I don't have anything against bzr really, it works well for everything I need
[13:57] <Mirv> git needs configuration to do everything and it can do everything, bzr has well thought out defaults, is simpler and better integrated
[14:00] <pstolowski> jibel, hello! are you ok if silo 31 is published without qa (a small wily packaging change), or do you want to take a look?
[14:04] <dobey> ogra_: it's not the past. it's just a better future :)
[14:04] <ogra_> heh
[14:06] <greyback> jibel: ^
[14:10] <jibel> pstolowski, yeah it's wily only, we don't verify them manually
[14:10] <jibel> greyback, thanks. Someone will pick it up
[14:10] <greyback> thanks!
[14:12] <pstolowski> jibel, thanks
[14:15] <cjwatson> ogra_: to clarify, I said it ought to happen, but I have no plans for that myself
[14:16] <ogra_> ah
[14:16] <cjwatson> ogra_: but git MP support certainly exists in LP
[14:16] <cjwatson> I'm not aware of any missing prerequisites at this point
[14:16] <ogra_> ah, then the train should be portable (technically)
[14:23] <sil2100> hmmm
[14:24] <sil2100> pstolowski: ok, it seems we have some CI Train bug
[14:25] <sil2100> The package has an empty changelog entry even though the merge has a proper commitlog
[14:26] <pstolowski> sil2100, the commit message was added after packages have been built
[14:26] <sil2100> Ah, ok...
[14:26] <sil2100> pstolowski: will require a rebuild then
[14:26] <pstolowski> sil2100, ok, doing
[14:26] <sil2100> Thanks!
[14:46] <AlbertA> cihelp: unity-system-compositor and qtmir boottests fail with mir 0.15 release since the mir drivers were updated (Which get updated through the seeds). Can you help confirm and pass them?
[14:55] <fginther> AlbertA, is there a new mir driver package too? The last time we ran into a problem I thought we learned that all we needed to do was pull in mir-graphics-drivers-android
[14:56] <AlbertA> fginther: do the boottest do that now?
[14:56] <fginther> AlbertA, yes
[14:58] <AlbertA> fginther: umm...
[15:02] <fginther> AlbertA, the base image being used is a little stale, would that make a difference?
[15:02] <AlbertA> fginther: potentially, like if protobuf-lite9v5 is not there
[15:03] <AlbertA> but wouldn't that be installed through the deps?
[15:03] <fginther> AlbertA, I would assume so.
[15:04] <AlbertA> fginther: I'll try locally here.... where do I see which image was used?
[15:04] <fginther> AlbertA, http://d-jenkins.ubuntu-ci:8080/job/wily-boottest-unity-system-compositor/ws/provision.log/*view*/
[15:04] <rvr> davmor2: jibel: So, attaching several images to an MMS and changing contact's picture several times with both the camera and the gallery show no ghosts in the spread and there are no crashes. This is krillin with silo 17.
[15:05] <fginther> AlbertA, if you can't view that, the answer is "Flashing version 7 from ubuntu-touch/devel-proposed-g++5/ubuntu"
[15:05] <davmor2> \o/
[15:05] <jibel> rvr, okay can you run the qtmir test plan too + some exploratory tests
[15:06] <jibel> rvr, I'm testing it too
[15:06] <rvr> jibel: Would be good to check it also in arale
[15:06] <jibel> rvr, yeah, I am on arale
[15:16] <seb128> grumph, three time this week that the promixity captor seems to not work at the end of a call
[15:17] <seb128> like I take the phone away from my ear and it doesn't turn the screen on
[15:17] <seb128> didi anybody else noticed such issues on rc-proposed bq?
[15:17] <kenvandine> fginther, did you get CI reconfigured for content-hub?
[15:17] <fginther> kenvandine, yes, it should be  on vivid+overlay now
[15:18] <kenvandine> fginther, awesome, thanks
[15:19] <rvr> jibel: I'm seeing "no data sources available" untranslated in the greeter
[15:21] <jibel> rvr, this bug has been there since image 1
[15:21] <rvr> I thought it was fixed long time ago
[15:22] <jibel> bug 1398016
[15:23] <sil2100> cjwatson: ping
[15:23] <cjwatson> sil2100: Please tell me what you want and I'll reply when I'm around.
[15:23] <rvr> jibel: Amazing
[15:23] <sil2100> cjwatson: hey! So, I wanted to know: we pushed a new version of trust-store to the bzr trunk with additions to the translation templates
[15:24] <sil2100> cjwatson: I see that those are available in the trust-store vivid translations, but they did not appear in the ubuntu-rtm/15.04 translations
[15:25] <sil2100> cjwatson: shouldn't uploads to the overlay + bzr trunk cause the templates to be imported automatically to 15.04?
[15:25] <cjwatson> sil2100: Should do
[15:25] <cjwatson> sil2100: I'm in the library with no VPN right now, can't check logs
[15:26] <sil2100> cjwatson: for instance, looking here: https://translations.launchpad.net/trust-store/trunk/+pots/trust-store/pl/+translate <- the template is present, but in https://translations.launchpad.net/ubuntu-rtm/15.04/+source/trust-store/+pots/trust-store/pl/+translate it is not
[15:27] <sil2100> cjwatson: is wgrant around to help us out if anything?
[15:28] <cjwatson> sil2100: He's on holiday this week, back next week
[15:28] <cjwatson> sil2100: I'll have a look when I get home and see if it's something obvious at the copy job level
[15:28] <sil2100> cjwatson: ok, thanks :)
[15:28] <cjwatson> Is this OMG urgent, i.e. I should get up and leave now? :)
[15:29] <sil2100> Not OMG urgent, no worries ;) We're anyway waiting for one more template change before I would request an export
[15:29] <sil2100> So we're anyway blocked
[15:29] <sil2100> But I'd like to get it into translators hands soonish
[15:30] <sil2100> So take your time and we would be grateful if you could take a look once you're back
[15:30] <cjwatson> OK
[16:00] <jhodapp> sil2100, can you free silo 38, no longer need it
[16:01] <sil2100> jhodapp: ACK
[16:02] <jhodapp> thanks
[16:02] <rvr> jibel: There ain't no ghosts
[16:03] <jibel> rvr, cool, but is there anything else?
[16:03] <rvr> jibel: The silo seems to work fine, I run the test plan and did exploratory testing and haven't found anything wrong. Have you?
[16:05] <balloons> ping cihelp. I need some job parameters on core app jenkins modified. both ubuntu-docviewer-app-ci and ubuntu-docviewer-app-ci-autolanding need to be updated to point at lp:ubuntu-docviewer-app/reboot rather than lp:ubuntu-docviewer-app
[16:05] <jibel> rvr, actually I see lot of shadows
[16:05] <rvr> jibel: :-/
[16:05] <jibel> at least 6 shadow windows in the spread
[16:05] <jibel> kgunn, ^
[16:05] <rvr> jibel: In arale?
[16:06] <jibel> yes
[16:06] <rvr> Installing silo 17 there
[16:06] <jibel> but overall it's a huge improvement no crash and shadows are rather difficult to trigger
[16:07] <jibel> rvr, if you didn't find anything I'd +1 the silo
[16:08] <jibel> rvr, I think shadows in the spread are apps shot by OOM killer
[16:09] <sil2100> Ouch, pstolowski left
[16:09] <jibel> greyback_, ^ on arale with silo 17
[16:09] <rvr> jibel: Hmm
[16:09] <kgunn> jibel: right...
[16:09] <seb128> jibel, rvr, did you notice issues with the proximity detector nor turning the screen on when getting the phone off your ear to hang up a call?
[16:09] <kgunn> so it's not perfect but no crashing
[16:09] <jibel> kgunn, yeah, it's a +1 from me
[16:10] <jibel> rvr, what do you think?
[16:10] <rvr> jibel: Yeah, +1
[16:10] <jibel> seb128, yes
[16:10] <seb128> jibel, is that reported?
[16:10] <jibel> seb128, if the call last longer than the screen timeout
[16:11] <jibel> seb128, not sure
[16:11] <seb128> that was not set as ota blocker?
[16:11] <seb128> it's quite visible/annoying
[16:12] <jibel> let me check if I find a bug
[16:13] <seb128> jibel, bug #1483127
[16:13] <jibel> seb128, thanks
[16:13] <seb128> yw
[16:13] <seb128> sil2100, ^
[16:13] <seb128> it was reported 10 days ago :-/
[16:14] <seb128> boiko, ^ is that one for you?
[16:14] <sil2100> That's really bad
[16:14] <sil2100> kgunn: ^ (since bfiller is not around)
[16:15] <sil2100> kgunn: could you take care of triaging it? I leave it up to you guys to decide if it's a blocker or not
[16:15] <sil2100> But for me it would be pretty annoying and visible
[16:18] <seb128> +1
[16:18] <jibel> sil2100, it's annoying and a regression in OTA6, it fell through the cracks
[16:18] <seb128> it's also discussed on the other IRC
[16:18] <rvr> Right, I can reproduce that proximity sensor bug
[16:19] <jibel> 17 approved
[16:20] <cjwatson> sil2100: The trust-store build doesn't appear to produce a translations tarball
[16:21] <cjwatson> sil2100: So that's why the scheme for copying those translations tarballs into 15.04 didn't work.  In fact, I've no idea how they got into vivid
[16:21] <sil2100> cjwatson: huh? But why do the templates appear in the trunk version? And we also have some existing translation templates for trust-store in ubuntu-rtm/15.04
[16:21] <sil2100> hmm
[16:21] <cjwatson> The ones that are there would have been copied from vivid
[16:21] <cjwatson> Maybe they were previously uploaded manually?
[16:21] <cjwatson> Or something
[16:22] <sil2100> Maybe, not sure... I think we'll need the trust-store people on this one
[16:22] <sil2100> kenvandine: do you know who could help out with this? ^
[16:22] <cjwatson> Or there might be something more sinister going on
[16:22] <cjwatson> It could be a failure of something in the chain that arranges for pkgstriptranslations to run
[16:23] <cjwatson> It does have .mo files
[16:23] <kenvandine> not sure...
[16:24] <kenvandine> tvoss, it would be really great to get that translation fix in wily :)
[16:24] <sil2100> Not only in wily
[16:25] <sil2100> Would be good to have the translations working anywhere, since as cjwatson mentioned it seems that we can't really get the template files imported into LP
[16:25] <sil2100> Either because the build is not creating them or for some other reasons
[16:25] <cjwatson> I'm still investigating
[16:25] <sil2100> cjwatson: thanks
[16:25] <seb128> cjwatson, kenvandine, sil2100, trust-store is in universe and not using X-Ubuntu-Use-Langpack: yes
[16:25] <seb128> that's probably why it doesn't import translations?
[16:25] <cjwatson> seb128: built in a PPA, shouldn't matter I thought
[16:25] <sil2100> Then how did we get them before?
[16:26] <jibel> sil2100, not sure if we'll have other fixes, if not could you copy the silos approved to the snapshot and kick an image before you EOD?
[16:26] <cjwatson> Oh
[16:26] <sil2100> jibel: ACK, sure thing
[16:28] <cjwatson> It's a non-virtual PPA, so it translates it to the component in the primary archive and pretends it's primary, so universe, right.  But as sil2100 says that still doesn't explain why it worked before
[16:28] <cjwatson> The .mo files are there, so worst case, you could jam translations manually into the package and they won't be stripped
[16:29] <cjwatson> But I think it would be better to set X-Ubuntu-Use-Langpack: yes
[16:29] <cjwatson> kenvandine: ^-
[16:29] <kenvandine> tvoss, ^^ could you?  if you're still around
[16:30] <cjwatson> sil2100: trust-store was in main for a while
[16:30] <cjwatson> https://launchpad.net/ubuntu/+source/trust-store/+publishinghistory
[16:30] <cjwatson> So that's probably why
[16:30] <sil2100> Oh?
[16:30] <seb128> hum, did the call start/end sound changed
[16:30] <cjwatson> I assume whatever pulled it in stopped doing so
[16:30] <seb128> it sounds really unpleasant and I didn't have that feeling before
[16:30] <cjwatson> OK, so mystery solved
[16:31] <cjwatson> Except that I'm not entirely sure how the modified translation got into vivid, but that could have been manual action
[16:31] <seb128> translation?
[16:31] <seb128> you mean template?
[16:32] <seb128> we did some template uploads through the webui for those content store new strings, but that was for wily I think
[16:32] <AlbertA> fginther: so on the bootest failures... for unity-system-compositor is that it will be a newer mir server version (running the new driver) and qtmir nested server since it's not updated will attempt to talk to the newer server but using an older driver version)  which won't work so unity8 won't start
[16:32] <cjwatson> I mean template yes
[16:33] <AlbertA> fginther: for qtmir is similar but in reverse....it will be a newer nested server trying to talk to an older mir server, which also won't work
[16:33] <cjwatson> I could probably search webapp logs for it but it would take ages and I think would ultimately not be very interesting.  X-Ubuntu-Use-Langpack: yes seems like the right answer
[16:34] <seb128> cjwatson, well, in any case I uploaded a new template to https://translations.launchpad.net/ubuntu/wily/+source/trust-store/+pots/trust-store/+upload this morning
[16:34] <seb128> dunno about other series
[16:34] <fginther> AlbertA, so if unity-system-compositor and qtmir were updated together it would work?
[16:34] <AlbertA> fginther: right
[16:37] <fginther> AlbertA, ack. I'll give them a pass then
[16:42] <sil2100> seb128: could you copy the new template from the overlay-ppa version of trust store to the ubuntu-rtm/15.04 series?
[16:42]  * sil2100 doesn't yet know how to do that
[16:42] <sil2100> ;)
[16:43] <seb128> sil2100, done from https://translations.launchpad.net/ubuntu-rtm/15.04/+source/trust-store/+pots/trust-store/+upload
[16:45] <fginther> balloons, I've added that to the list, will try to get it done today
[16:45] <balloons> fginther, ack and ty
[16:46] <seb128> sil2100, imported
[16:46] <seb128> https://translations.launchpad.net/ubuntu-rtm/15.04/+source/trust-store/+pots/trust-store/fr/+translate
[16:46] <seb128> :-)
[16:47] <sil2100> \o/
[16:47] <sil2100> seb128: thankz
[16:47] <sil2100> :)
[16:47] <sil2100> seb128: for me this link says: "Not allowed here"
[16:47] <sil2100> The +upload one
[16:47] <seb128> sil2100, not enough power yet ;-)
[16:48] <sil2100> I feel so... so weak!
[17:02] <balloons> fginther, not as big a deal, but I noticed http://91.189.93.70:8080/job/ubuntu-calendar-app-autolanding/1407/console didn't fail when it should have. The landing portion of the job 'failed', but it shows green oddly enough
[17:04] <fginther> balloons, ah thanks. I want to say that's a known bug, but I'll have to look. If not I'll add it.
[17:05] <Trevinho> sil2100: why if unity has been uploaded to distro (landing-019), upstream has not been updated yet? I see that xpathselect has not been updated, but... Shouldn't upstream been updated before (or together with) downstream?
[17:05] <Trevinho> sil2100: it looks weird in this way... I guess that when a package lands then upstream should be updated promptly
[17:11] <robru> Trevinho: silo 19 is not landed... The branches get merged after all packages migrate
[17:12] <Trevinho> robru: i see, but.... since unity landed in distro I was expecting its branches to be merged... So doing it *per project*, not *per silo*
[17:13] <robru> Trevinho: yeah, no. Silos are handled per silo. If you want to merge that one you can trigger it manually but then you'll lose reporting on the migration status of xpathselect
[17:14] <robru> Trevinho: also if unity depends on changes in xpathselect you should have noted that in the packaging so they'd migrate together
[17:14] <Trevinho> robru: it's not an hard dependency...
[17:15] <Trevinho> robru: othewise I would have done it
[17:15] <Trevinho> but, still I was hoping that once a package was landed in distro, then also its sources were merged...
[17:16] <robru> Trevinho: that is what happens, just after the last package lands in distribution
[17:16] <Trevinho> yeah I figured it now, but not sure I agree it's the best solution
[17:19] <Trevinho> robru: anyway, who can unblock libxpathselect? Since I've just triggered a recompilation with gcc5, and the failures (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xpathselect) aren't actually anything new
[17:19] <Trevinho> nor caused by that..
[17:19] <robru> Trevinho: you'd have to talk to #ubuntu-release about getting things unstuck from proposed
[17:19] <Trevinho> ok, thanks
[17:20] <robru> You're welcome
[18:13] <tvoss> kenvandine, I'm around now, what do you want me to do?
[18:18] <kenvandine> tvoss, cjwatson noticed trust-store isn't using langpacks properly
[18:18] <kenvandine> he said to set X-Ubuntu-Use-Langpack: yes
[18:18] <kenvandine> that goes in debian/control
[18:20] <tvoss> kenvandine, ack
[18:20] <tvoss> kenvandine, do you need that today?
[18:20] <kenvandine> i assume... cjwatson: ^^
[18:22] <kenvandine> or sil2100: ^^
[18:27] <sil2100> Not particulary today, since seb manually uploaded the templates
[18:32] <bfiller> sil2100: can we publish silo 17?
[18:33] <tvoss> kenvandine, I can prepare mp and silo Sunday, travelling to London anway
[18:34] <kenvandine> tvoss, me too :)
[18:34] <kenvandine> well traveling tomorrow
[19:07] <bfiller> robru: around?
[19:07] <robru> bfiller: hiya
[19:07] <bfiller> robru: mind publishing silo 17?
[19:08] <robru> bfiller: sure
[19:08] <sil2100> +1 on that
[19:08]  * sil2100 was AFK to do some housework
[19:08] <bfiller> thanks
[19:08] <bfiller> sil2100: do you know if silo 16 that landed earlier today is in an image yet?
[19:09] <sil2100> bfiller: no, not yet, but jibel asked me to build an image before I go EOD with whatever is available
[19:09] <bfiller> sil2100: but if I update from overlay ppa it should be there right?
[19:09] <sil2100> Yeah
[20:16] <sil2100> bfiller, jibel: ok, I suppose we won't get anything more besides the 2 silos today... I'll copy over the qtmir packages to the snapshot and create a new image
[20:16] <sil2100> + the trust-store translation fix
[20:27] <bfiller> sil2100: Kaleo fix going to be ready soon
[20:27] <kgunn> fginther: were you gonna poke that mir0.15 in proposed pocket thru ?
[20:28] <AlbertA> fginther: the mir boottest will fail also in a similar manner to qtmir/usc... because it will install an updated libmirclient library that wants to talk to a new server (i.e. new qtmir or new USC) but won't be available
[20:29] <AlbertA> fginther: so unity8 will fail to start too there
[20:29] <AlbertA> fginther: unless both qtmir/usc are updated
[20:29] <fginther> kgunn, I had't check that one as I didn't know it needed to be included. I can push that one forward also
[20:29] <kgunn> fginther: thanks, i think so
[20:30] <bfiller> AlbertA: any progress on proximity bug?
[20:30] <kgunn> bfiller: dang dude
[20:31] <AlbertA> bfiller: yeah I see what the issue is... but it requires some careful addition to not break the "short notification timeouts" that was added
[20:31] <bfiller> kgunn: you know about this one right?
[20:31] <kgunn> yes
[20:31] <bfiller> kgunn: ok, came up this afternoon
[20:31] <kgunn> bfiller: yes...hence my "dang dude" as in it's only been a couple of hours :)
[20:31] <bfiller> kgunn: lol
[20:32] <bfiller> kgunn: c'mon man, crank it out, time is short :)
[20:32] <bfiller> getting on a plane soon
[20:32] <bfiller> well not that soon
[20:32] <kgunn> it'll get there
[20:33]  * bfiller has his firehose out
[20:33] <kgunn> bfiller: when do you arrive london ?
[20:37] <bfiller> kgunn: flying sat night, arrive sun morning
[20:39] <kenvandine> best thing about london, it's one of the few places I can fly direct
[20:39] <kenvandine> i never even get direct flights within the US
[20:41] <sil2100> bfiller: should I wait with kicking the image then?
[20:42] <bfiller> sil2100: alesage_ are you testing silo 40? I tested it already and am good with it, just trying to decide if we should wait to spin an image with it or you need more time
[20:43] <alesage_> bfiller, I've been looking at, yes, probably need a little more time with it just to give a full pass on camera
[20:44] <alesage_> bfiller, working on now
[20:44] <sil2100> Ok then, I can still be around for a while
[20:44] <bfiller> jhodapp: does silo 40 need to be rebuilt or it has the latest?
[20:45] <jhodapp> bfiller, has the latest
[20:45] <jhodapp> wait sorry
[20:45] <jhodapp> one more build
[20:46] <bfiller> jhodapp: ok so respin and then mark ready for QA please
[20:46] <jhodapp> bfiller, alright it's building the one change I requested from the code review
[20:46] <jhodapp> will do
[20:46] <bfiller> thanks
[20:51] <fginther> AlbertA, kgunn, mir should be unblocked shortly
[20:54] <AlbertA> fginther: thanks
[20:59] <sil2100> I go AFK for ~30-45 minutes, I'll be back later and kick an image if everything is ready
[21:02] <kgunn> ta
[21:44] <cjwatson> kenvandine: what's in London?
[21:51] <sil2100> alesage_: are you looking at silo 40?
[21:51] <alesage_> sil2100, yes about to pass it
[21:51] <sil2100> \o/
[21:52] <alesage_> woo!
[21:58] <alesage_> sil2100, hiya, just want to make sure we're clear on 40--sitting across from jhodapp
[22:01] <jhodapp> sil2100, just need to make sure silo 40 is not stuck in the landing process
[22:16] <sil2100> ACK
[22:17] <sil2100> Ok, copying it over to the snapshot and kicking a new image
[22:35] <sil2100> bfiller, jibel: image building
[22:36] <sil2100> I go offline now, havew a good weekend everyone