#launchpad-yellow 2011-06-27
<bac> gmb: i notice on lp2kanban the board is now optional and if not provide will update all boards.  is that in preparation for supporting multiple teams/boards?
<gmb> bac: Yes.
<gmb> The version that's running on my VM still just runs -b yellow.
<bac> gmb: it just looks funny to update yellow and yellowtest.  to do multiteam we'll have to have a super LKK user who has access to all boards.  don't know it that exists atm.
<gmb> Ah, good point.
#launchpad-yellow 2011-06-28
<gmb> benji, danilos, gary_poster, bac: Apologies if you're getting spam from lp2kanban... for some reason all updates seems to trigger emails, even if there's no actual state change on the card. Nothing to do with us, but I've received duplicate messages an hour apart.
<benji> gmb: no worries
<bac> i haven't seen anything gmb
<gary_poster> gmb, no prob.  I think the problem is that we don't sort tags, so changing a card may reorder tags, which will trigger an email
<bac> gmb: are you changing the code?
<bac> gary_poster, gmb: we sort the tags now, if you grab the latest
<gary_poster> bac, oh, yay!
<bac> one-line change
 * gary_poster hopes that this is the problem
#launchpad-yellow 2012-06-25
<gary_poster> bac benji frankban (gmb sprinting) hiya: https://plus.google.com/hangouts/_/4bd3b7cfd27f6147267f7436311fa84bc45f94b4?authuser=1&hl=en-US as soon as you can
<benji> I'm back.
<bac> hi gary_poster.  i was reading jml's project start page and saw the note he had about their pre-commit pep8 checker.  we're not decided we want such a thing but i thought it would be a nice exercise so i'm trying to add it to a branch of lpsetup.
<gary_poster> +1 bac
<bac> gary_poster: however it relies on pep8.py from pypi.  i've tried cargo-culting some buildout stuff but cannot get pep8 to download
<bac> might you have some tips?  i've tried this: http://pastebin.ubuntu.com/1059070/
<gary_poster> bac, the buildout stuff in lpsetup is a nasty decoy
<bac> i hoped, adding in a versions.cfg with pep8 in it would do the magic.  it does not
<bac> ho
<bac> oh
<gary_poster> bac, it should be removed (right frankban?)
<frankban> gary_poster, bac: indeed.
<bac> gary_poster: if it is removed, how would you suggest i proceed?
<gary_poster> frankban, if bac wants to add a dependency, he should add it to setup.py and then...?
<gary_poster> use a virtualenv aiui
<gary_poster> and then...? :-)
<gary_poster> we should write this up, in a HACKING or in a page linked to by HACKING.  Moreover, it may be that buildout is the Preferred Technology for this (notice capitalization) and we'll have to conform
<gary_poster> But for now...
<frankban> gary_poster, bac: never used, but I've found this project: http://pypi.python.org/pypi/tissue/0.3
<gary_poster> frankban, oh, should not go off on a new tech for this
<gary_poster> if at all possible
<gary_poster> I hoped/assumed there would be instructions like thisL
<gary_poster> :
<gary_poster> 1) add to setup.py
<gary_poster> Scratch that, trying again
<gary_poster> 1) setup virtualenv
<gary_poster> 2) get lpsetup
<gary_poster> 3) add dependency to setup.py
<gary_poster> 4) run python setup.py build
<gary_poster> or some other similar tool
<gary_poster> frankban, oh I see what you mean, now that I actually looked at project.  So...that's something else we need to know how to do
<gary_poster> bac, do they have a custom pre-commit pep 8 checker, or are they using some standard?
<gary_poster> must be a standard of sorts since also getting it from pypi
<gary_poster> http://pypi.python.org/pypi/pep8/
<gary_poster> and tissue is actually ay 0.7
<gary_poster> at
<gary_poster> http://pypi.python.org/pypi/tissue
<gary_poster> and uses pep8.py
<bac> gary_poster: jml refers to http://bazaar.launchpad.net/~canonical-ca-hackers/ubuntu-webcatalog/trunk/view/head:/src/webcatalog/tests/test_pep8.py
<gary_poster> oh :-(
<gary_poster> oh
<gary_poster> so that's just a separate test
<benji> does pocketlint do pep8 checking?
<gary_poster> so another approach
<gary_poster> benji, it does not advertise pep8 explicitly, and it does not use the apparently "standard" pep8.py if its setup.py is to be believed
<gary_poster> bac, I think we are supposed to want pip, and I think we are about to fall off the cliff of "python packaging sucks"
<benji> hmm
<bac> gary_poster: so wanting to add one dependency cause use to go off the cliff?
<bac> s/cause us/ causes us
<bac> ergh, can't even type my corrections properly
<gary_poster> bac, you got it, because if we are trying to do it "right" that means we have to define what "right" means.  Although, if pep8 is packaged in debian we can look the other way...checking
<benji> I for one don't want pip. :)  As far as I have seen, it is inferior to buildout for the use cases I care about
<gary_poster> bac, pep8 is packaged in debian.
<gary_poster> quick, jump on that plane, and run away!
<gary_poster> benji, buildout is dying.  Jim and /me killed it, unintentionally.  He didn't want to maintain it, and I went off in a direction no one wanted, and it's been in an essentially broken state for...years now?  Meanwhile, the self-proclaimed and generally appreciated "python packaging experts" have declared virtualenv (going into Python as you know) and pip as The Standard.  See for instance the bottom of http://pack
<gary_poster> ages.python.org/distribute/ .
<gary_poster> Meanwhile, at Canonical, noone wants to actually pay attention.  They want system python and deb packages to be the standard for us
<benji> Yeah, I have accepted it as inevitable that buildout will never be popular.  I still think it is often the best tool for the job, even if we have to use different tools for political reasons.
<gary_poster> essentially broken: my evidence is that there are three trunks.  We use 1.5.x.  Others use 1.4.x.  jim uses 2.alpha.x
<gary_poster> fair enough, my argument had 0% content about "best tool for the job" except insofar as swimming along with the stream is generally better unless you are in the business of making streams.
<gary_poster> bac, can you make setup.py declaration plus deb dependency work for you?
<bac> gary_poster: geez, it is 'pep8' not 'python-pep8' so i didn't see it.
<gary_poster> yeah I got tripped up by that too, sorry, should have mentioned
<bac> gary_poster: perhaps.  i'm looking at it now.
<gary_poster> apparenty nose and testtools are somewhat in competition, apparently
<gary_poster> that's bad because nose wins in any popularity contest
<benji> I like that: "[S]wimming along with the stream is generally better unless you are in the business of making streams."
<gary_poster> :-)
<gary_poster> oh look, someone-probably-Robert broke sourcedeps.conf by adding extraneous newlines.  joy.
<frankban> gary_poster: if we want to switch to pip+virtualenv then we have to distribute shelltoolbox on pypi. tissue is broken and doesn't work with the last pep8. :-/
<gary_poster> frankban, good to know, and that confirms my desire to not add new untrusted dependencies.  We can add pep8 with debian, and add the test as a standalone test the way bac said jml is doing it: http://bazaar.launchpad.net/~canonical-ca-hackers/ubuntu-webcatalog/trunk/view/head:/src/webcatalog/tests/test_pep8.py
<gary_poster> I kind of prefer the tissue approach actually
<frankban> gary_poster: however the lpsetup code broke some pep8 rules we usually break in our launchpad guidelines: e.g. "E123 closing bracket does not match indentation of opening bracket's line". but you can setup pep8 to ignore some rules...
<gary_poster> but I don't want to add another low-popularity dependency if we can help it
<gary_poster> ack
<gary_poster> I will not be surprised if people in Canonical point to lxc instead of virtualenv for package development and testing.
<gary_poster> For Ubuntu packages, that makes some sense
<gary_poster> lxc and debs rather than virtulenv and eggs, I mean
<bac> gary_poster: i'm a bit confused about how to specify debian packages in setup.py and i find the docs less than helpful.  can you shed some light?
<frankban> bac: you can't afaik.
<bac> on call
<gary_poster> bac, correct, you cannot.  This would be a machine or lxc setup.  The setup.py assertion would just be for politeness, and maybe for pip if you did it right.
<bac> gary_poster: diogo's tarmac & jenkins work runs in the QA lab.  access is available only via openvpn.  i need to request the QA lab admin to generate openvpn certificates via an rt.  i suspect all of yellow needs access.
<gary_poster> bac, all of LP needs access
<gary_poster> we need it now
<gary_poster> but we will be handing over maintenance to the team as a whole
<bac> gary_poster: would you like to reply to that RT requesting access for everyone or do that later?  i'd prefer not to be too broad if it is going to delay getting yellow access in place.
<gary_poster> bac, understood.  Two thoughts so far.
<gary_poster> First, if we have a constrained initial set, it should include Robert and Francis and Diogo and Matthew just in case
<bac> diogo and matthew already have access
<bac> as does francis
<bac> here is the initial RT for access: https://rt.admin.canonical.com//Ticket/Display.html?id=53196
<gary_poster> Second, we should make it clear what our long term request is, IMO.  In other words, we could say "eventually, we would like all Launchpad maintainers to have access.  However, initally, only the yellow squad needs access now.
<gary_poster> OK
<gary_poster> Will go look
<gary_poster> bac, that's resolved--looks like we should have a new RT?
<bac> gary_poster: i filed a new rt and cc yellow on it 8 minutes ago
<gary_poster> oh..
<gary_poster> have not received
<bac> at least i intended to cc yellow.  let me forward.
<gary_poster> k
<bac> brb
<gary_poster> k
<gary_poster> bac, do you have permission to see https://rt.admin.canonical.com//Ticket/Display.html?id=53930 ?
<bac> gary_poster: i do not.  troubling.
<gary_poster> bac, apparently using "yellow" as rt CC is not a good idea.  We should do it individually
<gary_poster> (the one I asked you to look at is the one I filed)
<bac> gary_poster: but i filed it.  i would think i could read
<gary_poster> bac, yours is https://rt.admin.canonical.com//Ticket/Display.html?id=53963
<gary_poster> I can't see it
<gary_poster> but I expect you can
<gary_poster> I am going to ask flacoste to clear it up in RT for those two tickets
<bac> gary_poster: oh, right, i can see the old one: https://rt.admin.canonical.com//Ticket/Display.html?id=53930
<bac> logged in as warthogs
<bac> gary_poster: but i cannot see the new one i just filed
<gary_poster> oh
<gary_poster> huh
<gary_poster> I am logged in through openid bac
<gary_poster> bac, I bet you could see the one you filed if you logged in via your openid
<bac> gary_poster: hangout for a sec?
<gary_poster> sure
<gary_poster> you doing it, or shall I
<gmb> HALLO.
<gmb> Or
<gary_poster> HALLO
<gmb> Goedemiddag
<gary_poster> heh
<gmb> gary_poster, re: goals: I haven't been able to get into CA. I will ping the admin team about it.
<gary_poster> gmb: cool, lemme know if I should get involved
<gmb> Ok
<frankban> benji: do you have a minute?
<benji> frankban: sure
<frankban> benji: hangout? https://plus.google.com/hangouts/_/1c0ef54f3bef4cfa99dfeced5fb3af2621bbb66a?authuser=0&hl=it
<gmb> gary_poster, FWIW, jam tells me that both he and Francis have been having problems with HRa, and dragnob is aware of it and dealing with it.
<gary_poster> ok cool gmb thanks for heads up
<bac> gary_poster: https://portal.admin.canonical.com/53963
<gary_poster> bac, I just noticed myself, thx :-)
<gary_poster> frankban, I should create a different card for subcommand smoke tests, right?  What you are doing now is similar, but different?  Or should we really regard these as smoke tests?
<frankban> gary_poster: I am writing tests for expected steps and handlers for each subcommand
<gary_poster> I know.  :-)
<gary_poster> Is your point, you don't know whether we should we call them smoke tests or not, but they are good to have?
<frankban> yes gary_poster :-), and I am a bit confused about what kind of smoke tests you were thinking about
<gary_poster> frankban, I'm inclined to say that what you are doing now plus some simple "does the --help option work for all commands" test is a good start.  what kind of smoke tests: I'd like us to be confident that each command can be called (initialized).  The --help does that.  What you are doing is a bit more sophisticated.  I'd say it lets us be confident that each command seems to do broadly what we expect, to the degr
<gary_poster> ee that the names of the steps clarify that.
<benji> they seem more like non-smoke tests to me.  My definition of a smoke test (which was I did not just totally make up while typing this line) is that a smoke test just tells you that nothing went wrong and if something does go wrong, it tells you nothing about what in particular it was
<gary_poster> However, unless I misunderstand, it does not let us know whether the command will work at all.
<gary_poster> benji, my understanding was that a smoke test was less about only giving a small amount of information as to a failure, but about whether roughly things seem to be working at all.  Maybe I'm completely off base.
<gary_poster> For me, the --help is a smoke test because if it fails, we know things are not hooked up well enough for the command to run at all.
<gary_poster> Given the tests frankban is adding, I'd feel comfortable even simply checking whether the return code was 0
<benji> gary_poster: right (the bit about being helpful is only a corrolary: "real" tests should point you in a direction, smoke tests are under no such burden)
<gary_poster> cool
<benji> (agreed on the --help bit; it is a smoke test, and -- I think -- a good one)
<gary_poster> cool.  so benji, frankban, I'll add a card to add tests that verify that "lpsetup COMMAND --help" returns with a 0 for all commands.  If you disagree or have a better idea, lemme know. :-)
<benji> +1
<benji> if we had a --dry-run switch for all commands, that would be a good smoke test too (to help show import errors, name errors, missing command-line parameter processing, etc.) but it's too much work to add just for a smoke test (real tests would probably be less work and more valuable)
<frankban> gary_poster: +1, with the -h option you test that the command is correctly registered to the parser, and that the arguments make sense (no clashes, basically), so it adds value.
<gary_poster> cool, thanks guys
<bac> gary_poster: how do you get virtualenv to handle dependencies that are only available as debian packages, e.g. python-shelltoolbox?
<gary_poster> bac, option 1 is you tell virtualenv to allow all the system packages through.  See --system-site-packages
<gary_poster> bac, option 2 is to get the source for python-shelltoolbox and use it.  pip seems like it has the option to specify bzr branches, for instance
<bac> gary_poster: ok, option 2 implies pip-ing which i wasn't sure i was going to do
<gary_poster> right
<gary_poster> I assumed option 1, bac, I must admit.
<benji> if anyone wants to review an lpsetup branch (we really should canonicalize its name, we have "lpsetup" in some places and "lp-setup" in others) I would appreciate it: https://code.launchpad.net/~benji/lpsetup/add-get-subcommand/+merge/111904
<benji> bac: is there anything I can do to help with tarmac?
<bac> benji: i don't think so
<benji> k
<bac> benji: i'll review your lpsetup branch.  when it is approved please don't merge it.  let me see if i can get a manual run of tarmac to do it
<benji> bac: k
<bac> benji: approved.  please make the changes, pushed, and set the MP to approved and then i'll try running tarmac
<benji> bac: will do
<benji> bac: the MP is ready for you
<bac> cool
<bac> benji: Merging lp:~benji/lpsetup/add-get-subcommand into lp:lpsetup failed: Unapproved changes made after approval
<benji> bac: you are technically correct, the best kind of correct (so says tarmac)
<benji> bac: I guess you should add another approve=code comment
<bac> i marked the whole MP.  let's see if that works
<benji> bac: I had already marked the MP as approved
<bac> benji: before or after you pushed the post-review changes?
<benji> bac: after
<bac> weird.  it now correctly notes r34 is the approved version
<benji> bac: hmm, but the page says that 33 was the approved revision; I wonder if firefox and bzr were in a race and I lost
<bac> it says 34 now
<bac> on the MP page
<benji> I see that 34 is the approved revi... right
<bac> benji: so tarmac happily merged your changes...into a local branch on my machine.  that's not so helpful
<benji> :)
<bac> so am i supposed to manually do a 'bzr push' after tarmac does its thing?  i thought that was the whole point
<bac> i hate projects that have docs that are a little too clever...and then don't actually do what is advertised
<bac> benji: so on my second try it actually merged your branch
<benji> idempotent
<bac> benji: it is weird.  there is tree_dir settting, that lets you set where you want the local copy of the project's trunk to be
<bac> with tree_dir = /var/cache/lpsetup
<bac> it only merged locally.  i later found an example that made more sense so i changed to
<bac> tree_dir = /var/cache/tarmac/lpsetup/trunk
<bac> with that setting it actually did the landing.  odd.
<benji> yeah, I don't understand that
<gary_poster> bac, reviewed https://code.launchpad.net/~bac/lpsetup/sansbuildout/+merge/111942 .  I started crying a little bit, but then managed to hold it in.
<bac> gary_poster: it'll be ok
<bac> gary_poster: yay, merged by tarmac with nosetests run as pre-commit hook:  https://code.launchpad.net/~canonical-launchpad-branches/lpsetup/trunk
<bac> [bug=] is kind of gross but not easily solved
<gary_poster> bac, yay!
#launchpad-yellow 2012-06-26
<gary_poster> (bac out) benji frankban (gmb sprinting) https://plus.google.com/hangouts/_/af560291cc6180166d05d115d54a449ab5dab277?authuser=1&hl=en-US
<frankban> gary_poster or benji___ : could you please review https://code.launchpad.net/~frankban/lpsetup/commands-unittests/+merge/112094 ?
<benji> frankban: I can in a few minutes.
<frankban> thanks benji
 * benji wonders how his nick got to be "benji__", but enjoyed kicking the imposter "benji" off freenode anyway.
