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