[09:03] <mgz> morning all
[09:04] <mgrandi> heya
[09:08] <mgrandi> hey mgz, i'm available for said debugging stuff that we have been putting off forever
[09:08] <mgrandi> haha
[09:12] <mgz> hm, okay, where did we leave off?
[09:12] <mgz> with some meliae bugs to fix?
[09:12] <mgrandi> haha, good question, ill look at the logs
[09:12] <mgrandi> i believe i got the win7 sdk
[09:13] <mgrandi> and i had to recompile something cause it was not using the same version
[09:13] <mgrandi> and that was causing the meliae dumps to be incorrect
[09:16] <mgz> so, to start with, reproducing with 2.5.0 which is 32bit would be fine
[09:17] <mgz> which avoids the 64bit specific issues we had and the need to recompile things
[09:18] <mgrandi> so, just go back to the beginning and try to fast-import linux again?
[09:20] <mgz> yep, though you could pick a smaller branch and force the memory dump too
[09:20] <mgrandi> how do i do that?
[09:22] <mgz> well, manually, run the operation, wait till progress indication says it's near the end (or reaches max mem usage seen on a previous run),
[09:22] <mgz> then ctrl+break to get in with pdb
[09:23] <mgz> import sys, bzrlib.trace; bzrlib.trace._dump_memory_usage(sys.stderr)
[09:23] <mgrandi> k
[09:23] <mgz> then load the file that generates with meliae
[09:24] <mgrandi> should it be a fairly large branch but not a huge one like linux? =P
[09:27] <mgz> yup, something like that
[09:27] <mgz> just so the dump file isn't insane to try and understand
[09:28] <mgrandi> i'll try rails, big but not huge
[09:40] <mgrandi> well
[09:40] <mgrandi> things are off to a good start
[09:40] <mgrandi> bzr: ERROR: 36508955: Parse error: line 36508955: Timezone '+051800' could not be converted.
[09:41] <jelmer> is this importing a fastimport file ?
[09:41] <mgrandi> yeah
[09:41] <mgrandi> git fast-export --all --signed-tags=strip --progress=1000
[09:44] <mgrandi> the line in the file seems to be
[09:45] <mgrandi> author Vijay Dev <vijaydev.cse@gmail.com> 1312735823 +051800
[09:46] <jelmer> which repo is that?
[09:47] <jelmer> that definitely looks like an invalid timezone line
[09:47] <mgrandi> git://github.com/rails/rails.git
[09:48] <mgrandi> lets see if i can find the commit
[09:53] <mgz> mgrandi: maybe just try linux again while trying to work out why rails doesn't export?
[09:54] <mgrandi> yeah
[10:00] <mgrandi> jelmer, it seems that its listed in git as an invalid timezone too: , git  commit 4cf94979c9f4d6683c9338d694d5eb3106a4e734
[10:00] <jelmer> ah, interesting
[10:00] <mgrandi> https://github.com/rails/rails/commit/4cf94979c9f4d6683c9338d694d5eb3106a4e734
[10:00] <jelmer> I've requested an import on Launchpad, wondering what that will yield
[10:01] <mgrandi> yeah, a git log --grep <wahtever. says the date is Mon Aug 29 06:50:23 2011 +51800
[10:02] <jelmer> so I guess one of the options is to make bzr-fastimport just warn on invalid timezones and fall back to UTC
[10:03] <mgrandi> is that a valid timezone?
[10:03] <mgrandi> github seems to make something out of it
[10:03] <mgrandi> i'll start the linux one while we wait haha
[10:03] <jelmer> it is definitely an invalid timezone
[10:03] <jelmer> anything over 12 hours would be invalid
[10:04] <jelmer> this is 518 hours
[10:04] <jelmer> actually, anything over 14 or something I guess
[10:05] <mgrandi> wonder if thats a git bug, heh
[10:05] <mgrandi> either way , bzr should probably handle invalid timezones. should i file a bug for this?
[10:05] <jelmer> s/bzr/bzr-fastimport/ but yeah
[10:06] <mgrandi> well i meant that git accepted an invalid timezone
[10:07] <mgrandi> what should i file it under
[10:12] <jelmer> mgrandi: bzr-fastimport
[10:19] <mgrandi> and jelmer , https://bugs.launchpad.net/bzr-fastimport/+bug/959154
[10:26] <jelmer> mgrandi: where do you see the date/timezone on the github page?
[10:26] <mgrandi> if you hover over "authored 8 months ago" next to his username under the blue box title thingy
[10:27] <mgrandi> im assuming that is converted to your timezone (from your github account)
[10:27] <jelmer> mgrandi: ah, I see
[10:28] <jelmer> urgh, that is 22 days off.. they simply seem to interpret the timezone as an offset
[10:28] <mgrandi> yeah
[10:29] <mgrandi> weird o.o
[10:30] <mgrandi> finding bugs all over the place haha
[10:34] <jelmer> mgrandi: I wouldn't really consider this a defect in bzr-fastimport, rather a bug in git we can be more tolerant of.
[10:35] <mgrandi> true
[10:41]  * mgrandi waits for the stupid fast-export to finish
[10:48] <jh> is there an elegant way to create multiple patches from a bzr-repo and them to apply them to a avn-repo? conserving the commit-messages in any way?
[10:49] <jelmer> jh: the reverse is possible with "bzr svn-import", but there's no way to push a set of bzr branches into a svn repository, just one at a time
[10:50] <jh> ok
[10:51] <jh> then the best way seems to be to do multiple "bzr diff -c <rev> --format=svn > <rev>.diff" and copy the commit messages manually...
[10:51] <jelmer> jh: once we polish the UI for colocated branches a bit more this would be one of the things that would automatically be supported
[10:51] <jelmer> jh: that shouldn't be necessary, you can "bzr push" from the branches
[10:51] <jelmer> you just have to do it one branch at a time
[10:52] <jh> iirc, bzr push said something about no common ancestors
[10:52] <jelmer> jh: the bzr branches you're using aren't derived from the svn branches you're pushing to?
[10:53] <jh> right... some automatism replicates every svn commit into the bzr-repo
[10:54] <jh> so they are identical, but the bzr-repo is not derived from the svn-repo
[10:55] <jelmer> ah, in that case bzr indeed can't help you
[10:57] <jh> ok
[11:00] <mgrandi> well, now that i have a 22.7 gb fastexport file, time to import it
[11:00] <mgrandi> should i just leave it on for a couple of hours and then do the pdb thing mgz?
[11:10]  * mgrandi whines
[11:10] <mgrandi> bzr: ERROR: 881736312: Parse error: line 881736312: Command tag is missing section tagger
[11:13] <mgz> mgrandi: you want to do `bzr -Dmem_dump ...` on the import
[11:13] <mgz> and maybe induce it to run out of memory a little early by leaving it less than your full amount
[11:14] <mgz> but the export does need tobe loadable..
[11:14] <mgrandi> trying to print out the line in question
[11:16] <jelmer> mgrandi: I suspect you're hitting another case where stricly speaking fastimport requires a tagger for exported tags
[11:17] <jelmer> but there's an entry in the kernel repo where there's no tagger
[11:17] <mgrandi> is it because i did --signed-tags=strip?
[11:17] <jelmer> I'm not sure
[11:23] <mgrandi> well
[11:23] <mgrandi> its late here, i'll have to continue this later, i'll get to a point where i can pdb into some semi large git repo
[11:23] <mgrandi> for now, night~
[11:58] <Riddell> what could this mean?
[11:58] <Riddell> 11:56 <apol> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/~cyberspace/cyberspace/muon-packaging": no supported schemes
[11:58] <jelmer> Riddell: perhaps paramiko not installed?
[11:58] <Riddell> jelmer: he says it is
[11:59] <mgz> ugh, that's generally something specific but I'm failing to remember what
[11:59] <apol> hi Riddell
[11:59] <Riddell> mgz: it means bzr doesn't know about bzr+ssh for some reason?
[11:59] <jelmer> apol, Riddell: is that while pushing to that branch, because it doesn't seem to exist.
[11:59] <Riddell> apol: can you pastebin the last chunk in ~/.bzr.log ?
[12:00] <Riddell> jelmer: right, first time of pushing (he also just added his ssh key to launchpad)
[12:00] <mgz> do the normal ssh debugging steps just to check that
[12:01] <Riddell> apol: can you ssh bazaar.launchpad.net ?
[12:01] <mgz> `ssh your_launchpad_username@bazaar.launchpad.net`
[12:01] <mgz> which should connect then say there are no shells
[12:01] <mgz> and I'll grep logs and mail to see if I can remember the context this came up before
[12:02] <apol> let's see...
[12:03] <apol> Riddell, mgz: http://paste.kde.org/442808
[12:03] <Riddell> apol: got a ~/.bazaar/bazaar.conf with the right username?
[12:03] <Riddell> [DEFAULT]
[12:03] <Riddell> launchpad_username = jr
[12:04] <apol> Riddell: oh, there's none
[12:04] <apol> I'll add it
[12:04] <apol> Riddell: now it worked
[12:05] <wgz> bug 854713
[12:05] <wgz> so, it's not having done launchpad-login plus some oddness
[12:05] <Riddell> apol: great, mgz: that error message could do with being improved :)
[12:06] <wgz> should be able to say the branch doesn't exist in that case, rather than getting confusing follow-on error
[12:07] <apol> :)
[15:30] <ams_cs> jelmer: hi, any news on my lp:gcc/4.7 problem from last week?
[15:47] <lamalex> is it possible to shelve changes from a branch, and unshelve them into a different branch?
[15:59] <mgz> lamalex: not trivially
[16:01] <lamalex> well diff > into a patch
[16:01] <mgz> okay, you can do that trivially, but it's not exactly the same
[16:02] <mgz> `bzr unshelve --preview -d FROM|patch ...`
[16:20] <jelmer> lamalex: 'bzr merge --uncommitted' is perhaps whaqt you're looking for?
[16:20] <jelmer> ams_cs: not really, I'm still investigating but it's a nontrivial problem :-/
[16:21] <lamalex> jelmer, ah perhaps
[16:21] <lamalex> indeed
[16:21] <lamalex> thanks jelmer
[16:21] <ams_cs> jelmer: is there a work around?
[16:21] <ams_cs> jelmer: a reimport, perhaps?
[16:22] <jelmer> ams_cs: a reimport would fix the issue, but it's the data in lp:gcc-linaro that's problematic, not the data in lp:gcc/4.7
[16:23] <ams_cs> jelmer: oh, so merge to lp:gcc/trunk would be ok, for example (not that that would be a sensible thing to do)
[16:24] <ams_cs> jelmer: lp:gcc-linaro/4.7 (not lp:gcc-linaro, which is 4.6 based) is a very shallow branch, only recently merged from lp:gcc
[16:25] <ams_cs> jelmer: the merge was before the 4.7 branch point, so logically, I'd expect everything to be ok
[16:25] <jelmer> ams_cs: I'm not sure if a merge to lp:gcc/trunk would be ok
[16:25] <jelmer> ams_cs: we could possibly fix the issue manually for just lp:gcc-linaro/4.7, if it's really urgent for you guys
[16:26] <jelmer> that might be easier to do short term than to fix the underlying bug to recover from these situations
[16:28] <ams_cs> jelmer: it's not urgent right now, but in about 3 weeks time it will be!
[16:34] <jelmer> ok, that's good to know
[18:33] <kirkland> howdy!  I'm working in bzr with a colleague who's more familiar with git.  he's asking me for the equivalent of 'git rebase' in bzr ... do we have anything like that?
[18:34] <kirkland> uncommit -> shelve -> merge -> commit -> unshelve -> commit?
[18:38] <mgz> kirkland: for people who make heavy use of staging in git and never actually merge for progress,
[18:40] <mgz> just using shelve straight up is a near-ish match, provided you set an editor so 'e' works
[18:40] <mgz> for actual uses of rebase to do fancy things, can either use uncommit, or the rebase plugin, or quite often branching from an older revision then cherrypick merges
[18:46] <kirkland> mgz: cool, thanks!
[18:46] <kirkland> mgz: I'll check out the rebase plugin
[18:46] <kirkland> cmars232: ^
[18:48] <cmars232> kirkland mgz: thanks!
[19:16] <mgrandi> hey mgz, jelmer if you are there
[19:16] <wgz> hey
[19:16] <mgrandi> i tried like 4 different git repos and they are all are failing on fastimport
[19:16] <mgrandi> due to the error i posted last night, forget what it is exactly
[19:16] <wgz> on the import, or the export?
[19:16]  * wgz scrolls up
[19:16] <mgrandi> git fast-export works fine
[19:17] <mgrandi> but then i do bzr fast-import <something.fe> <bzr_repo> and it fails due to something about tagger
[19:17] <mgrandi> so im not sure what happened
[19:17] <mgrandi> but it seems that fast-import-from-git is broken
[19:18] <wgz> okay, I can't find an existing bug report for that
[19:19] <wgz> report it... against whichever of bzr-fastimport or python-fastimport is raising the exception
[19:19] <mgrandi> ok,
[19:19] <mgrandi> ill do it on my mac real fast since im at werk
[19:20] <wgz> :)
[19:20] <mgrandi> i really like how
[19:20] <mgrandi> this bug refuses to get fixed
[19:20] <mgrandi> cause we keep getting on tangents >.>
[19:27] <jelmer> mgrandi: try --fake-missing-tagger as argument to 'git fast-export'
[19:27] <mgrandi> i'll try
[19:27] <mgrandi> what is this missing tagger thing that its complaining about though?
[19:27] <jelmer> mgrandi: see the git-fast-export manpage
[19:27] <jelmer> to quote:
[19:27] <jelmer> Some old repositories have tags without a tagger. The fast-import protocol was pretty strict about that, and did not allow that. So fake a tagger to be able to fast-import the output.
[19:29] <mgrandi> yeah i read that, but what is a 'tagger'?
[19:29] <jelmer> somebody who created an annotated tag (in git)
[19:29] <mgrandi> ah
[19:29] <mgrandi> interesting how it worked the first time when i first reported the bug
[19:29] <mgrandi> but now it doesn't work
[19:29] <mgrandi> without the fake-tagger
[19:31] <jelmer> mgrandi: I think I miss some context - what do you mean with how it worked the first time you reported the bug?
[19:31] <mgrandi> like, first time i tried this just for fun, fast-importing the linux kernel git repo
[19:31] <mgrandi> it worked fine, it didn't complain about missing taggers or anything
[19:32] <mgrandi> like, late 2011
[19:32] <mgrandi> now i did it again and it complains
[19:33] <mgrandi> when you think that it would of not imported correctly because of missing taggers when i first did it
[19:38] <jelmer> mgrandi: is it actually bzr-fastimport that complains about the missing tagger? What's the exact message?
[19:39] <mgrandi> one sec, exporting a git repo on my computer since im on a diff comp
[19:46] <mgrandi> why does the mac version of bzrnot have fastimport >.>
[19:50] <mgrandi> jelmer: exact error: http://bpaste.net/show/25494/
[19:53] <mgrandi> but with --fake-missing-tagger it works.
[19:53] <jelmer> mgrandi: I'm pretty sure that code hasn't changed in a long time
[19:54] <mgrandi> yeah, i just remember not ever knowing about --fake-missing-tagger or any of the other arguments to git fast-export when i did it months ago
[19:54] <jelmer> mgrandi: did you perhaps use 'bzr fast-export-from-git' rather than git-fast-export?
[19:55] <mgrandi> thats probably what i did
[19:57] <mgrandi> im assuming fast-export-from-git makes sure that it uses --fake-misisng-taggers?
[19:57] <jelmer> mgrandi: that might explain it; I think it specified a few funky options
[19:57] <jelmer> it seems it specified --signed-tags=warn
[19:58] <mgrandi> i had to add that, but that doesn't seem to be the same problem
[19:59] <mgrandi> git's fast-export won't finish if you don't say --signed-tags=warn/drop/whatever
[20:31] <mgrandi> and wgz, i seemingly can't import 'loader' from meliae, it gives me: ImportError: cannot import name _intset
[20:32] <jelmer> mgrandi: did you compile meliae?
[20:32] <mgrandi> i ran setup.py install
[20:32] <mgrandi> llvm-gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 build/temp.macosx-10.7-intel-2.6/meliae/_intset.o -o build/lib.macosx-10.7-intel-2.6/meliae/_intset.so
[20:33] <mgrandi> i assume it compiled it from the output there ^
[20:33] <jelmer> ah, hmm
[20:34] <mgrandi> how can i tell why its unable to import it?
[20:37] <jelmer> 'python -c import meliae._intset'
[20:37] <jelmer> ehm
[20:37] <jelmer> python -c 'import meliae._intset'
[20:38] <mgrandi> ImportError: No module named _intset
[20:38] <jelmer> mgrandi: did it install that file properly?
[20:38] <mgrandi> yet i see _intset.so in the meliae directory in site-packages
[20:38] <jelmer> mgrandi: are you still in the meliae source while you're running this perhaps?
[20:39] <mgrandi> well im on a mac so i shouldn't be getting access errors
[20:40] <mgrandi> i think its because of the different versions of python on my mac haha
[20:40] <mgrandi> one sec
[20:43] <mgrandi> im so confused, it doesn't wnat to import that file >.>
[20:45] <mgrandi> annnd i'm stupid. i think i was running it on the desktop where the meliae source was so it was trying to import that
[20:49] <mgrandi> so now i have the memory dump, on mac at least, if wgz or anyone else wants to look at it now
[20:51] <jelmer> I think murphys law dictates that wgz now will have disappeared.
[20:51] <mgrandi> haha
[21:01] <wgz> K
[21:01] <wgz> ..I was having dinner, even
[21:02] <wgz> so, the import stage was completed, the boss defeated, and we're on to the dump understanding stage?
[21:03] <mgrandi> haha
[21:04] <mgrandi> yes, on my mac, not windows but close enough i guess
[21:04] <mgrandi> even though ive noticed the same trend, with the import getting slower and slower
[21:04] <mgrandi> but here is the summary: http://bpaste.net/show/25499/
[21:05] <wgz> that's not too bad looking, what was the total repo size?
[21:06] <mgrandi> 47.7 MB
[21:06] <mgrandi> its the 'git' git repo haha
[21:07] <mgrandi> i can try it with something bigger now that i know why its failing
[21:07] <mgrandi> why it was failing*
[21:07] <wgz> hm, that's not quite so good then.
[21:19] <mgrandi> any ideas?
[21:27] <wgz> well, 100MB or so is probably uncompressed bytes cache
[21:27] <wgz> if you bzip the dump file, is it small enough to upload somewhere?
[21:32] <mgrandi> yeah, let me do that
[21:43] <mgrandi> wgz, http://kramidnarg.com/tmp/dump.tgz
[21:52] <wgz> getting
[22:13] <mgrandi> let me know if you need anything, i still have the pdb session running
[22:26] <wgz> most of my little scripts are on the box upstairs so I'll probably leave poking till tomorrow morning
[22:36] <mgrandi> ok.
[22:48] <mgrandi> i'll be on sometime tommrow so let me know what you find i guess!
[22:57] <wgz> will do.
[23:25] <Omega_> Hey all.  I'm looking to start a project using bzr, however some of the initial boilerplates are done using git projects.
[23:25] <lifeless> go on...
[23:25] <Omega_> Is there a way I can have the git and bzr projects coexist?  I'm dealing only with dependencies, so I won't ever be committing my code to them.
[23:26] <lifeless> I don't see why not
[23:26] <lifeless> what happens when you try
[23:27] <Omega_> It would be nice if I could update those dependencies using git (as new stuff comes out), but have my own project and the surrounding structure tracked with bzr
[23:27] <mgrandi> you can, you can branch git repos
[23:27] <Omega_> I haven't yet as I'm being a little cautious about how I start this.
[23:27] <lifeless> is this your first use of bzr?
[23:27] <lifeless> if so, dive in - if you get it wrong you can always rearrange things
[23:28] <mgrandi> it sounds like you want a nested tree
[23:28] <mgrandi> which i dont think bzr supports yet
[23:28] <lifeless> and you won't have the experience yet to predict issues / non-issues yet.
[23:28] <mgrandi> having a bzr tree, with nested bzr-git trees
[23:28] <lifeless> mgrandi: there is a plugin that does nested trees
[23:28] <lifeless> scmproj I think its called
[23:28] <mgrandi> but, do you need to push to a git repo?
[23:29] <mgrandi> or are you just using bzr, but using git to get the other code
[23:29] <Omega_> No, I'm only consuming their code.
[23:29] <mgrandi> ok
[23:29] <mgrandi> then you can branch git repos
[23:30] <mgrandi> and if you want to set up the nested trees, then you can try that plugin
[23:30] <mgrandi> and things should be fine~
[23:30] <Omega_> I'm only getting started with bzr so I'd like to keep the curve down
[23:30] <mgrandi> its pretty simple, you will just need bzr-git, which you can get from launchpad
[23:30] <mgrandi> if its not included in bzr already
[23:30] <Omega_> I'm on Ubuntu, maybe it's already available.
[23:31] <fullermd> If all they are is "things in git I stick in particular places in my branch", you can just ignore it totally and just leave them independent pieces you git.
[23:31] <fullermd> Drawback is you'd have to set them in place manually when duplicating your setup, but...
[23:32] <fullermd> I'd eat that and stick with the conceptually trivial.  Worry about it when it's worth worrying about.
[23:33] <mgrandi> yeah
[23:33] <Omega_> Would be nice if bzr had a way to blend in git submodules.
[23:33] <mgrandi> or you can just
[23:33] <mgrandi> download a zip of the git code
[23:33] <mgrandi> and stick it in, and not worry about git at all
[23:33] <Omega_> The thought has crossed my mind.
[23:33] <mgrandi> also, wgz, it seems fast import failed at the end
[23:33] <mgrandi> http://bpaste.net/show/25508/
[23:33] <mgrandi> Omega_: and then just updated it when stable releases come out, thats usually what i do
[23:33] <fullermd> Well, that probably would follow after bzr has a way to blend in bzr submodules  8-}
[23:34] <mgrandi> im not sure what you mean by blend in
[23:34] <Omega_> The project includes some git submodule dependencies as well
[23:34] <fullermd> You could always just use a bzr-git bridge or something to get the code into bzr, then just merge it in like a vendor branch from there.
[23:34] <fullermd> Whether you care about carrying around the weight of that history would bear on it.
[23:36] <Omega_> So my first step would be to initialize my bzr repo and then use bzr-git to "clone" in that repo.
[23:36] <Omega_> Then start doing git operations on it to resolve its dependencies?
[23:36] <fullermd> If it were me, my first step would be to initialize your bzr repo, then use git (or mv or cp or whatever) to stick git repos contianing the git bits in the right places in the tree, and ignore them from bzr.
[23:37] <fullermd> If you wind up needing bzr to somehow manage them anyway down the line, you'd have a better feel for bzr and just what you need then, and 'll wind up with a better decision on details then anyway.
[23:38] <mgrandi> anyway, going home, laters all
[23:40] <Omega_> fullermd: I'm thinking I'm just going to get the whole git repo set up and then lift it into a bzr
[23:40] <Omega_> I'm getting a feeling that there's a flaw in the git-side's distribution model.
[23:41] <Omega_> Too much code living everywhere.
[23:41] <Omega_> Mixed together.
[23:41] <Omega_> What does bzr do when it sees a .git dir?
[23:41] <lifeless> nothing, unless you have bzr-git installed
[23:41] <Omega_> Is there a way I could get on with things and have the two pretend like the other just doesn't exist?
[23:42] <fullermd> That's what I was aiming at there.
[23:42] <Omega_> fullermd: Solid.
[23:42] <fullermd> Just stick a git repo inside your bzr branch in the filesystem.  Use 'bzr ignore $GITDIR' to make bzr not bother looking at it.
[23:43] <Omega_> Neat, I'll play away.  I've been using git to good effect although I like some of the community/launchpad aspects of bzr.  So I want to become proficient with it.
[23:43] <Omega_> From everything I'm hearing, it's fairly simple.  Thanks for the help, I'm sure I'll be back with more questions.
[23:45] <maxb> bzr is kind of like git, except with a UI that mere mortals can understand without a headache, and an awesome plugin infrastructure
[23:46] <Omega_> maxb: Being approachable with good cross platform and a creat collaboration tool like launchpad really puts all the points where they count.
[23:48] <Omega_> *great
[23:53] <poolie> hi all
[23:56] <lifeless> morning poolie
[23:56] <poolie> hi there