<gary_poster> :-)
<bac> tarmac should be working now.  frankban please let it merge your MP after review.
<bac> gary_poster: i'm back home but can't really see.  will go sit in a dark room for a little while
<frankban> ok bac
<gary_poster> ok bac, relax
<bac> gary_poster: good news though.  no visible problems. told me to go home and not come back for a year
<gary_poster> excellent, bac
<gary_poster> bac, when you return, let's get those goals take care of in allhands
<gary_poster> gmb, when you see this, please let me know how allhands is going for you
<gmb> gary_poster, Haven't tried today, will do so in the next half hour or so
<gary_poster> great gmb, thanks
<benji> frankban: I have commented on https://code.launchpad.net/~frankban/lpsetup/commands-unittests/+merge/112094
<frankban> thanks benji: reading
<frankban> benji: thanks for the comments, I will change the branch as you suggested. Only a question: how do you suggest to implement the get_arguments in the subcommand tests? Actually I am reusing arguments (e.g. test_install calls test_inithost.get_arguments)... so, class/static methods? Testcase subclasses?
<benji> frankban: I figured it would just be the body of the module-level get_arguments, but as a method instead.  Did I miss something?
<frankban> benji: we can have TestCase.get_arguments(self), but then we should continue supporting the story of another testcase reusing the arguments returned by the first testcase (e.g. InstallTest.get_arguments(self) should call and extend Inithost.get_arguments(self)). If I am not wrong, we can 2 this in 2 ways (that I can think now): 1) having one testcase as a subclass of another (so, use super and then extend)
<frankban>  or 2) use class methods, so we can call AnotherTestCase.get_arguments()
<benji> frankban: ah, I think I see why you went with the original solution then.  I agree that leaving it as-is is best.
<frankban> cool benji
<frankban> benji: branch updated following your suggestions.
<benji> cool; looking
<benji> frankban: looks great, approved
<frankban> thanks benji, I will approve the mp and wait for tarmac to do the rest.
<benji> I, for one, welcome our new branch-landing overlords.
<benji> frankban and gary_poster: I have the smoketest branch up for review at https://code.launchpad.net/~benji/lpsetup/bug-1017973-add-smoke-tests/+merge/112141
<frankban> benji: looking
<benji> thanks
<gary_poster> thanks
<frankban> hum...still waiting for tarmac...
<gary_poster> bac, is tarmac alive?
<gary_poster> I want to start adding the workaround to bug 1014916 and bug 1013921 to lpsetup.  I think it is kinda safe because Graham is out this week, and because I ought to be able to get people to help me if I slow down, and I think it ought to be fast.
<_mup_> Bug #1014916: simultaneously started lucid containers pause while starting after the first seven <lxc (Ubuntu):Confirmed> < https://launchpad.net/bugs/1014916 >
<_mup_> Bug #1013921: our zope.testing fork needs to emit subunit time immediately before test start and immediately before test completion <paralleltest> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1013921 >
<gary_poster> It goes against the rules...
<gary_poster> I'm gonna do it, and ask Brad to work with me on it when he returns
<frankban> gary_poster: cool. tarmac is not merging my branch, maybe this is because rhere wasn't a commit message at the time I approved it?
<gary_poster> frankban, maybe not.  I dunno.  Can I do anything to help?  You could try adding the commit message and then unapproving and then reapproving, maybe?
<frankban> gary_poster: trying
<gary_poster> frankban, if that fails, merge manually.  we can iron out the wrinkles later when someone has access to the tarmac machine
<frankban> gary_poster: yes, I will wait for 2 minutes and then merge manually
<gary_poster> ok cool
<frankban> gary_poster: maybe I should have asked this before: when I review lpsetup branches, should I follow the usual steps for a mentored reviewer (i.e. request Raphael review)
<gary_poster> frankban, um.  :-D  Can I pretend you didn't ask me that? ;-)  The thought had quietly occurred to me before, and I thought that it would be nicer and easier and quite reasonable if we did not go through the mentoring for this project.  That said...
<gary_poster> I suspect the proper thing to do is to go through the mentoring process.
<gary_poster> If I pretended the question didn't exist then I didn't have to do the proper thing :-P
<gary_poster> I know!  Let's ask Brad when he returns.  he's the reviewer god.  or was, once.
<gary_poster> So meanwhile frankban, continue reviewing lpsetup without mentor.  We'll ask Brad for his judgement later.
<frankban> hum... ok gary_poster, and we could still forget to ask him...
<frankban> :-)
<gary_poster> frankban, what was that?  did you say something?  Were we talking about something?
<frankban> about the weather I guess...
<frankban> and tarmac merge my branch.
<frankban> merged
<gary_poster> :-) cool
<frankban> benji: approved,  I've added just a comment.
<frankban> gary_poster: I am looking at the card "rename validators to handlers". we already have a handle() method in the subcommands that can generate confusion, do you agree in also renaming handle() to run()?
<gary_poster> frankban, lemme look at code, one sec
<gary_poster> frankban, so handle->run and handler->runner?
<gary_poster> (in argparser)
<frankban> no, handle -> run, validate -> handle_namespace (or similar), handler remains handler
<frankban> and, validators -> handlers
<gary_poster> ok, trying to get my head around that
<gary_poster> right, ok.  So handlers.py contains (validators -> ) handlers...and
<frankban> gary_poster: currently the handlers are called validators in argparse: we have a validators class attribute, a get_validators() method, a validate method that actually runs the handlers. we should rename all these attrs and methods.
<frankban> but...
<gary_poster> right, validate becomes handle_namespace or prepare_namespace, and is fir handler in self.get_handlers(namespace): try: handler(namespace); except ValidationError as err: parser.error(err)
<gary_poster> (IOW, ValidationError remains, and handlers raise it)
<frankban> yes
<frankban> I was suggesting to rename handle() to run() to avoid confusion, because handle() does a different thing: it runs the steps.
<gary_poster> frankban, right, I agree with that, but then why should handler (in register_subcommand and BaseSubCommand) remain handler?  It is either the "run" method or something else designed to run the subcommand's steps, right?  Calling that a handler seems another very similar confusion
<gary_poster> BaseSubCommand.__init__ in particular, I mean
<gary_poster> I don't love "runner"
<gary_poster> but I like it better in that context than "handler" I think
<frankban> gary_poster: ah! I see, yes... what about "callback"?
<gary_poster> frankban, I like that, yeah
<gary_poster> frankban, and all the rest you said makes sense to me now too, fwiw, so +1
<frankban> cool
 * benji returns from lunch and looks at the MP review.
