=== tvoss|otp is now known as tvoss|easter [08:10] hey sil2100 ;) good work! for yesterday [08:36] didrocks: hi! Thanks, wouldn't do it without cyphermox ;) [08:36] :) === andyrock is now known as andyrock|out === andyrock|out is now known as andyrock === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik === alan_g is now known as alan_g|lunch [13:11] * mterry is surprised to see that daily builds actually landed last night for the unity stack. Our luck day! [13:24] mterry: I had to work on it :/ [13:24] mterry: UTAH failed [13:26] didrocks, ah, well, it was a nice few minutes of thinking things worked [13:26] :) [13:26] mterry: btw, I'm still working on having the 2 releases in parallel [13:26] mterry: so head is still disabled [13:26] didrocks, and it seems that Head correctly didn't run last night? yup [13:26] (commit counting and so on) [13:26] mterry: it correctly didn't run rather :p [13:27] mterry: also, even if I reenable it, remember that all the branches are disabled ;) [13:27] until you https://wiki.ubuntu.com/DailyRelease/MovingNewRelease#Diverging_.22trunk.22_and_a_.22maintenance.22_branch [13:27] in accordance with upstream [13:40] didrocks ...i'm building unity/phablet...hadn't had a problem...but, now when i run setup (for updates) its saying temp failure to resolve 'ports.ubuntu.com' [13:40] kgunn: hum, what is setup? :-) [13:41] didrocks: setup is just an option on the build to update dependencies on the device [13:41] (or that is one step anyway) [13:41] didrocks: and i shouldn't say build...its actually run_on_device script [13:43] kgunn: do you have the script somewhere? that would help me know what this is trying to do [13:44] didrocks: http://bazaar.launchpad.net/~unity-team/unity/phablet/view/head:/run_on_device [13:44] i think its this line exec_with_ssh $SUDO apt-get -y install build-essential rsync bzr ccache [13:45] didrocks: normally i would suspect i did something stupid :) [13:45] kgunn: I don't think you are the guilty, ports.ubuntu.com is available here [13:46] kgunn: but looking at the script I would do some modifications [13:46] like exec_with_ssh $SUDO apt-get -y install build-essential rsync bzr ccache [13:46] avec the apt-get update line [13:46] for instance [13:46] kgunn: can you do that and relaunch? [13:46] didrocks: i actually thot maybe it was the script....so i opened shell on the device (ubuntu_chroot shell) [13:47] didrocks: did apt-get update [13:47] didrocks: and it still said "couldn't resolve" [13:47] during the apt-get update? [13:47] didrocks: right [13:47] do you have network on your device? [13:47] like if you ping google? [13:47] didrocks: let me check that... [13:48] didrocks: should've done that prior... [13:48] :) [13:48] no worry ;) [13:48] but yeah, ports.ubuntu.com is working, the archives are accessible [13:48] didrocks: dammit...thing had network a minute ago...sorry [13:48] :) [13:48] no worry at all ;) [13:49] didrocks: couldn't see forest for the trees [13:49] kgunn: well, another eye generally help for that! :) [13:49] didrocks: and so much for my overpriced verizon fios router ! [13:50] flakey piece of junk [13:50] kgunn: sometimes, the "boxes" we have in France are a blessing TBH. No need for another router, pretty reliable… cheap Internet [13:50] at least this thing is positive :) [13:51] didrocks: good ol' americans...figure out how to charge a premium for something that "sort of works" :) [13:52] kgunn: how to say without being rude that I'm not surprized? :) [13:53] didrocks: :) [13:55] didrocks, I wouldn't be worried about _sounding_ rude... seems impossible for French [13:55] didrocks, let's say a package has typical autopilot tests in tests/autopilot. What do you expect to see in that second-to-last column on that touch spreadsheet [13:56] olli: tsssss, how ironic after the "excuse my French" and other similar expressions I'm hearing ;) [13:57] never made sense to me [13:57] ;) [13:57] heh ;) [13:57] mterry: the package name shipping those autopilot tests (so -autopilot for instance), all the required packages to run it (maybe a manual run on a guest session for ensuring it's working is best) and the command that needs to be run to start them [13:57] mterry: making sense? [13:59] sil2100: FYI, everything is now published [13:59] sil2100: I just promoted in raring-proposed appmenu-qt5 and dbusmenus-qt5 to main [13:59] (as they are installed by default) [13:59] didrocks, yeah [14:01] didrocks: me and fginther are wondering if this is good to go: https://code.launchpad.net/~mrazik/cupstream2distro-config/webcred/+merge/155541 [14:02] mmrazik: should check with kenvandine, and upstream if they agree with moving their branches now === alan_g|lunch is now known as alan_g [14:02] mmrazik: you have duplicated btw [14:03] like target_branch: lp:libaccounts-qt [14:03] in raring [14:03] libaccounts-qt: [14:03] in head [14:03] oh [14:03] sorry, it's in to_transition [14:03] to yeah, excellent, just ensure with kenvandine and upstream that their branches moved :) [14:03] didrocks: do we actually need to check something with upstream? Can we just move stuff from to_transition as upstream creats the branches? [14:03] so upstream needs to create branches for raring right? [14:04] mmrazik: I mean, checking for the /13.04 branches [14:04] didrocks: but can't that be done independently? I.e. the current merge proposal should just work or not? [14:04] and as soon as we have 13_04 we would move stuff out of to_transition [14:04] didrocks, but we don't have to have those branches... [14:04] let me rephrase: [14:04] target_branch: lp:account-plugins/13.04 [14:04] for instance [14:04] until upstream needs them for some reason [14:04] you need to ensure upstream wants and has a lp:account-plugins/13.04 [14:04] right [14:05] that's what I mean :) [14:05] fginther: mmrazik: ^ [14:05] ok, so we don't need to create those branches for everyone project :) [14:05] just as needed [14:05] * mmrazik still confused [14:05] do I need to do anything? [14:05] * kenvandine is too [14:05] i think [14:06] * fginther confused +1 [14:06] so my idea with that MP was the following: [14:06] upstream has created lp:account-plugins/13.04 [14:06] -everything from head/webcred.cfg will be ignored except account-plugins [14:06] but not for others yet, because they haven't needed to [14:06] we will have autolanding jobs for lp:account-plugins [14:06] so, if upstream has created lp:account-plugins/13.04, fine [14:06] the MP is good [14:06] that what just the thing I wanted to ensure ^ [14:06] ok [14:07] - evreything in raring/webcred.cfg will be used to generate autolanding jobs [14:07] * kenvandine isn't confused anymore [14:07] :) [14:07] mmrazik: so yeah, you can go ahead :) [14:07] for account-plugins an autolanding job for lp:account-plugins/13.04 will be create [14:07] right :) [14:07] didrocks: oh [14:07] didrocks: understood [14:07] we just won't autoland anything else for raring, since they don't have 13.04 branches [14:07] trunk will go to head [14:07] kenvandine: the elements have daily_release: False [14:07] so they won't autoland [14:07] right [14:07] in this case [14:08] i was thinking bigger picture :) [14:08] uh oh [14:08] apart from signon-keyring-extension: of course ;) [14:08] we are overloading the "autoland" term [14:08] mmrazik, yes.... yes we are [14:08] mmrazik: that's part of the issue for quite some months :) [14:08] hence I'm talking about [14:08] shall we talk about about "autoland" and "upstream merge"? [14:08] "upstream merge" [14:08] ack [14:08] and "daily release" [14:08] ok [14:08] we need a new term :) [14:09] kenvandine: let's avoid the confusing term :-) [14:09] didrocks: so I'll top approve that merge proposal and will generate the jobs [14:09] automerge and autopackage? [14:09] fginther: ^^ [14:09] mmrazik: perfect ;) [14:09] mmrazik, ack [14:09] kenvandine: that works too [14:09] and stop using the term autoland complete [14:09] +ly [14:09] +1 [14:09] so if we here someone use the term, we know they are confused :) [14:10] kenvandine: so you don't really need to redeploy, as all the changes are either in to_transition or daily_release = False [14:10] (for autopackage) [14:10] didrocks, libhybris isn't in the touch blueprint. Are we upstream for that? [14:10] didrocks, and what do you mean by redeploy? [14:10] :) [14:10] we need a dictionary of terms here :) [14:10] mterry: it's on that one: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-ubuntu-touch-porting [14:10] mterry: because yeah, we are not upstream for it [14:11] kenvandine: did you read my wiki page I pointed the other day? :) [14:11] there are even links! === jono is now known as Guest21379 [14:11] yes [14:11] kenvandine: https://wiki.ubuntu.com/DailyRelease/MovingNewRelease#Deploy_both_stacks_you_modified [14:11] didrocks, OK, so I'll just put that in our PPA then [14:12] mterry: yep ;) [14:17] \o/ [14:39] didrocks, since the platform stack isn't deployed yet, i am just updating the stack in head removing the to_transition, and disabling it in raring until they have a branch for raring [14:39] didrocks, does that make sense? [14:45] kenvandine: we can still have daily release for it in raring, you think? or it will never happen? [14:45] maybe [14:45] i need to talk to them about maintaining a bug fix branch for raring [14:45] so, keep it like that for now, and let's see once we are sure :) [14:46] i am sure they are going to want fixes to land in raring [14:46] we can deploy it after the fact [14:46] ok... so keep it for raring and go ahead and deploy? [14:46] kenvandine: hum, why do you want to deploy it until it's ready? [14:47] i am anxious to get it deployed :) [14:47] I don't get it :) [14:47] if it's not ready for daily release [14:47] i figured letting it release to next would be a good start [14:47] not to raring :) [14:47] but trunk is ready? [14:47] bootstrapped, etc? [14:47] it just needs the bootstrap commit [14:47] we have integration tests running? [14:47] which i wanted to do today [14:47] yes [14:48] ok, fine by me to go that in head then [14:48] kenvandine: so bzr rm it on raring [14:48] ok, i figured better to start with head and not enable daily release on raring [14:48] ok [14:48] to avoid catastrophees ;) [14:48] indeed [14:48] ok [14:48] FYI [14:48] #schedule: 0 3 * * 1-5 [14:48] it's disabled by default [14:48] kenvandine: I'm still working on cupstream2distro to support parallel release [14:49] (in term of commits collect) [14:49] terms* [14:49] kenvandine: so you won't have it yet, but soon, I hope to finish on Monday [14:50] ok === mmrazik is now known as mmrazik|afk === alan_g is now known as alan_g|tea [16:08] mterry: btw, I've fixed and tested a bug (due to multiple manual uploads) that prevented unity-asset-pool to release its last commit. It was a new icon for 100scopes, do as you wish (it's not used, so technically doesn't break UIF) [16:09] mterry: just be prepare if infinity is going to close the archive as he told on the email in 12 hours that the manual review otherwise will reject it :) === alan_g|tea is now known as alan_g [16:17] didrocks, awesome. You mean it will land next time unity stack runs? [16:18] mterry: yep, so either you can do it today, or you can see what they will tell if infinity is going to freeze the archive :) [16:18] didrocks, might as well try today [16:18] great ;) [16:18] didrocks, I thought freeze was yesterday though [16:19] mterry: read ubuntu-devel (ML) [16:19] didrocks, I hate reading [16:19] mterry: but but… you read my "read ubuntu-devel (ML)" [16:19] mterry: I'm puzzled, afraid and lost now :p [16:20] didrocks, i actually don't see it [16:20] will check archive [16:21] oh [16:21] it's in ubuntu-release ML [16:21] mterry: sorry ^ [16:21] (they just end up in the same folder) [16:23] sure === mmrazik|afk is now known as mmrazik === mmrazik is now known as mmrazik|afk [17:59] hi, can anyone here tell me how I can run the tests in the compiz package? [17:59] (trying to fix a bug I filed a while back, and wanting to do it right with a new test case) [18:03] the package has a build-dep on libxorg-gtest-dev, but seems to be completely unused... debian/rules overrides the dh_auto_test target, but dh_auto_test doesn't do anything anyway... [18:03] slangasek, in your build dir for compiz, you should be able to do make test [18:11] bschaefer: hmm; why is this not being done by default in the package build? Also, there seem to be some bits missing wrt gtest support (-DCOMPIZ_BUILD_TESTING=OFF, google-mock not a build-dependency), is this relevant? [18:12] right, so it seems that after twiddling both of those things, the tests are building [18:12] but I wonder why that's off by default [18:13] slangasek, hmm im not sure why its turned off by default, smspillaz or didrocks would be ones that would have a better answer for that :) [18:13] ok === bschaefer_ is now known as bschaefer