[02:04] <ToyKeeper> I thought automatic builds were turned off...  why did 54 build so soon after 53?
[02:04] <ToyKeeper> (so soon afterward that I wonder if it was building in parallel)
[02:05] <ToyKeeper> Looks like a new device tarball went into 54.
[02:08] <ToyKeeper> If my guess is correct, there will be another soon for a new custom tarball?
[08:34] <dbarth> hey there
[08:35] <dbarth> o/ trainguards: could i have a new silo for line 86 please ?
[08:37] <seb128> shrug
[08:37] <sil2100> dbarth: on it
[08:37] <seb128> those langpack manual uploads are buggy
[08:38] <seb128> how have they been made?
[08:39] <sil2100> seb128: from the first wily export - I copied the .po files from there to the package contents
[08:39] <dbarth> thanks
[08:39] <seb128> sil2100, yeah, well that's buggy
[08:40] <seb128> that's assuming that wily has the changes from the overlay
[08:40] <sil2100> seb128: yes, isn't that the case for all our touch packages?
[08:40] <seb128> sil2100, dunno, but you regressed translations
[08:40] <sil2100> seb128: which apps have regressions? I can try manually resolving them then
[08:41] <seb128> like https://launchpadlibrarian.net/211135761/language-pack-touch-es_1%3A15.04%2B20150608.2_1%3A15.04%2B20150708.diff.gz
[08:41] <seb128> the "Got it" strings from dialer/messaging got removed
[08:41] <seb128> with the other ones from the tutorial
[08:42] <sil2100> In theory that should not have happened, as wily and overlay have the same messaging-app version
[08:42] <sil2100> Same for dialer
[08:42] <seb128> sil2100, that "let's fix that one string" approach doesn't give confidence in us having an handle on why we regressed strings and which other ones might have the same issue
[08:42] <seb128> right
[08:42] <seb128> in theory
[08:42] <seb128> in practice it happened
[08:42] <sil2100> So either the LP export does something funny or I don't know...
[08:43] <seb128> and I think we should understand why
[08:43] <sil2100> Definitely
[08:43] <seb128> rather than patching those specific examples
[08:43] <sil2100> In this case I suppose there's too many cases to actually patch them up manually anyway, hm
[08:43] <seb128> what happened to the ppa vs derived distro discussion?
[08:44] <sil2100> seb128: Victor poked me yesterday night already about a similar case in webbrowser-app, where on the LP webpage a specific string was available, but the export didn't have it
[08:44] <sil2100> seb128: we're staying with the overlay and the LP team has a solution for the translations, but it won't be available for OTA-5 possibly
[08:44] <seb128> has that been discussed anywhere in public?
[08:45] <seb128> I'm interested in the discussion/suggested solution
[08:45] <seb128> but I didn't see anything about it
[08:45] <sil2100> No... there generally was no public discussion, Pat and Olli were the decisive party
[08:45] <sil2100> I only provided Pat with feedback I got from various people
[08:45] <seb128> k
[08:46] <seb128> shame those are not open discussions :-/
[08:46] <seb128> anyway
[08:46] <seb128> it's not an export issue
[08:46] <seb128> https://translations.launchpad.net/ubuntu/wily/+source/dialer-app/+pots/dialer-app/fr/+translate?batch=10&show=all&search=Got+it
[08:46] <seb128> the wily template doesn't have the string
[08:46] <sil2100> I wonder why, since they have the exact same version
[08:48] <sil2100> I don't have enough knowledge of how translations in LP work, maybe we should call in someone from the LP team for help?
[08:49] <seb128> https://translations.launchpad.net/ubuntu/wily/+source/dialer-app/+imports
[08:49] <seb128> it's approved, but not imported
[08:50] <seb128> k, I asked on #ubuntu-devel
[08:51] <ogra_> sil2100, do you know if not having a date in the today scope is wanted ?
[08:51] <ogra_> or is that a bug
[08:51] <sil2100> No idea
[08:51] <sil2100> seb128: ah, so that's the reason then
[08:51] <seb128> yes
[08:52] <seb128> import not enabled
[08:52] <sil2100> Same for webbrowser-app I see ;/
[08:52] <sil2100> Well, we anyway wanted to prepare a re-spin with missing translations
[08:53] <seb128> how do you plan to catch missing translations?
[08:53]  * seb128 is interested on how we could do that
[08:53] <seb128> because I've no clue ;-)
[08:55] <sil2100> hah, well, there's Victor that always scans the core apps for missing translations for es... but yeah, there's no real way to check all of the languages and packages
[08:55] <sil2100> We simply knew that we couldn't get some translations on time anyway
[08:56] <sil2100> For things that landed yesterday night for instance
[08:56] <seb128> well, there is a different between not getting some and regressing some we had
[08:56] <sil2100> So a re-spin was in order anyway
[08:56] <sil2100> Indeed, I prepared those on a silo and Victor gave it a spin
[08:56] <sil2100> And noticed only a few things missing
[08:57] <sil2100> Anyway, it was all done really at the last minute, as the LP export took much longer than I expected
[09:11] <ogra_> sil2100, hmm, my krillin has a date in the today scope, my arale doesnt
[09:11] <ogra_> davmor2, ^^^ you had the same issue, do you have the date widget on your krillin ?
[09:12] <ogra_> there is definitely somethin wrong here
[09:13] <davmor2> ogra_: talk to penk
[09:15] <davmor2> ogra_: phone are currently reflashing to start roaming tests
[09:16] <ogra_> ah
[09:24] <pstolowski_> seb128, ping
[09:25] <seb128> pstolowski_, hey, ping with context is better
[09:25] <pstolowski_> ;)
[09:25] <pstolowski_> seb128, about yesterday's failures on arm64 - https://launchpadlibrarian.net/210999339/buildlog_ubuntu-wily-arm64.unity-scopes-api_0.6.19%2B15.10.20150706.1-0ubuntu1_BUILDING.txt.gz
[09:25] <seb128> yes?
[09:26] <pstolowski_> seb128, can you or somebody else check for me if that box has filesystem other than ext4 for the build dir?
[09:26] <seb128> cjwatson, ^ maybe you can help there?
[09:26] <seb128> pstolowski_, I've no idea about that
[09:28] <pstolowski_> seb128, sure, np
[09:35] <cjwatson> seb128: only infinity knows the exact setup there, unless it's made evident by some build
[09:35] <cjwatson> I would be surprised if it weren't ext4 though
[09:37] <pstolowski_> cjwatson, any chance it would still be ext3? i'm debugging a test failure which relies on nanosecond prevision for filetimestamps (which is unsupported on <ext4) and cannot reproduce the failure on porter arm64 box which has ext4. ext3 on the build machine could explain the failure
[09:37] <cjwatson> pstolowski_: I think it's unlikely, but infinity could tell you.
[09:37] <pstolowski_> cjwatson, k, thanks
[09:42] <davmor2> sil2100: can you do the magic on the device tarball to make the ticket appear while I go test it ta
[09:49] <sil2100> davmor2: ok!
[09:50] <sil2100> davmor2: hm, is it approved already?
[09:50] <sil2100> davmor2: it's this one, right? http://people.canonical.com/~alextu/tangxi/master/device_arale-20150709-8965e37.changes
[09:51] <davmor2> sil2100: no I'm just testing it now
[09:51] <sil2100> Ok, someone set it to 'Granted' already, switching back
[10:45] <sil2100> rvr: hey! Don't test translations for now ;)
[10:52] <jibel> ogra_, did you file a bug for the missing date widget on arale?
[10:52] <ogra_> jibel, penk just told me in the other channel that there is a fix to land before the OTA, so i didnt bother
[10:52] <ogra_> (seems the tarball is already being tested by them)
[10:52] <jibel> ogra_, okay, thanks
[11:09] <sil2100> jibel, davmor2, rvr: custom tarballs ready!
[11:10] <sil2100> brb
[11:18] <jibel> why do I receive update notification twice?
[11:19] <ogra_> i had that before
[11:19] <ogra_> but it stopped again
[11:24] <jibel> it seems like an indicator-message issue, push client received a single notification
[11:35] <jibel> sil2100, will you update the translations, some strings in unity8 are not translated (Restart & Install for example)
[12:28] <greyback> trainguards: hey, there's a few old packages in silo0 I'd like removed, who has the permissions to do that?
[12:30] <sil2100> jibel: yes, as mentioned  to rvr translations are broken
[12:30] <sil2100> So please don't test those yet...
[12:30] <sil2100> jibel: we had a whole big discussion on #ubuntu-devel, wily didn't have all the required automation setup by accident...
[12:30] <sil2100> So strings weren't auto-imported
[12:31] <greyback> wat
[12:32] <jibel> sil2100, ok, I didn't read devel
[12:35] <Mirv> greyback: we do
[12:35] <sil2100> greyback: ah, sorry, missed your ping since I'm in the middle of cooking
[12:36] <sil2100> It's as Mirv said ;)
[12:36] <sil2100> greyback: which packages do you want removed?
[12:36] <Mirv> greyback: libevdev, qtubuntu ... ?
[12:37] <greyback> Mirv: everything that hasn't been rebuild recently: libevdev, qtubuntu, qtsystems-opensource-src ubuntu-keyboard unity-api
[12:37] <greyback> sil2100: no worries, don't burn your food!
[12:38] <Mirv> greyback: done
[12:38] <greyback> Mirv: thanks!
[12:38] <Mirv> np
[13:23] <oSoMoN> trainguards: I’m going to want to publish silo 8 (which was targetted at a dual landing) to wily only, do I need to update the spreadsheet and reconfigure?
[13:38] <boiko> trainguards: can I get a silo assigned to row 88?
[13:39] <sil2100> oSoMoN: no, we can simply remove the vivid parts from the silo and publish
[13:40] <oSoMoN> sil2100, great, I’ll let you know once it’s ready, hopefully within the next 30min or so
[13:42] <sil2100> oSoMoN: ok :)
[13:42] <sil2100> boiko: on it
[13:42] <boiko> sil2100: nice! thanks!
[13:55] <dbarth> o/ trainguards: could i have a new silo for line 86 please ?
[13:56] <sil2100> dbarth: sure! Do you want that to be a dual landing?
[13:56] <sil2100> Since we won't be able to release both wily and vivid this week then
[13:57] <sil2100> We can always release only wily in a dual landing, but just want to know if you want that extra manual step
[14:05] <dbarth> sil2100: yes, please
[14:05] <dbarth> ie, dual, but i don't mind the xtra manual step next week
[14:05] <dbarth> when the landing window reopens
[14:08] <sil2100> k
[14:13] <sil2100> hmmm
[14:14] <sil2100> dbarth: so...
[14:14] <sil2100> We might have a problem
[14:15] <sil2100> dbarth: could you push directly to trunk a commit with the debian/changelog?
[14:16] <sil2100> dbarth: since I the train does not allow releasing something that doesn't originally have debian/changelog in trunk
[14:18] <sil2100> (a bit of a strange error)
[14:23] <dbarth> sil2100: let me check with mardy for that part
[14:33] <pmcgowan> dbarth, I assume we have not landed oxide 1.8?
[14:34] <sil2100> No, the silo is still there...
[14:37] <dbarth> it's not, but it's tested, just that there isn't a more recent build
[14:37] <pstolowski> hey trainguards, may i ask for a silo for line #90? (it's ok if it waits till gates are open again)
[14:37] <dbarth> pmcgowan: ^^
[14:38] <dbarth> is ci/qa still open for that one?
[14:39] <pmcgowan> dbarth, nope missed the train
[14:39] <sil2100> A train pun!
[14:41] <dbarth> hmm :/
[14:41] <sil2100> pstolowski: on it
[14:42] <pstolowski> thanks!
[14:51] <boiko> sil2100: could you please trigger a rebuild of telephony-service from silo 002 for the ppc64el arch? there is a test failure that happens 1/10 of the time due to a (not yet figured out) crash in the telepathy mocks
[14:53] <mvo> hey trainguards - silly question - I have a click update that only changes the click chroot in landing-045. how is the QA signoff handled for that? I tested it on my BQ device and noticed no regressions what is the next step before I can publish?
[14:54] <sil2100> boiko: sure
[14:55] <sil2100> boiko: re-ran it now
[14:56] <sil2100> mvo: I  guess QA can decide that no testing is needed and just approve it, but we have the gates closed right now due to OTA-5
[14:57] <mvo> sil2100: I see, thats fine. I guess it can stay as ready in there for now, I will update the bugreport
[14:57] <mvo> (well, fine with me in any case)
[14:57] <mvo> thanks!
[15:16] <pmcgowan> mvo, sil2100 drat i thought that landed
[15:16] <sil2100> Was that required?
[15:17] <pmcgowan> we should have had it some time ago
[15:18] <kenvandine> sil2100, does the train have a way to dual land packages that aren't from bzr?
[15:19] <sil2100> kenvandine: sadly no...
[15:20] <kenvandine> renatu, bfiller: i think we need to do a wily landing for line 91 then a sync to vivid
[15:20] <kenvandine> for this time
[15:20] <sil2100> kenvandine: the train disallows that - it not allow assigning a silo like that...
[15:20] <mvo> pmcgowan: its low risk, all code changes are in the chroot.py, sorry that it did not land earlier, I am not familiar with the current qa processes :/
[15:20] <sil2100> kenvandine: and besides, dual landing is like syncing, it only works on CI Trained version numbers
[15:21] <mvo> pmcgowan: is there a alternative? like only release it for the users of the sdk ?
[15:21] <bfiller> kenvandine: ok
[15:22] <pmcgowan> mvo, maybe I am confused, do we only need that on the developer desktop, or also on the image
[15:22]  * sil2100 gently pokes ogra_ 
[15:23] <kenvandine> sil2100, one more question... can the silo land new packages?  no previous version in the archive?
[15:23] <sil2100> kenvandine: yes, the train allows that - but as I noticed today, the current code requires the debian/changelog already present on the target trunk
[15:24] <sil2100> So, you would have to prepare the packaging beforehand, have it in trunk and then release it through the train with an empty merge, for instance
[15:25] <kenvandine> renatu, ^^
[15:25] <pmcgowan> mvo, ?
[15:26] <kenvandine> renatu, so go ahead and merge your initial branch into trunk
[15:26] <kenvandine> then create an empty merge proposal
[15:26] <mvo> pmcgowan: hmm, so there are two parts, the chroot change so that the sdk can build a chroot for ubuntu-sdk-15.10-dev1. that is part of this MP. the other part is the updated meta package, that happend in wily, let me find the upload
[15:27] <renatu> sil2100, could I have a empty project and a initial MR with all code, instead?
[15:27] <mvo> pmcgowan: that was https://launchpad.net/ubuntu/+source/ubuntu-touch-meta/1.230
[15:27] <pmcgowan> mvo, but which part is needed on the phone itself
[15:28] <renatu> sil2100, will be easy to review
[15:28] <sil2100> renatu: sadly no... I thought that worked in the past, but now it needs to have the debian/changelog file in place at least
[15:28] <pmcgowan> the chroot change should go into the sdk ppa I'd think
[15:28] <pmcgowan> mvo
[15:28] <sil2100> Not sure if there are any other requirements ;/
[15:28] <mvo> pmcgowan: the later (the ubuntu-touch-meta) upload
[15:29] <pmcgowan> mvo, ok so thats all we care about here
[15:29] <mvo> pmcgowan: sorry, I am not sure what the process is for a change like this, should this be directly uploaded to the overlay ppa? or land via a train package upload? or something else?
[15:29] <pmcgowan> mvo, at this point we land the meta package change when the gates open, and the chroot change can then go to the sdk ppa
[15:30] <mvo> pmcgowan: ok
[15:31] <renatu> sil2100, kenvandine, Is ok to merge only the debian dir for now. And create a new mr with all the code?
[15:31] <sil2100> renatu: I think that would work
[15:31] <renatu> sil2100, ok nice
[15:31] <sil2100> renatu: sorry for the trouble
[15:32] <renatu> sil2100, np
[15:43] <seb128> shrug
[15:43] <seb128> current rc image (62) doesn't show me the sim-switcher header on dialer/messaging
[15:53] <pmcgowan> sil2100, do we have a translation fix needed per sebs email?
[15:54] <seb128> pmcgowan, yes, we discussed that earlier, the langpacks updates are buggy
[15:55] <seb128> pmcgowan, wily templates import were not enabled, so it means wily didn't had the new string, which means the export are incomplete, they even regressed the strings we manually patched for the previous ota
[15:55] <pmcgowan> seb128, ok so someone is rectifying I take it?
[15:56] <seb128> pmcgowan, yes, launchpad team enabled the imports, things are being imported as we speak
[15:56] <seb128> then we need a new export
[15:56] <seb128> then langpack updates with that export
[15:56] <pmcgowan> ack
[15:56] <pmcgowan> seb128, btw I see the sim switcher here
[15:56] <seb128> we really need a better way to see translations issues
[15:57] <pmcgowan> seb128, any ideas on that?
[15:57] <seb128> rather than "wait for some user to report a bug about a string missing"
[15:57] <seb128> not really no :-/
[15:58] <seb128> maybe step 1 would be to encourage are non english speaker devs to test the device is their locale rather than english
[16:00] <pmcgowan> seb128,  is there a programmatic way to detect missing translations?
[16:00] <seb128> not really
[16:01] <seb128> there is no automatic way to tell if a string should be translated or not
[16:02] <seb128> like "ubuntu" shouldn't be translated
[16:02] <seb128> but we don't really have a rule/way to say what is a brand/tech word to not translate/...
[16:03] <seb128> I guess we could have tools/script to verify the state of things though
[16:03] <pmcgowan> I see
[16:03] <seb128> like fetch the source/update the template/download the launchpad one/compare the number of strings translatable
[16:04] <seb128> to verify that we don't have launchpad template lagging behind
[16:08] <robru> john-mcaleely: http://requests.ci-train.staging.ubuntu.com/#?q=john lol, 15 identical records? what happened there?
[16:08] <cjwatson> seb128: "ubuntu" shouldn't be translated> you sure of that example? :-)
[16:09] <seb128> lol
[16:09] <cjwatson> https://wiki.ubuntu.com/DistributionDefaultsAndBranding#Notes_on_branding_translations
[16:09] <seb128> learning every day ;-)
[16:09] <seb128> cjwatson, thanks
[16:10] <cjwatson> (agreed in general though)
[16:11] <cjwatson> export is currently waiting for webops vanguard to have a moment
[16:12] <john-mcaleely> robru, I believe I was given an error message
[16:12] <john-mcaleely> or, actually, no
[16:12] <john-mcaleely> no feedback at all
[16:12] <john-mcaleely> I concluded that this was not designed for device-tarball landings yet
[16:13] <john-mcaleely> and decided not to bother you about that :-) robru
[16:13] <john-mcaleely> I speculate that my input to 'name of assigned silo' was confusing
[16:14] <john-mcaleely> ('cos I couldn't even see the end of that string...)
[16:15] <john-mcaleely> I'm amazed I tried 15 times :-) but I certainly tried a few
[16:17] <robru> john-mcaleely: were you typing in 'Landed' to the status field every time?
[16:19] <robru> john-mcaleely: because 'Landed' landings are hidden by default, 'Landed' means 'this is totally done, ignore it'
[16:19] <john-mcaleely> well, I don't think I typed it more than once
[16:19] <john-mcaleely> that was the odd part - it just 'did nothing' when i hit save
[16:20] <john-mcaleely> I did select landing from a menu of options presented to me
[16:20] <john-mcaleely> landed, sorry
[16:21] <robru> john-mcaleely: yeah, 'did nothing' means "it saved the record and then didn't display it because Landed landings are hidden by default."
[16:21] <john-mcaleely> robru, that has a certain logic to it
[16:21] <john-mcaleely> in a fail sort of way :-)
[16:21] <robru> john-mcaleely: I'll put in a check so that new records can't be "Landed"
[16:22] <robru> john-mcaleely: well we need to hide Landed landings, otherwise the list will be huge and never stop growing.
[16:22] <john-mcaleely> I'm sure
[16:28] <popey> sil2100: https://bugs.launchpad.net/bugs/1471609
[16:38] <robru> john-mcaleely: ok if you try it now you should find that new records show up.
[16:40] <sil2100> popey: thanks!
[16:43] <john-mcaleely> robru, ok, so there is a box 'status', which offers the dropdown 'abandonded' or 'landed'. I now know 'landed' is wrong.
[16:43] <john-mcaleely> abandonded also feels wrong
[16:43] <john-mcaleely> why is this a box?
[16:43] <john-mcaleely> what do I put there
[16:44] <robru> john-mcaleely: for clicks and tarballs probably nothing. For the most part that box is set automatically by jenkins, but clicks & tarballs don't use jenkins, so there's not much really to say. You'd set it to 'Landed' after the request is completed and no longer relevant.
[16:45] <sil2100> pmcgowan: yeah, everything is known and in progress
[16:45] <sil2100> cjwatson: is the LP export that's visible on https://translations.launchpad.net/ubuntu/wily/+language-packs the correct one?
[16:45] <sil2100> cjwatson: with the new imports?
[16:45] <robru> john-mcaleely: it's a free form text box, Landed and Abandoned are just suggestions. Feel free to write 'hey this needs to be tested for the next image' or whatever you like in there.
[16:46] <robru> john-mcaleely: if you leave it blank it actually defaults to 'New'
[16:46] <john-mcaleely> robru, ah, thats not very obvious from the UI
[16:47] <john-mcaleely> anyway, I think I just made a device tarball request
[16:47] <robru> john-mcaleely: yeah sorry, some growing pains. Right now all the fields are free-form text to mimic the freedom we had with spreadsheet cells.
[16:47] <john-mcaleely> makes some sense
[16:48] <robru> john-mcaleely: seems reasonable. You don't have to specify 'dual' or 'stable-phone-overlay' or anything. Those don't hurt, but they're only used by jenkins, irrelevant to what you're doing there.
[16:48] <john-mcaleely> I see, ok.
[16:51] <cjwatson> sil2100: sadly that was from before most of the pot imports
[16:51] <sil2100> :<
[16:51] <cjwatson> or rather started before them so I would guess has not picked them up
[16:51] <cjwatson> ICBW, you could live dangerously, but I'm sceptical
[16:51] <sil2100> cjwatson: can we have a new export happening now? Since the imports finished, right?
[16:52] <john-mcaleely> ah yes, I see
[16:52] <sil2100> cjwatson: could you trigger one now? :)
[16:52] <sil2100> I need to fix what I broke
[16:53] <cjwatson> sil2100: I can't do it personally, I've been trying to find a sysadmin
[16:53] <cjwatson> trying a GSA at the moment
[16:56] <cjwatson> sil2100: ok, it's running now, but I can't say how long it'll take
[16:56] <sil2100> cjwatson: thank you!
[16:56] <cjwatson> and will not be around to check, so you're probably best to just poll https://translations.launchpad.net/ubuntu/wily/+language-packs occasionally
[16:56] <sil2100> I'll try being around when it happens
[16:56] <cjwatson> (not like the logs tell me much other than started/stopped anyway)
[17:03] <robru> john-mcaleely: looks good
[18:32] <robru> fginther: hey, you around? I'd like to test your branch out shortly.
[18:33] <fginther> robru, I'm here
[18:33] <robru> fginther: is your jenkins branch in a usable state? ready for me?
[18:35] <fginther> robru, it is
[18:35] <robru> fginther: sweet. Ok I'm mid-deploy with a mojo spec that only deletes /var/lib/jenkins/secret*
[18:35] <robru> fginther: will test yours in a couple minutes.
[18:36] <fginther> robru, probably requires one change to your mojo spec. "volume-ephemeral-storage: False" must be defined in the services file
[18:36] <robru> fginther: ok, thanks.
[18:36] <robru> fginther: does that prevent the initial install hook from doing anything to the ephemeral storage?
[18:37] <fginther> robru, yes, it blocks the install hook from proceeding until nova storage is attached, it will not install to the ephemeral disk
[18:37] <robru> fginther: sounds great
[18:38] <Mirv> sil2100: we're correcting the UITK wily proposed thing with zoltan, and it'll probably need to be dual released (only changes is ubuntu-keyboard-autopilot dependency change to be armhf i386 amd64 only)
[18:38] <sil2100> Mirv: ok, no other changes? In that case it should be fine :)
[18:39] <Mirv> sil2100: yes, just http://bazaar.launchpad.net/~bzoltan/ubuntu-ui-toolkit/landing_2015-06-26/revision/1547
[18:41] <robru> bzoltan_: did you get the memo about being able to assign your own silos yet?
[18:45] <oSoMoN> trainguards: silo 8 is now ready for landing in wily only, can you please delete the vivid packages and do the publication dance?
[18:45] <robru> oSoMoN: on it
[18:45] <sil2100> ...ok, robru's on it :)
[18:45] <sil2100> o/
[18:46] <robru> oSoMoN: ok deleted, just mark the spreadsheet as ready to publish and I'll publish
[18:46] <robru> sil2100: goodnight!
[18:46] <sil2100> Not yet!
[18:46] <sil2100> Just waving for no particular reason
[18:47] <sil2100> I still need to finish those translations...
[18:47] <robru> sil2100: welcome back!
[18:47] <oSoMoN> robru, done
[18:47] <robru> oSoMoN: https://code.launchpad.net/~osomon/webbrowser-app/desktop-tabs-prototype/+merge/262358 just need this top approved
[18:48] <oSoMoN> oh, right, let me do that now
[18:48] <oSoMoN> done
[18:51] <robru> boiko: https://ci-train.ubuntu.com/job/ubuntu-landing-002-2-publish/110/console need some merges approved
[18:52] <boiko> robru: ouch! let me handle that
[18:55] <boiko> robru: fixed
[18:55] <robru> boiko: publishing
[18:56] <boiko> robru: thanks!
[18:56] <robru> boiko: you're welcome
[19:36] <dobey> whee, wily-proposed is broken with gnutls again i guess :(
[19:44] <bfiller> robru: silo 35 can be deleted
[19:44] <robru> bfiller: thanks
[21:04] <fginther> AlbertA, is this dependency failure a known issue? https://jenkins.qa.ubuntu.com/job/mir-clang-wily-amd64-build/651/console
[21:06] <AlbertA> fginther: no
[21:20] <fginther> AlbertA, well prior to hitting that failure, my plan was to create a mir-clang-ts-wily-amd64-build to perform the thread-sanitizaer build
[21:20] <fginther> AlbertA, so this would run in parallel to mir-clang-wily-amd64-build
[21:27] <AlbertA> fginther: ok
[21:27] <AlbertA> fginther: sounds good
[21:29] <AlbertA> fginther: yeah we are started to see that failure today, only in the clang job: https://code.launchpad.net/~kdub/mir/fix-1471858/+merge/264279
[21:31] <fginther> AlbertA, hunh, I was assume that some dependency was still stuck in proposed or something, will have to inspect this directly for the un-installable package :-(
[21:31] <fginther> AlbertA, should have some idea on this today
[21:32] <sil2100> jibel, davmor2, ToyKeeper: preparing the fixed translations, language export finished
[21:53] <fginther> AlbertA, Here's the trouble - http://paste.ubuntu.com/11851858/
[21:53] <fginther> AlbertA, manually installing systemd to update it to 222-1 solves the problem
[21:53] <fginther> AlbertA, No idea why apt can't figure it out
[21:54] <fginther> (then again, I don't really know how apt-works so...)
[21:57] <AlbertA> fginther: ack
[22:21] <sil2100> New langpacks uploaded, building
[22:59] <sil2100> jibel, rvr, davmor2, ToyKeeper: I kicked a new image with the 'hopefully' fixed translations
[22:59] <sil2100> From what I checked those look fine this time
[22:59] <ToyKeeper> sil2100: Which device/channel, and what's the expected bulid number?
[23:00] <sil2100> rc-proposed for all devices, the image number should be 64 for krillin and 57 for arale
[23:00] <ToyKeeper> Okay, thanks!
[23:15] <sil2100> Thanks!
[23:15] <sil2100> Goodnight!