[00:22] <wgrant> cprov: Is it considered a bug that the component listed for a build sometimes lies?
[00:22] <wgrant> It can change after the build completes, if the package is promoted/demoted.
[00:23] <wgrant> That can be a bit confusing, as the only way to work out where it really built is checking the override-sources-list line in the build log.
[00:47] <spm> *** FYI. restarting codehosting for a Cherry Pick ***
[02:19]  * wgrant beats the AJAX milestone picker with a how-did-you-get-around-the-security-policy bat.
[02:21] <cprov> wgrant: sort of, it changes according to subsequent overrides.
[02:21] <wgrant> cprov: Right.
[02:22] <cprov> wgrant: ideally we would store the component at the time the source was dispatched, on Build table
[02:23] <wgrant> cprov: That's what I thought. But I guess it's rare enough that it's not worth it.
[02:23] <cprov> wgrant: I suspect it would be useful for spotting component mismatching.
[02:23] <wgrant> But it might be a bit stranger when package sets come into it.
[02:24] <cprov> wgrant: yeah, good point ... we need to study some real use-cases.
[03:04] <wgrant> Where would I add a test for c.l.w.tales.ObjectFormatterAPI.api_url? c.l.w.tests.test_tales doesn't seem right.
[03:22] <deryck> wgrant, ping
[03:31] <wgrant> deryck: Hi.
[03:32] <deryck> wgrant, hi.  So I see you're working on bug 415166.  Thanks!
[03:32] <mup> Bug #415166: Launchpad says I don't exist when I subscribe to a bug <Launchpad Bugs:In Progress by wgrant> <https://launchpad.net/bugs/415166>
[03:32] <deryck> wgrant, did you talk over your proposed fix with anyone?
[03:33] <wgrant> deryck: No, but it is less trivial than I thought, so I will.
[03:34] <deryck> wgrant, yeah, I thought it there might be more than that at first appears.
[03:34] <deryck> wgrant, what were you thinking?
[03:34] <wgrant> deryck: the obvious thing to do was pass rootsite='api' in ObjectFormatterAPI.api_url.
[03:34] <wgrant> But that gives the API site, not the API bit of the main site.
[03:35] <deryck> wgrant, right.  You get an https://api.launchpad.net... absolute URL, right?
[03:35] <wgrant> deryck: Right.
[03:36] <wgrant> I'm currently poking around to work out how to get an https://launchpad.net/api/beta/...
[03:36] <deryck> wgrant, but all the JS code assumes "me" is a relative URL, right? i.e. "/~me"
[03:36] <wgrant> That seems like it will be very difficult, though...
[03:36] <wgrant> deryck: Hmmmm. I suppose so.
[03:38] <deryck> wgrant, there are a lot of places in the js that make that assumption.  That LP.client.links['me'] is a relative URL, that the links in HTML scraped by JS are relative, etc.
[03:38] <deryck> wgrant, so I don't think there's a single spot to fix this and have it work.
[03:39] <wgrant> deryck: But ObjectFormatterAPI.api_url did work before. It just got broken by the canonical_url default chnage.
[03:40] <wgrant> Actually, that change should have been on edge before yesterday. So maybe it isn't that.
[03:41] <deryck> wgrant, right.  Let me say it another way.  You can fix "me" to be right and I suspect subscribing may still be broken in other ways.  The current bug is a symptom, not the problem.
[03:41] <beuno> wgrant, I got to give it to you, we open up Launchpad, and you've started fixing bugs
[03:42] <wgrant> beuno: You didn't think I would?
[03:42]  * deryck is quite happy wgrant is fixing bugs!
[03:42] <wgrant> Although I filed a lot this morning, too :(
[03:42] <deryck> good bug reports are never a problem, no matter the number.
[03:43] <wgrant> deryck: Assuming that api_url gets fixed, subscribing should work. What is broken about it, besides being fragile?
[03:43] <beuno> wg	most people don't  ;)
[03:43] <beuno> wgrant,  (tab fail)
[03:43] <wgrant> beuno: True.
[03:43] <wgrant> I imagine that will change over time.
[03:45] <deryck> wgrant, first, if "me" isn't relative the Subscriber js object won't initialize correctly, and second, unsubscribing won't work because the links in HTML won't be relative either.
[03:46] <deryck> wgrant, allow the second point may just be DOM update fail.  the unsubscribe API call may not depend on the HTML href.  Can't recall right now.
[03:46]  * deryck is up late
[03:47] <wgrant> deryck: You are probably right. This is indeed looking more difficult.
[03:47] <wgrant> I forgot about team unsubscription.
[03:48] <deryck> it's a tangled web.  inline subscribing is actually very complex.
[03:49] <deryck> wgrant, I'm not trying to discourage you though.  Please keep at it! :)
[03:49] <wgrant> Should I leave it to you, then?
[03:49] <wgrant> OK.
[03:49] <deryck> wgrant, just didn't want you to be disappointed if you fixed "me" and the rest was still borked.
[03:49] <wgrant> Ah.
[03:50] <BjornT> wgrant, deryck: wouldn't fixing fmt:api_url to always return a relative url fix the problem?
[03:50] <deryck> wgrant, and naturally if you work out any of the rest, or see hints of whats going on in light of what you know now, you'll be better able to file bugs on the rest. :)
[03:51] <wgrant> BjornT: I think so.
[03:51] <wgrant> BjornT: I'm testing team unsubscription now.
[03:51] <deryck> BjornT, I'm not sure.
[03:52] <deryck> BjornT, I thought we relied on user links in the DOM being relative, and so the API call may succeed, but if fmt:link was used, and it isn't relative, it may look like a fail in the UI.
[03:53] <wgrant> deryck: Team unsubscription doesn't use the fmt:link URLs.
[03:53] <wgrant> I'm not sure how it gets the other ones, though...
[03:54] <deryck> wgrant, what do you mean by "other ones"?
[03:54] <wgrant> deryck: I can see it making webservice requests with a person of https://bugs.launchpad.dev/~team
[03:55] <wgrant> deryck: But fmt:link should now give https://launchpad.dev/~team
[03:56] <deryck> wgrant, I think everything other than "me" is inferred from DOM.  or the subscriber_ids object.
[03:57] <deryck> wgrant, BjornT -- ok, so maybe I've just added confusion. sorry. :)  And now I must sleep if I'm to be worth anything the coming morning. :)
[03:57]  * wgrant digs into the JS.
[03:57] <wgrant> Night deryck.
[03:57] <wgrant> Fixing the me-link was as easy as I initially suspected after all.
[03:57] <deryck> good deal then
[03:57] <wgrant> (just needed rootsite=None, not rootsite='api')
[03:57] <deryck> ok, night
[03:59] <BjornT> wgrant: can i see the patch? i think there might be another solution
[04:00] <wgrant> BjornT: bzr diff is being a little slow, but I just replaced c.l.w.tales.ObjectFormatterAPI.api_url's self.url() call with self.url(rootsite=None)
[04:01] <wgrant> As various subclassess now specify rootsite='mainsite' as the default.
[04:01] <wgrant> This reverts to the previous behaviour.
[04:02] <BjornT> wgrant: ok, that's a sane solutoin. but i have a question for you. why not change api_url() to always return a relative path?
[04:03] <wgrant> BjornT: That's what it does.
[04:03] <wgrant> Although maybe that's just by accident -- I haven't dug all the way down the call stack.
[04:04] <BjornT> wgrant: not really. canonical_url() can't always return a relative url. note the parameter name: 'path_only_if_possible'
[04:05] <BjornT> wgrant: note that i don't know the answer to this question, and i don't expect you to either :) but it's worth thinking about.
[04:06] <BjornT> wgrant: in short, i think your patch is good, since it reverts to the old behaviour. i would go with your patch, and raise the issue i mentioned on the list.
[04:08] <BjornT> wgrant: btw, did you manage to write a test for this?
[04:10] <wgrant> BjornT: Sorry, the switch got angry and decided my packets were unworthy of retransmission...
[04:10] <wgrant> I haven't written a test, no.
[04:11] <wgrant> I'm about to find the best place to put it.
[04:11] <wgrant> Is there some repository of class-specific TALES tests somewhere?
[04:12] <wgrant> Ahh.
[04:12] <wgrant> c/l/doc/tales.txt
[04:12] <wgrant> I didn't expect there to be anything there, as the others are in c/l/w/tests/test_tales.py
[04:14] <BjornT> wgrant: unfortunetaly, i think that tales.txt is the right place for now.  it seems like api_url() is untested :(
[04:14] <wgrant> BjornT: It is.
[04:14] <wgrant> Not for much longer, hopefully.
[04:16] <wgrant> BjornT: Should I just add api_url tests for the three problematic classes, next to the tests that show fmt:link always goes to the mainsite?
[04:16] <wgrant> Or should I add a new section?
[04:19] <BjornT> wgrant: i think there should at least be a section for fmt:api_url
[04:24] <BjornT> wgrant: do you know how to go about making the test fail without your fix?
[04:25] <wgrant> BjornT: Um, what? You mean running the test?
[04:27] <BjornT> wgrant: nope. i meant writing the test, so that the pre-conditions are the same as in the bug report
[04:28] <thumper> BjornT: what time is it for you right now?
[04:28] <wgrant> Oh, right.
[04:28] <wgrant> thumper: I was wondering that...
[04:29] <wgrant> Isn't it like 06:30 over there?
[04:29] <BjornT> thumper: 6.30 am. woke up a bit earlier than usual today
[04:30] <wgrant> BjornT: I think I can fairly safely just check that api_url returns something relative, although I suppose that isn't testing exactly what we want.
[04:30] <thumper> wgrant: what you probably want to test is that the fmt:api_url always returns api.launchpad.net as the base
[04:31] <wgrant> thumper: No, that's exactly what we don't want.
[04:31] <thumper> so perhaps something like:
[04:31] <thumper> no?
[04:31] <thumper> what is the problem then?
[04:31] <BjornT> wgrant: i think such a check is ok. i do suspect that you need to do some setup to make api_url return a relative url
[04:31] <thumper> I must have misunderstood
[04:31] <wgrant> thumper: api_url is actually a path-only absolute URL.
[04:31] <wgrant> thumper: Nothing to do with the API, except that it's used by some flaky JS.
[04:31] <thumper> wgrant: and what is it doing right now?
[04:32] <wgrant> thumper: Returning an absolute URL to the main site, since fmt:url for person/team/pillar was changed to do that by default.
[04:32] <thumper> wgrant: why would it be wrong to check that the urls are always api.launchpad.net?
[04:33] <wgrant> thumper: Because they should never have a domain, and api.launchpad.net is particularly we don't want -- api.launchpad.net isn't usable from the webapp.
[04:33] <BjornT> wgrant, thumper: to be more exact, it's returning the url to the mainsite, unless calling it from the mainsite
[04:34] <wgrant> BjornT: Indeed.
[04:34] <thumper> BjornT: ok
[04:34] <thumper> wgrant: I'd make sure then that you test with the main pillars
[04:35] <thumper> wgrant: created by the factory, and test the explicit url with test_tales
[04:35] <thumper> wgrant: person, product, project, distribution
[04:36] <wgrant> thumper: Thanks.
[04:36] <wgrant> But first... lunch.
[05:17] <wgrant> Some of these factory tests don't seem to be much better than the sample data ones.
[05:17] <wgrant> I'd even say they're worse.
[05:17] <wgrant> Some depend on the order in which objects were created.
[05:17] <wgrant> So I throw in an innocent makeProduct and makePerson, and some of the subsequent tests start complaining that the numbers in the names are different.
[05:19] <thumper> wgrant: haha
[05:19] <thumper> wgrant: and here comes the magic of the factory
[05:19] <thumper> wgrant: factory.makePerson(name="eric")
[05:20] <thumper> wgrant: always provide what you want to test to the factory
[05:20] <wgrant> thumper: Right. But I'm going to have to fix other bits of the test.
[05:20] <wgrant> So it's a bug that the other tests test the name, but don't provide it?
[05:20] <thumper> wgrant: so if you are checking the url, make sure you don't have unspecified parts
[05:20] <thumper> wgrant: yes, that is very wrong
[05:21] <wgrant> But now I have to come up with more names ;'(
[05:21] <thumper> wgrant: ask and I will provide
[05:21] <thumper> wgrant: foo, bar, baz, fubar, widget, frobrisher
[05:21] <thumper> those are what I use
[05:21] <thumper> except for the last one
[05:21] <thumper> I just made that up
[05:21] <wgrant> Haha.
[05:22] <thumper> I use eric a lot for my random person
[05:22] <thumper> because there is no eric in the sample data, and I like Eric the Viking
[05:22] <wgrant> I've seen a few of him.
[05:22] <thumper> probably me
[05:22] <ajmitch> eric, john, graham, michael, terry
[05:22] <ajmitch> I'm sure you could think of a few more
[05:22] <thumper> wgrant: for multiple people, I also use abe, bob, charles, dave
[05:22] <thumper> xray, yankee, zulu for teams
[05:40] <spm> thumper: not "Eric the 'alf a Viking"?
[05:40] <thumper> spm: :)
[05:43] <rockstar> I use random naming schemes, depending on what's on my mind at the time.
[05:49] <thumper> rockstar: there is a 3.0 branch for some code-import pages if you are up for it
[05:51] <rockstar> thumper, I'll look at it in the morning.  Trying not to break my stride right now.
[05:52] <rockstar> Also, my media server's PSU just died, so I don't even get music anymore...  :/
[06:08] <wgrant> How does the JS build system work?
[06:08] <thumper> what do you mean?
[06:09] <wgrant> Do I make changes in lib/canonical/launchpad/javascript, and 'make run' will propogate those changes to lib/canonical/launchpad/icing/build?
[06:11] <wgrant> Oh.
[06:11] <wgrant> They're symlinks.
[06:11] <wgrant> That's easy, then.
[06:13] <sinzui> wgrant: I am tired but it think the answer to your question is that we have a script in utilities that scans the template we list the scripts in. The utility builds he compressed js.
[06:13] <wgrant> sinzui: But that's not relevant for development purposes?
[06:14] <sinzui> No, but it is relevant to YUI.Test. I recall have to run make build a few times.
[06:14] <wgrant> Ah.
[06:14] <wgrant> Thanks.
[06:16] <sinzui> I think the issues related to the html page that acts as a harness. It wants the built libs  plus the lib under test.
[06:18] <thumper> sinzui: hi, got a minute
[06:18] <thumper> for a question?
[06:18] <thumper> sinzui: what's the status of the new breadcrumbs?
[06:18] <thumper> sinzui: I sent out an email earlier
[06:19] <sinzui> I may not have a comprehensible answer
[06:19] <wgrant> To fix unsubscribing of teams, LP.client.normalize_uri needs to be convinced to prepend the root when operating on an absolute URL, which it currently explicitly doesn't do. Does anybody know why, before I go hunting?
[06:20] <sinzui> thumper salgado proposed a generic mechanism that will DTR thing on most cases to flacoate.  I believe there are exceptions and there will be a way to change the bread crumb
[06:20] <thumper> sinzui: yeah, I figured we'd need to annotate the breadcrumbs for branches
[06:21] <thumper> sinzui: which was the main point of my email, "what do we show"
[06:21] <thumper> sinzui: here's another idea
[06:21] <sinzui> thumper I wont know more until salgado wakes and I attain some form of caffeine induces consciousness.
[06:21] <thumper> sinzui: rename code -> branches for the "tab", and add a "code" tab for projects that goes to loggerhead
[06:21] <sinzui> +1
[06:21] <thumper> I'll copy that into an email for beuno
[06:22] <sinzui> I recall beuno_ wanted to do that, I wonder if that was shelved to 4.0 as being too invasive for 8 weeks of development
[06:24] <thumper> sinzui: lets see
[06:40] <wgrant> BjornT: Is it a sufficiently civilised time to request a review from you?
[06:41] <wgrant> I figure I'll get this fairly clean branch out of the way, rather than landing one polluted with JS changes as well.
[06:44] <rockstar> Ugh.  Why do we even have a test like notfound-traversals ?
[06:44] <sinzui> rockstar: I deleted a few today
[06:44] <rockstar> sinzui, it just fails with something that looks entirely unrelated.
[06:45] <rockstar> It's impossible to debug, it's a dumping ground for tests.
[06:45] <sinzui> rockstar: why do we test nofound + do pagetest 404 + view check_permissions? I think some drugs were involved
[06:46]  * sinzui only writes view check_permissions tests and deletes all others.
[06:46] <rockstar> If drugs are a requirement, I suggest that they be administered as part of rf-setup.
[06:46] <sinzui> rockstar: I think notfound was originally for URL that we wanted to retire. It is now an opportunity to not write a good test
[06:47] <rockstar> sinzui, yes, I would agree.  I'm willing to bet most of the code stuff in notfound-traversals is tested elsewhere in a better manner.
[06:51] <stub> notfound-traversals was a reaction to poor test coverage. A quick way to ensure the pages at least rendered, at a minimum.
[06:52] <stub> (or generated the correct error code in the first round, hence the name)
[06:52] <stub> I agree it should wither and die
[06:55] <rockstar> It'll probably shave eleventy billion minutes off the total time to run the test suite as well.
[06:59] <rockstar> Dangit.  Looks like I got a little overzealous while deleting templates.  One test failure left though.
[08:26] <adeuring> good morning
[08:26] <noodles775> hi adeuring :)
[08:27] <adeuring> hi noodles775!
[08:44] <lantash> danilos: Do you think it's time to make a merge proposal for https://code.edge.launchpad.net/~lantash/launchpad/bug-392154 ? I guess I'm supposed to write a merge proposal as suggested at https://dev.launchpad.net/DetailedCoverLetterTemplate and send a contributor agreement to you or kiko. What about running the whole test suite?
[08:45] <danilos> lantash: hi, let me take a glance at it
[08:46] <danilos> lantash: about the full test suite, it's generally preferred to do it ('make check'), but if it's problematic for you, running "bin/test -vvt lp.translations" (takes <15 minutes on my machine) should be enough
[08:47] <lantash> danilos: Thanks. I'll do that. Don't hesitate to tell me if you dislike anything about the newly introduced code or if there's anything missing.
[08:47] <danilos> lantash: looking at the revision log, I'd say you are mostly ready to submit it for review
[08:48] <danilos> lantash: don't worry, I am not shy about it, though it's very much appreciated you spent your time to help us improve Launchpad :)
[08:55] <henninge> wgrant: Hi. Anybody looking at your MP already?
[08:56] <wgrant> henninge: No. I discussed the patch with BjornT and deryck earlier, but if it seems sane to you then go ahead.
[08:56] <BjornT> henninge: i'm looking at it now
[08:57] <wgrant> Thanks BjornT.
[08:57] <henninge> BjornT: I already have, was about to review
[08:57] <henninge> BjornT: so you can save your time if you want ... ;-)
[08:57] <BjornT> henninge: were you about to start reviewing, or write up the review?
[08:57] <henninge> the latter
[08:58] <henninge> BjornT: ^
[08:58] <BjornT> henninge: ok, go ahead then
[09:00] <lantash> danilos: For some reason, my bin/ directory is gone. Looks like "make clean" removed it, which seems to have been invoked by "make check" (which failed by the way: "Error: Couldn't find a distribution for 'zc.buildout==1.4.0dev-gary-r102684'."). Can you tell me how to regenerate it?
[09:00] <danilos> lantash: once you merged with trunk, some dependencies (listed in versions.cfg) have changed; it should be enough for you to cd into download-cache and do a 'bzr up' there
[09:00] <wgrant> And then 'make' again.
[09:01] <danilos> lantash: and do 'make' again, as wgrant said (if it's not clear he was continuing on what I said :)
[09:04] <lantash> danilos,wgrant: It works fine now. Thanks! I'd run "make lint" too, but unfortunately, it fails on my 9.04 machine: "pkg_resources.DistributionNotFound: pylint==0.18.0"
[09:04] <wgrant> lantash: Odd. download-cache is up to date?
[09:05] <wgrant> And the branch is up to date with devel?
[09:07] <lantash> wgrant: If you mean running "bzr up" in download-cache and "bzr merge lp:launchpad/devel", then yes. I ran both commands just seconds ago. Just FYI, this isn't a new issue, I've never been able to successfully run "make lint" since I branched lp.
[09:08] <wgrant> lantash: Odd. It has always worked fine for me on Jaunty and Karmic.
[09:08] <wgrant> lantash: Do you have the pylint package installed?
[09:09] <danilos> wgrant, lantash: I don't see pylint in versions.cfg, so I'd expect that you'd need to install it yourself
[09:09] <lantash> wgrant: yeah, I'll check there's a version I installed by hand that conflicts with the one in the repositories.
[09:09] <danilos> of course, launchpad-developer-dependencies should do it for you, but there might be a bug
[09:09] <wgrant> maxb: Do you want to find a sponsor to get the necessary stuff from ~maxb/launchpad into ~launchpad/ppa to get things working on Karmic, or shall I?
[09:13] <mrevell> Hello my friends :)
[09:14] <hijacker_> hi mrevell
[09:14] <mrevell> hey there hijacker_ :)
[09:14]  * mrevell cuts down on the smilies
[09:15] <lantash> wgrant: did some investigation. ;-)
[09:15] <lantash> pylint 0.18 (which is required by lp) is in /usr/lib/python.2.6/dist-packages
[09:15] <lantash> pylint 0.15.2 can be found in /usr/lib/python.2.[45]/site-packages as well as pyshared (0.15.2 is in the Jaunty repos).
[09:17] <henninge> I am trying to submit a remote branch (wgrant's) to ec2test and pqm but ec2test complains like this:
[09:17] <henninge> To send email, a remotely accessible smtp_server (and smtp_username and smtp_password, if necessary) must be configured in bzr.  See the SMTP server information here: https://wiki.canonical.com/EmailSetup .
[09:17] <henninge> I know I have done this before so I wonder if something changed about this.
[09:18] <henninge> for the record: yes, the smtp server is configured ...
[09:19] <wgrant> henninge: Other people have repushed it, I think.
[09:20] <wgrant> But I'm no expert on sponsoring...
[09:22] <danilos> henninge: smtp server is probably configured for your LP repo, and not for remote others' repos; you can try moving smtp settings to your global bzr config
[09:22] <henninge> Ok, now it is working. I moved the smtp configuration from location.conf to bazaar.conf
[09:22] <danilos> henninge: that's it :)
[09:22] <henninge> danilos: ;-)
[09:23] <henninge> wgrant: ok, branch is in ec2test and will find it's way into the tree. Thanks again.
[09:23] <wgrant> henninge: Thanks!
[09:24] <danilos> lantash: note that LP uses python 2.4, so it'll probably try to use pylint 0.15.2, and that should be fine; it's probably 0.18 installation that causing the problems
[09:33] <maxb> wgrant: Hi, I was just thinking about that. The proper way would be to cherrypick my changes into individual small branches and submit those one by one, right?
[09:34] <maxb> Or, is submitting a branch with a one-line change considered a bit of a waste of time, and should I try to batch unrelated small changes?
[09:34] <wgrant> maxb: I mean the PPA packages.
[09:34] <maxb> Oh, right
[09:34] <wgrant> Just for 2.4 now.
[09:34] <wgrant> Since that works, and is better than nothing.
[09:34] <maxb> Well, works for you :-)
[09:34] <wgrant> Well, yes. Rather odd.
[09:35] <maxb> I guess I should try to talk to flacoste about that, based on the authorship of most of the packages in ~launchpad/ppa
[09:36] <wgrant> Probably.
[09:37] <lantash> danilos: Removing /usr/local/pylint as well as the 0.18 installation solved the problem. Thanks! Fortunately, the changed files are lint clean.
[09:38] <danilos> lantash: cool, let me know once MP (merge proposal) is up, so we can move to #launchpad-reviews to discuss it :)
[09:39] <maxb> I'm really annoyed with myself, I carefully started using launchpad~maxb in .deb versions in my ppa with the intent that launchpad versions would be higher when official. But then I did some uploads whilst too sleepy, and made some of them maxb~launchpad instead
[09:42] <danilos> bigjools: is this something you can help maxb with? ^
[09:42] <bigjools> not much I can do about that
[09:43] <maxb> No, the version numbering is entirely my screwup
[09:43] <bigjools> you could start a new PPA
[09:43] <bigjools> thumper!  working late?
[09:43] <thumper> bigjools: hey
[09:43] <thumper> bigjools: yeah, just a bit
[09:44] <maxb> Well, yeah, but the numbers are in the wild now, the PPA's advertised on dev.lp.net and I know people are using it
[09:44] <maxb> Anyway
[09:44] <maxb> I would like to help populate the ~launchpad ppa for karmic. What is the preferred form for submitted packages for sponsored upload / copy into there?
[09:44] <bigjools> good question
[09:45] <bigjools> check with flacoste when he's around later, but if necesarry we can add you as a named uploader
[09:45] <maxb> ok, if I don't catch flacoste later today, I'll ask launchpad-dev@
[09:47] <maxb> Separate topic - I'd like to start submitting code changes to support python2.5 - I thought I'd start small, with this one: http://bazaar.launchpad.net/~maxb/launchpad/python2.5/revision/8974
[09:47] <thumper> if I have a security wrapped product
[09:47] <thumper> and adapt it to something else
[09:47] <maxb> Are branches with a one-line change wanted, or is it better to try to collect a few one-liners into a single branch?
[09:47] <thumper> does the something else get security wrapped?
[09:47]  * thumper thinks not
[09:48] <thumper> maxb: one liners are fine
[09:48] <thumper> maxb: several one liners together are fine
[09:48] <thumper> maxb: several 50 line fixes should be broken up
[09:48] <thumper> maxb: keep changes easily reviewable
[09:48] <thumper> maxb: that's your axiom
[10:04] <bigjools> thumper: I think it does
[10:04] <bigjools> once wrapped, always wrapped
[10:04] <thumper> bigjools: adaptation doesn't go through a secured utility
[10:04] <bigjools> have you tried it?
[10:04] <thumper> by accident once
[10:04] <thumper> bigjools: but I have a test I'm writing
[10:05] <bigjools> I remember seeing some code somewhere that used an adapter so that we got proxied objects
[10:06] <thumper> bigjools: I'll let you know :)
[10:06] <bigjools> thumper: I'll honestly be very surprised if an adapter turns a proxied object into a non-proxied one
[10:07] <thumper> bigjools: well, the adapter is a class that takes the wrapped object as a parameter
[10:07] <wgrant> Don't trusted adapters get proxied (but get unproxied access to the wrapped object)?
[10:07] <thumper> bigjools: so it won't wrap the new object
[10:07] <wgrant> But IIRC non-trusted adapters don't get proxied, but rely on the proxy around the wrapped object.
[10:07] <thumper> wgrant: where are the docs about trusted adapters?
[10:07] <maxb> uhoh, ajax bug subscribe broken on edge for everyone or just me?
[10:08] <thumper> maxb: yep, broken
[10:08] <wgrant> maxb: I have a branch landing for that ATM.
[10:08] <wgrant> thumper: No idea. I just remember this from when I played with some Zope 3 code a couple of years back.
[10:08]  * wgrant Googles.
[10:09] <wgrant> thumper: http://docs.zope.org/zope3/ZCML/http_co__sl__sl_namespaces.zope.org_sl_zope/adapter/index.html, the trusted attribute seems relevant.
[10:09] <thumper> ta
[10:10] <thumper> wgrant: fantastic, thanks for that
[10:10]  * wgrant knows enough Zope 3 to survive.
[10:11]  * bigjools hoped to never have to know that much Zope3
[10:13]  * wgrant doesn't mind it.
[10:24] <mpt> Oh hooray, the global search field is going back down into the page footer
[10:24] <lifeless> ah, so people can't use it ?
[10:25] <mpt> eh?
[10:27] <lifeless> will people see it at all down at the bottom?
[10:28] <mpt> Well unless you're at the front page, the main reason to use the global search is because there's nothing on the current page relevant to where you actually want to be
[10:29] <mpt> My hypothesis (and it's only a hypothesis) is that you're more likely to come to that conclusion once you've scrolled through a page than when you're at the top
[10:30] <lifeless> mpt: my feeling is that search at the top is great, but it should always be contextual; if you want global search hit the home page
[10:30] <lifeless> or something like that
[10:31] <lifeless> it would be interesting to make sure we can track the result of the change being made
[10:31] <mpt> There are quite a lot of pages with context-sensitive searches, e.g. project Bugs pages, distribution pages
[10:33] <mpt> If all pages had a single search field it would be hard to tell when someone was wanting context-sensitive results (e.g. show me only bug reports about only this project) and when they were wanting site-wide search results
[11:02] <deryck> Morning.
[11:05] <deryck> wgrant, thanks for your work on tracking down (and fixing!) those inline subscribing bugs.
[11:05] <lifeless> mpt: thats true, which is why I suggest being always context sensitive and letting users request site wide
[11:06] <wgrant> deryck: The second one wasn't at all as hard as I suspected, fortunately.
[11:06] <deryck> wgrant, yeah, I think once you understand the general subscribing process in js, all of these should be fairly easy to fix.
[11:06]  * deryck needs to look closer at each bug though
[11:07] <wgrant> deryck: It took a while to work out how it all worked.
[11:07] <wgrant> There's a bit of JS there...
[11:07] <deryck> indeed there is.
[11:16] <mrevell> jtv: http://blog.launchpad.net/translations/screencast-importing-translation-templates-from-a-bazaar-branch
[11:17] <jtv> mrevell: listening to your voice now...
[11:17] <mrevell> jtv: That's nice to know :)
[11:17] <jtv> mrevell: "you might notice that this is a copy of Barry Warsaw's I Have a Colon Full of Cookie project"..?
[11:17] <jtv> mrevell: do you expect many people to pick up on that?  :)
[11:18] <mrevell> jtv: Only in that there is the rather odd phrase "I have a colon full of cookie" in the pot. I think this was the tenth take after several Audacity crashes :)
[11:19] <jtv> mrevell: and how many retakes from starting to laugh when you said the phrase?
[11:19] <mrevell> jtv: Heh, I was closer to tears after all the crashes
[11:19] <jtv> "oh good"
[11:20] <mrevell> jtv: there's a factual error in that I say imports happen once a day but I'll fix that when I re-record it for the new UI
[11:22] <jtv> mrevell: you say "a few minutes instead of a day or two," though that's about the approval process rather than the import process.
[11:22] <mrevell> jtv: Yeah, which I clarify later on
[11:22] <jtv> mrevell: where "clarify" is defined as "distort with lies and misinformation?"  :-P
[11:23] <mrevell> jtv: If the voiceover is actually misleading, I'll re-record. Do you want to give me a list of "bugs"?
[11:24] <jtv> mrevell: I just hit the point where you say "daily."  I'll be sure to note anything else, but no other mistakes have caught my ear so far.
[11:24] <jtv> mrevell: these imports get triggered as soon as you push your changes.
[11:25] <mrevell> jtv: I'll re-record.
[11:25] <mrevell> jtv: I think it's an important fact to get right :)
[11:26] <jtv> mrevell: well it's not actually harmful since everything else including your demo very clearly says "a few minutes."  So one could interpret the "daily" as "continually."
[11:27] <dpm> mrevell: I've just watched the screencast, and I found it excellent! Just a comment/suggestion: in the last few seconds, when you are typing the translation in the textbox, it might be worth clicking on the radio button or on the arrow button of the original string to show people that they can be easily copied to the translation textbox with a mouse click.
[11:27] <mrevell> jtv: The gods of audio recording seem to be smiling on me today, so it won't be too much effort to re-record. I like talking to myself anyway
[11:28] <jtv> mrevell: did danilo ask you about these screencasts btw?  Joey wanted something like this as well.
[11:28] <wgrant> Somebody want to help in #launchpad before things get too off course?
[11:29] <wgrant> mrevell: Note that nat/canonical/..
[11:30] <mrevell> dpm: Thanks for that suggestion! I have to confess I didn't even consider that. I'll mention that in the voiceover as that's easy to re-record and I think that's all we need for an extra value tip like that.
[11:31] <mrevell> wgrant: Yeah, I'm still used to be able to recognise everyone's name :)
[11:32] <mrevell> jtv: yeah, danilo pung me about this yesterday
[12:34] <mrevell> jtv: I've fixed the import video. Now I'm going to record the export video.
[12:36] <jtv> mrevell: looking forward to that, for obvious reasons.  :)  I really liked getting the information in this format.
[12:36] <mrevell> jtv: Is there any way to cheat/force the export? I guess I can wait until tomorrow to record the part where I go and look for the export in my branch, but joey might find this useful, as you said.
[12:38] <jtv> mrevell: you're not the first to ask...  May be worth a new feature, though obviously we're not going to work on it very soon.
[12:38] <jtv> otoh for now the script performs so well that it looks like we might run it much more frequently.
[12:39] <mrevell> jtv: Ah ok. So, there's no special "I'll buy you a pint jtv" button :)
[12:39] <mrevell> jtv: When does the export occur?
[12:40] <jtv> mrevell: buying me a pint is fine, but getting an extra cron job approved & executed might not get it done much faster than just sitting and waiting.
[12:40]  * jtv looks up the times
[12:40] <mrevell> :)
[12:41] <jtv> mrevell: between 03:00 and 04:00 UTC
[12:41] <jtv> or BST, if that's what the logs are in.
[12:41] <mrevell> jtv: Cool, thanks
[13:26] <wgrant> gmb: If I want to fix bug #415165, do I have to change all sites that set it to use the new method? Or can I just set the field readonly and export a mutator, to only protect the webservice side?
[13:37]  * gmb looks at the bug
[13:37] <gmb> Ah, right.
[13:38] <gmb> wgrant: The problem specifically effects anything that uses the webservice, so exporting the mutator should be sufficient. You can then file a follow-up bug to make everything else use the new method, but that's less urgent.
[13:43] <wgrant> gmb: Thanks, I was just wondering if I would be committing Evil by not changing the rest.
[13:44] <gmb> wgrant: Nah - what's there already has worked up until this point.
[13:44] <gmb> (And as I said, what's there already for non-webservice stuff isn't all that broken)
[13:49] <henninge> jtv, danilo-food: wanne take a look at my TranslatableMessage draft?
[13:49] <henninge> jtv: https://pastebin.canonical.com/21250/
[13:49] <jtv> henninge: looking...
[13:51] <henninge> jtv: actually I am thinking of even more high-level methods.
[13:51] <henninge> jtv: like "getAllTranslations"
[13:52] <jtv> henninge: a small note... names like is_empty and is_imported don't really mesh with the choice of Translat*able*Message.
[13:52] <henninge> ;-)
[13:52] <barry> sinzui said: No.one menu must be bound to the oject, the other to the view, so you must pass each so that when we use nearest(INavigationMenu) we get the right menu
[13:52] <henninge> jtv: well they are really "(Re)TranslatableMessage)
[13:52] <jtv> henninge: I think you've made a good start with these low-level things; this should not become a 2-year project after all.  :-)
[13:53] <henninge> jtv: meaning
[13:53] <henninge> ?
[13:54] <jtv> henninge: about the names, I mean that is_empty etc. should be something like current_translation_is_empty etc. to reflect that it's the translation, not the POTMsgSet, that is empty (or whatever).
[13:54] <henninge> jtv: ok, no problem
[13:55] <jtv> henninge: about the other thing, I mean don't worry too much about pulling in more functionality; you'll risk making more changes than needed and complicating things.
[13:55] <barry> sinzui: nearest() seems like a rather magical (and error prone) way to find the menu.  why is it not explicit?
[13:56] <sinzui> barry: You are using the zope, This is how all menus work
[13:56] <henninge> jtv: You mean, the rest can be done in the view?
[13:57] <jtv> henninge: I'm not making any predictions, just saying be conservative in what you move in here because it's going to pile up anyway.  :)
[13:57] <barry> sinzui: my point is, i guess, that we should do better
[13:57] <sinzui> barry: if it was very explicit, people would be making menus everywhere and the pages would be a mess. NavigateMenus were design to work with two scenario, items about the object and items about the objects content
[13:57] <henninge> jtv: I see.
[13:58] <sinzui> barry: I loath to change the way something has worked for 18 months
[13:58] <sinzui> barry: remember that lots of pages are using them.
[13:59] <barry> sinzui: then we should be building a better mechanism that new pages would use.  but i'll drop this for now.
[14:01] <sinzui> I think the way I outlined it ensures there one link definition, that we allowed two menus per page. The only oddness is the marker interface
[14:01] <allenap> sinzui: Hi, I have a question when you have a moment. I'm converting a page from onecolumn to main_only, and collapsibles are now not working. I notice that the code that sorts them out is in the page-javascript macro, but I don't think I want to be using that (it seems to be to support main-template). Any ideas how I should approach this?
[14:02] <jtv> henninge: overall, what you have here looks to me like the kind of interface we'd want to have.
[14:02] <henninge> jtv: good to hear, thank you
[14:02] <sinzui> allenap: head-epilogue-slot is where I have placed javascript
[14:04] <bigjools> sinzui: I think we also need .side h2 {font-weight: bold;} I think I might have said that before.
[14:04] <sinzui> yes,
[14:05] <sinzui> bigjools: I leave beautification to beuno
[14:06] <allenap> sinzui: Okay. Previously several calls were made on every page (activate_collapsibles(), and a few others). Is the policy now to only call those that each page needs?
[14:07] <gary_poster> mthaddon: when you get a chance would like to investigate the problem landing sourcecode branches on pqm that intellectronica and I wrote about.
[14:08] <sinzui> allenap: I do not know.
[14:08] <allenap> sinzui: Do you reckon beuno is the person to talk to?
[14:09] <sinzui> allenap: I think the problem is that those scripts were never converted to YUI, so we do not know what to do with them
[14:09] <mthaddon> gary_poster: ok, will be about 30 mins or so
[14:09] <gary_poster> mthaddon: cool thanks
[14:09] <sinzui> allenap: if there a problem with the epilogue slot?
[14:11] <wgrant> Should all schema circular import patches live in c.l.i._schema_circular_imports? It took me ages to find one that doesn't live in there.
[14:11] <allenap> sinzui: Those calls used to happen in every page, to set up sortables, inline help, collapsibles, etc. None of those things will work unless every template adds a block to the head_epilogue.
[14:14] <allenap> sinzui: The one I'm interested in - Y.lp.activate_collapsibles() - has been converted to YUI, so maybe I should add it to base-template.pt to ensure it gets run on every page?
[14:15] <sinzui> allenap: then I think we want to add that to the new template. There is a macro that makes discretional page javascript. We can add them to that or we add a new part the template loads non YUI scripts
[14:16] <sinzui> allenap: I think we want to update base-layout-macros.pt define-macro="page-javascript" to do this
[14:17] <sinzui> If you look, you will see it does a setup, loads the main scripts, then does some post setup
[14:18] <allenap> sinzui: Yeah, that macro is used by main-template.pt, but not by base-layout.pt, and adding it to the head_epilogue slot means that the load-javascript macro ends up being included twice in the page.
[14:19] <sinzui> allenap: I see Y.lp.activate_collapsibles(); in the define-macro="page-javascript" macro. It should be there now
[14:20] <allenap> sinzui: Yes. I'll break out the <script> block containing Y.lp.activate_collapsibles() into a separate macro so that I can include it in base-layout.pt.
[14:20] <sinzui> allenap: no
[14:21] <bigjools> sinzui: did you look into a way of automatically putting the file size in the sidebar download links?
[14:23] <sinzui> allenap: look at line 72 of  lp/app/templates/base-layout.pt
[14:25] <sinzui> allenap: load-javascript is meant to just provide libraries and by special pages like the timeline. I do not think we should be loading it in base-layout. It should call page-javascript, which does the required pre and post setup of those libraries.
[14:26] <sinzui> allenap: So I think we need to change line 72
[14:26] <sinzui>      use-macro="context/@@+base-layout-macros/page-javascript" />
[14:26] <allenap> sinzui: Okay, that seems good.
[14:28] <sinzui> bigjools: I have not. Salgado looking to a way and used the tooltip because there was room in many of the uses for download files.
[14:29] <sinzui> bigjools: I think the answer is when there is a table, show the information. When you are making a fast action button, just show the file name
[14:29] <bigjools> sinzui: it would be nice to put it next to the release date IMO.  release date won't work for me on the DSP page anyway since it's the package upload date that counts
[14:29] <sinzui> Will it always fit?
[14:30] <bigjools> what is "it"?
[14:30] <sinzui> bigjools:I do not think we can. the release date should only appear one in a list of download buttons.
[14:31] <bigjools> ah interesting
[14:31] <sinzui> bigjools: "it" was the file size
[14:31] <gary_poster> leonardr: ping
[14:31] <leonardr> gary: yo
[14:32] <bigjools> it should fit, but won't work too well if we don't want to put the release date in every button
[14:32] <gary_poster> leonardr: ready for call?
[14:32] <leonardr> yeah
[14:32] <gary_poster> cool
[14:44] <allenap> sinzui: Switching load-javascript to page-javascript in base-layout.pt is working nicely. However, initInlineHelp() breaks (because there's no #help-close element) necessitating a change to stop it from throwing an exception. Is inline help entirely going away for 3.0?
[14:45] <sinzui> hmm
[14:49] <sinzui> allenap: I think that mean we need to add the missing help info. Is the issue more complex than that.
[14:50] <allenap> sinzui: No, I don't think so. There's a div#help-pane in main-template which I can just copy into base-layout.
[14:54] <sinzui> allenap: I intentionally made the lp/app/browser/tests/base-layout.txt test very verbose to ensure that we know exactly what each layout provides. You should update one or all the layout sections to verify that #help-close is present
[14:54] <allenap> sinzui: Okay, cool. Thanks for you help :)
[15:03] <beuno> EdwinGrubbs, hi
[15:04] <EdwinGrubbs> beuno: hello
[15:04] <beuno> EdwinGrubbs, would you like to have a call to figure out the UI you're working on?
[15:10] <sinzui> salgado: is Bug 415133 update?
[15:10] <mup> Bug #415133: Update code-of-conduct pages to UI 3.0 <Launchpad Registry:In Progress by salgado> <https://launchpad.net/bugs/415133>
[15:19] <henninge> abentley: Hi!
[15:19] <abentley> henninge: Hi!
[15:19] <henninge> abentley: Are you knowledgable about the job system?
[15:19] <abentley> henninge: Yes.
[15:19] <henninge> abentley: I see a lot of stale "running" jobs.
[15:19] <henninge> abentley: that is jobs that remain in state "1" forever.
[15:20] <abentley> henninge: What kind of jobs?
[15:20] <henninge> abentley: rosettabranchjobs
[15:21] <henninge> abentley: but I just saw that there are other (old) jobs still in that state, too.
[15:21] <abentley> So, when a job terminates, the JobRunner should set its status appropriately.
[15:21] <henninge> abentley: what happens if it crashes?
[15:21] <salgado> sinzui, there are a few pages left to convert
[15:21] <sinzui> okay
[15:21] <abentley> henninge: You mean outside of normal python exception handling?
[15:22] <henninge> abentley: possibly ;-)
[15:22] <henninge> abentley: these are all rosettabranchjobs not in state "2" as of last night.
[15:23] <henninge> https://pastebin.canonical.com/21251/
[15:25] <james_w> could I get a review of https://code.edge.launchpad.net/~james-w/wadllib/fix-simplejson-unicode/+merge/10180 please?
[15:25] <henninge> abentley: looking at lines 65 to 70 you see 4 jobs for window-picker-applet but nothing ever happens, meaning nothing gets uploaded.
[15:26] <intellectronica> james_w: you're best trying in #launchpad-review, where the on call reviewers hang out. but if you can't find a reviewer there i'll be happy to review your fix
[15:26] <flacoste> gary_poster, adeuring, intellectronica: my fix for submission to sourcecode branches is #4 in PQM right now
[15:26] <intellectronica> hallelujah
[15:26] <adeuring> flacoste: thanks!
[15:26] <james_w> intellectronica: but I'm the only person in that channel!
[15:27] <gary_poster> flacoste: thank you!  mthaddon did you see that?  no investigation needed, probably
[15:27] <james_w> ah, -reviews
[15:27] <mthaddon> gary_poster: sounds good to me :)
[15:27] <gary_poster> :-)
[15:27] <abentley> henninge: Well, if it raises an exception, the job will be marked "failed" and an oops will be reported.
[15:27] <abentley> henninge: At least, that's what's meant to happen.
[15:27] <abentley> henninge: If the job causes a segfault, the job will be left in 1 state forever.
[15:28] <bigjools> sinzui: did you involvement portlet thing land?
[15:28] <bigjools> your*
[15:28] <henninge> abentley: I guess that is the problem, then.
[15:29] <henninge> abentley: I guess that is the problem, then.
[15:29] <sinzui> bigjools: yes!
[15:29] <bigjools> sinzui: woooo!  can I just copy the runes from the product-index template?
[15:30] <abentley> henninge: There have been some changes in that area recently, so it might work now.
[15:30] <henninge> abentley: the last failures were yesterday.
[15:30] <abentley> henninge: Drat.
[15:30] <henninge> that i know of.
[15:31] <abentley> henninge: Have you looked at the job system oopses?
[15:31] <sinzui> bigjools: <div tal:replace="structure context/@@+get-involved" />
[15:32] <henninge> abentley: yes, there are none, or at least not matching the job failures
[15:32] <bigjools> sinzui: in fact I just tried it and it looks a bit wonky, for the DSP page it adds "Register a Blueprint" which doesn't make sense does it?
[15:32] <bigjools> and it links to +addbranch
[15:32] <henninge> abentley: that is oopses for rosettauploadjobs
[15:32] <sinzui> bigjools: \o/ you found a bug
[15:32] <bigjools> sinzui: "Help translate" also just goes to the translations root site
[15:33] <sinzui> bigjools: yes it does
[15:33] <abentley> henninge: The only thing I can think of is trying to reproduce the failure locally.
[15:33] <abentley> henninge: Or maybe on staging?
[15:33] <henninge> abentley: are branches copied to staging, too?
[15:33] <henninge> abentley: it does not happen to all branches, just certain.
[15:33] <abentley> henninge: Only a few are copied, but you can push them.
[15:34] <thekorn> intellectronica, hi, right now, I try to fix bug 414992, and I have a question: there is a test in lib/canonical/launchpad/doc/displaying-paragraphs-of-text.txt line 224/225 which indicates that this is expected behaviour,
[15:34] <mup> Bug #414992: 'bug $ID' markup in descriptions and comments does not respect new lines <Launchpad Bugs:New> <https://launchpad.net/bugs/414992>
[15:34] <bigjools> sinzui: I guess the text is wrong, +addbranch is sane for packages now
[15:34] <thekorn> intellectronica, so: is the testcases wrong, or isn't it a bug at all?
[15:34] <sinzui> bigjools: lp/registry/browser/pillar has an exception for IProject, add one for IDistributionSourcePackage
[15:34] <bigjools> sinzui: okay
[15:35] <EdwinGrubbs> beuno: sorry, I didn't see your last comment. sinzui was saying that the problem with the duplicate headings is due to the base templates, so a fix doesn't really belong in my branch. We can have a call if you like, but I think sinzui should be involved, unless there is a different issue.
[15:36] <intellectronica> thekorn: sounds to me like the behaviour is wrong. i don't understand why you'll want to do that other than in one case - some text can come from email, where it may have been broken down
[15:36] <intellectronica> thekorn: let me have a look
[15:41] <beuno> EdwinGrubbs, if you're clear on what you need to do, then it's ok. If you're not 100% sure on design, let me know, and we'll have a call to figure it out
[15:42] <thekorn> intellectronica, thanks for looking at it
[15:42] <bigjools> sinzui: doesn't seem to work for DSP, the pillar is IDistribution in that code
[15:43] <bigjools> sinzui: maybe examine the context instead?
[15:43] <jtv> mthaddon: I have to go now, but I've written up my request for later: https://pastebin.canonical.com/21261/
[15:43] <jtv> mthaddon: with apologies for asking you to hold the baby, is that something you can work with while I go and slack off?
[15:45] <EdwinGrubbs> beuno: sinzui said that whatever changes that need to be done to the heading are up to you, so I couldn't even start working on that in a separate branch.
[15:45] <beuno> sinzui, do I owe you an answer then?
[15:46] <sinzui> bigjools: the __init__ needs to set the specs, code, and tranlations, to false if IDistributionPackage. just like IProject
[15:47] <bigjools> sinzui: it's ok, I have fixed it
[15:47] <sinzui> beuno: EdwinGrubbsI do not undersand the issue until I have seen it.
[15:47] <bigjools> sinzui: however, I am wondering why there's no Code link, even though the tab is enabled
[15:48] <sinzui> bigjools: Does Ubuntu have official_code?
[15:48]  * sinzui does not think so
[15:48] <bigjools> might be right, where the heck is it set ....
[15:48] <sinzui> bigjools: the involvement menu enforces the official status
[15:49] <mthaddon> jtv: sure - can you email that to losas and I'll have one of my new minions have a crack at it
[15:49] <sinzui> bigjools: <Change details>?
[15:49] <bigjools> sinzui: nope :/
[15:49]  * sinzui looks at model
[15:50] <bigjools> sinzui: why does "Help translate" go to the translations rootsite?
[15:50] <sinzui> Wow!
[15:50] <bigjools> when it doesn't on the existing page
[15:50] <bigjools> or is that a bug?
[15:50] <sinzui> bigjools: official_codehosting is a property allways set to false. There is a not about sourcepackage branches you shoudl read
[15:51] <bigjools> ha
[15:51] <intellectronica> thekorn: don't know, i think the reason i mentioned above is the only reason i can think of why we'd want to do that. if we wanted a really clever solution we could do the linkification only if the number on the next line is preceded by #, though i think it's worth changing even if we don't do that
[15:51] <intellectronica> i sort of feel like someone needs to be devil's advocate here
[15:51] <sinzui> bigjools: You might wan the view to falsify official_codehosting if distribution.full_functionality
[15:52] <sinzui> bigjools: That is were the link always goes as far as I understand.
[15:52] <bigjools> ok
[15:52] <bigjools> in the meantime, abentley, do you guys have plans to fix IDistribution.official_codehosting?
[15:53] <henninge> abentley: you have lots of "running" jobs, too... https://pastebin.canonical.com/21262/
[15:53] <intellectronica> BjornT: do you have an opinion on whether it makes sense to linkify 'bug\n123'? we currently do, and i can think of one reason why that would be good to do (text coming from email might be broken up for line length) but it's a bit confusing when entering lines starting with a number
[15:53] <henninge> abentley: this was the query run on staging: https://pastebin.canonical.com/21260/
[15:54] <abentley> bigjools: I lack context.
[15:54] <BjornT> intellectronica: i assume you mean that we don't do this currently?
[15:54] <bigjools> abentley: it always returns False, and there's a comment from you on 2008-01-22
[15:54] <intellectronica> BjornT: we currently do linkify across line boundaries. we even have a test demonstrating this
[15:54] <bigjools> abentley: doesn't seem right any more now we have source package branches?
[15:55] <BjornT> intellectronica: oh. so in what way is it confusing? can you give an example?
[15:55] <intellectronica> BjornT: https://launchpad.net/bugs/414992
[15:55] <mup> Bug #414992: 'bug $ID' markup in descriptions and comments does not respect new lines <Launchpad Bugs:New> <https://launchpad.net/bugs/414992>
[15:55] <abentley> bigjools: I don't think that's on our radar, but jml is most familiar with sourcepackage branch issues.
[15:56] <bigjools> abentley: ok, no rush anyway, just wondered.  Ta!
[15:56] <abentley> bigjools: Is it possible for a distribution's sourcepackage branches to be unofficial?
[15:56] <bigjools> abentley: I don't think so
[15:57] <abentley> bigjools: So perhaps we need to force it True.
[15:57] <bigjools> I'll wait for jml to comment when he's back
[16:05] <abentley> henninge: I'll investigate that, but I've no idea at the moment.
[16:05] <henninge> abentley: just like me ;-)
[16:11] <danilos> henninge: we should either turn all of those into properties, or turn them all into methods... I don't see a reason to be inconsistent like this... is_empty would be better if it was the opposite like is_translated, but that's ultimately equivalent to current not None and not current not is_empty
[16:12] <danilos> henninge: it might make sense to keep expensive operations as methods, and cheap ones as properties, but then everything might turn into methods :)
[16:14] <bigjools> sinzui: with the portlet changes: http://people.canonical.com/~ed/dsp_mockup_with_linkage2.png
[16:17] <sinzui> bigjools: What did you do with the help translate link? Should it change for an DSP?
[16:17] <bigjools> sinzui: yes, it should retain the pillar
[16:17] <bigjools> I've not fixed that
[16:17] <bigjools> sinzui: what do you think about the new layout though?
[16:18] <sinzui> I like it
[16:18] <sinzui> bigjools: we normally do not want a line (border, rule) between the <h1> and the content.
[16:18] <sinzui> bigjools: I am not sure what to do in this case
[16:19] <bigjools> sinzui: me neither
[16:19] <sinzui> bigjools: We could set the top two portlets to class="top-portlet"
[16:20] <sinzui> bigjools: Is there any narrative information we can place at the top of main?
[16:20]  * sinzui thinks not
[16:20] <bigjools> not relly
[16:20] <bigjools> the product info is the best narrative
[16:23] <bigjools> sinzui: so using top-portlet makes it sit right against the title now. noodles775 observed that on a review of something else earlier, it's a global problem
[16:23] <sinzui> yes, because top-portlet assumes that some real blocks are in it
[16:23] <noodles775> bigjools, sinzui: I haven't checked, but I've got a feeling it probably only affects top-portlet's where the first content is a table/form.
[16:24] <bigjools> sinzui: heh, on top of that, the <dt> have lost their styling
[16:24] <sinzui> :(
[16:25] <sinzui> bigjools: where does the explanation of what the package does come from when I use apt? is that available here?
[16:26] <gary_poster> salgado: please let me know what you think of https://pastebin.canonical.com/21264/ when you get a chance, and let me know what you think we ought to do next.
[16:27] <bigjools> sinzui: that's a different package you're seeing the description for - they're binary remember
[16:27] <bigjools> this is source
[16:29] <jtv> danilos, henninge, mthaddon: I'm off!
[16:29] <mthaddon> jtv: did you email losas@?
[16:29] <jtv> mthaddon: I did.  Didn't notify you because I figured you'd get the email anyway.  :)
[16:29] <mthaddon> cool, thxc
[16:29] <bigjools> sinzui: the class="summary" on the description looks really crap to me as well
[16:30] <rockstar> abentley, chat?
[16:30] <abentley> rockstar: sure.
[16:30] <henninge> danilos, jtv, mthaddon: so am I!
[16:30] <sinzui> bigjools: yes, since we are not using it as narrative we should not use the class
[16:31] <danilos> jtv, henninge: cool, enjoy it
[16:35] <salgado> gary_poster, I like that it seems like a lightweight solution for future changes, but doing that for all existing entries in versions.cfg will be a bit of a PITA, won't it?
[16:40] <thekorn> intellectronica, ok, thanks. so I guess best is to wait until someone notes a decission about this on the bugreport
[16:42] <intellectronica> thekorn: yes, i suggest let's put this question in the bug report and try to make a decision quickly. i'd say just do it, but the fact that someone went through the pain of making sure that it works the way it does makes me a bit cautious - maybe there's a really good reason we don't understand
[16:42] <bigjools> sinzui: instead of narrative, I can put something in that used to be on an old mockup, like "This package has 14 open questions and 139 untriaged bugs"
[16:43] <sinzui> oh
[16:44] <sinzui> bigjools: That is nice. Why aren't we showing them as portlets on the page? Is the information not interesting enough? Do you link to those bugs and questions?
[16:44] <gary_poster> salgado: We only have four ATM (Storm is 1.15).  It will be a bit of a PITA, yeah.  I think it's most important for feedvalidator, since right now we don't have any prospect of improving the situation (getting a real release).  The other three are hopefully on their way to being merged and officially released upstream, so I'd be +1 on letting them through as-is on a grandfather clause. :-)
[16:44] <gary_poster> So, to be clear, maybe just redo feedvalidator to comply with this.
[16:44] <bigjools> sinzui: I'm wary of putting too much on the page and slowing it down.  I would be happier to link to the relevant page.
[16:45] <sinzui> +1
[16:46] <bigjools> cool
[16:47] <salgado> gary_poster, oh, I thought we were doing the comments even for non-custom distributions.  I think that'd be good to kind of force people to update the comment in case they change it to a custom one, but it might be too much effort for not enough benefit
[16:48] <salgado> (your pastebin clearly says it's only for custom local distributions; I misread it)
[16:50] <gary_poster> salgado: cool.  if it is a non-custom distribution, then I think that's not Launchpad's responsbility to make those releases anyway (unless we are the upstream, like with lazr.*, but I think documenting that release process needs to be handled within those packages, not within launchpad).
[16:53] <gary_poster> salgado: so, are you +1 then?  Should I make any changes, or just put it on the wiki and invite comment?
[16:54] <salgado> gary_poster, big +1 from me. :)
[16:54] <gary_poster> salgado: :-) k cool thanks
[16:57] <danilos> kfogel: did we come up with a recommended PQM submit message to credit our contributors when submitting branches for them?
[16:57] <kfogel> danilos: no, because we're just going to parse the logs (the inner revisions) directly.  Which, coincidentally, is what I'm working on right now :-).
[16:58] <danilos> kfogel: ok, cool
[16:58] <kfogel> danilos: (and the result will feed to a wiki page automatically, keeping our contribution logs up-to-date)
[17:03] <sinzui> barry:  can you take 30 minutes to look at bug 403606. I haven't a clue what is up.
[17:03] <mup> Bug #403606: ExpatError errors should be handled to not generate the OOPSes <oops> <Launchpad Registry:Triaged by barry> <https://launchpad.net/bugs/403606>
[17:26] <kiko> sinzui, is it currently possible to subscribe a private team to code reviews? no, right?
[17:27] <sinzui> kiko: I think it can. We fixed a related bug in June
[17:27]  * sinzui tries
[17:30] <bigjools> sinzui: are the same links as the tabs available as global Links somewhere?
[17:30] <sinzui> bigjools: No :(
[17:30] <bigjools> bugger
[17:30] <sinzui> bigjools: I lied, but getting a link can be hard
[17:31] <bigjools> sinzui: so I shall have to duplicate them in my view then
[17:31]  * sinzui looks at old revision on involvement to see how it was done
[17:33] <sinzui> bigjools: I had to use the translations menu to get links. That is not good. I have been putting links in  mixins so that it is easy to share links between menus
[17:33]  * sinzui reads ancient code for hacks
[17:35] <sinzui> bigjools: view/menu:facet returns a list of links. you cannot access them by name :(
[17:37] <bigjools> sinzui: the help_translate link returns "/"
[17:38] <sinzui> bigjools: yeah, that is why I created the pillar menu which makes a rooted url
[17:38] <bigjools> sinzui: if I change it to "" it does what I expect
[17:38] <bigjools> well, sort of :)
[17:39] <bigjools> actually, no it doesn't. Crap.
[17:43] <kiko> sinzui, got an answer for me?
[17:43] <kiko> matsubara-afk, Ursinha: what about you, do you know if I can subscribe a private team to a public or private code branch?
[17:44] <Ursinha> kiko, nope, not sure, rockstar?
[17:44] <sinzui> kiko: private teams are supported
[17:44] <sinzui> kiko: I am creating a private membership team to verify it
[17:45] <rockstar> kiko, I don't know why you couldn't subscribe a private team, although it's existence might be leaked.
[17:46] <sinzui> rockstar: you could not in June because of validation contraint
[17:46] <sinzui> bac fixed it
[17:47] <rockstar> sinzui, Ugh.  Sometimes privacy is a real pain.
[17:47] <sinzui> kiko: rockstar: private and private-membership teams can subscribe to a public or private branch
[17:48]  * sinzui vows to conslidate and rename tests so that he can find them
[17:53] <kiko> thanks sinzui
[17:57] <kiko> sinzui, the new guided project registration is really nice, but we need a separate "import a project" workflow now, I realize
[17:57] <kiko> I used to think you could do that as part of the same workflow
[17:57] <kiko> but now I don't think you can
[17:57] <sinzui> kiko: yep
[17:58] <kiko-fud> I think "Register a new project" and "Import a project from somewhere else" are different things
[17:58] <kiko-fud> that the user sees really differently
[17:58] <kiko-fud> anyway, fud
[17:58] <rockstar> ALL:  I'm going to hunker down and hack.  If you need something, please text me, as I'll be ignoring IRC and email for the next few hours.
[18:05]  * gmb EoDs
[18:44] <salgado> sinzui, any suggestions for the next group of pages to convert? maybe poll-related ones?
[18:48] <sinzui> salgado: They
[18:48] <sinzui> salgado: I listed poll-edit, polll-newoption, polloption-edit as the ones to convert
[18:50] <salgado> sinzui, do you mean we're not converting the others or that these are the ones that should go first?
[18:51] <sinzui> salgado: we are converting all. I listed those pages in my notes to convert next.
[18:51] <salgado> sinzui, so you're doing them or can I take them?
[18:58] <sinzui> salgado: take them
[19:09] <bigjools> sinzui: can we put GET data on a Link() ?
[19:13] <bigjools> other than hacking the crap out pf it I mean
[19:19] <sinzui> bigjools: I do not understand?
[19:20] <bigjools> sinzui: never mind, I've hacked it, I don't see another way.  While you're there, check out these tweaks: http://people.canonical.com/~ed/dsp_mockup_with_linkage2.png
[19:20]  * bigjools has to go in 5 minutes
[19:23] <maxb> flacoste: Are you around today? I was hoping to discuss how to submit packages for inclusion in ~launchpad/ppa
[19:23] <flacoste> maxb: i am, on the phone, though
[19:23] <sinzui> bigjools: looks nice, beuno will want the links with the counts to have the colours of  the apps
[19:23] <bigjools> sinzui: do we have a style for that?
[19:24] <maxb> flacoste: ok, I'll be around for several hours, let me know if you have time for a chat
[19:24] <beuno> sinzui, you're becoming my evil, but better looking twin
[19:24] <bigjools> more eccentric twin you mean? :)
[19:24] <sinzui> bigjools: maybe, I did it on the milestone page
[19:25] <bigjools> sinzui: ok I'll look on there, ta
[19:25] <bigjools> beuno: any comments on that page now?
[19:26] <flacoste> maxb: ok, i just hung up, i have a couple of minutes before it rings again :-)
[19:26] <flacoste> maxb: these are packages for karmic?
[19:26] <maxb> Yes - basically the entire python2.4-using modules for karmic
[19:26] <beuno> bigjools, it looks 7000 times bettar than when you started. And, a few other things, that I'll take to -reviews now
[19:27] <bigjools> beuno: I need to finish coding the data-retrieval for the table and write tests, so in a couple of days I'll be pinging you for that
[19:28] <maxb> I have packages in https://edge.launchpad.net/~maxb/+archive/launchpad - some of which are just copy-with-binaries from ~launchpad/ppa jaunty - what's the best way for things to get into ~launchpad/ppa for karmic?
[19:33] <flacoste> maxb: i think we could copy the binaries over
[19:33] <flacoste> bigjools: do you have any better suggestion?
[19:33] <maxb> Sounds good if you're happy with that approach
[19:33] <bigjools> flacoste: +1
[19:33]  * bigjools has to go
[19:34] <flacoste> maxb: why did you drop the python2.4-foo in launchpad-dependencies?
[19:35] <maxb> That's because I'm simultaneously trying to make it work with both 2.4 and 2.5 - and not all of the packages provide pythonX.Y-foo vdeps anyway
[19:36] <maxb> Where possible I've done no-change rebuilds to re-add the python2.4 binaries - no source patching at all
[19:37] <flacoste> maxb: hmm, the problem is that if there is no python2.4 dep, it's possible for the ubuntu package to be selected instead of the PPA one
[19:38] <flacoste> that was the way we had to make sure that the PPA package was installed, or not removed on upgrade
[19:38] <maxb> Hmm. OK then
[19:39] <maxb> So either I need to get nifty with substvars or I have to abandon sticking with no-change rebuilds
[19:39] <flacoste> right
[19:39] <flacoste> i did the latter for Jaunty
[19:40] <flacoste> because i'm not a deb package sho-dan
[19:40] <barry> beuno: ui sadness :(
[19:42] <flacoste> maxb: so i'll copy over the other packages now
[19:42] <maxb> the other packages?
[19:43] <flacoste> maxb: other than launchpad-dependencies
[19:44] <maxb> hmm - but some of the others are going to need rebuilding anyway if you would like a python2.4-foo provides inserted
[19:44] <flacoste> right...
[19:44] <flacoste> anyway, it's already done :-)
[19:44] <flacoste> i can copy again later :-)
[19:44] <maxb> heh, ok
[19:46] <flacoste> maxb: let me know when there is more stuff you want to move over, either by an email to the list or IRC
[19:46] <flacoste> maxb: and thanks for doing this, this is really appreciated, especially since we are nearing beta and everybody will need to move over to Karmic
[19:46] <maxb> sure. btw, I never did a python2.4 version of python-lxml or python-setuptools because I couldn't find anything that needed them any more
[19:46] <maxb> ditto python-xml
[19:47] <flacoste> python-setuptools isn't needed anymore
[19:47] <flacoste> we can drop it from l-d
[19:47] <flacoste> python-lxml is still needed i think though
[19:47] <flacoste> for some tests
[19:47] <deryck> barry, hi.
[19:48] <maxb> Does launchpad-dependencies have a branch on which I can propose changes? Or what's the best way to submit a proposed change for it?
[19:48] <flacoste> python-xml, i can't recall
[19:48] <deryck> barry, your email about milestone links is bug 415156.
[19:48] <mup> Bug #415156: Can't get to milestone from bug <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/415156>
[19:48] <flacoste> maxb: actually, that's a very good point
[19:48] <flacoste> we should now use a branch!
[19:48] <barry> deryck: cool, thanks!  i'm gonna metoo it :)
[19:48] <flacoste> i don't think we have one yet
[19:48] <deryck> barry, heh. :)
[19:49] <maxb> flacoste: I could run a bunch of bzr import-dsc, and push one?
[19:49] <flacoste> maxb: that would be awesome
[19:50] <flacoste> i guess, i'll then need to copy over the branch to ~launchpad and make it an "official" branch of some sort so that merge-proposal goes to it?
[19:50] <flacoste> (i haven't use the feature yet)
[19:53] <barry> ubuntu tells me it wants to reboot.  what is this, a mac?
[20:21] <gary_poster> leonardr: I'm seeing a webservice request in the tests that looks like this.  Does this look well-formed?  http://api.launchpad.dev/beta/product-name4/+bug/16/comments/1
[20:21] <mup> Bug #16: "Swedish" and "Swedish (Sweden)" should be the same language <Launchpad Translations:Fix Released by daf> <https://launchpad.net/bugs/16>
[20:21] <gary_poster> heh
[20:22] <leonardr> gary: apparently so!
[20:22] <leonardr> i don't see anything wrong with it. are you having problems?
[20:23] <gary_poster> leonardr: :-) ok.  Yeah, problems in the lazr.* migration, but wanted to make sure that the problems were not above where I was looking.
[20:23] <gary_poster> thank you!
[20:23] <leonardr> np
[20:37] <salgado> beuno, the icon of the 'Setup a new poll' link on https://launchpad.dev/~ubuntu-team/+polls overlaps with the text; how can I fix that?
[20:38] <beuno> salgado, is it a sprite?
[20:38] <salgado> let me check
[20:39] <salgado>       <ul class="add" tal:condition="context/required:launchpad.Edit">
[20:39] <salgado>         <li><a href="+newpoll">Set up a new poll</a></li>
[20:39] <salgado>       </ul>
[20:39] <salgado> guess not
[20:40] <beuno> salgado, so the add button is b0rked?
[20:41] <beuno> remove the "add" class from the ul
[20:41] <beuno> and add class="sprite add" to the href
[20:42] <salgado> cool, thanks beuno
[20:49] <beuno> thumper, let me know if your up early
[20:49] <beuno> and feeling lonely, wanting to talk
[20:55] <beuno> woooo, 79 templates converted, and the number of templates dropped to 375
[20:59] <kiko> unconverted
[20:59] <beuno> yes, unconverted dropped to 375
[20:59] <beuno> from 400+  (can't remember the exact number)
[21:01] <beuno> actually
[21:02] <beuno> yeah, that makes no sense
[21:02] <beuno> the total number dropped, because the scales changed
[21:14] <barry> sinzui: ping
[21:22] <sinzui> hi bary
[21:25] <barry> sinzui: hi
[21:25] <barry> sinzui in your review you mentioned merge people, merge team and merge accounts.  i moved those inline so i don't feel a need to stick them in the menu.  wanted to see if you thought that was enough
[21:26] <barry> sinzui those don't feel like universal actions for all top level containers, like the other ones do
[21:27] <sinzui> but, barry, every other object puts at admin links in the action menu. The admins do not read the page.
[21:27] <barry> sinzui: then maybe they shouldn't go inline also?  it doesn't feel right to me.  maybe beuno can weigh in?
[21:28] <sinzui> barry: consider who we are designing for. The LOSAs. 4 people who have a lot to do and the only thing they read is BOFH.
[21:28] <beuno> barry, admin-only links can go on portlets
[21:29] <sinzui> barry: I do not think they need to be inline. That is content we become obligate to mainstain
[21:29] <beuno> but only if they're super-admin things that only 3 people in the worl dsee
[21:29] <sinzui> 4 next month
[21:29] <kiko> sinzui, did you see that https://edge.launchpad.net/helioviewer is still oopsing? didn't this fix land on edge yet?
[21:29] <sinzui> we need to capture this ruling
[21:29] <beuno> ok, call me when it's over 1000
[21:30] <sinzui> kiko: no PQM was closed for a CP
[21:30] <barry> sinzui, beuno okay, sounds good.  admin links into the portlet and out of inline
[21:30] <barry> thanks guys
[21:33] <gary_poster> EdwinGrubbs: ping
[21:33] <EdwinGrubbs> gary_poster: pong
[21:34] <gary_poster> EdwinGrubbs: When I run multiple tests in a branch that I'm doing some surgery on, I'm getting a postgres disconnection error after the first test.  so--the first test passes, the subsequent tests (in the same layer) fail with the disconnection error in the setUp.
[21:34] <gary_poster> EdwinGrubbs: (1) am I correct in assuming that normally we never disconnect from the db?
[21:35] <gary_poster> (or rarely, not normally between tests)
[21:35] <EdwinGrubbs> gary_poster: I believe we only disconnect in tests when we are testing that functionality.
[21:35] <gary_poster> (2) can you suggest a break point I can put in to see who is calling the disconnect?
[21:35] <gary_poster> EdwinGrubbs: cool, that's what I thought
[21:38] <gary_poster> EdwinGrubbs: (not sure you saw my question #2 above.) Probably a ``disconnect`` method I should use? :-)  Trying to grep myself, but advice would be welcome.
[21:41] <sinzui> barry: ping
[21:43] <sinzui> barry: is it possible to show the latest teams registered on the /people page in 30 minutes of work? See https://edge.launchpad.net/projects
[21:47] <EdwinGrubbs> gary_poster: the code you are looking for might be _reset_store() in canonical.launchpad.sqlbase. If that doesn't work, it might be easiest to wrap the _raw_connection object that storm holds, and watch for a close() method call.
[21:47] <barry> sinzui: maybe, but... mission creep? :)
[21:47] <gary_poster> EdwinGrubbs: awesome, thank you!
[21:48] <sinzui> barry: yes it is
[21:49] <barry> sinzui: open a bug.  maybe later
[21:49] <sinzui> barry: I do not know why that page has the team portlet. We can add it when we extract it from the project page
[21:51] <barry> sinzui: i don't understand
[21:51] <sinzui> barry: you are doing the project page next
[21:52] <sinzui> barry: I mean /projects page
[21:53] <sinzui> barry: I just cc'ed you on a reply to thumper. He is also playing with /projects
[21:54] <barry> cool
[21:57] <thumper> sinzui: one issue is we are redirecting from a view on LaunchpadRoot, to the default view on /projects for the code site
[21:57] <thumper> sinzui: does our redirection infrastructure allow this easily?
[21:57]  * thumper runs Maia to playcentre
[21:59] <sinzui> thumper: I see the rootsite in the directive. I think it works
[22:00] <flacoste> anyone knows where are the instructions on how to upload an .ogg recording the desktop?
[22:00] <sinzui> thumper: it was written for support.launchpad.net/<pillar>/+ticket/<id> to redirect to answers.launchpad.net/<pillar>/questions/id
[22:01] <barry> sinzui: well, at least ec2 is happen with my branch
[22:03] <sinzui> barry: \o/
[22:03] <barry> sinzui: now i just have to get through this review :)  nearly there
[22:14] <thumper> beuno: ping
[22:16] <thumper> barry: did you get my mail about mailman and missing people?
[22:17] <beuno> thumper, leaving home in 10
[22:17] <beuno> thumper, will try to come back online so we can talk in an hour
[22:17] <thumper> beuno: ack
[22:20] <beuno> thumper, I've continued working on the mockup
[22:20] <beuno> not much, but fed some of the feedback back in
[22:20] <beuno> now, really gone for an hour
[22:24] <flacoste> sinzui, beuno: here is what the launchpad-project home page looks for me
[22:24] <flacoste> https://devpad.canonical.com/~flacoste/launchpad-project-top.png
[22:24] <sinzui> a giant list and whitespace?
[22:24] <flacoste> https://devpad.canonical.com/~flacoste/launchpad-project.png
[22:25] <flacoste> sinzui: yes, but the side is also at the bottom
[22:25] <flacoste> and there is whitespace on the right
[22:25] <flacoste> and the left
[22:25] <sinzui> flacoste: I am rearranging the the portlets on that page as a part of my portlet preparation for the disrto page
[22:25] <sinzui> flacoste: all see it
[22:25] <flacoste> you mean, it's not flowing on the right for anybody?
[22:25] <sinzui> It should be fixed in 2 days
[22:26] <sinzui> flacoste: no YUI-G is a grid and it does not like variable width, which is what we do
[22:26] <flacoste> ah, ok
[22:27] <sinzui> flacoste: We are changing the layout to be more like 1.0 to accommodate it.
[22:27] <flacoste> and https://devpad.canonical.com/~flacoste/launchpad-project-code.png
[22:27] <flacoste> is the code page
[22:27] <sinzui> flacoste: This wasn't a surprise. We wanted to see severalc ases before making a decision about how to fix it
[22:27] <flacoste> there it always needs scrolling
[22:28] <flacoste> and the right column is tight with the scrollbar
[22:28] <flacoste> sinzui: ok, got it
[22:28] <sinzui> flacoste: this last pic is odd
[22:28] <flacoste> yeah, kiko wasn't seeing it
[22:28] <flacoste> i am using firefox
[22:28] <sinzui> flacoste: is there a very large unwrappable branch path?
[22:29] <flacoste> not that i can see
[22:29] <flacoste> all branches have amble of white space
[22:29]  * sinzui looks himself
[22:29] <barry> thumper: i did, but i haven't had time to think about it yet
[22:29] <flacoste> well, unless there is a padding-right on the name column
[22:30] <flacoste> in which case lp:~adeuring/launchpad/hwdb-db-schema-subvendor-subproduct-columns would explain it
[22:30] <flacoste> if there is someting like 20em of padding-right
[22:30] <sinzui> flacoste: I am looking at https://code.edge.launchpad.net/launchpad-project
[22:30] <thumper> who wrote the code for showing the pillar on the 3.0 pages?
[22:31] <flacoste> yep same here
[22:31] <sinzui> I see a 20px right margin, no scrolling
[22:31]  * sinzui force-reloads
[22:31] <flacoste> hmm, this is weird
[22:31] <flacoste> me gets the same thing after a force-reload
[22:33] <sinzui> I see missing row borders and rows that are uneven height. I cannot account for the irregularities in this page.
[22:34] <flacoste> sinzui: do you see the same errors after force-loading?
[22:34] <sinzui> yes
[22:35] <sinzui> My page is readable, which cannot be said for yours
[22:35] <sinzui> My browser window is set to 1024 wide
[22:35] <sinzui> yours is 1225
[22:37] <thumper> I have some questions about the logo in the corner
[22:37] <thumper> who do I ask?
[22:39] <rockstar> sinzui, I has a question about a failing answers test - Do you have a minute?
[22:39] <sinzui> i do
[22:40]  * sinzui prepares for uncode nonsense.
[22:40] <rockstar> sinzui, so, it looks like there is some sort of ACL for linking bugs to questions, as an admin seems to be able to link a bug that another person can't unlink.
[22:41] <sinzui> rockstar: bug linking is based on the user being an answer contact (which is voluntary)
[22:42] <rockstar> sinzui, hm.  Okay, so I haven't changed any actual underlying code here, but the test  answersbugs/stories/question-buglink.txt is failing at line 155.  I'm not sure how a minor template change would break that.
[22:43] <sinzui> rockstar: I just looked at the answersbugs/configure.zcml and see that +linkbug and +ublinkbug are AnyPerson
[22:43] <rockstar> Yeah, that's how I've understood it.
[22:43] <rockstar> sinzui, so I don't completely understand why there would be a test for not being able to unlink a bug.  This is what I'm trying to sleuth.
[22:44] <thumper> sinzui: I don't like that our primary context is derived by IHasLogo
[22:44] <thumper> sinzui: shouldn't we have a definitive interface like IPrimaryContext
[22:44] <thumper> sinzui: I'm trying to work out how to fix branches
[22:45] <rockstar> Oh wait, it looks like bug #6 is set to private in the test.
[22:45] <mup> Bug #6: "next 10 entries" at bottom of page <Launchpad Translations:Invalid by carlos> <evolution (Ubuntu):Invalid> <https://launchpad.net/bugs/6>
[22:45] <sinzui> thumper: you are welcome to introduce the interface. You can solve the ISprint problem while you are at it ;)
[22:45] <thumper> sinzui: also if the context doesn't provide IHasLogo, it walks up the canonical_url_iterator
[22:45] <rockstar> However, that still doesn't explain why the text is gone.
[22:45] <thumper> sinzui: what is the ISprint problem?
[22:46] <sinzui> rockstar: I see and think that is related
[22:46] <rockstar> sinzui, I think I figured it out.
[22:46] <sinzui> rockstar: There are nasty unicode issues in the tests where something prints fine (but has unicode in it) then the next test fails, leaving you confused
[22:46] <rockstar> generic-edit is proving less and less useful - or maybe the extra information we have is proving to be more of a pain in the but.
[22:47] <sinzui> thumper: Sprints have IHasLogo, so they get branding. Should they?
[22:48] <thumper> sinzui: what are we calling this thing in the top corner?
[22:48] <sinzui> thumper: I think Sprints really belong in a registry, but it bound to projects via a blueprint
[22:48] <thumper> sinzui: are we calling it our primary context?
[22:48] <sinzui> I call it a watermark
[22:48] <thumper> sinzui: and it should be one of Person, Product, Project, Distro ?
[22:48] <sinzui> The context is in the breadcrumbs. It is generated by the heading-slot
[22:49] <thumper> sinzui: is it ever something else?
[22:49] <sinzui> thumper: apparently there is Sprint
[22:49] <thumper> sinzui: *should* it ever be something else ?
[22:49] <spm> sinzui: we also read alt.sysadmin.recovery, not just BOFH
[22:50] <rockstar> thumper, I think that generic-edit.pt should have a way to show the "extra_info" slot idea.
[22:50] <sinzui> thumper: Anything that a top-level collection can return may be viewed as the root, so outside of the collections we just named, I will add bugtracker and language
[22:50] <rockstar> thumper, that would mean we could get rid of more templates.
[22:51] <sinzui> thumper: But I am unsure of them. there are several bugs about how we treat top-level collections or these rare objects so we are feeling out the rules as we implement their pages.
[22:53] <sinzui> rockstar: I am sorry about these tests. I am sure many failed because they assumed a certain HTML structure. I now only use ids to find and test content.
[22:54] <thumper> sinzui: ok, how about this: IWatermark interface, watermark:heading and watermark:logo tales path adapter
[22:54] <rockstar> sinzui, not a big deal.  This one was my fault, actually.  There were some others where I had WTF moments, but I have that pretty regularly anyway.  :)
[22:54] <thumper> sinzui: adapts the context to IWatermark.
[22:54] <thumper> sinzui: we register adapters for the pillars
[22:54] <thumper> sinzui: failure to adapt gives launchpad.net
[22:55] <sinzui> thumper: That is too close to IHasLogo. And the reason the design uses that is because branding is important. Let's rename IHasLogo if you are thinking about IWatermark.
[22:55]  * thumper thinks about walking the url...
[22:55] <thumper> sinzui: but what about sprints that have a logo?
[22:55] <thumper> sinzui: wouldn't it be more important to kill the logo of a sprint?
[22:56] <sinzui> Yes it does and I am not sure it is wrong to show it. It is branded so I think we want to show it
[22:56] <thumper> sinzui: if we are using IHasLogo to determine the watermark, then lets just use that
[22:56] <thumper> sinzui: but *should* it be branded?
[22:57] <sinzui> I think so
[22:57] <thumper> why?
[22:57] <thumper> sinzui: it seems strange to provide an adapter for IBranch to IHasLogo for some reason...
[22:57] <sinzui> Because they exist outside of teams and projects. I do not think they need a blueprint to exist.
[22:57] <sinzui> thumper: I agree
[22:58] <sinzui> Let's return to IPrimaryContext
[22:58] <thumper> ok
[22:58] <sinzui> My concern is that the content of the page is about the context, not the IPrimaryContext. like a milestone, or a bug
[22:58] <thumper> what about the watermark tales adapter?
[22:59] <sinzui> I like that suggestion
[23:00] <sinzui> I am considering IRegistration to make the "Registers by <person> on <date>" in the header
[23:00]  * thumper nods
[23:00] <thumper> although the content should be overridable
[23:01] <thumper> speling fail
[23:01] <sinzui> make more sense than my spelling
[23:01] <thumper> sinzui: how do you traverse to a sprint?
[23:02] <sinzui> https://edge.launchpad.net/sprints
[23:02] <sinzui> https://edge.launchpad.net/sprints/uds-karmic
[23:03] <thumper> oh holy bejezus
[23:03] <sinzui> thumper: ubuntu is the major user. the feature is hidden. I like it. I think it would be used if it was not so tightly coupled with blueprints
[23:03] <thumper> those pages need some love
[23:03] <thumper> sinzui: we should not hide it so much
[23:04] <sinzui> thumper: I believe that will be barry's effort
[23:04] <thumper> sinzui: bring on those project management features :)
[23:10] <barry> sinzui: more on your review
[23:10] <barry> sinzui using the menu on the inline text makes the tal look horrible.  how strongly do you feel about it?
[23:14] <sinzui> barry: You put me in an awkward position
[23:15]  * barry is a contortionista
[23:15] <barry> sinzui: oh and context/menu:overview is empty
[23:15] <sinzui> barry: I feel strongly that consistency is often better than beauty
[23:15] <barry> sinzui: "strongly" is an acceptable answer :)
[23:16]  * sinzui thinks
[23:17] <sinzui> menu:usefor=IPersonSet -> context/@@+global-actions
[23:19] <sinzui> barry: there is another option for a shortlist use <ul class="horizontal"> to make links like the project page external links. You can fit about 5 links in the space.
[23:21] <barry> hmm
[23:22] <sinzui> barry: did you update the menu directive in ZCML?
[23:23] <sinzui> barry: if not do you want to say FTW and just register them al in python like a real man.
[23:37] <sinzui> thumper: I think IRootContext or IFirstContext is better than IPrimaryContext. I think that because "primary" implies the content of the page to me, which is not your case when the breadcrumb are a level below root
[23:38] <thumper> IRootContext WFM
[23:42] <thumper> sinzui: do we have a nearest_adapter?
[23:43] <thumper> sinzui: the nearest method in c.l.webapp.publication only checks for providedBy, not adaptation
[23:43] <thumper> sinzui: sould we have IProduct, IProject, IPerson, IDistribution inherit from IRootContext?
[23:43] <thumper> sinzui: or should we adapt to it
[23:43]  * sinzui looks in menu
[23:44] <thumper> I've got to take the car to the mechanics now
[23:44] <thumper> there is some issue with the brakes they fitted a couple of weeks ago
[23:44] <thumper> shouldn't be long
[23:44] <sinzui> thumper: I would make them inherit
[23:45] <thumper> sinzui: ok
[23:45] <sinzui> from canonical.lazr.canonicalurl import nearest_adapter
[23:45] <sinzui> ^ thumper
[23:45] <thumper> sinzui: I think we should do something like this instead of nearest
[23:46] <thumper> sinzui: otherwise we need to provide adapters for everything under branches too
[23:46] <thumper> sinzui: sound ok?
[23:46] <sinzui> thumper: that is the same reasoning salgado gave for IRegistrant
[23:46] <thumper> sinzui: I'll write it up and get you to review
[23:47] <sinzui> thumper: I think it is and I think it better if we take the same kind of approach to solving the header issues.
[23:48]  * thumper nods and leaves
[23:51] <wgrant> cprov: buildd-manager isn't as async as you think it is. Both upload processing and ensurePresent block it.
[23:58] <kiko> hey
[23:58] <kiko> sinzui, barry: can I get a mailing list approved?
[23:59] <beuno> kiko, Canonical DX Team Commits?
[23:59] <kiko> beuno, yep!