[13:54] <fta> wgrant, ping
[19:15] <verterok> jelmer: around?
[19:15] <verterok> hi
[19:16] <verterok> I'm having some problems while trying to import a git branch, the lp branch is: https://code.launchpad.net/~verterok/boto/trunk-git
[19:16] <verterok> and I'm getting this error: http://launchpadlibrarian.net/61677251/verterok-boto-trunk-git.log
[19:16] <verterok> any ideas? should I file a bug? :)
[19:30] <jcsackett> hi verotek, sorry i didn't see your question earlier.
[19:30] <jcsackett> abentley, do you know anything about a code import difficulties, or who might be best to ask?
[19:31] <jcsackett> verterok, sorry. i mistyped your name above.
[19:31] <abentley> jcsackett, you could ask jelmer.  It doesn't look specific to launchpad.
[19:31] <verterok> jcsackett: hi, np :)
[19:32] <verterok> jcsackett: looks like a bug in dulwich/bzr-git...I'm getting the same failure locally :(
[19:32] <jcsackett> verterok: ah. i'm not sure then. i see you already pinged jelmer.
[19:33] <verterok> jcsackett: yes, I'll talk with him about how to workaround this. thanks!
[19:33] <jcsackett> verterok: no problem. sorry i wasn't exactly a help. :-)
[19:37] <abentley> verterok, I get the same issue with bzr-git tip.
[19:38] <verterok> abentley: yeap, it's a wrong utc offset: --700 instead of -0700 :/
[19:40] <abentley> verterok, please file a bug on bzr-git and Launchpad.  (The launchpad fix will need the bzr-git fix).
[19:40] <verterok> abentley: ok
[19:45] <verterok> abentley: done, thanks for trying it locally. the bug is: https://bugs.launchpad.net/dulwich/+bug/697828
[19:47] <abentley> verterok, thanks.
[20:37] <njin> Hello, is LP down?
[20:38] <micahg> wfm
[20:38] <njin> ok
[22:14] <dobey> how do i get a ~vcs-imports branch updated to point to the correct upstream repo? like for something that moved from svn to hg?
[22:19] <bjsnider> http://launchpadlibrarian.net/58709752/buildlog_ubuntu-maverick-amd64.gimp_2.7.3-2010110501~mm_FAILEDTOBUILD.txt.gz
[22:20] <bjsnider> that is listed as a build failure, but i can't see a reason
[22:20] <bjsnider> in fact it looks like it explicitly says it succeeded
[22:22] <wgrant> dobey: Import branches can't be changed from one type to another, so you'll need to create a new hg one.
[22:23] <wgrant> bjsnider: Look at the end of the log.
[22:23] <wgrant> Our automated build log filter detected the problem(s) above that will
[22:23] <wgrant> likely cause your package to segfault on architectures where the size of
[22:23] <wgrant> a pointer is greater than the size of an integer, such as ia64 and amd64.
[22:24] <dobey> wgrant: and how do i make it be trunk, and how do i make some reasonable team (which i am probably not a member of) be the owner?
[22:25] <wgrant> dobey: It's not clear what "reasonable team" means.
[22:25] <dobey> err, by "be trunk" i guess i mean "be the development target"
[22:25] <wgrant> dobey: You need to contact the project owner or an admin for that.
[22:42] <Blitzmerker> Hi, I tried to download the development source of gnome-media-player, but I there is a problem connecting to the Launchpad server
[22:46] <spiv> Blitzmerker: how did you try downloading it, and what problem did you see?
[22:46] <spiv> Oh, I see.
[22:46] <spiv> It's another one of these branches that is stacked on itself :(
[22:48] <spiv> thumper (or any other lp-code person): ~gnome-media-player-development/gnome-media-player/0.2 appears to be stacked on itself.
[22:48] <thumper> haha
[22:48] <thumper> not helpful I know
[22:50] <thumper> the LP branch page doesn't think it is stacked on itself
[22:52] <spiv> hpss call:   'Branch.get_stacked_on_url', '~gnome-media-player-development/gnome-media-player/0.2/'
[22:52] <spiv> result:   ('ok', '/~gnome-media-player-development/gnome-media-player/0.2')
[22:52] <spiv> Interesting that LP thinks differently, but I suppose LP gets its info updated by the branch scanner, which presumably can't open a self-stacked branch.
[22:53] <thumper> spiv: probably
[22:53] <thumper> we should set it back to what it was
[22:53] <thumper> then make it unstacked
[22:53] <spiv> I wonder how it got in that state in the first place.  A branch rename maybe?
[22:53] <thumper> no
[22:53] <thumper> well... maybe?
[22:53] <wgrant> It's normally a branch or person rename.
[22:53] <spiv> LP doesn't currently rewrite the stacked_on field when a branch is renamed, IIRC?
[22:56] <spiv> (Or alternatively, LP ought to be using the immutable branch ID and then dynamically rewriting that to the current name when reporting it to bzr or http clients)
[22:57] <spiv> That would innoculate against person and branch renames.  The rewrite-upon-rename solution would need to touch every branch a person owns as part of a person rename which is probably undesirable.
[22:58] <poolie> that would be nice
[23:51] <thumper> spiv: patches accepted :-)