[00:12] <lifeless> meep
[00:12] <lifeless> Raw size<PHONE_NUMBER>
[00:12] <lifeless> Compressed size 141152371
[00:12] <lifeless> Compressed size 508555
[00:13] <lifeless> thats the inventories from my main bzr repo
[00:13] <davidstrauss> Merging with no common ancestor is not working properly for me.
[00:13] <lifeless> Jc2k: ^ guess what the bottom compressed size is from
[00:13] <lifeless> davidstrauss: what it is doing
[00:14] <davidstrauss> lifeless: http://fourkitchens.com/blog/2009/01/17/distributed-version-control-provides-streamlined-alternative-vendor-branches
[00:14] <davidstrauss> lifeless: I'm trying the commented operation, but with "bzr merge --revision=1..-1 bzr://vcs.fourkitchens.com/drupal/6" as the merge
[00:14] <davidstrauss> lifeless: And I get TONS of conflicts
[00:15] <lifeless> if you run bzr init and add in a new tree,then the files have new identity
[00:16] <lifeless> so when you merge, and they have the same path, its a file name conflict
[00:16] <davidstrauss> lifeless: how can i force a common ancestor
[00:16] <lifeless> start from trunk rather than by doing 'bzr init'
[00:16] <davidstrauss> lifeless: that's impossible. the whole point of this procedure is that you've started your own project on its own
[00:16] <lifeless> I'm sorry if I'm not being really helpful - I'm trying to understand what your blog post is about
[00:17] <davidstrauss> lifeless: i want people who have drupal projects in bazaar branches to be able to migrate to using our drupal bazaar branch for upgrades
[00:18] <lifeless> davidstrauss: ah
[00:18] <davidstrauss> lifeless: despite having no established common ancestor
[00:18] <lifeless> so the -r x..y syntax will force an ancestor of x
[00:18] <davidstrauss> lifeless: yes, but we get tons of conflicts
[00:18] <lifeless> but the /content/ of the trees is unrelated, I would expect tons of conflicts
[00:18] <lifeless> do you know much about bzr internals?
[00:19] <davidstrauss> lifeless: not for content IDs
[00:19] <lifeless> ok, very quick primer so my answers will make sense to you
[00:19] <m4v> hi, quick question, does bzr track file permissions?
[00:19] <lifeless> m4v: execute bit only
[00:19] <bob2> only execute
[00:19] <davidstrauss> lifeless: is there a way to force bazaar to understand that file name match = content match?
[00:19] <lifeless> m4v: see etckeeper for tracking full permissions, which supports bzr
[00:20] <lifeless> davidstrauss: each object that bzr is managing has a path and a fileid. The fileid is the globally unique ID for the object
[00:20] <davidstrauss> lifeless: I can see that now, but that doesn't really make it possible to efficiently merge without common ancestry
[00:21] <davidstrauss> lifeless: I mean, there *has* to be a way to merge efficiently without common ancestry
[00:21] <lifeless> davidstrauss: this is a 1:1 relationship in any tree - 1 path, 1 id.
[00:21] <lifeless> davidstrauss: over time you can get many different paths having the same id - when things are renamed and so on
[00:21] <lifeless> davidstrauss: so, to do a merge with an unrelated tree
[00:22] <lifeless> davidstrauss: such that future merges can be no-brainers
[00:22] <lifeless> davidstrauss: you have to replace the fileid of *every* file that is in the source tree and in the target tree, with the fileid from the sourcetree
[00:22] <davidstrauss> lifeless: is there a way to do that automatically?
[00:23] <lifeless> then you have to do a merge across the two file ids using the specified base, or else the old fileids local changes wil be lost
[00:23] <davidstrauss> lifeless: Is there a way to do that branch-wide?
[00:23] <lifeless> you need to identify the common revision in both branches as well
[00:24] <m4v> lifeless: alright
[00:24] <lifeless> davidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up
[00:24] <davidstrauss> lifeless: identifying the common revision in both branches is already part of my procedure
[00:24] <lifeless> davidstrauss: yes, but there is no way to tell bzr at the moment, you only manage to tell it 3 of the 4 coordinates needed
[00:25] <davidstrauss> lifeless: so is there an efficient way to resolve the conflicts?
[00:25] <garyvdm> vila: I managed to get qbzr to use CLIUIFactory rather than TextUIFactory.
[00:26] <lifeless> davidstrauss: it is scriptable in python
[00:26] <davidstrauss> lifeless: has it been scripted?
[00:26] <lifeless> davidstrauss: in fact, writing a custom conflict resolver could do it during the merge to make it seamless
[00:26] <lifeless> 11:21 < lifeless> davidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up
[00:27] <davidstrauss> lifeless: what would the custom conflict resolver look like?
[00:28] <davidstrauss> lifeless: would it be in python or a shell command?
[00:31] <lifeless> davidstrauss: I think it would be a subclass of bzrlib.merge.Merge3Merger, though I haven't written a custom one myself
[00:32] <lifeless> http://paste.ubuntu.com/106710/ <- knit vs gc compression
[00:33] <lifeless> short story, 141MB to 0.5MB, but 10 times slower at extraction, at the moment
[00:36] <davidstrauss> lifeless: what is gc compression?
[00:39] <lifeless> davidstrauss: its a new delta compression I'm evaluation for bzr
[00:44] <davidstrauss> lifeless: is there a way to specify an external merge tool that runs in the shell?
[00:44] <lifeless> I think the extmerge plugin does this
[00:44] <lifeless> note though that I don't think it will handle the file id changing that you need
[00:44] <davidstrauss> ok
[00:44] <lifeless> fundamentally this needs code written to support it
[00:47] <davidstrauss> lifeless: I think this is one area git's architecture shines.
[00:47] <davidstrauss> apparently
[00:47] <lifeless> well its certainly simpler there, for git or hg
[00:48] <lifeless> its the inode abstraction that makes it complex to handle parallel imports
[00:48] <lifeless> I encourage you to file a bug, this is something we should put a canned answer to in the core
[00:48] <davidstrauss> ok
[00:49] <lifeless> for now, people that want to move onto your branch would be best served by:
[00:49] <lifeless>  - pull your branch
[00:49] <davidstrauss> lifeless: would that handle the file ID mismatches?
[00:49] <lifeless>  - apply their local changes as a plain patch (bzr diff -r x..y | bzr patch)
[00:49] <davidstrauss> ok
[00:49] <lifeless> commit that patch
[00:50] <lifeless> then they are descendants of your branches
[00:50] <davidstrauss> lifeless: so, basically, start fresh
[00:50] <lifeless> yes
[00:50] <davidstrauss> lifeless: this seems similar to when you bzr bind after divergence
[00:52] <lifeless> gc is faster at compression, sweet
[00:55] <jelmer> we have a gc?
[00:57] <davidstrauss> lifeless: https://bugs.launchpad.net/bzr/+bug/318620
[00:58] <lifeless> jelmer: groupcompress
[00:58] <lifeless> davidstrauss: thank you
[01:07] <garyvdm> What do you guys think about merging a number of revisions that are currently the tip of your mainline, with an older revision, just for the sake of grouping them together?
[01:08] <garyvdm> I think I better pastebin a dag to explain this..
[01:10] <lifeless> garyvdm: you can do it if you want
[01:10] <lifeless> it just makes it look like a merge of a branch
[01:12] <garyvdm> Here is my dag just to make sure we are on the same wave length: http://pastebin.com/d23836559
[01:14] <jelmer> lifeless, ah, that makes more sense (-:
[01:18] <spiv> jelmer: bzr-svn is working well for me these days, btw.
[01:18] <jelmer> spiv, cool
[01:18] <spiv> jelmer: the current 0.5 tip seems to be quite reliable at pulling from python's and twisted's repos.
[01:19] <spiv> jelmer: I have some hackery to submit to make it import faster, though :)
[01:19] <spiv> (e.g. don't import subertpy all the time, etc)
[01:19] <spiv> jelmer: it even does find_tags at a bearable speed now :)
[01:20] <jelmer> spiv, patches for import improvements are more than welcome
[01:50] <thumper> hi ho
[01:50] <thumper> I just went bzr init, and bzr stat
[01:50] <thumper> and got a traceback
[01:50] <thumper> is this a known bug?
[01:50] <thumper> bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose'
[01:51] <jelmer> thumper, do you have loom installed?
[01:51] <jelmer> thumper, I think you need a newer version of loom
[01:51] <thumper> plugin installed, yes
[01:51] <thumper> using it, no
[01:51] <jelmer> it wraps bzr status but doesn't cope with a new argument that has been added to status
[01:51] <jelmer> even if you're not using it
[01:52] <thumper> :(
[01:53] <jelmer> the last revision of the loom trunk fixes it
[01:53] <thumper> WTF?
[01:53] <thumper> :-(
[01:54] <thumper> bzr log --line -r-10..-1 now gives be non-mainline messages
[01:54] <thumper> this is very new
[01:55] <thumper> and I can't go --line --short, as that doesn't work
[01:55] <jelmer> yeah, I can confirm that has changed since 1.11
[01:56] <thumper> can we change it back?
[01:56] <thumper> it is really annoying
[01:57] <jelmer> I'm not sure it's intentional or a regression that is a side-effect of the recent work on log
[01:57] <thumper> I don't think it is intentional
[01:57] <jelmer> probably worth filing a bug about
[01:58] <thumper> igc: my log --line now shows non-mainline revisions
[02:02] <lifeless> jam: are you around by chance?
[02:15] <igc> thumper: I thought jam has sent a quick fix to pqm for that but it looks like he hasn't
[02:15] <igc> I'll do it now
[02:28] <thumper> igc: that'd be grand
[02:29] <igc> thumper: in the pqm queue now
[02:29]  * igc lunch
[02:29] <thumper> igc: fantastic
[03:08] <igc> thumper: try bzr.dev now and let me know if it's still broken
[03:08] <thumper> igc: ok
[03:08] <mwhudson> oops, 700 unread emails on the bzr list
[03:30] <S11001001> hello all
[03:30] <S11001001> I am maintaining a Trac with some modifications (my.desktopdoctorsinc.com) using a Bazaar branch.  I'm in the process of rebuilding it with upstreamable changes (~30% of the code) separated out.  I've built a bzr-loom with 7 patches so far, mostly non-interdependent, and can probably get a few more into upstreamable state.  I tend to merge upstream at new releases, the changes are typically larger than the total of all changes in my
[03:30] <S11001001> branch, and there are usually 2-3 conflicts.  Question is, would I be better off sticking with loom, or keeping separate ordinary branches for these changes?
[03:35] <lifeless> either is fine
[03:52] <thumper> igc: lp:bzr is a few revs behind by the look of it
[03:54] <spiv> thumper: it's 3 hours behind, on average ;)
[03:55] <thumper> spiv: funny man
[03:55] <thumper> so when is bzr going to host trunk on LP?
[03:58] <lifeless> http://bazaar.launchpad.net/~lifeless/+junk/bzr-compressbench
[04:52] <pygi> goooood morning
[05:32] <poolie> hello pygi
[05:47] <pygi> poolie, :)
[05:47] <pygi> chapter 1 coming to your address this week :)
[06:23] <davidstrauss> lifeless: http://fourkitchens.com/blog/2009/01/19/creating-common-branch-ancestry-hard-problem
[07:35] <vila> hi all
[08:03] <igc> hi vila
[08:36] <davidstrauss> What is the status of nested trees?
[08:37] <Lo-lan-do> They're full of birds?
[08:39] <jml> davidstrauss: they aren't there yet. interest is being renewed though.
[08:39] <davidstrauss> jml: The Drupal project is very interested in getting this support stable.
[08:39] <davidstrauss> jml: So we can effectively consider Bazaar for module development on Drupal.org
[08:39] <sdboyer> jml: like, very interested :)
[08:41]  * fullermd frowns.
[08:42] <fullermd> NEWS is looking a little odd.
[08:42] <jml> sdboyer, davidstrauss: I *think* abentley intends to work on it very soon.
[08:42] <jml> but I couldn't say for sure.
[08:43] <fullermd> poolie: It looks like r3940 spuriously added a whole separate section on top of NEWS
[08:46] <sdboyer> jml: well, our timeframe for making a vcs switch is anything but clear, but nested trees would be a _huge_ deal for us, so if part of the hold-up is having a really rigorous use case to put the code through, that's something we can provide
[08:46] <jml> sdboyer: cool :)
[08:49] <luks> can't https://launchpad.net/bzr-scmproj be used as an alternative?
[08:50] <jml> maybe!
[08:50]  * jml doesn't know anything about it.
[09:02]  * igc dinner
[09:03] <davidstrauss> bzr-scmproj looks kind of clunky
[09:29] <poolie> davidstrauss: it's trying to do it in a kind of minimal but useful way
[09:31] <vila> luks: Looks like gary merged a conflict in qbzr trunk, just deleting it seems enough though
[10:10] <poolie> hello vila
[10:10] <vila> hey !
[10:19] <fullermd> poolie: Did you catch my above?
[10:28] <poolie> about news, or about nested trees?
[10:28] <poolie> i saw both
[10:28] <poolie> i'm making 1.11final tonight, and then will merge back and fix the news
[10:28]  * fullermd nods.
[10:28] <fullermd> Just making sure IRC didn't eat it   :)
[10:29]  * davidstrauss smiles in anticipation of 1.11
[10:30] <fullermd> Shucks, that means I have to update the port...
[10:43] <LarstiQ> sdboyer, davidstrauss: yeah, that would help
[10:43] <davidstrauss> :-0
[10:43] <davidstrauss> :-)
[10:43]  * LarstiQ thinks he may need to rethink the current approach
[10:46] <sdboyer> LarstiQ: great, we should definitely talk, then. cept probably not at 5am my time :)
[10:46] <LarstiQ> sdboyer: k, I'm in utc+1/+#
[10:46] <LarstiQ> 3
[10:46] <davidstrauss> sdboyer: It's the same time here
[10:46] <LarstiQ> sdboyer: currently in .nl
[10:47] <LarstiQ> and some of my time in .fi
[10:47] <fullermd> Heck, it'll be that time here in about 15 minutes   ;p
[10:47] <davidstrauss> I think Drupal could survive without nested branch support by simply having checkouts for each module. It's just not as elegant.
[10:48]  * LarstiQ nods
[10:48] <sdboyer> sure. my interest in having nested branches really working prior to us beginning our coding work is that i'd rather do it all in one fell swoop
[10:49]  * sdboyer is wary that delaying a piece like that until later could very well mean that by the time nested branches are ready, our coders have found other itches to scratch :)
[10:50] <sdboyer> not essential for implementation, but probably wise.
[10:50] <sdboyer> however, unlike davidstrauss, who has been talking about needing to go to bed for two hours, i actually AM going to bed :P
[10:50] <fullermd> A lot of things are easier to setup than to re-setup..
[10:51]  * sdboyer agrees with fullermd wholeheartedly
[10:51]  * sdboyer waves g'night
[11:06] <LarstiQ> poolie: the only other moves on nested trees has been scmproj, right?
[11:10] <poolie> i think so
[11:16] <LarstiQ> hmkay
[11:17] <LarstiQ> poolie: and/but there is still interest in getting it done?
[11:17] <LarstiQ> (well, I know I'd _like_ to have it, but progress has been meh)
[11:18] <Peng_> Oh god. Now that bzr-svn can finally handle a certain pair of branches, bzr-search can't!
[11:18] <Peng_> lifeless: ping
[11:39] <poolie> LarstiQ: interested in working on it?
[11:39] <poolie> i heard you had a branch that fixed some subtrees bugs?
[11:43] <LarstiQ> poolie: I have a couple of small fixes. From time to time I try to merge bzr.dev, but with the 100k diffs, it's not the easiest thing to do and not very motivating
[11:43]  * LarstiQ needs to put more regular time into it to move it forward
[11:44] <LarstiQ> poolie: I'd very much like to get this moving somehow, yes.
[11:44] <poolie> hm
[11:44] <poolie> well, send them up and hopefully we can gradually reduce the problems
[11:44] <poolie> do they fix failures when a subtree format is the default?
[11:45] <LarstiQ> they fix failures on subtree formats, I don't know about specifically that being the default, but with bugs in the usage of subtrees, it's not ready for that yet anyhow
[11:48] <poolie> i'm just wondering what tests you added to get failures
[11:48] <poolie> or what you changed
[11:48] <poolie> since the trunk test suite does not fail, it's presumably not testing everything
[11:49] <LarstiQ> poolie: right, lp:~larstiq/bzr/nested-trees is a continuation from Aaron's branch
[11:50] <LarstiQ> poolie: which is, afaik, the only place where work on by-reference trees is
[11:53] <LarstiQ> poolie: and by reference is I think where the brunt of the usecases are
[11:57] <Jc2k> lifeless: omg is that groupcompress!?!?!
[11:58] <james_w> pretty amazing :-)
[12:03]  * LarstiQ goes to lunch
[12:06] <poolie> hello jc2k, james_w
[12:06] <james_w> hi poolie
[12:06] <Jc2k> hi poolie
[12:08] <Peng_> Whee
[12:17] <Lo-lan-do> I can't seem to find a description of this "groupcompress" thingy that everyone seems to happy about.  Any pointer?
[12:18] <james_w> Lo-lan-do: I don't think so. It's a new compression strategy for storage of texts inside packs (or anything else really)
[12:19] <james_w> it's a different way of doing deltas than what is currently used, which gives a large compression win, but has trade-offs in other areas
[12:19] <Lo-lan-do> Okay.  So smaller repository sizes, I guess?
[12:19] <james_w> currently decompression time, and I imagine annotation time, but that may not change as packs already damaged that
[12:20] <james_w> yes, *massively* smaller in the current implementation
[12:20] <Lo-lan-do> A new storage format too, I suppose.  Will it be compatible with the current ones?
[12:21] <james_w> but that is at a cost of a 200% increase in decompression time, which is unacceptable in my opinion
[12:21] <Lo-lan-do> Um, yeah, sounds not-very-nice indeed.
[12:21] <james_w> yeah, it's just a change in the internal compression, so it will be a new format, but not a watershed one or anything.
[12:21] <Peng_> Can throwing more Pyrex/C at the problem improve decompression time?
[12:21] <Peng_> (I guess not if it's all in zlib.)
[12:21] <james_w> perhaps
[12:22] <james_w> first thing will be to try limiting the delta chains. That will lose some of the win in terms of compression, but may still lead to a better overall format
[12:22] <poolie> it's currently only for inventory data
[12:23] <poolie> so the point is to speed up commit and extraction
[12:23] <james_w> ah, I thought it was texts too
[12:23] <poolie> the decompression time is something that still needs to be solved before we go ahead with ti
[12:23] <poolie> it could be applicable
[12:23] <james_w> yeah
[12:23] <james_w> is there any plan to move away from XML inventories?
[12:23] <poolie> to file texts too
[12:24] <poolie> however, for reasons i don't want to go into right now, it has some troubles with big files
[12:24] <poolie> ie it'll store too many full texts
[12:24] <poolie> (well, arguably too many)
[12:24] <poolie> Lo-lan-do: it'll be backward/forward compatible
[12:25] <poolie> in the usual way
[12:28] <Lo-lan-do> Thanks
[13:26] <yml> hello
[13:28] <yml> I thought it was possible to do a partial checkout of a bzr branch. I would like to create a branch with only a subfolder ot the complete bzr repository.
[13:28] <yml> Is it possible ?
[13:29] <luks> it isn't
[13:33] <yml> Thank you for the confirmation
[13:33] <beuno> yml, you should, however, be able to export a directory
[13:35] <yml> beuno: how would you do this ?
[13:35] <yml> I mean my branch is hosted on launchpad
[13:37] <beuno> yml, ah. I guess you can only do that with local branches
[13:49] <igc> night all
[13:55] <yml> beuno: I see. Thank you for your help
[13:56] <beuno> g'night igc
[13:56] <yml> I will create a symbolic link to put the folder in my pythonpath
[13:57] <edreamleo> Help!  Bzr is, all of a sudden, acting bizarrely.  It started reporting changed files, but bzr diff gives nothing and bzr commit said "useless commit"  I tried installing bzr 1.11 and 1.10 with no improvement.
[13:58] <edreamleo> I just tried bzr branch bzr/1.10 from c:\ (I'm using XP) and bzr appeared to install, but now I see no installed folder.
[14:00] <edreamleo> BTW, "changed" files happen just after a fresh bzr branch.  Is there a cache that should be cleared?
[14:01] <Jc2k> you dont do bzr branch bzr/1.10 to install a new version..
[14:03] <edreamleo> Jc2k.  True, I installed bzr 1.10 from a downloaded zip file.  But I wanted to use bzr to grab bzr sources, and that appeared to work.
[14:03] <Jc2k> does the output of bzr status say "unknown:" and then a list of file?
[14:04] <edreamleo> No.  bzr status says modified.  The actual file appears random, but compares binary equal to the file in other branches.
[14:05] <Jc2k> how odd
[14:05] <edreamleo> By "appears random" I mean the actual file that is reported varies from time to time, or rather, from branch to branch.
[14:05] <edreamleo> Yes!  Odd indeed.
[14:06] <Jc2k> i had some weirdness moving branches between linux, flash drive and windows but this was over a year ago
[14:07] <edreamleo> At first I suspected bad memory.  But the oddness happens on all branches.  Maybe a bit got flipped in a central .bzr folder?
[14:08] <Jc2k> not really sure, im not a dev and what bits of the code i know are related to the workingtree stuff
[14:08] <Jc2k> *arent
[14:10] <edreamleo> I wonder.  Does a fresh install change C:\Documents and Settings\HP_Administrator\.bzr ?  I suspect not.  Any reason not to trash this?
[14:14] <edreamleo> Is there a trouble-shooting guide or FAQ?
[14:34] <superm1> Hi guys.  I'm wondering how to push my tags to the main branch in LP without doing another revision.
[14:35] <superm1> i can't appear to push because pushing requires a new revision
[14:48] <Peng_> superm1: Push will push tags even if there are no new revisions.
[14:48] <superm1> Peng_, is that only with newer versions of bzr?  I'm on hardy, so 1.3.1-1ubuntu0.1
[14:49] <james_w> superm1: I'm not sure, how did you verify that the tags hadn't been pushed?
[14:50] <Peng_> superm1: I don't think it's a new feature.
[14:50] <superm1> james_w, i pulled from another computer that's regularly been pulling from that same branch
[14:50] <james_w> ah, ok
[14:50] <james_w> it's probably just broken then, I don't remember it changing
[14:52] <superm1> okay, well surely i'll be doing another revision at some point from this branch then. the tags will get pushed up at that time at least
[14:52] <Peng_> WFM in bzr.dev.
[14:52] <Peng_> superm1: Does the LP branch support tags?
[14:52] <Peng_> superm1: Does it have any tags currently?
[14:53] <superm1> Peng_, oh you know what, i just tried to pull again and i *did* get the tag this time. it must have committed but there was just a delay before it was available
[14:53] <Peng_> Oh.
[14:53] <superm1> sorry for the chatter james_w and Peng_ but thanks for helping indicate that it should be working :)
[14:54] <Peng_> superm1: If you're pulling from http://bazaar.launchpad.net/, there might be a (short) delay, yeah. There isn't one for bzr+ssh or sftp.
[14:54] <superm1> Peng_, yeah i was pulling from http on the other computer, so that would explain it
[14:54] <james_w> glad to know it works :-)
[14:55] <james_w> there's a bug open about it not telling you what it's done
[14:55] <james_w> "No revisions to push" should be extended to mention that it pushed some tags
[14:55] <superm1> yeah that would be useful
[15:03] <jelmer> james_w: Hi
[15:03] <jelmer> james_w: Are you aware of any guides about using bzr-loom as alternative to quilt/dpatch for Debian packaging?
[15:04] <james_w> jelmer: I'm not
[15:10] <LarstiQ> beuno, mwhudson: similar to https://bugs.edge.launchpad.net/loggerhead/+bug/260547 when I try to run serve-branches proxied by an ssl apache site, links to ../changes or ../annotate drop back to http
[15:11] <bvk> hi, is there any quick way to branch lp:bzr instead of std bzr branch lp:bzr ?
[15:11] <LarstiQ> beuno, mwhudson: should I make a new bug, comment on that one, fix it if it is easy to do?
[15:11] <bvk> it never gets finished for me :(
[15:11] <LarstiQ> bvk: your two alternatives are the same?
[15:11] <beuno> LarstiQ, fix it is always the first option  :)
[15:11] <beuno> if not, I think a comment on the bug is useful
[15:11] <LarstiQ> beuno: it is an area I'm rather unfamiliar with
[15:11] <LarstiQ> but I'll have a go
[15:12] <LarstiQ> beuno: any hints on where to start looking?
[15:12] <jelmer> bvk, if you mean an alternative URL, try http://bazaar-vcs.org/bzr/bzr.dev
[15:13] <bvk> LarstiQ, jelmer: no, i am looking for any tarbal with repository. is such a thing available anywhere?
[15:13] <LarstiQ> bvk: specifically to get one copy of bzr.dev? I could generate a tarball for you
[15:13] <jelmer> I'm curious though as to why branching lp:bzr doesn't work for you
[15:13] <bvk> LarstiQ, jelmer: no, i tried both urls, lp:bzr and http://.../bzr.dev :-( but both timeout from my computer always :(
[15:13] <LarstiQ> bvk: or do you mean, for a given launchpad branch, does it support downloading a snapshot tarball?
[15:14] <bvk> LarstiQ: yes, that would be of great; thanks
[15:15] <bvk> LarstiQ: no, my problem is 'bzr branch lp:bzr' always timesout and doesn't get finish. its too slow
[15:15] <LarstiQ> bvk: ok, it would be good to solve that if possible, but a tarball is coming up for you
[15:17] <bvk> LarstiQ: thanks LarstiQ
[15:17] <LarstiQ> bvk: http://richtlijn.be/~larstiq/bzr.dev-20090119.tar.gz
[15:17] <LarstiQ> bvk: that is my ~/src/bzr/bzr.dev as of now
[15:17] <LarstiQ> bvk: the file is ~5M, if that is too big, I can make a tarball of it after a `remove-tree`
[15:18] <LarstiQ> you would then have to `bzr co .` after unpacking and cding
[15:19] <bvk> LarstiQ: 5MB is fine, i can easily download that.
[15:22] <bvk> LarstiQ: Is the branch with full history is of only 5MB? Then why was bzr took more than half hour and still didn't complete :(
[15:23] <Peng_> I think LarstiQ left out the repo.
[15:23] <LarstiQ> hmm, good point, I recall it being 40~ ish
[15:24] <bvk> well, i was looking for a branch with full history :(
[15:24] <LarstiQ> bvk: it does seem to be so
[15:25] <bvk> btw, is there any way to make a branch with partial history? say, like 50 days history?
[15:25] <LarstiQ> meh, still not looking at the right place
[15:25] <Peng_> bvk: No, there's not.
[15:25] <LarstiQ> bvk: --stacked might help you
[15:25] <LarstiQ> though it does not do it like that
[15:25]  * Peng_ watches bzip2.
[15:27] <Peng_> bvk: http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar -- it's almost 100 MB, and you'll have to run "bzr co .".
[15:28] <Peng_> Ehh, http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar.bz2 saves about 10 MB.
[15:28] <LarstiQ> hth do I end up with a working standalonish branch but it's .bzr/repository is empty
[15:29] <Peng_> .bzr/repository exists but is empty?
[15:29] <Peng_> Maybe it's a stacked branch?
[15:29] <LarstiQ> yeah, it is...
[15:30] <LarstiQ> bvk: well. That explains why it is so small.
[15:30] <LarstiQ> and why logging all took longer than expected
[15:30] <Peng_> http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar.gz saves almost as much as the bzip2 version, and I'm going to stop now.
[15:31] <Peng_> Thank goodness I don't have p7zip, lrzip and lzma on that machine. ;)
[15:31] <LarstiQ> :)
[15:31] <LarstiQ> nullzip? ;)
[15:32] <Peng_> "bzr branch"'s new progress bars are neat. Reminds me a bit of all the info git gives, only prettier. ;)
[15:32] <LarstiQ> bvk: if you do continue downloading my tarball, you should end up with a stacked bzr.devc
[15:32] <bvk> okay, i just found out that i was using bazaar 1.5, where as latest one is at 1.11
[15:32] <Peng_> bvk: Ok, but 1.5 should work fine.
[15:33] <Peng_> Well, it'll probably be slower and use more RAM than 1.11, but it'll *work*.
[15:35] <bvk> i just did 'bzr co .' in LarstiQ's 5MB tree and i got 'Bazaar Branch Format 7 (needs bzr 1.6)\n' :-(
[15:35] <bvk> i will upgrade my bzr and will try 'bzr branch lp:bzr' again
[15:36] <Peng_> Well, 1.5 can branch from lp:bzr fine.
[15:36] <Peng_> Or http://bazaar-vcs.org/bzr/bzr.dev/
[15:37] <bvk> Peng_: my problem is that it takes too much time. I waited for half an hour and it didn't finish
[15:37] <Peng_> Cool, lzma saves close to 20 MB, and that wasn't with the best compression.
[15:38] <Peng_> bvk: You can't wait half an hour? What kind of Internet connection and computer do you have? Not some Pentium II on dial-up, right?
[15:38] <Peng_> Ohnoes, bzr.dev has a new revision. Now my tarballs are out-of-date. :P
[15:39] <bvk> Peng_: mine is macbook with 256Kbps internet
[15:39] <Peng_> bvk: 256 Kbps? Yeah, that could do it...
[15:41] <Peng_> ...It'd take you a long time to download 100 MB, wouldn't it?
[15:42] <LarstiQ> bvk: my tarball should give you a workingtree of bzr.dev at a recent revision, plus .bzr/ bits to act as a stacked bzr branch
[15:42] <bvk> Peng_: true...but its UI always made me think it hung and i would endup either killing it in the middle (impatient :D)
[15:43] <LarstiQ> bvk: so if you extrac that, you can run the bzr _in there_ to branch with
[15:43] <LarstiQ> just run path/to/extracted/bzr.dev/bzr branch ...
[15:43] <Lo-lan-do> I usually try a "watch du -hs .bzr" when I wonder if it's stuck.
[15:43] <Peng_> bvk: Well, it probably wasn't hung. And the next version (not today's 1.11) should have much a much more active progress bar when branching.
[15:43] <LarstiQ> Lo-lan-do: did you see the progress indication that's not in 1.11?
[15:44] <LarstiQ> Lo-lan-do: it succeeds in subjectively making me feel it's waaaay faster
[15:44] <LarstiQ> Lo-lan-do: achieved by actually giving information :)
[15:44] <Lo-lan-do> LarstiQ: I've grown used to just switching to another virtual desktop for a while :-)
[15:45] <Peng_> Hmm, it's kind of creepy that the server lets me monitor how far along bvk's download is, and how fast it's going.
[15:45] <Peng_> Lo-lan-do: You should try it. It's very nice. It gives a running count of the revisions downloaded.
[15:46] <LarstiQ> Lo-lan-do: I picked up that skill when I was on cable. 8kbs up/down combined. Cable modem attached via serial to the pc. Best idea EVAR
[15:48] <Lo-lan-do> Peng: I'm switching back and forth between 1.5 and 1.11rc1 these days, actually.
[15:48] <Peng_> Lo-lan-do: 1.11 final is out. :D
[15:49] <Lo-lan-do> 1.11rc1 seems nice, but the corresponding bzr-svn version takes half an hour for every operation I do on a branch bound to a remote SVN repo, so I often downgrade back to a version that "only" takes four minutes.
[15:49] <Lo-lan-do> Not in Debian yet => it doesn't exist :-)
[15:50] <Lo-lan-do> (I keep pestering jelmer about it, but I also try not to burn him out)
[15:53] <jelmer> Lo-lan-do: :-)
[15:53] <jelmer> Lo-lan-do, I'm trying to get 0.5rc2 out today, hopefully I can have another look at your performance regression after that
[15:54] <Lo-lan-do> jelmer: I'm trying to single out a bug in svn-import, too :-)
[15:54] <jelmer> Lo-lan-do, argh, and I just got the bug count in bzr-svn back to < 30 :-)
[15:56] <LarstiQ> beuno: it looks to me like it may be a bit more complicated than trying to replicate the patch *somewhere*
[15:56] <Lo-lan-do> jelmer: Okay.  Just ping me when it's < 29 then :-D
[15:56] <beuno> LarstiQ, a comment on the bug about the https is fine then  :)
[15:57] <beuno> you did install python-pastedeploy, right?
[15:57] <LarstiQ> beuno: yup
[15:58] <LarstiQ> beuno: and it's working fine for my http vhost
[16:11] <LarstiQ> beuno: added a comment
[16:18] <LarstiQ> lifeless: is bicyclerepair completely bitrotted?
[16:19] <jelmer> any versionedfile API experts around?
[16:19]  * LarstiQ hides
[16:23] <jelmer> LarstiQ, nevermind, already found the problem
[16:23] <jelmer> KnitCorruption caused by a text revision that has the same parent twice
[16:24] <jelmer> Lo-lan-do, never mind me, it's actually at 27 already :-)
[16:25] <Lo-lan-do> jelmer: Does 0.5rc2 change anything related to deleted files by any chance?
[16:26] <jelmer> Lo-lan-do: some things - what's the error you're seeing?
[16:26] <Lo-lan-do> bzr: ERROR: Unable to find file id for child 'editreleases.php' in 'gforge/www/project/admin' in <RevisionMetadata for revision 999, path branches/Branch_gforge in repository 'c3c08832-fc22-4c88-9867-b2b84583e700'>.
[16:27] <jelmer> ah, good chance that's fixed in rc2
[16:27] <Lo-lan-do> At first I suspected that there was a problem with repacking (since I seem to remember it happens on or near revisions 10^n), but that's apparently a different problem.
[16:28] <Lo-lan-do> I'll try using http://people.samba.org/bzr/jelmer/bzr-svn/0.5 then, see if it helps.
[16:38] <jinRooma> so if i push to an ftp server, does it upload every file, or just the modified and new ones?
[16:40] <Peng_> jinRooma: It uploads the new revision data.
[16:41] <jinRooma> Peng_, when you say revision data, do you mean the actual files from the project
[16:41] <Peng_> jinRooma: No, I mean the data in .bzr.
[16:42] <Peng_> jinRooma: Push doesn't deal with working tree files; it deals with revisions.
[16:42] <jinRooma> ok i see. THe way i want to use it is, i work offline on my project, and i then synch it with the server on a daily basis
[16:42] <Peng_> jinRooma: In answer to your question, it only uploads the new data.
[16:42] <Peng_> (Well, it will sometimes download some of the old data, combine it into fewer files, and upload it again, but that shouldn't be a big deal.)
[16:44] <jinRooma> I see, so bzr does do some analysis / comparison of local & remote, and make decisions based on this. its not just a dumb upload
[16:46] <Peng_> jinRooma: Right.
[16:46] <Peng_> Now, bzr isn't the fastest vcs ever, but you have to give it *some* credit. :P
[16:47] <jinRooma> its the only vcs i have used, for some reason could not get my around sub version and cvs
[16:47] <jinRooma> but im using it mainly for back up than versioning
[16:48] <jinRooma> ... which is primitive but better than nothing
[16:48] <jelmer> LarstiQ, any idea what could cause a versionedfile revision to end up with the same parent twice?
[16:49] <jelmer> get_parent_map() seems to filter out the duplicate parent unfortunately, but add_lines() complains
[16:52] <jinRooma> i should probably use rsync or some such for my needs
[16:55] <LarstiQ> jelmer: I don't know, but yesterday I got my bzr.dev in a state where I can't revert because I have two parents or some such
[17:45] <Peng_> Does anyone else care about my bzr.dev tarballs, or can I delete them now? bvk?
[17:47] <bvk> Peng_: you can delete it now; thanks a lot
[17:47] <bvk> :)
[17:48] <Peng_> bvk: Alright.
[18:11] <Lo-lan-do> jelmer: Back to 28, I'm afraid :-/
[18:12] <Lo-lan-do> (Report sent, off for dinner, back later if you have any insights)
[18:19] <jelmer> Lo-lan-do, :-(*
[18:19] <jelmer> rocky, hi
[18:19] <jelmer> rocky, I've worked around the bug you were seeing, but I think it's a bug in bzr.
[18:19] <rocky> jelmer: heyo
[18:19] <jelmer> (not committed to 0.5, as it degrades performance, especially on large trees)
[18:20] <jelmer> http://samba.org/~jelmer/tmp/test-text-existance.diff
[18:20] <rocky> hm
[18:21] <jelmer> hopefully one of the australians can shed some light on the actual problem when they wake up
[18:23] <rocky> hehe
[18:24] <jelmer> alternatively, there's a one-line fix to bzr that will work around it without any performance regressions
[18:24] <jelmer> Lo-lan-do, ENOBUGREPORT
[18:26] <bvk> hi, is there any bzr plugin that would allow me to maintain bugs (and messages) within the code repository?
[18:30] <jelmer> bvk, You mean something like be (BugsEverywhere)?
[18:31] <jelmer> see bugseverywhere.org
[18:31] <bvk> jelmer: well, i don't know about bugseverywhere; let me check it out
[18:33] <jelmer> rocky, alternative test http://samba.org/~jelmer/tmp/fix-add-records-dupe-test.diff
[18:39] <bvk> jelmer: yes, it is what i was looking for. thanks
[18:47] <mwhudson> LarstiQ: i'd actually just noticed something similar the other day
[18:47] <mwhudson> LarstiQ: file a bug, i guess
[19:20] <Lo-lan-do> jelmer: http://bugs.debian.org/512325
[19:20] <jelmer> Lo-lan-do, thanks, just found it
[19:21] <jelmer> I'm trying an import now, at r6132 atm
[19:21] <Lo-lan-do> I was puzzled by the fact that it copies something like 11k revisions even though there are less than 7k in the SVN repo.
[19:22] <jelmer> Lo-lan-do, Some svn revisions probably cause multiple bzr revisions
[19:23] <Lo-lan-do> I supposed that much.  Like, maybe some commits touched files in several branches at once.
[19:23] <Lo-lan-do> Not very important anyway.
[19:25] <flacoste> i've got a problem with bzr-svn repository
[19:25] <jelmer> hi flacoste
[19:25] <flacoste> hi jelmer!
[19:25] <flacoste> I have a bzr-svn branch tracking Windmill repository
[19:25] <flacoste> they moved to a failover server
[19:25] <flacoste> and now I get the following error when I do bzr pull
[19:26] <flacoste> http://svn.getwindmill.com/trunk is permanently redirected to http://svn.getwindmill.com/trunk/
[19:26] <flacoste> bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("Chemin '/windmill/!svn/vcc/default' non trouv\xc3\xa9", 175007)
[19:26] <flacoste> i can load the URL in the browser fine
[19:27] <flacoste> In English, the message reads "Path '...' not found"
[19:27] <jelmer> flacoste, This fails for me as well:
[19:27] <jelmer> svn ls http://svn.getwindmill.com/trunk/
[19:27] <flacoste> hmm, yeah, they just found that out :-)
[19:28] <flacoste> ok, it's probably an error on their end then
[19:28] <flacoste> sorry for the noise
[19:29] <jelmer> np
[19:52] <jelmer> Lo-lan-do, did you remove the svn-cache as well as the bzr repository prior to trying the import?
[19:53] <Lo-lan-do> Ah, damn.  No, I didn't.  Should I do that?
[19:54]  * Lo-lan-do tries
[19:54] <lifeless> -> LCA
[19:54] <lifeless> jelmer: compressbench may interest you, for your xdelta apply/create code
[19:55] <lifeless> Jc2k: did you see my gc stats?
[19:55] <jelmer> lifeless, 'morning
[19:55] <jelmer> Lo-lan-do, oh, never mind
[19:55] <jelmer> Lo-lan-do, just reproduced it
[19:55] <jelmer> lifeless, cool, I'll have a look
[19:55] <jelmer> lifeless, still there?
[19:55] <Jc2k> lifeless: yes
[19:55] <jelmer> lifeless, quick question about knits
[19:55] <Jc2k> lifeless: my reply was something like "omg thats groupcompress?!?"
[19:56] <lifeless> Jc2k: :)
[19:56] <jelmer> lifeless: what are the contents of node_refs ? The first part of the tuple are the parents of the text, what is the second?
[19:56] <lifeless> jelmer: node refs in indices is a list of lists of keys
[19:56] <lifeless> jelmer: for knit mapped packs
[19:57] <lifeless> jelmer: if the knit is defined with parents=True, delta=True, then the node refs length is 2, the first element is parents, the second is the compression tree
[19:57] <lifeless> jelmer: in all bzr repositories, the second must be either empty, or the first parent.
[19:57] <Peng_> lifeless: "-> LCA"?
[19:57] <lifeless> but its intended to be arbitrary
[19:57] <lifeless> Peng_: linux.conf.au
[19:57] <Peng_> Oh.
[19:57] <lifeless> jelmer: just not implemented yet
[19:58] <lifeless> jelmer: if delta=False, parents=True, the node refs length is 1, parents only
[19:58] <lifeless> jelmer: and False False is length 0
[19:58] <jelmer> lifeless, I'm seeing weird errors where add_record() crashes because the existing node_refs[1] contains the first parent and we're trying to add node_refs[1] that is an empty tuple
[19:58] <lifeless> jelmer: finally, delta=True, parents=False, is unimplemented in knits today
[19:59] <lifeless> jelmer: thats when one repository has a text compressed, and the other has a full text. The cross check is overly strict - that is a bug
[19:59] <flacoste> jelmer: they fixed it, but now when I bzr pull, it's refetching everything
[19:59] <Peng_> lifeless: I wanted to bug you about something: One of my bzr-svn branches makes "bzr index" die, with "Did not find ids set([some file IDs])".
[19:59] <lifeless> Peng_: please file a bug
[19:59] <Peng_> lifeless: Alright.
[20:00] <lifeless> Peng_: I'll ask you to run some custom code based on the details in the bug report, but I have a plane to catch now, so can't do it interactively
[20:00] <jelmer> lifeless, Ah, thanks!
[20:00] <jelmer> flacoste, did the repository change in some way ? Did you upgrade bzr-svn?
[20:01] <flacoste> jelmer: you mean the SVN repository, i don't think so, and I haven't update bzr-svn in a while
[20:02] <flacoste> jelmer: actually, i don't know if it will create new BZR revisions
[20:02] <flacoste> the message is
[20:02] <flacoste> Initialising Subversion metadata cache in /home/francis/.bazaar/svn-cache/7915dd7d-006c-436d-aff2-976aa4ca8641
[20:02] <flacoste> and then fetching all revisions
[20:02] <flacoste> but if that metadata is keyed by hostname, then i guess it would be normal
[20:02] <flacoste> to refetch everything
[20:03] <lifeless> flacoste: thats the svn repo uuid
[20:03] <flacoste> the question is, will this create new bzr revisions
[20:03] <lifeless> flacoste: its stored in the repository
[20:03] <lifeless> flacoste: and yes
[20:03] <flacoste> ok, so copying the repository files should preserve the UUID?
[20:03] <lifeless> flacoste: I'm not sure exactly where it is stored, so can't answer that
[20:03] <flacoste> "It's a scripted mirror of the original repo, so it should be the same."
[20:04] <lifeless> god, that could mean anything
[20:05] <flacoste> they are using svnsync
[20:06] <Jc2k> flacoste: by default svnsync would have a different UUID, but i have a hack on bzr-mirror to preserve the UUID
[20:06] <flacoste> Jc2k: can this help me?
[20:07] <flacoste> i mean can I use this to trick bzr-svn in considering the two UUIDs as identical
[20:08] <Peng_> Wow, "bzr check" sure spams .bzr.log.
[20:10] <Jc2k> flacoste: i dont know enough about what you are encountering
[20:10] <Kittens> hm...
[20:11] <flacoste> Jc2k: i have a bzr-svn branch of Windmil and the main server became unavailable, they had to switch to a failover mirror
[20:11] <flacoste> Jc2k: now when I do a bzr pull, it refetches every revision although there should only be about 4 or 5 that I don't have
[20:12] <Jc2k> ah.
[20:12] <flacoste> and I get:
[20:12] <flacoste> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[20:12] <flacoste> but that's not accurate
[20:12] <Jc2k> their failover mirror will have a different UUID; do you know if you can svnsync from their mirror?
[20:13] <flacoste> i don't know, i could check
[20:13] <flacoste> how would that help?
[20:13] <jelmer> flacoste: Do you have any local changes? If not, you can just "bzr pull --overwrite"
[20:14] <jelmer> flacoste, if you had a svn checkout I think you would get errors as well since the UUID of the repository changed
[20:14] <flacoste> i don't, ok, i'll do this
[20:16] <Lo-lan-do> Does svnsync preserve the uuid?
[20:16] <jelmer> Lo-lan-do, not by default I think
[20:17] <flacoste> jelmer: but will this break merging?
[20:17] <Peng_> jelmer: With the fix for bug 308353, will bzr-svn create any particularly convoluted history?
[20:17] <jelmer> flacoste, merging from where?
[20:18] <Peng_> jelmer: Because that's what breaks bzr-search. :)
[20:18] <flacoste> jelmer: for example, if I merge the new branch into one made from the previous repository
[20:18] <Peng_> lifeless: Filed bug 318935.
[20:18] <jelmer> flacoste, that will break, since they are fundamentally different repositories
[20:19] <flacoste> damn
[20:19] <flacoste> anyway to hack it?
[20:20] <jelmer> flacoste: Fix the upstream repository
[20:20] <flacoste> and is there an easy way to do this?
[20:20] <Lo-lan-do> jelmer: You're right.  But one can hack the mirror's UUID by hand, according to http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt
[20:20] <flacoste> using svnsync?
[20:20] <flacoste> aha
[20:21] <jelmer> flacoste, svnadmin setuuid can do that for you
[20:23] <jelmer> Peng_, Not that I'm aware of
[20:24] <guilhembi> vila: still there?
[20:25] <flacoste> jelmer: setuuid is only a 1.5 command and they are running 1.4 :-(
[20:26] <Lo-lan-do> flacoste: What about "vi db/uuid"?
[20:26] <flacoste> Lo-lan-do: is that safe?
[20:26] <Lo-lan-do> It may not be safe at all, I have no idea.
[20:26] <flacoste> lol
[20:26] <Lo-lan-do> It's just that the uuid seems to be stored there.
[20:26] <Lo-lan-do> If it's *only* stored there, then my guess is that it's safe, but...
[20:28] <LarstiQ> Lo-lan-do: seems like it's time for some experimenting! ;)
[20:28] <Lo-lan-do> Yeah, I'm currently "experimenting" with grep -r :-)
[20:28] <Lo-lan-do> Only one result.  db/uuid.
[20:29] <Lo-lan-do> Maybe it is safe after all.
[20:29] <LarstiQ> what about the svnadmin setuuid source?
[20:30] <wgrant> Lo-lan-do: I edited db/uuid in a fresh repository recently, and it worked fine.
[20:30] <Lo-lan-do> I'll read that too, although I don't really care for it (I was only asking about uuids out of curiosity).
[20:30] <flacoste> http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html
[20:30]  * Lo-lan-do deflects stuff to flacoste
[20:30] <flacoste> there is a solution ^^^
[20:33] <Lo-lan-do> LarstiQ: The source code has so many layers of indirection I gave up.
[20:33] <wgrant> I think one of my branches has suffered from bug #302698. Shall I just push my local copy, overwriting the remote branch?
[21:25] <alevine> anybody have experience with bzreclipse? When I import a project by branching it, it seems to freeze
[21:38] <guilhembi> vila: sent a mail. Bonne nuit!
[21:47] <Necoro> hey - is it possible to get the branch status w/o invoking bzr? - or at least to implement such things in C f.ex.
[21:47] <Necoro> because I want to display whether a bzr branch has been changed in my shell prompt
[21:48] <Necoro> and invoking bzr for this is way too slow
[21:48] <jelmer> Necoro, no you really need bzr for that
[21:48] <jelmer> you may be able to use the bzr service stuff though
[21:48] <Necoro> (I already managed to get rid of the "bzr nick" and "bzr revno" calls)
[21:48] <jelmer> (keeps bzr running in the background and makes incremental calls faster)
[21:49] <Necoro> "bzr service stuff" <-- sounds interesting ...
[21:49] <Necoro> documentation somewhere?
[21:49] <jelmer> launchpad.net/bzr-service I think
[21:53] <Jc2k> jelmer: wow, someone already made the crack i was daydreaming about!!
[21:54] <jelmer> Jc2k, the ssh stuff you mean?
[21:55] <Jc2k> jelmer: no, bzr-service!
[21:55] <jelmer> ahh
[21:55] <jelmer> where someone is jam I think
[21:55] <Necoro> hmm - bzr-service seems to be outdated though
[21:56] <Jc2k> yes :(
[21:59] <Jc2k> hmm, didnt take much to make it work again tho
[22:00] <Necoro> I needed to deal a bit with imports ... but as I don't know the bzrlib API, this can only be counted as workaround
[22:00] <Necoro> it's fast however
[22:01] <Necoro> instead of using TCP/Unix Sockets/FIFOs one could also implement this using DBus
[22:02] <Necoro> (at least for unix)
[22:02] <mwhudson> bzr-service needs more unix crack related to pty's and pipes
[22:02] <Necoro> which would also allow to omit explicitly starting the service ;)
[22:02] <Jc2k> i just added an import bzrlib and killed the call trace.something and it worked
[22:14] <sevenseeker> I have been making changes to various files and just noticed I accidentally deleted an entire directory
[22:14] <sevenseeker> how do I restore it and keep my changes?
[22:15] <mwhudson> does bzr revert directory-you-deleted work?
[22:15] <beuno> mwhudson, I think that if the directory isn't there, bzr will barf
[22:15] <beuno> maybe not barf, but not do what you'd expect  :)
[22:16] <sevenseeker> aha, yes... I don't know what I fat fingered earlier but it works great
[22:16]  * sevenseeker is embarrased
[22:16] <sevenseeker> thanks
[22:17] <Necoro> hmm ... my shell prompt now works ;)
[22:17] <Necoro> though there are still some rough edges with bzr-service
[22:28] <alevine> how can I import an authenticated svn repo into bzr? when I try I get a 401 error and when I add username@ I get a traceback
[22:29] <Necoro> and I guess, I'll take the bzr-service client instead of bzr whenever possible ;)
[22:29] <Necoro> should be much faster
[22:32] <jelmer> alevine, prefix the URL with "svn+"
[22:33] <alevine> jelmer, thanks so much. did i miss something in documentation?
[22:33] <alevine> it says its deprecated
[22:34] <alevine> or is it just the fact that it cant figure out that it's subversion because it is authenticated
[22:35] <jelmer> alevine, yeah, it's deprecated - it's a workaround around a bug in bzr itself
[22:37] <Necoro> perhaps bzr-service should get polished and directly integrated into bzr ... this will probably be sufficient to reduce the "bzr is sooo slow" voices a bit
[22:37] <alevine> jelmer, good to know i really appreciate you being here to tell me that
[22:37] <jelmer> alevine, np
[22:38] <jelmer> Necoro, bzr-service has several issues, I think they're mentioned on the main page
[22:39] <Necoro> jelmer: only "unsecure" and "works only on windows" ... if you accept the last one as "who cares", the first one should be easy to fix
[22:40] <Necoro> s/only/not/
[22:40] <jelmer> Necoro: bzr service will run under a different terminal
[22:40] <jelmer> that causes several problems for e.g. the GUI tools
[22:41] <jelmer> and I doubt it supports overriding environment variables right now
[22:42] <Necoro> hmm ok
[22:55] <alevine> jelmer, do you happen to know if branching an svn repo will download every file for every revision regardless of it has changed or not
[22:56] <jelmer> alevine, It will not download files when they have not changed
[22:58] <alevine> hm, ok. thanks
[23:25] <thumper> igc: I've confirmed with bzr.dev that log --line doesn't show non-mainline revs for me now
[23:41] <_raz_> does anyone know why the .bzr dir and files have a wrong mode in 1.10?
[23:42] <_raz_> I cannot do a brnch or pull on the remote directory via ftp
[23:43] <_raz_> as it seems, the files have no rights at all, directories only u+rwx
[23:43] <_raz_> according to the launchpad tracker that was already fixed


