#ubuntu-ci-eng 2014-01-02 <tvoss_> good morning * psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Network issues in 1SS * cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <cwayne> plars, hey, wondering how to get the adb device on ashes that's used for touch_custom? <plars> cwayne: should be in the output log, one sec <plars> cwayne: 01ce848e48dfa6a2 <plars> cwayne: it's not *super* clear, but it's in the log at 01ce848e48dfa6a2 toward the top <xnox> i need touch/autopilot expertise. Can I run all phablet-test-run deb/click tests in one go, without reseting/rebooting device in any way? <xnox> (as in does phablet-test-run sanity checks the environment before executing tests, and/or puts it back into a known state at the end) ? <cwayne> plars, so it looks like the gallery-app and ui-toolkit autopilot tests are somehow refusing to load a custom theme, which is why so many failures in touch_custom <plars> cwayne: ok, is that something you can confirm locally? do you need me to rerun things? <cwayne> plars, i've just confirmed it locally * doanac changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - * plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: plars | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - * plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - #ubuntu-ci-eng 2014-01-03 <Mirv> ok, I guess no daily calls yet <popey> Mirv: yeah <Mirv> and happy new year anyone who happens to be back :) * josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <fginther> morning <dobey> cihelp: can i get some review on https://code.launchpad.net/~dobey/cupstream2distro-config/add-u1client-data/+merge/200353 and perhaps a deployment of the config once it gets merged? <fginther> dobey, looking <fginther> cyphermox, kenvandine, robru, can any of you review ^ * kenvandine looks <kenvandine> approved <fginther> kenvandine, thx <kenvandine> np <dobey> fginther, kenvandine: thanks. any idea on when that can get deployed and show up in jenkins? <fginther> dobey, one moment, it should be merged and ready to deploy now <dobey> fginther: yep it is merged <fginther> dobey, it's deployed now * josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <dobey> fginther: thanks #ubuntu-ci-eng 2014-01-06 <didrocks> hey Mirv, happy new year! * ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: ev | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <popey> didrocks: no landing task force meeting? It disappeared. <popey> (morning and HNY btw) <didrocks> popey: magically! <didrocks> popey: happy new year ;) <ogra_> lol <didrocks> yeah, Mirv and sil2100 are off today <popey> ah <didrocks> no real need to have one, let's get people catching up emails <didrocks> and trolling for ogra_ :p <popey> haha <popey> ogra_: nexus 5 done yet? <popey> how about now? <popey> and now? <popey> etc <ogra_> so i got calendar notifications from my phone every damned day during my vacations ... but the firs meeting after my vacations doesnt notify me :P <popey> haha <didrocks> popey: apparently, he's rewriting something in perl soonâ¦ :p <ogra_> lol <popey> â» <popey> Hmm.. Ubuntu Touch on one of these puppies... http://liliputing.com/2014/01/hp-unveils-slate21-pro-android-powered-one-desktop.html? <ogra_> ++ <asac> o/ <asac> HNY :) <ogra_> same same :) <didrocks> hey asac, HNY too! <asac> didrocks: thanks!\ <rsalveti> popey: that device looks quite cool, but would be way better with ubuntu <ogra_> i doubt HP would have liked to wait for 14.10 and a working desktop mode in the converged UI though :) <davmor2> didrocks, ogra_: are you looking to promote a new image at all today? or can I test the current? <didrocks> davmor2: just test current, we won't promote anything I guess until we are back on shape :) * ogra_ hasnt heard anything ... and we have no meeting today <ogra_> i guess its not *that* urgent to promote one today * didrocks wonders why the launchpad cred message isn't shown * josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <Kaleo> wasn't there a QA website with boot startup time for Ubuntu? <ogra_> Kaleo, for x86/amd64 there is ... <Kaleo> ogra_, where is it? I cannot find it * ogra_ still has an open task to set something similar up for touch <ogra_> Kaleo, https://jenkins.qa.ubuntu.com/view/Bootspeed/ <Kaleo> ogra_, hmmm <Kaleo> ogra_, it was a very different website before <ogra_> hmm <Kaleo> ogra_, with even rendering stats per hardware too <ogra_> yeah, there must be bootcharts somewhere <Kaleo> http://ci.ubuntu.com/ <Kaleo> ... <Kaleo> ...:) <Kaleo> that's it :) <ogra_> hmm, actually not the one i meant <ogra_> mine actually had proper bootchart pngs linked <ogra_> but i cant find it ... these bootspeed measurements arent very helpful to track down services delaying the boot <xnox> Kaleo: http://ci.ubuntu.com/bootspeed/arch/amd64/ <xnox> ogra_: ^ <ogra_> xnox, no bootchart <ogra_> (thats the details page of Kaleo's link above) <seb128> ogra_, it has, click on "detailed view" and then "raw data" on the left <ogra_> doesnt load anything for me :( <seb128> it's slow for me too, I had to retry 3 times to get the list <xnox> ogra_: no without pain, one can download get everything from there... there is even a full tarball of logs & full-blow bootchart images available.... somewhere.... <ogra_> all i could find looks like a self knotted bootchart impostor thingie <ogra_> *knitted <ogra_> (through jenkins.qa.u.c) <seb128> ogra_, https://jenkins.qa.ubuntu.com/job/bootspeed-trusty-desktop-i386-acer-veriton-01/9/artifact/11/bootchart.png <ogra_> yeah <ogra_> it finally loaded here too * ogra_ just looks at artifact 13 .... 57sec boot time ... ugh <seb128> seems the system stopped working though, no record since 20131108 <ogra_> yeah <fginther> morning <didrocks> hey fginther! happy new year :) <fginther> didrocks, happy new year to you as well! <didrocks> thanks ;) <didrocks> fginther: before your meeting starts, do you know where you backup the gpg and ssh keys for ps-jenkins? <didrocks> I think we'll need them for the citrain and ev needs to put that as part of his incoming juju deploy script <fginther> didrocks, yep, I know where they are, let me dig them out for you <didrocks> fginther: yeah, if you can send them to me as well, that would help for my local testing! :) <fginther> didrocks, and get them documented <didrocks> perfect! <kgunn> didrocks: happy new year ! <kgunn> didrocks: am i correct in seeing, you guys just have some backlog to work thru before getting to mir ? <kgunn> totally understandable <didrocks> kgunn: hey! happy new year :) <didrocks> kgunn: yeah, there are some backlogs and Mirv/sil2100 start only tomorrow :) <ogra_> hmm, nobody pulled in the session changes it seems <didrocks> kgunn: so expect that we try landing Mir on wednesday I would say, is that ok for you? <kgunn> ok...np, will be looking to make sure mir is well behaved :) <didrocks> kgunn: thanks :) <didrocks> ogra_: no, see associated comment, it was pending on mterry, I didn't track then when I was on holidays <ogra_> hmm, i thought it was ready when i left <ogra_> didrocks, bah, thats long obsolete <didrocks> ogra_: ah, well, it was still written :) <ogra_> (he commented on the MP) <didrocks> (not sure why it's not showing up as red anymore) <sergiusens> fginther, hey, can we circle back with the android builder? <fginther> sergiusens, I'll be available shortly <sergiusens> fginther, ack, thanks <fginther> sergiusens, here's the last attempt: http://s-jenkins.ubuntu-ci:8080/job/ubuntu-touch-image-builder/12/console <sergiusens> fginther, try and install xz <fginther> sergiusens, xz is there <sergiusens> hmm <sergiusens> fginther, is this precise, trusty,..? <fginther> sergiusens, it was raring, I've since updated to saucy and am now trying a fresh build <sergiusens> fginther, ack, error looks weird to me <sergiusens> as in, not much information :-) * ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <Kaleo> ogra_, any idea how to disable MTP on the phone? <Kaleo> ogra_, it seems to be the probable cause of my adb/ssh shell being disconnected constantly <Kaleo> just dug up https://code.launchpad.net/~pwlars/ubuntu-test-cases/mtp-is-less-broken/+merge/197942 <ogra_> Kaleo, iirc there was a regression that cyphermox and sergiusens were about to fix * fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: fginther | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <sergiusens> Kaleo, ogra_ constantly or just at boot? <fginther> sergiusens, still fails on saucy: http://s-jenkins.ubuntu-ci:8080/job/ubuntu-touch-image-builder/14/console <fginther> sergiusens, same error regarding vmlinuz <sergiusens> Kaleo, ogra_ there is only one disconnect left and it's when android starts and resets the usb device <ogra_> sergiusens, what was that regression davmor2 talked about ? <sergiusens> ogra_, something about mtp not working on boot when the device was connected <ogra_> (i dont think the disconnect on boot is a regression, it was always there) <sergiusens> although that works for me <sergiusens> but it's not related to Kaleo's comment at all <Kaleo> sergiusens, constantly when connecting via ssh over adb <Kaleo> sergiusens, less frequently with just adb <sergiusens> Kaleo, that means you change the usb settings? <davmor2> ogra_, sergiusens: cyphermox I think was looking at that, the mtp from Friday <Kaleo> sergiusens, I don't know what that means; I'm just connecting via ssh <davmor2> ogra_, sergiusens, Kaleo: This is when you're ssh/adb session gets kicked when mtp connects I guess which is an older issue right? <davmor2> your even <Kaleo> davmor2, that's my guess <Kaleo> davmor2, yes <davmor2> Kaleo: yeah it does there is a bug for that :) <sergiusens> Kaleo, davmor2 I don't know how adb can reset ssh unless you connect over rndis <Kaleo> davmor2, linkie? <davmor2> sergiusens: I don't know about ssh but adb shell work fine if you attach after mtp has attempted to connect if you attach before you get kicked when mtp attaches <davmor2> Kaleo: I'll try and find it <Kaleo> davmor2, thanks <sergiusens> davmor2, I know; but the definition of constantly disconnects Kaleo gave is a bit different than disconnects on boot <davmor2> https://bugs.launchpad.net/mtp/+bug/1233613/ <ubot5> Ubuntu bug 1249162 in android-tools (Ubuntu) "duplicate for #1233613 Devices lose adb connection after phablet-flash loop" [High,Confirmed] <sergiusens> davmor2, mtp attaching should be the cause of the last disconnect; it's actually setting the usb device from ubuntu, then when android starts have it do the same (hence the disconnect) <sergiusens> davmor2, and the mtp job doesn't touch the usb config anymore, which waas the 3 disconnect <davmor2> sergiusens: ah fair enough <davmor2> Kaleo: ^ sorry I didn't add your nick to the bug <davmor2> sergiusens: that's good to know, so now in theory it shouldn't kick adb off when mtp connects right? if so I'll run a test on that once mtp is working correctly :) <sergiusens> davmor2, it shouldn't, no; the usb device is reset only when changing the android property for the usb device <Kaleo> davmor2, thank you <cjohnston> / <davmor2> sergiusens: thanks for the info I'll run a few tests on it when I know the mtp fix has landed <dobey> is there anything special one needs to do, to get a whole new package landed on the image? <sergiusens> dobey, needs to be in the touch seed <sergiusens> https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.trusty <dobey> sergiusens: right. i mean, if the package is set up for daily-release and in CI already, but not in ubuntu. <sergiusens> afaik, the daily release team can get into ubuntu <sergiusens> robru, ^^ <dobey> who all is the daily release team? <sergiusens> dobey, long read https://wiki.ubuntu.com/DailyRelease, short read https://launchpad.net/~ubuntu-unity <sergiusens> so that's basically cyphermox robru didrocks Mirv sil2100 <dobey> yeah, most of the people on it are in europe <dobey> kenvandine: !! :) <kenvandine> hey dobey <dobey> hey kenvandine. ready for the freezing tomorrow? <kenvandine> not really :) <dobey> heh <kenvandine> my plan is to not leave the house :) <kenvandine> dobey, what package do you need? <dobey> kenvandine: can you trigger a build of ubuntu-purchase-service into the daily ppa? <kenvandine> what stack is it in? <dobey> then do the rest of the daily-release work to get it into ubuntu if it builds successfully <dobey> kenvandine: click (is that a stack?) should be in the same stack that unity-scope-click is in <kenvandine> doesn't look like it's in the click stack <dobey> i put it next to unity-scope-click in the CI config, anyway <dobey> huh <kenvandine> ok, i see it now <kenvandine> but not showing in jenkins <dobey> hrmm <kenvandine> maybe it wasn't redeployed? <dobey> not sure. i saw the landing jobs for it when i looked at jenkins the other day <dobey> or maybe some other bit needs to be deployed for daily-release jobs stuff that i don't know about <dobey> who to ping about that? cihelp? <fginther> dobey, looking <kenvandine> i'm redeploying the stack <fginther> kenvandine, thanks <dobey> ah ok <fginther> dobey, I also deploy the webcred stack to finish ubuntuone-client-data. sorry for overlooking this portion of the deploy <dobey> thanks fginther <fginther> (2 deploys are needed on 2 different jenkins, I only did the first one) <kenvandine> http://q-jenkins.ubuntu-ci:8080/job/cu2d-click-package-head-1.1prepare-ubuntu-purchase-service/2/console <kenvandine> fginther, what's wrong with the version? <fginther> kenvandine, looking <kenvandine> oh <kenvandine> it isn't UNRELEASED maybe? <fginther> kenvandine, trusty should be ok <dobey> hrmm, one second <kenvandine> does it require an ubuntu revision? * kenvandine doesn't remember what's expected there <dobey> it might. <dobey> kenvandine: can you try to do builds of ubuntuone-client-data or ubuntuone-credentials? <dobey> if those fail on the version it's probably the broken expectation of a non-native version <dobey> so, blame didrocks :) <dobey> not sure what code to fix, in order to fix that, though <kenvandine> i started ubuntuone-client-data <kenvandine> same error <dobey> ok, so almost certainly it doesn't like native versions <dobey> hrmm <dobey> let me see if i can fix it <dobey> oh no, that's not the problem <dobey> seems it's parsing the date wrong <dobey> ah, becasue the regexp is wrong <fginther> dobey, kenvandine, looks like it expects 20131204 and not 013.12.19 <fginther> err 2013.12.19 <dobey> oh <dobey> yeah <dobey> where did i get the one with dots from <dobey> huh <dobey> robru: why was this done? https://bazaar.launchpad.net/~dobey/ubuntu-purchase-service/fix-version/revision/7 <dobey> and apparently without an MP for it? <dobey> kenvandine, fginther: https://code.launchpad.net/~dobey/ubuntu-purchase-service/fix-version/+merge/200578 <kenvandine> ugh... you reverted the packaging cleanup... <kenvandine> robru would have done that to follow our packaging standards <dobey> robru should have made a merge proposal <kenvandine> agreed <dobey> and explained why those changes make sense here <kenvandine> https://wiki.ubuntu.com/DailyRelease/InlinePackaging#Package_inlining_checklist <kenvandine> not sure why their wasn't a MP... maybe it didn't have CI setup yet? <dobey> it had ci <dobey> or it should have <dobey> at the very least it had people working on the code and reviewing branches <dobey> "jenkins isn't running on it yet" is not a valid reason to not have an MP <kenvandine> dobey, agreed <dobey> the changes to debian/control made no sense anyway. it didn't make it easier to read <kenvandine> all of the daily release packages we do that, didrocks set a standard for that <kenvandine> trailing comma <kenvandine> etc <kenvandine> sorting <kenvandine> robru, can you comment on dobey's MP? <dobey> i have no problem discussing such proposed changes, but that's what MPs are for. you don't just outright commit to the branch <dobey> remvoing debian/source and adding .bzr-builddeb were not necessary, and wrap-and-sort -a -t makes the control file less readable and more annoying to manage. the added comment about Vcs-Bar is also confusing and unnecessary <dobey> fml <dobey> qmltestrunner == pain. <dobey> qmltestrunner: could not find a Qt installation of '' <dobey> how am i even supposed to debug that? <kenvandine> does that support qtchooser? <sergiusens> dobey, QT_SELECT=qt5 probably missing <kenvandine> what sergiusens said :) <dobey> and why would i have to specify that? <dobey> i certainly don't have to when building locally <sergiusens> to support qt4 and qt5 at the same time <sergiusens> dobey, you have qt5-defaults package installed <dobey> i don't support qt4 at all <sergiusens> to support it on the same system that is <kenvandine> dobey, you could build dep on qt5-defaults <kenvandine> but i think someone was discouraging that <dobey> it's a clean environment and i build-dep on qt5base-dev; that should be enough <kenvandine> "should" <kenvandine> but without qt5-defaults, it can't find qt <dobey> well, software has been known to be buggy <kenvandine> it would be nice if it was smart about falling back <dobey> why doesn't the qt5 stuff depends on qt5-defaults? <kenvandine> because then it wouldn't work for qt4 <robru> kenvandine, dobey: sorry lauren32@example.com. I sometimes don't do MPs for such simple packaging changes since I follow didrock's packaging guidelines strictly, they should be uncontrovercial changes. Also it's possible that there was some rush to get a package out at the time (eg, jenkins was delayed by several hours but we wanted to get the package published for an image build). <kenvandine> on the same system <dobey> robru: this package isn't in ubuntu yet. it's a brand new project <dobey> robru: and i do find those guidelines controversial :) <kenvandine> dobey, you are the first upstream to complain about them <robru> dobey, yeah, I thought we were in a hurry to get it into ubuntu at the time. <kenvandine> dobey, that is sooo "dobey" of you :) <dobey> kenvandine: i'm probably also the only one who cares enough about package quality to complain about them :) <robru> dobey, yeah, I find your standards bizarre. 'wrap-and-sort -a -t' makes it way nicer, trailing commas especially make future diffs a lot easier to read. <dobey> robru: i don't care if diffs are easier to read or not. i'm not reading diffs when i'm looking at debian/control :) <dobey> and i don't think wrap-and-sort makes it nicer <kenvandine> didrocks set strick guidance on package consistency for everything landing in daily release <robru> dobey, um... lots of people are reading diffs of debian/control? like the release team? <dobey> having 1 space at the beginning of the line for EVERY dependency item, makes it much nicer for me <dobey> robru: really? debian/control shouldn't be changing so often <kenvandine> dobey, part of this is so the cu2d system can decide if the packaging needs packaging review before publishing <robru> dobey, it may not change often, but when it does, clean diffs are nice. also one-space indents are literally unheard of, it's a lot easier to read with a nice big indent that sets it apart from the rest of the file. one-space indent is nearly invisible, hard to see where the dep list ends etc <kenvandine> and gives a packaging only diff for us to review <dobey> kenvandine: they can't both be guidelines, and be strict. it's one or the other. and i've already bugged didrocks about the split/native thing, and i'm trying to make it better by not having it, here <dobey> robru: the problem with wrap-and-sort is that the indent is not consistent across the entire file <kenvandine> what i care about is consistency... i really don't want some packages split and some native <dobey> kenvandine: i don't want any packages split <robru> dobey: it is consistent: each following line is indented to the position of the first line ;-) <dobey> kenvandine: things that include the debian/ dir upstream are native packages <kenvandine> i don't want to go back and change all of them <dobey> kenvandine: using bzr-builddeb split mode is a red herring <dobey> robru: no, it is not consistent <dobey> robru: it is indented according to the value it is filling <dobey> robru: "Build-Depends:" and "Depends:" are not the same width <robru> dobey, yes, each stanza is consistently indented according to the value it's filling ;-) <dobey> robru: which means copying a dep from one to the other is a pain <robru> dobey, it's not a pain, just run 'wrap-and-sort -a -t' when you're done, it will indent it nicely for you. or get a real editor ;-) <dobey> and considering they are often the same, especially with packages that are runtime-interpreted code <dobey> whatever <dobey> if you have a problem with the way it exists in the tree, file a bug and a merge proposal and we can argue about it there <dobey> i don't want to waste time arguing about it in irc with multiple people about different aspects of the same thing <robru> dobey, i don't have a problem, I am following guidelines as I have done for literally hundreds of packages ;-). you're the one that has a problem. <dobey> i have no problem. i am following the policy as i have done for literally hundreds of packages :) <dobey> a) i shouldn't have to run wrap-and-sort, ever. b) my editor is just fine. "get a real editor" is not an argument, it's an insult <robru> dobey, what policy? I have never seen a policy that says "use one space indents and make sure you leave off trailing commas in a diff-ugly way." <dobey> sigh <kenvandine> dobey, the thing is, with the move to daily release this is the standard we've been given to follow <kenvandine> and it has been so for quite a while <kenvandine> so lots of packaging already following this <kenvandine> everything in daily release is <robru> kenvandine, have you ever seen a package with one-space indents? I have literally never seen that before. if you're going to argue that there should be a fixed number of spaces, at least pick a sane number like 4 or 8. <kenvandine> robru, i have... lots of them <dobey> every package i've ever put in ubuntu has one space indents <dobey> every Description: line has one space indents <robru> dobey, in the description line, it's a hack to tell the parser that it's a continuation line instead of starting a new field.... for dep lists i've never seen it that way <kenvandine> dobey, this isn't about difference of opinions... it's about standardizing all the packages we have auto landing for the distro <dobey> kenvandine: no, this is about commiting chages to a tree without a merge proposal <kenvandine> that would have helped understand, sure <kenvandine> but that isn't what we're talking about now... it's about packaiging preferences <dobey> we're only talking about that because i'm reverting the changes that were committed without an MP <dobey> and they happen to be packaging preferences <kenvandine> dobey, ok, so you'd take the changes if robru proposed them? <dobey> no <dobey> but i'd discuss them in the MP <dobey> and with didrocks <kenvandine> i guess that's the next step <kenvandine> and you can try to convince didrocks :) <dobey> if the commit i was reverting were style changes to c++, we wouldn't be having this conversation <dobey> and all these are, are style changes <robru> dobey, you're absolutely right, they are style changes... that's why they should be uncontrovercial and left alone. <dobey> robru: by that argument, you should never had made the change then, because the existing style should not be controversial and it should be left alone :) <robru> dobey, no... i'm following a standard as I was told to do by my team lead. <kenvandine> dobey, these debates with you are so much more fun with rum <dobey> i can go get some <dobey> it's about that time anyway <kenvandine> it is... and getting cold enough that it would be nice for warmth <dobey> kenvandine: https://ubuntuone.com/08D8LG5Pg8wG5Nx6i7bOKe <kenvandine> that looks much better than this banana stuff i have left from the virgin islands... <dobey> it is very good indeed <dobey> oh man, i should have bought some bananas, caramel, and ice cream, when i went to the grocery for lunch. could totally be having some tasty bananas foster right now if i had. <dobey> might have to go back after work <dobey> kenvandine: how many packages are using the split mode for daily release anyway? <kenvandine> tons <kenvandine> gotta be well over a hundred <kenvandine> everything in cu2d <dobey> so nothing a 30 line python script couldn't handle for turning them into proper native packages? <kenvandine> probably <kenvandine> it would still be a pain <dobey> pfft <dobey> only because you'd have to review all the MPs that took only 10 minutes to create with the 30 line python script :) <kenvandine> yup :) <kenvandine> and they'd all have to get in the distro too <dobey> and you'd know i'd do it just to annoy you and kill the "there are too many packages using split mode already" argument * kenvandine debates a drive to visit dobey <kenvandine> :-D <dobey> heh <dobey> i have rum :) <kenvandine> :-D <dobey> well the Kraken is almost gone, but the Flor de Cana is still almost a full bottle i think <dobey> of course there's a packey that's only 1 mile away, so not really an issue :) <kenvandine> :p <dobey> aka "the man" in virginia, since you can't buy it anywhere else <kenvandine> would need lots of rum to convince me switching to native is a good idea <dobey> i don't need to convince you. you already know i'm right, and native format is right, because the packages are already native, and split mode is a hack to probably workaround some issue we wouldn't have anyway if we properly used native packages :) <kenvandine> you might be right... <dobey> heh <kenvandine> i really don't know... but i'd hate to change everything just because <dobey> well yeah, i wouldn't change it "just because" * fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - #ubuntu-ci-eng 2014-01-07 * psivaa_ changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <Mirv> psivaa: hi and happy new year! there seem to be some lock files or such preventing both autobuilds and at least hud stack build - http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/All/job/cu2d-build_all-head/377/console <psivaa> Mirv: happy new year to you too, let me take a look <Mirv> thanks, no hurry <ogra_> hmm, no tests for #115 and #116 <psivaa> ogra_: will take a look at that too <ogra_> thx <ogra_> seems to have fallen over yesterday already <psivaa> ogra_: is there another image due now or shall i run the tests for 116? ( i'll need to see if we could run 115 at all) <ogra_> 116 is the latest from 3am UTC tonight <ogra_> the next auto-build would be at 15:00 UTC ... if we dont decide to disable that one and switch to manual <ogra_> so i'd say skip 115 <psivaa> Mirv: this stale stack issue requires some lock files deleted. i think it's safe now to remove them because there is no job running at the moment. <ogra_> looking over the last days i wouldnt expect any dramatic change anyway <psivaa> ogra_: ack, thx. i've started to run with 116 <ogra_> awesome :) <didrocks> Mirv: hey, joining? <didrocks> psivaa: ^ <ogra_> sigh, my talkpluginb asks weird questions <didrocks> ogra_: give weird answers then! <psivaa> didrocks: joining <didrocks> :) <popey> Like "What's the weight of an unladen swallow?" <asac> plars: psivaa: hi ... could we resume sending around the retried jobs (e.g. flaki ones?) ... or is mako really magically green nowadays? <asac> i think a mail to landing teams at end of day would be nice <ogra_> didrocks, it doesnt tell me where i can give these answers unless i read a multipage help thingie <psivaa> asac: ack, will do <ogra_> sigh <ogra_> so even setting the permissions according to the help file it still asks me to set them <Mirv> psivaa: yep nothing is running so lock files could be removed <psivaa> Mirv: ack, doing that <psivaa> Mirv: i've kicked off the job in concern.. http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/All/job/cu2d-build_all-head/378/console <psivaa> appears progressing <Mirv> psivaa: thanks! looks good now again, we'll get a bit fresher look and I fixed hud stack for example so it should try to build properly <psivaa> Mirv: ack <ogra_> argh ... and the firefox upgrade i just did makes it unstartable now ... yay for keeping an LTS installed for stability * ogra_ shakes his fist <ogra_> WOAH ! <ogra_> i had to remove the locale package ! <didrocks> Mirv: remember we have the weekly meeting tonight :) <ogra_> cronjob for 15:00 UTC disabled <didrocks> thanks ogra_ :) <Mirv> didrocks: sure! :) <popey> didrocks: aiming to promote 116? <popey> (assuming tests etc) <didrocks> popey: yeah, if you can get anough testing with davmor2 :) <popey> kk <davmor2> didrocks, popey: Hey anything specific that we are looking at? Was swap dropped or is that to come? <didrocks> davmor2: no, just usual health check :) <davmor2> didrocks: will do <didrocks> thanks! <davmor2> popey: is mtp working for you? <davmor2> didrocks: ^ <popey> yes <davmor2> popey: thanks <ogra_> davmor2, swap is still in ... we'll announce if we drop it <davmor2> ogra_: that's fine, Might be good to run some tests with it disabled again before we drop it. <ogra_> yes <ogra_> thats the plan <davmor2> ogra_: but not today <popey> davmor2: do you have a bluetooth headset? <davmor2> popey: I do it connects now but doesn't work <popey> ok <ogra_> pulse most likely <ogra_> missing profiles etc <popey> it breaks phone calls too <popey> for me, if I attach bluetooth headset, i can no longer make or receive calls <davmor2> ogra_: no I have a bug for the initial issue <ogra_> yeah, that points even more in pulse direction <popey> ok, will file a bug <popey> unless you know of one already? <davmor2> popey: see the spreadsheet <davmor2> that is one bug <popey> doesnt describe it <davmor2> for you it looks like another again though <popey> yeah <popey> k <popey> filing <davmor2> possibly just needs a profile like the wired headset <ogra_> right <popey> bug 1266738 <ubot5> bug 1266738 in pulseaudio (Ubuntu) "Bluetooth headphone pairing works, but no audio output - Mako #116" [Undecided,New] https://launchpad.net/bugs/1266738 <davmor2> didrocks: if I have an issue with a the layout of indicators what do I file the bug against? ie if you disable BT and then re-enable it from the setting and then drag down the BT indicator it is showing the Location settings <davmor2> I'm assuming unity8 <didrocks> davmor2: for those, I would say unity8 as well <didrocks> Saviq: hey, agreed? ^ <popey> davmor2: i filed one for that <popey> bug 1264678â <ubot5> bug 1264678 in Unity 8 "Incorrect indicator appears under correct indicator heading" [High,Triaged] https://launchpad.net/bugs/1264678 <davmor2> popey: thanks <davmor2> didrocks: mtp is still not working here for me <didrocks> davmor2: ok, so, this is a regression compared to latest published image? <didrocks> promoted* <sergiusens> fginther, hey, can you repo init from scratch? I see the jenkins build pulling in the prebuild kernels which I don't get when doing this from scratch <davmor2> didrocks: yeap happened I noticed it around build 100 <didrocks> davmor2: ok, do you know anyone else with a maguro who can confirm it's a maguro regression? <davmor2> didrocks: ignore that it's just kicked into life * ogra_ has a dejavu <ogra_> didnt we have that before ? <davmor2> ogra_: it seems really temperamental at the minute <ogra_> i cant confirm on my maguro <ogra_> works as it should <davmor2> ogra_: for me the icon shows as soon as I plug it in but nautilus never seems to open and I get the error message, works fine on my n7 running touch though <ogra_> davmor2, oh, i was commenting on the indicator stuff <davmor2> bingo seems to be working nicely no <davmor2> ogra_: ah yeah that was they were all jumbled before this is just if you remove one and then add it back again <ogra_> right, i just did that here <ogra_> and it works fine <davmor2> ogra_: to be honest I think it depends on the usage of the indicators etc, I'd just used the location indicator to turn on gps <ogra_> i switched bluetooth off and on several times <davmor2> ogra_: could just be a race condition maybe <ogra_> yep <davmor2> didrocks: right so mtp looks to be working here now just not as snappy as it was, this maybe down to the fact that I running a fresh saucy on this box rather than raring that was on it, or it maybe the changes that have been made to the upstart script, and the fact that it is maguro <davmor2> sergiusens: mtp and adb are still not getting on mtp is still kicking an adb session off <sergiusens> davmor2, are you sure it's mtp and not the start of android? <didrocks> davmor2: ogra_: popey: so let's wait for the test results, and if you +1, we can publish it <ogra_> yep <popey> +1 <davmor2> sergiusens: hmm could be I guess, but the action you see is adb shell is connected when mtp shows in nautilus it kicks the adb session <popey> (thats me +1ing you saying that, and also +1ing the image) :D <davmor2> didrocks: +1 looks good here only old issues nothing new <sergiusens> davmor2, well they are trigger almost at the same time <davmor2> sergiusens: it's the action of mtp displaying in nautilus when you see the adb get kicked though. Not the initial connection which I assume is instant (Ie when the icon appears on the launcher) <sergiusens> davmor2, do this, disable the mtp job and verify that you still get kicked out ;-) <davmor2> sergiusens: give me a minute * psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <davmor2> popey: in settings if you select backgrounds, then select different backgrounds for each, and set the home one to an image, and leave the welcome screen on the default what happens when you hit the power button a couple of times to show the welcome screen <popey> ugh, hate changing the background because it's a bitch to unset it * cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <fginther> morning <cyphermox> sergiusens: if that was the case then it would be a very out of date image <cyphermox> I haven't touched mtp since ... last year, and it's not my top priority right right now ;) <sergiusens> cyphermox, context? <cyphermox> sergiusens: mtp kicking off adb <sergiusens> cyphermox, oh, I'm saying that as well <cyphermox> doubtful that it's the case for a QA job. <sergiusens> cyphermox, i asked davmor2 to disable mtp for him to verify that this wasn't mtp kicking him off <cyphermox> yeah <davmor2> sergiusens: sorry just back from lunch give me 5. How do I disable the job from auto starting then, upstart is not a strong point for me :) <fginther> sergiusens, trying <sergiusens> davmor2, echo manual /usr/share/upstart/sessions/mtp-server.override <sergiusens> davmor2, add the missing > ;-) <davmor2> sergiusens: add the missing evil face ;) <sergiusens> lol <davmor2> sergiusens: meh forgot to enable write mode first D'oh <davmor2> tries again <sergiusens> davmor2, before ubuntu touch was trendy and everyone started using it, we even then had this problem; it started with the container switch <davmor2> sergiusens: ah okay we'll soon find out, and then just blame ogra_ if it is ;) (Bound to be his fault somewhere along the line ) <ogra_> oh, back then ... the good old times <davmor2> sergiusens: hmmm I set the override with echo manual > /usr/share/upstart/sessions/mtp-server.override and it still tried to connect mtp <davmor2> sergiusens: and that was after a reboot <cyphermox> well, the server won't be started but the device will still be registered as an MTP device, so you'll still get dialogs on your desktop <davmor2> cyphermox: ah okay <sergiusens> davmor2, the dialogs are a different story <davmor2> sergiusens: indeed :) <cyphermox> sounds very much like a case of android starting -- you probably still get kicked off of an adb session <sergiusens> it is <sergiusens> before: android booted first, android started adb; period <davmor2> right starting again unplugged the phone, reattached it, started adb shell <davmor2> still connected <sergiusens> after: ubuntu's init started adb; upstart started adb; android starts adb <cyphermox> sergiusens: now, ubuntu starts adb, android starts, android starts adb again, no? <davmor2> Yeap just got kicked <davmor2> so android starting is the issue then, is there a bug for that? <sergiusens> cyphermox, pretty much <davmor2> cyphermox, sergiusens ^ <sergiusens> davmor2, no; a workitem in a blueprint <davmor2> sergiusens: great okay thanks <sergiusens> fginther, btw, can we get merger for lp:usensord now? Sorry if I missed an ETA about this <fginther> sergiusens, I'm still working on it, the x86 box is not upgrading to saucy well <fginther> should be working by tomorrow <sergiusens> ah, great; thanks <dobey> didrocks: https://wiki.ubuntu.com/DailyRelease/InlinePackaging is guidelines, not strict rules, right? <cyphermox> dobey: not strict rules but if you follow them it works better and makes it easier for us to help you out with daily release if necessary <cyphermox> most are there as safeguards so that regressions are readily apparent, etc. <dobey> right <cyphermox> for instance, export DPKG_GENSYMBOLS_CHECK_LEVEL = 4 <dobey> yes, which i do <kenvandine> cyphermox, dobey is also pretty opposed to split mode <dobey> but native vs. bzr-builddeb split mode packaging is not part of that <cyphermox> *shrugs* <dobey> neither one is going to make any regression any more apparent, or make changes easier to review. it's something you do at the beginning and generally adhere to <dobey> and the wrap-and-sort, or annoying vcx-bzr comment don't make avoiding regressions any easier <dobey> or more apparent <cyphermox> no, they make maintenance easier <dobey> easier in some cases, yes <dobey> but having dependencies already sorted, and on separate lines, isn't made more readable or easier to manage, by having them spaced out an arbitrary number of spaces based on the name of the field they're in <cyphermox> I fail to parse that line, and busy with too much state to try harder <cyphermox> dobey: in general, we'd just rather you follow those guidelines to make it easier for us to work with your branch and help you with daily-release <dobey> and the comment about vcs-bzr is just silly because the whole point of daily-release is that people don't just upload changes directly into the archive. <cyphermox> dobey: in some cases it's necessary to <cyphermox> we don't want to make it so people absolutely can't land time-critical changes <dobey> are those cases documented anywhere? because the InlinePackaging wiki page sure makes no reference as to why that comment should be there, or what those cases are <kenvandine> dobey, remember there are core devs and motus that sponsor patches, etc <kenvandine> so sometimes upload directly <kenvandine> when that happens, we have to backport those to upstream <cyphermox> dobey: the comment is just a comment. omit it if you prefer <dobey> kenvandine: would it not be better to communicate that such uploads shouldn't happen (unless an absolute emergency requires it), and that changes should be donea s merge proposals to the upstream branch? <kenvandine> they are rare <kenvandine> and that comment could help show people where their changes belong <kenvandine> not all ubuntu developers are bzr users <kenvandine> old school :) <popey> didrocks: 116 looks good for tests.. <kenvandine> believe it or not... there are still people that seem to like using quilt <dobey> kenvandine: the comment may also be lying. i don't want people to assume that just because they uploaded something to the archive, that it will definitely be an accepted change upstream. because it makes no sense * kenvandine hugs packaging with bzr <dobey> well, using quilt is great for packaging things you don't actually own, when you need to make changes to them <kenvandine> dobey, ah... but we'll catch that quickly <kenvandine> the daily release machinery would flag the package for having an uploaded change that isn't in trunk <kenvandine> which we would then propose a branch for <kenvandine> which could get rejected <dobey> right. but i think there are too many potential points of human error in that process. <kenvandine> i don't think we can reduce that any more than we have already <dobey> well, it's going to happen regardless of whether that comment is there or not <dobey> and the Vcs-Bzr is there, so anyone with upload privileges should know to use it <cjwatson> we've had at least two major projects that were sufficiently short-duration that we didn't have time for uploads to go through daily release, just recently; you should certainly assume such things will continue to happen <kenvandine> indeed <cjwatson> when you're trying to get thousands of packages to build you don't have time to cope with a small fraction of them being special snowflakes :) <kenvandine> and we have process in place to keep from uploading over those <cjwatson> kenvandine: it's just a shame we can't use git-dpm (yet ...) <dobey> not using git is a win in my book <cjwatson> I'm not git's biggest fan, but git-dpm is light-years ahead of anything bzr can offer <kenvandine> i've never tried it, but i do love bzr bd :) <cjwatson> And with bzr basically being a dead project, the git ecosystem is only going to get further ahead :-/ <xnox> dobey: kenvandine: until trunk matches distro, always, it hurts everyone to be able re-arrange / prioritise which sets of changes get in. At the moment one can only land trunk, and if it has 10 features 1 bugfix 1 packaging-fix, one cannot land any part without other two. <cjwatson> (Similarly, dgit was fundamentally more reliable one week into development than UDD can ever be) <xnox> dobey: kenvandine: i had to resort at times getting packaging fixes merged into trunk, cherrypicking & uploading into distro, and then merging back the "cherrypick" debian/changelog entry to keep everything in "sync" <kenvandine> xnox, yeah, there are quite a few cases where this is necessary <xnox> dobey: kenvandine: in this sense dgit rules, as it's a hard requirement for dgit/trusty branch match the archive. And then one is free to stage any amount of branches and one gets the hand over the trigger which sets of changes to simultaniously push to central repository as dgit/trusty branch with a matching dput into the archive. <dobey> and still not relevant to whether something should be a native package, or use split mode in bzr-bd <fginther> sergiusens, here's a build from scratch (on raring): http://s-jenkins.ubuntu-ci:8080/job/ubuntu-touch-image-builder/15/console <fginther> sergiusens, still failed with the vmlinuz problem <sergiusens> fginther, don't know how your sync is fetching the ubuntu/prebuilts/* <sergiusens> did a sync from scratch this morning and didn't get that pulled in * cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <sergiusens> fginther, oh, it's just cloned, but not added; was chsing the wrong thing <didrocks> dobey: split mode is mandatory for the whole system to work <didrocks> dobey: as we already talked about before holidays <didrocks> dobey: vcs-bzr is to be nice for other packagers, but I don't really care <didrocks> dobey: I hate wrap-and-sort, but that's a personal taste, it's not a blocker <didrocks> dobey: but following the same guidelines everywhere help when other touches other packages <Laney> are the mergers not merging? <dobey> didrocks: i thought native would be fine? if native doesn't work that seems like a bug in the system (the stuff that deals with the the versioning) <didrocks> dobey: can counted as a bug, but nobody is going to change that AFAIK <didrocks> dobey: as some people want to have upstream tarballs for other distros <dobey> didrocks: i certainly agree on that last one, but i don't think doing things consistently wrong is good, even if it is consistent and easy. and i think split mode is wrong. <didrocks> dobey: so right now, following the same for everyone is better <dobey> didrocks: i wouldn't say it's better. i'd say it's consistent <kenvandine> dobey, consistent == better :) <didrocks> dobey: it's not wrong, some people may argue that they don't want to publish native natives <didrocks> well s/may argue/were arguing/ <dobey> didrocks: arguing that one wants to have tarballs for release on other distros doesn't make split mode correct. "correct" would be to have debin/ not be in tree in those case, or to at the very least fix the system to create proper upstream tarballs and not use split mode as a way to get that. yeah, it works, but it's still not "correct" :) <didrocks> dobey: it's consistent at least and part of our requirements <dobey> need to get lunch, bbiab <didrocks> Laney: the upstream merger is disabled for system-settings as I requested it. You are part of "THE" prototype :) <Laney> O_O * ogra_ hands Laney some salad and other guineapig food * Laney hides under ogra_'s sofa * ogra_ sends the cat <Laney> /nick pinocchio <ogra_> heh <Laney> didrocks: what does this mean for us? :-) <xnox> Laney: see ubuntu-phone mailing list =))))) you get to land your own stuff. <didrocks> Laney: you're screwed! :) <kenvandine> :-D <didrocks> Laney: more seriously, in a call, will tell you afterwards :) <xnox> Laney: invoking ogra was a good move ;-) <Laney> while(true) ogra(); <ogra_> hah <xnox> Laney: Ooh, showing off C99 skillz ;-) <ogra_> didrocks, i thought you guys use the UI for image builds now <didrocks> ogra_: oh, we do <didrocks> but holidaysâ¦ ;) <didrocks> ogra_: want me to do it? <didrocks> ogra_: not having feedback isn't really great though <didrocks> (in the UI) <ogra_> didrocks, yeah, agreed, someone should improve it <didrocks> ogra_: did you poke it or should I? <ogra_> go ahead <didrocks> ok doing :) <didrocks> ogra_: for promotion, you are still in line though ;) <ogra_> yeah, np <didrocks> build 117 requested <didrocks> Laney: so, yeah, you will be in the pilot program :) <didrocks> Laney: did you read asac's email on the phone ML? <Laney> yes I've seen it and the slides <Laney> but it talks about setting up checklists and stuff which I don't think we did <didrocks> Laney: yeah, we are trying the landing part for now <seb128> Laney, in summary they want to stop automerging to trunk for approved mps, but have a "coordinator" picking branches to land and making a mp with those, throwing that to a ppa (using a tool provided by CI), testing the result and acking through the tool <Laney> I see <seb128> then that "set" would land in distro and be merged back in trunk <didrocks> we need to open the publication to core-dev btw <didrocks> so that for core-dev, there is no more landing team involved at all <Laney> nice <Laney> the meeting thing would probably put me off :P <Laney> anyway, hope it all works <didrocks> Laney: it works on my machine, is that enough? :p <Laney> sounds like the gold standard to me <Laney> ship that bad boy <didrocks> \o/ <asac> Laney: those checklists are TODOs for engineering teams <asac> Laney: so you should self-impose what you want to do... as long as there is something reasonable you qualify for doing landings on your own <asac> the checklist and testplan will then be improved as we go <ogra_> === image 116 promoted === <balloons> ping doanac :-) Can you by chance re-run a merge job for me? It looks rather suspicious <balloons> https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906 <doanac> balloons: looking now <dobey> cihelp: can someone please do a rebuild of http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-ci/564/rebuild ? the job results links in the MP comment are giving 404s :( <doanac> dobey: looking <fginther> dobey, that job has been purged, do you have the MP or something that triggered it? <dobey> fginther: https://code.launchpad.net/~diegosarmentero/ubuntu-system-settings/click-updates/+merge/195729 <fginther> dobey, that'll work. <dobey> thanks. just want to see why the builds failed, but 404s don't tell me much :) <doanac> balloons: http://s-jenkins:8080/job/ubuntu-ui-toolkit-autolanding/543/console <balloons> bah, I lost my vpn setup.. grr <balloons> doanac, what's it say? <doanac> balloons: its just running now. i'll let you know <balloons> kk <doanac> dobey: your job was retriggered about 10 minutes ago. I'll let you know how it goes: http://s-jenkins:8080/job/ubuntu-system-settings-ci/571/console <doanac> dobey: oops - already failed: http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-trusty-amd64-ci/87/console <dobey> thanks <dobey> kenvandine: can you try to trigger an ubuntu-purchase-service build into the daily ppa again now? <kenvandine> dobey, did you guys work out the packaging? <kenvandine> we need it split mode to let it get published <dobey> no. i'd like to see if it's going to give the same error though. it was in "split mode" yesterday. now it isn't. <fginther> balloons, can you approve https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906? The tests pass, but it can't merge without being approved (and I don't have permission) <kenvandine> http://paste.ubuntu.com/6710757/ <kenvandine> pile of MP for all the out of sync packages <kenvandine> if anyone wants to help review them :) <kenvandine> dobey, ok, let me kick off a build <balloons> fginther, I too don't have superpowers for that one <kenvandine> robru, have you proposed a branch to bring the packaging inline with our practices? <dobey> kenvandine: he has not <kenvandine> http://paste.ubuntu.com/6710796/ <kenvandine> dobey, same failure <kenvandine> dobey, i bet because it has a native package version :) * kenvandine ducks <dobey> kenvandine: i bet because the cupstream2distro code is broken :) * kenvandine whistles <kenvandine> anyway... i gotta run to lunch <kenvandine> robru, don't forget to throw that packaging back to dobey :) * kenvandine runs
{'channel': 'ubuntu-ci-eng', 'month': 1}