[05:00] <lotuspsychje> good morning to all
[05:00] <kostkon> gm
[05:00] <lotuspsychje> hey kostkon
[05:00] <kostkon> hey
[05:01] <lotuspsychje> http://www.omgubuntu.co.uk/2017/06/improved-ubuntu-hidpi-support-in-gnome
[05:04] <lotuspsychje> big updates this morning
[05:04] <lotuspsychje> !info linux-image-generic xenial
[05:05] <lotuspsychje> https://www.ubuntu.com/usn/USN-3304-1/
[06:35] <lordievader[m]> Good morning
[09:32] <BluesKaj> 'Morning folks
[12:31] <pauljw> Hi everyone
[12:32] <BluesKaj> Hi pauljw
[12:33] <pauljw> hey BluesKaj :)
[13:25] <brunch> http://www.omgubuntu.co.uk/2017/06/ubuntu-17-10-daily-builds-gnome
[14:04] <EriC^^> hi all
[14:08] <pauljw> hi EriC^^
[14:09] <EriC^^> hi pauljw :)
[14:09] <EriC^^> how are you?
[14:10] <pauljw> doing great, you?  :)
[14:10] <BluesKaj> hey EriC^^
[14:11] <EriC^^> pauljw: good thanks :)
[14:12] <EriC^^> hey BluesKaj :) how's it going?
[14:12] <BluesKaj> good thanks EriC^^ , and you?
[14:12] <EriC^^> BluesKaj: good thanks
[14:15] <BluesKaj> got a spot of bother at #ubuntu , this stevenguy is stuck on dpkg --configure = , but doesn't want to kill it
[14:15] <BluesKaj> dunno what he wants
[14:17] <BluesKaj> tire of "attitude types" who ask for suggestions then object to each one d
[14:19] <BluesKaj> beyond my scope anyway
[14:23] <lotuspsychje> good afternoon to all
[14:23] <BluesKaj> hey lotuspsychje
[14:24] <lotuspsychje> hey BluesKaj
[14:25] <EriC^^> hey lotuspsychje
[14:25] <EriC^^> what's up?
[14:25] <lotuspsychje> hey EriC^^
[14:25] <lotuspsychje> worked a bit in the garden today
[14:25] <lotuspsychje> and shopping
[14:25] <lotuspsychje> morning nacc
[14:27] <lotuspsychje> http://www.omgubuntu.co.uk/2017/06/ubuntu-17-10-daily-builds-gnome
[14:29] <nacc> lotuspsychje: morning
[14:29] <lotuspsychje> http://www.omgubuntu.co.uk/2017/06/ubuntu-decides-replace-lightdm-gdm
[15:31] <lotuspsychje> bbl guys
[15:55] <immu> BluesKaj, hey
[16:02] <BluesKaj> hi immu
[16:18] <akik> i fail to understand the reasons for changing from lightdm to gdm. gnome 3 works just fine with lightdm
[16:23] <immu> whatsup BluesKaj
[16:23] <immu> is their a technical discussion about switching to GDM at launchpad
[16:26] <akik> i just saw the url lotuspsyche pasted
[16:26] <akik> 17:29 < lotuspsychje> http://www.omgubuntu.co.uk/2017/06/ubuntu-decides-replace-lightdm-gdm
[17:21] <immu> akik, true, but they must have had some documented discussion about it, that what i am interested in
[17:27] <immu> i got it i got it
[17:27] <akik> ah it's on lists.ubuntu.com
[17:27] <immu> https://lists.ubuntu.com/archives/ubuntu-desktop/2017-June/004969.html jbca
[17:27] <akik> yes :)
[17:28] <akik> i press ctrl-alt-l in gnome and get a lock screen
[17:29] <akik> i'm not getting what he means with "and using GNOME Shell as a LightDM Greeter"
[17:29] <akik> i'm using the stock lightdm from kubuntu 14.04
[17:35] <oerheks> BluesKaj, he has an odd lightdm situation, i could not make sense out of it too..
[17:35] <oerheks> maybe not running ubuntu at all..
[17:36] <BluesKaj> he's on ubuntu the DE command showed that , but I think he had a screwup on his nvidia update/install
[17:37] <BluesKaj> and he blames lightdm which isn't the real problem IMO , but I'll let those who think they know better sort it out
 BluesKaj, should I first try to reinstall ubntu-desktop using ....
[17:38] <oerheks> here it comes ...
[17:38] <oerheks> sudo apt-get install --reinstall gnome-session ubuntu-desktop
[17:38] <oerheks> gnome-session?
[17:39] <BluesKaj> now they have him reinstalling systemd
[17:42] <akik> immu: there's more discussion at https://lists.ubuntu.com/archives/ubuntu-desktop/2017-April/thread.html
[17:44] <brunch> oof crazy
[17:44] <brunch> whenever I stumble upon these wild problems, I just grab a new image and format
[17:45] <oerheks> it used to be no problem, 2 desktops on same kernel install
[17:45] <oerheks> nowadays i seperate installs, too much unwanted situations indeed
[17:46] <oerheks> maybe the switch to pure snap packages will fix this
[17:46] <akik> why do they mix desktop settings/configurations? they = ubuntu devs
[17:47] <oerheks> it is not that easy to blame, wish it was :-(
[17:48] <oerheks> but then again, it is nice to have something to work out
[17:48] <immu> akik, thanks
[17:48] <akik> kde plasma 4 and gnome 3 seem to play nice
[17:52] <BluesKaj> i stick with kde/plasma. no other DEs needed...begining to think i should stay away from the #ubuntu chat...dunno enough about the changes and their consequences with the other DEs
[17:55] <akik> immu: https://lists.ubuntu.com/archives/ubuntu-desktop/2017-April/004886.html the lightdm founder writes about negative sides in gdm: "- no significant tests (make check runs one thing from 2007)"
[17:55] <akik> that can't be true
[18:05] <immu> well what ever the case maybe they are switiching to GDM
[18:11] <BluesKaj> say that in #ubuntu and see how many corrections you get
[18:13] <BluesKaj> oerheks, from what i can see they still haven't found a solution to the lightdm issue ...now they have him reinstalling the OS
[18:19] <oerheks> BluesKaj, did anyone ask what the other OS is, dualboot ?
[18:20] <BluesKaj> windows I think
[18:26] <immu> so GDM is it folks :) bravo :)
[18:30] <BluesKaj> ahh know it alls, they're so sure of themselves until their ideas beginb to fail then they blame the helpee
[18:31] <nicomachus> what's the lightdm issue?
[18:31]  * nicomachus hasn't noticed anything...
[18:32] <BluesKaj> lightdm doesn't load, the user has to start it in the vt/tty
[18:32] <nicomachus> oh. no problems here...
[18:32] <nicomachus> but I have some sort of bastardization of lightdm/gdm going on here.
[18:32] <BluesKaj> this is old news, now they have hi reinstalling the OS
[18:32] <nicomachus> ever since I installed gnome.
[18:33] <BluesKaj> yup, that appears to be the case with this one too
[18:34] <nicomachus> like, I get the gdm/gnome animation on boot, but then log in through lightdm. but if I lock the screen, it gives me the gdm lock screen
[18:34] <nicomachus> I should probably just remove lightdm.... but I'm lazy
[18:38] <BluesKaj> heh
[18:41] <immu> i am wating for offical release of 17.10 to upgrade , wont like to mess with  my system right now
[19:06] <nicomachus> https://www.sudosatirical.com/articles/police-standoff-outside-house-of-man-not-in-sudoers-file/