[01:02] <ColonelPanik> que pasa?
[15:41] <n0wje> good morning
[16:00] <ColonelPanik> Hey.
[16:02] <n0wje> How are you?
[16:02] <ColonelPanik> Good, always good.
[16:02] <n0wje> great it is cold today!
[16:03] <ColonelPanik> Yes, we need to go to Grants but many roads are closed.  Maybe Sunday?
[16:04] <n0wje> Are they closed? I haven't been watching the news.
[16:06] <ColonelPanik> Parts of I25 and I40 for sure.  US60 mostly closed.  http://nmroads.com
[16:07] <n0wje> yes went to it, but the website is different.
[16:08] <n0wje> looks like a mobile app.
[16:10] <ColonelPanik> http://m.nmroads.com/site.html?RoadConditions
[16:10] <mneptok> nmroads.com versus m.nmroads.com
[16:10] <ColonelPanik> Or you can just drive out and see for yourself?
[16:11] <mneptok> or stay in and not think about it ;)
[16:11] <n0wje> ha ha! no I rather stay nice and safe here in the house.
[16:12] <ColonelPanik> Got places to go and things to do, my dear wife has taken a new job in Grants and we need to get her set up there.  Starts first week in Jan.
[16:15] <mneptok> will the homestead be moved, as well?
[16:15] <mneptok> too nosy?
[16:15] <n0wje> congrats
[16:16] <ColonelPanik> Well, I am still working on our present house, finish and sell is the plan.  Mrs. Panik will get something cheap to start and then............?
[16:17] <ColonelPanik> If anyone would like to purchase a small house in Portales, Gnu Mexico just drop em a line.
[16:19] <ColonelPanik> I also have a nice Louisiana acre of prime swamp land with a mobile home, 40 miles from NO.  Cheap, very cheap.  Did I mention CHEAP?
[16:23] <mneptok> it's above water at LEAST 4 months per year!
[16:24] <mneptok> ColonelPanik: for both Portland and ABQ moves, woowoo and i rented before buying. get Mrs. Panik into a nice apartment with a 6 month lease, and start watching the market in Grants.
[16:24] <mneptok> or rent a house.
[16:24] <ColonelPanik> Little soft part of the year, yeah.
[16:25] <ColonelPanik> mneptok, yes and we have not done that and the job ends and we are stuck with property/mortgage.
[16:26] <ColonelPanik> Thinking about a camper at a place that charges $120/month.
[16:26] <mneptok> oh. i thought this career change was a known permanent deal
[16:28] <ColonelPanik> Lad, so did we but ENMU does not play nice (they are dumping tenured profs)  think Wal-Mart, a few bosses and tons of part timers.  I would not want my degree to be from Wal-School.
[16:29] <ColonelPanik> Where Nancy is going now should be her last deployment.  Should.
[17:04] <n0wje> have a great Christmas and a good new year I got to take care of things outside.
[17:04] <ColonelPanik> You too.
[17:50] <mneptok> ColonelPanik: tenure was always more of a guarantee of intellectual freedoms than a job. but the two go hand-in-hand so closely ...
[17:51] <mneptok> at least in my mind it was. they couldn't fire you if they didn't like what you said. big deal being a Buddhist at The Catholic University Of America. ;)
[17:51] <mneptok> actually, i realized i was a Buddhist while at CUA. says a lot for the the U as well as protection of academic freedoms.
[19:28] <ColonelPanik> "Protection of Academic Freedoms"  Thats a great concept but not in this country.


