[00:27] <LPCIBot> Project devel build (330): STILL FAILING in 3 hr 32 min: https://hudson.wedontsleep.org/job/devel/330/
[00:39] <wgrant> sinzui: Around?
[01:16] <mbrigdan> So, this is probably some dumb error on my part, but when I do "make schema", it spits out a giant python traceback that ends with "ImportError: cannot import name boolean". What should I do?
[01:17] <wgrant> mbrigdan: That's rather odd. Could you pastebin the full traceback?
[01:19] <mbrigdan> sure thing, just give me a second
[01:19] <mbrigdan> Here you go: http://pastebin.com/kpQi2Gsi
[01:24] <wgrant> mbrigdan: Where did /usr/lib/python2.6/dist-packages/_xmlplus come from?
[01:25] <mbrigdan> I'm pretty sure i've never seen that before today. Strange
[01:26] <mbrigdan> huh, google says it may be related to python-xml, which was removed at some point
[01:27] <mbrigdan> And I still have it installed. That might be a problem
[01:29] <mbrigdan> Removed it, and now it looks like its working. Cool
[01:31] <wgrant> Excellent.
[01:45] <mbrigdan> ugh, sorry to keep bothering you, but now make run gives me a rather smaller traceback, ending with "dent authentication failed for user "launchpad_main"". Looking at google, this happened to someone else because they have two versions of postgres installed, but I'm certain I only have one.
[01:46] <mbrigdan> sorry, s/dent/ident
[01:57] <wgrant> mbrigdan: Have you run utilities/launchpad-database-setup?
[01:57] <mbrigdan> yes, but I'm running it again, along with make schema to see if that fixes anything
[02:01] <mbrigdan> huh, still not working. I just do "./utilities/launchpad-database-setup $USER", right?
[02:02] <wgrant> That should do it.
[02:02] <wgrant> Can you run 'psql postgres' successfully?
[02:03] <mbrigdan> yeah, seems to work fine
[02:03] <wgrant> You're running 'make run' as the same user?
[02:05] <mbrigdan> yup
[02:05] <mbrigdan> and echo $USER gives my username, just incase something fishy was going on
[02:09] <wgrant> Does 'psql -U launchpad_main launchpad_dev' work?
[02:09] <wgrant> mbrigdan: ^^
[02:10] <mbrigdan> no, it fails with: psql: FATAL:  Ident authentication failed for user "launchpad_main"
[02:14] <wgrant> mbrigdan: Run "psql postgres", and "SELECT * FROM pg_user WHERE usename='YOUR_USERNAME';"
[02:14] <wgrant> Is usesuper true?
[02:15] <mbrigdan> usesuper has a t underneath it, so, not knowing anything about postgres, I would assume yes.
[02:16] <wgrant> Indeed.
[02:17] <wgrant> What about usename='launchpad_main'?
[02:18] <mbrigdan> usecreatedb, usesuper, and usecatupd are all false, whatever they are. Should I got about changing this?
[02:19] <wgrant> No, that's fine. I was mostly wondering if the user actually existed.
[02:20] <wgrant> Which version of Ubuntu are you using? 10.10?
[02:21] <mbrigdan> err, that's maverick right?
[02:21] <mbrigdan> if so then yes
[02:21] <wgrant> That is.
[02:21] <wgrant> Does /etc/postgresql/8.4/main/pg_hba.conf have 'local   all         all                           trust' and 'host    all         all         127.0.0.1/32      trust' lines in it?
[02:22] <wgrant> If so, perhaps try restarting postgres.
[02:22] <wgrant> Since I can't think what else it could be.
[02:23] <mbrigdan> yes it does.
[02:23] <mbrigdan> How would I restart postgres?
[02:23] <wgrant> sudo service postgresql restart
[02:28] <mbrigdan> When I restart postgres (or start/stop/anything else for that matter), it gives me Insecure directory in "$ENV{PATH} while running with -T switch at /usr/bin/pg_ctlcluster line 63" and then "FAIL". But it still seems to be working. Could that be the problem?
[02:29] <wgrant> I've never seen that before.
[02:30] <wgrant> Is there anything interesting in /var/log/postgresql/postgresql-8.4-main.log?
[02:32] <mbrigdan> huh, this is in there: MST LOG:  provided username (launchpad_main) and authenticated username (matthew) don't match
[02:32] <mbrigdan> followed immediately by MST FATAL:  Ident authentication failed for user "launchpad_main"
[02:33] <wgrant> Hmm, so it is indeed using ident rather than trust.
[02:34] <wgrant> The 'local   all         all                           trust' line in pg_hba.conf should make it work...
[02:35] <wgrant> Oh, unless it's disabling it because it thinks the directory is too insecure.
[02:37] <wgrant> Who owns /etc/postgresql/8.4/main and its contents?
[02:38] <mbrigdan> user and group is all postgres
[02:39] <mbrigdan> although, I have added other things to my personal $PATH, could that be it?
[02:39] <wgrant> Ahh, that's probably it. The restart is failing, not postgres itself.
[02:40] <wgrant> And I bet it failed the same way when launchpad-database-setup tried to do it.
[02:40] <wgrant> Either fix PATH, fix that directory's perms, or use sudo -i.
[02:41] <mbrigdan> huh, sudo -i still fails
[02:42] <mbrigdan> What would I need to change the permissions to? Because I think I should already be the only one with access
[02:48] <wgrant> I can't work out what generates that error message, but it sounds like there is a world-writable directory in $PATH.
[02:48] <wgrant> And if it's still there after sudo -i, you've probably chmodded one of the default one.
[02:48] <wgrant> +s
[02:50] <mbrigdan> oh wait, I think apt started to complain about something after I updated to maverick, if only I could remember what it said
[02:52] <mbrigdan> well, I found at least one problem, /usr/bin is world-writeable. Thankfully, I'm the only one to ever use this computer
[02:52] <wgrant> Hah.
[02:53] <mbrigdan> Oddly, I remember apt complaining about something similar after my last upgrade too, but then it just went away
[02:54] <mbrigdan> and what d'ya' know, sudo -i now get postgres to restart perfectly fine
[02:54] <wgrant> If you don't remember making that change yourself, I would be hesistant to trust your machine much further.
[02:55] <mbrigdan> The thing is, I don't remember doing it, but my machine likes to do funny things on dist updates
[02:55] <mbrigdan> like installing apache
[02:55] <mbrigdan> every time
[02:55] <mbrigdan> for no reason
[02:56] <wgrant> Nice.
[02:56] <mbrigdan> and I haven't ran any software that hasn't come from the repos, so I'm hopefully good
[02:57] <mbrigdan> and, as a high school student, who backs up everything to external drives, I don't have that much that I would feel bad about losing
[02:57] <mbrigdan> other than a bunch of music which I should have on CDs somewhere anyways
[02:57] <wgrant> You would be one of the few such people who regularly back up, I suspect.
[02:58] <mbrigdan> hah, probably. After a few VERY close calls, I set up rsync to do it in the background once a day.
[02:59] <mbrigdan> I've discovered some rather interesting ways to corrupt data
[03:02] <sinzui> hi wgrant
[03:02] <wgrant> sinzui: Hi. Do we have form design guidelines somewhere?
[03:03] <sinzui> I do not think so...
[03:03] <mbrigdan> sweet, make run works now. Thanks for putting up with all of my strange problems man.
[03:03] <sinzui> There were many rules, but nothing in a single place
[03:04] <sinzui> wgrant, I think many of our rules are embodied in the Canonical web design guildelines that we do not *officially* use
[03:04] <wgrant> sinzui: I didn't realise that we had web design guidelines.
[03:04] <wgrant> Perhaps my initial investigations of the Canonical wiki were inadequate.
[03:05] <sinzui> wgrant, http://design.canonical.com/the-toolkit/guides-for-websites/
[03:05] <sinzui> ^ I have been trying to reconcile Canonical + Ubuntu with Lp
[03:06] <wgrant> Aha
[03:06] <sinzui> Colour is difficult, font-sizes impossible, but forms look like beuno's rules
[03:07] <wgrant> sinzui: That mostly covers visual design.
[03:07] <wgrant> I am more concerned at the moment about textual content.
[03:08] <wgrant> eg. some field captions use title case, others sentence case.
[03:08] <sinzui> ahh
[03:08] <sinzui> yes that was once in many documents
[03:09] <wgrant> Description style also varies considerably.
[03:10] <wgrant> And even those with stylistic similarities differ in subtle yet jarring ways. For example, on how they refer to the object on which they operate ("the archive" vs. "this archive").
[03:10] <wgrant> It is all disturbingly inconsistent.
[03:10] <sinzui> wgrant, :( I think we was missing a page in the wiki
[03:11] <wgrant> sinzui: dev.launchpad.net/UI has lots of links.
[03:11] <wgrant> But they are all broken.
[03:11] <sinzui> I recall something about the form slots
[03:11] <wgrant> And I cannot find anything on wiki.canonical.com or launchpad.canonical.com.
[03:13] <sinzui> I am looking at the later and do not see them
[03:13] <sinzui> There was a page about the extra form slots, another about writing the title and description in the interface
[03:15] <wgrant> I do not recall ever having seen those.
[03:15] <wgrant> Which suggests that they were not public.
[03:15] <sinzui> right
[03:16] <sinzui> I recall a rule about labeling fields as optional. Then you reported a bug that we have forms where we label the field as required
[03:17] <wgrant> That was quite some years ago.
[03:17] <wgrant> I presumed at the time it was because of differing form libraries.
[03:23] <sinzui> wgrant, I do not see anything. from the past. I think we need to focus on the future. U1, Lp, and Ubuntu should used the same rules. Maybe they have rules for us
[03:24] <wgrant> sinzui: The Ubuntu and Canonical guidelines always seemed to focus on the visual side of things rather than interaction.
[03:24] <wgrant> Which makes them unuseful for Launchpad, which must maintain a distinct visual identity.
[03:24] <wgrant> I fear that the guidelines we seek may not in fact exist.
[03:25] <sinzui> The rules of spacing and text are based on usability tests. They are thing Lp is ignoring
[03:25] <sinzui> The rules of interaction for Lp, U1 and Ubuntu should be the same.
[03:25] <sinzui> Maybe beuno developed something for U1
[04:40] <LPCIBot> Project devel build (331): STILL FAILING in 3 hr 30 min: https://hudson.wedontsleep.org/job/devel/331/
[05:09] <thumper> YAY \o/
[05:09] <thumper> 2nd logger branch landed
[05:09]  * thumper EOYs
[05:17] <LPCIBot> Project db-devel build (247): STILL FAILING in 3 hr 36 min: https://hudson.wedontsleep.org/job/db-devel/247/
[05:26] <LPCIBot> Project devel build (332): STILL FAILING in 8 min 28 sec: https://hudson.wedontsleep.org/job/devel/332/
[05:31] <LPCIBot> Project devel build (333): STILL FAILING in 0.47 sec: https://hudson.wedontsleep.org/job/devel/333/
[05:45] <wgrant> WTF Zope.
[07:51] <StevenK> $ bzr revision-info -d /mnt/test/launchpad/workspace/devel
[07:51] <StevenK> null
[07:51] <StevenK> Whee
[07:52] <spiv> StevenK: Hmm, not "0 null:"?
[08:29] <wgrant> Wow, we've really closed 208 bugs?
[09:01] <LPCIBot> Project db-devel build (248): STILL FAILING in 3 hr 15 min: https://hudson.wedontsleep.org/job/db-devel/248/
[09:01] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12140
[09:01] <LPCIBot> included.
[09:01] <danilos> wgrant, hi, just wanted to check if you have landed a fix for the interfaces for bug 685624? I didn't see any separate commits, but didn't have the time to look at it fully
[09:01] <_mup_> Bug #685624: Translation template build jobs should use the new BuildFarmJob <bugjam2010> <lp-soyuz> <lp-translations> <qa-ok> <Launchpad itself:Fix Released by danilo> < https://launchpad.net/bugs/685624 >
[09:02] <wgrant> danilos: Totally forgot about that, sorry.
[09:02] <wgrant> Will do that now.
[09:02] <danilos> wgrant, ok, thanks
[09:04] <wgrant> danilos: Should I reuse that bug?
[09:04] <danilos> wgrant, yeah, please
[09:27] <LPCIBot> Project devel build (334): STILL FAILING in 3 hr 29 min: https://hudson.wedontsleep.org/job/devel/334/
[10:02] <wgrant> danilos: Could you bless https://code.launchpad.net/~wgrant/launchpad/bug-685624-ttbj-build-interface/+merge/44558?
[10:03] <danilos> wgrant, blessed may it be!
[10:04] <wgrant> danilos: Thanks.
[10:06] <henninge> danilos: poimport.txt has a section called "Cron Scripts" that was either deleted in db-devel or added in devel. It's causing a merge conflict now. In or Out?
[10:08] <danilos> henninge, toss a coin... uhm, I don't know, we do want to have some basic testing for cron scripts so if it's not moved to a unit test, keep it :)
[10:08] <henninge> okay
[10:11] <wgrant> danilos: :( I don't think ec2 likes your review type very much.
[10:11] <danilos> wgrant, uhm, ok, I'll try fixing it
[10:12] <wgrant> I'm not sure if you can, but I guess we'll see shortly.
[10:12] <danilos> wgrant, seems to have worked fine
[10:13] <danilos> wgrant, sorry about the trouble :)
[10:16] <wgrant> danilos: Ah, great. Thanks.
[10:20] <wgrant> This more forgiving bugactivity grouping is nice.
[10:25] <danilos> wgrant, btw, we were finally able to get a clean slate of stable branch for rollout yesterday, just if you haven't noticed (I know you were waiting for a fix to be rolled out)
[10:25] <wgrant> danilos: I was pleasantly surprised this morning to find the deployment page empty.
[10:26] <wgrant> We still had two un-QA'd items when I went to sleep last night, so I wasn't too hopeful.
[10:26] <wgrant> Thanks for getting that deployed.
[10:26] <danilos> wgrant, your rollback was very helpful, thanks for doing it
[10:26] <wgrant> danilos: You needed that celebrity fix?
[10:27] <wgrant> So many revs lately that I cannot remember them all :(
[10:44] <danilos> wgrant, btw, before you are gone (though you should be gone :), is there a way we can do something similar on production to re-uploading kde-l10n-sr .translations.tar.gz file you did on dogfood or should we ask packagers to re-upload it?
[10:44] <danilos> wgrant, or perhaps we can just do a rebuild?
[10:45] <wgrant> danilos: We can't do an explicit manual upload of the tarball to the source package, like we can with a project?
[10:45] <danilos> wgrant, no, unfortunately
[10:46] <wgrant> danilos: We'd have to do an upload to maverick-updates.
[10:46] <wgrant> The way I did it on DF was a little... unconventional.
[10:47] <danilos> wgrant, I know, just checking :)
[10:47] <wgrant> It involved a disturbing amount of conversation with psql.
[10:47] <danilos> wgrant, so, what about rebuilding, will that work, and can we do that?
[10:47] <danilos> wgrant, or will we have to have a re-upload with version change?
[10:48] <wgrant> danilos: We'd have to do a new upload to maverick-proposed.
[10:48] <danilos> wgrant, I am wondering because this is an ubuntu package
[10:48] <wgrant> And then we'd probably have to get an SRU exemption.
[10:48] <danilos> and I guess it wouldn't be very nice to change the package with the same version (though, package would stay the same, but dates would change)
[10:49] <danilos> wgrant, right, then I'll just ask Kubuntu people to do it, thanks
[10:49] <wgrant> Yeah, Riddell would probably be a good person to talk to.
[10:49] <danilos> was just looking to see if he's around :)
[10:50] <danilos> wgrant, fwiw, we don't have to release these packages, we just need to re-import translations
[10:52] <wgrant> danilos: So we could probably get away with accepting an upload to -proposed and then deleting it as soon as it builds.
[10:52] <wgrant> Without ever going through -updates.
[10:53] <danilos> wgrant, I wouldn't know enough about what I am doing there (i.e. I am totally unfamiliar with Ubuntu policies and also about "pockets" or whatever :)
[10:53] <danilos> wgrant, I'll see if Riddell has any ideas and if he'd like to do something like that
[10:54] <wgrant> Right.
[11:10] <wgrant> Good morning jml.
[11:11] <wgrant> Your Jamometer is looking much more healthy today.
[11:11] <jml> oooh
[11:11]  * jml looks
[11:11] <jml> zowie!
[11:11] <jml> I gather we rolled out?
[11:11] <wgrant> Indeed we did.
[11:12] <wgrant> The deployment report was deliciously empty this morning.
[11:13] <jml> wow.
[11:14] <jml> "critical" doesn't mean what it used to.
[11:23] <wgrant> jml: Hm?
[11:24] <wgrant> You mean the critical bugs that have been sitting around for ages untouched?
[11:33] <jml> wgrant: yes
[11:45] <gmb> allenap: Do you know what the current EC2 image number is or how I'd find out?
[11:46] <gmb> (I ask because you're the last person to touch it, IIRC)
[11:46] <allenap> gmb: bin/ec2 images
[11:46] <gmb> Aha.
[11:46] <gmb> Ta
[11:46] <allenap> gmb: 503
[11:46] <wgrant> Using machine image version 503
[11:55] <jml> looking at bug 272304. I now recognize that error string.
[11:55] <_mup_> Bug #272304: "User timeout caused connection failure." doesn't make sense <branch-puller> <confusing-ui> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/272304 >
[12:06] <gmb> allenap: When you updated the EC2 image, did you get a lot of nonsense about installing GRUB?
[12:07] <allenap> gmb: Mmm, don't remember :-/
[12:07] <gmb> Hrm.
[12:08] <gmb> allenap: Did you base your image off the previous launchpad-ec2test image or did you base it off the official Lucid AMI?
[12:08] <allenap> gmb: Official.
[12:08] <gmb> Ok.
[12:09]  * gmb washes his hands of this weirdness, restarts the process.
[12:09] <allenap> gmb: There are some instructions on how to do it on the wiki. I updated them last time I did it.
[12:10]  * allenap really goes now
[12:10] <gmb> allenap: Yeah, that's what I'm following :)
[12:15] <jml> allenap, gmb: do you reckon all those story-foo tags should be "official"?
[12:15] <jml> (I'm guessing official means at least "visible on the front page")
[12:16] <jml> gah, you know what I mean by 'front'.
[12:21] <voidspace> where do I report a bug in launchapd?
[12:21] <gmb> jml: Well, they were made official out of laziness and i-can-never-type-things-right-the-first-time -ness.
[12:22] <jml> voidspace: bugs.launchpad.net/launchpad/+filebug
[12:22] <voidspace> ah - that's right, I bug jml about it directly until it is fixed
[12:22] <voidspace> jml: no need, I can just hassle you instead
[12:22] <gmb> jml: I'm thoroughly ambivalent about their actual officialness.
[12:22] <voidspace> and where do I change my launchpad password?
[12:22] <jml> voidspace: a veritable blessing falls from the sky and on to my lap
[12:22] <voidspace> my account details page doesn't appear to provide that option...
[12:23] <jml> gmb: I guess once they aren't under active development the laziness factor is less important?
[12:24] <wgrant> voidspace: Check the link down the bottom of https://launchpad.net/people/+me/+edit
[12:24] <wgrant> voidspace: https://launchpad.net/launchpad/+faq/51
[12:24] <jml> wgrant: beat me by seconds
[12:25] <voidspace> ok - so if I click on my username in the top right of the page it appears to show an account page, from which I can edit all details except my password
[12:25] <voidspace> this does not compute ;-)
[12:25] <voidspace> anyway - thanks
[12:25] <wgrant> voidspace: There is a 'Change details' link on that page.
[12:25] <wgrant> Which goes to the page that I linked you to.
[12:26] <gmb> jml: Yeah. Actually, if you rephrase that as "story-* tags are considered official whilst the story is under active development" it doesn't sound like a half-bad rationale.
[12:26] <voidspace> ah right, I am on that page and don't see an option to change my password
[12:26] <wgrant> voidspace: It is a little awkward at the moment, since we are part-way through a migration to use OpenID for authentication.
[12:26] <wgrant> voidspace: Right, there is a link down the bottom to an FAQ about that.
[12:26] <jml> voidspace: yes, but if you actually read what wgrant says, there's a link at the bottom
[12:26] <voidspace> FFS
[12:27] <voidspace> thanks
[12:27] <jml> gmb: cool.
[12:27] <wgrant> Someone should throw the OpenID story at a squad next year and get this sorted out.
[12:28] <voidspace> aaaand I can't change my password to something memorable because of the damn password rules
[12:28] <voidspace> but I can leave it as the current weak password which also doesn't meet the rules...
[12:28] <voidspace> yay
[12:29] <wgrant> I've also avoided changing mine lately because I can't be stuffed respecting those rules :(
[12:29] <jml> gmb: I notice that a lot of the story-* tags are phrased incrementally (e.g. "refactor-log-api"). I think tags work a little better when they are more absolute (e.g. "patch-tracking").
[12:29] <jml> gmb: this is by way of an observation, I can't think of any useful thing to actually *do* as a result.
[12:35] <gmb> jml: You're right, though. I think that those were "sub-stories" that grew as a result of us looking at a particular problem. As in "We can only do this part of $major_story when $minor_story is finished." so we make a tag for $minor_story to make it easier to track which bugs we need to fix first.
[12:36] <jml> makes sense
[12:38] <jml> wgrant: I wonder how much of the openid stuff can get cleaned up through bug fixes
[12:38] <wgrant> jml: I don't think it can be properly fixed until the divorce is compelte.
[12:38] <wgrant> Once the split is done, login.launchpad.net can go away,.
[12:38] <wgrant> And then confusion is eliminated.
[12:38] <jml> I see.
[12:39] <wgrant> (it cannot go away now, because forcing everyone through login.ubuntu.com would be suicide)
[12:57] <jml> hmm.
[12:58] <jml> I wish there were an obvious choice for argument parsing stuff when writing a Python command-line app.
[13:01] <wgrant> jml: I like the look of argparse. But since it's 2.7, I still use OptionParser mostly.
[13:01] <wgrant> Is there anything better than OptionParser?
[13:01] <jml> wgrant: there's twisted.python.usage and stuff based on bzrlib.options
[13:01] <jml> (e.g. commandant)
[13:02] <jml> wgrant: and lifeless has a new, more experimental thing in testr.
[13:02] <wgrant> Oh, right, but those all have large external dependencies.
[13:03] <jml> yeah, exactly
[13:19] <stub> OptionParser is still pretty cool and can do a lot. Not that this is obvious from the badly layed out docs which are more a tutorial than a reference.
[13:22] <jml> what does searchTasks do when it's on person?
[13:23] <jml> 'related', it seems
[14:11] <LPCIBot> Project devel build (335): STILL FAILING in 3 hr 30 min: https://hudson.wedontsleep.org/job/devel/335/
[14:41] <jml> what do we think about this format of output? http://paste.ubuntu.com/546931/
[14:42] <jml> trying to prototype a command-line display of all Launchpad inventory
[14:43] <jelmer> jml: I think it makes sense to display MPs inline with the branches
[14:43] <jelmer> makes more sense than displaying them separately I mean
[14:43] <jml> jkakar: kind of related to that kanban board...
[14:43] <jml> jelmer: yeah, I think I agree.
[14:45] <jml> jelmer: you have a lot of stuff :)
[14:47] <jml> jelmer: http://pastebin.ubuntu.com/546932/
[14:49] <jelmer> jml: that's quite a useful overview, I forgot a lot of the stuff that's on that list :-)
[14:49] <jml> jelmer: yeah, there's some on mine that I'm deleting / abandoning now.
[14:50] <jml> jelmer: I guess I could try to make some HTML output so it's linked and better as a prototype for an actual LP page.
[14:50] <jelmer> jml: Actually, this is something I've been wondering about..
[14:51] <jelmer> Is there any reason for not importing *all* Debian bugs? It'd be very neat to be able to browse my Debian bugs in lp.
[14:51] <jelmer> Just the sheer volume?
[14:51] <jml> jelmer: I don't know. gmb might.
[14:53] <jml> jelmer: I mean, it's the sort of thing we _should_ do.
[14:56]  * gmb reads scrollback
[14:57] <gmb> jelmer, jml: We should be doing it, but we (originally) didn't because of the volume. The correct way to deal with it in the first instance, I think, would be to do a batched import.
[14:59] <jml> gmb: does the 'originally' imply that another reason came up?
[15:01] <gmb> jml: No. The only reason we don't do it now is because we don't do it now (i.e. we forgot to ever revisit the problem)
[15:01] <jelmer> should I file a bug ?
[15:01] <jml> that old chestnut :)
[15:01] <jml> gmb: thanks.
[15:02] <gmb> jelmer: I think there's one already, but feel free to take a look and file one if not.
[15:02] <LPCIBot> Project db-devel build (249): STILL FAILING in 3 hr 36 min: https://hudson.wedontsleep.org/job/db-devel/249/
[15:03] <jelmer> gmb: Thanks
[15:03] <jml> jelmer: also has this style of output: http://paste.ubuntu.com/546935/
[15:04] <jelmer> jml: btw, it only seems to report upstream bugs/branches at the moment?
[15:04] <jelmer> jml: nice
[15:04] <jml> jelmer: no, it should get package branches / bugs
[15:04] <jml> but maybe the way it prints them out is wrong
[15:05] <jml> jelmer: http://paste.ubuntu.com/546936/
[15:05] <jelmer> ah, it reports them under the upstream project
[15:06] <jelmer> I think most of my ubuntu-specific branches are team-owned
[15:07] <jml> jelmer: specifically, it just groups by target.name
[15:08] <jelmer> jml: ah
[15:09] <jelmer> jml: are you looking at this in preparation of e.g. a dashboard, or is this just random hacking?
[15:09] <jml> jelmer: a bit of both
[15:10] <jml> jelmer: I'd like to prototype a Launchpad dashboard, get a feel for the data etc.
[15:11] <jml> lp:~jml/+junk/whip has the code. would love it if you made it better.
[15:15] <jelmer> I might have a look :-)
[15:22] <jkakar> jml: Yeah, I should spend some more time on that kanban board and then announce it somewhere.  I've been finding it quite useful.
[15:37] <jml> jkakar: http://people.canonical.com/~jml/jkakar-wip.html
[15:41] <jml> interesting
[15:45] <jml> how would I debug this? http://paste.ubuntu.com/546951/
[15:51] <jkakar> jml: That's really cool. :)
[15:51] <jelmer> jml: perhaps it's related to the fact that bzrk is inactive?
[15:51] <jml> jelmer: yeah, I think so.
[15:51] <jml> jelmer: I hacked around it
[15:52] <jml> jkakar: thanks. it's certainly the start of something that could be quite cool.
[15:54] <jkakar> jml: Yeah, I've wanted something like that for a while.  It sounds like it, or something like it, would be nice to have in my kanban project.
[15:55] <jml> jkakar: I'm not at all convinced that kanban-style presentation is the best way to go.
[15:56] <jkakar> jml: I find it useful as a high-level view, but yeah, it's not a golden hammer.
[15:56] <jkakar> jml: I was thinking something more like the "list of stuff" that you have, integrated into the kanban system, could be useful.
[15:57] <jml> jkakar: *nod*
[15:59] <jkakar> jml: One thing I noticed about your thing is that it lists branches that have been proposed for merged and 'Rejected'.
[15:59] <jml> jkakar: yes. it also lists MPs for Abandoned branches.
[16:00] <jml> jkakar: I'm not sure if that's a bug in Launchpad or a bug in the thing.
[16:00] <jkakar> jml: In the two cases I see in my listing (lp:~jkakar/storm/resultselect and lp:~jkakar/storm/resultset-expression) they're both things that I don't really care about anymore, but I also don't want to delete the branches.
[16:00] <jml> jkakar: "Abandoned" is your friend.
[16:00] <jkakar> jml: Ah, I didn't even know about it. :)
[16:04] <jml> jkakar: similarly, marking a branch as "Mature" or linking it to a series will get it off the list.
[16:04] <jkakar> jml: Hmm, weird. :/
[16:05] <jml> I don't know that it's so weird.
[16:06] <jkakar> jml: I don't understand what "Mature" means or why linking to a series would get it off that list.
[16:06] <jml> jkakar: because lp:foo or lp:foo/2.1 is unlikely to be work-in-prorgess
[16:07] <jkakar> jml: I see.  So what does 'Mature' mean?
[16:07] <jml> jkakar: no-one knows what Mature means. Here I'm using it as a convenient way to let people say "this branch isn't abandoned, it should appear on listings, but it's not really intended to ever be merged anywhere"
[16:07] <jkakar> jml: Hehe, cool. :)
[16:10] <jml> jkakar: so, for example, I've marked some of my unofficial VCS imports as Mature
[16:11] <jml> jkakar: and my fork of pyflakes that supports lazy imports
[16:11] <jkakar> jml: Right, makes sense.
[16:11] <jkakar> jml: Is the script that you used to generate the wip HTML page on Launchpad somewhere?
[16:11] <jml> jkakar: yes. all the details are here: http://code.mumak.net/
[16:12] <jml> jkakar: I mean, lp:~jml/+junk/whip
[16:12] <jml> (I have also blogged)
[16:25] <sidnei> what is the reviewers channel again?
[16:31] <bac> #launchpad-reviews
[16:31] <bac> henninge: have you seen the failure on db-devel related to MockLogger.  Looks like some tests were not updated.
[16:32] <henninge> bac: no, I have not
[16:33] <bac> henninge: r12141 updated poimport.txt but your branch did not, for example.
[16:33] <henninge> bac: this is poimport-script.txt, though
[16:34] <danilos> bac, it might be thumper's "mock logger consolidation" branch
[16:34] <bac> yes, poimport-script.txt, i meant
[16:34] <bac> danilos: yes, that is the branch i think henning was trying to merge into db-devel
[16:34] <henninge> bac: that is true
[16:35] <henninge> but I only resolved a merge conflict in poimport.txt.
[16:35] <danilos> anyone knows how are script names related to config sections?
[16:35] <henninge> I am sorry, though, I have to leave right now. I cannot look into it any further.
[16:36] <bac> henninge: so do we think thumper's branch is the original culprit then?
[16:36] <henninge> bac: yes, in relation to db-devel differing a lot currently because of the recife branch having been merged into it.
[16:37] <henninge> differing in translations
[16:37] <henninge> danilos, bac: would either oof you be so kind and have a closer look, please? I really have to go.
[16:37] <danilos> henninge, that's not a lot, that was barely 25k lines of diff when merged ;)
[16:38] <bac> thanks henninge.  i just wanted to get your take on what was going on
[16:38] <henninge> sure, you got it ;)
[16:38] <henninge> bac: Have a great Christmas!
[16:39] <bac> you too
[16:42] <bac> danilos: poimport-script.txt is in db-devel but not trunk.  was it supposed to be removed/
[16:43] <danilos> bac, I am not sure, I'll check
[16:45]  * bac is unsure how to get bzr to tell about deleted files
[16:46] <danilos> bac, it needs to be removed, test was replaced with a unit test lib/lp/translations/scripts/tests/test_translations_import.py
[16:46] <danilos> bac, if you feel trigger happy, r=danilo for that :)
[16:47] <danilos> bac, otherwise, I'll get to it a bit later after I am done shuffling a few WIP tasks
[17:00] <bac> danilos: it was easier just to fix the test.  i'll submit a testfix branch in a bit
[17:02] <danilos> bac, easier? it's a duplicate test, that's why it was removed in the first place :)
[17:03] <danilos> bac, though thanks anyway :)
[17:03] <bac> danilos: but the replacement has not landed in db yet
[17:03] <danilos> bac, no? that's where I see it so it's weird
[17:05] <bac> danilos: oh, you are right.  i just assumed the branch that introduced the new one had deleted the old.
[17:05] <bac> danilos: i'll just zap it then
[17:05] <danilos> bac, cool, thanks
[17:23] <leonardr> jml, can you tell me about LaunchpadBranchLander or point me to someone who can?
[17:23] <leonardr> i'm trying to figure out what to do with its call to login_with, which is about to be deprecated
[17:23] <leonardr> is this a script people will run from their desktops?
[17:23] <jml> leonardr: can you give me some more context? a URL? a filename?
[17:25] <leonardr> jml: sure
[17:25] <leonardr> lib/devscripts/autoland.py
[17:25] <jml> oh
[17:25] <leonardr> it could be something you run yourself or it could be something run automatically on the ec2 instance
[17:25] <leonardr> i can't tell
[17:25] <jml> leonardr: that's 'ec2 land'
[17:26] <jml> leonardr: it's used only in cmd_land in devscripts/ec2test/builtins.py
[17:26] <jml> leonardr: it's a script that developers run from their desktops.
[17:26] <leonardr> jml: ok, so it's all right if it causes a browser open
[17:27] <jml> leonardr: indeed.
[17:29] <allenap> leonardr: I'm not going to finish your review before I go. I'll probably be back online in about 3 hours for a while. Is it urgent?
[17:29] <leonardr> allenap: not at all
[17:30] <allenap> leonardr: Okay, I'll either finish it this evening or have it done by the time you start tomorrow.
[17:32] <leonardr> allenap: today's my last day for the rest of the year, so don't rush
[17:33] <allenap> leonardr: Don't tell me that or I'll procrastinate until January ;)
[17:33] <allenap> leonardr: Have a good holiday.
[17:34] <leonardr> thanks, you too
[17:37] <LPCIBot> Project devel build (336): STILL FAILING in 3 hr 5 min: https://hudson.wedontsleep.org/job/devel/336/
[17:37] <LPCIBot> Launchpad Patch Queue Manager: [r=danilo][ui=none][bug=685624] Let
[17:37] <LPCIBot> TranslationTemplatesBuildJob.build through the security proxy.
[17:49] <lifeless> jml: have you looked at my persistence science-fiction?
[17:50] <jml> lifeless: no. I skimmed the discussion on the list.
[17:50] <jml> lifeless: I might take a look tomorrow.
[18:01] <jelmer> ec2 test/land appears to be broken on natty - has anybody looked into that yet?
[18:04] <jml> jelmer: perhaps that's what leonardr was just talking about.
[18:04] <leonardr> jelmer: what's the error?
AWS was not able to validate the provided access credentials</Message></Error></Errors><RequestID>26328b8e-9dd8-4cba-af10-746d34227953</RequestID></Response>
[18:05] <jelmer> I can reproduce it on two natty machines, and the lucid partition (with the same home dir as one of the natty installs) works fine.
[18:09] <jelmer> leonardr: is that the same as you were seeing?
[18:10] <leonardr> jelmer: i'm not testing it, i was inspecting code for problems with a branch i'm working on
[18:10] <leonardr> that looks like a problem between you and aws, not related to the launchpad web service
[18:11] <jelmer> That's what I was thinking, but it's strange that it works fine in my lucid install with the same credentials.
[18:11] <jelmer> I'll investigate further.
[18:30] <LPCIBot> Project db-devel build (250): STILL FAILING in 3 hr 14 min: https://hudson.wedontsleep.org/job/db-devel/250/
[18:30] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12142
[18:30] <LPCIBot> included.
[18:34] <lifeless> grr
[18:34] <lifeless> something has broken feature flag timeouts :(
[18:47] <jcsackett> can someone tell me where to look to find the javascript responsible for controlling the spinner that shows on the merge proposal status when you change status?
[18:47] <lifeless> jcsackett: you pinged me yesterday
[18:47] <jcsackett> ah, yes i did, lifeless.
[18:48] <jcsackett> it's in relation to a bug you filed, let me dig tat up.
[18:49] <jcsackett> lifeless, bug 691846. i was wondering what url facilities you were thinking of? urllib/urllib2 can't handle all of those protocols to my knowledge, but perhaps you're thinking of something i'm unaware of?
[18:49] <_mup_> Bug #691846: hardcoded list of protocols for urlification is a maintenance burden and duplicate code <bugjam2010> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/691846 >
[18:51] <lifeless> jcsackett: urls follow a generic ruleset
[18:51] <lifeless> any url parser can parse all urls unless its totally broken - see ietf std 66
[18:52] <lifeless> [the python stdlib url parser may be totally broken; I've had to monkey patch it before]. That said,
[18:52] <lifeless> there are broadly two sorts of urls
[18:52] <lifeless> path like urls
[18:52] <lifeless> and non-path like urls
[18:53] <lifeless> parsers are meant to handle both, at least as far as scheme, otherstuff
[18:53] <lifeless> secondly, we have our own url facilities in Launchpad
[18:53] <jcsackett> the second point was what i assumed--i am unaware of such facilities, but figured they existed.
[18:55] <lifeless> for the record, urlparse supports ftp, http, gopher, nntp, impa, wais, file https shttp snew prospero rtsp rtspu rsync svn svn+ssh sftp nfs git git+ssh, and we use it directly in bzr after extending the urlparse.uses_netloc whitelist
[18:55] <lifeless> thats a rather more extensive scheme list than your patch used, I think :)
[18:56] <jcsackett> lifeless: i wasn't actually aware of the urlparse lib. :-)
[18:56] <jcsackett> that seems quite sufficient, thanks. :-P
[18:57] <lifeless> you want urlparse.urlsplit I think
[18:57] <jcsackett> lifeless: that or urlparse.urlparse, it looks like.
[18:57] <jcsackett> thanks.
[18:57] <lifeless> throw some empty things at it
[18:57] <lifeless> no, urlsplit
[18:57] <lifeless> you have stuff that *isn't* a valid http url
[18:57] <jcsackett> lifeless: true. ok.
[18:57] <lifeless> that you want to see is just http, for instance.
[18:57] <lifeless> urlsplit should handle that, as I read it
[19:04] <jcsackett> cool. thanks again.
[19:08] <lifeless> gary_poster: hi, around?
[19:09] <gary_poster> lifeless, hi, yes
[19:09] <lifeless> I just found myself filing a dup of https://bugs.launchpad.net/oops-tools/+bug/677299
[19:09] <_mup_> Bug #677299: please always report at least one of each pageid that times out in the 'lpnet' daily summary <OOPS Tools:New> < https://launchpad.net/bugs/677299 >
[19:10] <lifeless> I'm wondering if your team has the bandwidth to do something stopgap in that area.
[19:10] <gary_poster> heh, not for the rest of the year.
[19:11] <lifeless> I appreciate that grouping differently is tricky and hard
[19:11] <lifeless> gary_poster: ok, I guess we'll see what the brand new year brings :)
[19:11] <gary_poster> :-) ok
[19:11] <lifeless> gary_poster: I'm going to triage that up to high though
[19:12] <lifeless> this cost me 15 minutes today
[19:12] <lifeless> (and yes, I'm still on leave :)
[19:13] <lifeless> anyhow, have a great xmas or whatever you call it over there :)
[19:14] <gary_poster> lifeless: high: ack.  let's circle around at start of year--several people will be pedaling hard to tie various things up before the team disperses at thunderdome but maybe we can fit things in then.
[19:14] <gary_poster> have a great holiday also
[19:15] <lifeless> gary_poster: hmm, my previous came across overly grumpy; sorry about that.
[19:15] <lifeless> gary_poster: I agree, and understand.
[19:15] <gary_poster> :-) no worries
[19:15] <lifeless> I suspect in the new structure we need to move all the subprojects to canonical-engineering team maintenance
[19:15] <lifeless> rather than qa-team, etc
[19:15] <gary_poster> agree
[19:16] <lifeless> then ask folk to save bugs.launchpad.net/launchpad-project/+bugs?field.priority=high as their go-to search
[19:16] <lifeless> or something like that
[19:16] <gary_poster> yeah
[19:16]  * lifeless will worry about it in the new year
[19:16] <gary_poster> good idea :-)
[21:40] <LPCIBot> Project db-devel build (251): STILL FAILING in 3 hr 9 min: https://hudson.wedontsleep.org/job/db-devel/251/
[21:40] <LPCIBot> Launchpad Patch Queue Manager: [testfix][r=danilos][ui=none][no-qa] Remove redundant test.
[23:14] <LPCIBot> Project devel build (337): STILL FAILING in 3 hr 33 min: https://hudson.wedontsleep.org/job/devel/337/