<benji> Laura Czajkowski's change of the smoke test bug importance from Undecided to High confuses me.  Was that a bot, perhaps?
<frankban> hum...
<gary_poster> benji, no, she is responsible for triaging, just as we were when we had community rotation or whatever it was called.  We are not allowed to have untriaged bugs in the LP project and lpsetup is an LP project.
<gary_poster> "high" is the correct triage in fact: it is not critical, but we intend to do it now.
<benji> ah, that makes sense
<gary_poster> correct at least according to our LP definitions of course
<benji> yeah, my main confusion was to why she was doing anything, but since it is part of LP, it makes sense
<benji> confusion relieved, tragedy averted
<gary_poster> :-)
<gary_poster> frankban, are you quitting now?  I have a question for you but I don't want to keep you
<frankban> gary_poster: no problem, please ask
<gary_poster> ok thanks.  So, I want to add a --lxc option to inithost.  When you use that option, it will run a separate step that installs things specific to the host only if it is an lxc container.  (Then lxcinstall will include that option.)  I intend to do this by adding an lxc step, and then adding an lxc argument and then adding a call_lxc that only calls the step if the argument is included
<gary_poster> what do you think of that?
<gary_poster> frankban, ^^
<gary_poster> I'll be right back
<frankban> gary_poster: I think it's right. FWIW I've used the dynamic dispatcher in the same way for create_scripts in lxcinstall
<gary_poster> frankban, ok cool thank you!
<frankban> welcome, have a nice evening!
<gary_poster> you too :-)
<benji> well, that was fun.  I had to restart my machine to get networking to work again
<bac> hi gary_poster, i'm looking at your suggestion about piotr's method.  i don't really see that it buys that much and adds an unexpected command line option.  i'd vote for not doing it.
<gary_poster> hey bac
<gary_poster> cool
<bac> and you've got to remove it from sys.argv before calling setup() or it gets angry
<bac> minor
<gary_poster> bac, what it buys, apparently, is that you can use the system's setuptools if it is installed
<gary_poster> as it usually is
<gary_poster> on Ubuntu
<gary_poster> (where setuptools == distribute)
<bac> oic
<gary_poster> so, isn't that something of value?  Note that another way to approach this is to run screaming to barry, who IME will make you feel better at the very least, even if there aren't any options ATM.  He write that email not very long ago though
<gary_poster> aren't any good/approved/official options, I should say
<gary_poster> he's probably doing something reasonable for his flufl things
<gary_poster> let's see...
<gary_poster> bac, :-/ http://bazaar.launchpad.net/~barry/flufl.i18n/devel/view/head:/setup.py
<bac> so your point being barry has punted like us mortals?
<gary_poster> bac, precisely
<benji> bac: are we in all tarmac, all the time land now?  In other words, do I have to manually land my lpsetup branch or will tarmac do it for me?
<bac> benji: don't land.  i have it running as a cron job but am having some problems with gpg-agent
<bac> benji: either it will land via the cronjob or i'll do it by manually running tarmac
<benji> k
 * benji laments that his beeper still needs AC power to work
 * gary_poster goes to have lunch, a bit late.
