[00:14] <mwhudson> boo to not being able to restart the buildmaster ever :(
[00:16] <thumper> huh?
[00:17] <thumper> what changed?
[00:17] <mwhudson> well, there's always a build running
[00:17] <mwhudson> if i bounced it now, we'd lose the progress so far on the tests currently running
[00:17] <mwhudson> maybe it's worth it though
[00:17] <mwhudson> (it would be nice if the bzr builder ran today)
[00:19] <mwhudson> thumper: opinion?
[00:19] <thumper> hmm
[00:20]  * thumper wants a stop.patch
[00:20] <thumper> mwhudson: will we need to manually kick the builds to get them going again?
[00:20] <thumper> mwhudson: if we won't, do it now
[00:20] <mwhudson> thumper: i don't think so
[00:21] <mwhudson> thumper: let's find out!
[00:21]  * mwhudson restarts the wrong bit, oops
[00:22] <wgrant> What's the bzr builder?
[00:23] <mwhudson> builds seem to be going now
[00:23] <mwhudson> wgrant: it runs the launchpad tests against bzr.dev
[00:23] <wgrant> mwhudson: Ah.
[00:25] <thumper> mwhudson: we have a new image for bzr?
[00:25] <mwhudson> thumper: no, it was master only changes
[00:25] <mwhudson> (a new image wouldn't require a master restart)
[00:36] <thumper> mwhudson: ah crap
[00:37] <thumper> mwhudson: my tests run fine locally
[00:37] <thumper> mwhudson: but there are changes on devel that cause it to fail
[00:37] <mwhudson> thumper: wheeee!
[00:37] <thumper> mwhudson: but I really want this cherry pickable...#
[00:37] <thumper> mwhudson: if I fix it to land, it won't cherry pick
[00:38] <mwhudson> thumper: land it on devel first, then prepare a branch off production containing the fix?
[00:38] <thumper> the branch I have is prepared off production
[00:38] <mwhudson> oh right
[00:38] <thumper> mwhudson: I think I'll push my current branch to a new branch on lp
[00:38] <thumper> then fix to land on devel
[00:38] <mwhudson> right, two branches is the answer i think
[00:47] <thumper> ah fuck
[00:48]  * thumper walks away for coffee
[00:48] <thumper> I'll fix the problem later...
[00:50]  * mwhudson afk for a bit again
[00:51] <mwhudson> (well, for lunch)
[02:03]  * wgrant cringes a bit at IAnnouncement.
[02:04] <wgrant> And related interfaces..
[02:04] <meaton2veggies_> wgrant: installed on jaunty now
[02:05] <wgrant> meaton2veggies_: i386?
[02:05] <thumper> wgrant: do a bzr blame on that one
[02:05] <wgrant> thumper: I did see some comments around which indicate what I think you might be suggesting.
[02:05]  * wgrant tries.
[02:05] <meaton2veggies_> wgrant: yes, VM
[02:05] <wgrant> Indeed.
[02:06] <meaton2veggies_> wgrant: any idea how i fix self-signed cert with feeds.launchpad.dev:443?
[02:06] <wgrant> meaton2veggies_: Tell your browser to trust it.
[02:06] <meaton2veggies_> yep, doing that now
[02:07] <meaton2veggies_> in firefox 3.5 it comes up on the front page launchpad.dev error alert
[02:07] <wgrant> That's correct.
[02:07] <wgrant> You need to tell Firefox to trust it.
[02:08] <meaton2veggies_> do i have to create a proper cert for the local site
[02:08] <wgrant> You could, but there's little point.
[02:08] <meaton2veggies_> ok
[02:09] <wgrant> thumper: How aggressively should method name conventions be fixed?
[02:09] <thumper> wgrant: what are you wanting to fix?
[02:09] <wgrant> thumper: IAnnouncement.set_published_date and IHasAnnouncements.announcements
[02:10] <wgrant> (to setPublishedDate and getAnnouncements respectively)
[02:10] <thumper> wgrant: are they methods?
[02:10] <wgrant> thumper: They are.
[02:10] <wgrant> And they both want to be exported.
[02:11] <thumper> announcements is a method not an attribute?
[02:11] <wgrant> thumper: Correct.
[02:11] <thumper> wgrant: I'd review and approve those changes
[02:11] <wgrant> thumper: It takes some arguments to customise the result. Maybe it used to be an attribute.
[02:13] <wgrant> thumper: I shall start another branch and do the renames. Thanks.
[02:13] <wgrant> Seems much nicer than using exported_as.
[02:14] <thumper> wgrant: agreed
[02:14] <wgrant> And they're not used much, so it's easy.
[02:39]  * mwhudson reappears
[02:39] <thumper> wb
[02:40] <thumper> :)
[02:56] <mwhudson> mars: "- Node.queryAll()'s signature changed.  It now returns an empty sentinel object with size() == 0 if no results were found, instead of returning 'null'. "
[02:56] <mwhudson> hoo-bleeping-ray!!
[02:57] <mwhudson> that was a particularly stupid change in pr2
[03:05] <mars> hehe
[03:05] <mars> well, it makes the test clearer, and universal
[03:05] <mars> test for length: done!
[03:06] <mars> I don't know what Y.all() returns though
[03:13] <mwhudson> oh right
[03:14] <mwhudson> in loggerhead i had to change a few Y.query(selector).each(...) to nodes = Y.query(selector); if (nodes) nodes.each(...)
[03:14] <mwhudson> s/query/all/ i guess
[03:14] <mwhudson> which just made me a bit unhappy
[03:21] <wgrant> The sparklines really encourage me to read the project branch listing very quickly, before the horrible virus slowly infects all of the rows.
[03:22] <lifeless> wgrant: thumper is landing a fix, or you could put one up :)
[03:22] <wgrant> lifeless: They should be gone in a few hours, I think.
[03:23] <wgrant> I'm surprised they missed the edge update last night.
[03:23] <thumper> wgrant: heh
[03:24] <thumper> wgrant: missed the cut off by about 2.5 h
[03:24] <lifeless> thumper: thats ok, have a beer for commiseration. Or something.
[03:24]  * wgrant defeats the stupid uni firewall, and successfully pushes that IAnnouncement branch.
[03:25] <wgrant> thumper: Shall I request a review from you?
[03:25] <thumper> wgrant: sure
[03:25] <wgrant> Hmmm.
[03:26] <wgrant> I attempted to search for 'devel' as the branch to propose the merge to, and the picker gives me one option: "undefined"
[03:26] <wgrant> Oh. "Too many matches" is the error, "undefined" is the option.
[03:35] <thumper> ew
[03:35] <thumper> wgrant: try "lp:launchpad/devel"
[03:36] <thumper> wgrant: once you've done it once, it'll remember
[03:36] <thumper> and offer it next time#
[03:37] <wgrant> thumper: Ah, useful.
[03:37] <wgrant> thumper: Thanks. I'll file a bug.
[03:37] <thumper> ok
[03:40]  * thumper takes a break as 4 ec2's do their thing
[03:54] <wgrant> So, a friend of mine just totally failed to realise that status and importance are AJAXy, because they have no icons.
[03:55] <lifeless> wgrant: I filed a bug on that
[03:55] <lifeless> search for mystery meat
[03:55] <lifeless> bad web design since 1995
[03:55] <wgrant> I thought I remembered seeing them.
[03:55] <wgrant> s/them/one/
[04:09] <thumper> WTF?
[04:09] <thumper> got an invalid docstring :(
[04:09] <mwhudson> apidocs are processed from docstings
[04:09] <thumper> api doc compilation thingy
[04:09] <thumper> where can I find out what exactly is invalid?
[04:10] <mwhudson> thumper: i'd start with the diff against trunk :/
[04:10] <mwhudson> woo bzr builder ran to completion today
[04:10] <thumper> its a new docstring for a new method
[04:10] <thumper> mwhudson: 8 failures
[04:10] <thumper> mwhudson: but yes, it ran :)
[04:10] <thumper> oh 3 failures, 10 errors
[04:10] <mwhudson> thumper: almost all uifactory failures
[04:11] <mwhudson> i think i have a branch that fixes that actually...
[04:11] <mwhudson> hm, no
[04:11] <mwhudson> i have a branch that was created to fix that :)
[04:11] <thumper> heh
[04:11] <thumper> mwhudson: add it to the todo list :)
[04:11] <mwhudson> https://bugs.edge.launchpad.net/bugs/405052
[04:12] <mup> Bug #405052: bzr 1.18dev breaks our uifactory <Launchpad Bazaar Integration:In Progress by mwhudson> <https://launchpad.net/bugs/405052>
[04:12] <mwhudson> filed a while ago
[04:12] <mwhudson> i'm sure i fixed this, must have lost the changes somehow
[04:12] <thumper> :(
[04:13] <mwhudson> it's minor
[04:13] <thumper> off to get the car now
[04:13] <thumper> bbs
[04:40]  * thumper is no $806 poorer
[04:40] <thumper> s/no/now
[04:40] <thumper> d'oh
[04:42] <spm> thumper: I'd be more worried about the $806 vs the no/now
[04:42] <thumper> spm: well, the car needed brake pads and discs
[04:43] <spm> what do you need brakes for? don't NZer's just run into the nearest sheep to stop?
[04:43] <lifeless> no way, waste of a good sheep
[04:44] <thumper> spm: it is the lack of sheep at the town lights that cause problems
[04:44] <spm> you'd think they'd do something about that. what do you pay your taxes for eh!
[04:44] <thumper> spm: to pay for the politicians Wellington houses apparently
[04:45] <spm> ah. some things dno't ever change....
[04:49] <thumper> spm: how goes disk space on codehosting?
[04:49] <thumper> spm: also, what is the RT for more disk space?
[04:58] <mars> wgrant, was your friend using Safari?  Be sure to note that in the bug report.  Safari doesn't show the icons, IIRC.
[04:59]  * mars goes off to sleep for real now
[04:59] <thumper> mars: I have noticed that sometimes they don't show at all
[04:59] <thumper> mars: on FF2.0 on Windows
[05:00] <wgrant> mars: Firefox 3.0. It's intended that they don't show up unless hovered.
[05:00] <wgrant> That they don't show up even if hovered over is another issue.
[05:00] <thumper> wgrant: even on hover they weren't showing
[05:02] <lifeless> mystery meat sucks
[05:05] <wgrant> lazr.restful seems to think that my zope.schema.URI is a hosted file :(
[05:10] <thumper> lifeless: there was an Indian resturant near where I lived once in London that had "meat chilli chilli" as a menu item :)
[05:10] <thumper> I was never game to ask exactly what the meat was
[05:10] <thumper> it was a mystery :)
[05:11] <lifeless> :)
[05:11] <lifeless> http://en.wikipedia.org/wiki/Mystery_meat_navigation is what I meant though
[05:18] <thumper> lifeless: found the community review tag bug
[05:19] <lifeless> cool
[05:20] <thumper> 1 line fix, 50 lines of tests to write
[06:17] <mwhudson> concurrency is hard :(
[06:40] <mwhudson> !!
[06:40] <mwhudson> emacs just died on me?
[06:40] <mwhudson> ah no
[06:40] <mwhudson> just hiding
[06:41] <thumper> I'm done for now
[06:41] <thumper> will finish off these tests later
[06:41] <thumper> night
[06:42] <mwhudson> night
[06:42]  * mwhudson very nearly finished too
[06:42] <mwhudson> thumper: what was the problem for community reviews?
[06:43] <thumper> branch.reviewer vs. branch.code_reviewer
[06:43] <thumper> reviewer can be None
[06:43] <thumper> code_reviewer == branch.reviewer or branch.owner
[06:43] <thumper> I'm changing the view logic and renaming a method and adding tests :)
[06:44] <mwhudson> argh
[07:23] <noodles775> Morning ppl
[08:58] <jml> morning
[08:59] <noodles775> morning jml
[08:59] <spm> hey jml, noodles775; and g'night
[09:00] <noodles775> :)
[09:01] <jml> spm, g'night
[09:09] <mrevell> Morning!
[10:01] <allenap> mrevell: Morning :)
[10:01] <mrevell> hey allenap
[10:03] <allenap> Does anyone know why PQM is throwing out my branches? It seems to be claiming we're in testfix mode for lp/devel, but the waterfall is green a long way back.
[10:08] <danilos> allenap: we get into testfix even if db-devel is red
[10:09] <danilos> allenap: it's "stop the line" approach
[10:09] <allenap> danilos: Ah ha, thank you.
[10:10] <BjornT> allenap: we should get out of testfix mode soon, though. it depends on when the script that turn it off sees the testfix commit.
[10:11] <allenap> BjornT: Fantastic :)
[10:30] <jml> hey
[10:31] <jml> liwii sent an email to the launchpad-dev mailing list
[10:34]  * wgrant hasn't seen it come through.
[10:55] <jml> and it doesn't seem to be in the archive, nor in the moderation queue
[10:55] <jml> wgrant, sorry I got distracted for a while
[10:57] <wgrant> jml: Not even in the moderation queue? Huh.
[10:59] <mrevell> jtv: ping
[10:59] <jtv> mrevell: pong
[11:00] <jtv> mrevell: saw your message about the getting-started guide, though haven't looked at the guide yet
[11:00] <jtv> mrevell: just what we need though, so definitely let's set a time.
[11:00] <jtv> (that is what this is about, isn't it?)
[11:00] <mrevell> jtv: No worries. This is on a slightly different subject. Should the help wiki present bzr imports and exports as the default method?
[11:01] <jml> but I don't know how the moderation queue works.
[11:01] <jml> do we have an admin around who can take a look?
[11:02] <deryck> Hi, all.
[11:02] <jtv> mrevell: for exports I'd present both options side by side depending on use case (and it should be clear that it's for maintainers, reviewers etc., not for end-users)
[11:03] <jtv> mrevell: for imports, I would like bzr to be seen as the default source.  Also makes it less inviting to set up proprietary projects for translation without contacting us.
[11:03] <jml> deryck, g'day
[11:03] <jtv> hi deryck, hi jml
[11:04] <mrevell> jtv: Great. I'm uncertain what you mean by " makes it less inviting to set up proprietary projects for translation without contacting us."
[11:04] <mrevell> yo dezza
[11:04] <jml> jtv, hi
[11:04]  * jtv feels an O(n²) process
[11:04] <danilos> jtv, henninge_: let's have a call
[11:04] <mrevell> danilos: hands off, I'm talking to jtv
[11:04] <danilos> mrevell: no way, it's in the calendar ;)
[11:04] <mrevell> heh
[11:05] <jtv> mrevell: with bzr imports, you share your source first and the translation imports are then easy.  With manual uploads, it can seem to make sense not to share source.
[11:05] <jtv> danilos: call
[11:05] <jtv> So flattering to have people fight about you...
[11:05] <mrevell> jtv: I see, although of course people could just have a bzr branch with only their templates. But I get the point. Cool, will update das wiki now.
[11:05] <mrevell> henninge: die, der or das for wiki?
[11:05] <jtv> mrevell: cool, thanks.
[11:05] <henninge> mrevell: das
[11:06] <henninge> danilos: call
[11:06] <mrevell> lucky guess on my part, thanks henninge :)
[11:06] <danilos> das wiki ist mein wiki, henning get online on skype
[11:06] <henninge> danilos: I am
[11:06] <danilos> henninge: just seen you, calling
[11:07] <jtv> "ring"
[11:07] <jtv> "ring"
[11:26] <stub> Now I have Abba in my head. Thanks :-P
[11:27] <danilos> jtv, henninge: https://lpstats.canonical.com/graphs/TranslationsCommitToBranches/
[11:30] <jml> al-maisan, who has launchpad.Edit permissions on a package set?
[11:31] <jml> al-maisan, I can't find any security adapter for it
[11:31] <al-maisan> jml: it should be "techboard"..
[11:31] <al-maisan> jml: just a minute ..
[11:31] <jml> al-maisan, techboard is the person with IPackagesetSet.new permissions.
[11:32]  * wgrant hopes there is never a need to access groups of package sets.
[11:36] <jml> BjornT, do you know who has launchpad.Edit permissions to an object in the absence of a security adapter?
[11:38] <jml> my reading says no one has permissions
[11:47] <mrevell> bigjools: Nice change on the Packaging/PPA help page, thanks.
[11:48] <bigjools> mrevell: yeah, it kinda helps to know how to upload :)
[12:10] <BjornT> jml: right. if there is no adapter, no one should have permission. although we have some general adapters, for example for IHasOwner, which might get used.
[12:11] <jml> BjornT, hmm, thanks. Maybe that was being used in this case...
[12:12] <jml> BjornT, are there any tools to find out which security adapter is being used?
[12:12] <jml> currently I just use grep
[12:21] <BjornT> jml: queryAdapter(ob, IAuthorization, 'launchpad.Edit')
[12:21] <jml> BjornT, of course, thanks.
[12:46] <kfogel> BjornT: does bugs.l.n offer full text search via the APIs?  If not, are there plans to make it do so?  (Someone from the Emacs project is asking.)
[12:47] <kfogel> leonardr: ^^  (do you know answer to above?)
[12:48]  * kfogel goes to look
[12:48] <leonardr> kfogel: i don't know the answer
[12:48] <intellectronica> kfogel: sort of. we offer the same search you get in the advanced bugs search
[12:48] <BjornT> kfogel: yes, it does, through the searchTasks() method
[12:49] <BjornT> kfogel: as intellectronica said, it's the same as the advanced search in the ui.
[12:49] <kfogel> leonardr, intellectronica, BjornT: thanks.  Yes, looking at advanced search, it seems to meet the description "full text search".  I mean, it searches on the body as well as the description and summary of the bug, right?
[12:49] <intellectronica> anyone knows what might be the problem with PQM? my lazr-js branch is sitting there for quite some time with no progress
[12:50] <BjornT> kfogel: yes
[12:50] <intellectronica> nm. it just got merged :)
[12:51] <kfogel> BjornT: searchTasks() is not in launchpadlib, it is part of the ReST API, right?
[12:51] <intellectronica> kfogel: that's true for everything in the API. launchpadlib is just an automatically generated wrapper
[12:52] <intellectronica> kfogel: see https://launchpad.net/+apidoc/ for the complete reference
[12:52] <kfogel> intellectronica: sure, but he could be saying a method name in launchpadlib
[12:52] <intellectronica> kfogel: the point is, the method will be there when you use launchpadlib, but you won't find it grepping the source of launchpadlib
[12:53] <kfogel> intellectronica: oh, it dynamically generates the method names by querying the site?
[12:53] <kfogel> at run time?
[12:53] <intellectronica> kfogel: exactly
[12:53] <kfogel> intellectronica: inspired.  I didn't know that.  Thank you.
[12:54] <intellectronica> kfogel: plus or minus a few modifications to make the interface a bit nicer
[12:56] <kfogel> leonardr: we generate HTML id="foo" for each section name in the API docs; if we generated title="foo" attribute as well, then hovering over a given section would show the name, and one could write deep link URLs without having to View Source first.  For example, view source around https://launchpad.net/+apidoc/#bug_target-searchTasks to see what I mean.
[12:57] <intellectronica> kfogel: that should be quite easy to modify. the documentation is transformed into html from wadl, which is an xml interface description language
[12:57] <leonardr> kfogel: yeah, file a bug for it or jfdi by modifying the xslt file
[12:58] <intellectronica> that's done using xslt, which is heaps of fun, if you haven't tried it yet :)
[12:58] <kfogel> leonardr: just wanted to make sure you thought it was a good idea; I'll have a look
[12:58] <mwhudson> jml: did you get my mail?
[12:59] <jml> mwhudson, yes, I did.
[12:59] <jml> mwhudson, I guess I should actually read it in detail.
[12:59] <mwhudson> jml: i would appreciate it
[12:59] <mwhudson> jml: no hurry though, i should be asleep :)
[12:59] <jml> mwhudson, sure thing.
[12:59] <jml> mwhudson, I've been puzzling through security & soyuz stuff
[13:00] <mwhudson> jml: so concurrency in the puller should be a nice relaxing change for your brain
[13:00] <mwhudson> jml: or something
[13:01] <jml> mwhudson, yeah, for sure.
[13:01] <bigjools> soyuz gets such a bad rap ...
[13:01] <jml> bigjools, there's a fair bit of scope for cleaning it up
[13:02] <bigjools> yeah, it's the oldest code in LP
[13:02] <jml> and the problem domain itself is very complex
[13:02] <jml> which compounds the problem
[13:02] <bigjools> I personally never thought it was that complex, there's just a lot to know
[13:03] <jml> bigjools, that's the sense I meant, I guess :)
[13:03] <jml> bigjools, so, while I have you distracted...
[13:03] <bigjools> I knew you'd say that :)
[13:03] <jml> bigjools, why doesn't nascentupload check pocket permissions?
[13:03] <bigjools> because they don't exist? :)
[13:04] <jml> bigjools, what's IDistroSeries.canUploadToPocket all about then?
[13:05] <jml> oh, it's in uploadpolicy
[13:05] <bigjools> oh that's a state check
[13:05] <bigjools> right
[13:05] <bigjools> it's not a permission as such
[13:05] <jml> what's the guiding principle for a check being in uploadpolicy rather than nascentupload?
[13:05] <bigjools> I guess that makes your job interesting
[13:06] <bigjools> hysterical raisins?
[13:06] <bigjools> honestly, no idea, it doesn't seem that sane does it
[13:06] <jml> bigjools, that's fine. I'm happy to clean things up as I go along.
[13:06] <jml> just as long as I'm justified in doing so :)
[13:06]  * bigjools owes jml a lot of whisky
[13:07] <jml> it's also nice doing this in the same room as the ubuntu foundations team :)
[13:07] <bigjools> ha :)
[13:07]  * bigjools waves to cjwatson
[13:07] <jml> bigjools, btw, this is what the verify_upload function looks like now: http://paste.ubuntu.com/247942/
[13:07] <jml> it's still missing component checking & pocket checking
[13:09] <jml> actually, the tests might be a little more interesting: http://paste.ubuntu.com/247943/
[13:10] <bigjools> jml: is that a new file?
[13:12] <jml> bigjools, yeah. the new file is at archiveuploader/permission.py -- http://paste.ubuntu.com/247946/ for the full thing
[13:12] <bigjools> it seems to duplicate checks done elsewhere
[13:12] <jml> bigjools, I'm happy to move it, but I figured that was as good a starting place as any
[13:12] <jml> bigjools, it's extracting out verify_acl
[13:12] <bigjools> right - so we can remove some other tests
[13:13] <bigjools> I doubt they're as efficient as these
[13:13] <jml> bigjools, yeah, that's probably a good idea.
[13:13] <bigjools> since they're probably trying to upload a package
[13:13] <jml> finding tests to delete is a lot harder than finding code to delete though.
[13:13] <jml> heh heh.
[13:13] <bigjools> lib/lp/soyuz/doc/nascentupload*
[13:13] <bigjools> and
[13:13] <bigjools> lib/lp/archiveuploader/tests/*
[13:13] <jml> and I've been keeping the existing tests as guarantees that my refactoring maintains the existing behaviour.
[13:14] <bigjools> good call
[13:14]  * bigjools is looking forward to seeing your changes
[13:14] <jml> bigjools, do the interim versions look ok so far?
[13:15] <bigjools> jml: I think so, I am still looking
[13:16] <jml> cool.
[13:16] <jml> well, I'm off to lunch now, but I'll be happy to read your comments in the backlog :)
[13:16] <jml> ciao
[13:16] <bigjools> jml: enjoy, I am eating now too
[13:18] <bigjools> hmmm the new AJAX-y "request another review" for an MP doesn't go quite right
[13:26] <kfogel> intellectronica, leonardr: http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00219.html
[13:26] <leonardr> kfogel, col
[13:27] <intellectronica> kfogel: so what, emacs is moving or thinking of moving to LP?
[13:28] <kfogel> intellectronica: Emacs is switching to Bazaar (but trunk not hosted on LP).  I'm proposing that it switch to launchpad bugs, because right now only launchpad bugs and debbugs meet Emacs' criteria for a bug tracker: that it be free software, and that it be entirely operable by email.
[13:28] <intellectronica> very nice
[13:29] <kfogel> leonardr: find . -name "*.xslt" -print  ==> no results in Launchpad tree, same with "*.wadl".  Give me hint as to what to search for?
[13:31] <kfogel> leonardr: ./lib/canonical/launchpad/apidoc/wadl-development.xml
[13:31] <kfogel> ?
[13:32] <leonardr> kfogel: no, that's a test file
[13:32] <leonardr> the xslt file is in launchpadlib
[13:32] <leonardr> now that launchpad is open source we could move it back into launchpad
[13:32] <leonardr> but some people wanted to modify it
[13:33] <kfogel> leonardr: cd ~/src/launchpadlib && find . -name "*xslt*"  ==> no results
[13:33] <NCommander> kfogel, debbugs could also do it
[13:33] <NCommander> oh, doh
[13:34] <kfogel> NCommander: :-)
[13:34] <NCommander> kfogel, I thought bugzilla was adding support for that htough
[13:34] <kfogel> leonardr: ah, found it I think
[13:34] <NCommander> Does anyone know if the sync packages script can copy into a component
[13:34] <kfogel> leonardr: wadl-to-refhtml.xsl, right?
[13:36] <leonardr> y
[13:39] <kfogel> leonardr: where is the process that drives the XSL conversion?  I don't see any other file (like a Makefile or setup.py) that refers to wadl-to-refhtml.xsl.  I.e., how will I test my changes?
[13:40] <leonardr> kfogel: i believe there is something in the launchpad makefile that does the conversion and puts it in apidoc/
[13:40] <kfogel> leonardr: oh, launchpadlib is a dependency of launchpad?  I didn't realize that.  Thanks.
[13:40] <kfogel> (I thought we drove the ReST APIs directly... maybe we do, and the dep is only for the apidocs.  dunno)
[13:43] <leonardr> kfogel: i'll lay it down for you
[13:43] <kfogel> leonardr: lay it on the line for me, brother
[13:44] <leonardr> there are five pieces of software: lazr.restful, launchpad, wadllib, lazr.restfulclient, and launchpadlib
[13:44] <leonardr> data flows out of the launchpad database from left to right
[13:44] <leonardr> lazr.restful and launchpad are on the server. wadllib, lazr.restfulclient, and launchpadlib are on the client
[13:45] <leonardr> lazr.restful has self-contained tests that use fake web services
[13:45] <leonardr> wadllib has self-contained tests that use an old static copy of launchpad's wadl
[13:45] <leonardr> lazr.restfulclient has tests where it acts as a client for lazr.restful's fake web service
[13:46] <leonardr> launchpadlib contains launchpad-specific code and must be tested against the actual launchpad web service
[13:48] <leonardr> we integrated launchpadlib tests into launchpad because changes to launchpad can break launchpadlib
[13:48] <leonardr> but all the other pieces of software -- lazr.restful, wadllib, and lazr.restfulclient -- are tested standalone
[13:48] <kfogel> leonardr: *nod*  thank you.  (please take a look at http://paste.ubuntu.com/247977/ to see if I'm on the right track, when you get a chance)
[13:50] <leonardr> kfogel: that looks good to me, but ask sinzui, he's the xslt expert
[13:50]  * sinzui looks
[13:50] <kfogel> sinzui: thanks.  Not tested yet (i.e., I haven't generated docs from it yet)
[13:52] <sinzui> kfogel: what is the value of having a title in every heading?
[13:53] <kfogel> sinzui: right now, if you're reading the API docs online (say, visit https://launchpad.net/+apidoc/#bug_target-searchTasks), you cannot know the name of the section you're in without doing View Source.  With this change, hovering the mouse pointer over a section would show its name.  That way people could more easily refer to specific sections within the documentation.
[13:54] <kfogel> s/refer/refer other people to/
[13:54] <kfogel> heh, I mean s/refer to/refer other people to/
[13:55] <kfogel> In other words, I had to do View Source to come up with the "#bug_target-searchTasks" part of that URL.  After this change, I could just hover and grab it.
[13:55] <sinzui> okay. This change look good.
[13:56] <kfogel> sinzui: do you know off the top of your had what command I should run to re-generate the HTML to test this?  (If not, no worries, I'll poke around.)
[13:56] <sinzui> make clean; make build
[13:56] <sinzui> will do it
[13:56] <kfogel> heh
[13:56] <kfogel> thnks
[13:56] <kfogel> thanks
[14:01] <flacoste> morning everyone
[14:01] <kfogel> flacoste: morning
[14:02] <mrevell> hey flacoste, good morning. I'll let you settle in but I have a CP request when you have time to talk about it :)
[14:04] <kfogel> sinzui: http://paste.ubuntu.com/247987/    Not sure how to interpret that error message -- there are 9 files named "_pythonpath.py" in the tree, and they are all under version control or a symlink to a file under version control, so just removing the file would be weird...
[14:05] <sinzui> I wonder if this relates the the make distclean that was requested
[14:06] <flacoste> kfogel: we want to get rid of _pythonpath, buildout allows it to a certain extent, but it's not complete yet
[14:06] <sinzui> kfogel: I'm not sure what is wrong
[14:09] <kfogel> sinzui: thanks
[14:09] <kfogel> flacoste: ok.  In the meantime, do you know what I should do to make my tree buildable?
[14:09] <kfogel> sinzui: (yeah, I was wondering the same thing re distclean)
[14:10] <flacoste> kfogel: i don't know what is the problem, and my tree is two weeks old here so...
[14:12] <kfogel> flacoste: np
[14:12] <gary_poster> kfogel: top level _pythonpath
[14:12] <kfogel> gary_poster: remove it?  (it's versioned...)
[14:12] <gary_poster> it is?  :-/  hm, checking further
[14:13] <gary_poster> uh, it shouldn't be.  checking further.
[14:15] <gary_poster> kfogel: it is not versioned.  it is in .bzrignore.  buildout-templates/_pythonpath.py.in is versioned
[14:16] <kfogel> gary_poster: sigh.  So when you do 'bzr status -v' on an unversioned-but-ignored file, it does not say "unknown file", it just returns silently.
[14:16] <salgado> JamalFanaian, ping. can you set a commit message on https://code.edge.launchpad.net/~jamalfanaian/launchpad/bug-337582/+merge/9524 so that I can use it when landing your branch?
[14:17] <kfogel> gary_poster: Unfortunately, this is the same behavior as for a versioned-but-unmodified file!  So it is difficult in bzr to ask the question "Is this file under version control?"
[14:17] <kfogel> gary_poster: (I just learned this now by testing.)
[14:18] <gary_poster> kfogel: looks like it.  I was wondering about how to ask that question too.  abentley ^^^ ?
[14:22] <abentley> kfogel: ls -V
[14:23] <gary_poster> kfogel: I hope to get the answer to this bzr question also.  oh, thank you abentley.  but kfogel, IRT the problem you started with, is the change I described sufficient? it should be.  and not removing _pythonpath.py in make clean is an oversight.  If you have a branch you are preparing for merge, it would be great to have you add that.  otherwise let me know and I will.
[14:23] <kfogel> gary_poster: my branch is of launchpadlib; it would be great if you could take care of the 'make clean' issue with _pythonpath.py.
[14:24] <kfogel> gary_poster: rebuilding now, after 'rm _pythonpath.py' in the top level
[14:24] <kfogel> abentley: thanks
[14:24] <gary_poster> kfogel: cool, ok
[14:34] <kfogel> gary_poster: sigh, 'make run' failing, seems I might be out-of-date with some deps: http://paste.ubuntu.com/248001/
[14:35] <gary_poster> kfogel: no, you just need to run make schema
[14:35] <kfogel> gary_poster: and launchpad-dependencies failing to update in system manager, hmm: http://paste.ubuntu.com/248002/
[14:35] <kfogel> gary_poster: I tried that
[14:35] <gary_poster> kfogel: uh.
[14:36] <kfogel> gary_poster: http://paste.ubuntu.com/248003/
[14:36] <kfogel> gary_poster: though 'make schema' seems to have failed only with perm denied errors, let me see...
[14:36] <gary_poster> kfogel: for your apt problems, I'm not your man.  I would try uninstalling and reinstalling, or seeing if there's some force-reinstall
[14:36] <kfogel> http://paste.ubuntu.com/248004/
[14:37] <kfogel> gary_poster: hmmm, manually doing the rm -rf seems to have fixed things, fingers crossed
[14:38] <gary_poster> kfogel: I've encountered those Permission denied thing too.  Don't know why they appear (seemingly bzr-related, obviously).  didn't investigate. but just removed them by hand as you did
[14:39] <kfogel> gary_poster: :-(   I'll bet the same is true of all of us.
[14:39] <kfogel> gary_poster: okay, 'make schema' completed apparently successfully.  trying 'make run' now
[14:40] <kfogel> Ha.  Ha hah hah HAH.  HAAAAAAAAAAAAAAh.  Of course, I can't test my change if my FIREFOX IS GOING TO FREEZE UP ON ME, NOW CAN I???
[14:40] <gary_poster> kfogel: lol, hang in there
[14:42] <kfogel> gary_poster: :-)
[14:43] <kfogel> gary_poster: just need to rant.  btw, killed ffox, now it won't start up at all
[14:44] <gary_poster> urg :-(
[14:45] <mars> check the network meter
[14:45] <mars> sometimes FF will spin in the background before rendering if there is a bunch of JS or Flash to load onto the pages
[14:46] <bigjools> FF is rapidly losing my friendship
[14:46] <mars> bigjools, noodles775 uses Chrome....
[14:46] <kfogel> gary_poster: (all good now)
[14:46] <gary_poster> kfogel: \o/ :-)
[14:46] <bigjools> can I get noscript and adblock for it?
[14:47] <bigjools> and firebug
[14:47] <kfogel> sinzui: so my change appears to have had no effect.  Here's what I did: manually took my patch and 'patch'ed it into sourcecode/launchpadlib in the new tree I created with rocketfuel-branch, built that tree, make clean && make build && make schema && make run.
[14:49] <sinzui> I puzzled then
[14:49] <sinzui> api/index.html had no title?
[14:51] <sinzui> kfogel: does this work when called by itself?
[14:51] <sinzui> bin/apiindex lib/canonical/launchpad/apidoc/wadl-development.xml
[14:51] <gary_poster> kfogel: we are using launchpadlib from egg AFAIK (on call)
[14:52] <kfogel> gary_poster: thank you
[14:52] <kfogel> gary_poster: but do we re-unpack that egg every time?  I mean, I patched the source tree on disk.
[14:53] <kfogel> gary_poster: and my "title=" mods are still in it...
[14:53] <kfogel> sinzui: yes, let me look at teh output
[14:54] <gary_poster> kfogel: sourcecode is not consulted.  I'm checking if we still update launchpadib in sourcecode
[14:54] <kfogel> gary_poster: hunh.  shouldn't we get rid of the one in sourcecode then?
[14:54] <gary_poster> kfogel: +1
[14:54] <kfogel> sinzui: ran that command -- the output does not contain "title=" anywhere
[14:55]  * sinzui look at the xslt again
[14:56] <bac> kfogel: do you want to join the reviewers meeting at the top of the hour to discuss your fine work on the wiki update?
[14:57] <sinzui> kfogel: your changes must be fine, I think something else is going the generation here. Break the XSLT, do something to verify that we get errors if this file is insane
[14:57] <kfogel> bac: might be a good idea
[14:57] <bac> kfogel: if so, join #launchpad-meeting in three minutes
[14:57] <gary_poster> kfogel: looks like it has been removed from utilities/sourcedeps.conf so it must be still in the rsynced directory,  I'll send something to RT...
[14:58] <kfogel> gary_poster: rsync'd from where?  devpad?  We shouldn't have *any* of those left...
[14:59] <gary_poster> kfogel: no?  I'm a bit behind the times on what we do for sourcecode I guess.  I thought we were still doing that.  So, maybe you and I just have old sourcecodes?
[14:59] <kfogel> gary_poster: apparently.
[14:59] <kfogel> gary_poster: nothing can come from devpad because devpad is not publicly accessible :-).
[14:59] <kfogel> gary_poster: we open-sourced.  Here, let me find you the press release... :-)
[14:59]  * kfogel kidding
[15:00] <kfogel> bac: there
[15:00] <gary_poster> kfogel: :-P :-) so, if this is only controlled by sourcedeps, then we are ok already afaik
[15:00] <rockstar> abentley, #launchpad-meeting
[15:01] <abentley> me
[15:01] <abentley> Doh.
[15:01] <gary_poster> :-) you!
[15:02] <noodles775> beuno: I'm looking at the code that creates the breadcrumbs (c.lp.browser.launchpad.Hierarchy) - and the presentation is actually in the code rather than a separate template. Are you going to be working on that with salgado? I'd like to add something like render_ul(), but don't want to waste time if it'll be done elsewhere.
[15:02] <JamalFanaian> salgado: hey, sorry i was away.. what do you mean exactly?
[15:03] <kfogel> sinzui: due to a typo, I removed bin/apiindex.  it's not versioned, so I can't revert.  'make build' and 'make run' don't regenerate it.  Where does it come from, and how do I get mine back?
[15:03] <salgado> JamalFanaian, I'm going to request a merge of your branch into our trunk branch, and to do that I need a commit message -- something that describes (in one or two sentences) what you've done in your branch
[15:03] <kfogel> sinzui: ah, lib/lp/scripts/utilities/apiindex.py
[15:03] <sinzui> kfogel: the first make build
[15:04] <sinzui> kfogel: the scripts to no regenerate if bin is there
[15:04] <JamalFanaian> salgado: would you like me to just post it here?
[15:05] <salgado> JamalFanaian, yeah, here would be fine, but you could also enter it on the merge-proposal page
[15:05] <JamalFanaian> salgado: ok
[15:05] <JamalFanaian> salgado: Renamed the sort option in the branch list page from "by registrant" to "by owner".
[15:05] <JamalFanaian> is that good?
[15:06] <salgado> JamalFanaian, it is great, thanks
[15:06] <beuno> noodles775, I will
[15:06] <JamalFanaian> salgado: thank you :)
[15:06] <beuno> noodles775, we can tackle this with salgado then
[15:07] <noodles775> beuno: yeah, it wouldn't make sense to do the css until the html is sorted (a simple ul :) ).
[15:09] <beuno> noodles775, agreed. Thanks.
[15:17] <beuno> noodles775, replying
[15:17] <noodles775> thanks beuno
[15:28] <joshuahoover> sorry if this is off topic, but are there plans to ever provide launchpad as a package vs. what we have today?
[15:29] <beuno> joshuahoover, no, we want people to contribute, not set up instances  :)
[15:30] <joshuahoover> beuno: got ya...i was asked by a former co-worker who is interested in launchpad for a project he's working on for the us army
[15:32] <kfogel> https://dev.launchpad.net/PatchSubmission   review on new wording welcome
[15:32] <kfogel> bac: ^^
[15:32]  * bac looks
[15:33] <beuno> noodles775, done
[15:33] <beuno> approved
[15:33] <noodles775> Cheers :)
[15:35] <bac> kfogel: i think rocketfuel-setup makes the .bazaar/locations.conf work so that you don't have to name the destination for pushes to launchpad.  so step 3 would just be 'bzr push'
[15:36] <jml> anyone here know xsl?
[15:36] <kfogel> jml: heh, working on some xsl right now.  doesn't mean I know it, though.  What do you need?
[15:36] <jml> kfogel, I just filed bug 409360 and I was going to try to fix it
[15:36] <mup> Bug #409360: API docs need a table of contents <Launchpad Foundations:New> <https://launchpad.net/bugs/409360>
[15:36] <kfogel> jml: we're working in the same file, it seems.
[15:37] <jml> kfogel, wadl-to-refhtml.xsl?
[15:37] <kfogel> jml: so, I don't know how to generate TOC in xsl.  I may be able to help with regenerating the HTML, once you get to that point.
[15:37] <kfogel> jml: right, that file
[15:37] <jml> kfogel, hmm. me neither.
[15:37] <jml> google to the rescue
[15:38] <kfogel> sinzui: so, I replaced the contents of wadl-to-refhtml.xsl with the word "fish" and re-ran bin/apiindex, and it still succeeded!  Obviously, sourcecode/launchpadlib/src/launchpadlib/wadl-to-refhtml.xsl is not the file apiindex is actually using...
[15:38] <kfogel> sinzui: but, sys.path in apiindex does contain "/home/kfogel/private/work/canonical/lp/lp-sourcedeps/eggs/launchpadlib-1.0.2-py2.4.egg"
[15:38] <kfogel> sinzui: is it getting launchpadlib's .xsl file directly from inside the egg?
[15:40] <sinzui> ah
[15:40] <sinzui> kfogel: you need to hack on launchpadlib, not launchpad.
[15:40] <jml> kfogel, almost certainly it is.
[15:41] <kfogel> sinzui: I know.  That's what I'm trying to do.
[15:41] <kfogel> sinzui: my patch is to launchpadlib; the question is, how do I get the patch into a launchpadlib that launchpad is paying attention to?
[15:41] <kfogel> sourcecode/launchpadlib is apparently not the one!
[15:42] <kfogel> sinzui: it seems I need to regenerate the egg, yah?
[15:42] <beuno> sinzui, noodles775, do you guys want to have a call about the remaining navigation questions?
[15:43] <noodles775> Sure.
[15:44] <sinzui> kfogel: you are hacking on the launchpad code, you need to be hacking on the launchpadlib code it seems. https://code.edge.launchpad.net/launchpadlib
[15:44] <kfogel> sinzui: please read above
[15:44] <sinzui> kfogel: a different checkout
[15:44] <kfogel> sinzui:  I'm already there.  Long done :-).  I'm hacking on launchpadlib.
[15:44] <kfogel> sinzui:  the question here is "How do get Launchpad's bin/apiindex to use the changed launchpadlib?"
[15:45] <sinzui> I think the next step is to place your new egg into develop-eggs/ gary_poster will no for certain. I have never done egg development
[15:46] <sinzui> beuno: I am preparing for a meeting. I expect to be available in 1 hour
[15:46] <gary_poster> kfogel: yeah, what sinzui says is probably the easiest.  I think I put it in the docs, checking
[15:46] <beuno> noodles775, are you around in an hour?
[15:46] <leonardr> gary_poster: aren't we still far away from having launchpad use an up-to-date (post-lazr.restfulclient) launchpadlib?
[15:47] <leonardr> the best thing to do might be to move that file back into launchpad now that launchpad is open source
[15:47] <noodles775> beuno: for 15mins yes (I've got to run in 1hr 15mins)
[15:47] <beuno> sinzui, noodles775, ok, ping me as soon as you guys are available
[15:48] <gary_poster> leonardr: oh is that what this is?  yes, it's the next big thing to which I plan to return, having almost gotten one off my plate, but I have not proven to be a speed demon for this particular task :-/
[15:49] <noodles775> beuno: I'm available any time so, I guess sinzui can ping us when he's available :)
[15:49] <gary_poster> kfogel: fwiw, the way to do a develop egg is described in doc/buldout.txt, albeit in passing.  grep for "develop another dependency"
[15:49] <kfogel> gary_poster: thanks
[15:49] <beuno> noodles775, so am I
[15:49] <kfogel> gary_poster: will move that to dev wiki as appropriate
[15:49] <gary_poster> kfogel: but what leonardr brings up is a legitimate concern
[15:50] <kfogel> gary_poster: leonardr is just talking about the wadl file, right, not all of launchpadlib?
[15:50] <gary_poster> kfogel: I'm not clear on dev wiki vs. doc directory.  kiko seemed to agree with my reviewers that this should go in the doc directory, although we are supposed to clean up that directory.
[15:50] <kfogel> gary_poster: btw, is most of buildout.txt up-to-date?  I.e., I could transfer to dev wiki with impunity?
[15:51] <kfogel> gary_poster: I'm not sure I see any reason to have anything in the doc/ directory other than a single README saying "Please see https://dev.launchpad.net/."
[15:51] <gary_poster> kfogel: yes, but the doc directory version is supposed to be the source, according to my last discussions.
[15:52] <kfogel> gary_poster: there can only be one master, but it can be anywhere we want.  The only complication is when we auto-generate some other stuff from the source -- is that happening here?
[15:52] <gary_poster> kfogel: wiki vs. doc directory: that is a discussion you need to have on the list.  It was already started, with kiko somewhat agreeing that some stuff belongs in the doc directory.  the policy is not clear, though I believe he gave a general direction dor a distinction of what goes where.  jml, for instance, may have a strong opinion about docs going in the doc directory
[15:53] <kfogel> gary_poster: I understand that there is a larger discussion here, & will raise it.  In general, I don't see any good reason to split our documentation between in-tree and in-wiki.  That way lies madness not only for contributors but for (*cough*) Canonical employees like me.
[15:53] <kfogel> And you :-).
[15:54] <gary_poster> kfogel: :-) (I don't have a horse in the race really, but a (new?) decision ITR should at least be aware of the history and the agreements.)
[15:54] <gary_poster> I mean past disagreements
[15:55] <gary_poster> the only horse in the race I have is that I want to be able to use ReST, not moin, wherever I have to write docs :-)
[15:55] <jml> hello what.
[15:55] <gary_poster> what's on first base
[15:55] <jml> I think there should be one place
[15:55] <kfogel> jml++
[15:55] <jml> and that should be in the tree
[15:55] <jml> and it should be in rest
[15:55] <kfogel> jml: sigh
[15:55] <kfogel> jml: why not the dev wiki?
[15:55] <jml> (in that order of conviction)
[15:56] <kfogel> jml: that is, why is some of our documentation in the wiki and other docs in tree, making every dev search two places?
[15:56] <jml> kfogel, because I think I hate textarea more than I hate waiting for our test suite
[15:56] <jml> kfogel, but it's a close call.
[15:56] <kfogel> jml: get the ViewSourceWith plugin.  This is an easily solved problem.
[15:56] <kfogel> I never edit in my browsre.
[15:56] <abentley> beuno: Could you please review https://code.edge.launchpad.net/~abentley/launchpad/reassign/+merge/9463 ?
[15:57] <kfogel> jml: that is one of *many* plugins that solve this problem.
[15:57] <beuno> abentley, absolutely. On my queue
[15:57] <jml> kfogel, there's also greppability and ease of making changes to multiple docs.
[15:57] <abentley> beuno: Thanks.
[15:57] <kfogel> jml: er, well, yes, but that kind of argues against the wiki entirely.
[15:57]  * jtv goes awl
[15:58] <kfogel> jml: we don't have a perfect solution.  Having better user experience (the wiki) means a harder writer experience.  That may just be life...
[15:58] <jml> kfogel, hmm, I think that might be true
[15:58] <kfogel> jml: wiki search should answer the greppability question (and if it's broken, we should fix it, obviously)
[15:58] <jml> kfogel, also, someone should pull their finger out and allow 'bzr branch http://dev.launchpad.net/'
[15:58] <kfogel> jml: I don't have a good answer for the "similar changes to multiple docs" problem, but we deal with the wiki every day and we manage.
[15:59] <abentley> kfogel: Until our wiki plans come to fruition...
[15:59] <kfogel> jml: that would be *fantastic*
[15:59] <kfogel> jml: but: Let not the perfect be the enemy of the cliche.  Or something like that.
[15:59] <jml> kfogel, to me, the most important values I have are 'one place' and 'navigable'
[15:59] <kfogel> jml: what about "easy for newcomers and lightweight visitors"?
[15:59] <jml> kfogel, and I guess putting everything on the wiki gives us that.
[16:00] <kfogel> jml: oh, by navigable, you meant by readers?
[16:00] <kfogel> (I thought you meant for editing.  It's funny how each system supplies one of those and not the other.)
[16:00] <jml> kfogel, yeah, by people trying to figure things out :)
[16:00] <jml> kfogel, I think in-tree would provide navigation for readers
[16:00] <kfogel> jml: those are my two priorities too.  I think the wiki is the answer then, despite the fact that it is harder to edit.
[16:00] <jml> we'd just have to change the way we store docs in tree.
[16:00] <kfogel> jml: uh... hyperlinks?
[16:00] <jml> kfogel, documentation build step
[16:00] <kfogel> jml: oh, from .txt to .html?  We could do that.
[16:01] <gary_poster> Sphinx
[16:01] <gary_poster> my pref
[16:01] <jml> kfogel, that's what Python does, and it's pretty nice
[16:01] <jml> kfogel, we can also make sure that the docs for trunk are always available on the web
[16:01] <kfogel> jml: ideal would be if launchpad-top/docs/  ==  dev.launchpad.net/
[16:01] <jml> kfogel, bzr does this already
[16:01] <kfogel> bzr branch and edit away
[16:01] <kfogel> jml: all these are things for the future.  in the meantime, our docs are split across two places; I'd like to get docs/* into the wiki.
[16:02] <jml> e.g. http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html
[16:02] <jml> kfogel, I think that makes sense.
[16:02] <kfogel> jml: being editable in the wiki is a huge advantage too.  Really huge, actually.  If fixing a doc bug means getting a branch merged, nothing will ever get fixed by contributors.
[16:03] <jml> kfogel, yeah. that makes me sad though.
[16:03] <gary_poster> m etoo
[16:03] <kfogel> jml: another process problem that could use solving ;-)
[16:03] <kfogel> jml: but, if the wiki were backed by a bzr branch with auto-commit-after-identifying-through-OpenID, then we'd be golden.
[16:04] <jml> someone's already done this for hg.
[16:04] <gary_poster> jml: with Sphinx?
[16:04] <jml> which is embarrassing because we've been talking about it for bzr for years
[16:04] <jml> gary_poster, no. just a custom wiki that is a view on an hg branch.
[16:04] <jml> gary_poster, some sort of wiki syntax.
[16:04] <kfogel> jml: we get trapped by our own shadow too often
[16:05] <gary_poster> jml: gotcha
[16:05] <kfogel> gary_poster: how to build an egg?  (I could find this on the Net, but if it's two easy steps and you know them, please share)
[16:06] <gary_poster> kfogel: mm, context?  you may not need to
[16:06] <kfogel> gary_poster: I've modified my buildout.cfg to point to my new 'develop' location, I just need to put a new eg there
[16:06] <kfogel> gary_poster: from the beginning, for clarity:
[16:06] <gary_poster> kfogel: ah, you don't need egg
[16:06] <kfogel> ah
[16:06]  * kfogel listens
[16:06] <gary_poster> kfogel: just symlink your branch into the lp tree using the name you put in the develop section
[16:06] <gary_poster> then rerun bin/buildout
[16:07] <gary_poster> you may have to change the version
[16:07] <gary_poster> in versions.cfg
[16:07] <gary_poster> note that leonardr's warning was about the package, not about the output
[16:07] <gary_poster> so if this is from trunk, your change will break
[16:08] <gary_poster> releasing a 0.1.1 with your change (branching from the 0.1 source, if we were good package maintainers) would be the right thing to do
[16:08] <beuno> intellectronica, when the project doesn't have milestone, it lets you target, and shows you an empty overlay
[16:08] <kfogel> gary_poster: reading your instructions makes me realize how badly I need breakfast.  Back soon.
[16:08] <gary_poster> or doing what leonard said, which is to temporarily give up on eggs because I Haven't finished eggifying everything, which is what is blocking this process
[16:08] <gary_poster> ack
[16:10] <beuno> deryck, hey dude
[16:11] <deryck> beuno, hey man
[16:11] <beuno> deryck, got any news for me on your awesome inline editing?
[16:11] <deryck> beuno, very, very close. :)
[16:12] <beuno> deryck, is it up for review yet?
[16:12] <deryck> beuno, no, not yet.  I need the rest of today to finish.  So in review late today or early tomorrow.
[16:13] <beuno> deryck, perfect
[16:13] <deryck> beuno, I had CHR and OCR two of the last three work days, so today really is the first I've had to just sit and work on it since we last talked.
[16:15] <beuno> deryck, no worries. I'm just anxious  :)
[16:16] <deryck> beuno, yeah, me too actually.  I like this feature a lot.
[16:18] <intellectronica> beuno: oh, right. that doesn't make much sense. fixing
[16:26] <intellectronica> beuno: fixed and pushed
[16:26] <intellectronica> allenap: https://pastebin.canonical.com/20793/ is the incremental
[16:27] <allenap> intellectronica: Cool.
[16:28] <beuno> intellectronica, super, thanks. Just submitted the review
[16:34] <intellectronica> beuno: i don't know why you don't see the spinner. i always do. i remember you've had this before, though
[16:35] <beuno> intellectronica, I'm happy to trust you, I just don't. As well as I don't see any feedback after clicking until the green flash
[16:35] <beuno> the overlay is gone, and I don't see anything until it flashes
[16:35] <intellectronica> that's weird, and it needs investigation. looks fine here
[16:36] <intellectronica> beuno: as for the location of the overlay - it's just centered around where you clicked. we can compensate and make sure it doesn't go beyond the current page dimensions. that's a lazr fix, so i'll do that in another branch - i don't think it should block this one
[16:37] <beuno> intellectronica, agreed. If you schedule that change to lazr-js, it's fine to have it this way for a little while
[16:37] <intellectronica> beuno: finally, where do you want to see the milestone icon? we didn't display it before. i'm not sure it makes sense to repeat it for each milestone what do you think?
[16:38] <beuno> intellectronica, on the bugtask, no?
[16:38] <beuno> we don't display it now?
[16:38] <intellectronica> beuno: all other comments are clear and easy to address
[16:38] <beuno> cool
[16:38] <intellectronica> beuno: no, we just display the milestone title
[16:40] <beuno> intellectronica, I swear I saw the milestone icon. Maybe I broke it with my sprites branch
[16:40] <beuno> anyway, if you can show it, super
[16:40] <beuno> otherwise, it's a separate bug
[16:40] <beuno> I think it will make it clearer
[16:40] <intellectronica> beuno: you mean, next to the milestone title?
[16:40] <beuno> intellectronica, yes
[16:41] <intellectronica> i think it doesn't make much sense to repeat it for every row, but it's easy to give it a try and see
[16:41] <beuno> intellectronica, well, you usually don't have a milestone per every row?
[16:42] <intellectronica> beuno: why not?
[16:42] <beuno> intellectronica, don't know, doesn't seem to be the common case
[16:42] <beuno> you *can*
[16:42] <beuno> it's just rare that things line up so much  :)
[16:42] <intellectronica> right, i see what you mean. it is the less common case
[16:43] <intellectronica> in general, most bugs have only one task anyway
[16:43] <beuno> xzactly
[16:44] <bigjools> beuno: did you have any more comments on my mockups?
[16:44] <beuno> bigjools, I've had it open in a tab for days
[16:44] <beuno> all I can think of is "it's confusing"
[16:45] <bigjools> beuno: welcome to soyuz
[16:45] <bigjools> I can take you through it on a call later if you like
[16:47] <beuno> bigjools, I think I understand what each element is, it's just that the layout is confusing. Maybe we should be mocking this up on a more wireframe level?
[16:47] <beuno> sinzui, noodles775, how are we coming along with that call?  postpone til tomorrow?
[16:47] <bigjools> beuno: which page are you talking about?
[16:48]  * sinzui almost ready
[16:48] <bigjools> I made 2
[16:48] <beuno> bigjools, I know I'm not being helpful, I need to sit down and dedicate a few hours to this. I just haven't been able to.
[16:48] <beuno> bigjools, looking at: http://people.canonical.com/~ed/dspr_mockup2.png
[16:48] <beuno> which is an improvment ovr the previous one
[16:48] <bigjools> beuno: they are pretty much exactly as we discussed in our sprint, apart from the second where I took the liberty of moving stuff to the sidebar
[16:49] <bigjools> ah, I did three then :)
[16:50] <beuno> bigjools, I sucked at solving the problem then!
[16:50] <bigjools> beuno: it was a team suck^Weffort
[16:50] <bigjools> beuno: it would be best if we had a call, I can explain the nuances
[16:51] <beuno> bigjools, agreed. Can we have it tomorrow, so I can clear my schedule to work on it after the call if needed?
[16:51] <bigjools> beuno: +1
[16:52] <noodles775> beuno, sinzui: I've replied to sinzui's post on the MP with some more screenshots, just to help visualize things if/when we call.
[16:52] <sinzui> beuno: noodles775: I am ready
[16:52]  * noodles775 waits for beuno's skype conference call :)
[16:53]  * beuno fire sup skype
[16:56] <beuno> noodles775, sinzui, http://people.canonical.com/~michaeln/menu_3-0/10-project-index.png
[16:59] <noodles775> sinzui: http://people.canonical.com/~michaeln/menu_3-0/11-sprint.png
[17:01] <noodles775> sinzui: http://people.canonical.com/~michaeln/menu_3-0/6-no-location-default-launchpad.png
[17:31] <beuno-lunch> salgado-lunch, are you available to have a call around 20UTC today?
[17:37] <bac> intellectronica: you indicated this bug was similar to others you've fixed in the past and should be easy.  https://bugs.edge.launchpad.net/malone/+bug/397457
[17:37] <mup> Bug #397457: Bug privacy edit icon is not visible <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/397457>
[17:38] <bac> intellectronica: any chance of it getting bumped in priority?  the inability to change bug privacy is quite annoying
[17:39] <intellectronica> bac: i don't know if it's similar. why the urgency? i can definitely spend a bit of time investigating, at the very least
[17:41] <bac> intellectronica: the urgency is just broken functionality for all of our fine users of webkit-based browsers make their (my) experience less than rewarding.
[17:42] <intellectronica> bac: well, if it's like the other one than talking about it takes longer than fixing. i'll try to have a look later today
[17:42] <bac> intellectronica: great!
[17:54] <ara> intellectronica, hey tom, I am trying to break a lock and I get an error
[17:54] <ara> bzr: ERROR: Unsupported protocol for url "lp-45197200://~mago-contributors/mago/mago/.bzr/branch/lock
[17:54] <salgado> beuno-lunch, can we make it 21UTC?
[17:54] <ara> intellectronica, any ideas?
[17:55] <ara> bzr: ERROR: Unsupported protocol for url "lp-45197200:///~mago-contributors/mago/mago/.bzr/branch/lock
[17:55] <intellectronica> ara: right, just replace the bogus stuff in the beginning of the url to bzr+ssh://bazaar.launchpad.net and it should work
[17:56] <intellectronica> i don't know why bzr spits this weird stuff
[17:56] <ara> intellectronica, ta! (btw, you're missed in the Platform sprint...)
[17:56] <intellectronica> maybe rockstar or abentley know? ^^^^^
[17:56] <intellectronica> ara: and i'm missing you. have fun!
[17:59] <beuno-lunch> salgado, even better
[17:59] <beuno-lunch> salgado, just ping me when you're ready
[18:03] <beuno-lunch> BjornT, do you know why adding bug comments is so slow? (4+ seconds)
[18:03] <beuno-lunch> is there a bug filed about it?
[18:09] <mrevell> Night all!
[18:16] <kfogel> gary-lunch: ping when you're back
[18:18] <BjornT> beuno-lunch: well, i'm guessing it's because lp is slow in general. loading the front page also took 4+s seconds just now
[18:19] <BjornT> beuno-lunch: but we certainly can speed it up a bit. we're currently doing at least two requests, where one should be enough
[18:22] <beuno> BjornT, do you want me to file a bug about it?
[18:22] <beuno> I *think* most ajax interactions aren't that slow, like, say, subscribing
[18:24] <BjornT> beuno: sure. i don't think it's not easy to fix, though; it requires changes to the api infrastructure
[18:24] <beuno> BjornT, gotha. Will file it for tracking purposes
[18:25] <gary_poster> kfogel: pong
[18:27] <kfogel> gary_poster: hey.  So I read what you wrote to me a while back (right before I ate).  I confess I understood it not :-(.  You might have to say it again with more words?  My starting point is: https://code.edge.launchpad.net/~kfogel/launchpadlib/apidoc-html-title-attrs .  I'm trying to test r53 there.
[18:28] <kfogel> gary_poster: you said I don't have to build a new egg?  But then how do I make Launchpad's bin/apiindex use the new wadl file?
[18:29] <gary_poster> kfogel: ok, this is complicated, no doubt, and you are also going to be sad as to where we are with this particular package and your goals.
[18:29] <kfogel> gary_poster: thank you for preparing me :-)
[18:32] <kfogel> gary_poster: (btw, I have a conf call in 30min, could take this up after that's over if you want)
[18:32] <gary_poster> kfogel: :-) so, first (forget about eggs and such for now), we are not using launchpadlib trunk in launchpad.  We are using 0.1 (notice that you are editing something > 1.5.  We will not be able to move forward until I get launchpad to use zope eggs.  That branch has been following me around for probably months now.
[18:32] <gary_poster> Everybody wants it to be done, including myself.  I hope to get it done next, like, within the next week.  I know flacoste wants this to have been done long ago.  So, you might want to consider waiting to fix whatever it is you want to fix in launchpad for a week.  Then again, you might not.
[18:32] <gary_poster> sorry, I write novels
[18:33] <kfogel> gary_poster: no, this is great, keep it flowing
[18:33] <gary_poster> kfogel: second, there are two kinds of ways to work with new revisions.  If you are testing something tricky, sometimes you want to use a develop egg.  That technique is almost never something we actually want to commit.
[18:33]  * kfogel absorbs hungrily
[18:34] <gary_poster> kfogel: the other way is to make a new egg.  it can be temporary (you don't check it in) or permanent (you check it in).  This is described as thoroughly as I could in the buildout doc to which I referred you earlier
[18:35] <gary_poster> kfogel: if we were in a good place with launchpadlib, this is what I would have suggested to you:
[18:37] <gary_poster> (If the wind blew from a southeasterly direction:) Make an egg and put it in download-cache/dist as described in the document.  Upgrade your versions.txt in a launchpad branch and see if it works.  If it does, ideally arrange socially and technically to make a real release of launchpadlib, put the release's egg in download-cache/dist (discarding your temporary one), and put your launchpad branch up for review.
[18:38] <gary_poster> (if the wind blew from a northwesterly direction, I would explain how develop eggs works.  their cleanup-after-test story is somewhat better)
[18:39] <gary_poster> kfogel: so what to do *now* is a unclear.  I'd say you have three options, on the face of it.
[18:39] <gary_poster> (where "now" recognizes that our launchpadlib + launchpad story is unfortunate)
[18:40] <gary_poster> 1) see if I do what I want to do and get the zope eggs in by next week.  then see if you can add launchpadlib in the usual way.
[18:41] <gary_poster> 2) figure out a branch of whatever we used for launchpadlib 0.1.  make a branch of that, cherrypick your change, and make a 0.1.1 release, doing thinsg the normal way
[18:41] <gary_poster> 3) remove launchpadlib from the whole buildout story and add it back to the old sourcecode story.  hack away as needed.
[18:42] <gary_poster> kfogel, neither 2 or 3 are easy and quick IMO.  #1 is easy but slower than 2 & 3.
[18:42] <kfogel> gary_poster: (1) it is.  Thank you for explaining!
[18:42] <gary_poster> (because you are waiting on me; the process itself is much easier)
[18:43] <kfogel> gary_poster: what bug do I subscribe to to know when your work is done?
[18:43] <gary_poster> kfogel: welcome, and sorry our current state has foiled your dastardly plans ;-)
[18:44] <gary_poster> kfogel: the branch is https://code.edge.launchpad.net/~gary/launchpad/zbuildout
[18:44] <gary_poster> I'm not aware of a bug for the task.  There probably should be one.  bugs, and the py 2.5/2.6 effort, are waiting on it.  here's an example of a waiting bug I happen to have lying around: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/408897
[18:45] <mup> Bug #408897: Use latest zope.testing <python-upgrade> <Launchpad Foundations:New> <https://launchpad.net/bugs/408897>
[18:45] <kfogel> gary_poster: want to create a bug about the actual task and then I'll make my branch/bug dependent on it?
[18:45] <gary_poster> kfogel: ok.  lemme doublecheck in various places I forget about that there is not one already...
[18:47] <kfogel> gary_poster: np
[18:52] <maxb> Is it worth filing more "Use latest zope.foo" bugs, every time a specific need to upgrade is discovered?
[18:52] <maxb> We need newer zope.proxy and zope.security for python 2.5
[18:56] <jml> maxb, yes.
[19:02] <beuno> kiko-fud, TL call?
[19:02] <gary_poster> kfogel: bug 409480
[19:02] <mup> Bug #409480: Use source distributions (via zc.buildout) for zope dependencies <Launchpad Foundations:In Progress by gary> <https://launchpad.net/bugs/409480>
[19:03] <gary_poster> maxb: that bug is the one you are waiting on too
[19:03] <maxb> Ah, it has a bug as well as a branch
[19:03] <kfogel> gary_poster: thank you
[19:03] <gary_poster> maxb: brand new fresh bug right out of the oven :-)
[19:10] <james_w> thanks mthaddon
[19:10] <mthaddon> er, no problem (I think) :)
[19:11] <jml> :)
[19:11]  * jml is off to dinner
[19:13] <rockstar> sinzui, so, I think I might be missing a class assignment somewhere that makes the h2 of portlets gray.
[19:14] <sinzui> rockstar: h2 just works if you are using it in a class="portlet"
[19:14] <rockstar> class="yui-u portlet"
[19:16] <maxb> I have a testsuite question - are the names of the tests printed when the start, or finish?
[19:16] <maxb> i.e. if a test times out and is killed, is it the last test shown, or the next in sequence after that?
[19:17] <sinzui> rockstar: That is correct for presentation. I just updated a bug for beuno to comment on I think we need to avoid using yui-u and portlet on the same div. I have two proposals that I need feedback on
[19:17] <sinzui> rockstar: can you paste the page so that I can see the whole context?
[19:18] <beuno> sinzui, point me to the bug!
[19:18] <rockstar> sinzui, yea, one sec.
[19:18] <sinzui> beuno: https://bugs.edge.launchpad.net/launchpad-registry/+bug/405916
[19:18] <mup> Bug #405916: Update project page to UI 3.0 <story-ui-3> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/405916>
[19:19] <salgado> maxb, they're printed after the test finishes
[19:19] <rockstar> sinzui, https://pastebin.canonical.com/20818/
[19:20] <rockstar> The only thing I have left on this portlet is getting the h2 styled right.
[19:20] <sinzui> rockstar: and the calling page? it sets main_side
[19:21] <rockstar> sinzui, one sec.
[19:21] <sinzui> rockstar: the yui-u is unneed in the side portlets...it is not in a yui-g
[19:22] <rockstar> sinzui, https://pastebin.canonical.com/20819/
[19:24] <sinzui> rockstar: your <tal:side metal:fill-slot="side"> looks perfect
[19:25] <rockstar> sinzui, yeah, I thought so too, but I keep getting: http://devpad.canonical.com/~rockstar/answers-subscribers.png
[19:26] <rockstar> I can't for the life of me, get that "Subscribers" h2 to be gray, thought you might have some insight.
[19:27] <sinzui> I wonder if the id is imposing style. <h2> is always color: #5a5a5a; in maincontent and .side
[19:27] <beuno> rockstar, h2's seem to be tweaked for blueprints?
[19:28] <rockstar> beuno, maybe.  Sleuthing now.
[19:28] <beuno> intellectronica, BjornT, is there any reason why we show inactive people in the subscribers portlets?
[19:28] <beuno> rockstar, what does firebug say?
[19:28] <beuno> it should tell you where it's coming from
[19:29] <rockstar> Yup, firebug says there's some special rule overriding the color.
[19:29] <intellectronica> beuno: really? that sounds pointless
[19:29] <sinzui> beuno: rockstar I see that h2 is resent in style-3-0.css, but maybe it is wrong:
[19:29] <sinzui> body.tab-answers #mainarea #portlets .portlet.active h2
[19:29] <BjornT> beuno: i don't think so. we simply haven't cared about it, and that's the way they are rendered, i think
[19:29] <beuno> intellectronica, Bjorn, I will file a but then. It will de-clutter it a bit
[19:29] <intellectronica> cool
[19:30] <sinzui> beuno: intellectronica: wee need a process that remove deactivated and suspended users from teams and subscriptions. There is a bug for it
[19:30] <rockstar> beuno, sinzui, .tab-answers h2 is defined on line 2210 of style.css as color: 3840BE
[19:30] <sinzui> we do not want to automatically remove the user in the case of suspended because we may want to restore the user in a few days
[19:30] <beuno> yes, bug 238493
[19:30] <mup> Bug #238493: Deactivated account still appear in 'subscribers'-portlet <registry> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/238493>
[19:31] <beuno> rockstar, bad css! bad!
[19:31] <rockstar> beuno, I think the big thing is that the 3.0 styles should override the style.css stuff.
[19:31] <beuno> rockstar, it should kill style.css, actually
[19:32] <rockstar> beuno, so I can eated that bad style then?
[19:32] <sinzui> rockstar: can we tweak line 141 of style-3-0.css to fix the issue
[19:33] <rockstar> sinzui, I don't see a id="portlets" in my current mockup.
[19:34] <EdwinGrubbs> sinzui: you mentioned putting polls in a portlet. Is that for the team, or some other object?
[19:34] <sinzui> hmm
[19:35] <rockstar> Er, s/mockup/markup
[19:35] <sinzui> rockstar: I think the rule I wrote was bad then We need a definitive rule to make h2 grey
[19:35] <sinzui> EdwinGrubbs: yes, polls belong to teams
[19:35] <rockstar> sinzui, why not just .portlet h2 { color: grey }
[19:36] <sinzui> rockstar: okay, use the real colour though
[19:36] <rockstar> sinzui, yeah, I will.
[19:36]  * rockstar was being lazy
[19:38] <rockstar> sinzui, so, like I said, the real issue is that no matter what I put in the style-3.0 css, the style.css rule overrides it.  :/
[19:38] <sinzui> firebug confirms this?
[19:39] <rockstar> sinzui, yup, the color is properly set in the 3.0 styles, but then is crossed out for line 2210 of style.css
[19:40] <rockstar> Basically, h2 is set globally in style-3-0.css, and overridden in style.css to change the colors.
[19:40] <sinzui> rockstar: but 3.0 is loaded after style, and 3.0 sis after reset
[19:41] <rockstar> :/
[19:42] <sinzui> If I make a change 3 times and never see anything work, I assume I am editing or viewing the wrong thing
[19:43] <sinzui> rockstar: if you copy that crack selector from style to 3.0 and set the colour, is the issue fixed?
[19:43] <rockstar> sinzui, trying now.
[19:46] <beuno> thumper, sinzui, BjornT, could you guys fill in: https://dev.launchpad.net/UI/ThreeDotOPages
[19:46] <thumper> yes
[19:46] <sinzui> I will
[19:51] <rockstar> sinzui, I slapped my browser a bit, and it's working now.
[19:52] <sinzui> control+shift+r ?
[19:55] <rockstar> sinzui, I restarted my dev instance, and then refreshed, and everything was hunky dory.  No idea...
[20:06] <maxb> Is there any way to disable shhh.py without having to remember to say SHHH= on every make invocation and without having a local uncommitted modification that blocks merging?
[20:36] <gary_poster> maxb: pretty sure not.  I suppose we could add some sort of a ~/.NAME scheme for a directory or a file if it made sense
[20:39] <maxb> I filed bug 408564
[20:39] <mup> Bug #408564: Make shhh.py not the default <Launchpad itself:New> <https://launchpad.net/bugs/408564>
[20:43] <rockstar> sinzui, actions go above portlets, but in the same slot, correct?
[20:45] <gary_poster> maxb: cool, I see your point.  I tend to run the internal commands by hand when I want detail, but I see what you mean.
[20:46] <JamalFanaian> do you have to restart the launchpad daemon if you make any changes to the py files?
[20:47] <JamalFanaian> so far it seems like that is the case for me
[20:47] <rockstar> JamalFanaian, yes.
[20:47] <JamalFanaian> rockstar: ah ok, thanks
[20:58] <sinzui> rockstar: every block of content is a portlet. I am preparing a branch that creates an action portlet from a NavigationMenu that can be placed as the first portlet in the side
[20:59] <rockstar> sinzui, great, that would be helpful for what I'm currently doing.
[21:00] <sinzui> rockstar: I created (well reused) a navigation menu. I just invented
[21:00] <sinzui> <tal:menu replace="structure view/@@+global-actions" /> a few hours ago
[21:01] <rockstar> sinzui, ah, so it's nothing magic, just a new way to do it?
[21:01] <beuno> salgado, call?
[21:02] <sinzui> rockstar: nothing magic. I am reusing the all the nav menu exception for the black bar template (we can remove it in a few weeks)
[21:03] <salgado> beuno, haven't we moved it to 21UTC? I need to go out in a few minutes to pick up my new passport
[21:03] <beuno> salgado, ah, yes. Got my UTCs wrong
[21:03] <beuno> just ping me  :)
[21:03] <salgado> will do
[21:04] <sinzui> rockstar: beuno is looking at bug 405916, it has some screen shots showing what can happen in yui. The nicest solution is the trickiest to implement
[21:04] <mup> Bug #405916: Update project page to UI 3.0 <story-ui-3> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/405916>
[21:04]  * jml looks around
[21:05] <sinzui> rockstar:  you may want to take a look at the firefox-3.0-missing-rows.png because that is what will happen with the yui classes that are documented in the conversion page
[21:06] <JamalFanaian> Sorry if this is a retarded question, but what does foaf stand for?
[21:07] <gary_poster> sinzui: I'm getting a test failure on my zope-egg branch that is odd, and I wonder if you have any insights.  Running "./bin/test -vt test_script_default_error_dir" fails in my branch and on trunk.  The error is that "/var/tmp/lperr.test is not a directory".  I actually can't see where that directory should have been made in the test's setUp, and I wonder if it has been passing because of test ordering "luck".  How is that s
[21:07] <gary_poster> JamalFanaian: friend of a friend.  it is an rdf spec, IIRC
[21:07] <sinzui> gary_poster: on my two computers it is /var/tmp
[21:08] <JamalFanaian> gary_poster: hm... ok i guess that makes sense
[21:08] <sinzui> gary_poster: I I recall needing to root to make that directory mine during some big config change
[21:09] <gary_poster> sinzui: I have /var/tmp.  I don't have /var/tmp/lperr.test .
[21:09] <mwhudson> morning
[21:09] <gary_poster> morning
[21:10] <gary_poster> or something :-)
[21:10] <jml> hi
[21:10] <sinzui> gary_poster: I have that a lots of other dirs
[21:10] <gary_poster> sinzui: right, but presumably the tests are responsible for making that dir?
[21:10] <sinzui> gary_poster: do an ls -l and see if you lost ownership
[21:10] <sinzui> correct
[21:12] <gary_poster> sinzui: no.  I have ownership, and can add directories there.  So, on both machines, if you remove /var/tmp/lperr.test and then run that test in isolation, it passes?  If so, it's clearly something on my box.  However, I'm not convinced of that yet
[21:13] <beuno> sinzui, trying to decide
[21:13] <beuno> and understand  :)
[21:13]  * sinzui makes a quick drawing of the underlying implementation
[21:15] <salgado> beuno, if you're free, we could have the call now. (gf is late so we won't be able to get the passport today)
[21:15] <beuno> salgado, sure
[21:16] <beuno> salgado, I'm on skype: martin.albisetti
[21:16] <salgado> I think I have you
[21:24] <gary_poster> sinzui: when you have a moment, then, I think that this https://pastebin.canonical.com/20830/ is necessary to make ``./bin/test -vt test_script_default_error_dir`` pass in isolation, without a primed /var/tmp.  It works for me.  You and (mostly) Stuart seem to be the ones who have touched this, so if you can verify that what I am proposing seems reasonable, I would appreciate it.  (If you don't have time, understood.)
[21:27] <beuno> jml, FWIW, edit away on the wiki!   :)
[21:27] <jml> beuno, thanks :)
[21:28] <sinzui> beuno: I added a comment that explains what is making the pictures
[21:30] <sinzui> gary_poster: I get the same error after I delete the dir
[21:30] <gary_poster> sinzui: cool
[21:30] <gary_poster> sinzui: ok good enough, unless you want to look at the patch.  I think it is right. :-)
[21:30] <sinzui> I wonder id it fails when the layer is run
[21:30] <sinzui> I bet something else creates it
[21:31] <beuno> sinzui, does my inclination towards #4 align with your expectations?
[21:32] <sinzui> yes, that is what I have ready to commit because that is what I want to do. I think I should not recommend it to all engineers since it requires more though
[21:32] <sinzui> t
[21:33] <beuno> sinzui, I commented on your preferred option as well
[21:34] <gary_poster> the layer is run when you run this in isolation.  the test may be in the wrong layer, no idea.  but the test's setUp is already creating an oops directory at another location and populating it, so this is at least not out of character
[21:37] <sinzui> beuno: I think messing with yui-* definitions is a bit dangerous. These problems we are seeing as the reason yui-grid is deprecated. New browser can do this better, so the next layout solution for YUI will use CSS 3
[21:38] <beuno> sinzui, agreed. Still, we need to make sure the end result is good, no matter what we use
[21:39] <sinzui> I think this will be a lot easier when I compile this experience into sample templates
[21:57] <sinzui> rockstar: I am now splitting my work into 3 branches. The first is an infrastructure branch that will help with the menus and provide layout ideas. My branch also has some fixes for FAQs
[21:58] <rockstar> sinzui, yeah, I've been keeping my branches in pipes so that I don't have to split it up later.
[21:58] <rockstar> sinzui, I'm currently auditing the answers pages to make sure I didn't forget anything.  That's how I found I had forgot action menus.
[21:58] <sinzui> rockstar: I have learned never to mix yui-* with portlet
[21:59] <rockstar> I don't use answers enough to know what might be missing.
[21:59] <bac> sinzui: quick question, the portlets i have on the side don't have rounded corners where the examples i've gotten from you and bigjools do.  what does that indicate?
[21:59] <sinzui> I added links to the faqcollection menu
[21:59] <rockstar> sinzui, why?  I though yui-* wasn't doing anything currently.
[21:59] <thumper> sinzui: one thing that I found when starting the conversions, is that I didn't have any expectations of what the changes would be
[21:59] <thumper> sinzui: is it expected that the text gets bigger?
[22:00] <sinzui> bac CSS .side .portlet. I think you are missing the portlet class on you content divs, or you are not using the side slot
[22:00] <bac> sinzui: i know i am using the side slot
[22:01] <rockstar> thumper, yes, in some places.
[22:01] <rockstar> thumper, generally, I just went with the flow of what happened with CSS, unless there was something totally out of whack (like most the answers CSS)
[22:01] <sinzui> rockstar: yui-* does positioning, not decoration. since our content often has rules to not render if the portlet is empty, you get wholes in your layout: https://bugs.edge.launchpad.net/launchpad-registry/+bug/405916.
[22:01] <mup> Bug #405916: Update project page to UI 3.0 <story-ui-3> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/405916>
[22:02] <sinzui> rockstar: think of yui-g as a tr and yui-u as td, and the 'first' class a a col rule. They all assume the content is always rendered and demands that it control which is first.
[22:03] <rockstar> sinzui, Ah, I see. I wondered how first would be used if that portlet wasn't rendered.
[22:04] <sinzui> rockstar: so I am being very strategic with yui-g. never put an optional portlet next to an essential portlet. I will update the conversion doc with my experience and suggest 3 different combinations of yui-* classes to make the page display well
[22:04] <rockstar> sinzui, when you say "Global object menu" do you mean action menu?
[22:04] <rockstar> sinzui, cool.
[22:05] <rockstar> sinzui, I've also been trying to update it as I go along.
[22:05] <sinzui> yes, the action menu what I mean
[22:05] <rockstar> sinzui, so are you planning on fixing that bug soon?
[22:06] <rockstar> I was just going to do what you proposed earlier.
[22:06] <sinzui> thumper: the bigger text is a side-effect of the backward compatible fonts rules that were added last release. I am tempted to remove them in my next branch
[22:06] <sinzui> rockstar: I am making that branch now.
[22:06] <beuno> sinzui, do it. I keep on promising I will and never do
[22:07] <rockstar> sinzui, okay.  Do you have an ETA on that?
[22:07] <sinzui> goody. I get to see if my page really looks like the mockup now
[22:07] <sinzui> Landing tomorrow. I'll give you the branch URL when it is ready
[22:08] <jml> g'night all.
[22:08] <beuno> night jml
[22:13] <bac> sinzui: could you take a peek at this snippet:  http://paste.ubuntu.com/248246/
[22:13] <bac> sinzui: re: square corners
[22:13] <sinzui> bac You do not need yui-u or first because the classes are not in a yui-g
[22:17] <sinzui> bac: crtl+shift+r if you are not seeing rounded corners. The rule in the css is .side .portlet {
[22:17] <sinzui>     -moz-border-radius: 3%;
[22:17] <sinzui>     -webkit-border-radius: 3%;
[22:17] <sinzui> }
[22:18] <sinzui> I see a     border-radius: 3%; property too
[22:23] <bac> sinzui: the corners are roundy in ff but not safari
[22:24] <sinzui> bac: That is interesting
[22:24] <sinzui> bac: note that we have both the webkit and official properties in the rule. Can you try to fix the error?
[22:32] <bac> sinzui: yeah, can you give me an idea where to start?  just poking at the CSS?
[22:34] <sinzui> bac:-webkit-border-radius is safari 1-3, border-radius is safari 4. I expected that to just work
[22:34] <sinzui> bac: start with this reference: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(CSS)
[22:35] <bac> sinzui: changed -webkit-border-radius to 5px; and it works
[22:35] <sinzui> interesting
[22:36] <sinzui> bac: I suppose that border-radius is not supported as I thought. It is listed as experimental
[22:37] <bac> mwhudson: ping
[22:37] <mwhudson> bac: hello
[23:01]  * rockstar standses up
[23:03] <maxb> "Send the email to contributor-agreement@canonical.com and to the project lead for the project in question (usually, that's the person who asked you to send in the form)."   -- does that mean I'm supposed to talk to someone before filing the contributor agreement?
[23:04] <lifeless> is it for launchpad?
[23:04] <maxb> yes
[23:04] <lifeless> kiko
[23:04] <lifeless> just mail him the agreement
[23:05] <lifeless> that prose seems to assume much more centralised communication than we're seeing
[23:15] <thumper> rockstar: http://kiwicon.org/default
[23:17] <lifeless> classic
[23:21] <mwhudson> thumper: i hear rumours of a 2009 version of that, know anything about it?
[23:21] <thumper> mwhudson: look at the twitter feed
[23:22] <thumper> mwhudson: Nov 28th 29th
[23:22] <mwhudson> ah, another weekend thing
[23:25] <thumper> sinzui: got a few minutes tot alk?
[23:25] <sinzui> I do
[23:36] <sinzui> thumper: https://code.edge.launchpad.net/~michael.nelson/launchpad/3-0-menu/+merge/9577
[23:59]  * thumper goes to cook bacon - http://xkcd.com/418/