[12:18] hey mpt === kiko yawns [12:19] hello kiko [12:20] how's it going matt [12:20] I just forwarded you some mail [12:22] Good [12:22] though I'm uncovering many little lists of things that need to be implemented for 1.0 [12:22] reporting them all as bugs [12:22] yeah, that's expected, I guess [12:22] we will fix some, and push off some and fix them post 1.0 [12:23] Well, they leave holes or XXXs on prominent pages [12:23] those ones we won't push off I assume :) [12:23] Anyway, I'll post a list of them tonight [12:23] since I'm on leave from tomorrow [12:24] Oh, awesome, we can drop displayname? [12:24] "Ubuntu" vs. "Ubuntu Linux" is an interesting example, because Ubuntu branding has been de-emphasizing "Linux" for quite a while === shawn___ [n=shawn@208.68.64.75] has joined #launchpad [12:26] Actually in my survey, .displayname was appropriate much more often than .title was === jml [n=jml@220-253-134-47.TAS.netspace.net.au] has joined #launchpad [12:27] That's probably because "Title:" comes after "Display Name:" in the new product form, so people think "huh? what on earth is this for?", whereas if they were around the other way they'd think exactly the same about Display Name [12:28] What do you think, kiko? [12:29] I think I agree, but not having display name means certain project names would look bad [12:29] GNOME for instance [12:29] KDE [12:29] KDEPim [12:29] etc [12:29] KDE versus Kde [12:29] maybe you're suggesting having name /always/ be auto-generated [12:29] based on displayname [12:30] so we'd have "Display name" and "Title", and name auto-gend [12:30] I'm suggesting dropping Title, and using Display Name everywhere we currently use Title [12:30] that's another option [12:30] maybe we could do both [12:31] As for Name, I agree with auto-generating it [12:31] but those are still confusing names [12:32] so my blue-sky suggestion would be [12:32] In my ideal world, Name -> Launchpad ID, Display Name -> Name [12:32] Name: (currnt Displayname) [12:32] ID: ... [12:32] wow [12:32] snap! [12:32] that was some synchonicity there [12:32] how very special [12:32] and ID gets auto-suggested by JavaScript when you enter the Name [12:32] or even auto-gend and you can change it later if you want to be cheap like me [12:33] yeah [12:33] Should this be a RegistrySimplifications spec? :-) [12:33] I wonder whether you want to fight this battle now [12:33] No [12:33] it's a bit of a bad time to invest in it with so much crap for 1.0 [12:33] indeed [12:33] even if we get approval it will sit untouched for months [12:33] This problem is #6 on my list, iirc [12:33] so let's revisit this when your list is shorter. [12:34] ok [12:34] mpt, btw, consider sharing your list with matt. r., who I've charged with assembling a top-user-visible list of issues across all data sources we have [12:34] and having a launchpad meeting slot for that [12:34] this will be slightly different but may overlap with criticals and oopses [12:34] ah, #5 [12:34] "Too much input required" [12:35] that's pretty vague. [12:35] Specifics on the wiki if you want to read it :-) [12:36] kiko, what do you mean by "across all data sources"? [12:36] well [12:36] launchpad-users [12:37] tickets [12:37] bugs [12:37] oh, right [12:37] the ether [12:37] blogsphere [12:37] ubuntu mailing lists [12:37] So, pretty much the same as my DesignProblems list [12:37] seances [12:37] I think your designproblems list is more focused on design [12:37] true [12:37] where an inclusive list would also point out functional issues that go beyond design [12:37] I'm not saying design issues are not important [12:37] specific missing features, for example [12:38] or features that are broken or limited, etc. [12:38] Sign me up for the seances [12:38] have you ever had one? [12:38] no [12:38] "You must have access to the e-mail address registered under the duplicated account." [12:38] hmmmmm [12:38] What's "the duplicated account"? [12:38] Is that the one you're wanting to keep, or the other one? [12:38] the text there and in the email notification is VERY wonky [12:39] like a disaster in the making [12:39] we could fix that [12:39] And those instructions are on the wrong page [12:39] but matsubara's bug would still be interesting [12:39] matsubara's bug? [12:41] Not bug 43741? [12:41] Malone bug 43741 in launchpad "Hey! That account/product/project/distribution belongs to me!" [Medium,Unconfirmed] http://launchpad.net/bugs/43741 [12:41] mpt, the security bug he reported today [12:42] oh [12:42] nasty [12:42] night all [12:42] mpt, if you want to [trivial] some fixes to the text there bmg [12:43] night mark [12:43] goodnight mark [12:43] kikomatic, you're SO right about that blog post. best blog i've ever seen [12:43] heh [12:44] sabdfl, it probably took him a working day to finish it [12:44] and then another one to deal with the replies and fallout [12:44] it may not have been worth it to him, but damn, it was worth it for us :-) [12:44] as long as the final BOSS level involves bzr victory :-) [12:46] kiko, often the reason people want to merge an account is that they don't have access to the old account's e-mail address [12:46] mpt, that's an admin merge, though -- a separate use case [12:46] Can you think of any way to allow that without LP admin intervention? [12:46] I can't really. there is no way to tell the guy is who he says he was. [12:46] I do google researching to confirm usually [12:46] I was thinking maybe mail the address of the old account over a series of months, saying "if you don't respond, your account will be merged into X" [12:47] but maybe that's too dangerous [12:47] and pretty slow if you want to claim that! [12:47] yeah [12:47] and I guess any wait short enough to be tolerable would be too short for mdz to go on holiday [12:48] oh well [12:48] YSWIM [12:48] I don't think admin merge is so bad [12:48] I am not sure if all merges should be admin merges, but webstats should tell us that. === dominussuus [n=borden@206-248-177-83.dsl.teksavvy.com] has joined #launchpad [12:50] New bug: #74578 in launchpad "Account merging instructions are unclear" [Undecided,Unconfirmed] http://launchpad.net/bugs/74578 [12:51] is there a launchpad.net or wiki.ubuntu.com admin in the room? === WaterSevenUb [n=WaterSev@c-65-96-188-198.hsd1.ma.comcast.net] has joined #launchpad [12:52] dominussuus, yes, kiko is one of the former [12:52] what's up dominussuus [12:53] hey kiko - I'm a moron and I think I disabled wiki access through my launchpad account [12:53] dominussuus, that's okay. file a ticket and I'll ask an admin to fix it. [12:53] erm, ticket? [12:54] the real morons here are me and spiv who have been unable to patch that option out of moin. [12:54] dominussuus, launchpad.net/products/launchpad/+tickets [12:54] (bug 6283) [12:54] Malone bug 6283 in launchpad "Disabling the account thru Wiki causes more harm than good. That option should be nuked." [Medium,Confirmed] http://launchpad.net/bugs/6283 [12:54] yeah, I didn't like my wiki name and I thought I could disable my account and open a new one [12:54] yeah, I read that one [12:54] dominussuus, heh. bet that let to a surprise ;-) [12:55] anyway, file the ticket and I'll make sure it gets done tomorrow [12:55] I need to crash shortly [12:55] yeah, and then I was like "hey, I can just change it through launchpad... oh, wait..." [12:56] goodnight kiko [12:56] night night [12:57] thanks kiko === dominussuus [n=borden@206-248-177-83.dsl.teksavvy.com] has left #launchpad [] === belito [n=user@201.240.229.80] has joined #launchpad === Ng [n=cmsj@mairukipa.tenshu.net] has joined #launchpad === Fanch [n=fanch@fanfan.staff.proxad.net] has joined #launchpad === crimsun [n=crimsun@dargo.trilug.org] has joined #launchpad === bubulle [n=bubulle@81.56.227.253] has joined #launchpad === jamesh [n=james@203-59-208-48.dyn.iinet.net.au] has joined #launchpad === Spads [n=spacehob@host-87-74-54-249.bulldogdsl.com] has joined #launchpad === mdke [n=matt@85-210-195-200.dsl.pipex.com] has joined #launchpad === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad === JanC [n=janc@lugwv/member/JanC] has joined #launchpad === daq4th [n=darkness@netstation-005.cafe.zseries.org] has joined #launchpad === stgraber [i=stgraber@server.lan.stgraber.org] has joined #launchpad === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #launchpad === [PUPPETS] Gonzo [i=gonzo@80.69.47.16] has joined #launchpad === SteveA [n=steve@costello.z3u.com] has joined #launchpad === outime go to sleep === rrittenhouse [n=tad@cpe-76-188-35-66.neo.res.rr.com] has joined #launchpad === _thumper_ [n=tim@166-179-19-152.jamamobile.co.nz] has joined #launchpad [01:32] that's odd [01:32] <_thumper_> I'll bite, what's odd? [01:33] I'm odd, there's only one of me, and one's an odd number [01:33] jamesh, why isn't /people/whoever/+edit using the new form layout? [01:33] Does it apply only to GeneralForm? [01:33] yeah. [01:33] actually, LaunchpadFormView [01:34] ok [01:34] the older forms are being upgraded slowly [01:34] We should have countdowns for things like that :-) [01:34] "Only 38 non-LaunchpadFormView forms left!" [01:36] some of the layout details you speced for the new form layout made it a bit difficult to implement for all forms [01:36] could possibly backport the layout to some of the forms (e.g. to GeneralFormView ones) [01:37] but it'd be good to get all the forms moved over to the new infrastructure [01:40] yes [01:40] Meanwhile, the position of the submit buttons bothers me [01:41] when a form ends in a bunch of single-line stuff, the submit button should be underneath them [01:41] but when it ends in a multi-line field, that probably would look wrong === belito [n=user@201.240.3.186] has joined #launchpad === belito` [n=user@201.240.3.186] has joined #launchpad [02:12] <_thumper_> ping jamesh [02:13] <_thumper_> jamesh: bzr blame shows you as adding in the landing target for branches, what's the status of this? [02:13] <_thumper_> is it just at the object level atm, or is there more somewhere? [02:18] _thumper_: I think ddaa added that db column [02:19] _thumper_: I don't think it is currently exposed anywhere in the UI [02:19] <_thumper_> hmm, bzr blame doesn't seem as consistent as svn blame [02:19] <_thumper_> jamesh: I didn't think I had seen it exposed yet [02:19] <_thumper_> but just checking [02:20] <_thumper_> we'd been talking about landing targets for some time [02:20] it is possible that I last touched the lines in the file you checked [02:20] <_thumper_> and here in lies one of the problems with blame [02:20] <_thumper_> oh well [02:21] there are a bunch of columns that were added for a branch review feature that hasn't been implemented yet [02:21] landingtarget is meant to be the branch that the developer wants their branch merged to [02:22] I remember seeing some more recent specs that seemed to decouple the review stuff into a separate table to allow multiple landing targets for a branch [02:22] but I don't know much more about that. [02:24] <_thumper_> jamesh, thanks for that [02:24] <_thumper_> I've just started a new branch off rocketfuel and I've hit a TypeError [02:25] <_thumper_> this is the first time I have tried to run things since upgrading to edgy [02:25] <_thumper_> and I'm not sure if it is something I have just changed or not [02:25] <_thumper_> I have just expanded a vocabulary for branch status, but that's all [02:26] <_thumper_> I didn't notice anything on the mailing list about it, but I could have missed it [02:26] could you paste the traceback at https://sodium.ubuntu.com/~andrew/paste/ ? [02:26] <_thumper_> ok [02:27] <_thumper_> jamesh: https://devpad.canonical.com/~andrew/paste/filehpe0pU.html [02:28] okay [02:28] you'll need to update the zope tree under sourcecode/ [02:28] The Python in edgy includes a security fix to the CGI module that broke zope [02:29] we've since pulled the upstream zope fix for this issue into our tree [02:30] <_thumper_> ok, pulling new bits === belito` [n=user@201.240.245.234] has joined #launchpad [02:31] <_thumper_> and trying again with --overwrite :) [02:32] the basic problem is that readline() has an infrequently used optional argument [02:34] <_thumper_> oh poos: now I'm getting "IOError: [Errno 2] No such file or directory: '/home/tim/src/lp/working/sourcecode/zope/src/zope/publisher/configure.zcml'" on make run [02:34] <_thumper_> where did it go? [02:34] <_thumper_> all I did was bzr pull --overwrite [02:34] <_thumper_> from the sourcecode/zope dir [02:34] what do you have in sourcecode/zope now? [02:35] what branch did it pull from? [02:35] looks like rocketfuelbuilt has a bad parent branch set (chinstrap.ubuntu.com) [02:37] <_thumper_> https://devpad.canonical.com/~andrew/paste/filefEOVDR.html [02:37] should be devpad.canonical.com [02:37] are you still using that setup-lp-sourcecode-dir script of mine? [02:37] <_thumper_> yep [02:38] <_thumper_> should I just re run that? [02:38] <_thumper_> or does it need editing first? [02:38] if so, then just update your rocketfuel-built tree, then run setup-lp-sourcecode-dir in your tree again [02:38] that should update your tree from the local copy of rocketfuel-built [02:39] <_thumper_> ok, I'll try that [02:39] (we need to make these things easier ... [02:43] <_thumper_> hang on, my ~/src/rocketfuel-built is an exploded tar ball from Steve from the start of Oct [02:50] <_thumper_> I think I have it... [02:53] I use the following command to pull it down from devpad: rsync -azP --delete-after devpad.canonical.com:/code/rocketfuel-built/launchpad/ [02:53] ~/src/rocketfuel-built/ [02:55] <_thumper_> what benefit does it give you having a local copy? [02:57] I can set up new local trees without hitting the network [02:57] <_thumper_> hmm... ok [02:57] probably also habit [02:59] <_thumper_> I'll try that now... [03:01] <_thumper_> jamesh: how much network traffic does that make? [03:01] <_thumper_> I pay by the MB over a certain amount right now [03:01] _thumper_: rsync is a differential protocol, so it depends on how different your local copy is to the remote one [03:02] checksums for all the blocks get passed in one direction, and then matched against the files at the other end, and the missing data gets passed in the other direction [03:03] <_thumper_> given that it is over 8 weeks out of date, I think much of it will be [03:03] <_thumper_> and I just checked the size 571Meg [03:03] <_thumper_> so, it can wait till I get to a wifi spot :) [03:04] it'll transfer a lot less than 500MB :) [03:05] I am not sure how much 8 weeks worth would be though [03:05] <_thumper_> it can wait [03:05] probably not a huge amount though [03:05] <_thumper_> my working branch is working again [03:05] <_thumper_> I just did a --remeber --overwrite pointing to the correct place [03:05] <_thumper_> and got the right number of revisions [03:06] <_thumper_> so happy enough for now [03:07] rsync and "bzr pull" end up transmitting similar amounts of information (same order of magnitude) === shawn___ [n=shawn@mothership.metainterfaces.com] has joined #launchpad === stub [n=stub@ppp-58.8.6.154.revip2.asianet.co.th] has joined #launchpad === jml [n=jml@220-253-134-47.TAS.netspace.net.au] has joined #launchpad [04:26] <_thumper_> do we have a magic widget for rendering a drop down list given a list and an active item? === mdz [n=mdz@cpe-76-173-8-128.socal.res.rr.com] has joined #launchpad === jml [n=jml@59.167.203.44] has joined #launchpad [04:33] _thumper_: A Choice field in a schema is rendered the way you describe by the form machinery. [04:33] But you need a Vocabulary rather than a list [04:34] <_thumper_> stub, it is for a general selection rather than an attribute for a db object [04:34] <_thumper_> I'm looking at filtering branches [04:34] <_thumper_> and providing a way to do that on the branch listing pages [04:34] You can use the form machinery without db objects. [04:34] <_thumper_> so merged and abandoned don't appear by default [04:34] <_thumper_> I was just stepping through the pt code and getting to the underlying form machinery [04:35] <_thumper_> I see that in some of the views there are custom_widget attributes [04:35] <_thumper_> I guess I want to use something like that [04:37] Could be. I haven't done any form stuff for ages and it has changed a few times since then :) [04:38] Maybe you just need to set the default or current value on the widget/field/whatever before rendering [04:48] _thumper_: you can create a vocabulary pretty easily with a dbschema enumeration [04:49] that's what the bug search/listing page uses [04:49] define the enumeration in lib/canonical/lp/dbschema.py [04:50] <_thumper_> I've had a good look through dbschema.py [04:50] declare the vocabulary in lib/canonical/launchpad/vocabularies/dbschema.py [04:50] <_thumper_> as I have been playing with the lifecycle status [04:50] register the vocabulary in lib/canonical/launchpad/vocabularies/configure.zcml [04:50] <_thumper_> ok, I'll look at those two now [04:51] you'd need a schema for the form (which is just an interface) [04:51] we put them under lib/canonical/launchpad/interfaces/ (even for ones that are purely browser code related) [04:52] create a LaunchpadFormView using that schema, and it'll create the widgets for you based on the fields in the schema === mpt [n=mpt@121-72-128-96.dsl.telstraclear.net] has joined #launchpad === shawn___ [n=shawn@adsl-70-231-253-100.dsl.snfc21.sbcglobal.net] has joined #launchpad === Kylekf [n=Kyle@gw3.eb.net.my] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [07:58] morning! === mhb_ [n=mhb@64.73.broadband3.iol.cz] has joined #launchpad [08:06] hello SteveA! [08:07] SteveA, what's happening with /ui-one-zero? Is it still auto-merging from /devel? [08:09] mpt: it's not auto-merging [08:10] what needs to happen next is that I do a merge from the production revision (done), resolve conflicts (not done), merge your stuff, then push that [08:16] SteveA, ok, it's just that I saw yesterday flacoste implemented one of the missing things for software Answers pages [08:18] SteveA, next, any progress on getting the brilliant server running again? [08:19] you just threw out a fact about flacoste implementing something, but you didn't explain how it is relevant to the ui-one-zero branch. please explain what you're thinking. [08:19] sorry, one of the missing things for *the 1.0 design* for software Answers pages [08:19] mpt: do you have a list of things that need to be implemented for the Bugs 1.0 UI? [08:19] just giving facts isn't all that useful unless you also explain how those things fit into your plans or intentions [08:20] BjornT, I'm reporting bugs as I come across them, with milestone 1.0, and linking them to the relevant spec [08:20] one moment [08:20] mpt: ok, for the 1.0 design... but why is that important for the beta server or the 1.0 branch? [08:20] SteveA, the sooner it's in a mergable branch, the sooner I can incorporate it into the page. [08:21] we're now tracking production. so, that stuff needs to get into a production rollout [08:22] from next week or so, we'll be asking people to work on the ui branch for all new code, unless it is database code [08:22] BjornT, for bug tracking so far, bug 73871, bug 74461, bug 73872 [08:22] Bug 73871 on http://launchpad.net/bugs/73871 is private [08:22] Bug 74461 on http://launchpad.net/bugs/74461 is private [08:22] Bug 73872 on http://launchpad.net/bugs/73872 is private [08:22] I was planning on posting a list of all these bugs later this evening [08:24] mpt: ok, thanks. i think i'm going to have time to start working on them today. [08:31] great, thanks BjornT [08:31] mpt: seen stub around today? [08:32] SteveA, no [08:32] ok. so, we should find out from him when he plans to do the next roll-out, and ensure that UI support things you need are in that [08:36] SteveA, by "tracking production" do you mean that /ui-one-zero is configured to auto-merge from production instead of /devel? [08:37] mpt: not quite. [08:37] ui-one-zero is not automatically merging from anywhere [08:37] I'm manually merging it [08:38] when we have our processes smoothed out, with people working on the one-zero branch for as much as possible, then we'll turn on auto-merging again [08:38] ok, so what is the importance of ensuring that code I'm using has been rolled out? [08:38] what I mean by "tracking production" is that the only work from devel we should merge into ui-one-zero is that work that has been rolled out to production [08:39] so, if flacoste has done work on devel, and you want to use it on ui-one-zero, then we need to get that work rolled out to production [08:39] so we can merge it onto ui-one-zero [08:39] To reduce churn, or to get better testing, or what? [08:40] to ensure that the beta server will work against the production database, and work alongside the current UI in production [08:40] not sure what "churn" means [08:43] churn as in number of sessions of merge conflict resolution (e.g. one per fortnight vs. one or two per week) === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === _thumper_ [n=tim@166-179-28-56.jamamobile.co.nz] has joined #launchpad === danilos [n=danilo@adsl-233-130.eunet.yu] has joined #launchpad === tim_ [n=tim@166-179-30-131.jamamobile.co.nz] has joined #launchpad [09:18] <_thumper_> ping jamesh [09:18] _thumper_: pong [09:19] <_thumper_> jamesh: do you think that a non-db vocabulary should go in the lp/dbschema.py file? [09:19] <_thumper_> I don't [09:20] _thumper_: this has come up before. There probably is a better place for them, but we haven't created it yet [09:20] so for now we've been putting those enumerations in dbschema.py [09:20] <_thumper_> I think perhaps a different file in the vocabulary directory [09:20] <_thumper_> hmm... [09:20] would probably be worth bringing up on the mailing list [09:20] <_thumper_> yeah, [09:21] <_thumper_> I think I will [09:21] if we do create a new location, all the enumerations not used for database columns should be moved out at the same time though [09:21] <_thumper_> yep [09:21] <_thumper_> what I think I'll do is to put it with the others for now [09:21] <_thumper_> and write something up === malcc [n=malcolm@host86-135-237-55.range86-135.btcentralplus.com] has joined #launchpad === twb [n=twb@155.143.208.237] has joined #launchpad === matthewrevell [n=matthew@82-47-122-36.cable.ubr05.wolv.blueyonder.co.uk] has joined #launchpad [09:25] I'm trying to register with ubuntu. [09:26] I got the "Finish your Launchpad registration" OK. [09:26] I browsed to the URL it gave with emacs-w3m, and tried to enter dat into the form a couple of times. It kept taking me back to the same page. [09:27] Looking at the raw HTML suggests that it requires javascript, so I tried again using Firefox. [09:27] It gave me an "OOPS-340A337" error. [09:27] https://devpad.canonical.com/~jamesh/oops.cgi/340A337 [09:27] twb: Sorry you've had a problem. Thanks for reporting the error. [09:28] Unreported issues don't get fixed :-) [09:28] twb: if you wait 5 minutes, I can check what the problem is [09:28] twb: javascript shouldn't be required, but in order to stay logged in, your browser needs to support cookies. maybe emacs-w3m doesn't support cookies, or reject cookies from Launchpad? [09:28] Emacs-w3m supports cookies, and I have them enabled for all sites. [09:28] the error reports are copied from the app server by a cron job [09:29] jamesh: righto. [09:30] twb: i think that w3m rejects the kind of cookies that we use, though. my guess that the registration process actually succeeded. while waiting for the oops report to get copied, you could try using firefox to login, using the email and password you gave. === tim_ [n=tim@166-179-31-134.jamamobile.co.nz] has joined #launchpad [09:31] https://launchpad.net/products/launchpad/+bug/59510 [09:31] Malone bug 59510 in launchpad "Can't log in with w3m due to bad cookies" [Undecided,Unconfirmed] [09:31] BjornT: ah. [09:31] So launchpad.net won't work AT ALL with emacs-w3m? [09:32] twb: well, it will work, but you can't log in, so you can only use launchpad.net anonymously using emacs-w3m === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [09:33] Owie. [09:33] I can't log in with firefox. === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [09:35] twb: what happens when you try to log in with firefox? the same as for emacs-w3m, or do you get 'incorrect password'? [09:35] BjornT: the latter. [09:35] http://twb.ath.cx/tmp/tmp.png <-- trying to finish registration [09:36] http://twb.ath.cx/tmp/tmp2.png <-- trying to log in anyway [09:37] twb: hmm, ok. i see that you try to finish the registration on https://bugs.launchpad.net/token/...., try removing the 'bugs' part from the url, i.e. http://launchpad.net/token/... [09:38] fwiw, bugs. is the one the email gave me. [09:39] ok, that might be a bug. [09:39] Different error this time: OOPS-340a349 [09:39] https://devpad.canonical.com/~jamesh/oops.cgi/340a349 [09:44] twb: if you don't mind there are one or two things you could try. first, go to https://launchpad.net/+login and try registering again, using only firefox this time. [09:45] OK. === eric-the-viking [n=tim@166-179-26-85.jamamobile.co.nz] has joined #launchpad [09:52] eric-the-viking: tim p? === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [09:57] BjornT: reading the RFC, we'd probably need to change https://launchpad.net URLs to https://www.launchpad.net or similar in order to share the session with blueprints.launchpad.net, etc _and_ work with w3m === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === WebMaven [n=webmaven@ip72-193-220-34.lv.lv.cox.net] has joined #launchpad [09:58] it seems the spec lets you share a cookie between "foo.example.com" and "bar.example.com", but not "example.com" and "foo.example.com" [10:00] jamesh: so, is FF being lax in its interpretation of the spec? [10:00] jamesh: could be, i haven't looked into it. maybe you could add that to the bug report? [10:00] SteveA: that would appear to be the case [10:01] SteveA: the spec says that the domain parameter specified in a Set-Cookie header must start with a dot, and have at least one embedded dot [10:01] but ".launchpad.net" won't match "launchpad.net" [10:02] SteveA: well, FF and most other browser. w3m is the only browser i know that has a problem with cookies from LP [10:02] that means the RFC doesn't reflect common practice [10:02] iirc that was one of the first things changed in Safari once it went beta [10:03] changing the cookie handling so that it matched the Web instead of matching the spec [10:03] I don't know if this is worth addressing in Launchpad [10:03] There are other problems w3m has with Launchpad [10:04] such as the translation completion charts being stretched one-bar-per-screenful === mpt babbles away not-too-usefully [10:06] of course, the RFC doesn't seem to disallow me setting a cookie with "Domain=.com.au", which is a much bigger potential security problem compared to disallowing "Domain=launchpad.net" [10:15] actually, we could probably be RFC-compliant if we did the following: [10:15] (a) made sure the Set-Cookie header was only sent from a page on https://launchpad.net [10:16] (b) set two cookies: one without a domain attribute (which will only match launchpad.net), and a second one with Domain=.launchpad.net [10:16] and use the same value [10:17] That's interesting. I also have problems using emacs-w3m with gmail, but not with other cookie-using sites. [10:17] Would it be easier to just make launchpad.net always redirect to www.launchpad.net? [10:19] actually, that would fail, because ".launchpad.net does not domain-match "launchpad.net", so the second cookie would get rejected [10:19] it would need to be set by a *.launchpad.net request [10:20] twb: or fix emacs-w3m to handle the web as it exists rather than how it is documented :) [10:20] That is immorral. [10:20] *immoral [10:20] It merely encourages web "designers" to disregard standards. [10:20] FSVO standard = rfc [10:20] yep. [10:21] but if the standard says one thing and the browsers that 99% of users use do something else, is it really a standard? [10:21] You want to do what the majority thinks is a good idea? [10:21] I am saying that standards that don't match reality are problematic. [10:22] So we have to fight back! [10:25] Pardon the ideology. [10:26] Oh, twb, you are going to hate HTML 5 ;-) === twb is from the `HTML is for documents, not programs. If you want programs, bloody well use NeWS' camp :-) [10:27] heh [10:27] My suspicion is confirmed [10:27] rather than use a cookie shared across domains, we could instead do an openid style thing and bounce browsers through a login domain [10:27] so, I suspect we can ignore this for now, and look again once we have open id running [10:29] BjornT: OK, I did the WHOOOOLE thing via firefox, and I registered successfully. [10:30] twb: great! sorry for the trouble. i'll notify the person responsible for the registration code, to take a closer look at it and see what went wrong. === sabdf1 [n=sabdfl@217.205.109.249] has joined #launchpad [10:34] Do any of you guys speak Spanish? I'd like to reply to a Spanish language email on the -users ML [10:34] Solo un poco. [10:35] twb: Me too. I learnt it at school then stuck to French :) [10:37] twb: Someone has signed up to the launchpad-users mailing list and says that they don't understand why they keep getting emails about Launchpad. [10:38] Sounds like you're already doing better than I can. [10:38] Ideally, I'd like to offer them an explanation of what the list is for and how they can unsubscribe, should they choose to. [10:38] matthewrevell, perhaps someone in #ubuntu-es could help [10:38] Perhaps I'll just have to start the email with, "No hablo Espanol, lo siento" :) [10:38] mpt: Yeah, I'll try that, thanks. [10:39] There's a couple of people in #emacs-es who might be bored enough to help you. [10:39] twb: Thanks. [10:40] matthewrevell: Google can give you a machine translation English -> Spanish [10:41] Check out libtranslate-bin [10:41] I wonder how many people subscribe to launchpad-users from the link on the oops page [10:41] jamesh: Yeah, I'm always a little wary about using automated translation, though. [10:41] jamesh: I'll try to find the Spanish to ask that :) [10:41] matthewrevell: I've only done it a few times, giving both what I wrote and the machine translation, and make a note that it is a machine translation. [10:42] jamesh: I'll keep that as my back-up plan :) [11:05] jamesh: Back-up plan engaged :) [11:09] Ahead, warp factor foor. [11:09] *foo === ddaa is awed by matthewrevell's babelfish-fu [11:25] ddaa: Ha :) [11:26] ddaa: It required some fiddling. [11:26] I think we should definitely make launchpad-users harder to find. [11:27] ddaa: Why do you think so many people sign up to launchpad-users in error? [11:27] no idea [11:27] but obviously the mailing list is too visible, somewhere [11:27] matthewrevell: my guess is that they get confused being asked to get a launchpad account to access shipit [11:27] do you need to have some lost users captured and their brain dissected? [11:27] it is on the Launchpad.net OOPS page [11:28] ddaa: Either that or it's visible in the wrong way. i.e. we're not sufficiently clear about the list's purpose. [11:28] so I wonder if they are hitting that? [11:28] matthewrevell: and then find the launchpad-users address on an oops message. often it is people who don't read english well [11:28] and are very focused on getting free CDs [11:28] what SteveA says [11:29] there's a very clear pattern [11:29] if we localise any LP pages, the OOPS page would be a good candidate :) [11:29] I notice the Mailman list signup page has a big, "This list is not for free CDs" message. But the Mailman signup page says a *lot* of things, so even something flagged up to give it extra prominence can be easily invisible === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad [11:30] a problem doubled if you're not so good with English< i'd imagine [11:30] GIVE FREE CD THANK YOU [11:30] If no one objects, I'd like to look at how we can reduce the number of mistaken signups to the list. [11:31] YOU'D BE HARD PRESSED TO DIND SOMEONE OBJECTING, CAN I HAVE FREE CD? [11:31] :-D [11:32] it might be interesting to look at how many of the people requesting cds through launchpad-users appear in OOPS reports related to bug 44919 [11:32] Malone bug 44919 in launchpad "UnicodeDecodeError while registering a new account." [High,Confirmed] http://launchpad.net/bugs/44919 [11:33] BjornT: Thanks. I'll read that. [11:35] matthewrevell: you could ask matsubara to get you all the relevant OOPS reports. [11:36] BjornT: Is that something only matsubara can do, or can I do it myself? [11:40] matthewrevell: you might be able to do it yourself, but for example i don't even know where the OOPS report are stored. it's also not completely trivial to extract the relevant reports, since there's no clear linkage. you have to look at URL, exception, and traceback. [11:40] BjornT: Ah right. [11:41] Okay, I'll speak to matsubara :) [11:43] we can easily find oops reports containing a UnicodeDecodeError [11:43] they are archived on the machine devpad [11:43] so, a find and grep would do that [11:44] the production OOPS reports are in /srv/launchpad.net-logs/production/ [11:44] morning === sivang [i=sivan@ubuntu/member/sivang] has joined #launchpad [11:45] hi [11:45] Thanks. I'm still waiting on devpad access. [11:45] why can't I file bugs on the source package from here https://launchpad.net/distros/ubuntu/+source/ifupdown/0.6.8ubuntu1 ? [11:46] IMHO it would be very intuitive to allow me to file bugs after I've searched for a source pkg [11:47] matthewrevell: you could also look at https://devpad.canonical.com/~matsubara/oops-summaries/ [11:47] BjornT: Thanks. [11:47] matthewrevell: it's the production-* that you want to look at. [11:48] and even from here it could be nice to have a filebug link [11:48] https://launchpad.net/distros/ubuntu/feisty/+package/ifupdown [11:50] sivang: yes, there should at least be a link to the relevant bugs for that package, from where you'd be able to file a bug. [11:51] sivang: those pages haven't received much attention. could you please file a bug about both these issues? [11:52] jordi: ping === niemeyer [n=niemeyer@200.138.132.233] has joined #launchpad [11:57] BjornT: what's the product ? launchpad or malone? [11:59] Does launcpad.net/people/foo require javascript? [11:59] *Does launchpad.net/people/foo require javascript? [12:00] sivang: hmm, not sure :) file it on launchpad, then === SteveA --> lunch [12:00] twb: none of the pages should require javascript -- simply be enhanced by it [12:00] In Galeon, I tried browsing to it and *then* logging in, and I don't get all the preference pane stuff that I get in firefox. [12:00] Okay, this is weird. [12:01] caching issues, maybe? [12:01] When I halve the window size, the menu stuff shows up. [12:01] So it sounds like CSS on + images off might be the problem. [12:02] http://twb.ath.cx/tmp/1.png [12:02] http://twb.ath.cx/tmp/2.png [12:03] If I pick View > Styles > None, I see all the options. === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:09] jamesh: do you think you could review my branch that's in your queue any time soon? it's been unreviewed for a week already now. [12:15]