=== yofel_ is now known as yofel
[06:40] <poolie> hi riddell
[06:51] <vila> hey poolie and others !
[06:53] <poolie> hi there
[06:53] <poolie> i'm giving udd config options to talk to staging lp to make it easier to debug/test stuff
[06:53] <vila> poolie: great !
[06:54] <vila> poolie: don't worry too much about using the stacked-based configs, I intend to upgrade udd when 2.4.x is deployed on jubany anyway
[07:46] <poolie> vila, so how about https://code.launchpad.net/~mbp/udd/configure/+merge/71822
[07:46] <poolie> oh also, while i'm here, can you see if you can get into the blog?
[07:46]  * vila looking
[07:47] <vila> poolie: this won't work until 2.4x is deployed I think
[07:49] <vila> poolie: meh, I'm out-of-date about iconfig
[07:50] <vila> gee, I didn't remember introducing a forward-compatible layer there...
[07:50] <poolie> ah, are you saying iconfig's present but can't be used?
[07:51] <vila> no no no, you're doing fine, my bad
[07:53] <poolie> thanks for thinking of it though
[07:54] <Riddell> hola
[07:55] <poolie> hi thar
[07:56] <jam> morning all
[07:56] <poolie> hi jam
[08:02] <vila> poolie: reviewed
[08:02] <vila> poolie: BB:tweak
[08:13] <poolie> thankss
[08:31] <poolie> i'll roll that out then
[08:38] <poolie> actually i might try to actually fix the httperrors first
[08:54] <jimis> I did a bzr switch, and an unexpected conflict happened
[08:54] <jimis> Can I undo and go back to previous branch to commit?
[08:55] <poolie> hi jimis
[08:56] <poolie> you can go back but i think that will carry back the conflicts
[08:56] <poolie> sorry
[08:56] <poolie> there ought to be a way to say 'i wish i never switched (or, merged, or whatever)' but there isn't yet
[08:58] <jimis> I was afraid of that :-(
[08:58] <jimis> anyway I understand that this workflow is not considered as mainstream for bzr
[08:58]  * jelmer waves
[08:58] <poolie> hi jelmer
[08:59] <jelmer> g'evening poolie
[08:59] <jimis> imho it should ask before switching, saying that a conflict has occured
[08:59] <vila> jimis: out of curiosity, what kind of unexpected conflict did you get ?
[09:00] <jimis> vila: I had changed a file but forgot to commit
[09:01] <jimis> so when I did "bzr switch other-branch" a conflict happened
[09:01] <jimis> and now I have to resolve it
[09:02] <vila> oh, so you wanted to commit it, not switch to the other branch carrying the change ?
[09:02] <jimis> wow, switching back created a double conflict :-o
[09:02] <vila> yeah, never a good idea to leave unresolved conflict
[09:02] <jimis> vila: no I wanted to switch, but I had forgotten to commit this particular file
[09:03] <vila> right, that what I meant, you wanted to commit *before* switching
[09:03] <jimis> that's what I should have done, yeah
[09:03] <vila> there are cases when you want to switch but still want to carry the change over
[09:03] <jimis> but bzr should have reminded me because I forgot
[09:04] <jimis> I intend to file a bug when I find some time, about missing functionality when working with checkouts
[09:04] <vila> yeah, kind of the --strict option on pull/push and... I forgot the other one send ?
[09:04] <jimis> I understand it is not a mainstream workflow, but it is the *only* possibility when working with branches sized as big as lp:gcc
[09:05] <jimis> multiple dirs is not an option then
[09:10] <Riddell> vila: where is baboun again?
[09:10] <jelmer> Riddell, under vila's desk :)
[09:10]  * Riddell books a trip on the eurostar to test his branch
[09:10] <jelmer> jam: did you have more comments on my transport-segments branch?
[09:10] <vila> Riddell: http://babune.ladeuil.net:24842
[09:10] <vila> jelmer: :)
[09:11] <jelmer> Riddell: :)
[09:11] <jam> jelmer: no, just the display thing, Riddell had already approved the branch
[09:14] <Riddell> vila: hmm, how do I build a branch again?
[09:14] <Riddell> oh, helps if I log in
[09:14] <vila> yeah, a lot ;)
[09:15] <jelmer> jam: thanks :)
[09:23] <jam> vila: do you have python-2.4 on babune?
[09:25] <Riddell> vila: I scheduled selftest-subset-natty but it says "pending - natty64.local is offline"
[09:25] <vila> Riddell: yup, the slave needs to be started, just wait a bit
[09:25] <vila> jam: probably, depends on the slave
[09:26] <jam> when did FF go to 6.0?
[09:26] <vila> jam: why would you care, we don't support anymore ?
[09:26] <jam> did they just decide to stop doing minor versions
[09:26] <jam> vila: I'm backporting something to bzr-2.1 for Lucide
[09:26] <jam> Lucid
[09:26] <jam> so we *do* care there
[09:26] <vila> then it should be available on the lucid slave
[09:27] <vila> jam: note that installing a local lucid chroot will probably be more convenient for you
[09:28] <vila> unless you just want a final test run that is
[09:30] <maxb>   
[09:30] <jam> vila: yeah, pretty much
[09:30] <jam> I think everything is ok
[09:30] <jam> I just want to make sure before I submit it, and it goes boom when we release
[09:32] <vila> but.. doesn't python defaults to 2.5 on lucid already ?
[09:33] <vila>    python | 2.6.5-0ubuntu1 |         lucid | all
[09:33] <vila> yeah, 2.6 even
[09:33] <jam> vila: sure, but we are still backporting to a 2.1 series, which *is* 2.4 compatible
[09:33] <vila> I'm not even sure 2.4 is supported on lucid (imbw)
[09:34] <jam> even backporting to bzr-2.3 we should be verifying python-2.4 compatibility
[09:34] <vila> right, but I'm not sure you can use lucid to test 2.4 you may need to dig deeper
[09:34] <jam> I thought you had that set up on babune
[09:34] <jam> (since it at least are excuse for why it was ok to upgrade PQM)
[09:35] <poolie> ok this time for sure
[09:38] <jam> poolie: ? (this time you're gone for sure?)
[09:38] <poolie> this time i think i fixed bug 819910
[09:38] <jam> or this time httperror is fixed
[09:38] <ubot5> Launchpad bug 819910 in Ubuntu Distributed Development "many packages fail to import due to HTTPError talking to Launchpad (eg ubuntu:transmission)" [Critical,In progress] https://launchpad.net/bugs/819910
[09:38] <poolie> it took kind of a silly long time
[09:38] <vila> poolie: \o/
[09:38] <poolie> we'll see
[09:38] <poolie> i have something a bit more realistic working locally though
[09:38] <poolie> which is a good step
[09:39] <poolie> not my best day ever
[09:39] <poolie> https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71832
[09:40] <poolie> quick review anyone?
[09:43] <jam> poolie: looking
[09:43] <vila> not at lot to look at ;) can't you add a test for that, even against a live lp ?
[09:43] <jam> poolie: str() is worrying for me, though it may be correct. And it certainly looks like something that Launchpadlib is likely to break
[09:44] <jam> since you're poking at private attributes
[09:44] <poolie> the object itself is a URI class
[09:44] <vila> and yeah, why the str() ?
[09:44] <poolie> and it defines a str as apparently the right way to get an actual string
[09:44] <jam> poolie: ok, that part works for me.
[09:44] <poolie> other launchpad client infrastructure won't accept the URI
[09:44] <poolie> as far as using the underscoe
[09:45] <poolie> there's no public equivalent
[09:45] <poolie> maybe i'll ask in #launchpad
[09:45] <jam> poolie: there's no way to ask for a branch's LP URL?
[09:45] <jam> or is it that you have to go via a round-trip that you are trying to avoid
[09:46] <jam> like lp.branches['~user/project/branch'].url seems like it should work
[09:46] <jam> but that is a round trip you might be trying to avoid
[09:46] <poolie> does that work?
[09:46] <poolie> it would be cleaner
[09:46] <poolie> i don't think this will be a performance problem
[09:46] <poolie> it's not hit all that much compared to the amount of other work this program does
[09:47] <jam> poolie: https://launchpad.net/+apidoc/beta.html#branches
[09:47] <jam> I'm thinking
[09:47] <vila> yeah, make it work, make it right, make it fast... and it doesn't work yet ;)
[09:48] <poolie> that doesn't work; it seems to expect an integer index
[09:48] <poolie> but there might bbe something similar
[09:48] <jam> poolie: so probably lp.branches.getByUniqueName(short_form).self_link
[09:48] <poolie> yep
[09:48] <poolie> or no
[09:48] <lifeless> jam: I wonder if you could have a look at https://code.launchpad.net/~lifeless/python-oops-wsgi/extraction/+merge/71839
[09:49] <lifeless> jam: its a replacement for the oops middleware we use in launchpadloggerhead
[09:49] <jam> lifeless: no diff yet, but I'll give it a minute
[09:49] <lifeless> yeah, no panic
[09:49] <lifeless> bedtime for me, 7am meeting tomorrow ;)
[09:49] <jam> lifeless: maybe you have a hint. Trying to get the LP API reference for a branch known by its short name
[09:49] <jam> (~user/project/branch)
[09:49] <poolie> yep, that's it
[09:49] <jam> trying to get something like api/1.0/...
[09:50] <poolie> thanks
[09:50] <jam> poolie: getByUniqueName is correct?
[09:50] <lifeless> jam: you want the devel api, not beta
[09:50] <jam> lifeless: this is for the udd package importer
[09:50] <lifeless> yes
[09:50] <jam> I think we found it, though.
[09:50] <lifeless> beta is -deprecated-
[09:50] <lifeless> dead dead dead
[09:51] <lifeless> for a live service under maintenance, I would definitely be using the devel version of the API
[09:51] <poolie> where is he using beta?
[09:51] <poolie> oh in the doc api
[09:52] <poolie> i don't think that's a problem unless we still have an lplib that defaults to beta
[09:52] <jam> poolie, lifeless: sure, it was just what firefox quick-linked for me when typing "apidoc"
[09:52] <poolie> oh actually if we're going to call we can just use getByUrls and simplify this a bit more
[09:53] <jam> poolie: or getByUrl, just depends what you actually have.
[09:53] <lifeless> poolie: its a problem to the extent that there is stuff in 'beta' that no longer exists, and conversely not stuff in beta that now exists.
[09:53] <lifeless> best to read the docs for the api being used.
[09:53] <poolie> i am looking at the 1.0 docs
[09:53] <poolie> i mean i don't think there's a practical problem for the importer
[09:54] <lifeless> sure
[09:54] <lifeless> I get that; I'm just trying to ensure you don't do what I've seen others do which is try a gone api and be confused when its not there but is on the web page.
[09:55] <poolie> oh it is actually gone?
[09:55] <lifeless> that particular one isn't.
[09:55] <poolie> perhaps the beta api doc pages should be removed
[09:55] <lifeless> but, in beta particularly, a great many have been deprecated and are now gone
[09:55] <lifeless> and there is a great deal in 1.0 that won't be listed on the beta page
[09:55] <lifeless> so you might miss out on just the right api for the job
[09:55] <lifeless> anyhow
[09:56] <lifeless> jam: that diff is up; I realise I haven't glued the url inclusion in the report in yet, I'll do that as a separate landing I think
[09:56] <poolie> so, jam needs to just update his bookmark or browser history
[09:57] <lifeless> more or less ;)
[09:57] <lifeless> gnight
[10:06] <poolie> jelmer: hooray
[10:07] <jelmer> poolie: glad that finally seems to be taking shape :)
[10:08] <jam> vila: so, do you have a test runner on babune that can run older versions of bzr against python-2.4?
[10:10] <vila> jam: not sure, do you know which ubuntu release supported 2.4 in the end ?
[10:11] <jam> hardy?
[10:11] <vila> hardy is 2.5 by default iirc
[10:11] <jam> vila: probably default, but still supported
[10:11] <jam> vs you can't even install python-2.4 on Lucid
[10:14] <vila> after a quick check, babune always use the default python so there is no existing job to test 2.4 explicitly, but you can probably create one pretty easily
[10:14] <vila> the hardy slave has python-2.4 installed
[10:17] <poolie> jam, ok, how about https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71832 then
[10:18] <jam> poolie: lp_call is really how you have to spell that? ugh
[10:18] <jam> but otherwise, approve
[10:18] <jam> poolie: you have a comment "Sripo of the scheme, and hostname" that should go
[10:19] <poolie> lp_call is a wrapper that handles retrying the operation etc
[10:19] <poolie> it really ought to be in lplib
[10:19] <poolie> also, for that matter, it would be nice if you could declare special forms in python for things like this
[10:20] <jam> sure
[10:21] <poolie> thanks
[10:22] <poolie> ok, i'll merge it and try it
[10:30] <jam> poolie: care to chat about my patch?
[10:30] <poolie> i'm just trying to roll this onto jubany and it seems to be breaking
[10:30] <poolie> after that sure
[10:31] <jam> sure
[10:33] <poolie> this is your get_parent_map patch?
[10:35] <jam> yes
[10:55] <poolie> jam, ok that _seems_ to be working
[10:55] <poolie> bit hard because of bug 827935
[10:55] <ubot5> Launchpad bug 827935 in Launchpad itself "consistent timeout on user branch listing page" [Undecided,New] https://launchpad.net/bugs/827935
[11:00] <poolie> jam i might have some dinner now, i'll try to ping you later
[11:00] <jam> sure
[11:00] <jam> I should have lunch as well
[11:11] <jelmer> hmm, it's kindof worrying that PQM is now so slow that we can keep it busy overnight :-/
[11:21] <vila> jelmer: ... and still has a queue of 5 :-(
[11:32] <Riddell> so it this my fault or baboun's? http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-natty/12/console
[11:33] <jam> Riddell: isn't everything your fault? You're the new guy, after all.
[11:33] <Riddell> it might be less my fault if I learnt to spell babune
[11:34] <vila> FATAL: Unable to delete script file /tmp/hudson2041655501694922969.sh
[11:34] <vila> shudder, long time not seen
[11:35] <vila> slave died for mysterious reason, try again, using a smaller subset may help
[11:36] <vila> making chroots real nodes and switching the old jobs to these new nodes will also address the issue but I'm not there yet...
[11:37] <vila> I've made some progress on upgrading the gentoo slave (which I couldn't do for.. months), currently rebuilding 12/258 packages...
[11:46] <vila> maxb: ping
[11:47] <vila> jam: are you planning to build th windows installers for 2.4.0 ?
[11:47] <jam> vila: at some point, though I was still dragging my feet based on what Jelmer has stated about bzr-svn (critical bug still remaining)
[11:48] <vila> huh ? Where ? When ? jelmer ?
[11:48] <vila> crap, just found the mail
[11:49] <vila> jelmer: is there a bug # for that ?
[11:51] <jam> vila: https://bugs.launchpad.net/bzr-svn/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed ?
[11:51] <jam> 3 critical bugs
[11:52] <vila> hmpf
[11:52] <vila> madness
[11:54] <vila> jelmer: are all these bugs relevant for 2.4.0 or only for prior versions ?
[11:55] <vila> jelmer: also, are they regressions and do they affect the majority of users ?
[11:55] <jam> vila: I think you scared him away
[11:55] <vila> hehe
[11:56] <vila> *I* am the one who is scared, I know nothing scares jelmer ;)
[12:01] <jelmer> I'm lunchin' :)
[12:02] <jelmer> 826946 is the one that's worrying me
[12:02] <jelmer> 704716 is fixed so no longer an issue
[12:02] <jelmer> 485601 is fixed I think but doesn't have tests yet
[12:03] <vila> pfew, good to know (bon appétit by the way)
[12:05] <vila> jelmer: should bug #826946 block the 2.4.0 release (or even the 1.1.1 ? bzr-svn release) though ?
[12:05] <ubot5> Launchpad bug 826946 in Bazaar Subversion Plugin "Commit to svn repo completes, but repo is not updated" [Critical,Triaged] https://launchpad.net/bugs/826946
[12:06] <vila> HMPF (no space left on device, gentoo I hate you)
[12:06] <jelmer> vila: if it is as serious as it appears to be, it's a serious regression
[12:06] <vila> k
[12:06] <vila> jelmer: let me know how it goes
[12:15] <poolie> jam, are you back?
[12:15] <jam> poolie: yep
[12:15] <poolie> vila, is enospace connected or something else?
[12:16] <poolie> jam do you have an mp up already?
[12:16] <jam> poolie: yeah, I posted it while you were dining
[12:17] <vila> poolie: I went to /etc/fstab and found the comment I left ages ago when the same problem happened: don't use tmpfs for /var/tmp if more space is needed for emerge
[12:21] <jam> poolie: if you want to read through the merge proposal, I think I've captured everything I had to say about it. The only other bit that would-have-been-nice is to have you run some tests from Sydney
[12:21] <jam> but they take a while, and I didn't work up a script to automate all of it
[12:21] <poolie> i might do that tomorrow
[12:25] <poolie> vila, just add more swap
[12:26] <vila> poolie: or more memory or just comment out the fstab line which I did. After a reboot, the emerge is going on now
[12:27] <poolie> jam, i'm reading it
[12:27] <poolie> or tell emerge to use a different tmpfs
=== Mkaysi_ is now known as Mkaysi_|ZNC
[12:34] <poolie> what a nice analysis
[12:34] <poolie> and what a long commit message :)
=== Mkaysi_|ZNC is now known as Mkaysi
[12:43] <poolie> jam, hi
[12:43] <jam> hey
[12:43] <poolie> so the reasoning and the code make sense to me
[12:43] <poolie> i can't see any actual bugs (other than a couple of tweaks)
[12:44] <poolie> i'm not super confident that i would catch any bugs that actually were there though, cause it's moderately large
[12:44] <jam> yeah
[12:44] <poolie> so, perhaps i should just try it out a bit tomorrow
[12:44] <jam> I did manually test it against launchpad a fair amount
[12:44] <jam> Not that it exhaustively tests all possible edge cases.
[12:47] <poolie> i think landing into trunk first makes sense
[12:47] <poolie> it's really nice it doesn't need a server change
[12:48] <poolie> is there anything in particular we should talk about?
[12:54] <jam> poolie: I think I've worked through it. I mostly wanted to do the summary live-on-the-phone, but it has been done
[12:55] <poolie> weeee
[12:55] <poolie> the flood of mp mail indicates the lpapi connection is unjammed
[12:56] <poolie> i wonder if people will feel spammed
[12:56] <poolie> i guess it's a good chance to consider how much they are useful
[12:56] <jam> poolie: when don't people feel spammed by lp?
[12:56] <poolie> i don't know
[12:56] <poolie> i certainly do
[12:56] <poolie> i'd like to do built-in non-email notifications some time
[12:57] <poolie> https://bugs.launchpad.net/launchpad/+bug/827935/comments/1 might amuse
[12:57] <ubot5> Ubuntu bug 827935 in Launchpad itself "consistent timeout on user branch listing page" [Critical,Triaged]
[12:57] <poolie> i should sleep
[12:59] <jam> poolie: real quick, what time would be reasonable to load the global config to check the value?
[13:00] <jam> poolie: OFFSET 313000 seems particularly telling
[13:01] <jam> (sort all 500,000 entries, and give me the middle 48)
[13:03] <poolie> yeah that offset looks to me like it's either loading them all (i'm not sure if that's what the oops means) or slicing a big collection
[13:03] <poolie> i haven't dug into it
[13:03] <poolie> how do you mean 'what time'?
[13:03] <poolie> as in, where in the code, or how long do i think it would take?
[13:03] <jam> poolie: where in the code
[13:04] <poolie> perhaps when the remotebranch or similar is constructed, make an instance and hold it?
[13:04] <jam> I don't think we want to check the config on every _get_parent_map_rpc call
[13:04] <poolie> that should make sure it's read just once
[13:04] <jam> this is in RemoteRepository
[13:04] <poolie> ok, remoterepository then
[13:04] <poolie> vila may have a more evolved idea, but putting it there should mean it's not loaded too many times in normal use, and we can move it later
[13:05] <jam> poolie: but you're thinking to cache the GlobalStack object, not just the config value
[13:05] <poolie> yes
[13:05] <jam> vila: ^^ thoughts?
[13:05] <poolie> is even reading out of that expensive?
[13:05] <poolie> it may be
[13:05] <jam> poolie: I don't think it is expensive as in, will show up in real-user-time branching all of history
[13:06] <jam> maybe in shorter term. But for all of bzr it only does 600 or so RPCs
[13:06] <jam> because of the preloading behavior
[13:06] <vila> jam,poolie: is there a global config on lp ?
[13:06] <poolie> ok, good night then
[13:07] <jam> vila: a config for all branches on lp? no
[13:07] <poolie> jam, if it's nontrivial to change i wouldn't block on it
[13:07] <jam> though you could do a locations.conf thing
[13:07] <poolie> we can always add it if it's wanted
[13:07] <vila> I suspect not (today)
[13:07] <poolie> another option would be to go off a debug flag which we know should be cheap
[13:08] <poolie> good night all
[13:09] <vila> jam: if you're talking about *local* config then the plan is that checking an option will be a bit more than checking an in-memory dict (or thrice) i.e. far lower than reading a file
[13:09] <vila> poolie: g'night
[13:10] <vila> jam: or doing an rpc call
[13:11] <jam> sure, but "plan" and what will "land in 2.4" is pretty different
[13:12] <jelmer> g'night poolie
[13:13] <vila> jam: well, stop worrying about a bug that has been there since the beginning then
[13:14] <vila> jam: *all* options requires reading one or several config files so far
[13:45] <jam> vila: which is why I've generally *avoided* having things in config files so far
[13:49] <vila> jam: then keep doing so until we get a better config or join the effort to get there ;)
[13:55]  * jelmer is generally also not too fond of adding configuration options
[13:56] <jelmer> it's often the easy answer, deferring to the user instead of thinking about what the right thing to do is
[13:56] <vila> yup, I know the trap
[13:56] <bigjools> as a KDE user, I say moar config!
[13:57] <vila> that doesn't mean nothing should be configurable
[13:58] <jelmer> bigjools: ((-:
[14:00] <vila> jelmer: the other extreme example is OSX (or more generally Apple) where you *can't* configure what you want because *they* know better
[14:04] <jelmer> vila: yeah
[14:11]  * jelmer takes a quick break
=== Mkaysi is now known as Mkaysi|ZNC
[15:11] <vila> jelmer: back ?
[15:17] <jelmer> vila: yep
[15:18] <vila> jelmer: you mentioned a fallout about my last patch around BZR_HOME, I can't find the thread anymore :-/
[15:20] <vila> jelmer: but from memory you mentioned bzr-svn tests failing because of it. I was wondering if these tests should be put into core instead
[15:20] <jelmer> vila: basically, if BZR_HOME is set then bzrlib.config.config_dir() returns unicode strings
[15:20] <vila> yeah, I remembered that
[15:20] <jelmer> vila: GMTA. lp:~jelmer/bzr/cachedir was an attempt to do just that :)
[15:23] <vila> oooh
[15:23] <vila> I don't clearly see the connection though :)
[15:24] <vila> or was it just a first step ?
[15:24] <jelmer> vila: bzr-svn falls back to storing its cache in ${config_dir()}/cache/svn if it can't find a cache directory
[15:26] <vila> ha, that's the connection, pfew, but... where does cache_dir calls config_dir ?
[15:31] <jam> jelmer: so it looks like PQM is still chewing through stuff you submitted yesterday. Not a good sign.
[15:31] <jam> http://webnumbr.com/bzr-pqm-queue-length.from%282011-08-01%29
[15:31] <jam> I do wish we had some stats on time-to-run-the-test-suite
[15:32] <jam> anyway, I'm off for now. Have a good night y'all
[15:34] <vila> g'night jam, the issues you mentioned have been briefly discussed here ;)
[15:36] <jelmer> jam: g'night
[15:36] <jelmer> jam: it does indeed look worrying :_/
[15:36] <jelmer> vila: it doesn't, but the bzr-svn equivalent of it does
[15:37] <vila> ....finally :)
[15:38] <vila> sooo, no need to search how to avoid return unicode right ? Better spend my time on reviewing your branch instead ? Or are you already addressing jam's review ?
[15:43] <vila> jelmer: ^
[15:45] <jelmer> vila: Yeah, I'm addressing jam's concerns at the moment.
[15:46] <vila> k
=== beuno is now known as beuno-lunch
=== Mkaysi|ZNC is now known as Mkaysi
[16:52] <jelmer> have a good evening
[17:19] <wilx> Hi, I am having problems installing/running bzr-fastimport: http://codepad.org/Uz43PkP4
[17:19] <wilx> This is the selfcheck fastimport as suggested by the README.txt output.
[17:20] <wilx> I run setup.py build and then I have copied the directory to ~/.bazaar/plugins/fastimport
[17:25] <fullermd> That's happening in bzr-git, not fastimport...
=== deryck is now known as deryck[lunch]
[17:38] <fullermd> Riddell: ping   (if'n you're around still)
=== beuno-lunch is now known as beuno
=== deryck[lunch] is now known as deryck
[19:00] <wilx> fullermd: Oh, so it is not a problem with my installation steps of bzr-fastimport?
[19:00] <wilx> Shall I report it as a bug as suggested?
[19:18] <maxb> Perhaps, but not on fastimport, because the problem is an version incompatibility between bzr-git and dulwich
[19:21] <hexsprite> I _think_ i'm using a checkout, why do I get this? ERROR: Cannot switch a branch, only a checkout.
[19:22] <maxb> wilx: Actually the problem is simply: If you install dulwich 0.8.0, you must also install bzr git >= 0.6.2
[19:22] <maxb> hexsprite: Try "bzr info", see if it is as you expect. Pastebin it for more help.
[19:22] <lifeless> mgz: hi
[19:22] <hexsprite> Maybe that's not even the right command for what I want to do.  Which is to switch my working copy to be based on a new repository located in my homedir
[19:24] <mgz> hey lifeless
[19:24] <hexsprite> eg. i just merged all my changes from my feature checkout in ~/feature into ~/trunk repo. now i want to update ~/feature to be based on ~/trunk
[19:24] <lifeless> mgz: I can meet anytime, if now would be more convenient for you
[19:25] <lifeless> mgz: I just need 5 minutes to feed cats n stuff (I"ll be right back after that - let me know :P)
[19:25] <maxb> hexsprite: Please pastebin the output of "bzr info ~/feature" and "bzr info ~/trunk" - it will help explain the details of your situation
[19:28] <hexsprite> bzr info for both: http://pastebin.com/eMF1iiVD  -- note ~/main a checkout of trunk and 1079_dojo is where I'm actively working on new features
[19:28] <mgz> lifeless: I'm ready when you're back
[19:30] <hexsprite> to get 1079_dojo up to date so should i be doing: bzr switch ~/main
[19:36] <lifeless> mgz: kk
[19:36] <lifeless> mgz: do you have skype ?
[19:37] <mgz> I don't have a decent mic to connect to the computer unfortunately
[19:37] <lifeless> kk
[19:37] <lifeless> ringing in  a sec
[19:41] <jxself> http://doc.bazaar.canonical.com/latest/en/whats-new/whats-new-in-2.4.html
[19:41] <jxself> Says 2.4 was released August 8?
[19:41] <jxself> http://bazaar.canonical.com/en/ disagrees
[19:46] <meme> hi im trying to use bzr to push source code to a launchpad project but i have no idea what im doing i think im doing it right but i get bzr: ERROR: Not a branch: "/home/jadon/airscripts/.bzr/branch/": location is a repository.
[19:46] <meme>  
[19:47] <meme> anyone able to help?
[19:50] <meme> anyone?
[19:50] <jxself> Relax. Be patient, young grasshopper. :)
[19:50] <beuno> meme, you're not in a branch, you're in a repostiry
[19:51] <meme> so i need to cd deeper tell im in a branch?
[19:55] <hexsprite> seems like bzr pull ~/main was what i needed
[19:57] <meme> well i did something that happend and now it does other stuff and it seems to work
=== hexsprite_ is now known as hexsprite
=== Quintasan_ is now known as Quintasan
=== yofel_ is now known as yofel
[22:08] <Riddell> fullermd: pong
[22:10] <fullermd> Ohai.  Um.  Why was I pinging you?
[22:10]  * fullermd scratches his elbow.
[22:11] <fullermd> Oyah.  Are you doing much actively on qbzr?  I noticed you popping up in the commit logs somewhat lately...
[22:56] <wilx> maxb: Thanks, that's probably it. I have only bzr-git 0.6.1 installed.
[22:56] <controversial> hi
[22:57] <controversial> i've tried svn, git, and hg, and i'm using hg right now.  i'm curious about bzr though.  how does that compare against hg
=== krow_ is now known as krow