<benji> I really like having tarmac.  It has already saved me from comitting with failing tests.
<gary_poster> yay!
<bac> benji: yeah, i saw that.  cool.  yours is committed now.
<bac> benji: distribute_setup.py is dirty too
<benji> Is that distribute's version of ez_setup.py?  Do we need either of them?
<gary_poster> benji, yes; and it depends.  I added a "pain" topic for bac to talk about the packaging annoyances on Friday.
<benji> cool
<bac> benji: hey, tarmac makes me look busy:  https://code.launchpad.net/~benji/lpsetup/bug-1017973-add-smoke-tests/+merge/112141
 * bac needs to make a new LP user for tarmac
<benji> :)
 * bac ponders --swedish-chef option for tarmac
<gary_poster> heh
<bac> gary_poster: it is time for me to switch to a 'bot user in LP for tarmac to use.  can you think of an appropriate one to re-use or just create 'yellow-tarmac', 'yellow-robot', etc?
<bac> actually it should not be yellow-specific, of course
<gary_poster> um
<gary_poster> bac, lp-tarmac?
<gary_poster> bac, I wonder who diogo is using
<gary_poster> on call with flacoste
<bac> were he not off stuffing his face with crepes and red wine i would ask him.  (diogo, not francis)
<gary_poster> lol
 * bac </jealous>
<bac> ok, i'll suffer with my user id until tomorrow
<bac> gary_poster: damn homonyms
 * bac intrigued that "skillz" got by your spellchecker
<gary_poster> :-)
<gary_poster> heh
<gary_poster> skillz seemed humorous
<gary_poster> vain seemed unintentional
<bac> yes, quite.
<bac> i remember in grade school the teacher was talking about homonyms.  she had the hardest time convincing us that "pin" and "pen" were not pronounced the same.
#launchpad-yellow 2012-06-27
<gary_poster> :-)
<gary_poster> frankban, approved your MP, with a small typo change.
<gary_poster> frankban, oh, after you make the change let me know and I'll approve again, or you can approve.
<gary_poster> (and after that, change the MP to Approved)
<frankban> gary_poster: thanks
<gary_poster> welcome, looked great
<frankban> gary_poster: typo fixed.
<gary_poster> reapproved frankban
<frankban> cool, approving the MP
<bac> gary_poster: doing another approve vote doesn't tickle tarmac.  only changing the top status of the MP does
<bac> nm
<bac> :)
<gary_poster> :-)
<gmb> gary_poster, What's the secret sauce for forcing the buildbot-slave to have a specific number of workers?
<gary_poster> gmb, look at master.cfg on master, at --concurrency option in testr call
<gary_poster> currently forced at 20
<bac> gary_poster: do note the second vote was not necessary
<gmb> gary_poster, Awesome, ta.
<gary_poster> bac, I thought it was in order to have tarmac not complain that there was a revision that had not been approved?
<bac> i just don't want people thinking they have to revisit the MP
<bac> gary_poster: no, the approved revision gets noted when the top-level status goes to 'Approved'
<bac> your reviews are just votes
<gary_poster> bac, oh!  ok cool
<gary_poster> I voted twice.  Watch out for the chads.
<bac> tarmac uses the rule 'approves >=1, disapproves == 0' so one bad vote will keep it from landing
<bac> that's why we need picture IDs for voting
<gary_poster> bac benji frankban (gmb) https://plus.google.com/hangouts/_/6bdd991b10f6aa1b4f28efb196620126c5f443ec?authuser=1&hl=en-US
<gary_poster> gmb, still allhands problems?
<gmb> gary_poster, I signed in this morning but can't get to my goals... I'm going to talk to Sarah about it this afternoon; ISTR that hte last time we had this problem she was happy with an email to you and her with my update goals - it's the record that matters.
<gary_poster> bac, allhands is ready for your final handshake
<bac> gary_poster: will do now
<gary_poster> gmb, ok.  the deadline is Friday, so please take some time aside today and get it sorted out for good one way or another.
<gmb> Right.
<gary_poster> gmb, also, replying to your python 2.7/parallel email now
 * bac still hates google authenticator.  i wonder if it got hacked along with the RSA fob
