 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         <IP_ADDRESS>/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/


[09:08] <dkessel> ballooons: just fyi - if there is any test automation meeting today, i wont be able to participate
[11:52] <balloons> dkessel, ack
[16:24] <balloons> ping svij
[16:25] <svij> balloons: pong
[16:25] <balloons> svij, so nuclearbob is going to be hosting things :-) I'm working through the next steps, and I'm curious if you have any code from how you setup the jobs
[16:26] <balloons> I was thinking the jobs could all simply pull from an lp branch. I'll setup a new project on lp under the testcase admins as drivers
[16:26] <svij> uh, no. I only tried running the tests the "manual" way.
[16:26] <balloons> ahh ;-0
[16:27] <balloons> ok, so it'll be blank at first, heh
[16:27] <svij> in the READmE of ubiquity there is a tutorial how to setup the jenkins slave afair
[16:29] <balloons> right, indeed there is
[16:29] <svij> I didn't check if that still works
[16:30] <balloons> nuclearbob found this trying to run it: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1487098
[16:31] <svij> my tests with the cloud instances didn't get that far ;)
[16:33] <svij> brb (dinner)
[17:05] <svij> er
[17:16] <DanChapman> balloons: svij, hey o/ so I have the tests nearly up and running again \o/ Just the manual partition step to fix and they should be all back to normal
[17:16] <svij> cool!
[17:17] <balloons> DanChapman, oO!!!
[17:17] <balloons> high-five!
[17:17] <DanChapman> balloons: hmmm bug 1487098 looks like it is for kubuntu??
[17:17] <balloons> lol DanChapman
[17:17] <balloons> I guess we'll have to confirm with nuclearbob if indeed he was launching kubuntu
[17:19] <DanChapman> the line before the traceback shows "Aug 20 11:22:06 hostname ubiquity[4050]: Exception in KDE frontend (invoking crash handler):" I havn't hit that issue with the iso's i've been using
[17:23] <balloons> right, I saw the same after you mentioned it. I'm guessing that's it
[18:27] <nuclearbob> balloons: I was just running the run_ubiquity script
[19:54] <balloons> nuclearbob, was it starting the qt version then? seems odd
[19:55] <nuclearbob> balloons: indeed. Not sure how to get it to use the gtk version
[19:55] <balloons> DanChapman, thoughts ^^?
[20:07] <DanChapman> balloons: nuclearbob IIRC ubiquity just queries /cdrom/.disk/info to determine the flavor in use for the install and will switch gtk/qt based on that. What flavor iso were you using nuclearbob?
[20:07] <nuclearbob> DanChapman: I installed using a normal unity-based image, but that was some time and several upgrades ago
[20:14] <DanChapman> nuclearbob: oh right, you ran run_ubiquity locally? and not in a vm? If so I would advise against doing that as run_ubiquity will launch ubiquity as root and bad things could happen
[20:14] <nuclearbob> DanChapman: okay, good to know. I'll try it in a vm next, thanks
[20:29] <balloons> so DanChapman, I assume you have an MP that will need reviewed for ubuquity right?
[20:30] <DanChapman> balloons: yeah I will need to get someone to review it. Who would be best to ping to get it reviewed?
[20:32] <balloons> DanChapman, my guess is cjwatson and/or cyphermox
[20:33] <DanChapman> cool beans, well I'll just request "Ubuntu Installer team" to review and ping one of them to get it on their radar.
[20:36] <balloons> rigjt
[20:36] <balloons> awesome!
[20:37] <cyphermox> good evening
[20:37] <DanChapman> balloons: thinking about it, it might be wise to initially start running the tests from my (future) branch then it will be easier to get quicker fixes in to test rather than bothering cjwatson/cyphermox with loads of little fixes. Once there deemed stable enough then propose a merge? What's your thoughts?
[20:38] <cyphermox> what is it that you are trying to do?
[20:38] <balloons> DanChapman, mmm.. that could also be a thing.  But there might be more work invovled with making them work in jenkins
[20:39] <balloons> hey cyphermox. DanChapman has updated the failing AP tests for ubiquity
[20:39] <cyphermox> the failing AP tests?
[20:39] <cyphermox> http://autopkgtest.ubuntu.com/packages/u/ubiquity/
[20:39] <cyphermox> do you mean the image promotion tests?
[20:42]  * cyphermox 's brain defaults to acronym["AP"] =  "access point", needs a bit more context :)
[20:44] <DanChapman> cyphermox: "autopilot tests" :-) https://jenkins.qa.ubuntu.com/view/Ubiquity/view/All/
[20:45] <DanChapman> balloons: I think last time we intitially got the jenkins runs going off a seperate branch before switching them to trunk once they were running correctly
[20:45] <cyphermox> guess once or twice every 9 months it's good to run these tests ;)
[20:46] <cyphermox> DanChapman: let me know when you're done, but do you need to change things in ubiquity to fix this?
[20:47] <balloons> DanChapman, I believe you are correct. I'm ok with that idea, but I don't think it's a bad idea to get other folks invovled so they know abou tit
[20:47] <balloons> Little changes are easier to digest
[20:48] <DanChapman> cyphermox: ok great.... no I havn't needed to change anything in ubiquity just in the tests themselves and the testrunner
[20:49] <cyphermox> ok
[20:50] <cyphermox> knock yourself out. anything we can find automatically before release makes me want to give you beer, if you're into that :)
[20:52] <cyphermox> DanChapman: there's the image promotion tests that could also use some careful reviewing / fixes, looks like they sometimes pass when the image doesn't boot (and don't test much anyway), and sometimes fail for no reason.
[20:53] <DanChapman> balloons: well i'm not fussed either way, Getting other folks involved would be awesome so we should probably make it as open to that as possible. (i.e just do trunk :-) )
[20:53] <cyphermox> I started looking, and the few tests that are already created look pretty good, it would just be a matter of making sure they are consistent and truthful, and enabled
[20:53] <balloons> DanChapman, ahh right.. collaboration means put it in trunk!
[20:54] <cyphermox> and then there were other priorities, but I'll be back home this weekend and should have time to hack at it


[10:00] <jtaylor> meld needs an SRU for bug 774265 bug 786134 and bug 787831, as I'm doing this anyway can I also throw in bug 770549 which is less severe but more an annoyance?
[10:01] <jtaylor> it forces one to use meld from the command line
[13:26] <hggdh_> jtaylor: it is an usability issue, so _can_ be considered for SRU
[17:26] <charlie-tca> ubuntu-bug is not attaching logs when run in terminal
[17:47] <hggdh> charlie-tca: this is probably the apport hook
[17:47] <charlie-tca> gnome-control-center?
[18:35] <hggdh> might be, yes
[18:35] <hggdh> right now cannot test, upgrading to Oneiric...


[04:50] <shtylman> cjwatson_: I just pushed a branch to lp:~shtylman/ubiquity/kubuntu-installer-style it contains the new package .install file and updates to make things work with that package. I don't really know what the policy is for new packages after freeze so I didn't merge myself. This package was requested by anothr kubuntu developer as they are using only the style elements in another installer
[04:53] <rgreening> hey shtylman
[04:54] <shtylman> rgreening: howdy
[04:54] <rgreening> does the installer have the slideshow now too? :P
[04:54] <shtylman> rgreening: working on it
[04:54] <rgreening> kool
[04:54] <shtylman> trying to get the slide content down
[04:55] <rgreening> excelent
[04:55] <rgreening> did you look into the slowness issue
[04:56] <rgreening> in loading the timezoe, the app paused and seemed hung shtylman
[04:56] <rgreening> havent tried it in the last few days though...
[04:56] <shtylman> not yet...I did run the installer and didn't really notice anything wrong myself...but I will try to run it in a vm with low memory and speed
[04:56] <shtylman> and see if that shows anything
[04:57] <rgreening> shtylman: try from a usb stick
[04:57] <rgreening> shtylman: I was doing this on my netbook 1ghz and 1gb ram and 2gb swap
[04:57] <rgreening> and a SSD
[04:58] <shtylman> damn
[04:58] <shtylman> ok..I will see if I can set that up
[04:58] <rgreening> lol. I'll try it again tommorrow. Is there some debug info or log info you would like me to capture?
[04:59] <shtylman> um...see if /var/log/installer/debug has anything interesting or noteworthy...
[04:59] <rgreening> ok
[04:59] <shtylman> thanks :)
[04:59] <rgreening> btw, it all looks pretty slick shtylman
[04:59] <rgreening> :P
[04:59] <shtylman> :)
[09:44]  * evand stabs devicekit-disks repeatedly
[10:03] <cjwatson> danilos: just one more question about this translation upload from debian-installer to ubiquity - what will happen if there are old translations in debian-installer, but people have already updated the translations in ubiquity? which will win?
[10:03] <cjwatson> danilos: and is there anything I can do about this?
[10:07] <danilos> cjwatson: it depends
[10:07] <danilos> cjwatson: LP has complicated rules for that
[10:08] <danilos> cjwatson: if ubiquity translation was provided through Launchpad when there was no previous imported translation, when you upload debian-installer translation, debian-installer translation wins
[10:09] <danilos> cjwatson: if there was an ubiquity translation which overrides already imported translation, the existing one in LP wins
[10:10] <cjwatson> should I perhaps manually merge the ubiquity translations before uploading?
[10:10] <cjwatson> I think in general the ubiquity translations ought to win
[10:13] <davmor2> evand: I'm taking a pot shot guess here at the fact your not liking devicekit-disks something to do with usb creator?
[10:15] <evand> yeah, formatting
[10:22] <davmor2> evand: can you not use the format tool that is already in place.   If you right click the icon on the desktop you can select format now?
[10:22] <evand> no, it's not that simple
[10:23] <davmor2> evand: Why?
[10:24] <evand> I'm starting off with the same basic method as that code, but I then need to immediately write a partition table, partition, and filesystem to the disk, and devkit isn't updating its view of the disk quickly enough
[10:36] <davmor2> evand: ah that's a bit of a bummer.
[10:38] <cjwatson> danilos: ^- just highlighting in case you didn't see my questions above ...
[10:44] <danilos> cjwatson: right, thanks, that helps :)
[10:44] <danilos> cjwatson: yeah, you can merge them if you want to be certain
[10:44] <cjwatson> ok, I think I'll do that then
[10:45] <danilos> cjwatson: basically, that's the behaviour LP used to have (i.e. LP translations always won), but due to repeated requests from translators working in both upstream and ubuntu translation teams, we've changed it (and I believe it works better for everything but a few cases like we've got here)
[10:45] <cjwatson> yeaah
[10:45] <cjwatson> -a
[11:13] <CIA-33> ubiquity: cjwatson * r3440 ubiquity/debian/ (14 files in 2 dirs): Update translations from Launchpad.
[11:20] <cjwatson> danilos: ok, thanks. Uploaded now and we'll see how it works out ...
[11:20] <cjwatson> oh, bah, maybe not
[11:20] <danilos> cjwatson: what's going on?
[11:20] <cjwatson> danilos: lp-translations-tools-upload says "Warning: Transient problem: HTTP error"
[11:20] <cjwatson> (repeatedly)
[11:21] <cjwatson> danilos: http://paste.ubuntu.com/269062/
[11:22] <cjwatson> hmm, maybe I need to re-login
[11:22] <danilos> cjwatson: perhaps
[11:22] <danilos> cjwatson: also, note that our import queue is halted again (we've had some critical issue last night, we need to figure out what's going on)
[11:24] <cjwatson> ah, not logged in, my cookie must have expired
[11:26] <cjwatson> danilos: there we go, much better, sorry to bother you
[11:26] <danilos> cjwatson: not at all, happy to see it working :)
[11:26] <danilos> cjwatson: also, we sometime trash the session database when we have a problem with it (I know we did it something like ~1 month ago or so)
[11:28] <cjwatson> yeah, I think that was it
[11:28] <cjwatson> I'll go ahead and upload new debian-installer content as well now, then
[11:47] <CIA-33> ubiquity: cjwatson * r3441 ubiquity/ (debian/changelog ubiquity/components/partman.py): Fix method name to allow page changing in partitioner (LP: #427347).
[11:51] <CIA-33> ubiquity: cjwatson * r3442 ubiquity/ (bin/ubiquity debian/changelog):
[11:51] <CIA-33> ubiquity: Fix oem-config crash if the KDE frontend is detected, due to trying to
[11:51] <CIA-33> ubiquity: delete UBIQUITY_MIGRATION_ASSISTANT from the environment when it's not
[11:51] <CIA-33> ubiquity: there (LP: #414854).
[12:20] <cjwatson> evand: I narrowed down bug 425011 a bit
[12:21] <evand> ah, good deal
[12:22] <cjwatson> I was wondering if build_shortlist_region_pairs should use debian-installer/country if there's no shortlist, or something
[12:22] <cjwatson> although of course we should also disable Forward unless a region/zone is selected to avoid the crash
[12:24]  * evand digs
[12:29] <CIA-33> ubiquity: cjwatson * r3443 ubiquity/ (bin/ubiquity-dm debian/changelog):
[12:29] <CIA-33> ubiquity: Stop ubiquity-dm crashing if a process it's trying to kill doesn't exist
[12:29] <CIA-33> ubiquity: (LP: #423700).
[12:38] <cjwatson> BTW we ought to have a ubiquity upload at some point today as the manual partitioning regression (427347) was pretty serious
[12:40] <evand> absolutely
[13:02] <cody-somerville> cjwatson, Do you know if its possible to mount the install media via NFS? If not, would it be appropriate for cdrom-detect to grow that functionality?
[13:02] <cjwatson> no and no
[13:02] <cjwatson> it's been on the wishlist forever to write an NFS retriever
[13:02] <ogra> cody-somerville, why dont you use netinst and http ?
[13:02] <cjwatson> but it doesn't belong in cdrom-detect
[13:03] <cjwatson> (imo, anyway)
[13:04] <cody-somerville> ogra, because I want the full power of the installer - some udebs rely on the files from the installation media being present.
[13:05] <ogra> hmm, wouldnt the mini.iso solve that (not sure we build that though)
[13:07] <cody-somerville> Yes. That could be used to solve that but I'd like to be able to net boot the solution as well
[13:07] <cody-somerville> Basically, the idea is to be able to perform a normal install like you had local install media without the install media actually being local.
[13:08] <cjwatson> it would fit better into d-i's design to treat the NFS-mounted thing as a mirror rather than as CD media
[13:08] <cjwatson> if nothing else because the network is typically not up yet when cdrom-detect is run
[13:09] <cjwatson> that would make it a relatively simple matter of writing an analogue to net-retriever (or possibly even extending net-retriever), and patching a few things like choose-mirror and such that only expect ftp/http for mirrors
[13:09] <cjwatson> if that were done well we'd take it upstream
[13:09] <cody-somerville> But a mirror does not contain the same files - for example, it doesn't have the live system's squashfs.
[13:10] <cjwatson> I'm sorry that you chose to use a crazy design O:-)
[13:10] <cjwatson> network access just won't fit into cdrom-detect
[13:11]  * cody-somerville nods.
[13:11] <cody-somerville> Thats understandable.
[13:11] <cjwatson> if you really want to NFS-mount something on /cdrom, it'd have to be a separate component that could go in the netboot initrd
[13:11]  * cody-somerville nods.
[13:11] <cjwatson> nfs-detect would be fine I guess
[13:11] <cjwatson> less upstreamable, though
[13:12] <cjwatson> maybe not "-detect", I guess you can't detect this in any reasonable way, it has to be a question
[13:12] <cjwatson> you could ask the Debian Live people if they've thought about this
[13:14]  * cody-somerville nods.
[13:16] <cody-somerville> Booting a live system and using ubiquity would be pretty easy using nfsroot, eh?
[13:17] <cjwatson> should be, modulo casper bugs - it does at least theoretically support it
[13:17] <cjwatson> not often tested of course
[13:30] <CIA-33> partman-auto-loop: cjwatson * r50 ubuntu/.bzrignore: update ignores
[13:30] <xivulon> hi cjwatson your script looks mostly fine (thanks)
[13:31] <xivulon> not sure you need the loopback/set root in there
[13:31] <xivulon> also shouldn't it be "lupin_entry" in line 124? (sorry cannot test it now)
[13:31] <cjwatson> yeah, it should, thanks
[13:32] <cjwatson> why wouldn't I need loopback/set root?
[13:33] <cjwatson> gotta read the kernel/initrd somehow
[13:33] <xivulon> because root will already be set by the embedded cfg, otherwise I wouldn't even be able to read the linux side cfg
[13:34] <cjwatson> ah, so we put the loopback/set root there?
[13:34] <xivulon> well it has to be there anyway, you can put it also in the main one, but it does not add anything
[13:35] <cjwatson> yeah
[13:35] <cjwatson> we'll need to take some care to avoid root getting overwritten by the standard configuration stuff though
[13:35] <cjwatson> not entirely trivial
[13:36] <cjwatson> so wubildr.cfg would look a bit like http://paste.ubuntu.com/269136/
[13:39] <cjwatson> maybe we need to extend prepare_grub_to_access_device to avoid problems later
[13:40] <xivulon> yes that is similar to what I have in my local branch, /ubuntu/install/boot/grub/grub.cfg can probably stay, that one loads the ISO for unattended installation, there is no /ubuntu/install/root.disk
[13:40] <cjwatson> ah
[13:41] <cjwatson> I'm putting together a grub2 upload at the moment; needs some more testing of my timeout changes though
[13:41] <cjwatson> I'm including the 64-bit NTFS and loopback/root fixes
[13:42] <xivulon> if you have them in your ppa I can test them tonight
[13:47] <cjwatson> I don't, but I hope to have them in the archive tonight
[14:12] <xivulon> fantastic!
[16:10] <davmor2> evand, shtylman: on kubuntu Live I have enabled the encrypted Home Partition.  I get a light bulb icon on the taskbar.  When I click on it I get the "Record your encrypted passphrase" however when I click on Run this action now all I get is a root terminal by the look of it.
[16:16] <evand> davmor2: please file a bug on ecryptfs-utils
[16:16] <davmor2> evand: No Probs
[16:41] <davmor2> evand: don't worry it's me.  The text box explains what to do it's just it got covered by the terminal window.
[16:41] <evand> okay
[17:00] <CIA-33> ubiquity: evand * r3444 ubiquity/ (debian/changelog ubiquity/components/ubi-timezone.py):
[17:00] <CIA-33> ubiquity: Don't let the user proceed past the timezone page until a selection has
[17:00] <CIA-33> ubiquity: been made (LP 425011).
[17:00] <evand> still trying to work out the rest
[17:01] <cjwatson> cool, thanks
[17:01] <cjwatson> you weren't intending that changelog to close the bug?
[17:01] <evand> correct
[17:01] <evand> I thought the proper solution was to actually select Warsaw automatically
[17:02] <cjwatson> yeah
[17:02] <evand> I'll be around for a few hours tonight.  If I can't figure it out by the time I have to scurry, I'll release what we have.
[17:03] <cjwatson> ta
[17:59] <diogo_79> hi guys
[17:59] <diogo_79> i am trying to install ubuntu in raid0 mode
[17:59] <diogo_79> can some one help me
[18:00] <diogo_79> i have create the raid0 with an alternate disk
[18:00] <diogo_79> but the boot loader is not install
[18:00] <diogo_79> and i dont know hbow to install
[18:02] <diogo_79> any one?
[18:09] <diogo_79> anyone?
[18:13] <CIA-33> ubiquity: jriddell * r3445 trunk/ (bin/ubiquity-wrapper debian/changelog): Update path to kdesu in ubiquity-wrapper
[18:29] <diogo_79> anyone?
[18:39] <cjwatson> diogo_79: sorry, it's the end of my day's work and I don't really have time to dive into this now - please see the topic for what to do when you don't get a response (the answer is not to repeat your question)
[18:40] <cjwatson> diogo_79: you will need to include full installation logs (syslog and partman) for anyone to be able to help
[19:16] <rgreening> hey evand, how goes policykit in usb-creator and the format backend issue?
[19:17] <evand> rgreening: I've been working on the format issue most of the day
[19:17] <evand> one bug fixed
[19:17] <evand> in devicekit
[19:17] <evand> working on another
[19:17] <rgreening> awesome
[19:18] <rgreening> I'm waiting for pitti (or someone) to look at my intltool/python-distutils-extra bug so we can get translations working for KDE front-end.
[19:18] <rgreening> so, we are getting pretty close to a finished product
[19:19] <evand> wonderful
[19:19] <evand> go team
[19:25] <CIA-33> ubiquity: evand * r3446 ubiquity/ (d-i/manifest debian/changelog):
[19:25] <CIA-33> ubiquity: Automatic update of included source packages: partman-auto
[19:25] <CIA-33> ubiquity: 89ubuntu1, partman-partitioning 71ubuntu1.
[19:26] <CIA-33> ubiquity: evand * r3447 ubiquity/debian/real-po/ (81 files): debconf-updatepo
[19:26] <rgreening> hehe
[19:38] <CIA-33> ubiquity: evand * r3448 ubiquity/debian/changelog: releasing version 1.99.18
[22:01] <CIA-33> usb-creator: rgreening * r176 trunk/usbcreator/ (backends/base/backend.py misc.py): * Enforce a MAX_PERSISTENCE of 4GB, otherwise dd fails tring to create a file > 4GB
[22:02] <CIA-33> usb-creator: rgreening * r177 trunk/debian/changelog: * Update changelog
[23:02] <xivulon> cjwatson will the packages be available soon?