[00:10] <wgrant> spm: Around? bug #514074 has been going on for a few days now, and I think it's probably a sysadmin/LOSA thing.
[00:10] <mup> Bug #514074: PGP fingerprint registration fails to find key <pgp> <Launchpad Foundations:New> <https://launchpad.net/bugs/514074>
[00:11] <spm> hrm. I have a sneaking suspicion I may know what's causing that....
[00:11] <wgrant> Is keyserver.internal not syncing with the rest?
[00:42] <didrocks> do you know if there is some plan to upgrade the launchpad bzr branch to fix bug #513432? (I'm stuck for installing LP on lucid to expose some new element on the API)
[00:43] <mup> Bug #513432: AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo' <fetch> <Bazaar:Fix Released by mbp> <Bazaar 2.0:Invalid> <Bazaar 2.1:Fix Released by mbp> <Launchpad Bazaar Integration:Confirmed for mwhudson> <https://launchpad.net/bugs/513432>
[01:03] <james_w> didrocks: you can't work around it?
[01:07] <didrocks> james_w: I guess I have to init-repo 0.92 format, right?
[01:07] <didrocks> so, change the lp-rocket script?
[01:08] <james_w> didrocks: I'll find you.
[01:08] <didrocks> james_w: thanks, just one sec, getting some coffee right now :)
[01:09] <wgrant> I can't see which branch would be problematic, though.
[01:10] <wgrant> spm: Any luck? (I suspect this will affect me tomorrow, so I'm fairly interested)
[01:10] <spm> wgrant: not yet unf; I'm about 2-3 layers down in higher priority interrupts atm. sorry... :-/
[01:11] <wgrant> Ah, right.
[02:04] <mwhudson> well, getting online in town was a bit more of an adventure than i expected
[03:58] <abentley> mwhudson, surprised.  The nets were favourable at LCA.
[03:58] <mwhudson> abentley: yeah, it was a bit strange
[03:58] <mwhudson> abentley: i'm now in the library about 150m from the lca venue and it's working fine :)
[03:59] <abentley> :-)
[04:01] <mwhudson> i had a 70000 (yes 70 seconds) ping to python.org from the other place i tried
[04:08] <wgrant> Does Wellington's Internet somehow break when it no longer has the extra load of 700 geeks?
[04:14] <mwhudson> it's possible the access points got rebooted more aggressively that week or something
[04:20] <mwhudson> right, time to go and see some dotty art
[04:26] <MTecknology> 150m ??
[04:26] <MTecknology> I'm getting ~30kb/s between my two systems trying to doanlowd ~200MB
[06:08] <kfogel> Anyone here who can do UI review?
[06:21] <kfogel> stub: if code review has approved https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report, and martin's UI review said "need fixing" but then I fixed all the things he said need fixing, is it okay to land it?
[06:21] <kfogel> stub: my intuition is yes, but I don't want to step on any toes.
[06:22] <stub> Need Fixing means they want to see it again.
[06:22] <kfogel> stub: thanks.  Second question is finding someone who can do UI review right now, then :-).
[06:22] <stub> You can get Approved conditional on changing stuff
[06:22] <stub> That wouldn't be me then :)
[06:23] <kfogel> stub: ah, I see.
[06:23] <kfogel> yeah, I wonder if the dev wiki lists ui reviewers, let's see...
[06:26] <kfogel> stub: https://dev.launchpad.net/ReviewerSchedule   pretty much everyone is EU/Americas right now.  Oh well.
[06:29] <kfogel> spm: okay, ready for some questions.  http://paste.ubuntu.com/368019/ lists five branches, in various states of review (some can be landed now, some need review or re-review first).  For the purposes of argument, let's say they're all approved already, so we can focus on the mechanics of landing.  Three of the branches are against devel, two are against db-devel.  The goal is to have the total (all five) live on staging.  Would I land
[06:29] <kfogel>  the three devel ones on devel, the two db-devel on db-devel, and then... anything special to do after that?
[06:30] <kfogel> I see I stumped him :-)
[06:30] <spm> yup
[06:30] <spm> I think I know the answer, just confirming :-)
[06:34] <spm> ahh this is what I was looking for. it's moved. https://dev.launchpad.net/Trunk
[06:34] <spm> yup. land on devel 1st; when that gets thru to db-devel; land against db-devel. from a high level.
[06:34] <wgrant> Is there any point in landing the first one separately?
[06:35] <spm> so it gets to edge?
[06:36] <spm> or is your meaning; why not merge the 1st 3 into one mega merge?
[06:36] <wgrant> It's not clear that the second and third are related, but they both include the first so landing it separately seems pointless.
[06:37] <spm> ahh. that'd be code issues - /me hands that Q back to kfogel :-)
[06:38] <kfogel> spm: one of these db-devel branches has no dependencies on the others, and is approved.  I assume I can land that one now, right?
[06:39] <kfogel> wgrant: as for how to land them, yes, I may do it all as one mega merge.
[06:39] <kfogel> wgrant: point is, they all need to be approved first -- separately.
[06:39] <kfogel> spm: specifically, https://code.edge.launchpad.net/~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort/+merge/18446  seems approved.  I'm not sure it's landed yet.  I know it passes tests because I just ran them on a mega-integration branch :-).
[06:40] <kfogel> if it hasn't landed, I'm going to land it
[06:40]  * kfogel issues fair warning
[06:40] <spm> kfogel: ...
[06:41] <spm> kfogel: yeah that looks fine; stub's given the nod and he's the one I know needs to care about db-devel landings
[06:41] <kfogel> spm: oh, wait, I forgot to mention that there are *slight* conflicts (trivial) between some of these branches.  I already resolved them once in my integration branch, so I may just land that when the time comes.
[06:41] <spm> oh?
[06:41] <spm> being ware that if BB can't merge; it'll reject
[06:42] <spm> heh (evil grin ON) much a losa does when doing a manual merge.....
[06:42] <kfogel> spm: what does "can't merge" here mean?  If I've resolved the conflicts in my mega-integration branch, and that's the branch I land, then it's okay, right?
[06:43] <spm> kfogel: rephrasing - if you submit a branch; and "something/one" goes to merge against their version of the code; and it fails. Boom.
[06:44] <kfogel> spm: sure.  But I don't see why it would fail to merge, in this case, that's all.
[06:44] <spm> ie. you need to verify your branch (whichever one you submit) works as a merge against, eg, db-devel
[06:44] <kfogel> spm: *nod*
[06:44] <spm> so if it has a trivial conflict; it's still a conflict
[06:44] <spm> kinda thing....
[06:45] <kfogel> spm: sure, but I resolved those (on the integration branch)
[06:47] <spm> sweet, shouldn't be a problem then. and we can all igore the last 5 minutes of conversation. :-D
[06:48] <kfogel> spm: interesting -- in all of db-devel, two revisions seem to have a pqm commit message of the form "[db=foo]"; all the rest use "[r=foo]" :-)
[06:48] <spm> I'd put down a small wager that was eitehr one of us; or stub, getting bored. :-)
[06:50] <spm> [db=foo] doesn't appear to be in the RE, so that should be fine
[06:50] <kfogel> spm: sanity check: bzr pqm-submit --submit-branch=lp:~launchpad-pqm/launchpad/db-devel -m "[r=stub,jml][bug=512500] Add Bug.latest_patch_uploaded column, to allow efficient sorting by patch age."
[06:50] <spm> looks good to me
[06:52] <kfogel> spm: holy cow, PQM is backed up though.  I guess this'll be landing in 2012 sometime.
[06:53] <spm> oh oh....
[06:53] <kfogel> spm: btw, I got this error, because it's abel's branch not mine:
[06:54] <kfogel> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~kfogel/launchpad/bug-512500-searchtasks-patch-age-sort/".
[06:54] <kfogel> I don't see an option to pqm-submit to tell it "use ~adeuring/... instead of ~kfogel/..." though
[06:55] <wgrant> Most people seem to use 'ec2 land' or push the branch up themselves.
[06:55] <wgrant> I'm not sure if there's another way.
[06:58] <spm> kfogel: https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadRollout <== under prep there's a complete submit we/I use for config submissions. that may help? I've used that to land eg branches from francis.
[06:58] <kfogel> spm: thanks
[06:58] <kfogel> wgrant: I've already run through ec2, so don't want to reintroduce that delay
[06:59] <kfogel> spm: hunh, looks like the '--public-location' option of bzr pqm-submit might be useful here.  I've been trying to figure out what it's doc means :-).
[07:00] <kfogel> "Use this url as the public location to the pqm." is not exactly crystal clear
[07:02] <kfogel> spm: this worked (I think) -- http://paste.ubuntu.com/368037/
[07:02] <spm> kfogel: if any consolation, when I worked that recipie out istr I was almost at the level of bliding trying random configs in the hope something worked. :-)
[07:03] <spm> s/bliding/blindly/
[07:03] <kfogel> spm: pqm is to code submission as reed snorkel is to traversing arctic sea under ice?
[07:04] <spm> on the grounds of living near to lead dev for same - ie thumping range: No Comment.
[07:04] <kfogel> spm: I'm a little worried -- pqm.launchpad.net says "Wed Feb 3 07:01:51 2010 UTC: Karl Fogel<EMAIL_ADDRESS>Request for non-PQM managed branch."
[07:05] <kfogel> spm: I was trying to land abel's branch *onto* db-devel, and I thought db-devel is a PQM managed branch.  So why that message in the queue (currently #16, at the bottom)?
[07:06] <spm> hrm. I suspect the syntax may be backwards on the submit; I'll check the mesg
[07:07] <kfogel> spm: ack, sorry.  I can redo w/ reverse values to the options...
[07:08] <al-maisan> kfogel: did you use "--submit-branch=ARG" ?
[07:08] <kfogel> spm: you know, reverse values, like http://paste.ubuntu.com/368039/    (/me giggles)
[07:08] <kfogel> al-maisan: I used both --submit-branch and --public-branch, and fear I messed it up.  I'm submitting a branch of adeuring's, not my own branch.
[07:09]  * spm falls out of chair; hurts self laughing and sues the pants offa kfogel
[07:09] <al-maisan> --submit-branch is probably all you need
[07:09] <kfogel> al-maisan: my exact command is here: http://paste.ubuntu.com/368037/
[07:09] <kfogel> al-maisan: no, that got an error (is backscroll available to you?)
[07:09]  * al-maisan looks
[07:09] <kfogel> al-maisan: here, I'll clarify:
[07:09] <kfogel> I originally did this:
[07:10] <kfogel>   1) I branched lp:~adeuring/launchpad/bug-512500-searchtasks-patch-age-sort locally
[07:10] <kfogel>   2) I cd'd into that local branch
[07:10] <kfogel>   3) I ran this pqm submit command: bzr pqm-submit --submit-branch=lp:~launchpad-pqm/launchpad/db-devel -m "[r=stub,jml][bug=512500] Add Bug.latest_patch_uploaded column, to allow efficient sorting by patch age."
[07:10] <kfogel>
[07:10] <kfogel> That got me an error:
[07:10] <kfogel> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~kfogel/launchpad/bug-512500-searchtasks-patch-age-sort/"
[07:11] <al-maisan> ah
[07:11] <al-maisan> I see
[07:11] <kfogel> al-maisan: ...okay, so it was looking in lp:~kfogel instead of lp:~adeuring.  How to tell it to use the lp: branch where my local branch "came from", not the branch it "would go to" if I pushed?
[07:11] <al-maisan> just a second
[07:11] <kfogel> al-maisan: so next, I tried http://paste.ubuntu.com/368037/  (just so you're up to date)
[07:12] <kfogel> al-maisan: and that got the result that the PQM queue at pqm.launchpad.net has a weird message at the bottom of the queue now:
[07:12] <kfogel> "Wed Feb 3 07:01:51 2010 UTC: Karl Fogel<EMAIL_ADDRESS>Request for non-PQM managed branch."
[07:12] <kfogel> al-maisan: that's where we are now.
[07:13] <al-maisan> kfogel: I believe for '--submit-branch' you should use the uri syntax from ~/.bazaar/locations.conf
[07:14] <kfogel> al-maisan: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel  ?
[07:14] <al-maisan> i.e. --submit-branch=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel
[07:14] <kfogel> :-)
[07:14] <al-maisan> :)
[07:14] <kfogel> spm: wanna get my dud out of the queue, and I'll try al-maisan's suggestion above?
[07:14] <spm> sure
[07:15] <spm> gone
[07:15] <al-maisan> kfogel: also, https://dev.launchpad.net/WorkingWithDbDevel
[07:15] <spm> (fwiw, was prepping to do just that, figuring it'd be needed shortly)
[07:15] <kfogel> spm: nice magic wand you got there
[07:15] <kfogel> al-maisan: thank you!
[07:15]  * kfogel reads
[07:16] <al-maisan> last section: "Submitting to PQM"
[07:18] <al-maisan> Even Minotaur would be proud of the labyrinth called launchpad (development) .. *sigh*
[07:19]  * spm bows in admiration to al-maisan for THAT line
[07:19]  * al-maisan blushes
[07:20] <stub> If you want to land abel's branch, you don't need to fake things with --public-location. Just tell pqm to land it (bzr pqm-submit -m 'comment' --submit-branch=bzr+ssh://... bzr+ssh://bazaar.launchpad.net/~abel/...
[07:21] <kfogel> stub: just pass abel's branch as a direct argument?
[07:21] <stub> Yes. bzr pqm-submit --help gives you the command line syntax
[07:22] <stub> No need to stuff around with local branches - its not like pqm can access your hard drive.
[07:22] <kfogel> stub: Thank you.  Believe me, I've been poring over that help quite a bit :-).  It doesn't make clear when one can/can't use the "lp:" shorthand, and the difference between --submit-branch and --public-location is not clear.
[07:22] <stub> Glitches are bits of pqm can't cope with lp: urls and you need to explicitly specify --submit-branch because you likely haven't got abel's launchpad branches configured in your locations.conf
[07:22] <kfogel> stub: yeah, I thought it looked in the local branch to divine the upstream lp branch to submit, but if there's a way to just tell it, then... no need.
[07:23] <kfogel> right, I don't have anything in locations.conf about it
[07:23] <stub> Use bzr+ssh: all the time for pqm - I think they work in some bits, but no idea which bits they are
[07:24] <kfogel> stub: http://paste.ubuntu.com/368044/
[07:26] <stub> Bah
[07:26] <kfogel> stub: if I did use --public-location, would adeuring's branch be the right arg to it?
[07:29] <stub> Bah. Could have sworn that worked. echo "star-merge bzr+ssh://bazaar.launchpad.net/~abel/...  bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/foo-devel" | gpg --cl | mail<EMAIL_ADDRESS>-s "merge message"
[07:29] <stub> kfogel: Might work with --public-location
[07:29] <kfogel> stub: I'll try.  I can always get spm to clean a dud out of the pqm queue again :-)
[07:29] <spm> heh
[07:30] <kfogel> stub: well, that seemed to succeed.  let me see what pqm front page says about it.
[07:31] <kfogel> looks good to me!  item #16
[07:31] <kfogel> spm: seriously, though: should I worry about the size of that pqm queue?
[07:31] <spm> kfogel: nope
[07:31] <spm> we have a real landing taking place; and the tests are... slow
[07:31] <kfogel> spm: ok
[07:31] <spm> it's still doing real work
[07:31] <kfogel> stub: thanks
[07:32] <spm> yeah, most recent, just a few mins ago. slowly but surely...
[07:33] <noodles775> Howdy people
[07:34] <spm> hey noodles775
[07:35] <kfogel> hey noodles775
[07:35]  * noodles775 waves to spm and kfogel
[07:37] <spm> huh. that'd be why mwh and myself were able to attempt to break buildbot with impunity earlier; all the merges are stuck behind pqm. win.
[08:07] <kfogel> beuno: ping
[08:09] <beuno> kfogel, hi
[08:10] <kfogel> beuno: hey, morning
[08:10] <kfogel> beuno: need some UI re-review on some branches.
[08:10] <kfogel> beuno: actually, give me a sec and I'll point you to a mail with lots of nice info
[08:11] <kfogel> beuno: this is all assuming you've NOTHING BETTER to do, of course :-)
[08:11] <beuno> kfogel, I still need to get out of bed
[08:11] <kfogel> beuno: what are you doing on IRC, man??
[08:11] <beuno> but if you give me a link, I will get to it within the next few hours  :)
[08:12] <beuno> kfogel, danilo got to the bathroom first!
[08:12] <kfogel> beuno: https://lists.launchpad.net/launchpad-dev/msg02411.html
[08:13] <kfogel> beuno: that mail gives context for what's going on.  The actual branches that need ui review are:
[08:13] <kfogel> https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/+merge/18414
[08:13] <beuno> kfogel, cool, will feed back soon
[08:14] <kfogel> https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428
[08:14] <kfogel> and a re-review for this one:
[08:14] <kfogel> https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report/+merge/18181
[08:15] <kfogel> beuno: re that mail: I'm writing a followup in which I de-confuse something that is very confused toward the end of the mail.  sorry.  It's late here.
[08:16] <beuno> and I'm still sleepy, so it should even out
[08:18] <kfogel> heh
[08:18] <kfogel> beuno: okay, followup sent
[08:19] <kfogel> beuno: upshot is, there will probably be one more MP later that needs UI review ("patches view sorting by patch age" basically), in addition to the above.  But the new one doesn't exist yet.
[08:30] <adeuring> good morning
[08:31] <kfogel> adeuring: heh
[08:31] <kfogel> adeuring: I'm about to go to bed -- see my email.
[08:31] <kfogel> adeuring: good morning :-)
[08:31] <kfogel> adeuring: but before I go to bed, let's coordinate a bit maybe?
[08:31] <adeuring> hi kfogel, must have been a long for you,..
[08:32] <adeuring> kfogel: yes, but let me find your mail first.
[08:32] <kfogel> adeuring: well, it was punctuated by an amazing concert by Radu Lupu in Carnegie Hall, that's why I'm up now.
[08:32] <kfogel> adeuring: https://lists.launchpad.net/launchpad-dev/msg02411.html
[08:32] <kfogel> adeuring: note that right after, I send a followup that clarifies something confusing in the original post.
[08:33] <kfogel> adeuring: (it's where I wrote the wrong summary line for the hypothetical merge proposal text; it'll be obvious)
[08:33] <kfogel> adeuring: so, I'm going to go brush teeth and stuff while you read.  I'll check back here in some minutes.
[08:37] <adeuring> kfogel: do you have screenshots for the ui re-review of lp:~kfogel/launchpad/506018-patch-report ?
[08:39] <kfogel> adeuring: no, but I could make them
[08:39] <kfogel> adeuring: hey, let me brain dump at you briefly about conflict resolution:
[08:40] <kfogel> adeuring: some subsequent changes of 506018-patch-report trivially conflict with the other branches for which it is a prereq.  I've had to resolve them two or three times now, so I know them almost by heart :-).  It's that in the story test, "user_browser" became "anon_browser", and "expected_contents" became "contents".
[08:40] <kfogel> And in factory.py, we init is_patch to the "_DEFAULT" object instead of None now, and test for that.
[08:41] <kfogel> there might be some others, but they're equally trivial if so
[08:41] <adeuring> kfogel: ok.
[08:41] <kfogel> adeuring: now, would you like some screenshots?
[08:41] <adeuring> kfogel: na, i think you should go to bed ;) I'M trying to understand what i need to do today, except to get a review for one of my branches
[08:42] <kfogel> adeuring: main thing, I think, is actually implement the UI for patch age sorting.
[08:42] <adeuring> kfogel: right.
[08:42] <kfogel> adeuring: it's actually easy for me to make the screenshots, let me do that.  I have martin's three Ui comments right here in front of me anyway.
[08:42] <kfogel> - Padding in the tooltips would be super nice
[08:42] <kfogel> - I'd add an "Order by: " label to the ordering drop down, and drop the "by" from each option to improve readability
[08:42] <kfogel> - Bug icons don't respect importance
[08:47] <kfogel> adeuring: urrrrgh, just noticed a buglet: if you view patches by user:
[08:47] <kfogel> https://bugs.launchpad.dev/~name16/+patches
[08:47] <kfogel> the page says:
[08:47] <kfogel> "Patch attachments in Foo Bar"
[08:47] <kfogel> where Foo Bar is the person's name.
[08:47] <kfogel> should be "for Foo Bar" or something.
[08:47] <adeuring> kfogel: I like this ;)
[08:47] <kfogel> you like the "in"?
[08:47] <adeuring> kfogel: yes
[08:48] <kfogel> adeuring: as a native speaker, I'm going to have to assert my authority here :-).
[08:48] <adeuring> kfogel: yeah, I get the meaning .-- that's the reason why I like it
[08:54] <kfogel> adeuring: okay, here you go:
[08:54] <kfogel> http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-distroseries-2010-02-03.png
[08:54] <kfogel> http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-no-patches-message-2010-02-03.png
[08:54] <kfogel> http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-orderby-dropdown-2010-02-03.png
[08:54] <kfogel> http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-padding-around-tooltip-has-orderby-label-bug-icon-respects-importance-2010-02-03.png
[08:54] <kfogel> http://people.canonical.com/kfogel/patches-view/screenshot-patches-view-project-group-2010-02-03.png
[08:55] <adeuring> kfogel: thanks!
[08:55] <kfogel> adeuring: before I go to bed, are you set?
[08:55] <adeuring> kfogel: yes ;)
[08:56] <kfogel> adeuring: beuno should be coming back soon, and has the list of things needing UI review, but might be good to confirm with him.
[08:56] <kfogel> Okay, I'm off.
[08:56] <kfogel> adeuring: thanks!  Sorry not to have had the new patch-age-sorting UI ready for you :-(.
[08:56] <adeuring> kfogel: ok. BTW, I think my branch for sorting by patch age does not need a ui review, because it does not implement any UI chenages
[08:57] <adeuring> kfogel: no problem with the patch age sorting still missing.
[08:58] <kfogel> adeuring: (if I handed beuno your branch for UI review, it was an accident -- in fact, I think I *did* do that accidentally at one point, then deleted the MP right afterwards when I realized)
[08:58] <kfogel> but you might have gotten an email about it
[08:59] <adeuring> kfogel: ah, right, just tred to find that MP and got a 404
[08:59] <kfogel> :-)
[08:59] <kfogel> adeuring: let beuno know that was an accident when he comes back, please :-)
[08:59] <adeuring> kfogel: sure
[09:01] <kfogel> adeuring: ok, g'night for realz.  See you later.
[09:01] <noodles775> Night kfogel
[09:01] <kfogel> night noodles775
[09:01] <adeuring> night kfogel
[09:01]  * kfogel gets stuck in an infinite good night loop...
[10:03] <thekorn> hi, after reading some launchpad code, I'm a bit confused. what is a Project, and what is a Product?
[10:07] <thekorn> hmm, I think I got it now, it looks like for example "firefox" is called a "project" in the web UI, but internally it is implemented by IProduct
[10:08] <thekorn> and IProject defines a super-project/project-group
[10:09] <intellectronica> thekorn: IProduct is what is called in the UI a 'project', and IProject is what is called in the UI 'project group'. confusing, eh? :)
[10:10] <asabil> hi all
[10:10] <thekorn> it, is confusing! same with bug and tasks, in the web UI your can search for bugs, but get a list of tasks as the result
[10:10] <thekorn> launchpad needs a glossar ;)
[10:10] <asabil> what's the difference between the lp_person table and the person table ?
[10:11] <intellectronica> thekorn: that's actually a good idea. maybe we should start one on the wiki
[10:12]  * intellectronica doesn't know :-O
[10:12] <thekorn> yeah, let's called it "launchpad speech for n00bs"
[10:12] <thekorn> -ed
[10:16] <asabil> anyone ?
[10:16] <intellectronica> asabil: stub would probably know, but i can't see him online at the moment
[10:17] <asabil> ok thanks, I will wait then
[10:17] <wgrant> asabil: It's to do with integration with the Ubuntu SSO service. Ignore the lp_* tables.
[10:18] <wgrant> (they should be identical copies of the corresponding non-lp_* tables -- eg. lp_person has the same content as person.)
[10:18] <asabil> wgrant, that's what I see, but I don't really understand the purpose
[10:18] <wgrant> asabil: We can't see the code that uses them, so that's not surprising.
[10:19] <asabil> oki thanks
[10:57] <thekorn> allenap, hi, I merged your official_bug_tags changes to my branch, now the xx-official-bug-tags.txt test is failing, http://paste.ubuntu.com/368114/
[10:57] <thekorn> do you have any idea what's going wrong there?
[11:01] <allenap> thekorn: I'll take a look..
[11:02] <thekorn> thank you
[11:09] <allenap> thekorn: It's because I made IOfficialBugTagTargetPublic.official_bug_tags read-only.
[11:13] <thekorn> allenap, oh yeah, makking it readonly=False works
[11:13] <allenap> thekorn: Of course, other things break now :)
[11:14] <thekorn> allenap, but in my understanding there are a few lines in registry/interfaces/product.py which make this field writable?
[11:14]  * allenap goes to look
[11:15] <thekorn> around line 727
[11:16] <allenap> thekorn: In r/i/distribution.py too.
[11:16] <allenap> thekorn: This is all a bit hacky and unpleasant.
[11:29] <thekorn> allenap, ok, I don't think I have enough voodoo powers to understand what's going on there, and maybe to work around it,
[11:30] <allenap> thekorn: I think I've got something... I'll paste a diff in a minute or two.
[11:30] <thekorn> wow great
[11:30] <allenap> thekorn: Well, more like 10 or 20.
[11:30] <thekorn> take your time
[12:24] <allenap> thekorn: Merge my branch again; it's got something that seems to work in it.
[12:55] <asabil> can someone explain what is zopeless please ?
[13:27] <thekorn> allenap, thanks. looking
[13:58] <thekorn> allenap, super, I finally was able to merge your changes, it works great, (altought I don't get how this is different to the old hackish solution)
[13:58] <thekorn> thanks again
[14:31] <allenap> thekorn: Well, the difference is that it's less hackish ;)
[14:31] <thekorn> allenap, ok, but this does not explain why it was not working the other way :)
[14:32] <allenap> thekorn: That's the magic of Zope! (Meaning, I will try and think of a better answer...)
[14:34] <thekorn> allenap, anyway, it seems to work now, is something fundamental missing (or wrong), if not I think I will go an file a merge proposal for this branch
[14:35] <thekorn> so I can get this searchTasks in, in a later branch I will try to add methods like  searchCommentedTasks() ...
[14:39] <Ursinha> A/5
[14:42] <allenap> thekorn: Go for it :)
[15:01] <thekorn> done, https://code.edge.launchpad.net/~thekorn/launchpad/make_iperson_ihasbugs/+merge/18523
[15:01] <thekorn> allenap, thanks again for your help, you helped me alot
[15:02] <allenap> thekorn: Cool, you're welcome, you're helping us a lot :)
[15:43] <bac> hi rockstar
[16:11] <rockstar> bac, hi
[16:22] <bac> hi rockstar.  nm, i was able to get help from abentley
[16:23] <rockstar> bac, awesome. abentley is handy like that.  :)
[16:43] <allenap> rockstar: When using "Resubmit proposal", can I change the merge target?
[16:43] <rockstar> allenap, no, because then you're not resubmitting.  Your submitting to another target.
[16:45] <allenap> rockstar: Ah, fair. (I'm trying to be constructively lazy when I submit to lp:launchpad when I mean devel.)
[16:45] <allenap> thekorn: The merge proposal for make_person_ihasbugs is proposed for merging into lp:launchpad, aka db-devel, so the diff is huge. You'll need to file a new proposal for devel.
[16:45] <rockstar> allenap, yeah, I've done that a few times as well.  I just delete the proposal and start over.
[16:46] <allenap> rockstar: Yep, me too. Thanks.
[16:49] <abentley> rockstar, allenap: We are planning to allow resubmitting with a changed target in the future.
[16:51] <allenap> abentley: That will be great.
[16:53] <abentley> rockstar, chat?
[16:53] <rockstar> abentley, 5 mins?
[16:53] <abentley> rockstar, sure.  Call me.
[17:01] <kfogel> adeuring: I haven't read all email yet, btw
[17:02] <adeuring> kfogel: so, Martin ui-approved your main branch, and (implicitly) also the "no patches available" variant
[17:02] <adeuring> my branches landed on db-devel
[17:02] <kfogel> adeuring: both of yours?  awesome!
[17:02] <kfogel> adeuring: so the three devel branches still need to land, then?
[17:02] <adeuring> intellectronica branched from your big-iintegration branch and added sorting by patch age
[17:03] <adeuring> kfogel: yes, but i think we can just land tom's most recnet branch, if...
[17:03] <adeuring> if we are sure that everything is reveiwed ;)
[17:03] <kfogel> adeuring: ah, it has everything, right.
[17:03] <kfogel> whew
[17:03] <kfogel> adeuring: well, I'm doing that now: checking the review status on all the individual branches, then will look at tom's integration+sorting branch.
[17:04] <adeuring> kfogel: cool.
[17:04] <kfogel> beuno: can you mark https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428 as approved by you, since you implicitly approved that UI in another branch already?
[17:05] <kfogel> adeuring: https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/+merge/18414 has no UI review yet, and it's not clear to me if beuno or anyone else did persons/teams.
[17:05] <kfogel> ?
[17:05] <adeuring> kfogel: well, the presentation is the same as for the other variants
[17:06] <beuno> kfogel, done
[17:06] <kfogel> adeuring: well, there is that "in" vs "for" issue we noticed last night
[17:06] <kfogel> beuno: thank you!
[17:06] <allenap> kfogel: I think it's safe to not do a UI review. There are, however, some pending changes to that branch which abel noticed this morning.
[17:06] <kfogel> allenap: pending changes?
[17:07] <adeuring> kfogel: yes, the things you moticed earlier
[17:07] <allenap> kfogel: The title was wrong for people, and the target column was not showing up.
[17:07] <adeuring> "patches in..."
[17:07] <kfogel> allenap: so the necessary changes are in the branch now, or need to be made?
[17:07] <adeuring> and i think that we should show the target on ~person/+patches
[17:07] <allenap> kfogel: I'm making them, and will be done soon.
[17:08] <intellectronica> adeuring, kfogel: you can land my branch, it's reviewed and all. it does require a test run, though i'm quite confident about it
[17:08] <kfogel> adeuring: I'm actually a little curious, now that I think about it, about the meaning of ~person/+patches.  Is it showing all patches for bugs which that person is somehow associated with, or...?
[17:08] <intellectronica> kfogel: i'll have to go away in an hour. are you cool to take over?
[17:08] <kfogel> intellectronica: yes
[17:08] <kfogel> intellectronica: your branch https://code.edge.launchpad.net/~intellectronica/launchpad/no-patches-message/+merge/18428 was part of my mega-test-run yesterday.
[17:08] <adeuring> kfogel: yes, but don't ask me about details, what "associated" exactly means...
[17:09] <kfogel> adeuring: IOW, it's about how a person/team "has bugs", whatever "has" means
[17:09] <adeuring> kfogel: yes
[17:09] <kfogel> adeuring: the issue, though, is what should the title of the target column be then?
[17:09] <intellectronica> kfogel: i have another branch, ~intellectronica/launchpad/sort-by-patch-age, which does what it says on the tin. that's the one i was referring to
[17:09] <kfogel> adeuring: what if it can be both packages and products, for example?
[17:09] <kfogel> intellectronica: ah, ok, thanks
[17:09] <adeuring> kfogel: right
[17:10] <adeuring> it can be packages and products...
[17:10] <kfogel> adeuring: so, we need a better title :-)
[17:10] <adeuring> so, "target"?
[17:10] <kfogel> ugh
[17:10] <kfogel> adeuring: loathe to use "target", since (as others have pointed out) it has a verb meaning for series and milestones.
[17:10] <adeuring> or "package/product"?
[17:10] <kfogel> prackuct?  prodage?
[17:11] <adeuring> kfogel: let's try that ;)
[17:12] <kfogel> whoo boy
[17:12] <adeuring> kfogel: but I wouldn't put too much effort into this detail right now. There isn't very much time left to run the ec2 test and to merge
[17:13] <adeuring> kfogel: let's take something vaguely reasonable, like target, and replace it by a better word later
[17:14] <kfogel> adeuring: *nod*
[17:14] <kfogel> beuno: are you seeing above?  I can summarize if you want.
[17:15] <beuno> kfogel, sorry, am not
[17:15] <kfogel> beuno: I'll summarize, np:
[17:15] <beuno> what's up?
[17:15] <kfogel> When seeing the patches view for a person/team, we're going to make two simple UI tweaks.
[17:15] <kfogel> One is obvious: "Patches in J. Random" isn't a good page title, should be "Patches *for* J. Random".
[17:15] <kfogel> I assume no controversy there :-).
[17:16] <kfogel> The second is that there's a variable column in the view -- second from right column, it's sometimes called "Package" and sometimes called "Project" (meaning product) depending on the type of the view.  But in the case of persons/teams, it can vary row-by-row, sometimes pkg, sometimes proj.
[17:16] <kfogel> beuno: so, we're thinking we have to call it "target" for now, unless you can think of a better name.
[17:17] <kfogel> the column, that is
[17:17] <kfogel> (maybe "Task Target" ?)
[17:17] <beuno> kfogel, target I think is something we only know what it means
[17:18] <kfogel> beuno: I know.  I just can't come up with a better word right now.  "Pkg/Proj" ?
[17:18] <kfogel> "Package / Project" is awfully long.
[17:18] <beuno> kfogel, this is the table header?
[17:18] <kfogel> beuno: right, column name in the table.
[17:22] <kfogel> adeuring: okay, so I'd like to sketch out what comes next if you don't mind.
[17:22] <adeuring> kfogel: sure
[17:22] <kfogel> adeuring: first of all, we're done with db-devel, right?  No worries there.
[17:22] <adeuring> kfogel: right
[17:23] <kfogel> adeuring: we now have four other branches to integrate
[17:23] <kfogel> (one sec)
[17:23] <adeuring> kfogel: well, they _are_ integrated, aren't they?
[17:23] <kfogel> s/integrate/land/
[17:23] <kfogel> but one of them needs some code changes!
[17:23] <kfogel> I don't actually have intellectronica's new branch; let me find it.
[17:24] <adeuring> kfogel: i think allenap's branch is not yet merged into your big integration branch
[17:24] <kfogel> oh, allenap's
[17:24] <kfogel> adeuring: how much longer are you on?
[17:25] <kfogel> adeuring: (subtext is: I'm going to need some food at some point soon)
[17:25] <adeuring> kfogel: not very long, at least not in a "useful way". I think I caught a bronchitis
[17:25] <adeuring> kfogel: but grabbing food right now is a good idea :)
[17:26] <kfogel> adeuring: oh, sorry :-(
[17:26] <kfogel> adeuring: 15 min, just some quick breakfast
[17:26] <kfogel> I'll be much more functional after that
[17:26] <adeuring> kfogel: sure, I'll be afk for 20 minutes to buy some food
[17:26] <kfogel> see you back here
[17:34] <thekorn> allenap, damn, sorry. will file a new one
[17:35] <allenap> thekorn: No worries, I do it all the time. abentley earlier said that a feature to resubmit a proposal for a different merge target is planned, but for now you've got to create a new one and delete the old one.
[17:37] <thekorn> allenap, that's the new one: https://code.edge.launchpad.net/~thekorn/launchpad/make_iperson_ihasbugs/+merge/18541
[17:38] <allenap> thekorn: Cool.
[17:41] <kfogel> adeuring: back
[17:48] <kfogel> intellectronica: (still there?)  what about UI review on your branch?
[17:49] <intellectronica> kfogel: come on, for adding another option to the combo?
[17:49] <intellectronica> ui=me
[17:49] <kfogel> intellectronica: okay.  I'm still learning the processes :-).
[17:49] <intellectronica> me too :)
[17:50] <poolie> hi
[17:50] <poolie> what is the username/password in the sampledata
[17:51] <kfogel> poolie<EMAIL_ADDRESS>"test" I think
[17:51] <kfogel> allenap: so reading backscroll, I'm not quite clear on what changes you're making to which branch.  Can you give me a one-sentencer?
[17:51] <poolie> thanks
[17:51] <kfogel> poolie: np, thanks for looking it over
[17:51] <allenap> poolie<EMAIL_ADDRESS><EMAIL_ADDRESS>(I think), with "test" as the password.
[17:52] <beuno> kfogel, sorry I moved away. Need me to click on anything?
[17:52] <kfogel> poolie: I never used that one allenap said above, but maybe it works too :-)
[17:52] <poolie> karl's stuff worked
[17:52] <kfogel> beuno: no, won't be for at least half an hour yet unfortunately
[17:52] <allenap> kfogel: Sorry if I was butting in. There are several users to choose from.
[17:52] <kfogel> beuno: sorting out some chaos here.
[17:52] <beuno> kfogel, take my ui=beuno and land. I can always file bugs  :)
[17:52] <kfogel> beuno: many branches flying around, trying to reduce that to just one or two :-)
[17:52] <poolie> oh that's so sexy
[17:52] <poolie> a not-quite-so-trivial branch
[17:52] <kfogel> beuno: heh.  thanks, wil do
[17:53] <allenap> intellectronica: Do you have time to review r10187 in https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/+merge/18414? I /hope/ it'll be swift and painless. No harm in saying no though.
[17:54] <kfogel> allenap: ah, great!  I see rev 10187; you were doing what I was about to do, great.
[17:55] <kfogel> (except probably doing it faster, cough cough)
[17:55] <allenap> kfogel: Oh, don't believe that; I took a fair old time doing that one.
[17:55] <kfogel> allenap: and IPerson.providedBy(foo) counts teams as well, right?
[17:57] <allenap> kfogel: Yep.
[17:57] <kfogel> allenap: in another branch, shouldShowTarget name is now targetName and looks like this:
[17:57] <kfogel> http://paste.ubuntu.com/368365/
[17:58] <kfogel> allenap: and the .pt file has been updated accordingly.
[17:58] <kfogel> allenap: that's in https://code.edge.launchpad.net/~kfogel/launchpad/506018-patch-report/
[18:00] <kfogel> allenap: the purpose of that is to vary that column name depending on whether it should be "Package" or "Project" (product).  after discussion, beuno suggested defaulting to "Project" when it's a person view (since the column may show both, but "project" is broader).
[18:00] <allenap> kfogel: I have to go, erm, basically now. I will be back in about 2.5h, can it wait, or could you perhaps fix it up in the integration branch? I would guess it should be something like "Project or Package" for IPerson.
[18:00] <kfogel> allenap: I can fix it up, np.  I just wanted to let you know.
[18:00] <poolie> kfogel: or whoever: where should new bugs-related pagetests go?
[18:01] <poolie> lib/lp/bugs/pagetests/ or something else?
[18:01] <kfogel> poolie: not sure
[18:02] <allenap> kfogel: Thanks.
[18:02] <poolie> BjornT: ^^ ?
[18:03] <kfogel> allenap: np.  thank you so much for finishing those UI fixes!
[18:03] <allenap> kfogel: Sorry I was so slow.
[18:04] <kfogel> allenap: I dunno, man, I was sleeping :-).
[18:04] <kfogel> if you'd been faster, I wouldn't have woken up earlier!
[18:19] <kfogel> adeuring: ayt?
[18:19] <adeuring> kfogel: yes
[18:20] <kfogel> adeuring: now that we're both fooded, let's resume :-).  My next steps are to integrate https://code.edge.launchpad.net/~intellectronica/launchpad/sort-by-patch-age and the new r10187 from https://code.edge.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018 into my patches-view-mega-integration branch (which is based off db-devel, btw).
[18:21] <kfogel> There will be some trivial adjustments to make, at least in allenap's code, but nothing that should be a problem.
[18:21] <kfogel> Then I'm going to run EC2 on that, and then submit it (I believe we have all the approvals now, will double-check that).
[18:21] <kfogel> adeuring: when I submit, I submit to db-devel?
[18:21] <adeuring> kfogel: yes
[18:21] <kfogel> adeuring: actually, I should the ec2-land thing, right?
[18:22]  * kfogel realizes these tools exist for a reason
[18:22] <adeuring> kfogel: yes ;)
[18:22] <adeuring> kfogel: but ec2 test -s "submit message" etcetc works too
[18:22] <kfogel> adeuring: so, I'm sure that the ec2 run will start in less than an hour, probably less than half an hour.  Given that, I think I can tell jcastro not to move his talk to friday, but keep it thursday.
[18:23] <adeuring> kfogel: right
[18:24] <kfogel> adeuring: thanks
[18:24] <adeuring> kfogel: but to be sure, let's double-check with the LOSAs when staging is update
[18:24] <adeuring> ...updated
[18:24] <kfogel> adeuring: ok.  losas, ayt? :-)
[18:25] <mthaddon> kfogel: what's up?
[18:25] <kfogel> adeuring: you'll be more competent at asking this question.
[18:25] <kfogel> mthaddon: (what adeuring says; I'll listen and learn)
[18:25] <adeuring> mthaddon: at whoch time is the code on staging  updated?
[18:26] <adeuring> i.e.;: What is the lastest time to land a branch so that it is included in the next code update?
[18:26] <mthaddon> adeuring: it runs every half an hour, but if it includes DB updates, the upgrade can take up to 1 day, so it's very hard to estimate
[18:27] <adeuring> mthaddon: wow, that's more frequently than i assumed
[18:27] <adeuring> The DB patch already landed, BTW
[18:29] <kfogel> adeuring: in my patches-view-mega-integration branch (locally), I should *not* do 'bzr merge ../devel', right?
[18:29] <adeuring> kfogel: no, it's better to merge db-devel
[18:32] <kfogel> adeuring: how frustrating.  'bzr update' in my db-devel branch locally gets no changes, but 'bzr pull' does.  How is one supposed to remember this?
[18:32] <kfogel> sorry, just grumbling
[18:32] <adeuring> ;)
[18:33] <kfogel> adeuring: 'cd patches-view-mega-integration; bzr merge ../db-devel'
[18:33] <kfogel> Warning: criss-cross merge encountered.  See bzr help criss-cross.
[18:33] <kfogel> adeuring: should I worry about that?
[18:33] <adeuring> kfogel: gah, yes :(
[18:33] <adeuring> kfogel: do you get many conflicts?
[18:34] <kfogel> adeuring: 4, yes
[18:34] <kfogel> adeuring: I can redo the entire integration branch; that'd add maybe 15 minutes delay.
[18:34] <adeuring> kfogel: well, that's not many ;)
[18:34] <kfogel> adeuring: should I just resolve them before committing?
[18:34] <adeuring> kfogel: yes, I think so. But our bazaar specialists might have better advice
[18:34] <kfogel> adeuring: I just worry that the "criss-cross" merge could end up screwing up db-devel's history.
[18:35] <kfogel> is that possible?
[18:35] <adeuring> kfogel: I must admit that I was never sure about the side effects of a criss-cross merge...
[18:35] <adeuring> kfogel: but I think it is hard to avoid it now...
[18:36] <kfogel> adeuring: I'm asking in bzr.
[18:38] <kfogel> adeuring: poolie says that won't screw up the history.
[18:38] <adeuring> kfogel: ok, so, if the conflicts are not too difficult to resolve, let's try that
[18:40] <kfogel> adeuring: they're actually not completely trivial.  I'm asking poolie in #bzr about maybe reordering my operations to avoid it, one sec.
[18:40] <adeuring> kfogel: which files show conflicts?
[18:41] <kfogel> adeuring:
[18:41] <kfogel> Text conflict in lib/lp/bugs/doc/bugtask-search.txt
[18:41] <kfogel> Text conflict in lib/lp/bugs/interfaces/bugtask.py
[18:41] <kfogel> Text conflict in lib/lp/bugs/stories/webservice/xx-bug.txt
[18:41] <kfogel> Text conflict in lib/lp/testing/factory.py
[18:41] <kfogel> adeuring: first file is trivial whitespace, no issues
[18:42] <kfogel> second one is small, but not immediately obvious which side is "right"
[18:42] <adeuring> kfogel: I think these are real conflicts.
[18:43] <adeuring> kfogel: let me have a look myself. Is your integration branch on LP up to date?
[18:43] <adeuring> (except for the db-devel merge, of course)
[18:43] <kfogel> adeuring: yes.  it has tom's change, but I havne't committed nor pushed the db-devel merge yet.
[18:43] <adeuring> kfogel: ok
[18:44] <kfogel> adeuring: note jam suggest 'bzr merge --weave' or 'bzr remerge --weave' over in #bzr
[18:45] <adeuring> kfogel: right, that helps quite often. You could try that, but I think the conflicts detcted by bzr are all real
[18:45] <kfogel> adeuring: *nod*  if you can resolve them, that'd be great.  can you just push to my branch, or do you have to push to somewhere else and then I merge from your branch?
[18:45] <kfogel> "my branch" meaning mine up on launchpad
[18:45] <adeuring> kfogel: a few minutes, please ;)
[18:45] <kfogel> I suppose you can't do that.  Oh well, no big deal.
[18:46] <kfogel> adeuring: sure :-)
[18:47] <kfogel> mthaddon: so I wasn't clear on the resolution of the conversation you and abel had just now.  We're going to send a db-devel branch through EC2 in the next hour or so; assuming it passes and lands, when will staging get the update?
[18:48] <mthaddon> kfogel: the conclusion was there's not really an easy way to tell - I'd have to dig into it in a lot more detail to be able to tell you but I'm already past EOD - we update every 30 mins, but with DB updates it can take a day to restore
[18:49] <kfogel> mthaddon: np, I don't want to keep you late.  Is there another LOSA who will be around the next few hours?
[18:52] <mthaddon> kfogel: it depends on if there are any other commits with db changes that hit before that one does - if so, two days, if not, one day is about as close as we can get
[18:54] <kfogel> mthaddon: one day as in ~24h ?
[18:54] <mthaddon> yep
[18:55] <mthaddon> assuming there are no problems with the staging update process
[18:58] <adeuring> kfogel: conflicts resolved: lp:~adeuring/launchpad/patches-view-mega-integration
[18:59] <kfogel> adeuring: I will now merge that into my local patches-view-mega-integration and push up, and then take care of getting allenap's chnages in
[18:59] <kfogel> mthaddon: thanks.
[18:59] <adeuring> kfogel: ok
[18:59] <kfogel> adeuring: based on what mthaddon says above, I think I need to tell jcastro to move his talk to friday.  concur?
[18:59] <didrocks> installing LP on lucid is still failing, but not in the bzr part this time (thanks james_w!). It seems to try to executes something in a non existing file: http://pastebin.com/f5426fbab
[19:00] <adeuring> kfogel: yes, that's probably better
[19:06] <kfogel> adeuring: okay, lp:~kfogel/launchpad/patches-view-mega-integration is now totally up-to-date; includes your branch, which means it's up to date with latest db-devel.  Right?  I'm being extra verbose just to make sure I don't miss a step here :-).
[19:06] <adeuring> kfogel: yes ;)
[19:07] <adeuring> kfogel: except... that db-devel has been updated in the last minutes. but that shouldn't matter
[19:08] <kfogel> adeuring: thanks.  Now, I need to merge *just* http://bazaar.launchpad.net/~allenap/launchpad/patch-report-for-people-and-teams-bug-506018/revision/10187 .  Is that just this command?:
[19:08] <kfogel> bzr merge -c 10187 lp:~allenap/launchpad/patch-report-for-people-and-teams-bug-506018
[19:08] <adeuring> kfogel: yes, but I think you don't need to specify the revision. We want the recent verion, don't we?
[19:09] <adeuring> s/verion/version/
[19:09] <kfogel> adeuring: oh, right, duh -- bzr will just DTRT.  I'll try it without -c.
[19:09] <kfogel> adeuring: merging now.  remember this is the one where I will have to resolve some conflicts.
[19:09] <adeuring> kfogel: right
[19:12] <mwhudson> good morning
[19:14] <thekorn> how is this +apidoc generated out of thes wadl file?
[19:14] <kfogel> mwhudson: morning
[19:14] <kfogel> thekorn: oh, wait, I think we covered this long ago, I might have a branch that has notes on this...
[19:16] <thekorn> kfogel, sorry, already found it, there is a stylesheet in launchpadlib which is used for it
[19:16] <thekorn> I was just confused because I expected to find something in launchpad itself
[19:17] <kfogel> thekorn: so https://code.edge.launchpad.net/~kfogel/launchpadlib/426323-apidoc-html-title-attrs is of no help to you now, I guess :-)
[19:17] <kfogel> more specifically, https://code.edge.launchpad.net/~kfogel/launchpadlib/426323-apidoc-html-title-attrs/+merge/12442
[19:18] <thekorn> kfogel, it tells me that launchpadlib is the correct place to look at
[19:18] <thekorn> thanks kfogel
[19:19] <kfogel> thekorn: np
[19:22] <didrocks> kfogel: any idea about the failing installation? ^
[19:23] <kfogel> didrocks: I'm afraid I'm under the gun right now with a deadline, sorry.  Wish I could look :-(.
[19:24] <didrocks> kfogel: no pb, I can handle other task and ping you again when you're up again. It's just that LP doesn't want me apparently :-)
[19:25] <kfogel> didrocks: no, it wants you, I promise.  It's just coy sometimes.
[19:26] <didrocks> kfogel: hehe right, do you mind I ping you later? (next week if you prefer?)
[19:26] <didrocks> just need my changes to land before alpha3 for Quickly Feature Freeze
[19:27] <kfogel> didrocks: it's always okay to ping, sure!
[19:27] <kfogel> if i'm tied up I'll just say so
[19:28] <kfogel> didrocks: but, others may be available sooner (like now, maybe?)  worth a try, if you're in a rush
[19:28] <kfogel> adeuring: http://paste.ubuntu.com/368404/
[19:28] <kfogel> adeuring: ^^ trouble building patches-view-mega-integration.  were you able to run the branch?
[19:28] <kfogel> adeuring: I got the same error with 'make run', btw
[19:29] <kfogel> adeuring: hmmm, maybe I didn't link external sourcecode?
[19:29] <kfogel> I'll try that...
[19:30] <kfogel> nope
[19:30] <kfogel> still get the error afterwards
[19:30] <adeuring> kfogel: strange....
[19:30] <kfogel> adeuring: you can build it?
[19:31] <kfogel> adeuring: btw, the pending changes in my tree are allenap's fixes, with conflicts resolved.  I can push those, I just wanted to actually test them first.
[19:31] <adeuring> let me try...
[19:32] <adeuring> kfogel: no problems running "make", "make schema"
[19:33] <kfogel> adeuring: whoa
[19:33] <kfogel> adeuring: well, in the interests of time, let me push up then
[19:33] <adeuring> kfogel: when running utilities/link-entrnal-sourcecode, did you specified ../devel or ../db-devel?
[19:34] <adeuring> kfogel: gah, sorry, used the wrong branch
[19:35] <kfogel> adeuring: I specified ../db-devel
[19:36] <adeuring> kfogel: hmmm... that should be right...
[19:37] <adeuring> kfogel: let me run the tests you want. (I have r8960 of the iegration branch)
[19:37] <kfogel> adeuring: wait, pushing now
[19:37] <kfogel> you want 8961
[19:37] <adeuring> kfogel: i have it
[19:37] <adeuring> ..now
[19:38] <kfogel> :-)
[19:38] <kfogel> adeuring: run bin/test -v -t patches-view.txt first, I'd say, just to make sure
[19:40] <adeuring> kfogel: a few simple test failures. http://paste.ubuntu.com/368409/ I'll fix tehm
[19:41] <kfogel> adeuring: dang it.  what'd I miss?  reading...
[19:43] <kfogel> adeuring: hunh.  I wonder why we get those?
[19:43] <kfogel> ohhhhhh
[19:43] <kfogel> I see why
[19:44] <kfogel> allenap change the displayname, yeah...
[19:44] <kfogel> good, makes sense now
[19:44] <adeuring> kfogel: i think defualt sort order changed too ;)
[19:46] <kfogel> adeuring: could be
[19:52] <kfogel> Anyone here know what might cause http://paste.ubuntu.com/368404/ ("ImportError: No module named canonical.config" "make: *** [compile] Error 1" when trying to build a branch) ?
[19:52] <kfogel> mwhudson: ^^
[19:52] <kfogel> barry: ah, you might know answer to above
[19:53] <mwhudson> kfogel: no, not really
[19:53] <mwhudson> i guess i'd try make clean; make
[19:54] <adeuring> kfogel: lp:~adeuring/launchpad/patches-view-mega-integration has the test fix
[19:55] <kfogel> adeuring: thank you.
[19:55] <kfogel> mwhudson: that may have fixed it...
[19:55] <adeuring> kfogel: np
[19:59] <kfogel> adeuring: pushed up now, 8962 is latest in my branch
[19:59] <kfogel> adeuring: I'm doing 'make schema' and 'make run' now just to sanity check, and run the patches-view.txt tests.  Then I will start the EC2 run with auto-land on success.
[20:00] <adeuring> kfogel: great. So let's start ec2 test
[20:00] <kfogel> adeuring: start now in parallel you mean?
[20:00] <kfogel> adeuring: makes sense
[20:00] <kfogel> let me compose the cmd
[20:00] <adeuring> kfogel: nah -- I'll leave that to you ;)
[20:01] <adeuring> I guess that I'm sleeping when the test will finish
[20:01] <adeuring> so I wouldnt notice any problems...
[20:01] <kfogel> adeuring: hm?  the cmd is now -- I meant the ec2 command, which will have the pqm submit message in it
[20:02] <adeuring> kfogel: now I'm conpletely confused ;)
[20:04] <kfogel> adeuring: I thought you were saying "Start the ec2 tests now, with the option to auto-land via pqm if the tests are successful."
[20:04] <adeuring> kfogel: yes, that's what i meant
[20:05] <kfogel> adeuring: so the cmd I'm composing begins with "utilities/ec2 ..."
[20:06] <kfogel> adeuring: I'm trying to figure out whether to use 'land' or 'test'.  I guess 'land' wants a merge proposal, whereas 'test' takes a branch.
[20:07] <adeuring> kfogel: I've always used "ec2 test -s 'submit-messge'"
[20:07] <adeuring> kfogel: ...which would in our case also need the traget branch speciiftaion
[20:07] <kfogel> adeuring: that's all?  Don't we need to specify db-devel as the dest?
[20:08] <kfogel> :-)
[20:08] <adeuring> kfogel: yes
[20:08] <kfogel> adeuring: *nod*  okay, one sec, I'm writing the submit message
[20:08] <adeuring> kfogel: so, --pqm-submit-location=bzr+ssh://...
[20:09] <adeuring> but without a trailoing '/'
[20:09] <kfogel> adeuring: it's important that it be w/o trailing '/' ?
[20:10] <adeuring> kfogel: IIRC, pqm bails out if it sees a trailing '/'
[20:10] <kfogel> adeuring: ok
[20:11] <adeuring> kfogel: and you can't use the lp:~launchpad-pqm/... notation either. You must use bzr+ssh://
[20:12] <kfogel> adeuring: yeah, learned last night :-(     :-)
[20:13] <kfogel> adeuring: should I actually make an MP for lp:~kfogel/launchpad/patches-view-mega-integration ?  I don't see any need, really, but if I should I can.
[20:14] <adeuring> nah, i think that's not necessary
[20:19] <kfogel> adeuring: sanity check please:
[20:19] <kfogel> utilities/ec2 test --pqm-submit-location=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel --submit-pqm-message='[r=intellectronica,adeuring,allenap][ui=beuno][bug=506018,512500,516593,512498,516186] Implement a "+patches" view on packages, products, project groups, distroseries, persons, and teams.'
[20:19] <kfogel>
[20:19] <kfogel> (should we say just "series" instead of "distroseries" ?)
[20:19] <kfogel> oh, forgot jml and stub as reviewers, let me add them
[20:19] <adeuring> kfogel: i think it doesn't matter ;)
[20:20] <adeuring> kfogel: -...i mean the [distro]series stuff
[20:20] <kfogel> ok
[20:20] <adeuring> but right, stub and jml should appear in r=
[20:20] <kfogel> I made it "series" and added jml and stub
[20:20] <kfogel> utilities/ec2 test --pqm-submit-location=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel --submit-pqm-message='[r=intellectronica,adeuring,allenap,jml,stub][ui=beuno][bug=506018,512500,516593,512498,516186] Implement a "+patches" view on packages, products, project groups, series, persons, and teams.'
[20:21] <kfogel> Ready to launch? :-)
[20:21] <adeuring> looks good (ti my somewhat tired eyes ;)
[20:21] <adeuring> kfogel: yes, ready to launch to the pad
[20:22] <adeuring> erm, launch the pad ? from the pad?
[20:22] <kfogel> adeuring: wow, you are tired
[20:22] <kfogel> adeuring: :-)
[20:23] <kfogel> wow, instance taking a long time to start up
[20:30] <kfogel> adeuring: should I have done --headless?
[20:31] <kfogel> adeuring: I will need to be able to shut my laptop later... :-)
[20:31] <EdwinGrubbs> salgado-afk: ping
[20:32] <EdwinGrubbs> mars: ping
[20:32] <adeuring> kfogel: yes, --headless have been better,
[20:33] <adeuring> kfogel: so, just stop the current test and restart with --headless
[20:34] <kfogel> adeuring: yup
[20:35] <adeuring> kfogel: but make sure that the current instance is really goone in the AWS management console
[20:35] <kfogel> adeuring: why is it that, after I ^C in the terminal, *and* hit the "Terminate" button in elasticfox, the instance is still listed?
[20:35] <adeuring> kfogel: no idea...
[20:35] <kfogel> adeuring: if I hit the "don't show terminated instances" checkbox, then it goes away, which is reassuring, but still... oh well.
[20:36] <kfogel> not going to worry.
[20:36] <adeuring> just kill the instance in elasifox
[20:36] <kfogel> adeuring: I did, see above :-)
[20:37] <adeuring> kfogel: perhaps elastifox is simply slow in updating the machine status...
[20:37] <kfogel> adeuring: could be
[20:37] <kfogel> anyway, restarting with --headless
[20:39] <wgrant> bac: Bug 514074 concerns me.
[20:39] <mup> Bug #514074: PGP fingerprint registration fails to find key <pgp> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/514074>
[20:39] <wgrant> bac: All of the involved keyservers are contained within the DC.
[20:40] <wgrant> The synchronisation issues that sinzui speaks of should be nonexistent.
[20:40] <wgrant> And it's well over a few hours.
[20:40] <bac> wgrant: the keyservers were synced by IS a little while ago by pjdc
[20:40] <bac> wgrant: i'm not sure why this situation occured
[20:40] <kfogel> adeuring: I see this line in the output:
[20:40] <kfogel> ec2test@i-64584b0c$ bzr branch bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel /var/launchpad/test
[20:40] <kfogel> shouldn't that be db-devel?
[20:41] <adeuring> kfogel: hmmm
[20:42] <kfogel> adeuring: full output so far:
[20:42] <kfogel> http://paste.ubuntu.com/368440/
[20:42] <wgrant> bac: Are they regularly syncing now?
[20:42] <adeuring> kfogel: I think you're right -- but I assume that the ec2tests I ran today worked the same way
[20:42] <kfogel> adeuring: well, if they checked out devel, then folded your entire branch -- including the db-devel changes -- into the devel dest, I guess in theory that would wok.
[20:42] <kfogel> work
[20:43] <adeuring> right
[20:44] <kfogel> mwhudson: see paste above, and my question to adeuring a bit before that about "shouldn't that be db-devel?".  Are my ec2 tests abut to run on the wrong trunk?
[20:44] <bac> wgrant: i will follow up with IS after i verify the problem is gone
[20:44] <mwhudson> kfogel: did you run "ec2 test -b db-devel" ?
[20:44] <kfogel> mwhudson: nope, thanks
[20:45] <mwhudson> if you used -s, if the tests pass it will be pqm-submitted to devel, which will fail
[20:45] <kfogel> mwhudson: okay, terminating the instance and restarting.
[20:45] <kfogel> mwhudson: (I read the help for -b, and did not take away from that that it does what I know understand it does, though on re-reading it seems clearer -- hindsight is great)
[20:46] <kfogel> mwhudson: you mean "-b bzr+ssh://...lots of stuff/db-devel", not just "-b db-devel", right?
[20:47] <mwhudson> kfogel: i don't know all of the things -b does but i know what -b db-devel does :-)
[20:47] <mwhudson> kfogel: actually no
[20:47] <kfogel> mwhudson: literally "-b db-devel"
[20:47]  * kfogel breathes a sigh of relief
[20:47] <mwhudson> kfogel: literally "-b db-devel"
[20:47] <kfogel> At least something works kind of the way one would want :-).
[20:47] <kfogel> thanks
[20:48] <kfogel> mwhudson: about to re-start.  Does anything about this command strike you as wrong?:
[20:48] <kfogel> utilities/ec2 test --headless -b db-devel --pqm-submit-location=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel --submit-pqm-message='[r=intellectronica,adeuring,allenap,jml,stub][ui=beuno][bug=506018,512500,516593,512498,516186] Implement a "+patches" view on packages, products, project groups, series, persons, and teams.'
[20:48] <kfogel> mwhudson: uh, aside from that fact that you should also be listed in the reviewers, I mean! :-)
[20:49] <mwhudson> kfogel: i don't *think* you need the  --pqm-submit-location if you have "-b db-devel"
[20:49] <mwhudson> but that's just possible redundancy, not wrong
[20:49] <mwhudson> kfogel: go for it
[20:49] <kfogel> mwhudson: that would make sense.  It can't hurt, though.
[20:50] <kfogel> mwhudson: firing away; thanks for reviewing.  I added your name and henninge's to the r= list.
[20:50] <mwhudson> kfogel: cool
[20:50] <kfogel> adeuring: third try's the charm...
[20:58] <kfogel> mwhudson: I think I do need the full expansion of the db-devel URL after all; see http://paste.ubuntu.com/368452/ (search for 'bzr: ERROR: Invalid url supplied to transport: "lp:db-devel": No such project: db-devel')
[20:58] <mwhudson> kfogel: :(
[20:58] <kfogel> mwhudson: or at least the "lp:..." expansion
[20:58] <kfogel> if not the full URL
[20:58] <kfogel> easy enough to fix
[20:58] <mwhudson> kfogel: try -b launchpad=db-devel
[20:58] <kfogel> mwhudson: whoa, really??
[20:59] <kfogel> not this?
[20:59] <kfogel> utilities/ec2 test --headless -b lp:~launchpad-pqm/launchpad/db-devel --pqm-submit-location=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel --submit-pqm-message='[r=intellectronica,adeuring,allenap,mwhudson,henninge,jml,stub][ui=beuno][bug=506018,512500,516593,512498,516186] Implement a "+patches" view on packages, products, project groups, series, persons, and teams.'
[20:59] <kfogel> mwhudson:  I've never seen that "launchpad=foo" syntax before.    Kindly back away from the machinery.
[20:59] <mwhudson> kfogel: i have that in my shell history a few times, at least
[20:59] <mwhudson> (tbh, i mostly use ec2 land these days)
[20:59] <kfogel> mwhudson: above should work too, though, right?
[20:59] <mwhudson> kfogel: yes, it should
[20:59] <kfogel> ok
[21:00] <kfogel> fourth try now
[21:04] <kfogel> mwhudson: nope, fail again.  Your syntax may have been the way to go.  http://paste.ubuntu.com/368457/
[21:04] <mwhudson> kfogel: grrr
[21:05] <kfogel> mwhudson: trying your way now
[21:06] <kfogel> it's great, though: I'm accumulating all these terminated instances in my elasticfox.  I think of them like shrunken trophy skulls lined along my belt.
[21:06] <kfogel> Er, well, lined down my suspenders.  Anyway.
[21:15] <mwhudson> kfogel: you DO know what "suspenders" means in british english?
[21:15] <kfogel> mwhudson: oh, right, forgot
[21:15] <kfogel> mwhudson: s/suspenders/braces/ :-)
[21:15] <mwhudson> :-)
[21:15] <kfogel> mwhudson: success at last: http://paste.ubuntu.com/368469/
[21:16] <mwhudson> kfogel: yay
[21:16]  * mwhudson wanders off for a couple of minutes
[21:17]  * kfogel does same
[22:00] <thumper> mwhudson: ping
[22:06] <mwhudson> thumper: hi
[22:07] <thumper> mwhudson: can I get you to triage some of the new recipe bugs?
[22:07] <thumper> mwhudson: or actually any bugs :)
[22:07] <thumper> new ones that is
[22:08] <thumper> mwhudson: also, the priority on the incremental import work just got ratcheted up somewhat
[22:08] <mwhudson> thumper: ok
[22:08] <mwhudson> thumper: goodie
[22:08] <thumper> I'll tell you more when I'm back next week
[22:09] <mwhudson> thumper: ok
[22:10] <mwhudson> thumper: step 1 is done now
[22:10] <thumper> yeah, I saw that lnad
[22:10] <thumper> land even
[22:34] <lifeless> hey, who would be a good person to chat to about tweaking the CoC signing workflow
[23:25]  * mwhudson lunches