<gmb> Thanks.
<gary_poster> :-)
<gmb> gary_poster, We have a working parallel test instance on Py2.7 / Precise: http://ec2-23-22-155-23.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/0. Limited to 8 workers.
<gmb> gary_poster, Tests are running, which is new :)
<gmb> But we're seeing "unknown worker" tests.
<gmb> Which is sad-panda-making.
<gary_poster> gmb, will review in a sec.  I got this error when starting up the charm:
<gary_poster> 2012-06-27 11:53:30,606: hook.output@ERROR: Command '['su', 'buildbot', '-c', "bzr branch 'http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel' /var/lib/buildbot/slaves/slave/devel"]' returned non-zero exit status 3
<gary_poster> seems transient
<gary_poster> Was just going to retry
<gary_poster> Is that what you had before?
<gmb> gary_poster, No, I had problems with adding the buildbot group.
<gary_poster> weird
<gmb> destroy-environment and bootstrappign again worked.
<gary_poster> yeah I think I'll just retry also
<gary_poster> gmb, what size machine is the slave?
<gary_poster> it looks too small for 8
<gary_poster> you are losing three of eight workers still
<gary_poster> I'd also guess that the first of the two errors you have in the summary so far are because the machine is underpowered
<gmb> gary_poster, Yeah, it's an m1.small. My mistake; I forgot to make it bigger. Yesterdays was a 32-core machine.
<gary_poster> ow
<gmb> Yeah.
<gmb> But, weirdly, this works (ish).
<gmb> Yesterday's didn't.
<gmb> gary_poster, So at this point, I'm going to see what else breaks on our woefully underpowered machine
<gary_poster> gmb, you could try shrinking concurrency down further, but that's smaller than I've ever used
<gmb> Right.
<gary_poster> gmb, as far as unknown worker goes, I have no idea.  That's something going wrong within testtools, probably, within the test aggregation code orchestrated by testr --parallel
<gmb> Hmm.
<gmb> gary_poster, So, here's what I'm going to do:
<gary_poster> the stdout doesn't give me any immediate clues beyond that
<gmb> Let this finish (because we've come this far)
<gmb> Kill it
<gmb> Start a new big slave
<gmb> RUn it again
<gmb> Ahaha.
<gmb> Now it's OOMing
<gmb> Time to die.
<gary_poster> yeah. I was going to say :-)
<gary_poster> gmb, is this a known py 2.7 failure?
<gary_poster>     raise TypeError("Level not an integer or a valid string: %r" % level)
<gary_poster> TypeError: Level not an integer or a valid string: None
<gmb> gary_poster, Yes. mgz has just submitted a branch to fix that
<gary_poster> cool
<gmb> It's dead. Now, let's try this again :)
<bac> all:  tarmac is now running on canonistack.  let me know when you have a MP ready to be approved.
<gary_poster> great, bac.
<gary_poster> I'm going for early lunch, because it is so lovely out and will be hot again in next few days.  biab
<gmb> gary_poster, For when you get back: jam pointed out something interesting. The unknown worker output looks different from the the worker-N output; it looks like the output from bin/test without --subunit.
<gmb> gary_poster, http://ec2-23-22-155-23.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/1/steps/shell_9/logs/unknown%20worker%20%28bug%20in%20our%20subunit%20output%3F%29
<gmb> gary_poster, benji, bac: So, here's an interesting thing: http://ec2-23-22-155-23.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/1/steps/shell_9. We're running with --concurrency=8 and yet we have 9 workers. The "unknown worker" appears to contain the normal output from bin/test... Are we maybe seeing some crap on stdout from somewhere again?
<bac> benji: with grep, when do you need to dereference the count modifiers?  i.e. if i wanted to make the trailing '=' optional would i end it with =* or =\* in
<bac> grep -c "^ssh-[dr]sa [a-zA-Z0-9: .\/=+-]\+= " "$1"
<bac> not dereferencing works.  but why is the + escaped?
<bac> s/derefernece/escape
<benji> bac: if you use -P (perl-like regular expressions) you don't have to escape the *
<benji> I don't know about the other types, I always use -P
<gary_poster> gmb, hey.  That looks like a subset of the stdout bits.
<gary_poster> In particular, :setUp and :tearDown are patterns the subunit stuf uses for the fake subunit layers, I believe
<gmb> gary_poster, Hum. okay. I've replied to the thread about it all - we're about to take off for dinner.
<gmb> More poking around to be done tomorrow then.
<gmb> We'll try running against 2.7 under lucid.
<gmb> (if that's even possible)
<gmb> Anyway.
 * gmb -> exeunt, in search of victuals
<gary_poster> bye
<gary_poster> benji, for your lpsetup changes, have you just been running the command every now and then to make sure things work as you expect, given the minimal tests of the subcommands?
 * gary_poster is wondering what to do himself
<gary_poster> I'm tempted to run the command on an ec2 instance
<benji> gary_poster: yeah; it is quite sub-optimal, especially given how long some of the steps take
<gary_poster> ok, thanks benji
<benji> After I finish this card I hope to work on the testing cards a bit; I suspect testing will be quite hard given the subject matter and that there is so much code already.
<gary_poster> benji, you mean the slack time card?
<benji> no... I thought we had a "real" card for testing; I guess not.  I won't be doing that, in that case. :)
<bac> gary_poster: nm
<gary_poster> bac, ?
<bac> gary_poster: i accidentally pinged you in #launchpad
<gary_poster> bac, lucky I'm not over there then :-)
<gary_poster> benji, if you want to explore for a bit, you are welcome.  I thought I did what we had agreed to do last Friday
<benji> gary_poster: you probably did; that's why cards are good, they help keep our (my) memory straight
<gary_poster> :-) cool
<gary_poster> you are still welcome to explore for a bit :-) .  We don't really love the story we have right now, so I'm hoping someone will explore.  We may not have a real reason to go into slack time until gmb returns though
<bac> gary_poster: i've added lpqabot to ~yellow so she can access private branches
<gary_poster> she, like a ship, bac?
<gary_poster> sounds good :-)
<bac> gary_poster: http://mrl.nyu.edu/~perlin/experiments/rosie/rosie.jpg
<gary_poster> lol
<gary_poster> bac, I guess you need to document for us what you did to set up the canonistack instance, including the credentials?
<bac> gary_poster: yes
<gary_poster> cool
<bac> gary_poster: it *would* have been quite straightforward but for a couple of problems with software in lucid
<gary_poster> bac, why/where do we have lucid?
<bac> in lucid ssh-import-lp-id failed for 4/5 of the yellows, rejecting our ssh keys as invalid
<gary_poster> bac, feel free to postpone that answer for whatever time is more appropriate, like writing up your docs
<gary_poster> uh
<gary_poster> huh
<bac> gary_poster: the recipe jamesw gave me uses a lucid instance on canonistack.  i tried using a precise ami but the version of puppet there was not compatible with his scripts
<gary_poster> who was lucky 1/5
<gary_poster> oic
<bac> benji
<gary_poster> :-)
<bac> you had a trailing line feed
<bac> one of my keys had lots of line feeds
<bac> and gmb and frankban had the misfortune of not having any base64 padding.
 * benji polishes his SSH key collection.
