[00:34] ribru, ↑ please [00:34] Saviq: rtm 4 [00:35] ribru, thank you :) [00:35] Saviq: you're welcome [00:35] 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] ribru, it was there already [00:36] 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] ribru, I did, but just per-field [00:36] ribru, I didn't touch any of the automagic fields [00:36] Saviq: hm, weird. mysterious spreadsheet bs :-/ [00:42] ribru, need help ↑ [00:42] https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-004-1-build/61/console [00:42] how do I resolve that? [00:44] uh [00:45] 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] ribru, looks like sync should still rewrite 15.04 into 14.10... [00:45] ribru, yeah, that's what I thought, but meh :| [00:45] Saviq: no, the sync *did* do that, but the problem is that it shouldn't, because 15.04 is already there [00:45] 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] ribru, well, sync took the upstream 15.10 [00:46] ribru, it is 15.04 *with* the rtm tag [00:46] ribru, https://launchpad.net/ubuntu-rtm/+source/unity8 [00:46] bah [00:46] ribru, it was a source copy, that copied 15.04, now it tried to do 14.10 [00:47] meh for bumping, but what can I do... [00:48] * Saviq goes for -rtm [00:49] 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] was rejected. [00:49] Saviq: basically yeah, you have to mangle the version number yourself and upload manually [00:49] ribru, well, I know *how* it happened [00:49] ribru, just not sure what the correct resolution would be :) [00:50] ribru, I synced it from vivid last Friday [00:50] ribru, that was a source sync, but it only appended ~rtm [00:50] Saviq: a binary sync? [00:50] ribru, source sync, hence the ~rtm [00:50] ribru, basically a silo sync [00:51] ribru, line 1985 in the train archive [00:53] Saviq: this other error you're getting is much more interesting [00:53] ribru, it is indeed [00:53] getting the same for the other source :/ [00:54] and totally no error msg :'| [00:54] 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] Saviq: I'll try reverting my last commit and see if that gets it back into a state that can hobble along [00:55] 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] ribru, it's worky [00:56] I mean it's trying === chihchun is now known as chihchun_afk [00:58] Ursinha-afk: ^^ my awesome branch is less awesome than I thought [00:59] ribru: s/Ursinha-afk/Ursinha/ :) [00:59] ribru: oops [00:59] 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] 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] justinmcp_: welcome! [01:17] Justin Master Control Program. [01:18] justinmcp_: ok so do you know about the spreadsheet? [01:19] ribru: i know nothing [01:19] justinmcp_: ok. funny i thought we did this already once [01:19] justinmcp_: ok go here: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc#gid=0 [01:20] justinmcp_: find the first empty row (78) [01:20] ribru: got it [01:20] 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] ribru: and then magic? [01:22] justinmcp_: less like magic, and more like... http://i.ytimg.com/vi/MjuioxC5WwA/maxresdefault.jpg [01:23] ribru: :) confidence is high [01:24] justinmcp_: I'd like to retroactively rename ci train to... 'ci house of cards'. [01:24] case in point ^ [01:26] 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] ribru: *disappointment*, nobody cares :( [01:28] !! [01:28] my description has *links* to bugs! [01:28] Column A is used by QA though... very helpful to have a list of bugs fixed there. [01:28] and everything! [01:28] ToyKeeper, say you like my Column A, you know you do! [01:29] I do, actually. [01:29] Saviq: what links? there's no links ;-) [01:29] hmm this sounded much more sexist than I intended it to... [01:29] It saves me the trouble of populating that info myself on QA's kanban cards. :) [01:29] ribru, see! links! http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-007 [01:29] Saviq: oh you are doing links now. you used to just have the numbers ;-) [01:29] ribru, I was hoping you'd do links :P [01:29] ribru, but since you don't [01:30] Saviq: yeah everything's gonna change when we dump the spreadsheet, doesn't make sense to do new features right now [01:30] Most of the time, I have to either dig up the bug numbers or at least convert them to clickable URLs. [01:30] hah [01:32] 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] ribru, get a bigger screen ;p [01:32] 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] 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] 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] ToyKeeper: soon [01:33] ribru, you're an engineer, you should've engineered a crane to hold your 27" over your head! [01:33] ribru, it'd have worked, I assure you [01:34] and would be relatively safe [01:34] Saviq: hindsight is always 20/20. couldn't do that after I was already injured [01:34] ribru, excuses excuses :P [01:35] 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] and now the train-generated one will be higher again [01:35] hmm hmm [01:36] wait [01:36] ribru: finished, I guess.. [01:36] it will not be higher than the one in distro, though, will it... [01:36] yeah, that was stoopid [01:38] justinmcp_: ok, just set J78 to 'Yes' (which triggers the bot to notify us that you're ready) [01:40] its almost like magic [01:40] 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] Yup, magic indeed. [01:44] Saviq: you are just not having any luck today... [01:45] ribru, nah, it just uploaded [01:45] justinmcp_: Fatal error on your first try. You've got the magic touch! :) [01:45] ribru, will be fine now [01:45] this is why I code [01:45] how did all this 15.04 shit get into rtm? [01:46] ... what? [01:46] Please tell me we didn't pull stuff from 15.04 into rtm... [01:47] 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] That's a snowball which is very difficult to stop. [01:49] ribru, no, that's not true [01:49] ribru, *syncs* don't rewrite the 15.04 part [01:49] ribru, standard landings do [01:50] 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] ribru, but indeed, this will now happen to everyone that needs to move from syncs to rtm-targetted landings + series branch [01:51] oh right, you guys have MPs [01:51] Saviq: justinmcp_ well you better target your MPs into vivid then I guess. [01:51] ribru, they just landed in vivid [01:51] ribru, now I need to cherry-pick into rtm [01:52] ugh [01:52] ribru, because I can't afford to not land stuff that's not rtm-approved [01:52] ribru, and there will be more of that as we go on [01:52] Saviq: I'm frustrated, I don't understand how citrain code was allowed to get as bad as it is. [01:52] ribru, so this needs resolving asap, otherwise everyone will have to go .1 on their upstream versions [01:53] ribru, I imagine because it was only meant to live for a few months [01:53] 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] ribru, yeah, I'll try and talk to sil in between talks [01:53] am out for a conference tomorrow [01:53] and on that note, 4h of sleep ahead of me... === ribru changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI Train is incapable of landing MPs into RTM if that package was previously synced from vivid. you have to mangle the versions and upload manually [01:57] how do I re-try the build? [01:59] 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] justinmcp_: did you change your MP in some way? shit's pretty broken right now, you might have to wait until tomorrow. [02:00] ribru: I changes the target to vivid, but otherwise untouch [02:01] ribru: I can leave it till tomorrow [02:01] justinmcp_: oh if you're doing vivid we can do it today [02:01] justinmcp_ it's just syncs to rtm that are busted for now [02:01] or mps [02:01] justinmcp_: I have to free the silo to reset it for vivid, hang on [02:05] justinmcp_: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=justinmcp click Build here now ;-) [02:05] i feel empowered [02:06] justinmcp_: that was the idea originally ;-) [03:19] ribru: are you still around per chance? [03:21] veebers: what's up? [03:21] ribru: hey, I have a silly question that I thought you would be able to answer for me :-) [03:22] veebers: shoot [03:22] 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] 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] veebers: that looks like a recipe build, why don't you just run the recipe? [03:25] ribru: hmm, I was under the impression that wouldn't work due to version number conflicts [03:25] veebers: the version number already has 15.04 in it so you're basically already boned [03:25] hmm perhaps I miss-interpreted the comment that lead me to believe that [03:26] veebers: what was the comment? [03:26] ribru: oh, really? :-\ [03:27] 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] veebers: so that shouldn't cause any further problems than what's already there. [03:28] Me: "I could use the recipes 'request build right?' response "veebers: Unless the revno hasn't changed, thus causing a version conflict." [03:28] 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] veebers: but why do you want a new build if the revno hasn't changed? [03:29] 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] 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] veebers: i would personally try the recipe build, if that fails then you can futz the version manually [03:32] 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] 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] ribru: ack, I take it trying the recipe will fail as opposed to breaking things? (/me is being careful with this) [03:33] veebers: right, if there's any problem, the recipe will just fail, it won't make things worse. [03:33] the conflict you heard before and the 15.04 brokenness I'm talking about now are separate issues. [03:33] ribru: ok, I'll give that a try and see what happens, thanks for talking me through that [03:33] veebers: you're welcome [05:20] mornings [05:40] Mirv: morning [05:40] this is my queue that I really should log off ;) [05:40] *cue [05:45] cyphermox: correct! [05:46] ;) [05:54] Mirv: good night! [05:54] cyphermox: good night! [07:46] trainguards, can I get a silo for line 79 [07:49] tvoss: there you go, Mr. Bond. [07:49] (silo 007) [07:50] hah [07:50] Mirv, in style ;) [08:25] 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] Mirv, morning, did you have a chance to look at this ^ ? [08:27] pstolowski: hey! [08:27] pstolowski: just provide MR that target this branch in your landing [08:28] MRs [08:29] sil2100, hi! yep, i did that. cool, thank you [08:45] pstolowski: yes, I commented on the branch since you weren't online [08:54] Mirv, awesome, thanks! [09:05] damn [09:06] sil2100, so we have a slight image build prob ... [09:08] * ogra_ ponders how to solve it best === Saviq is now known as Saviq-codedive [09:15] trainguards, could you please reconfigure ubuntu-rtm/landing-002 ? [09:16] pstolowski: done. [09:17] thanks [09:17] ogra_: what's up? [09:17] ogra_: everything was fine yesterday, right? [09:17] sil2100, you might wanna know we're up for some train woes [09:18] Saviq-codedive: what's up? [09:18] sil2100, the dropping of the langpack causes the metapackage to be out of sync [09:18] sil2100, everone that synced from vivid to rtm have 15.04 in their versions in rtm [09:18] sil2100, but now you try to land through an MP into an rtm series branch [09:18] sil2100, you end up with 14.10 in there and you're lower than what's in rtm archive [09:19] sil2100, had to .1 unity8 for rtm silo 4 [09:19] Saviq-codedive: hm, indeed this might be trouble ;/ Damn, somehow no one expected this problem to happen [09:20] 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] But that's not something I can do without consulting slangasek and cjwatson [09:20] sil2100, well, and worse, that won't help now [09:20] I know... [09:20] sil2100, only thing that would help now is actually keeping 15.04 there [09:20] But at least it won't make the situation any worse [09:21] sil2100, which is actually something I would recommend [09:21] the series has no impact ... only if you put it into the version number [09:22] ogra_: I mean the series in the version [09:22] right [09:22] 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] 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] sil2100, TBH I'd recommend keeping it as is in the current top version [09:24] 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] sil2100, yup [09:24] * Saviq-codedive goes to focus on the talk [09:24] Saviq-codedive: thanks on letting me know about this! [09:24] Saviq-codedive: I was slowly moving away from CI Train maintenance so I didn't even notice this === chihchun_afk is now known as chihchun [09:59] 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] davmor2: close the camera app, does it show then? [10:00] thostr_: I think if I reboot it will appear though judging by what ToyKeeper was saying [10:00] 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] davmor2: just close camera app [10:01] thostr_, davmor2 - for me just closing the app worked [10:01] thostr_: yes after a couple of swipe to refresh now it shows up [10:01] thostr_, and that's not a new bug? [10:01] no, see my comment on the mailing list [10:01] it's a camera issue... [10:01] it's not releasing file handles of recorded videos [10:01] thostr_, yeah i confirmed the same thing [10:02] which means mediascanner can not pick it up as it can only react to files that are fully written [10:02] or rather, we get only notified once the file handle is released [10:03] 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] bzoltan, you didnt see cjwatson's answer ? he wrote quite a lot yesterday [10:04] ogra_: I have missed that... [10:04] * bzoltan reading logs [10:05] http://irclogs.ubuntu.com/2014/11/04/%23ubuntu-ci-eng.html#t16:07 [10:07] 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] ogra_: in the meantime enabling legacy ciphers would be an acceptable _temporary_ solution. [10:08] i would like to hear security team input to that first [10:12] 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] 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] this has to be fixed within the next months [10:14] ogra_: fine with me ... as long the devs can run their apps on the device after they switch the "development mode" on [10:14] (or earlier depending when/if rtm switches to vivid [10:14] shipping an insecure ssh on a sold phone is not an option [10:15] 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] so upstream has to react somehow ... [10:15] (i also doubt we are the only distro using a new upstream ssh) [10:16] bzoltan, this is something we dont have control over ... upstream considers these cyphers to insecure to ship [10:16] 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] (beyond the fact that vivid at this point doesnt get Qa [10:16] ) [10:17] hi Mirv, we'd need a binary copy of oxide in silo 15 (vivid) [10:18] 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] or a nice trainguard if not available [10:19] dbarth, Mirv: hold on a sec, the silo needs a rebuild first (just removed a MR from it) [10:20] dbarth: o/ [10:21] dbarth: from which PPA? [10:21] 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] oSoMoN: ACK [10:21] * sil2100 reconfigures then [10:22] thanks! [10:24] oSoMoN: ok, copying the package now [10:25] okie [10:25] uh [10:25] oSoMoN: I see oxide was built for utopic in that PPA... [10:25] sil2100: it probably needs to be done from command line. I can do that, I've done it before. [10:26] oSoMoN: this *might* be a problem when doing binary copies, as we can't guarantee binary compatibility [10:26] Mirv: ^ [10:26] sil2100: utopic shouldn't be a problem, vivid could be? [10:26] sil2100, oh, you’re right! sorry about that, I guess we’ll have to rebuild it for vivid first [10:26] oSoMoN: no, vivid could be a bigger problem for rtm than utopic [10:26] Mirv: well, the phablet PPA has utopic binaries of oxide-qt, and they need to copy it to vivid [10:26] oh, this's a vivid silo, not rtm [10:26] Yes [10:27] Mirv, we’re not going to sync to rtm anyway, oxide 1.3 has been rejected for rtm [10:27] oSoMoN: yeah so in that case indeed rebuild for vivid [10:27] Mirv, yup, will do, thanks [10:27] and then we can copy [10:27] Mirv: will you handle this till the end then? :) [10:27] Thanks! [10:27] sil2100: what oSoMoN said ;) [10:27] sil2100: sure, no problem, but with Oxide I'll be EOD's when the build finishes in 5h ;) [10:27] thanks guys [10:27] Eeej [10:27] Eeek [10:27] ;) [10:27] Mirv, sil2100, no worries, there’s no urgency on this one, it can wait till tomorrow [10:28] my last build was 5h 26min https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-002/+build/6514437 [10:28] we’ll get oxide built for vivid first, and ping you tomorrow when done and tested [10:34] 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] uh [10:37] Mirv, pstolowski: seems like the issue mentioned by Saviq-codedive... [10:37] * sil2100 sighs [10:37] What to do what to do... [10:38] sil2100, ah.. [10:39] 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] cjwatson: hello! Are you around for a quick advice? :) [10:40] sil2100, sure [10:41] 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] Since it should probably point to the current developmnent series anyway [10:59] sil2100: the unity8 run came back ok on the rerun [10:59] psivaa_: how many failures? 2-3? [10:59] ok meaning at least it completed [11:06] sigh [11:07] ogra_: any luck? [11:07] sil2100, no, and i see no way to fix this ... pitti doesnt seem around either, nor does cjwatson ... [11:07] Yeah, I would need cjwatson's or slangasek's opinion as well to fix the train [11:08] 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] the prob here is that germinate needs to recognize the langpack gone ... [11:09] by default it reads from the utopic archive ... where the landgapck simply isnt gone [11:09] *langpack [11:09] (and where we cant remove it now that utopic is released) [11:09] Can't we retarget it somehow? [11:09] yes, thats what i tried ... but there is debootstrap involved ... [11:10] and debootstrap neither knows what rtm is nor that there is a 14.09 release [11:10] the rtm archive only knoows 14.09 and devel as distros [11:11] (and no, debootstrap doesnt know devel) [11:12] Damn [11:13] i'll sync the latest changes into vivid now at least ... [11:13] we coould theoretically binary snyc from vivid once this is done ... but that completely messes up the changelog [11:13] 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] Like blacklisting those langauges somehow in the UI [11:14] well, the seed has "langpack-ubuntu-touch-*" ... it reads the actual list from the available packages in the archive [11:14] read: this isnt even a seed change at all ... just a germinate run [11:15] blacklisting but shipping would be quite some hack [11:16] i think the only sane way is to pull the vivid meta in ... but at the cost of losing the histroy :( [11:16] Let's hack germinate! [11:16] \o/ [11:16] heh [11:17] Anyway, I would still wait for at least pitti to appear [11:18] right [11:21] sil2100: sorry, variously on vacation / conference leave this week so not really enough brainspace to advise, hopefully somebody else is around [11:22] ogra_: I'd just hack the metapackage manually (carefully!) and not worry too horribly much about germinate-update-metapackage being unhappy [11:22] it's not actually a hard requirement [11:22] cjwatson, you mean hack the deps directly ? [11:23] ok, that shouldnt be to hard [11:23] sure [11:23] thanks [11:23] well, the files used to generate them [11:23] thats the one option i didnt consider :) [11:32] * ogra_ uploads and crosses fingers [11:54] Mirv, do you happen to know where the latest clicks for e.g. calculator might be? [12:03] sil2100, ok, starting a test build for both distros ... cross your fingers :) [12:03] ogra_: \o/ [12:04] (the bot wont announce them, it still waits for the finishing of vivid9 and rtm143) [12:13] I go to lunch, back in some time [12:15] pstolowski: after lunch someone from should be already available to review my proposal and I might be able to unblock your landing [12:19] phew, looks like the build got past the failure ... great [12:20] sil2100, k, thanks for heads up [12:23] brendand: http://s-jenkins.ubuntu-ci:8080/job/calculator-app-click/ [12:28] brendand: they all tend to be of the same form (url) [12:38] 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] mdeslaur, there is a request from the SDK team to re-enable them in vivid [12:39] 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] (there is subsequent discussion between zoltan and me in todays backlog too btw) [12:44] ogra_: what component is responsible for that? [12:45] openssh-server [12:45] on the phone side ... [12:45] ah, I see the qtcreator commit now [12:45] not sure what component of QtCreator [12:50] 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] but as a temporary measure only [12:50] right [12:50] and who keeps track of this [12:50] ogra_, was a 143 built? trying to debug my updates [12:51] and who makes sure that doesnt slip into a potential vivid-rtm if we merge before feature freeze etc [12:51] pmcgowan, no, we have image build issues [12:51] ok [12:51] working on them ... with luck there should be an image in a few [12:51] ... and so we will ... phew [12:52] rootfses build again ... waiting for system-image importer now [12:52] ~20-30min [12:52] 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] *much [12:53] ogra_: right, someone needs to own the bug to fix qtcreator and to remove the workaround [12:53] honestly, it's probably as easy to fix qtcreator [12:53] bzoltan, ^^^^see backlog [12:54] yeah, one would hope so ... especially since it will surely be hit by that in other distros too [12:59] mdeslaur, whats the fix - to use a different lib? [12:59] just add a couple of extra algorithms, no? [13:00] or are those the _only_ ones that are available? [13:00] * mdeslaur looks at source [13:09] ah, yeah, it's going to require some modifications, hrm [13:10] I guess adding the ciphers back to the phone images until upstream replaces the ciphers in qtcreator is the workaround for now [13:11] hmm, k [13:16] traingards, a silo for row #71 pretty please? :-) [13:16] davmor2, brendand can I get your help to test vivid silo 7? [13:16] trainguards ^ [13:17] tvoss, today is your lucky day [13:18] brendand, cool [13:25] brendand, please test media playback, too [13:44] === trainguards: IMAGE 9 DONE (finished: 20141105 13:45) === [13:44] === changelog: http://people.canonical.com/~ogra/touch-image-stats/9.changes === [13:44] === trainguards: RTM IMAGE 143 DONE (finished: 20141105 13:45) === [13:44] === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/143.changes === [13:44] \o/ [13:44]