[12:05] <mpt> <h2 style="margin-top: 0; padding-top: 0;">OMG WHAT A HACK</h2>, even
[12:06] <bradb> check now; the actions portlet ends up really high up
[12:07] <bradb> our other pages don't line up the actions portlet with the page label (or whatever you want to call that bit), they line up with the bit that appears in the body
[12:07] <bradb> er, wait
[12:08] <bradb> SWEET
[12:08] <bradb> that worked, thanks
[12:11] <mpt> bradb: It shouldn't affect the branch's review/merge in any way, but it will be interesting trying to come up with meaningful text for that "General Bugs" heading 
[12:11] <mpt> Is "Untargeted" wrong?
[12:11] <bradb> Untargeted is right
[12:12] <mpt> Then why does bug 3 show up in "Fix wanted for Sarge" as well?
[12:12] <bradb> mpt: because bug #3 is targeted to be fixed in Sarge
[12:12] <mpt> Well it can't be both targeted and untargeted
[12:13] <mpt> I understand what's going on in the underlying model, I just don't know how to explain it :-)
[12:14] <bradb> yeah, it's a bit tricky
[02:55] <stub> spiv: ping
[02:56] <spiv> stub: pong
[02:57] <stub> In current head, a person can have multiple wikinames per wiki, including the ubuntu one.
[02:57] <stub> This currently occurs when person merging happens
[02:58] <stub> I was wondering how this would affect the moin integration
[02:58] <jamesh> probably depends on whether the authserver uses selectOne :)
[02:58] <stub> I need to determine if this is a bug or a feature ;)
[02:59] <spiv> The authserver will just grab which ever row happens to be returned first, I think.
[02:59] <spiv> jamesh: The authserver doesn't use SQLObject atm, so it doesn't :)
[02:59] <spiv> There really ought to only be one wikiname for the "ubuntu" wiki.
[03:00] <spiv> (Which really means in a strict sense that it ought to be column on Person...)
[03:00] <stub> How will it affect subscriptions etc? Will it depend on what wikiname I log in as? Or will preferences be stored against the one returned by the authserver?
[03:00] <spiv> There's some confusion here.
[03:00] <spiv> So:
[03:00] <spiv>  * it doesn't affect subscriptions at all.
[03:01] <spiv>  * you don't log in as a wikiname (you log in with your launchpad login, like everywhere else)
[03:01] <spiv>  * launchpad-integrated moin uses the Person id for keeping track of preferences and things, the wikiname is purely for display.
[03:02] <spiv> The wikiname is only used as the thing to display in RecentChanges and the like.
[03:02] <stub> I though 'launchpad-login' meant 'your person.name, or one of your validated email addresses, or your wikiname' at the moment?
[03:02] <spiv> No, just the first two.
[03:03] <spiv> (Although LP itself only accepts validated email addresses -- we should make this consistent)
[03:03] <stub> ok. So we can consider this a feature if we want, and the only glitch might be that the authserver may not consistantly return the same wikiname for a peron
[03:04] <stub> (which would be a trivial ORDER BY fix)
[03:04] <spiv> (I'd have been just as happy for the "wikiname" for our wikis to be the Person.name, but people seem to expect otherwise0
[03:04] <stub> In hindsight you might be right there.
[03:05] <spiv> Well, Wikipedia/Wikitravel have heaps of happy users with names that don't conform to WikiCaps.
[03:05] <spiv> In fact, so did our old zwiki, which used person.name :)
[03:05] <jamesh> spiv: would it be difficult to get launchpad integrated moin to accept the wiki name too?
[03:05] <spiv> jamesh: Not at all -- but the existing inconsistency bugs me, and I don't like the idea of making it worse.
[03:05] <jamesh> okay
[03:06] <stub> which inconsistency do you refer to?
[03:06] <spiv> Purely from a UI standpoint -- having a unified login that then behaves differently seems a bit silly :)
[03:06] <jamesh> wikipedia doesn't do auto linking of StudlyCaps, so having non StudlyCaps wiki names isn't as big a deal
[03:07] <jamesh> spiv: I was suggesting allowing either an email address or the wiki name
[03:07] <spiv> stub: https://launchpad.net/ accepting different logins to the wikis (and anything else using the authserver)
[03:07] <jamesh> spiv: that way it'll work for people who see it as "launchpad login", and for people who see it as "moin login"
[03:07] <spiv> stub: Saying "Use your Launchpad login, only different" on the login form would be silly ;)
[03:07] <spiv> jamesh: It's pretty explicitly a Launchpad login.
[03:08] <spiv> To the extent that to create a wiki account it says "Go here and sign up with Launchpad."
[03:08] <stub> I see. Yes, launchpad and authserver should use the same 'username' definition. No reason for them to be different. No reason they can't all use any of the unique keys associated with a person (name, emails, wikinames)
[03:08] <stub> I'll open a bug on that
[03:09] <spiv> Yeah, I'm happy for it to include wikiname, so long as the web app does too :)
[03:11] <stub> So allowing multiple wikinames for our internal wikis is utterly pointless?
[03:11] <spiv> jamesh: Yeah.  Sometimes I think people confuse auto-linking StudlyCaps as being an integral part of being a wiki, when the important part is just that every page is editable.  (linking should be easy, of course, but ["some foo"]  isn't significantly harder than SomeFoo).
[03:11] <jamesh> email addresses are distinguishable from launchpad usernames and wiki names
[03:11] <spiv> stub: Yeah.  If only one of them is ever going to be displayed in page metadata, there's not much point.
[03:12] <jamesh> but launchpad user names aren't necessarily distinguishable from wiki names
[03:12] <jamesh> which would be a problem
[03:12] <spiv> Well, lp user names must be lower case, iirc.
[03:12] <jamesh> you'd only want to allow one of those at most as a username
[03:12] <spiv> And by convention wikinames have caps in them, but that's not enforced...
[03:13] <stub> I think StudlyCaps is pretty important - it makes wiki pages trivially linkable, less likely to get typos and nicer urls
[03:14] <jamesh> okay.  So if we require a leading capital on the Ubuntu wiki name then they are definitely distinguishable
[03:14] <spiv> stub: Wikipedia disproves that, I think.  I may depend somewhat on the audience and activeness of the wiki, though.
[03:15] <spiv> s/I may/It may/
[03:16] <stub> wikipedia solves the same issues in otherways. it controls the wikinames and urls that get generated. It doesn't rely on someone typing ["This is a wiki page"]  to generate a new document.
[03:17] <spiv> It does?  I wasn't aware of any differences -- you can link to pages that don't exist, and if you visit a page that doesn't exist, you're prompted to create it if you like.
[03:17] <spiv> (I'm more familiar with Wikitravel than Wikipedia, but they both run Mediawiki)
[03:18] <jamesh> stub: you can create pages in wikipedia the same way, iirc -- link to a non-existant page, or just type in the URL
[03:18] <stub> oh... you are probably right. It uses a different algorithm to generate urls though (whitespace is replaced with _, which I think is non standard (and preferable))
[03:18] <spiv> Oh, right.  Yeah :)
[03:19] <jamesh> that and requiring special syntax to create links
[03:19] <jamesh> (note that moin 1.3 also converts spaces to underscores in page names)
[03:19] <spiv> StudlyCaps is already special syntax, really.
[03:20] <stub> heh... they still get occasional sucky urls though ;) http://en.wikipedia.org/wiki/Union_County%2C_New_Jersey
[07:39] <nlghtcrawler> hey guys
[09:02] <dilys> Merge to rocketfuel@canonical.com/arch-pqm--main--0: r=spiv merge in public branch and pqm status improvements (patch-26: robert.collins@canonical.com, pasc@redellipse.net)
[10:18] <carlos> morning
[10:23] <spiv> carlos: Hey.
[10:23] <carlos> spiv, hi
[10:24] <spiv> carlos: Can you find out if that rosetta-export-queue.py on production is current, so we can track down that error?
[10:25] <carlos> sure
[10:25] <spiv> (I'm very tired though, so input from me may have to wait until Monday)
[10:26] <carlos> spiv, Monday is holiday here so I will not be back until Tuesday
[10:27] <spiv> Hmm :/
[10:27] <spiv> Well, get me as much info as possible so I can look into it myself on Monday, I guess.
[10:28] <carlos> I'm updating my "dist" directory to see the patchsets on production
[10:28] <carlos> I think I would only give you the "yes, production code has the fix" or "no, production code is lacking the fix"
[10:30] <spiv> Can you give me a brief description of how I might be able to test or reproduce this?  I'm not hugely familiar with that export code.
[10:30] <spiv> I'll resort to just reading the code and guessing if I have to :)
[10:31] <carlos> spiv, to reproduce exactly the same situation
[10:31] <carlos> request the download of the same po file from different users
[10:31] <carlos> and then execute the export script
[10:31] <carlos> the first will work
[10:31] <carlos> and will upload that file into librarian
[10:32] <carlos> the second request will try to get the file from librarian and will fail
[10:32] <spiv> Excellent.  Thanks!
[10:32] <carlos> http://localhost:8086/products/evolution/+series/main/+pots/evolution-2.2/es/+export
[10:32] <carlos> spiv, you can request the export from that URL
[10:33] <carlos> spiv, and the cronscript you need to execute is rosetta-export-queue.py from the cronscripts directory
[10:33] <carlos> spiv, I can do it if you want
[10:34] <spiv> Already done it ;)
[10:34] <spiv> Thanks.
[10:36] <carlos> np
[10:37] <carlos> stub, which is current production branch?  rocketfuel@canonical.com/launchpad--production--1.26 ?
[10:48] <carlos> spiv, if production is 1.26, it has already the fix
[10:56] <jordi> carlos: any quick idea of how you'd remove strings from a po file that are not included in a second pofile?
[10:56] <jordi> msgcmp tells me whch, but I can't generate a file based on that.
[10:56] <carlos> jordi, msgmerge?
[10:57] <carlos> jordi, take the second pofile as a .pot file
[10:57] <carlos> and merge it
[10:57] <jordi> carlos: doesn't work, it gives me a greatly fuzzied file
[11:00] <carlos> jordi, no idea then, sorry
[11:00] <carlos> jordi, perhaps you could use msgfilter
[11:00] <carlos> to remove all translations
[11:00] <carlos> so you get a .pot file
[11:00] <carlos> and you can merge that
[11:03] <jordi> hmm
[11:03] <jordi> let's try that one
[11:05] <jordi> you mean msgattrib=
[11:20] <stub> carlos: stuart.bishop@canonical.com/launchpad--production--1.27 (it never got tagged across to Rocketfuel)
[11:22] <carlos> jordi, msgfilter lets you filter translations
[11:22] <carlos> stub, oh, ok
[11:27] <carlos> spiv, ok, confirmed, production has the commit between the librarian upload and the next request
[11:50] <spiv> carlos: Ok, I'll dig further.  Thanks!
[11:51] <carlos> spiv, you are welcome
[11:52] <carlos> spiv, as a workaround, should I catch that exception and do a full export instead?
[11:52] <carlos> or do you think you will fix it soon?
[11:53] <spiv> I'm not sure off the top of my head, I need to read the code and get a little more context.
[11:56] <spiv> carlos/jordi: http://mail.zope.org/pipermail/zope3-dev/2005-August/015197.html
[11:57] <carlos> spiv, ok
[11:57] <carlos> spiv, the workaround is easy so If you don't have a clue on Tuesday I will implement it and ask to include it with the production update
[11:58] <spiv> Ok :)
[11:58] <carlos> spiv, that's what I call a useful bug report....
[11:59] <spiv> carlos: I know :/
[11:59] <spiv> Still, a prompt response will hopefully give a positive impression, and turn it into something useful.
[12:00] <spiv> Interesting also that they chose to ask the Zope community for help rather than Launchpad.
[12:07] <carlos> answered
[12:33] <Mez> I cant seem to login to launcyhpad and stay logged in
[12:34] <Kinnison> Mez: the cookie is short-lived
[12:34] <Kinnison> Mez: Or perhaps you're refusing cookies from us entirely
[12:35] <Mez> Kinnison, It's letting me log in now
[12:35] <Mez> weird
[12:35] <Mez> Kinnison, it was saying I was logged in, then I was trying to click on my name in the top right and it was logging me out :D
[12:35] <Kinnison> very odd
[12:36] <Mez> mmhmm
[12:36] <Mez> works now
[12:46] <Kinnison> SteveA: ping
[12:54] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Feedback and tweaks to data fix script (patch-2250: stuart.bishop@canonical.com)
[01:02] <SteveA> Kinnison: 
[01:02] <Kinnison> SteveA: see your SMS inbox
[01:03] <SteveA> thx
[01:17] <SteveA> spiv: re ian bicking's blog, can you tell jblack where it is?
[01:17] <SteveA> this would be a good place for jblack to chip in about the supermirror
[01:19] <spiv> jblack, SteveA: http://blog.ianbicking.org/
[01:19] <SteveA> i replied to the list.  can you reply with that url?
[01:19] <spiv> Ok.
[01:20] <spiv> Hmm, he's just posted another entry.
[01:22] <spiv> Done.
[01:23] <SteveA> spiv: is ian's blog widely read?
[01:23] <spiv> Yes, quite.
[01:23] <spiv> e.g. Havoc Pennington linked to him (on this topic).
[01:24] <spiv> He's fairly well known, because of his work on SQLObject and WSGI.
[01:44] <salgado> yo SteveA. any news about the review of my branches?
[01:45] <SteveA> salgado: i'm 1/2 way through
[01:45] <SteveA> looking good.  i need to check that the login stuff works properly with the rest of the infrastructure.
[01:46] <salgado> SteveA, great. thank you. :)
[02:10] <allee> Hi
[02:28] <allee> I'm plaing with malone. When Debian BTS has already a bug registered. I tried 'Indicate Bug Occurs in Distribution'
[02:29] <allee> but found no way to specify debian (select always returns nothing)
[03:03] <bradb> allee: hi.
[03:03] <allee> bradb: hi
[03:03] <bradb> allee: you're right, we don't seem to have imported details about debian into Launchpad yet.
[03:03] <allee> bradb: 'k
[03:04] <salgado> SteveA, how do I get rid of the security proxy so I can append()/insert() items in a list?
[03:05] <allee> another thing I've not found yet: is there a way I can subscribe cc/watch to some pkgs (not only bugs).
[03:05] <bradb> allee: not yet, but we just finished spec'ing such functionality last week and the week before at a developer summit in brazil
[03:06] <bradb> allee: https://wiki.launchpad.canonical.com/PackageSubscriptions
[03:06] <allee> bradb: that's great news.  Malone has many features I missed
[03:06] <SteveA> salgado: i think this is in the hackers faq, but in case it isn't, the best way is to use list(L) to make a mutable copy of the list
[03:08] <allee> bradb: about indicate distro:  Does it submit a but report to this BTS too?  this was not clear to me  (because there is no bug# to specify)
[03:08] <allee> s/but report/bug report/
[03:08] <Kinnison> If anyone needs anything from me, catch me in the next 10 minutes
[03:10] <bradb> allee: no. malone can watch the status of bugs in external bug trackers, but not push bugs into the upstream bugtracker itself (unless, of course, upstream is using Malone. :)
[03:10] <bradb> pushing the bugs upstream would encourage people to file dups, IMHO
[03:12] <allee> That's okay. I added a watch already.  To make this clear I would suggest to ask for distro/package/bugID on this page.  At least I would not have worried that malone may submit a bts report
[03:14] <allee> bradb: Thx.  Malone is pretty usable and nice.  I'll recommend it to others ;)
[03:14] <bradb> allee: that's an interesting idea about the "indicate also exists in..." for a distro. we'll ponder that.
[03:14] <mpt> bradb: Shall I make you up a template for the merged page?
[03:15] <mpt> or would it be auto-generated?
[03:16] <bradb> mpt: don't worry about it; forms like that are easy enough html/css wise that i can do them :P
[03:16] <mpt> So, just a JPEG then? :-)
[03:18] <mpt> salgado: I got an error in make run
[03:18] <mpt> psql: FATAL:  user "mpt" does not exist
[03:18] <mpt> * Add the following to /etc/postgresql/postgresql.conf:
[03:18] <mpt>     search_path='$user,public,ts2'
[03:19] <bradb> mpt: if you want to do it, go ahead. i've got a huge amount of work to do before i get anywhere near it, so...
[03:20] <salgado> mpt, can you try that again now?
[03:20] <mpt> psql:trusted.sql:13: ERROR:  permission denied for language plpythonu
[03:20] <mpt> psql:trusted.sql:24: ERROR:  must be owner of function valid_name
[03:20] <mpt> salgado: and a dozen other pairs of errors of the same type
[03:21] <salgado> mpt, again? ;)
[03:21] <mpt> now we're further ...
[03:23] <mpt> * Creating launchpad_dev
[03:23] <mpt> dropdb: database removal failed: ERROR:  database "launchpad_dev" is being accessed by other users
[03:23] <mpt> salgado: I'm not sure that problem's fatal, though
[03:23] <mpt> createdb: database creation failed: ERROR:  database "launchpad_dev" already exists
[03:23] <mpt> * All done
[03:24] <stub> That should be fatal
[03:24] <mpt> ok, it runs, but the schema still doesn't match the code
[03:24] <salgado> mpt, we're going to share the same database for some time. this is definitely not a good idea, but I don't have time to investigate how to make the db creation scripts read the configuration files
[03:25] <mpt> So I need to update this branch, then
[03:25] <mpt> ok, no big deal, thanks
[03:25] <salgado> stub, how much work do you think it is to get the db-creation scripts (make -C database/schema, in fact) to read the config files and create the proper databases
[03:27] <stub> salgado: Bits would need to be rewritten in Python. It wouldn't help though as the test database names are not configured in the config file - they are well known names.
[03:28] <stub> salgado: So it would also involve trawling for launchpad_ftest_template and launchpad_ftest (I think) and fixing those references.
[03:28] <salgado> mpt, then we'll probably have some considerable annoyances soon. :-(
[03:29] <stub> salgado: You can't run multiple postmasters? Might be easier - just give developers their own ports
[03:29] <mpt> salgado: How do you and kiko and cprov normally work together, then?
[03:29] <bradb> mpt: where did the attachment go that was pointed to from https://wiki.launchpad.canonical.com/MaloneSearchResults ?
[03:29] <salgado> mpt, they work in their laptops. I'm the only one using anthem's postmaster (the one you use now)
[03:29] <mpt> bradb: lpwiki, probably
[03:29] <bradb> ISTR that might have been the spec where we used a long-and-ugly URL to link to the attachment, and those URLs are subject to change, AFAIK
[03:30] <mpt> hmm, no
[03:30] <mpt> "Upload new attachment" means it was never uploaded
[03:30] <salgado> stub, that seems to be the best thing to do. will try it
[03:30] <bradb> we didn't upload it
[03:30] <mpt> using a long and ugly URL would give you a broken-image icon
[03:30] <bradb> we linked to it with some long-and-ugly URL pointing somewhere else, instead of uploading it into the wiki for that specific spec and using the normal "attach:filename" syntax, IIRC
[03:31] <bradb> or not. i dunno. but it's not there now. where do i find it?
[03:33] <mpt> No, because if we'd done that, there'd be a broken-image icon rather than "Upload new attachment"
[03:33] <mpt> Well, there's still the version in Montreal2005
[03:33] <bradb> n/m, i found the file
[03:34] <mpt> https://wiki.launchpad.canonical.com/Montreal2005?action=AttachFile&do=get&target=2-search-results-list.jpg
[03:35] <mpt> bash: refuel: command not found
[03:35] <bradb> right, i *knew* there was a long-and-ugly-subject-to-changing URL somewhere :)
[03:35] <mpt> but I know what you mean, I did draw a newer version during the sprint
[03:36] <bradb> argh, the file that i thought it would be (per the name) isn't what i expected it to be
[03:37] <salgado> stub, I guess it's a good idea to use a different $PGDATA, or there's no need for it?
[03:37] <bradb> mpt: where can i get the photo of the newest design?
[03:38] <mpt> bradb: I don't know, sorry
[03:38] <stub> salgado: You have to - you won't be able to start multiple postmasters using the same one
[03:38] <mpt> bradb: I'll draw it again if you like
[03:38] <salgado> stub, how do I setup a new PGDATA? what files are initially needed there?
[03:40] <stub> initdb 
[03:41] <stub> initdb -E UNICODE --no-locale --pgdata=/var/whatever/foo
[03:44] <stub> salgado: You can probably share the launchpad.conf etc. by creating symlinks to /etc/postgresql (see the default PGDATA for an example - default Debian setup does it this way)
[03:45] <salgado> yes, it looks like initdb did this for me
[03:46] <mpt> salgado: dude, you don't have refuel installed :-)
[03:50] <salgado> stub, "postmaster -d 5 -D /var/lib/postgres/data/mpt -p 5431" seems to run fine, but is not listening on port 5431. am I missing something?
[03:51] <stub> Add a -i in there too
[03:53] <salgado> ah, cool. ta
[04:00] <bradb> spiv: ping
[04:00] <niemeyer> Greetings!
[04:02] <mpt> bradb: https://wiki.launchpad.canonical.com/SimplifyingMalone
[04:03] <bradb> daringly sane
[04:04] <bradb> one of my favourite bits of that would be to de-amateurize the way comments are displayed
[04:09] <bradb> SteveA: I want to declare a constant for the list of unresolved bugtask statuses. It would look like: BUGTASK_UNRESOLVED_STATUSES = [BugTaskStatus.NEW, BugTaskStatus.ACCEPTED] . Do we have a module for that?
[04:10] <bradb> if not, should i just create a canonical.launchpad.constants?
[04:13] <mpt> ddaa: Had time to look at the samba/ubuntu-doc bug yet?
[04:25] <mpt> great, baz crashes on normal merging *and* star-merging
[04:39] <bradb> spiv: ping
[05:02] <mpt> ddaa/jblack: baz is crashing on every merge, and it's not because it's running out of memory ... help?
[05:05] <bradb> mpt: Do we have a CSS class to underline links in portlets? Should "requires _login_" be underlined in a portlet?
[05:05] <mpt> bradb: No, portlets are explicitly excluded from the "links should look like links" part of launchpad.css
[05:05] <bradb> even for a "requires _login_" link?
[05:06] <bradb> (like the "Assigned to me (requires _login_)" option)
[05:06] <mpt> bradb: Yes, portlets are explicitly excluded from the "links should look like links" part of launchpad.css, and CSS is not yet powerful enough to examine the text of nodes
[05:07] <mpt> bradb: "(requires login)" looks bad anyway ... Can you instead link to a generic URL that asks you to log in, then redirects you to your own list of assigned bugs?
[05:08] <mpt> Then you'd only need to follow one link, not two 
[05:08] <bradb> hm, good point, i'll file a bug on this
[05:09] <mpt> We appear to already have this, bradb, https://launchpad.net/malone/assigned
[05:10] <bradb> quite trolling :)
[05:10] <bradb> quit, even
[05:10] <jeprubio> hello
[05:10] <mpt> except that after logging in, instead of redirecting me to https://launchpad.net/people/mpt/+assignedbugs or whatever, it says "Sorry, you don't have permission to access this page"
[05:10] <mpt> I'm not trolling, I'd forgotten about that page until after I suggested it
[05:11] <bradb> That page is not equivalent to the "Assigned to me" bug list link
[05:11] <bradb> (not to mention that /malone/assigned just sucks in overall)
[05:12] <bradb> s/in //
[05:13] <mpt> What is it supposed to do?
[05:13] <mpt> It looks like it's supposed to be equivalent to "Assigned to me", because when I went over its template I ended up reporting https://launchpad.net/malone/bugs/1367
[05:13] <jeprubio> I have found a bug detecting a Sis sound card and a web who fixes it, I think it could help for other people who have the same problem, I'm going to include the link in the wiki but I'm sure it should be better that ubuntu fixes it
[05:14] <mpt> jeprubio: At the moment, you should report a bug like that in http://bugzilla.ubuntu.com/
[05:14] <SteveA> bradb: constants are part of the interfaces
[05:14] <bradb> /malone/assigned is context-free, lives at the wrong URL (and has thus been reimplemented in FOAF), has a totally inconsistent look and feel to the other bug listings (and to all other lp pages), etc.
[05:14] <SteveA> bradb: our standard for constants is that they live inside a class's namespace, and are importable from interfaces.
[05:15] <jeprubio> mpt ok, thanks
[05:15] <SteveA> if this is more of a one-off then perhaps just declare it in interfaces/bugtask.py
[05:15] <SteveA> and make it available from interfaces.
[05:16] <SteveA> there is no need for a special new place for these things.
[05:16] <bradb> i.e. IBugTask.UNRESOLVED_STATUSES?
[05:16] <bradb> er, no, i guess you meant module-level
[05:18] <SteveA> yes
[05:18] <SteveA> but, it needs to be UNRESOLVED_BUGTASK_STATUSES
[05:18] <SteveA> as it will be importable from interface
[05:18] <mpt> bradb: Well, a context-free URL to begin with is what you want when someone's not logged in yet, and it already has part of the right behavior (making you log in first) ... I don't know how much sense it would make to modify it to redirect you to your own +assignedbugs as opposed to implementing that from scratch, though.
[05:19] <bradb> mpt: why do you want a context-free URL when someone's not logged in but they're already in a context?
[05:19] <SteveA> i don't like the idea of pages that themselves change totally according to who is logged in.  i prefer the idea of pages that redirect to a page that is related to a person
[05:20] <SteveA> so, for example,
[05:20] <SteveA> i go do +my-own-assigned-bugs-k-thx-bye
[05:20] <SteveA> and it redirects to /person/stevea/+assigned
[05:20] <SteveA> this is a good model, because i can then give /person/stevea/+assigned to other people
[05:20] <SteveA> and they can see what i see
[05:20] <mpt> bradb: Oh, *that* kind of context-free
[05:20] <bradb> mpt: the fact that /malone/assigned makes you login is purely accidental, btw. :)
[05:20] <mpt> bradb: I thought you meant "all bugs assigned to me"
[05:22] <mpt> SteveA: Sure, I absolutely agree, we just need an URL to put in the portlet that will (a) make you log in and (b) direct you to your personal URL, such that we don't need to cruft up the portlet with "this isn't a link because you need to __log in__ first"
[05:35] <bradb> mpt: Just to be clear then, when looking at, say, /products/malone/+bugs and not logged in, should there be a "Show Assigned to Me" link which, when clicked, will prompt you to login?
[05:37] <bradb> SteveA: I'm about to finish a response to a review on a critical Malone landing (sp bug listing), but spiv, the reviewer, appears to be sleeping. Is it possible that you might be able to pick up on this and look at my response based on his comments and tell me if I can merge it?
[05:38] <mpt> bradb: "Assigned to me", yes
[05:38] <bradb> ok, thanks
[05:39] <SteveA> bradb: i have a salgado review to finish, and then some other stuff planned.  i may be able to look at it later, but i think spiv should be the one to finish the process he and you started.
[05:39] <SteveA> you're not going to get the changes into the standard rollout anyway
[05:39] <mpt> bradb: All those buglists should have their own <h4>Bug lists</h4> or similar, so that they're separated from the actions and therefore don't all need to start with "Show"
[05:40] <bradb> I put them in their own portlet, but the sab moved them into the actions portlet in .br, IIRC
[05:41] <SteveA> um
[05:41] <SteveA> the actions portlet should not be called "actions"
[05:42] <SteveA> and so it need not have everything be verbalized
[05:42] <mpt> bradb: well, if you're repeating the same word(s) more than ~2 times it's a good sign you're using the wrong presentation
[05:42] <bradb> mpt: preaching, choir, etc.
[05:44] <mpt> Well, I could remove all the <h4>actions:</h4> right now if someone could help me get baz working ;-)
[05:46] <mpt> jblack?
[05:46] <jblack> I'm here, but in a conversation. what's up?
[05:47] <mpt> jblack: In two different branches, I get "baz: uncaught exception: -1:(unable to fork for patch)" when merging rocketfuel into them
[05:47] <mpt> for both normal merge and star-merge
[05:47] <mpt> and it's not lack of memory, consumption reaches only about 60% before the failure
[05:49] <jblack> Try the --star-merge argument
[05:50] <mpt> Yes, that's what I mean by "both normal merge and star-merge"
[05:52] <jblack> Oh, unable to fork for patch.
[05:52] <jblack> For some reason, when baz is calling exec on patch, its not finding it, can't get a process for it, there's not enough memory for patch, etc.
[05:53] <jblack> typically, because you're actually missing patch. Its seen most often on bsd systems that haven't install gdiff/gpatch. Maybe you're missing diff3.
[05:53] <salgado> jblack, no way, he uses the same system I'm using
[05:53] <mpt> mpt@deadsea:~/ubuntu/launchpad$ which patch
[05:53] <mpt> /usr/bin/patch
[05:54] <mpt> jblack: It gets as far as applying 62 revisions out of 80 before it gives up.
[05:55] <mpt> (assuming each "." is one revision)
[05:55] <jblack> salgado: Taht's what that error is. baz either can't fork, or it can't call patch. 
[05:55] <jblack> Why don't you try stracing it, and seeing what the last 20 calls or so were. 
[05:55] <jblack> (well, also, patch could be dying with an error somehow)
[06:01] <mpt> salgado, on anthem it doesn't crash
[06:01] <salgado> mpt, then your problem is lack of memory. that's why I have 1G
[06:02] <jblack> Yeah. Memory could do it. 
[06:02] <mpt> fnord.
[06:02] <mpt> ok, thanks for your time jblack
[06:02] <bradb> "your problem", i.e. baz's problem turned your problem :)
[06:02] <mpt> Has baz reduced memory consumption in the past month?
[06:02] <mpt> This version is from July 9th
[06:03] <bradb> I haven't noticed any improvement
[06:20] <jblack> bradb-bbl: Yeah, its baz's problem that it eats all that memory.
[06:21] <jblack> But a problem in any tool is a problem to the designer as well, as his tool can't do the job he needs.
[06:21] <jblack> mpt: Yeah, its had various memory fixes over the months. 
[06:27] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=spiv]  Change all DOAP to Registry, including urls (patch-2251: morgan.collett@canonical.com)
[06:58] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=spiv]  MaloneSourcePackageBugListing implementation (patch-2252: brad.bollenbach@canonical.com)
[07:58] <mohameth> helo :)
[07:59] <mohameth> somebody who`s working on Gourmet Recipe Manager here?
[08:03] <carlos> mohameth, I'm not working on it, but anyway, what do you need?
[08:06] <mohameth> carlos, just a suggestion
[08:07] <mohameth> but i will tell it by mail
[08:07] <carlos> ok
[08:48] <mpt> bradb: http://wiki.launchpad.canonical.com/MaloneSearchResults
[08:50] <bradb> I'm just preparing to land distro release targeting now. I'll take a closer look in about an hour.
[09:02] <ddaa> mpt: did not have time to look at it (I had three days off)
[09:03] <ddaa> If the amount of nagging I get about it is any measure, I guess that has to be pretty important. I'll start learning about the problem early next week (before finishing my current task).
[09:03] <ddaa> That means tuesday, since monday is a national holiday.
[09:04] <mpt> thanks ddaa
[09:05] <ddaa> hopefully the reviews will start to flow again, the cscvs backlog is already uncomfortably large.
[09:06] <ddaa> and any non-trivial work I have to do involves very large chunks since it's overall a pep8 calamity.
[09:23] <bradb> mpt: for DR targeting, if a release is already targeted, so it's checkbox is disabled, should any part of "[/]  sarge mozilla-firefox (New, Unassigned)" be linkified and if so, what and pointing where?
[09:29] <mpt> bradb: I haven't seen the page we're talking about, but I guess it would probably be linked to all the open bugs targeted to that DR package
[09:31] <madduck> hi dudes.
[09:31] <madduck> just tried to attach a file to https://launchpad.net/malone/bugs/1755/
[09:31] <madduck> and it gave me a system error
[09:31] <bradb> mpt: http://69.70.209.33:8086/distros/debian/sarge/+bugs/1/+target
[09:31] <madduck> i should be reporting a new bug but i am pressed for time.
[09:31] <madduck> so please, if someone could check it out?
[09:31] <bradb> BjornT: ^^
[09:32] <mpt> madduck: If telling someone a bug on IRC is faster than reporting it in Malone, there's something wrong with Malone :-)
[09:32] <madduck> mpt: yeah dude
[09:33] <mpt> (er, something other than the bug you're experiencing in the first place)
[09:33] <bradb> mpt: It's faster to report it in Malone, but human nature jumps to IRC first
[09:33] <bradb> mpt: which is why i'm campaigning for a bot that speaks Malonese
[09:34] <bradb> of course, reporting bugs to a bot increases the likelihood of dups, without some extra special feeping creaturism
[09:34] <mpt> madduck: Is it specific to the file? Can you attach a different file ok?
[09:35] <madduck> mpt: lemme check
[09:35] <mpt> bradb: Are you a pagetest expert?
[09:35] <mpt> :-)
[09:35] <bradb> mpt: sort of
[09:35] <madduck> mpt: yeah, fstab attached fine.
[09:36] <mpt> madduck: Okay, you'll need to make public somehow the file that wouldn't attach, so people can poke it with a stick and work out why Malone doesn't like it
[09:36] <madduck> mpt: it's wget of the link i posted in the comment.
[09:37] <bradb> mpt: right, i'm going to go with what i've got re: DR targeting and you can tweak it later if you want
[09:38] <madduck> mpt: i also checked "patch" on the failing file, not on fstab
[09:39] <mpt> ooo
[09:40] <mpt> worksforme without marking it as a patch
[09:40] <mpt> BjornT: Is there a test for attaching a patch?
[09:40] <bradb> BjornT said there was something important missing from his attachments implementation. maybe this is what he was referring to.
[09:40] <madduck> mpt: i thought so too.
[09:40] <madduck> because the patch is actually malformed.
[09:40] <madduck> rafb.net/paste malforms it.
[09:41] <mpt> bradb: Yes, as I said, link to the list of open bugs for that package
[09:41] <mpt> bradb: And soon I'll have ready a nice package icon
[09:43] <bradb> ok
[09:45] <mpt> bradb: Ok, so in a pagetest instead of doing the print http(...) ... thing, I do output = http(...)
[09:46] <mpt> and then things like
[09:46] <mpt> >>> 'Your subscription to this bounty has been updated' in output
[09:46] <mpt> True
[09:46] <mpt> But they all fail because "TypeError: iterable argument required"
[09:46] <spiv> mpt: do 'foo' in output.getBody()
[09:46] <mpt> I'm guessing I shouldn't be using the word "in", but what should I be using instead?
[09:47] <mpt> ah, thanks spiv
[09:47] <spiv> mpt: the result of http(...) isn't actually a string, it's a richer object.
[09:47] <spiv> It happens to behave like one when you print it, for convenience.
[09:47] <mpt> >>> do 'Your subscription to this bounty has been updated' in output.getBody()
[09:47] <mpt> True
[09:48] <spiv> "do"?
[09:48] <mpt> that's what you said ...
[09:48] <spiv> (There are some examples of this in lib/canonical/launchpad/pagetests/standalone/xx-notfound-head.txt)
[09:48] <mpt> oh, ok
[09:48] <spiv> mpt: English :P
[09:49] <spiv> Plus, I shouldn't be awake ;)
[09:49] <mpt> xx-notfound-head.txt doesn't use "in" at all
[09:51] <spiv> Oh, hmm.  It does use getBody though.
[09:52] <spiv> xx-login-and-join-links.txt and xx-productseries-reset-to-test.txt do.
[09:53] <mpt> great, thanks
[09:53] <BjornT> madduck: by looking at the error logs it looks like you tried to upload an empty file. maybe your web browser couldn't read the contents of the file? anyway, there should be a nice error message there, I'll look into it.
[09:54] <BjornT> mpt: there are tests for attaching patches/non-patches, but not for attaching an empty file
[09:54] <madduck> BjornT: that's weird, but thanks for clearing it up.
[09:54] <madduck> mpt: you get karma. :)
[09:54] <madduck> and wow. there is no such file.
[09:54] <madduck> i am confused now.
[09:55] <madduck> i wgot it, then x-pasted the name to the browser
[09:55] <mpt> Old-fashioned Web browsers that let you enter non-existent paths, ptui
[09:55] <madduck> firefox snapshot :)
[09:55] <madduck> sorry to have stirred things up
[09:56] <BjornT> madduck: it's ok, it's still a bug :) it shouldn't produce a system error
[09:56] <madduck> true
[09:56] <madduck> you guys are using plone2.1, right?
[10:05] <spiv> bradb: FWIW, I'm happy with you merging that branch now (which I see you already did)
[10:05] <spiv> bradb: Don't forget to remove it from PendingReviews though!
[10:06] <bradb> spiv: right, I'll remove it now, thanks
[10:11] <BjornT> bradb: do you have any idea of why the bug notifications get weirdly wrapped?
[10:12] <bradb> spiv: sorry if I was a bit hasty about merging, but I felt like I addressed your points fairly directly and, in the two cases where i wasn't 100% sure, i asked the relevant people for their advice (i.e. SteveA re: constants and mpt re: the "Assigned to me" link)
[10:13] <bradb> BjornT: probably. I just want to finish up this DR release targeting landing before doing anything else. after that, i'll take a look.
[10:15] <spiv> bradb: No, it's fine, you addressed the points.  I'm perfectly happy :)
[10:15] <bradb> cool, thanks
[10:16] <BjornT> bradb: ok, cool. if you feel you don't have time, i could do it, though.
[10:19] <bradb> BjornT: i'll have a 30 sec look to see if i can offer a quick solution
[10:20] <bradb> salgado: you've got mail!
[10:28] <bradb> BjornT: hm, DocWrapper doesn't seem to deal with newlines in paragraphs well
[10:28] <bradb> e.g. even:
[10:28] <bradb> foo
[10:28] <bradb> bar
[10:28] <bradb> doesn't wrap to one line
[10:31] <BjornT> well, i'd expect that to be two lines. the problem seems to be, if you give it something that's already properly wrapped, it will wrap it some more...
[10:32] <bradb> What do you mean by "properly wrapped?"
[10:33] <bradb> Presumably you mean a line already fewer than 80 chars
[10:34] <BjornT> exactly. i just submitted a bug via email, with all lines less than 72 chars. in the notification, some lines had been wrapped anyway.
[10:36] <bradb> Right, do you want to look into this then?
[10:36] <bradb> salgado: around?
[10:37] <BjornT> bradb: sure
[10:37] <bradb> thanks
[10:37] <bradb> BjornT: You might want to start by writing some science fiction in doc/textformatting.txt, where this module is tested
[10:39] <BjornT> bradb: yeah, i was planning to do that.
[10:39] <mpt> Anyone: Where can I find docs or an example on how to use the new "logged in as person Foo" syntax for pagetests?
[10:40] <mpt> It's not in the LaunchpadHackingFAQ or LaunchpadPageTests
[10:41] <spiv> mpt: You mean the still-unmerged feature from  steve.alexander@c.c/launchpad--unittest-authentication--0?
[10:41] <mpt> ah, crap
[10:41] <mpt> probably :-)
[10:41] <spiv> https://chinstrap.ubuntu.com/~jamesh/pending-reviews/steve.alexander@canonical.com/launchpad--unittest-authentication--0/filtered-diff
[10:42] <spiv> I'm not sure why it isn't merged; it's been merge-conditional since 2005-06-01, apparently.
[10:43] <mpt> well, failing that, how do I turn a known sampledata name and password into the magic "Authorization: Basic Zm9vLmJhckBjYW5vbmljYWwuY29tOnRlc3Q="-style string?
[10:44] <bradb> mpt: why do you want to do that instead of using login()?
[10:45] <mpt> bradb: What's login()?
[10:46] <bradb> canonical.launchpad.ftests.login, IIRC
[10:46] <bradb> login(email_address) Just Works
[10:46] <BjornT> mpt: try using: Authorization: Basic test@canonical.com:test
[10:47] <bradb> mpt: btw, is salgado around there?
[10:47] <mpt> Um, I think so
[10:47] <mpt> one moment
[10:48] <mpt> bradb, he's gone out, but reportedly will return soon
[10:48] <bradb> ok, thanks
[10:49] <bradb> n/m what i said about login() btw; i was thinking doctests
[10:49] <bradb> actually, i was /really/ thinking of getting DR targeting landed, but anyway...
[10:49] <mpt> sorry for the interruption :-)
[10:50] <bradb> mpt: is anyone working on google-style list results? if not, i'll start that now (will unfortunately have to put of BjornT's review of the bugtask assignee widget for the moment, i guess)
[10:50] <mpt> thanks BjornT
[10:51] <mpt> bradb: If you mean MaloneSearchResults ;-), I finished the Design section of that spec a couple of hours ago
[10:52] <bradb> yeah, i saw that
[10:52] <mpt> I could do the HTML part of it easily enough
[10:52] <bradb> Rationale -- "The table format is hard to scan..."?
[10:53] <mpt> yes, because stuff is all spaced out
[10:53] <bradb> The table format is *easier* to scan than a google-style listing could ever hope to be. At least things are lined up. :)
[10:53] <mpt> the gap between columns is much wider than the normal gap between words.
[10:53] <bradb> The rationale is that there's too much info to show about a task without exploding off the end of the pages.
[10:54] <BjornT> mpt: sorry, what i said won't work, our copy of zope3 is too old. you can look in some other pagetest, though, and copy the header from there.
[10:55] <mpt> BjornT: I don't know who the authorization is for unless it's explicitly mentioned in the pagetest
[10:55] <mpt> but thanks
[10:55] <BjornT> spiv: i think the reason SteveA's branch isn't merged, is that the functionality already exists upstream
[10:57] <bradb> mpt: so, noone's working on implementing MSR right now, right?
[10:57] <mpt> bradb: Not as far as I know
[10:57] <spiv> BjornT: Hmm.  How hard is it to backport that feature from upstream?
[10:57] <bradb> ok, i'm bazzing my way to an MSR branch right now...
[10:58] <yota> hi
[10:58] <mpt> I need (a) the magic string for someone who's not Foo Bar, and (b) the name of that person
[10:58] <yota> any rosetta admin here ?
[10:59] <mpt> yota: Sorry, they're all sick/asleep at the moment ... Did you have a problem or a suggestion?
[11:00] <yota> problem, I cannot upload a translation file
[11:00] <mpt> What happens when you try?
[11:01] <yota> a message appears on screen and that all
[11:01] <mpt> What does the message say?
[11:02] <yota> oups sorry
[11:02] <yota> thx you for you upload ...
[11:02] <mpt> :-)
[11:02] <mpt> You were expecting to see something else instead, perhaps?
[11:02] <mpt> (Maybe we should be showing something more obvious)
[11:03] <yota> sure, an update :)
[11:03] <bradb> ERROR: Thank you for your upload.
[11:03] <BjornT> spiv: it shouldn't be that hard. i think it's only one extra function, and one modification to another function. although isn't the plan to upgrade our version of zope3 soon?
[11:03] <mpt> bradb, shush
[11:04] <spiv> BjornT: I'm not sure, but this has been an outstanding problem for a long time, and it's frustrating that we both have a branch to solve it, and later upstream solves it, but we aren't using either.
[11:04] <spiv> Who's responsible for updating our zope3?
[11:05] <BjornT> spiv: yeah i know. and i actually think that upstream had this before we even tried to fix it...
[11:08] <bradb> Isn't the intent for us to wait to upgrade to 3.1 when it's officially released?
[11:10] <mpt> yota: Does the message say something about the import process taking a while?
[11:11] <BjornT> well, it'd be best to upgrade before that, to ensure that the functionality we use still is supported
[11:11] <mpt> yota: Ah, you get an orange box, which looks like an error message
[11:12] <yota> mpt: message say that translation content will appear  in few minutes. After few uploads, no update
[11:12] <SteveA> hi
[11:13] <mpt> bradb: Bad news
[11:13] <bradb> mpt: kiko's already working on it?
[11:14] <bradb> or salgado's not coming back?
[11:14] <mpt> bradb: salgado's back from the doctor, but his eyes are no-worky so he can't read anything you say
[11:14] <bradb> ouch! :/
[11:14] <mpt> and they'll be like that for the next day or two
[11:14] <mpt> So he says to e-mail him
[11:14] <mpt> (he managed to find Ubuntu's "Log Out" menu item)
[11:15] <bradb> poor guy
[11:19] <spiv> SteveA: Btw, the other place I regularly see Ian Bicking's blog entries is linked from Daily Python-URL (http://www.pythonware.com/daily/)
[11:29] <SteveA> mpt: if salgado is there, can you tell him that i reviewed his smallfixes--4 branch.  it's good.  a couple of small changes, and he'll be good to merge it.
[11:33] <mpt> SteveA: He can't read code and he's just gone home for the weekend
[11:33] <SteveA> okay
[11:33] <SteveA> jblack: ping
[11:39] <jblack> pong
[11:40] <jblack> steva: pong
[11:42] <mpt> AHA!!!
[11:42] <SteveA> jblack: i guess i didn't understand what i was asking for when we talked about the bzr demo tarball.
[11:43] <SteveA> i've had to bzr init and bzr add in the various branches to get them to work
[11:43] <jblack> Oh, no, that's my fault. 
[11:43] <SteveA> and of course, i'd forgotten there's no bzr switch yet
[11:43] <jblack> I forgot to init them.
[11:43] <SteveA> so, a multi-branch demo doesn't make much sense
[11:43] <jblack> Yeah. bzr isn't usable in any real sense.
[11:43] <SteveA> i think your instructions are a good start
[11:44] <SteveA> in that they show how easy it is to branch, and commit and diff
[11:44] <jblack> Its about good enough for local stuff and to play with some of the early merging stuff, but thats about it. :( 
[11:44] <jblack> I'll put up a better 8/12 with the tools initted. sorry for the botch
[11:53] <SteveA> no woorries.  please go through the instructions from a fresh download to check they make sense and work :-)
[11:56] <jblack> Yeah. I did with 8-11. The changes to 8-12 were so minor, that I didn't check. 
[11:57] <jblack> I'm walking through them now with 8-12-2