<bac> none of those things make a key invalid,, but the script wrongly thought it did
<gary_poster> heh
<benji> hmm, the frameworky bits in lpsetup seem to be getting in my way; I /guess/ I should add more framework
<benji> This is how Zope started. ;P
<gary_poster> benji please record reminders of pain points for Friday
<benji> gary_poster: ooh, good point
<benji> (this isn't /entirely/ a "pain" point but more like something that needs to be handled that isn't handled by the structure there now)
<bac> gary_poster: did you see G+ has events now?  i just created one for our hangout tomorrow as an experiment
<bac> looks like they are only one-offs right now
<gary_poster> bac, what does that mean?  Where should I look?
<bac> G+
<benji> (which in my ever-so-slightly humble opinion is why frameworks (things that call your code) are often inferior to libraries (things that you call))
<bac> gary_poster: 'events' on left vertical bar
<bac> i guess you can't have a left horizontal bar
<benji> what's with the dripping pancakes? :)
<gary_poster> bac, cool thanks
<bac> i see benji found it
<benji> I love those HD-quality, looped animated GIFs.
<bac> benji: you don't like pancakes?
<benji> I love pancakes.  Especially non sequitur pancakes.
<bac> gary_poster: see if you can ssh tarmac@10.55.60.129
<gary_poster> bac worked
<gary_poster> (on call)
<bac> cool
<bac> better than not working
<gary_poster> :-)
<bac> gary_poster: i've added tarmac landing for zope.testing/3.9.4-fork too.  it's easy peasy now:  http://pastebin.ubuntu.com/1063107/
<gary_poster> bac, you rock
<bac> gary_poster: other requests?
<bac> of course, none of these are tested as no branches have landed
<gary_poster> bac, whirled peas.
<gary_poster> IOW, no, not right now.  Docs on what to do will be fabulous.
<bac> i do wonder how to communicate the IP address of the instance when it spins up.  does canonistack have any dns abilities?
<bac> gary_poster: most of it is in a branch, so it is self documenting.  i'll write up what i've got
<gary_poster> canonistack dns abilities: Not last I tried, unfortunately.  You could use a frozen ip, whatever those are called
<gary_poster> bac ^^
<gary_poster> bac, we are allocated three of those IPs per person in theory
<gary_poster> in reality you have to beg for them, IME
<bac> oh, really?  i saw they have public addresses but we don't need that...just a fixed one in our internal numberspace would be fine
<bac> it's just a PITA when it hops around
<bac> gary_poster: https://dev.launchpad.net/yellow/TarmacOnCanonistack
<gary_poster> bac, yeah meant public address.  Why not?
<gary_poster> bac, great! "You'll also need to install fabric" -> locally?  or on canonistack?  I'd guess the latter but the text reads as if it is the former
<bac> gary_poster: public is not necessary as long as our team can access it via chinstrap
<bac> fabric is installed on your local machine
<bac> i'll make that clear
<gary_poster> bac, not necessary, but it gives us the "non hopping" characteristic...if it's not that big of a cost, I think it is worth it
<gary_poster> bzc, oh, fabric drives juju locally?
<gary_poster> bac, I mean
<gary_poster> so it is kind of like your runparallel script?
<bac> gary_poster: no juju
<gary_poster> ih
<gary_poster> oh
<bac> fabric launches a canonistack instance and deploys tarmac using puppet
<gary_poster> got it
<gary_poster> mildly embarrassing to company that this is not juju, IMO
<gary_poster> in terms of being a public resource
<bac> gary_poster: from the wiki page: Public IP addresses are a limited resource. Please be considerate when reserving and using public IP addresses for you instances and release them when you're not needing them
<gary_poster> yeah saw that before
<bac> so, from that i figured we don't really need them.  ssh tunneling via chinstrap is easy and not noticeable.  since none of the services are public facing it doesn't make sense to me
<bac> if we were running a django site then i'd grab one
<gary_poster> so what's the annoyance of the IP jumping then?
<bac> there is no annoyance
<gary_poster> tarmac used to have an idea of a web site
<bac> you just have to set up your .ssh/config properly and then it is transparent
<gary_poster> so you have to do that every time, and that is the annoyance
<gary_poster> "there is no annoyance" bah humbug! :-)
<bac> gary_poster: james said he was working on a juju charm but it isn't ready. i chose to go with what he had as the quickest way to deploy.
<gary_poster> ah excellent
<bac> i spent about half the time on the dumb ssh-import problem
<gary_poster> +1
<bac> +1 on dumb problems?  :)
<gary_poster> :-P +1 on the quickest way to deploy
<gary_poster> bac, can you move your card to Done now?  Would be nice for frakban tomorrow
<gary_poster> frankban
<gary_poster> bac or benji, if you want a quick review, https://code.launchpad.net/~gary/lpsetup/paralleltweaks/+merge/112438 is for you
<gary_poster> talk to you all tomorrow
#launchpad-yellow 2012-06-28
<gmb> frankban, Do you have any idea how I can ssh in to an ephemeral lxc instance on the buildbot slave?
<gmb> user: ubuntu password: ubuntu doesn't work...
<frankban> gmb: you have to use '/var/lib/buildbot/.ssh/launchpad_lxc_id_rsa' as ssh key (or something like that). you can use lp-lxc-ip -n lptests to get the container's ip
<gmb> frankban, Ah, thanks.
<frankban> gmb: remember to stop buildbot master while you are working on lptests lxc, otherwise you can generate a time/space fault...
<gmb> Wow.
<gmb> I'll bear that in mind :)
<frankban> :-)
<bac> morning y'all
 * bac wonders how this google hangout event will work.  is the hangout pre-created for us?