[15:25] <hamiltra> hello, I'm having some issues with Ubuntu not recognizing the grub loader after a fresh install


[07:44] <Karl-Arne> Howto setup prive ssl sertificate on virtual name server? Any links to howto's?
[07:57] <RoyK> HAPPY CAPS LOCK DAY
[08:02]  * koolhead17 pokes RoyK
[08:44] <ewook> *yawn*
[08:51] <radish> greetings, I want to setup using a two node setup (one controller, one compute node) using ubuntu 12.04, folsom release. The official documentation mentions that the controller node has to use LVM. Is this also true for a setup that would use local hdds on the compute node (no shared storage)?
[08:53] <RoyK> what controller?
[08:55] <melmoth> radish, i think you need lvm only on the nodes where you wanna run nova-volumes (or cinder)
[08:55]  * RoyK uses lvm for most volumes
[08:55] <melmoth> (and i bet you wanted to ask the question in #openstack :) )
[08:56] <radish> melmoth: I did =)
[08:56] <radish> melmoth: so if I use 1 system as the cloud controller and another one as the hypervisor (using local storage), the controller doesn't need lvm as it won't serve volumes?
[08:56] <melmoth> yep.
[08:58] <koolhead17> hola melmoth
[08:59] <melmoth> hola koolhead17
[08:59] <radish> melmoth: another question if you would be so kind: is it really necessary to setup the controller node to be a ntp-server? wouldn't it feasible to use an internal one?
[09:00] <melmoth> you can use an internal one
[09:00] <melmoth> what is important is that all nodes have the same time
[09:00] <koolhead17> radish: we area ll here to help :)
[09:00] <melmoth> otherwise, strange thingds may hapen
[09:00] <koolhead17> melmoth: +1
[09:00] <melmoth> such as services appearing as XX in nova manage service list and stuff
[09:01] <koolhead17> or in another words all nodes need to be synced because multiple service needs to communicate with each other
[09:03] <radish> thank you for your help, guess I'll continue until things screw up =)
[09:04] <koolhead17> radish: it will badly if time is not synced :)
[09:04] <radish> koolhead17: we use an internal ntp-server, no worries =)
[09:05] <koolhead17> radish: point it to that server then
[09:05] <radish> koolhead17: already implemented by our preseed installation
[09:06] <koolhead17> radish: COOL
[10:05] <radish> melmoth: regarding the openstack packages, should I install suggested packages as well? (we have usually turned off suggested/recommended packages for apt)
[10:05] <melmoth> unsure
[10:05] <melmoth> try without, and see if it works ?
[10:54] <radish> Again a question regarding openstack: I'm trying to grant the admin role to the admin user, however, keystone complains about an ambiguous option: "keystone user-role-add: error: ambiguous option: --user could match --user-id, --user_id" which one should I use?
[12:55] <radish> melmoth: if I have mistyped the region at the creation of the swift service, how can I change that? adjust the command and run it again, or do it somehow using the id / service id?
[12:56] <melmoth> dont know. I dont even remember exactly when does one use the region
[12:56] <radish> melmoth: when you create the services and their endpoints in keystone
[12:56] <melmoth> ahh. so i guess you may change it with keystone comand itself
[12:57] <radish> melmoth: so just rerun the same command after adjusting it?
[12:57] <melmoth> i dont see a kesytone endpoint-edit
[12:57] <koolhead17> radish: keystone-endpoint --help
[12:57] <koolhead17> see if it helps
[12:57] <melmoth> but there s a keystone endpoint-list, ten you can keystone endpoint-delete and recreate it
[13:16] <radish> melmoth: thanks for that, I did just rerun the old command and will delete the faulty entry later on. If I run a token-get using the admin user, I get the correct data, but also the message "No handlers could be found for logger "keystoneclient.v2_0.client"" Is this to be expected?
[13:17] <melmoth> i think the no handler error is sort of common
[13:18] <melmoth> what i tend to do is sudo sed -i "s|log_config.*|log_file = /var/log/keystone/keystone.log|g" \
[13:18] <melmoth> /etc/keystone/keystone.conf
[13:18] <melmoth> so i have logs.
[13:24] <hallyn> zul: around?
[13:25] <zul> hallyn: kind of
[13:25] <hallyn> zul: question on openvswitch-datapath-dkms
[13:25] <zul> hallyn: ok
[13:25] <hallyn> zul: it was dropped in q, i assume bc the module exists upstream
[13:25] <zul> hallyn: yeah
[13:26] <hallyn> probelm is the upstream module doesn't yet do gre tunnels.
[13:26] <zul> hallyn: oh...also the dkms doesnt build on quantal either
[13:27] <hallyn> drat :)  my q was going to be which src you recommend i grab (from a juju charm) to build it
[13:27] <zul> hallyn: i think you would have to heavily patch it in order for it to work
[13:28] <hallyn> zul: ok, thx.  gotta think about whether that's worth it or not
[14:03] <radish> melmoth: in the /etc/glance/glance-registry.conf, one has to set config_file, however, the documentation says to use /etc/glance/glance-api-paste.ini, not the default one glance-registry-paste.ini, is this correct?
[14:05] <melmoth> i dont know
[14:05] <melmoth>  i dont see this setting here anywhere in /etc/glance
[14:05] <melmoth> (but i havent finished installing, and am struggling with swift charm)
[14:08] <melmoth> i always have been confused as to why glance needed 2 paste file anyway
[14:16] <radish> melmoth: my /var/log/glance/registry.log is spammed with errors about removing dead childs, source is eventlet.wsgi.server. Do I need some kind of wsgi package (none installed currently)?
[14:16] <melmoth> the whole openstack is a big wsgi.
[14:16] <melmoth> all of em, keystone, nova, glance... Name it, it s wsgi
[14:18] <radish> melmoth: seems it's this bug: https://bugs.launchpad.net/glance/+bug/1042823
[14:19] <melmoth> i never hit this one (yet ?)
[14:25] <radish> melmoth: well, I'm using 2012.2-0ubuntu1~cloud0 which should be fixed, according to the bugreports
[14:45] <radish> melmoth: did solve it, the documentation is faulty
[15:53] <tboat> hey all, is there a way to allow users to connect to sftp without needing a DSA key? or do they still need to generate a SSH key first?
[15:56] <andol> tboat: I assume the answer you are looking for isn't to use a RSA key instead? :) Alternatively you should be able to tell you ssh server to also accept password logins
[15:57] <tboat> i prefer no password logins, for security, so i guess I can't have seperate settings for sftp?  If the answer is just to generate the keys, that is not that big of a deal.
[15:57] <tboat> my server is a LAN samba file server, and currently sftp/ssh to just me with a key, but wish to allow others access to a certain directory via sftp
[15:59] <andol> tboat: So, you want to restirct full shell sessions to key auth, but allow sftp for passwords logins? Not sure how much benefit that would be, given that the user then could just as well login with passwords on sftp and use that access to put a new ssh key in place.
[16:00] <andol> tboat: Alternatively you could have different requires (ssh key vs. passwords) for different users, or only allow certain users to login using sftp.
[16:06] <RoyK> addisonj: does sshd support that?
[16:07] <addisonj> ? assuming you meant andol
[16:09] <tboat> if i restrict them to just sftp, but ssh still uses keys, then the user will still need to generate a key correct? my user is elsewhere, so they would have to generate a key and email it to me, which is fine, but was just looking for an alternate route
[16:10] <andol> tboat: Whatever you restrict them sftp or not is a separate issue from whatever you allow password logins or not. Or did I missunderstand your question.
[16:10] <RoyK> addisonj: erm, yes ;)
[16:11] <tboat> no you did, restricting them to sftp is essentially what i want, but i also need to distinguish the authentication between ssh/sftp, which seems to just not be possible, undertandable as sftp depends on ssh, just looking for a workaround
[16:11] <andol> tboat: But yeah, if they are going to login using ssh keys they will have to send you their public ssh key in some way. (That is unless you generate the keypair and provide them with the private key, which in almost all cases is a worse idea.)
[16:16] <sarnold> tboat: I wonder, if you could run two different sshd daemons; run one on say, port 22, that only does sftp. Run another on port 2222 that only does ssh. You'd need to create your own /etc/init.d/ssh copy that starts the other daemon with a different configuration file. (-f)
[17:28] <axisys> which ubuntu perl package has BER.pm ?
[17:28] <axisys> libconvert-ber-perl is not it which has /usr/share/perl5/Convert/BER.pm
[17:28] <sarnold> axisys: libconvert-ber-perl and libsnmp-session-perl
[17:29] <axisys> sarnold: is there a easy way to find out besides asking here?
[17:29] <sarnold> axisys: apt-file search BER.pm
[17:29] <sarnold> apt-file is an immensely useful little tool :)
[17:29] <axisys> sarnold: thanks a lot
[17:53] <phear> Anyone in the Lafayette, LA area? I'm looking for dev work
[19:08] <maxmahem> hey question. Trying to upgrade server but out of space on /boot. Turns out I have a lot of old packages there. apt-get purge old-linux-image fails with some errors on unmet dependancies (linux-image-server depends linux-image-3.0.0-26-server)
[19:08] <maxmahem> thoughts?
[19:08] <maxmahem> er old kernals there that is.
[19:22] <jdstrand> mdeslaur: fyi, that is probably a dupe of your bug ^
[19:22] <mdeslaur> jdstrand: yeah, I'm looking at it now
[19:23] <jdstrand> cool
[19:44] <koolhead17> philballew, around
[19:44] <koolhead17> seems like netflix gone too http://news.ycombinator.com/item?id=4684384
[19:46] <philballew> koolhead17, lame!
[19:46] <koolhead17> what happned to the monkey script which they released
[19:48] <_ruben> ahh bugger, the /boot on mdadm boot issue didn't get resolved afterall .. wonder what made me think it did :/
[19:49] <philballew> koolhead17, Seems odd if you ask me
[19:49] <philballew> its middle of the day there
[19:49] <philballew> there in east cost iirc from last time
[19:51] <koolhead17> seems like they are turning it off/on on regular basis :P
[19:54] <philballew> koolhead17, iirc github was down last week or something like that
[19:54] <koolhead17> ya
[21:03] <Guest47529> Hi, I have a really strange one I have installed LVM2 but dont have the pvcreate command, why might that be?
[21:08] <Guest47529> strange, I just removed then installed it and the commands were there
[21:36] <ninjai> hey all, I'm running kernel 2.6.32-23 on ubuntu server 12.04, but suffering from this bug: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/565288.  Seems I should upgrade my kernel to 2.6.32 or .34, but I can't find the kernel in the apt-cache.  Where can I obtain the kernel?
[21:36] <blizzow> I installed gcp on my 12.04 server and keep running into this when trying to use it.  http://pastebin.com/nSubWH7X
[21:37] <blizzow> Anyone have any idea what might cause that problem and what the solution might be?
[21:47] <diogo_79> hi
[21:48] <diogo_79> i have an usb modem that is connected to ubuntu server 12.04 but i cannot get it to work, help is need
[21:49] <diogo_79> the modem is identify has SGS Thomson Microelectronics 56k SoftModem
[21:51] <diogo_79> in the dev directory the modem is ttyACM0
[21:51] <diogo_79> i have install minicom to talk to the modem but the port ttyACM0 is not a valid port
[21:52] <diogo_79> what to do next
[22:14] <aFeijo> I've got an WORM! How can I find and remove it?
[22:15] <sarnold> aFeijo: wordpress? :)
[22:15] <aFeijo> no
[22:16] <sarnold> some other php application? :)
[22:16] <aFeijo> I'm using drupal
[22:19] <aFeijo> sarnold, funny that only php does that :p
[22:19] <aFeijo> it seems that it is a exacutable named "i", just the letter
[22:19] <aFeijo> how can I find it? lol
[22:19] <sarnold> aFeijo: find / -name i -print
[22:20] <sarnold> though that may take a little while :)
[22:20] <aFeijo> thanks
[22:20] <aFeijo> /bin/i
[22:20] <aFeijo> damn worm
[22:28] <aFeijo> Opyum Team got me
[22:35] <aFeijo> how can I remove this Opyum Team ???
[22:37] <sarnold> aFeijo: safest and most fail-safe way is to re-install
[22:37] <aFeijo> omg...
[22:38] <sarnold> aFeijo: you _may_ be able to track down where the specific intrusion took place, find related files, replace them, etc. but rootkits can make it impossible to trust anything on the system
[22:39] <aFeijo> I see
[22:43] <aFeijo> thanks for the hints, I'll work on it
[23:01] <ninjai> hey all, I'm running kernel 2.6.32-23 on ubuntu server 12.04, but suffering from this bug: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/565288.  Seems I should upgrade my kernel to 2.6.32 or .34, but I can't find the kernel in the apt-cache.  Where can I obtain the kernel?