[05:58] <ob1> hi y'all !  i am not able to run linux exe on ubuntu
[05:58] <ob1> tried changing chmod +x .. but not working


[11:07] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2886 Needs rebuild due to higher version at destination
[13:27] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2895 Publishing packages
[13:56] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2895 Proposed pocket
[14:37] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2900 Preparing packages
[15:05] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2900 Needs rebuild due to new commits
[15:15] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2895 Release pocket
[16:10] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2900 Preparing packages
[16:42] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2900 Successfully built
[18:27] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2900 Publishing packages
[18:42] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2900 Proposed pocket
[19:42] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2900 Release pocket


[03:26] <_mup_> txzookeeper/session-and-conn-fail r44 committed by<EMAIL_ADDRESS>[03:26] <_mup_> watch delivery tests and some additional session expire tests
[11:27] <beber> hi
[11:27] <beber> I've got some problems with juju and the local provider
[11:28] <beber> I can't deploy more than a single service
[11:28] <beber> is this a bug ?
[12:08] <fwereade> hi beber, sorry I missed you, I was having lunch
[12:08] <fwereade> it may be a bug; would you describe what you're trying to do please?
[12:08] <beber> hi
[12:09] <beber> ok, I'm just trying to use juju with the local provider
[12:09] <beber> I'm using VirtualBox as a test machine (with Oneiric)
[12:09] <beber> Once juju is installed, I bootstrap the environment
[12:09] <beber> and deploy the mysql charm
[12:10] <beber> everything goes well, the mysql unit is started
[12:10] <beber> but then, when I want to deploy another charm or add a mysql unit, nothing happens
[12:11] <fwereade> nothing at all?
[12:11] <beber> (despite juju tells me "INFO 'deploy' command finished successfully"
[12:11] <beber> I use watch -n1 "ps afx | tail -n 45"
[12:11] <fwereade> ah ok, so when you "juju deploy wordpress" it claims to deploy but nothing happens
[12:11] <beber> exactly
[12:11] <fwereade> and similarly for "juju add-unit mysql"?
[12:12] <beber> yes
[12:13] <fwereade> beber, there are a couple of logfiles that might be helpful
[12:13] <fwereade> there should be a data-dir defined in your environments.yaml
[12:13] <beber> could you tell me which one to look at ?
[12:13] <beber> yes
[12:14] <fwereade> ah, hmm, just a sec, I have an alternatve "what's-going-on" command
[12:14] <fwereade> pgrep lxc| head -1| xargs watch pstree -alU
[12:15] <fwereade> but the interesting logfiles would be
[12:15] <fwereade> data-dir/units/master-customize.log
[12:15] <fwereade> data-dir/machine-agent.log
[12:15] <fwereade> ...and the output of:
[12:15] <fwereade> /usr/lib/juju/juju/misc/devel-tools/juju-inspect-local-provider
[12:15] <fwereade> would also be helpful
[12:16] <fwereade> beber, if you pastebin those over I will gladly take a look
[12:17] <beber_> sorry, wifi problem...
[12:17] <fwereade> beber_, np, I'll repaste it privately to avoid spam ;)
[13:34] <hazmat> good mroning
[13:34] <hazmat> morning
[14:19] <SpamapS> FYI, today I am going to switch the build recipe to use the packaging from Ubuntu (for natty -> precise) ... Maverick and Lucid had to have changes applied
[15:58] <jimbaker> fwereade, what if we used mixin instead of colo? to me, colocation sounds much more like placement as an equal on the same machine. which is important, just the other story :)
[15:59] <fwereade> jimbaker, that's quite nice
[15:59] <jimbaker> in any event, programming has a whole set of words we can choose from with these sorts of ideas
[16:00] <fwereade> jimbaker, I spent the afternoon writing an email trying to define a minimal set of changes to get this story up, and I started using the word "buff", which I've grown quite fond of
[16:00] <jimbaker> buff ;) ?
[16:00] <fwereade> it sounds magicy and geeky and has about the right meaning ;p
[16:00] <jimbaker> as in waxing something?
[16:00] <fwereade> nah, as in games
[16:01] <fwereade> casting a spell on something to give it more strength or speed or whatever
[16:02] <jimbaker> i see, this is very jargony however (never heard of that usage before), but it's there on http://www.urbandictionary.com/define.php?term=buff
[16:02] <fwereade> I have a theory that it's an immediately comprehensible name to a good proportion of our target demographic, but, er, I'm 0 for 1 so fr :/
[16:03] <jimbaker> fwereade, what if we used something like blend?
[16:03] <jimbaker> or maybe we can find words from potion making
[16:04] <fwereade> jimbaker, my quibble with that is that mixin/blend implies a two-way relationship, which is not necessarily applicable
[16:04] <fwereade> I also considered "aura" as a semi-appropriate magicy word, but it didn't seem to work so well
[16:04] <jimbaker> fwereade, actually that's the good thing about mixin, it's not 2 way at all
[16:05] <fwereade> jimbaker, in theory :)
[16:05] <fwereade> but I do take your point
[16:05] <jimbaker> well, again from its usage in programming, that's the case. but i may be the less target. i have never played a MMORPG
[16:06] <fwereade> jimbaker, you're not missing all that much (says the man who played WoW for 4 years ;))
[16:07] <jimbaker> fwereade, reality consumes enough of my time it seems
[16:08] <fwereade> jimbaker: yeah, RL is OK, but the surrounding of most major cities are totally overrun with farmers
[16:08]  * fwereade shamelessly steals a joke from somewhere he can't remember
[16:09] <jimbaker> :)
[16:10] <jimbaker> fwereade, so mixin sounds good, and if we can find a good charm-oriented synonym that connotes that little extra special (pixie dust, unicorn hair, powdered dragon bone), that would be nice
[16:13] <fwereade> jimbaker, sounds good :)
[17:02] <_mup_> txzookeeper/session-and-conn-fail r45 committed by<EMAIL_ADDRESS>[17:02] <_mup_> make the proxy easier to use as for blackholing communications, and verify session expiration with event and exception
[17:50]  * hazmat ponders failure
[17:53] <jimbaker> hazmat, sometimes we must fail before we can succeed ;)
[17:53] <jimbaker> i believe there are successories to consider too
[17:56] <SpamapS> failure is the only teacher really
[17:57] <hazmat> indeed its hard to model/test failure without the experiencing it
[17:57] <hazmat> i guess the team meeting got scrapped
[17:57] <SpamapS> speaking of failure.. I have been failing at reading email the last 3 days
[17:57]  * SpamapS implements more auto-labelling for sup
[17:57] <robbiew> I thought the meeting was punted to next week?
[17:57] <robbiew> SpamapS: filters...filters...filters
[17:58] <jimbaker> that's my understanding too
[17:58] <jimbaker> re meeting
[17:58] <hazmat> cool
[17:58] <hazmat> add-buff ;-)
[17:58] <SpamapS> robbiew: yeah, I'm finally giving in and implementing some
[18:02] <jimbaker> in my mind, 'juju add-mixin mysql logging' is not as obscure as 'juju add-buff mysql logging', but maybe i'll learn to like the obscurity
[18:03] <SpamapS> ** huge rocks fall from the sky and kill everyone.
[18:03] <SpamapS> fwereade: thank you for the LOLs
[18:18] <_mup_> txzookeeper/session-and-conn-fail r46 committed by<EMAIL_ADDRESS>[18:18] <_mup_> extant watches recieve errors on session expiration
[18:22] <hazmat> uh oh... exceptions.SystemError: error return without exception set
[18:23] <hazmat> bindings bug
[18:38] <_mup_> txzookeeper/session-and-conn-fail r47 committed by<EMAIL_ADDRESS>[18:38] <_mup_> capture a test case that exposes a bug in the libzk python bindings
[18:39] <careo> gl
[18:43] <careo> wrong window, sorry
[18:47] <hazmat> no worries
[18:47]  * hazmat debates the value of meta programming error handling
[18:48] <hazmat> generally not a good idea, but for a retry facade it seems appropriate
[19:44] <SpamapS> hazmat: I ran into a guy at ODS who said he had a lot of problems with libzk
[19:45] <SpamapS> hazmat: said he had developed a pure python ZK library because of it
[19:45] <hazmat> SpamapS, yeah.. the error handling is delciate, and without the twisted bindings, using libzk is painful imo, but in general its been pretty solid as of 3.3.3.. i contributed a few patches/bug reports upstream when we were first getting started
[19:47] <hazmat> SpamapS, most of it the issue is actually not the python zk binding, though there are some, but just understanding libzk itself.. i'd be curious to look at an alternative py lib though
[19:48] <hazmat> SpamapS, a few weeks ago i started another one zk python wrapper ( still built on py libzk) using a coroutine greenlet approach.. still its infancy though..
[19:48] <hazmat> ^in
[19:52]  * SpamapS imagines hazmat surrounded by bubbling flasks of liquid over bunsen burners and tubes
[19:53] <hazmat> SpamapS, at the moment its hp touchpads and hard drives for a nas ;-)
[19:57] <SpamapS> I need to bite the bullet and buy an SSD
[19:57] <SpamapS> Keep debating with myself about what size and whether to get two or one SSD and one honking big rotational drive. :-P
[20:02] <hazmat> SpamapS, i'm planning on  waiting for the new ocz onyx  and samsung 830s, should be out at the start of nov.
[20:02] <SpamapS> I don't really do the "wait for the best" thing
[20:02] <SpamapS> I do the "whatever costs me the least amount of time" thing :)
[20:03] <SpamapS> Right now 5400rpm is costing me time.. so I need an SSD now. :)
[20:49] <hazmat> SpamapS, talk about breaking backwards compatiblity ;-)
[20:53] <SpamapS> hazmat: which thing?
[20:53] <hazmat> SpamapS, the commit diff stuff
[20:53] <SpamapS> oh, well we can turn autocommit on for the first release. ;)
[20:54] <SpamapS> And its selective backward incompatible.. you can turn on the "old mode" if thats what your scripts expect. ;)
[20:56] <SpamapS> hazmat: we can also just punt that off to a wrapper if we have import/export
[20:56] <hazmat> SpamapS, why is this more repeatable?
[20:57] <hazmat> vs. just import/export
[20:57] <SpamapS> hazmat: because you get a single thing, in VCS, that is the exact way to repeat what you have
[20:57] <SpamapS> If you've had an env for 2 years, and youw ant to repeat, you don't want to repeat *every* deploy, add-relation, add-unit, remove-unit .. ;)
[20:57] <hazmat> so more of an oplog
[20:57] <SpamapS> the thing in vcs is the exported env
[20:57] <hazmat> vs. just load this graph
[20:57] <SpamapS> I think we're agreeing
[20:58] <SpamapS> give me exports and imports and I can implement this w/o juju's help
[20:58] <SpamapS> oplog would be a disaster. I want a snapshot. :)
[21:00] <hazmat> yeah.. if your building it on the graph, its not clear to me what the extra value is.. but i think my perspective is long, given the 2 year running env, with import/export, you just load up the export and your done. the distinction here is being able to verify the evolution of the system,
[21:00] <hazmat> so effectively a snapshot audit log
[21:00] <SpamapS> It could be done simply with user discipline
[21:01] <SpamapS> but I like the idea of being able to edit the local copy with the same commands you would use to edit the live copy
[21:01] <hazmat> hmm but all of the ops are effectively standalone transactions, ie. its not atomic
[21:01] <SpamapS> Yeah if one of them fails I understand, you can't back them out
[21:01] <SpamapS> --dry-run to the rescue? ;)
[21:02] <hazmat> yeah.. probably not, dry-run is effectively print the dump ;-)
[21:02] <SpamapS> with the import..
[21:02] <SpamapS> you'd need a way to tell the user what you're going to do to the env
[21:03] <hazmat> but actually understanding what its doing to the units is non starter unfortunately.. hooks are  binaries
[21:03] <SpamapS> like, I'm going to destroy service X, and create a new service called Xasdf... etc
[21:03] <hazmat> you can see what its doing to the env, but what its doing to the machines is a different matter
[21:03] <SpamapS> yeah thats more of an operational issue
[21:03] <SpamapS> if stuff fails.. you're going to have to resolve that yourself
[21:04] <SpamapS> But what the user needs to see is the *diff*
[21:04] <SpamapS> what is this import going to do to my environment?
[21:04] <SpamapS> With single commands.. you know.. because you're running them. ;)
[21:06] <SpamapS> Puppet goes through the same problem. --dry-run tells you its going to edit file X and put value Y in it.. but that may still fail for some reason
[21:06] <SpamapS> hazmat: anyway, export/import seems the key to repeatability
[21:07] <SpamapS> Ok well I've muddied the waters enough for today. Back to syncs and merges. :-p
[21:10] <_mup_> txzookeeper/session-and-conn-fail r48 committed by<EMAIL_ADDRESS>[21:10] <_mup_> a zookeeper client facade that transparently retries on various non fatal connection errors
[21:11] <hazmat> SpamapS, but the import itself is the diff
[21:12] <hazmat> i'd rather it just bail before attempting to modify anything existing in the env
[21:12] <hazmat> and just add a prefix op
[21:12] <hazmat> for importing it back into a running env that may have those existing services
[21:13] <hazmat> perhaps the delta application is useful and we can grow that, and a diff op against that
[21:16]  * hazmat goes back to pondering failures
[21:27] <hazmat> argh.. this is tricky
[21:36] <_mup_> txzookeeper/session-and-conn-fail r49 committed by<EMAIL_ADDRESS>[21:36] <_mup_> retry wrapper for watch methods, run the full client test suite against the retry facade via test subclass, disable white box tests
[21:41] <jimbaker> bcsaller, sorry i'm just re-reviewing statusd. would it be possible to address my review points? it does look like you have fixed things, but obviously a doublecheck would be nice
[21:42] <jimbaker> the more important thing: watch_status does not sufficiently watch the changes in the environment with respect to expose services and opened ports
[21:42] <bcsaller> jimbaker: I'll iterate in the proposal, thanks
[21:42] <jimbaker> these are not in the topology node
[21:44] <jimbaker> bcsaller, you probably should take advantage of the provisioning agent here. you don't want to redo the watch structure for expose. trust me on this ;)
[21:49] <jimbaker> bcsaller, this is actually a good requirement for the refactoring in bug 873108; you should be able to use the observer capabilities to register an interest in these changes. right now, they are just there to support testing, and support just one observer. multiple observers might be the right solution here
[21:49] <_mup_> Bug #873108: Move firewall mgmt support in provisioning agent into a separate class <juju:In Progress by jimbaker> < https://launchpad.net/bugs/873108 >
[21:50] <bcsaller> jimbaker: thanks, looking into it
[22:56] <jimbaker> bcsaller, the other thing to consider is the impact of https://code.launchpad.net/~fwereade/juju/dynamic-unit-state/+merge/79560, this will add more ways for the status to change
[22:57] <bcsaller> jimbaker: I'm thinking about the idea of us to chase these down, vs these somehow triggering a status change (touching /status to trigger the watch)
[22:58] <jimbaker> bcsaller, agent status is an ephemeral node, but its structure is not one easy to watch without recursive watches
[22:59] <jimbaker> bcsaller, but definitely the expose refactoring can do this triggering, via the observer mechanism
[23:01] <jimbaker> bcsaller, so agent status will definitely require more thought. this might be a good thing to point on its review, my first impression was that fwereade's branch was too big in scope
[23:17] <hazmat> woot it works
[23:18] <_mup_> txzookeeper/session-and-conn-fail r50 committed by<EMAIL_ADDRESS>[23:18] <_mup_> get_children_and_watch test with transparent retry on connection lost
[23:18] <SpamapS> hah.. wow.. I've been running my blog on 11.04 and now 11.10 for 8 months.. just now realized there's a massive incompatibility between wordpress 3.0.5 and the jquery version that natty and oneiric have
[23:19] <SpamapS> Just figured my drizzle mods were causing the problems
[23:33] <_mup_> txzookeeper/session-and-conn-fail r51 committed by<EMAIL_ADDRESS>[23:33] <_mup_> additional transparent retry tests with watchers, remove bad session test based on erroneous upstream faq entry.
[23:42] <_mup_> txzookeeper/session-and-conn-fail r52 committed by<EMAIL_ADDRESS>[23:42] <_mup_> remove management of the connected attribute on clients from error handler, libzk is going to be transparently reconnecting under the hood, also supports retry much better