<gary_poster> bac, yes
<gary_poster> I went to event page
<gary_poster> then there is a link to hangout
<gary_poster> bac benji frankban (gmb) https://plus.google.com/hangouts/_/b52c1a893347c571cd1a315088194860867fb396?authuser=0&hl=en-US in 2
<bac> it is annoying that google events don't allow you to set up recurring ones...takes a lot of the utility out of it for a daily call.
<gary_poster> agreed
<bac> hi gary_poster, YetAnotherDistributeTypeQuestion
<gary_poster> bac, heh, ok
<bac> gary_poster: benji and i ran into this on our dev boxes and for expediency decided the simple thing to do was use sudo to go ahead and let it install in /usr/local/lib
<bac> http://paste.ubuntu.com/1064215/
<gary_poster> bac, I'd try sudo apt-get install python-setuptools first
<bac> i don't want to use 'sudo' in the verify_command for tarmac.  is there another solution?  or just use 'sudo' once manually and let it do the deed?
<gary_poster> I think once it is installed, even the official package, things will work
<gary_poster> and that's nicer
<gary_poster> the official package installation is nicer I mean
<bac> oh, ok.  just make a dependecy on python-distribute?
<bac> er, python-setuptools
<bac> which, unfortunately, is already installed
<bac> so installing python-setuptools does not help
<gary_poster> ah :-/
<gary_poster> it worked for lpsetup :-/
<gmb> bac, question bout STDERR: and STDOUT: stuff in subunit from zope.testrunner...
<gmb> Should it be:
<gmb> STDERR: [text]\n
<gmb> or
<gmb> STDERR:\n
<gmb> [text]
<gmb> ?
<bac> gmb: the latter
<gmb> ok.
<gmb> bac, So, my question is, how would testr handle this:
<gmb> successful: lp.codehosting.codeimport.tests.test_worker.TestSubversionImport.test_sync [ multipart
<gmb> Content-Type: text/plain;charset=utf8
<gmb> STDERR:
<gmb> 63
<gmb> No handlers could be found for logger "root"
<gmb> WARNING:root:N changeset 2
<bac> gary_poster: yeah, you see at line 11 of the paste that it sees the debian pkg is installed but is unhappy b/c it isn't an egg
<gmb> WARNING:root:N changeset 3
<gmb> 0
<gmb> ]
<gmb> Is that safe because it's in the multipart []?
<bac> gmb: i don't know what you mean by safe?  it is just informational and should be ignored b/c it is in the multipart
<gmb> bac, I mean "will it cause testr to choke and give us an unknown worker?"
<bac> gmb: i wouldn't think so
<gmb> Okay.
<gmb> Hmm.
<gary_poster> bac, maybe is that an older ez-setup?
<gary_poster> try the distribute-setup you have and see if it is more polite?
<gary_poster> as I said, lpsetup worked with python-setuptools for me yesterday
<bac> gary_poster: you mean bootstrap.py?
<bac> gary_poster: yeah but lpsetup isn't using buildout
<gary_poster> bac, no...I meant ez_setup.  but yeah, I guess the part that is unhappy is bootstrap :-/
<bac> right, so there is no ez_setup as bootstrap fetches it
<gary_poster> does it fetch ez_setup or the distribute version?  There is a --distribute falg now I think
<gary_poster> flag
<bac> gary_poster: could we move our call up to 3pm today?
<gary_poster> benji, could we move our call up to 2pm today?
<benji> gary_poster: sure
<gary_poster> thanks
<gary_poster> bac, sure :-)
<bac> gary_poster: it is this version: $Id: bootstrap.py 110538 2010-04-06 03:02:54Z tseaver $
<bac> i don't see any option for using distribute.
<bac> if there is a newer bootstrap.py i could replace with it
<gary_poster> bac, <shrug> http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py?rev=123006
<gary_poster> that has a --distribute
<gary_poster> bac, oh one other idea.  if that falls over, try this one:
<gary_poster> bac http://svn.zope.org/*checkout*/zc.buildout/branches/1.4/bootstrap/bootstrap.py?rev=116869
<bac> gary_poster: i tried with the first new boostrap.py you referenced.  with it 'python bootstrap.py' worked, no new option needed
<gary_poster> bac, great, hopefully
<bac> it is ashame that those bootstrap files often don't have any date or versioning information embedded within them
<gary_poster> that's one of the reasons benji probably advocates not including bootstrap in packages, and forcing people to download them.  I disagree, but I see where he is coming from. :-)
<bac> gary_poster: well, i'd like you to review this instead of benji:  https://code.launchpad.net/~bac/zope.testing/newbootstrap/+merge/112562
<gary_poster> :-)
<bac> gary_poster: i did not bump the version as it does not need releasing
<gary_poster> bac, ack.  I made an "approve" comment but did not approve the mp (should I, as a matter of best practice, do you think?)
<bac> gary_poster: if it does not require any code changes then i think the reviewer should do it.  that prevents any subsequent versions from getting merged...which has good and bad points to it.
<gary_poster> bac, cool.  approved mp
<bac> gary_poster: well this is odd:
<bac> 2012-06-28 13:24:03 INFO     No approved proposals found for lp:~launchpad/zope.testing/3.9.4-fork
<gary_poster> frankban, I was just reviewing the results log.  bug 974617 showed up on 2012-05-15 .  then it was completely silent till 2012-06-21, when it had two instances--and after which we've had two more instances in the next seven days.  Do you remember anything off-hand that might have re-triggered the problem?  Did we reduce the timeout again?
<_mup_> Bug #974617: test_operationalerror_view_integration fails intermittently in parallel tests <paralleltest> <qa-untestable> <Launchpad itself:Fix Released by benji> <Python PGBouncer:Triaged> < https://launchpad.net/bugs/974617 >
<gary_poster> ISTR we had some very large timeout
<gary_poster> and then we reduced it to 60
<gary_poster> and then increased it to 180
<gary_poster> (we reduced it to 60 when you improved the retry code somehow)
<gary_poster> bac, uh?
<gary_poster> bac, I'm afraid I don't know what to do about it.
<gary_poster> do you have any thoughts?
<bac> gary_poster: was just informational
<gary_poster> oh cool
<bac> gary_poster: i'm chatting with dobey
<gary_poster> cool
<frankban> gary_poster: the connection is now retried for 180 times
<bac> gary_poster: despite the vague message, the problem was the MP lacked a commit msg so it was ignored.  boo.
<gary_poster> bac, bah
<benji> frankban: https://bugs.launchpad.net/lpsetup/+bug/1016645 calls for positional arguments for repo and branch; is there an easy way to do that in the current lpsetup structure?
<_mup_> Bug #1016645: lpsetup: get command <launchpad> <lpsetup:In Progress by benji> < https://launchpad.net/bugs/1016645 >
<benji> I might be better off using switches instead.
<gary_poster> bac, a vague message that you could only see if you logged on to the tarmac machine, no less
<gary_poster> frankban, https://plus.google.com/hangouts/_/777c438088f7788065d36f022db674481b12d167?authuser=1&hl=en-US when you are ready
<frankban> benji: you can add positional arguments as you usually do with argparse
<bac> but now when people are confused there are two of us to ask "did you set a commit message"?
<gary_poster> benji, argparse supports that, and we're on top of that; don't have a ready answer to your question, but am hopeful that there is one.  That said...there's probably reasonable defaults for those values, which suggest switches, and it seems to be the path of least resistance anyway, so +1
<gary_poster> bac, heh, true
<benji> gary_poster: it probably wouldn't be hard, but switches make more sense to me anyway
<gary_poster> cool
<frankban> benji: however: http://stackoverflow.com/questions/4480075/argparse-optional-positional-arguments
<benji> frankban: thanks
<gmb> gary_poster, Do you have some time to help me debug our parallel testing 2.7 problems? I've been having issues getting into the LXC containers on the slave in order to be able to follow the steps you outlined in your email.
<gary_poster> gmb, on call, wil ping
<gmb> Sure
<benji> frankban: am I right in thinking that "repository" referenced in https://bugs.launchpad.net/lpsetup/+bug/1016645 is the same as the already-existing --directory option?
<_mup_> Bug #1016645: lpsetup: get command <launchpad> <lpsetup:In Progress by benji> < https://launchpad.net/bugs/1016645 >
<frankban> benji: looking
<gary_poster> gmb, hey sure.  how would you like to pair?
<gmb> gary_poster, Sure thing.
<gmb> I'll start a hangout.
<gary_poster> cool
<gary_poster> gmb, I will "prepare."  Back in 2.
<gmb> O.o
<frankban> benji: yes, it's the same
<benji> frankban: cool; I got half-way into implementing it when I realized it was already done but with a different name.
<frankban> :-(
<benji> no worries
<gary_poster> gmb, hangout?
<gmb> gary_poster, G+ is teh suck.
<gmb> Bear with me...
<gary_poster> :-/ k
<gmb> gary_poster, https://plus.google.com/hangouts/_/713717cf5af4c438fee987556699093cd56fd288?authuser=0&hl=en-GB#
<bac> gary_poster: the next step for tarmac-controlled branches would be to move them to be owned by lpqabot so that people cannot just push to them directly as currently done with the launchpad branches and the PQM user.  for the two under our control now i don't think that's a high priority but should be done before we hand it off to lp-proper.  agree?
<gary_poster> agree bac
<benji> I have an MP ready for review: https://code.launchpad.net/~benji/lpsetup/bug-1016645-add-command-line-options/+merge/112588
<gary_poster> benji, I'll review after lunch if no-one beats me to it.  I request/suggest a low priority card for branch option.  Also, if I were reviewing, I'd ask your opinion on the spelling of directory vs repository.  I'd have to think through it myself, and asking you would help. :-)
<benji> gary_poster: I don't love "directory" but not being steeped in bzr-lore, "repository" doesn't seem to mean the right thing either; at least "directory" is meaningless enough that it can mean whatever we want it to mean given the context
<frankban> gary_poster: do you thing initlxc should stop the container at the end of the process?
<frankban> s/thing/think
<gary_poster> frankban, good question.  thinking...
<gary_poster> frankban, to make our normal story as smooth as possible, the answer would be, by default, no.  Maybe an option to turn it off at the end would be good.
<gary_poster> Leaving it on make me kinda nervous, but I think it makes the most sense.  Telling the user that the container is running woud be a good thing to do
<frankban> gary_poster: cool, that's what I was thinking.
<gary_poster> cool
<gary_poster> benji, repository vs. directory: aren't we talking about the argument to initrepo?
<gary_poster> stepping away, back soon
<benji> gary_poster: I don't know about initrepo, but it's an argument to just about all of the commands because it's where all the files go
<benji> Now I'm doubting my understanding of the situation... but frankban said I was right...
<frankban> benji: I think gary_poster meant "bzr init-repo" and yes, directory is the argument init-repo in this case. so, it's actually a bzr shared repository. +1 on renaming directory to repository
<gary_poster> benji, what frankban said :-)
<benji> gary_poster: k
<benji> gary_poster: the changes to rename "directory" to "repository" are done
<gary_poster> benji, thank you.  I've had some other things come up, sorry
<benji> no worries
<gary_poster> benji https://plus.google.com/hangouts/_/096fce3ced6cd2c17da53177decc22d9ae8a5b43?authuser=1&hl=en-US ?
<gary_poster> when you are ready
<gary_poster> no rush
<bac> gary_poster: ping
<gary_poster> bac, I know, five more mins max, sorry
<bac> gary_poster: ok
<gary_poster> bac https://plus.google.com/hangouts/_/096fce3ced6cd2c17da53177decc22d9ae8a5b43?authuser=1&hl=en-US
 * benji enjoys a mango lassi.
 * bac braces for leankit-pocalypse tomorrow
