[00:34] <Saviq> ribru, ↑ please
[00:34] <ribru> Saviq: rtm 4
[00:35] <Saviq> ribru, thank you :)
[00:35] <ribru> Saviq: you're welcome
[00:35] <ribru> Saviq: out of curiousity, how did you fill out row 77? it was missing all the necessary spreadsheet formulas. I fixed it, just wondering how it gets that way...
[00:35] <Saviq> ribru, it was there already
[00:36] <ribru> Saviq: you didn't like, copy & paste the values from somewhere? even if you insert a new blank row it should fill those formulas in...
[00:36] <Saviq> ribru, I did, but just per-field
[00:36] <Saviq> ribru, I didn't touch any of the automagic fields
[00:36] <ribru> Saviq: hm, weird. mysterious spreadsheet bs :-/
[00:42] <Saviq> ribru, need help ↑
[00:42] <Saviq> https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-004-1-build/61/console
[00:42] <Saviq> how do I resolve that?
[00:44] <ribru> uh
[00:45] <ribru> Saviq: well the easiest thing to do would be to just bump the unity8 version number to 8.01.1 or 8.02 I guess
[00:45] <Saviq> ribru, looks like sync should still rewrite 15.04 into 14.10...
[00:45] <Saviq> ribru, yeah, that's what I thought, but meh :|
[00:45] <ribru> Saviq: no, the sync *did* do that, but the problem is that it shouldn't, because 15.04 is already there
[00:45] <ribru> Saviq: so I guess at some point you did a binary sync from vivid to rtm already? the version in rtm is 15.04 with no ~rtm tag
[00:46] <Saviq> ribru, well, sync took the upstream 15.10
[00:46] <Saviq> ribru, it is 15.04 *with* the rtm tag
[00:46] <Saviq> ribru, https://launchpad.net/ubuntu-rtm/+source/unity8
[00:46] <ribru> bah
[00:46] <Saviq> ribru, it was a source copy, that copied 15.04, now it tried to do 14.10
[00:47] <Saviq> meh for bumping, but what can I do...
[00:48]  * Saviq goes for -rtm
[00:49] <ribru> Saviq: yeah I'm not sure what's going on there. it looks to me like the version number it's trying to use is correct, but this is thwarted by somehow a vivid version number already being at the destination. second time today I've seen this where rtm had a newer version than it should have and then the code that was generating a very reasonable version number
[00:49] <ribru> was rejected.
[00:49] <ribru> Saviq: basically yeah, you have to mangle the version number yourself and upload manually
[00:49] <Saviq> ribru, well, I know *how* it happened
[00:49] <Saviq> ribru, just not sure what the correct resolution would be :)
[00:50] <Saviq> ribru, I synced it from vivid last Friday
[00:50] <Saviq> ribru, that was a source sync, but it only appended ~rtm
[00:50] <ribru> Saviq: a binary sync?
[00:50] <Saviq> ribru, source sync, hence the ~rtm
[00:50] <Saviq> ribru, basically a silo sync
[00:51] <Saviq> ribru, line 1985 in the train archive
[00:53] <ribru> Saviq: this other error you're getting is much more interesting
[00:53] <Saviq> ribru, it is indeed
[00:53] <Saviq> getting the same for the other source :/
[00:54] <Saviq> and totally no error msg :'|
[00:54] <ribru> Saviq: I'm in the middle of converting citrain to use absolute paths instead of relative paths, because the code was a mess of spaghetti cd'ing everywhere. there was a bug where it would cd to the wrong place, do stuff, then cd back, and files weren't where we expected them
[00:54] <ribru> Saviq: I'll try reverting my last commit and see if that gets it back into a state that can hobble along
[00:55] <ribru> Saviq: ok try it again now, this time it should probably "work" (there'll still be an error, but this time the error should come after the PPA upload, and then you can run a WATCH_ONLY afterwards as a workaround)
[00:56] <Saviq> ribru, it's worky
[00:56] <Saviq> I mean it's trying
[00:58] <ribru> Ursinha-afk: ^^ my awesome branch is less awesome than I thought
[00:59] <Ursinha> ribru: s/Ursinha-afk/Ursinha/ :)
[00:59] <Ursinha> ribru: oops
[00:59] <ribru> Ursinha: my next branch will convert even more relative paths into absolute ones so hopefully that gets that back into a consistent state.
[01:00] <ribru> Ursinha: for now I reverted production, so things can work while I tinker
[01:09]  * ToyKeeper wonders why, 4 hours after imgbot announced the start of build 143, that image still isn't on the image servers
[01:17] <ribru> justinmcp_: welcome!
[01:17] <ribru> Justin Master Control Program.
[01:18] <ribru> justinmcp_: ok so do you know about the spreadsheet?
[01:19] <justinmcp_> ribru: i know nothing
[01:19] <ribru> justinmcp_: ok. funny i thought we did this already once
[01:19] <ribru> justinmcp_: ok go here: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc#gid=0
[01:20] <ribru> justinmcp_: find the first empty row (78)
[01:20] <justinmcp_> ribru: got it
[01:20] <ribru> justinmcp_: fill out the info as best you can (some fields are autogenerated, so just leave blank whatever you're not sure of). look at the other rows for guidance. ask me if you have any questions.
[01:21] <justinmcp_> ribru: and then magic?
[01:22] <ribru> justinmcp_: less like magic, and more like... http://i.ytimg.com/vi/MjuioxC5WwA/maxresdefault.jpg
[01:23] <justinmcp_> ribru: :) confidence is high
[01:24] <ribru> justinmcp_: I'd like to retroactively rename ci train to... 'ci house of cards'.
[01:24] <ribru> case in point ^
[01:26] <ribru> justinmcp_: column A is purely informational and isn't actually used anywhere, so don't write your life story in there like saviq does ;-)
[01:27] <justinmcp_> ribru: *disappointment*, nobody cares :(
[01:28] <Saviq> !!
[01:28] <Saviq> my description has *links* to bugs!
[01:28] <ToyKeeper> Column A is used by QA though...  very helpful to have a list of bugs fixed there.
[01:28] <Saviq> and everything!
[01:28] <Saviq> ToyKeeper, say you like my Column A, you know you do!
[01:29] <ToyKeeper> I do, actually.
[01:29] <ribru> Saviq: what links? there's no links ;-)
[01:29] <Saviq> hmm this sounded much more sexist than I intended it to...
[01:29] <ToyKeeper> It saves me the trouble of populating that info myself on QA's kanban cards.  :)
[01:29] <Saviq> ribru, see! links! http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-007
[01:29] <ribru> Saviq: oh you are doing links now. you used to just have the numbers ;-)
[01:29] <Saviq> ribru, I was hoping you'd do links :P
[01:29] <Saviq> ribru, but since you don't
[01:30] <ribru> Saviq: yeah everything's gonna change when we dump the spreadsheet, doesn't make sense to do new features right now
[01:30] <ToyKeeper> Most of the time, I have to either dig up the bug numbers or at least convert them to clickable URLs.
[01:30] <Saviq> hah
[01:32] <ribru> Saviq: ToyKeeper it's just that the spreadsheet doesn't let you scroll smoothly, it forces the view to snap to the rows. and when a single row is larger than my screen it destroys the UX.
[01:32] <Saviq> ribru, get a bigger screen ;p
[01:32] <ToyKeeper> ribru: Indeed, that's obnoxious.  I have the same issue.  Usually I just go to one of those cells and copy/paste the info elsewhere so I can actually read it.
[01:33] <ribru> Saviq: well excuuuuuse me! my 27" is on the other side of the room. I'm just using my 10" for now because I'm in bed with broken ribs!
[01:33] <ToyKeeper> But since I'm generally copying it anyway, it's not a big inconvenience.
[01:33]  * ToyKeeper looks forward to no-more-spreadsheet
[01:33] <ribru> ToyKeeper: soon
[01:33] <Saviq> ribru, you're an engineer, you should've engineered a crane to hold your 27" over your head!
[01:33] <Saviq> ribru, it'd have worked, I assure you
[01:34] <Saviq> and would be relatively safe
[01:34] <ribru> Saviq: hindsight is always 20/20. couldn't do that after I was already injured
[01:34] <Saviq> ribru, excuses excuses :P
[01:35] <Saviq> ribru, on that note, I think I managed to convince dch to take my version, I just needed to force a lower version in my branch
[01:35] <Saviq> and now the train-generated one will be higher again
[01:35] <Saviq> hmm hmm
[01:36] <Saviq> wait
[01:36] <justinmcp_> ribru: finished, I guess..
[01:36] <Saviq> it will not be higher than the one in distro, though, will it...
[01:36] <Saviq> yeah, that was stoopid
[01:38] <ribru> justinmcp_: ok, just set J78 to 'Yes' (which triggers the bot to notify us that you're ready)
[01:40] <justinmcp_> its almost like magic
[01:40] <ribru> justinmcp_: ok, I gave you silo rtm 9, which means you can go to http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=justinmcp and click 'Build'
[01:44] <ToyKeeper> Yup, magic indeed.
[01:44] <ribru> Saviq: you are just not having any luck today...
[01:45] <Saviq> ribru, nah, it just uploaded
[01:45] <ToyKeeper> justinmcp_: Fatal error on your first try.  You've got the magic touch!  :)
[01:45] <Saviq> ribru, will be fine now
[01:45] <justinmcp_> this is why I code
[01:45] <ribru> how did all this 15.04 shit get into rtm?
[01:46] <ToyKeeper> ... what?
[01:46] <ToyKeeper> Please tell me we didn't pull stuff from 15.04 into rtm...
[01:47] <ribru> ToyKeeper: well the traceback that justinmcp_ got and Saviq also got just now are that they're trying to do syncs from vivid into rtm, the sync code makes the version number be 14.10.whatever, but rtm already contains version numbers 15.04.whatever and so you can't upload an older version over top of a newer version. I have no idea what's going on
[01:48] <ToyKeeper> That's a snowball which is very difficult to stop.
[01:49] <Saviq> ribru, no, that's not true
[01:49] <Saviq> ribru, *syncs* don't rewrite the 15.04 part
[01:49] <Saviq> ribru, standard landings do
[01:50] <Saviq> ribru, so I got 15.04 from a sync last week, and that's higher than what I now get with a MP-based landing
[01:50]  * ToyKeeper backs away slowly and goes off to do some sanity testing
[01:51] <Saviq> ribru, but indeed, this will now happen to everyone that needs to move from syncs to rtm-targetted landings + series branch
[01:51] <ribru> oh right, you guys have MPs
[01:51] <ribru> Saviq: justinmcp_ well you better target your MPs into vivid then I guess.
[01:51] <Saviq> ribru, they just landed in vivid
[01:51] <Saviq> ribru, now I need to cherry-pick into rtm
[01:52] <ribru> ugh
[01:52] <Saviq> ribru, because I can't afford to not land stuff that's not rtm-approved
[01:52] <Saviq> ribru, and there will be more of that as we go on
[01:52] <ribru> Saviq: I'm frustrated, I don't understand how citrain code was allowed to get as bad as it is.
[01:52] <Saviq> ribru, so this needs resolving asap, otherwise everyone will have to go .1 on their upstream versions
[01:53] <Saviq> ribru, I imagine because it was only meant to live for a few months
[01:53] <ribru> Saviq: I EOD in 10 minutes and I'm already putting out other fires ;-) I'll fix it tomorrow if sil doesn't beat me to it
[01:53] <Saviq> ribru, yeah, I'll try and talk to sil in between talks
[01:53] <Saviq> am out for a conference tomorrow
[01:53] <Saviq> and on that note, 4h of sleep ahead of me...
[01:57] <justinmcp_> how do I re-try the build?
[01:59] <ribru> justinmcp_: well you can run the build job again, you might need to check 'FORCE_REBUILD' option or maybe 'IGNORE_STEP', just follow the errors you get.
[01:59] <ribru> justinmcp_: did you change your MP in some way? shit's pretty broken right now, you might have to wait until tomorrow.
[02:00] <justinmcp_> ribru: I changes the target to vivid, but otherwise untouch
[02:01] <justinmcp_> ribru: I can leave it till tomorrow
[02:01] <ribru> justinmcp_: oh if you're doing vivid we can do it today
[02:01] <ribru> justinmcp_ it's just syncs to rtm that are busted for now
[02:01] <ribru> or mps
[02:01] <ribru> justinmcp_: I have to free the silo to reset it for vivid, hang on
[02:05] <ribru> justinmcp_: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=justinmcp click Build here now ;-)
[02:05] <justinmcp_> i feel empowered
[02:06] <ribru> justinmcp_: that was the idea originally ;-)
[03:19] <veebers> ribru: are you still around per chance?
[03:21] <ribru> veebers: what's up?
[03:21] <veebers> ribru: hey, I have a silly question that I thought you would be able to answer for me :-)
[03:22] <ribru> veebers: shoot
[03:22] <veebers> ribru: I'm wanting to trigger a build for this ppa so we get Utopic + arm versions: https://launchpad.net/~autopilot/+archive/ubuntu/1.5. I will need to bump the version in the changelog and dput the result to do so, I'm finding the version number a little intimidating as I don't want to break things
[03:23] <veebers> the version number in the ppa is: 1.5.0+15.04.20141031-0~504~ubuntu14.04.1 , I should be able to branch, set the version to "1.5.0+15.04.20141105-0~504~ubuntu14.04.1 " and use that, right?
[03:23] <ribru> veebers: that looks like a recipe build, why don't you just run the recipe?
[03:25] <veebers> ribru: hmm, I was under the impression that wouldn't work due to version number conflicts
[03:25] <ribru> veebers: the version number already has 15.04 in it so you're basically already boned
[03:25] <veebers> hmm perhaps I miss-interpreted the comment that lead me to believe that
[03:26] <ribru> veebers: what was the comment?
[03:26] <veebers> ribru: oh, really? :-\
[03:27] <ribru> veebers: https://code.launchpad.net/~autopilot/+recipe/autopilot-1.5 looking at the recipe, it won't touch the date, it'll just use whatever the current revno is.
[03:27] <ribru> veebers: so that shouldn't cause any further problems than what's already there.
[03:28] <veebers> Me: "I could use the recipes 'request build right?' response "veebers: Unless the revno hasn't changed, thus causing a version conflict."
[03:28] <ribru> veebers: the current situation is that citrain is incapable of building an MP in RTM if RTM contains a version string with '15.04' in it, because the mp generated version string is '14.10', which is less, so it rejects the upload. you already have 15.04 so it's already busted.
[03:28] <ribru> veebers: but why do you want a new build if the revno hasn't changed?
[03:29] <veebers> ribru: because I didn't get the changes in this into Utopic, so I want it in the ppa so people can use it if they need to (i.e. CI) but I didn't update the 1.5 ppa until after it had built the new 1.5 branch
[03:31] <ribru> veebers: the ppa only contains trusty, IIRC that conflict that person is talking about is for the same version within the same series.
[03:31] <ribru> veebers: i would personally try the recipe build, if that fails then you can futz the version manually
[03:32] <veebers> ribru: ok, yeah I changed the recipe today to build for utopic (and asked wgrant to add arm building to it) hence me wanting to trigger the build so there was a utioc version in there
[03:32] <ribru> veebers: the recipe appends the series to the version number, so if you upload utopic you'll get blah~ubuntu14.10.1 and it won't conflict.
[03:33] <veebers> ribru: ack, I take it trying the recipe will fail as opposed to breaking things? (/me is being careful with this)
[03:33] <ribru> veebers: right, if there's any problem, the recipe will just fail, it won't make things worse.
[03:33] <ribru> the conflict you heard before and the 15.04 brokenness I'm talking about now are separate issues.
[03:33] <veebers> ribru: ok, I'll give that a try and see what happens, thanks for talking me through that
[03:33] <ribru> veebers: you're welcome
[05:20] <Mirv> mornings
[05:40] <cyphermox> Mirv: morning
[05:40] <cyphermox> this is my queue that I really should log off ;)
[05:40] <cyphermox> *cue
[05:45] <Mirv> cyphermox: correct!
[05:46] <cyphermox> ;)
[05:54] <cyphermox> Mirv: good night!
[05:54] <Mirv> cyphermox: good night!
[07:46] <tvoss> trainguards, can I get a silo for line 79
[07:49] <Mirv> tvoss: there you go, Mr. Bond.
[07:49] <Mirv> (silo 007)
[07:50] <tvoss> hah
[07:50] <tvoss> Mirv, in style ;)
[08:25] <pstolowski> trainguards, hello, a new rtm-14.09 branch for unity-scopes-api has been created to land top blocker at line #60; do i/we need to do anything special for it to build packages against the new branch?
[08:27] <pstolowski> Mirv, morning, did you have a chance to look at this ^ ?
[08:27] <sil2100> pstolowski: hey!
[08:27] <sil2100> pstolowski: just provide MR that target this branch in your landing
[08:28] <sil2100> MRs
[08:29] <pstolowski> sil2100, hi! yep, i did that. cool, thank you
[08:45] <Mirv> pstolowski: yes, I commented on the branch since you weren't online
[08:54] <pstolowski> Mirv, awesome, thanks!
[09:05] <ogra_> damn
[09:06] <ogra_> sil2100, so we have a slight image build prob ...
[09:08]  * ogra_ ponders how to solve it best 
[09:15] <pstolowski> trainguards, could you please reconfigure ubuntu-rtm/landing-002 ?
[09:16] <Mirv> pstolowski: done.
[09:17] <pstolowski> thanks
[09:17] <sil2100> ogra_: what's up?
[09:17] <sil2100> ogra_: everything was fine yesterday, right?
[09:17] <Saviq-codedive> sil2100, you might wanna know we're up for some train woes
[09:18] <sil2100> Saviq-codedive: what's up?
[09:18] <ogra_> sil2100, the dropping of the langpack causes the metapackage to be out of sync
[09:18] <Saviq-codedive> sil2100, everone that synced from vivid to rtm have 15.04 in their versions in rtm
[09:18] <Saviq-codedive> sil2100, but now you try to land through an MP into an rtm series branch
[09:18] <Saviq-codedive> sil2100, you end up with 14.10 in there and you're lower than what's in rtm archive
[09:19] <Saviq-codedive> sil2100, had to .1 unity8 for rtm silo 4
[09:19] <sil2100> Saviq-codedive: hm, indeed this might be trouble ;/ Damn, somehow no one expected this problem to happen
[09:20] <sil2100> Saviq-codedive: ok, so I can theoretically make sure that when we do source syncs, we rewrite the series part of the version number as well
[09:20] <sil2100> But that's not something I can do without consulting slangasek and cjwatson
[09:20] <Saviq-codedive> sil2100, well, and worse, that won't help now
[09:20] <sil2100> I know...
[09:20] <Saviq-codedive> sil2100, only thing that would help now is actually keeping 15.04 there
[09:20] <sil2100> But at least it won't make the situation any worse
[09:21] <Saviq-codedive> sil2100, which is actually something I would recommend
[09:21] <ogra_> the series has no impact ... only if you put it into the version number
[09:22] <sil2100> ogra_: I mean the series in the version
[09:22] <ogra_> right
[09:22] <sil2100> ogra_: since CI Train adds the series version number to the version it creates, so I can make that being rewritten too... but well, not really possible
[09:23] <sil2100> Saviq-codedive: in any way, I indeed will have to tweak the code, as even in the likelyhood of staying with 15.04, CI Train will try to rewrite it to 14.10 on direct releases
[09:23] <Saviq-codedive> sil2100, TBH I'd recommend keeping it as is in the current top version
[09:24] <sil2100> Saviq-codedive: so I need to make sure CI Train can just say 'ok, it's 14.09, but I'll use 15.04 now still because the previous releases had that'
[09:24] <Saviq-codedive> sil2100, yup
[09:24]  * Saviq-codedive goes to focus on the talk
[09:24] <sil2100> Saviq-codedive: thanks on letting me know about this!
[09:24] <sil2100> Saviq-codedive: I was slowly moving away from CI Train maintenance so I didn't even notice this
[09:59] <davmor2> thostr_: http://paste.ubuntu.com/8833284/ I took two photos and a video with the camera app and mediascanner doesn't seem to of picked up on the video though.  so it doesn't show in the video scope
[10:00] <thostr_> davmor2: close the camera app, does it show then?
[10:00] <davmor2> thostr_: I think if I reboot it will appear though judging by what ToyKeeper was saying
[10:00] <bzoltan> cjwatson: fyi -> the 6.7 ssh server has removed the algorithms what the QtCreator is using (https://qt.gitorious.org/qt-creator/qt-creator/source/b72a9dd2391680b7a9ed7c82c1cfefc7cef687e8:src/libs/ssh/sshcapabilities.cpp#L65)
[10:00] <thostr_> davmor2: just close camera app
[10:01] <brendand> thostr_, davmor2 - for me just closing the app worked
[10:01] <davmor2> thostr_: yes after a couple of swipe to refresh now it shows up
[10:01] <brendand> thostr_, and that's not a new bug?
[10:01] <thostr_> no, see my comment on the mailing list
[10:01] <thostr_> it's a camera issue...
[10:01] <thostr_> it's not releasing file handles of recorded videos
[10:01] <brendand> thostr_, yeah i confirmed the same thing
[10:02] <thostr_> which means mediascanner can not pick it up as it can only react to files that are fully written
[10:02] <thostr_> or rather, we get only notified once the file handle is released
[10:03] <bzoltan> Mirv: sil2100: So, right now the Vivid images are not good for app development. RTM is good as long it is on 6.6 ssh server
[10:04] <ogra_> bzoltan, you didnt see cjwatson's answer ? he wrote quite a lot yesterday
[10:04] <bzoltan> ogra_:  I have missed that...
[10:04]  * bzoltan reading logs
[10:05] <ogra_> http://irclogs.ubuntu.com/2014/11/04/%23ubuntu-ci-eng.html#t16:07
[10:07] <bzoltan> ogra_: cjwatson: Ok, thanks for the explanation. That is what I too figured out today morning. I checked the qtcreator's upstream trunk and there is no sign of preparation to safer ciphers. We will talk to the devs and see if they are willing to address the problem.
[10:07] <bzoltan> ogra_: in the meantime enabling legacy ciphers would be an acceptable _temporary_ solution.
[10:08] <ogra_> i would like to hear security team input to that first
[10:12] <bzoltan> ogra_: whatever they say, they should understand that in the present setup there is no app development for devices with Vivid images. Even if the QtCreator upstream devs are willing to take this work on their backlog the fix will not come out quickly.
[10:13] <ogra_> bzoltan, we can likely switch on the extra cyphers again during development if the security team thinks thats ok ... but definitely not for release
[10:13] <ogra_> this has to be fixed within the next months
[10:14] <bzoltan> ogra_: fine with me ... as long the devs can run their apps on the device after they switch the "development mode" on
[10:14] <ogra_> (or earlier depending when/if rtm switches to vivid
[10:14] <ogra_> shipping an insecure ssh on a sold phone is not an option
[10:15] <bzoltan> ogra_: no bad feeling, but it is yet again a significant change in the platform what was rolled out without considering the app development.
[10:15] <ogra_> so upstream has to react somehow ...
[10:15] <ogra_> (i also doubt we are the only distro using a new upstream ssh)
[10:16] <ogra_> bzoltan, this is something we dont have control over ... upstream considers these cyphers to insecure to ship
[10:16] <bzoltan> ogra_: for sure not.. and it is strange that the qtc devs have not yet reacted to it at all... they should know about such upcoming change.
[10:16] <ogra_> (beyond the fact that vivid at this point doesnt get Qa
[10:16] <ogra_> )
[10:17] <dbarth> hi Mirv, we'd need a binary copy of oxide in silo 15 (vivid)
[10:18] <bzoltan> ogra_: yes, I know... nobody to blame. It is how it is :) The vivid is the development series, so this kind of "regressions" are acceptable
[10:18] <dbarth> or a nice trainguard if not available
[10:19] <oSoMoN> dbarth, Mirv: hold on a sec, the silo needs a rebuild first (just removed a MR from it)
[10:20] <sil2100> dbarth: o/
[10:21] <sil2100> dbarth: from which PPA?
[10:21] <oSoMoN> sil2100, we need a reconfigure of silo 15, then a copy of oxide-qt from https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+packages
[10:21] <sil2100> oSoMoN: ACK
[10:21]  * sil2100 reconfigures then
[10:22] <oSoMoN> thanks!
[10:24] <sil2100> oSoMoN: ok, copying the package now
[10:25] <Mirv> okie
[10:25] <sil2100> uh
[10:25] <sil2100> oSoMoN: I see oxide was built for utopic in that PPA...
[10:25] <Mirv> sil2100: it probably needs to be done from command line. I can do that, I've done it before.
[10:26] <sil2100> oSoMoN: this *might* be a problem when doing binary copies, as we can't guarantee binary compatibility
[10:26] <sil2100> Mirv: ^
[10:26] <Mirv> sil2100: utopic shouldn't be a problem, vivid could be?
[10:26] <oSoMoN> sil2100, oh, you’re right! sorry about that, I guess we’ll have to rebuild it for vivid first
[10:26] <Mirv> oSoMoN: no, vivid could be a bigger problem for rtm than utopic
[10:26] <sil2100> Mirv: well, the phablet PPA has utopic binaries of oxide-qt, and they need to copy it to vivid
[10:26] <Mirv> oh, this's a vivid silo, not rtm
[10:26] <sil2100> Yes
[10:27] <oSoMoN> Mirv, we’re not going to sync to rtm anyway, oxide 1.3 has been rejected for rtm
[10:27] <Mirv> oSoMoN: yeah so in that case indeed rebuild for vivid
[10:27] <oSoMoN> Mirv, yup, will do, thanks
[10:27] <Mirv> and then we can copy
[10:27] <sil2100> Mirv: will you handle this till the end then? :)
[10:27] <sil2100> Thanks!
[10:27] <dbarth> sil2100: what oSoMoN said ;)
[10:27] <Mirv> sil2100: sure, no problem, but with Oxide I'll be EOD's when the build finishes in 5h ;)
[10:27] <dbarth> thanks guys
[10:27] <sil2100> Eeej
[10:27] <sil2100> Eeek
[10:27] <sil2100> ;)
[10:27] <oSoMoN> Mirv, sil2100, no worries, there’s no urgency on this one, it can wait till tomorrow
[10:28] <Mirv> my last build was 5h 26min https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-002/+build/6514437
[10:28] <oSoMoN> we’ll get oxide built for vivid first, and ping you tomorrow when done and tested
[10:34] <pstolowski> Mirv, hey, failure in ubuntu-rtm/landing-002 with missing gcc-4.9 and then with version number (which i'm not sure where it comes from). anything todo for me?
[10:36] <sil2100> uh
[10:37] <sil2100> Mirv, pstolowski: seems like the issue mentioned by Saviq-codedive...
[10:37]  * sil2100 sighs
[10:37] <sil2100> What to do what to do...
[10:38] <pstolowski> sil2100, ah..
[10:39] <sil2100> pstolowski: can you wait a little bit? Since fixing this might be easy, but current CI Train trunk is b0rken so I need to first work-around the changes ribru made
[10:40] <sil2100> cjwatson: hello! Are you around for a quick advice? :)
[10:40] <pstolowski> sil2100, sure
[10:41] <sil2100> cjwatson: I was thinking: would it be sane to just use 15.04 in rtm version-numbers instead of 14.10 by default? i.e. the 1.1+15.04.20141105~rtm instead of 1.1+14.10 as we have now?
[10:42] <sil2100> Since it should probably point to the current developmnent series anyway
[10:59] <psivaa_> sil2100: the unity8 run came back ok on the rerun
[10:59] <sil2100> psivaa_: how many failures? 2-3?
[10:59] <psivaa_> ok meaning at least it completed
[11:06] <ogra_> sigh
[11:07] <sil2100> ogra_: any luck?
[11:07] <ogra_> sil2100, no, and i see no way to fix this ... pitti doesnt seem around either, nor does cjwatson ...
[11:07] <sil2100> Yeah, I would need cjwatson's or slangasek's opinion as well to fix the train
[11:08] <ogra_> as a last resort i tried to hack the metapackage in rtm ... to read from the rtm archive ... that works up to the point where germinate needs debootstrap ... no 14.09 distro there
[11:08] <ogra_> the prob here is that germinate needs to recognize the langpack gone ...
[11:09] <ogra_> by default it reads from the utopic archive ... where the landgapck simply isnt gone
[11:09] <ogra_> *langpack
[11:09] <ogra_> (and where we cant remove it now that utopic is released)
[11:09] <sil2100> Can't we retarget it somehow?
[11:09] <ogra_> yes, thats what i tried ... but there is debootstrap involved ...
[11:10] <ogra_> and debootstrap neither knows what rtm is nor that there is a 14.09 release
[11:10] <ogra_> the rtm archive only knoows 14.09 and devel as distros
[11:11] <ogra_> (and no, debootstrap doesnt know devel)
[11:12] <sil2100> Damn
[11:13] <ogra_> i'll sync the latest changes into vivid now at least ...
[11:13] <ogra_> we coould theoretically binary snyc from vivid once this is done ... but that completely messes up the changelog
[11:13] <sil2100> I'm starting to think that maybe removing those langpacks wasn't such a good idea, maybe it could have been worked-around some other way
[11:13] <sil2100> Like blacklisting those langauges somehow in the UI
[11:14] <ogra_> well, the seed has "langpack-ubuntu-touch-*" ... it reads the actual list from the available packages in the archive
[11:14] <ogra_> read: this isnt even a seed change at all ... just a germinate run
[11:15] <ogra_> blacklisting but shipping would be quite some hack
[11:16] <ogra_> i think the only sane way is to pull the vivid meta in ... but at the cost of losing the histroy :(
[11:16] <sil2100> Let's hack germinate!
[11:16] <sil2100> \o/
[11:16] <ogra_> heh
[11:17] <sil2100> Anyway, I would still wait for at least pitti to appear
[11:18] <ogra_> right
[11:21] <cjwatson> sil2100: sorry, variously on vacation / conference leave this week so not really enough brainspace to advise, hopefully somebody else is around
[11:22] <cjwatson> ogra_: I'd just hack the metapackage manually (carefully!) and not worry too horribly much about germinate-update-metapackage being unhappy
[11:22] <cjwatson> it's not actually a hard requirement
[11:22] <ogra_> cjwatson, you mean hack the deps directly ?
[11:23] <ogra_> ok, that shouldnt be to hard
[11:23] <cjwatson> sure
[11:23] <ogra_> thanks
[11:23] <cjwatson> well, the files used to generate them
[11:23] <ogra_> thats the one option i didnt consider :)
[11:32]  * ogra_ uploads and crosses fingers
[11:54] <brendand> Mirv, do you happen to know where the latest clicks for e.g. calculator might be?
[12:03] <ogra_> sil2100, ok, starting a test build for both distros ... cross your fingers :)
[12:03] <sil2100> ogra_: \o/
[12:04] <ogra_> (the bot wont announce them, it still waits for the finishing of vivid9 and rtm143)
[12:13] <sil2100> I go to lunch, back in some time
[12:15] <sil2100> pstolowski: after lunch someone from should be already available to review my proposal and I might be able to unblock your landing
[12:19] <ogra_> phew, looks like the build got past the failure ... great
[12:20] <pstolowski> sil2100, k, thanks for heads up
[12:23] <Mirv> brendand: http://s-jenkins.ubuntu-ci:8080/job/calculator-app-click/
[12:28] <Mirv> brendand: they all tend to be of the same form (url)
[12:38] <ogra_> mdeslaur, could you take a look at the ssh discussion between colin and zoltan on http://irclogs.ubuntu.com/2014/11/04/%23ubuntu-ci-eng.html ? seems upstream dropped some cyphers, the SDK uses its own ssl lib that can only be used with these cyphers ...
[12:39] <ogra_> mdeslaur, there is a request from the SDK team to re-enable them in vivid
[12:39] <ogra_> while i think we could indeed technically re-enable them i would like to hear some security team opinion
[12:41]  * mdeslaur reads
[12:42] <ogra_> (there is subsequent discussion between zoltan and me in todays backlog too btw)
[12:44] <mdeslaur> ogra_: what component is responsible for that?
[12:45] <ogra_> openssh-server
[12:45] <ogra_> on the phone side ...
[12:45] <mdeslaur> ah, I see the qtcreator commit now
[12:45] <ogra_> not sure what component of QtCreator
[12:50] <mdeslaur> I'm not thrilled about adding the ciphers back, they were removed for a reason. The real solution is to fix qtcreator by adding in some of the better ciphers. That being said, you could _temporarily_ add them back to the phone image until qtcreator gets updated
[12:50] <mdeslaur> but as a temporary measure only
[12:50] <ogra_> right
[12:50] <ogra_> and who keeps track of this
[12:50] <pmcgowan> ogra_, was a 143 built? trying to debug my updates
[12:51] <ogra_> and who makes sure that doesnt slip into a potential vivid-rtm if we merge before feature freeze etc
[12:51] <ogra_> pmcgowan, no, we have image build issues
[12:51] <pmcgowan> ok
[12:51] <ogra_> working on them ... with luck there should be an image in a few
[12:51] <ogra_> ... and so we will ... phew
[12:52] <ogra_> rootfses build again ... waiting for system-image importer now
[12:52] <ogra_> ~20-30min
[12:52] <ogra_> mdeslaur, i'm not so musch worried about adding them back temporary than i am about forgetting that we did that in a few months
[12:52] <ogra_> *much
[12:53] <mdeslaur> ogra_: right, someone needs to own the bug to fix qtcreator and to remove the workaround
[12:53] <mdeslaur> honestly, it's probably as easy to fix qtcreator
[12:53] <ogra_> bzoltan, ^^^^see backlog
[12:54] <ogra_> yeah, one would hope so ... especially since it will surely be hit by that in other distros too
[12:59] <pmcgowan> mdeslaur, whats the fix - to use a different lib?
[12:59] <mdeslaur> just add a couple of extra algorithms, no?
[13:00] <mdeslaur> or are those the _only_ ones that are available?
[13:00]  * mdeslaur looks at source
[13:09] <mdeslaur> ah, yeah, it's going to require some modifications, hrm
[13:10] <mdeslaur> I guess adding the ciphers back to the phone images until upstream replaces the ciphers in qtcreator is the workaround for now
[13:11] <ogra_> hmm, k
[13:16] <ralsina> traingards, a silo for row #71 pretty please? :-)
[13:16] <tvoss> davmor2, brendand can I get your help to test vivid silo 7?
[13:16] <ralsina> trainguards ^
[13:17] <brendand> tvoss, today is your lucky day
[13:18] <tvoss> brendand, cool
[13:25] <tvoss> brendand, please test media playback, too
[13:44] <imgbot> [13:44] <imgbot> [13:44] <imgbot> [13:44] <imgbot> [13:44] <ogra_> \o/
[13:44] <ogra_> allthefixes !
[13:45] <popey> ☹ my phone hung when drawing welcome screen on unlock
[13:45] <ogra_> popey, i have seen that on the weekend
[13:45] <ogra_> but no crashes or anything :(
[13:46] <popey> yeah
[13:46] <popey> and takes ages to phablet-shell
[13:46] <popey> i think it's not coming out of sleep properly
[13:46] <ogra_> well, powerd seems to still work in that state
[13:46] <popey> hmm
[13:46] <ogra_> (i can toggle screen on/off with the powerbutton)
[13:46] <popey> same
[13:47]  * popey looks for a a bug
[13:47] <popey> can't find one...
[13:49]  * popey files one
[13:55] <brendand> tvoss, ok testing silo 7 now
[13:55] <tvoss> brendand, ack
[14:03] <olli> ogra_, is there a list of bugs that were fixed in images since #140?
[14:04] <ogra_> olli, only if yu look through the individual changelogs ... i think sil has a tool for that
[14:05] <davmor2> Mirv: I just saw your silo man you need help :P  Silos are not distributions you know :D
[14:05] <olli> heh
[14:06] <ogra_> olli, you find the chnagelogs at https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-November/thread.html and the list of changed packages at http://people.canonical.com/~ogra/touch-image-stats/rtm/143.changes
[14:06] <fginther> balloons, if you have a moment, can you give this MP to move the core-apps to vivid a review? https://code.launchpad.net/~fginther/cupstream2distro-config/vivid-core-apps/+merge/240634
[14:06] <olli> ogra_, I'll wait to talk about sil200's tool
[14:07] <balloons> fginther, sure
[14:07] <ogra_> olli, usually lands here ... http://people.canonical.com/~lzemczak/landing-team/ubuntu-rtm/ but it takes my change list as input asnd i dont know exactly when it runs, might be manual
[14:08] <olli> ogra_, I can wait until he is back
[14:09] <ogra_> well, if it is cron driven it will just show up, but yeah
[14:10] <ogra_> hmm, still no push notification on my krillin
[14:11] <ogra_> Chipaca, i thought the cron job for that runs every 5 min now ?
[14:11] <bfiller> Mirv: can you do a reconfigure on rtm silo 17? just added a package
[14:11] <Chipaca> ogra_: are you looking at the logs?
[14:11] <Chipaca> ogra_: you only get the visible notification when it's finished downloading
[14:12] <ogra_> Chipaca, no, at the images :) i cant look at your server :P
[14:12] <ogra_> oh
[14:12] <ogra_> hmm
[14:12] <Chipaca> ogra_: the push client logs when it gets the broadcast; then it calls system image asking to download the image
[14:12] <Chipaca> unless you've turned off automatic downloads, in which case you get it immediately
[14:12] <ogra_> i have them on indeed
[14:13] <Mirv> davmor2: that's the smallest it can be, we could include various other things like updating qtpim snapshots and their reverse dependencies too :) but yeah, you're right that I need help!
[14:13] <Mirv> bfiller: ok.
[14:13] <Chipaca> ogra_: and if any of system settings is in the foreground you never see the notification
[14:13] <ogra_> ok
[14:13] <Chipaca> ogra_: answering your original question, yes, the cron runs every five minutes
[14:14] <ogra_> right, i was just wondering since it is more than 30 that the image showed up
[14:14] <Chipaca> ogra_: you can look at ~/.cache/upstart/ubuntu-push-client.log (and in fact, please do)
[14:14] <Chipaca> ogra_: ok, so please let me see your logs then
[14:14] <Mirv> bfiller: ^ done
[14:14] <bfiller> Mirv: thank you
[14:15] <Chipaca> ogra_: there are some weird things happening wrt this, which if have just happened to you i'd appreciate the logs and such
[14:15] <seb128> hum, I just got a duplicate update notification
[14:15] <seb128> is that a known issue?
[14:15] <Chipaca> "some weird things" -> broadcast arriving but the push helper dying in less-than-useful ways
[14:15] <seb128> I'm on r141 and there is r143 available
[14:15] <Chipaca> seb128: no you didn't! :-p
[14:15] <ogra_> seb128, you probably got mine then :P
[14:15] <Chipaca> seb128: explain "duplicate"
[14:15] <ogra_> Chipaca, http://paste.ubuntu.com/8836200/
[14:16] <seb128> Chipaca, the messaging indicate lists 2 "update available" entries
[14:16] <seb128> indicate->indicator
[14:16] <Chipaca> seb128: that shouldn't happen
[14:16] <seb128> just did
[14:16] <Chipaca> seb128: get me your logs
[14:16] <Chipaca> stat :)
[14:16] <seb128> which ones?
[14:17] <ogra_> Chipaca, this log is gigantic, can you make sure to drop the debug spam before final release goes out ? ß
[14:17] <Chipaca> ogra_: could you check whether you have a python process alive?
[14:17] <Chipaca> ogra_: https://code.launchpad.net/~chipaca/ubuntu-push/logging-is-for-the-birds-tweet-tweet/+merge/240713
[14:17] <ogra_> phablet@ubuntu-phablet:~$ ps ax|grep python
[14:17] <ogra_> 18506 ?        Sl     0:01 /usr/bin/python3 /usr/sbin/system-image-dbus
[14:17] <ogra_> seems fine
[14:17] <seb128> Chipaca, http://paste.ubuntu.com/8836225/ if that's the log you want
[14:18] <Chipaca> ogra_: and check the tail of the push client log again in case it's just died (system-image-dbus should go away shortly after everything stops talking to it afaik)
[14:19] <ogra_> only one line added since the paste
[14:19] <ogra_> 2014/11/05 15:15:22.916197 DEBUG ping.
[14:19] <Chipaca> seb128: yes, it was
[14:20] <Chipaca> seb128: so, it's explicitly clearing the indicator before posting the new one
[14:20] <balloons> fginther, you build now for python3 only, amd64 only?
[14:20] <seb128> Chipaca, that somewhat failed I guess :/
[14:21] <seb128> hum, the indicator log has
[14:21] <seb128> g_menu_remove: assertion '0 <= position && position < menu->items->len' failed
[14:21] <seb128> dunno if that has to do with it
[14:22] <tvoss> brendand, any first impression?
[14:22] <Chipaca> seb128: i'll ask larsu
[14:23] <popey> ogra_: bug 1389718
[14:23] <brendand> popey, sure you didn't just hit one of the cpu hogs?
[14:24] <brendand> tvoss, patience :)
[14:24] <ogra_> popey, confirmed ... pmcgowan olli ^^^^
[14:24] <popey> brendand: no
[14:24] <ogra_> brendand, yes, that is different than just being sluggish
[14:24] <popey> top - 14:24:54 up 17:00,  2 users,  load average: 0.00, 0.01, 0.05
[14:25] <popey> its completely idle
[14:25] <ogra_> the UI hangs hard on the greeter
[14:25] <ogra_> sometimes the panel is even empty
[14:25] <brendand> ogra_, sometime that happens and location stuff is going haywire
[14:25] <ogra_> i have seen this every two days since the weekend
[14:25] <brendand> popey, right so top is idle
[14:25] <ogra_> but that is no data or info anywhere to be found
[14:26] <ogra_> *there
[14:26] <Chipaca> ogra_: do you still have that device up?
[14:27] <ogra_> sure
[14:27] <ogra_> Chipaca, system-image-dbus is still sitting there
[14:28] <ogra_> nothing changed
[14:29] <fginther> balloons, yes. at one time there was a specific job for running tests with python2, plus the one for python3 because detecting just proved to be unreliable. Now that everything is python3, there is only need for a single generic job
[14:29] <balloons> fginther, right.. I left a comment, a little nitpick and a note about some future work we need to do.
[14:30] <Chipaca> ogra_: please pastebin the output of
[14:30] <Chipaca> ogra_: gdbus call --session --dest com.ubuntu.Postal --object-path /com/ubuntu/Postal/_ --method com.ubuntu.Postal.PopAll _ubuntu-system-settings
[14:31] <brendand> tvoss, you might have broken video rotation
[14:31] <fginther> balloons, thanks! I'll get a comment added
[14:31] <tvoss> brendand, that's a bit weird. How do you test?
[14:32] <rsalveti> ogra_: great, seems we can now build images again
[14:32] <ogra_> rsalveti, yeah, that was a hard bone to chew though
[14:33] <ogra_> Chipaca, http://paste.ubuntu.com/8836388/
[14:33] <rsalveti> ogra_: thanks for working on that
[14:33] <ogra_> np
[14:33] <ogra_> rsalveti, in general out rtm seed changes will now be rather hackish ...
[14:34] <rsalveti> ogra_: yeah =\
[14:34] <ogra_> needing to hack meta directly
[14:35] <rsalveti> urgh
[14:35] <ogra_> yeah
[14:36] <Chipaca> ogra_: INteresting. thanks.
[14:36] <brendand> tvoss, take a video in portrait mode and view it in the photo roll
[14:37] <brendand> tvoss, it will be sideways
[14:37] <brendand> tvoss, it will be played in the correct orientation though
[14:37] <ogra_> jhodapp, is that the thumbnail rotation fix you are working on ^^^ ?
[14:38] <jhodapp> ogra_, the video yes, but the preview in the photo roll is not me
[14:38] <jhodapp> ogra_, that's Satoris
[14:38] <tvoss> jhodapp, but it's a known issue?
[14:38] <jhodapp> tvoss, yes
[14:39] <tvoss> brendand, ^
[14:39] <brendand> jhodapp, sorry i thought that was fixed in RTM
[14:40] <jhodapp> brendand, if it was I've never seen it :)
[14:40] <jhodapp> brendand, we need to ping Satoris to see if he ever got that landed
[14:40] <jhodapp> brendand, he was working on it in DC
[14:41] <tvoss> brendand, just tried without my silo, same issue
[14:41] <brendand> tvoss, ok
[14:41] <tvoss> brendand, did you see any unity 8 crash?
[14:42] <brendand> tvoss, not so far. but haven't been using it that long
[14:42] <tvoss> brendand, ack
[14:42] <tvoss> brendand, it will go through full qa for that anyway
[14:42] <tvoss> brendand, do you test vivid or rtm?
[14:42] <brendand> tvoss, vivid, as you asked
[14:42] <tvoss> brendand, ack and thx
[14:43] <ogra_> Chipaca, do you need anything more ? else i'll force the update
[14:45] <Chipaca> ogra_: dmesg?
[14:45] <Chipaca> ogra_: just in case :)
[14:51] <ogra_> Chipaca, http://paste.ubuntu.com/8836542/ ... beware, it is hugfe
[14:51] <ogra_> *huge even
[14:51] <sil2100> Ursinha: right, missed the test, fixed it now - before I can land this I need to talk with slangasek or someone from the archive admins first though
[14:51] <sil2100> :)
[14:52] <Chipaca> ogra_: for next time, remind me to ask you for dmesg -T :)
[14:52] <ogra_> Chipaca, one sec
[14:52] <Chipaca> ogra_: nah, it's fine
[14:52] <Chipaca> ogra_: nothing there of interest to me :-(
[14:53] <ogra_> yeah, it looked like ... apart from the sleep and wakeup messages perhaps
[14:53] <Chipaca> was hoping for a juice OOM or something :)
[14:53] <ogra_> heh
[14:53] <Chipaca> anyway, school run
[14:55] <Ursinha> sil2100: okay :)
[14:55] <sil2100> slangasek: ping
[14:56] <thostr_> jhodapp: brendand: the rotation fix is in vivid... back then it wasn't seen as critical enough
[14:56] <fginther> balloons, I added a bug report
[14:57] <jhodapp> thostr_, it's not in vivid yet, just confirmed that with Satoris
[14:57] <jhodapp> thostr_, he's going to get it landed in vivid shortly
[14:57] <satoris> This is the MR: https://code.launchpad.net/~jpakkane/thumbnailer/videoflip/+merge/238907
[14:57] <thostr_> jhodapp: ok. brendand: how critical do you see this for rtm? adding to wishlist?
[14:58] <jhodapp> thostr_, I personally think it's pretty critical since it's a very easy bug to spot for anybody
[14:58] <satoris> I'd want to talk to jamesh first. Thumbnailer does not have an rtm branch yet because we have kept them identical for the time being.
[14:59] <thostr_> satoris: but if it's identical then landing to rtm should be even easier, no?
[15:00] <sil2100> thostr_, brendand: what bug are you  talking about now?
[15:00] <ogra_> sil2100, thumbnail rotation
[15:00] <ogra_> it is on the list somewhere
[15:01] <satoris> thostr_: there's stuff to land in trunk that will never make it into rtm. One of the reasons being that they are not for super duper critical top blockers.
[15:02] <satoris> Eventually we need different branches.
[15:02] <satoris> If we just want to land this one thing to rtm and trunk, then there's no problem.
[15:03] <satoris> Though didn't it already land in rtm, I remember someone from qa testing it and verifying that it works?
[15:03] <brendand> satoris, yes it did - http://people.canonical.com/~davmor2/pr.png
[15:04] <brendand> satoris, maybe it never landed in vivid though?
[15:04] <satoris> brendand: it's spreadsheet line 22.
[15:04] <satoris> "Ready to build".
[15:05] <brendand> satoris, ok - that's your concern now :)
[15:07] <satoris> brendand: I distinctly remember talking to mirv about this ages ago (last week?). There was some confusion at the time. Why has it not built the packages by now and what do we need to do to make it happen?
[15:07] <brendand> satoris, the landing team can help you with that
[15:07] <brendand> sil2100, ^
[15:08] <satoris> Ok, thanks.
[15:10] <sil2100> satoris: let me take a look at that silo
[15:12] <sil2100> satoris: ok, just so you know - with this, trunk will start pointing to vivid releases from now on
[15:13] <satoris> sil2100: ack, should we set up a branch for rtm and if yes are there instructions on how to do that correctly?
[15:15] <sil2100> satoris: this depends on how you want to develop - if you're certain that anything that you work on eventually should go to ubuntu-rtm, then you can stay with one trunk and just sync to ubuntu-rtm
[15:15] <sil2100> satoris: but if you think you want to develop features/changes that are not meant for ubuntu-rtm, then just do a copy of the current trunk to some different name and use that one for ubuntu-rtm landings
[15:15] <sil2100> Where you would only cherry-pick changes that are rtm-enabled
[15:16] <satoris> Ok, thanks for the info.
[15:32] <brendand> tvoss, so i don't get any volume overlay at all here
[15:32] <brendand> tvoss, unless somehow that feature isn't in vivid...
[15:44] <sil2100> pstolowski: can you try working on your silo now? e.g. rebuilding it?
[15:45] <pstolowski> sil2100, ok
[15:51] <pstolowski> sil2100, i'll soon need to do the same excercise with new rtm branch for another project (unity-scopes-shell)
[15:52] <sil2100> pstolowski: if all works correctly for -api, then it should work for all branches now
[15:52] <sil2100> I bumped the ubuntu-rtm version number to the current development focus
[15:53] <sil2100> (it's a hotfix, but we need to figure out how to proceed with this for the future)
[15:54] <cjwatson> ogra_,mdeslaur: I'd like to review whatever you/whoever do to fiddle with cipher configs, btw; not around that much this week but I'll see highlights eventually
[15:57] <sil2100> tvoss: hey! How's the CPU eater bug? What's the overall status on all fronts?
[15:58] <ogra_> cjwatson, will show you once i have somethin
[15:58] <bzoltan> cjwatson: ogra_: mdeslaur: would it be possible to enable those "unsafe" ciphers only when the dev mode is switched on? The  fix for QtCreator to support the more safe ciphers are not going to come quick.. more like months than weeks.
[15:59] <ogra_> bzoltan, i would just add them to the hardcoded cmdline we already have in the ssh.override upstart job
[15:59] <cjwatson> yes, that sounds like a good idea to make it easier to control
[16:00] <ogra_> fancy dev mode integration is just extra work for something we want to drop asap
[16:01] <ogra_> cjwatson, yeah, i imagine the implementation is trivial, my biggest fear is that we forget about it (which is why i'm so reluctant to add it)
[16:03] <cjwatson> bzoltan: I'm surprised it's that hard though; a minimal fix for 6.7 interoperability doesn't require a fundamental new cipher implementation, just running it in a different mode (CTR rather than CBC)
[16:04] <cjwatson> bzoltan: And QtC uses libbotan, as far as I can see, which already supports CTR mode
[16:07] <cjwatson> SshEncryptionFacility::makeCipherMode and SshDecryptionFacility::makeCipherMode would need to be made smarter of course
[16:07] <cjwatson> I appreciate that it requires getting somebody with relevant competence to care, but it looks like it needs plumbing rather than actual difficult new crypto code
[16:08] <cjwatson> Bumping to aes256-ctr rather than just aes128-ctr while there would be a good idea too, but that actually does look trivial once the cipher mode stuff is done
[16:08] <slangasek> sil2100: contentless pong? :)
[16:10] <sil2100> slangasek: hey! I made a hotfix for CI Train which I'm not sure if is good or not - people had trouble with releasing stuff to rtm from their RTM trunks when they made any syncs from vivid before
[16:10] <bzoltan> cjwatson:  you are right. But note that it is about changing the QtC upstream code, what has never been quick. Even if it is a single line change. Also , the fix would land on teh upstream's trunk and migrating to a new QtC would take some time too. It is more time consuming job than difficult.
[16:10] <sil2100> slangasek: as per topic, every sync from vivid carried a 15.04 number in the version number, while native builds for ubuntu-rtm used 14.10 in the versions
[16:11] <sil2100> slangasek: so what I did I made it to now use 15.04 as well
[16:11] <sil2100> slangasek: + the additional append of ~rtm of course
[16:14] <cjwatson> bzoltan: Well, that's certainly the type of change we ought to cherry-pick
[16:17] <bzoltan> cjwatson: at least we managed to draw the upstream's attention to it https://bugreports.qt-project.org/browse/QTCREATORBUG-13340 I will for sure backport the fix in a form of distro patch to LTS and U/V when it comes out.
[16:17] <cjwatson> Great
[16:21] <slangasek> sil2100: I don't understand the concern here - this is just about whether it's ok to use 15.04 as the version number for packages in rtm/14.09?
[16:21] <sil2100> Yes
[16:22] <ogra_> well, there isnt really an alternative :)
[16:23] <sil2100> So I made it that ubuntu-rtm-built silos will generate version numbers in the format of 1.1+15.04.20141105~rtm now instead of 1.1+14.10.20141105~rtm - just asking in case you have any better ways of solving this
[16:23] <sil2100> To enable both syncs and 'native' builds
[16:53] <sil2100> tvoss: ping
[16:53] <sil2100> ricmm: ping
[16:54] <ricmm> sil2100: sup
[16:54] <pstolowski> sil2100, #60 has been built ok
[16:57] <ricmm> sil2100: whats up?
[16:57] <sil2100> pstolowski: \o
[16:57] <sil2100> ricmm: hey! How's the media-hub fix for the CPU issue, is that landed already?
[17:03] <ricmm> sil2100: its moving through the bowels of the landing process
[17:04] <sil2100> davmor2: meeting!
[17:24] <john-mcaleely> ogra_, sil2100 new device tarball, incoming
[17:24] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141105-4a6bca7.tar.xz
[17:24] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141105-4a6bca7.changes
[17:24] <ogra_> whee !!
[17:24] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20141105-4a6bca7.ods
[17:25] <john-mcaleely> this will be the last 'universal' tarball. next time I'll be doing separate ones for rtm & V
[17:25] <john-mcaleely> any chance of davmor2 or brendand taking a look at this when they have time in their queue
[17:25] <john-mcaleely> fixes are from the list, but not TOPBLOCKER
[17:25] <john-mcaleely> (to make priority calls)
[17:26] <john-mcaleely> sil2100, ^ :-)
[17:28] <brendand> davmor2, add that to the trello board
[17:29] <brendand> john-mcaleely, davmor2 should be able to look at it today/tomorrow
[17:30] <john-mcaleely> brendand, sounds perfect, thanks!
[17:32] <sil2100> \o/
[17:32] <sil2100> john-mcaleely: but all from the wishlist, right?
[17:34] <john-mcaleely> sil2100, yes
[17:46] <davmor2> john-mcaleely, sil2100: what all there is only one change :)
[17:47] <tedg> trainguards, can I get a silo for line 85 please?
[17:47] <ogra_> davmor2, but it will make your logs 50MB smaller :)
[17:48] <ribru> tedg: vivid 24
[17:51] <davmor2> ogra_: turn logs off they will be at 0MB then ;)
[17:52] <ogra_> haha
[17:55] <tedg> ribru, thanks!
[17:56] <ribru> tedg: you're welcome!
[17:56] <ribru> infinity: https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141105-0ubuntu1.diff here's the response to your NACK, can you confirm it's now up to your standards? thx
[18:14] <john-mcaleely> davmor2, but it's a change on 'the list' :-)
[18:16] <davmor2> john-mcaleely: indeed I didn't say it wasn't, it was just the way sil2100 said ALL
[18:16] <john-mcaleely> davmor2, :-)
[18:16] <john-mcaleely> set logic still works for 1 item in the set :-P
[18:39] <tvoss> davmor2, you still around?
[18:41] <tvoss> sil2100, pong
[18:42] <ogra_> dont disturb davmor2 he is testing a heavy patchset in the device tarball :P
[18:42] <tvoss> sil2100, or better: ping
[18:49] <sil2100> tvoss: ping pong
[18:49] <sil2100> ogra_: ;p
[18:49] <ogra_> :)
[18:50] <john-mcaleely> lol
[18:56] <davmor2> ogra_: no I'm not I was at tea and then I have the sanity testing on mako to finish first :P
[19:02] <ribru> tvoss: https://ci-train.ubuntu.com/job/ubuntu-landing-007-2-publish/28/console needs top approvals
[19:04] <tvoss> ribru, ack, gimme two
[19:07] <tvoss> ribru, top-approved
[19:07] <ribru> tvoss: thanks
[19:07] <davmor2> tvoss: I'm back around now
[19:07] <tvoss> davmor2, ack
[19:13] <davmor2> john-mcaleely: can you check the permissions on the tar ball please
[19:14] <john-mcaleely> davmor2, argh
[19:14] <john-mcaleely> davmor2, I can. I have. they are now fixed. sorry!
[19:15] <davmor2> john-mcaleely: makes it easier to test when you can download it :)
[19:16] <john-mcaleely> davmor2, over-rated!
[19:18]  * davmor2 Fails the tarball on grounds of untestability 
[19:18] <sil2100> davmor2: ;)
[19:19] <davmor2> john-mcaleely, sil2100, ogra_: right flashing now
[19:20] <davmor2> john-mcaleely: about an hour I'll give you a ping
[19:20] <john-mcaleely> davmor2, I'll be around
[19:20] <john-mcaleely> davmor2, thanks!
[19:31] <ribru> ungh
[19:40]  * sil2100 jumps out for a while, bbl
[19:49] <balloons> ping fginther
[19:49] <fginther> balloons, hey
[19:49] <balloons> fginther, :-) howdy. So I have a quick question/ request. Can we make sure all the click jobs for core apps on s-jenkins build automagically after a merge to trunk? It seems calender for instance does not:
[19:49] <balloons> http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/
[19:51] <fginther> balloons, yeah that just sounds like a bug in the job, I can try to fix that
[19:53] <davmor2> john-mcaleely: so the sanity test passed, next to look at the logs and see what that is like :)
[19:53] <john-mcaleely> \o/
[19:53] <ogra_> still noisy i guess
[19:54] <ogra_> but a lot less than before :)
[19:54] <ogra_> (not one line per second at least)
[19:54] <brendand> tvoss, around?
[19:54] <john-mcaleely> when the machine was 'doing nothing', the logs did seem to stop when I looked
[19:54] <tvoss> bregma, yup
[19:55] <john-mcaleely> which seemed like a plus
[19:55] <tvoss> brendand, for the volume overlay: that's not in vivid
[19:55] <ogra_> john-mcaleely, yeah, but fallung asleep and waking up still produce like 30lines or so per event
[19:55] <john-mcaleely> it's an important event!
[19:55] <ogra_> lol
[19:55] <john-mcaleely> :-)
[19:59] <brendand> tvoss, yeah realised that in the end
[19:59] <brendand> tvoss, after reflashing
[19:59] <brendand> tvoss, seems like a few things have not landed there
[20:03] <tvoss> brendand, yup
[20:03] <tvoss> brendand, so with that, I set the vivid silo to testing done
[20:05] <davmor2> john-mcaleely: phablet@ubuntu-phablet:~$ ls -l /var/log/syslog   -rw-r----- 1 syslog adm 550734 Nov  5 20:02 /var/log/syslog    That doesn't in comparison to the -rw-r----- 1 syslog adm 2438369 Nov  5 20:04 /var/log/syslog on mako that has been up for 2 hours
[20:05] <davmor2> john-mcaleely: I'd say let it loose
[20:05] <brendand> tvoss, and the crashing is apparently gone - bonus!
[20:05] <ogra_> yay
[20:05] <tvoss> brendand, yup
[20:08] <davmor2> ogra_: should be roughly a 40-45% reduction that's not bad
[20:08] <ogra_> i want 90-95% :P
[20:08] <ogra_> but yeah, its a good start :)
[20:09] <davmor2> ogra_: turn all logs off you get 100% :P
[20:12] <davmor2> ogra_: man you had to talk to john-mcaleely about falling asleep and now we get no response from him,  I blame you entirely ;)
[20:12] <ogra_> hahaha
[20:13] <davmor2> ogra_: you and your hypnotic text
[20:13] <ogra_> *grin*
[20:14] <davmor2> ogra_: no that would be a proper Muhahahahaha and rubbing of hands :)
[20:14] <davmor2> evil plotting ahead :)
[20:28] <ribru> Saviq: vivid 16
[20:28] <ribru> kgunn: ^
[20:29] <kgunn> sah-weet
[20:46] <bfiller> ribru: can you publish rtm silo 6 please?
[20:48] <sergiusens> plars: hey, do the jobs/workers auto update from ppa:phablet-team/tools ?
[20:49] <plars> sergiusens: no
[20:49] <sergiusens> plars: you copy to another ppa?
[20:49] <sergiusens> plars: or just do it manually?
[20:49] <plars> sergiusens: not at the moment, but I would assume that we'll need to once it goes over to an is-control production server
[20:50] <plars> sergiusens: at the moment, we have some control over the box, so we just update packages as needed
[20:50] <sergiusens> plars: when the adb stuff lands, you'll need what landed in vivid today
[20:50] <plars> sergiusens: ok, what's changing?
[20:50] <plars> sergiusens: and we're not running vivid, we're on trusty
[20:50] <sergiusens> plars: adb only enabled after the screen is unlocked
[20:50] <sergiusens> plars: it's the same package ppa-copy-ed
[20:51] <plars> sergiusens: err, so is there a new option for this? or does --developer-mode still take care of it all for us?
[20:51] <sergiusens> plars: it's what I had you test during the sprint, no new option, no flag day, no zero day; --developer-mode takes care of it
[20:52] <sergiusens> plars: and it's harmless to use before the device stuff lands
[20:52] <plars> sergiusens: I didn't test this during the sprint did I? I thought all I tested was the new ubuntu-device-flash that added subcommands
[20:52] <sergiusens> plars: right
[20:52] <sergiusens> plars: but it's a noop today
[20:53] <plars> sergiusens: ok, when do you expect it will hit the ppa?
[20:53] <sergiusens> plars: as soon as you want it too
[20:54] <sergiusens> plars: when would you want to update?
[20:54] <plars> sergiusens: I can update it anytime
[20:58] <sergiusens> plars: great, I'll ping you once copied
[20:59] <john-mcaleely> so, thanks davmor2
[20:59] <john-mcaleely> I guess I push this tarball then ogra_ ?
[21:00] <sergiusens> plars: will you juju setup the box eventually?
[21:01] <plars> sergiusens: it's like that now
[21:01] <sergiusens> plars: oh, nice
[21:01] <plars> :)
[21:01] <john-mcaleely> in the absense of ogra_ I think I need to check with the trainguards to see if a build is underway right now?
[21:01] <john-mcaleely> if not, I think I'm clear to push
[21:02] <ribru> john-mcaleely: a build of what?
[21:02] <sergiusens> john-mcaleely: I can check on cdimage
[21:02] <john-mcaleely> ribru that ^ thanks sergiusens
[21:02] <ribru> cool
[21:08] <sergiusens> john-mcaleely: nothing seems to be running on cdimage
[21:08] <john-mcaleely> sergiusens, thanks. I'll push it then :-)
[21:09] <john-mcaleely> ogra, sergiusens pushed. should see a build appear in 30 mins or so
[21:09] <john-mcaleely> ogra_, ^
[21:13] <john-mcaleely> sil2100, ^
[21:16] <infinity> bregma: That new changelog looks much better, thanks!
[21:17] <bregma> infinity, I'm still learning how to defeat the ci-train robot's idea of what a good changelog looks like
[21:17]  * bregma is getting a bigger hammer
[21:20] <infinity> sil2100: What's the magic required to register my ACK of bregma's compiz changes?
[21:26] <AlbertA2> trainguards: can vivid silo landing-017 be published?
[21:38] <nik90> sergiusens, ogra_: Who do I talk to with regards to the volume of a phone call or alarm? Since the recent update (#6 on N4), despite the volume slider set to maximum, I can barely hear a phone call or an alarm. I just read an email in the mailing list where another person also experienced this.
[21:46] <tedg> trainguards, can you please publish vivid/24 ?
[21:46] <sergiusens> nik90: that would be rsalveti
[21:47] <nik90> sergiusens: cool, thnx
[22:02] <ribru> kenvandine: mterry: any core devs around for a packaging ack? https://ci-train.ubuntu.com/job/ubuntu-landing-017-2-publish/lastSuccessfulBuild/artifact/packaging_changes_location-service_2.1+15.04.20141105.1-0ubuntu1.diff is adding boost-dev, IIRC that's tricky
[22:03]  * kenvandine looks
[22:03] <ribru> tedg: sorry was on lunch, published
[22:04] <kenvandine> ribru, that looks fine
[22:04] <kenvandine> +1
[22:05] <tedg> ribru, No worries, thanks!
[22:05] <ribru> tedg: you're welcome
[22:06] <ribru> kenvandine: isn't there some kind of restriction where boost-dev can't be in main, you have to check which individual boost components you're using and only depend on those instead? like boost-dev is too large a thing and brings in too many unused deps or something
[22:06] <kenvandine> it is in main
[22:07] <kenvandine> the dev package needs some headers from boost to work, so it's really so other apps that build depend on location service
[22:07] <kenvandine> get the right build depends
[22:07] <kenvandine> one thing that has bitten us in versioned dev packages
[22:07] <kenvandine> like libboost-54-dev
[22:08] <kenvandine> or something... that has caused all kinds of pain in the past
[22:08] <ribru> kenvandine: hm, not sure what I'm thinking of then
[22:08] <kenvandine> well there are a bunch of broken down ones
[22:09] <kenvandine> we wouldn't want the runtime of location service to depend on all of libboost
[22:09] <kenvandine> but this is just the -dev package
[22:09] <kenvandine> depending on the other -dev
[22:10] <kenvandine> it could make builds faster if they depended on libboost-math1.55-dev
[22:10] <ribru> kenvandine: ahhh ok, it's the runtime I'm thinking of then. thx
[22:10] <kenvandine> for example
[22:10] <kenvandine> if all they needed was in that
[22:10] <kenvandine> but then again... that's versioned hell
[22:10] <kenvandine> i think there are virtuals for all of those actually
[22:10] <kenvandine> but for dev packages, i wouldn't make a stink about it
[23:37] <rsalveti> nik90: is this with vivid?
[23:37] <rsalveti> nothing changed in the audio stack, wonder if something else is causing that bug
[23:38] <nik90> rsalveti: no this is rtm image #6 stable image
[23:39] <nik90> it seems another person on the mailing list has that issue
[23:39] <rsalveti> nik90: that's interesting, mind opening a bug?
[23:39] <rsalveti> could be against pulseaudio, will try to take a look
[23:39] <nik90> I talked to brendand about it, and he said I should try adjusting the volume while receiving the call since that would then change the ringer volume instead of the media volume.
[23:40] <nik90> If that doesnt fix it, then I will report the bug
[23:42] <rsalveti> right, it depends on the active role
[23:43] <rsalveti> for you to change the current volume for voice call you need to have an active voice call in place
[23:43] <rsalveti> and then try changing volume
[23:43] <rsalveti> without anything playing, it'll change the volume for the alert role by default
[23:43] <rsalveti> which means ringtone
[23:43] <rsalveti> same for alarm and multimedia
[23:49] <nik90> rsalveti: which is fine, but there should still be a UI for this where it shows the volume for individual roles
[23:49] <rsalveti> nik90: indeed, that's something that would be part of system settings
[23:49] <nik90> rsalveti: is that something targetted for rtm, or ota?
[23:50] <rsalveti> probably for ota, but would need to check
[23:50] <nik90> ok