<bac> gmb you must share with frankban tomorrow.  i concur.  https://sphotos.xx.fbcdn.net/hphotos-ash4/s720x720/293727_10150902819136845_208774280_n.jpg
#launchpad-yellow 2012-06-29
<gmb> frankban, bac Said I should pass this on :) https://sphotos.xx.fbcdn.net/hphotos-ash4/s720x720/293727_10150902819136845_208774280_n.jpg
<bac> thank you gmb
<bac> i must confess i knew italy had beaten germany but didn't know they were up against spain next.
<gary_poster> bac benji frankban (gmb sprinting) https://plus.google.com/hangouts/_/ce53455e59c22e8108452c6d52293c8b4e481603?authuser=1&hl=en-US
<gmb> gary_poster, bac, benji, frankban: I have a solution for (at least some of) the parallel testing under 2.7 problems. Yes, it's zope.testing that's at fault. Can one of you take a look at this when you have a free moment? https://code.launchpad.net/~gmb/zope.testing/make-skips-work-bug-1019275/+merge/112762
<gary_poster> great, gmb!  bac says he will review
<gmb> Cool, thanks.
<gmb> bac, If you haven't started on that MP yet, Jelmer just reviewed it for me.
<gmb> If you have, well, same message, but with more sympathy.
<bac> gmb, great.  still on call
<gmb> COol.
<bac> had not looked yet
<gmb> gary_poster, bac, benji, frankban Any idea why a buildbot-master instance wouldn't get past the "installed" stage?
<gary_poster> gmb, I'm afraid not.  And FWIW, it Worked For Me
<gmb> Hmm.
<gmb> gary_poster, It was using a different branch for checkouts... I've switched it back to devel and poked the config manually.
<gary_poster> benji, ok, I'm ready.  https://plus.google.com/hangouts/_/36c7b753942b0839215fca6730a9a0a9b7356ce8?hl=en-US
<gary_poster> weird gmb (IIUC) but glad you have it working well enough (IIUC)
<gmb> gary_poster, YUC :)
<gary_poster> :-)
<bac> gmb, if you set a commit message on your zope.testing branch it should be landed by tarmac.  if you push changes you'll need to toggle the top-level approval.
<bac> hi frankban, in your MP at 213 and 216 it looks like you're calling 'apt-get update' twice in a row.  intentional?
<frankban> bac: let me see
<bac> frankban: oh, nm.  i can't read
<frankban> bac: heh, upgrade vs update?
<bac> yep, sorry
<frankban> np
<gmb> bac: My branch can't land through tarmac, it seems:    raise Exception("Requires subunit 0.0.5 or better") happens a few times.
<gmb> Is subunit installed on the canonistack instance?
<bac> gmb: hmm, perhaps not.  let me finish this review and i'll check/fix it.
<gmb> ta
<bac> frankban: review done.  looks good but i made a couple of suggestions.  toggle it to 'approved' after pushing any changes you make.
<frankban> bac, right, thanks
<bac> gmb:  boo -- http://paste.ubuntu.com/1066309/
<gmb> Ah
<bac> really?  avahi and fontconfig?  and libthai-data?  wth?
<gmb> Yeah. Um... That's a fun dependency tree there.
<bac> i just don't get it
<bac> i mean, it has no impact on my life, but it still is deeply offensive
<gmb> :)
<bac> After this operation, 24.2 MB of additional disk space will be used.
<bac> Do you want to continue [Y/n]? Y-but-I'm-Not-Happy
<bac> the good news is doing stuff within the data center is mighty snappy
<gmb> Cool.
<gmb> bac: Do I need to do anything once you've done to get the branch through tarmac?
<bac> gmb: no, once i'm done i'll toggle to approved again and it should just work
<gmb> bac: Cool. In that case I'll disconnect. I'll be at Schiphol before long...
<gmb> See you all Monday.
<bac> yay, you
 * gmb -> exeunt, on a train
<bac> gary_poster: i just had to restart tarmac.  it occurs to me that the next time that happens i should ask someone else to do it...spread the knowledge.  pretty painless but may require some local setup as documented.
<bac> gary_poster: could you make us ops on this channel?  i'd like to update the topic with the tarmac IP address.
<frankban> bac: review commented, do you agree in approving the MP as is? I will investigate the symlink issue when I am back.
<gary_poster> bac, I'll be happy to make everyone ops.  Do you know how, by chance?  If not I'll look it up
<gary_poster> why is /msg chanserv help not doing anything? :-/
<gary_poster> benji, if you type /msg chanserv help, do you get any reply?  /msg nickserv help works...
<benji> gary_poster: works for me
<gary_poster> :-/
<gary_poster> weird
<gary_poster> will try rejoining, maybe
<gary_poster> bac, everybody has ops, whee
<gary_poster> benji, can rejoin on hangouts whenever suits you
<bac> thanks gary
<benji> gary_poster: k
<gary_poster> welcome
<benji> gary_poster: https://plus.google.com/hangouts/_/553e533541af2146473369b5b184ced83f539c39
<bac> frankban: i think it is nicer to use os.symlink but that shouldn't stop you from landing.  feel free to update the MP to approved and let it land.
<frankban> cool bac, thank you
* bac changed the topic of #launchpad-yellow to: https://dev.launchpad.net/yellow | http://launchpad.leankitkanban.com/Boards/Show/14028610 | http://irclogs.ubuntu.com/ | https://devpad.canonical.com/ ssh tarmac@10.55.60.90
<gary_poster> bac, could you hangout with us https://plus.google.com/hangouts/_/553e533541af2146473369b5b184ced83f539c39
<gary_poster> initlxc
<gary_poster> inithost
<gary_poster> user
<gary_poster> get
<gary_poster> inituser
<gary_poster> get me a repo and code and stuff
<gary_poster> get me a branch to do stuff in
<bac> gary_poster: my tarmac branch is at lp:~bac/tarmac/make_treedir
<bac> it is doc fix and code fix
<gary_poster> awesome bac, thanks for link
<bac> gary_poster: do you use a scroll pad, magic or otherwise?
<bac> single-swipe back-n-forth on kanban used to scroll the screen.  the update seems to have broken that.  kind of annoying as i have to go grab the scroll bar now.
<gary_poster> bac I do
<gary_poster> bac, two finger scroll in Ubuntu works fro me
<bac> could be my choice of an aberrant browser
<bac> or desktop
<bac> gary_poster: so is the s76 being replaced?
<gary_poster> bac not sure yet. returned today.  Will arrive next friday.  when I get money back I will be willing to act :-)
#launchpad-yellow 2013-06-27
<teknico> benji: thank you ;-)
<teknico> I guess we can drop this channel now...
 * benji turns out the lights.
