[09:32] <k1l> ok, just tested a fresh linuxmint. hexchat connects automatic to spotchat and the mint channels there. so every mint user comming to #ubuntu does this on purpose
[09:33] <bazhang> nice , thanks for doing that k1l
[09:37] <ikonia> they often discuss it in the mint channel
[09:38] <ikonia> the mint channels are very poor
[09:38] <ikonia> they are trying to have an ubuntu style "support" / "non-support" channel
[09:38] <ikonia> and trying really hard to have a friendly channel policy
[09:38] <ikonia> the issue is there is a.) almost no-one in there b.) the people in there are very weak, and you can't tell them they are wrong as that's not friendly
[09:38] <ikonia> so the support quality in there as the norm is pretty poor
[09:39] <ikonia> so you often see people ask in #linuxmint-help, get no/poor response, then ask in #linuxmint-chat get told either the same or "linux mint support is poor so try #ubuntu"
[09:39] <ikonia> or they rage and say "this is why mint support sucks, I'll try #ubuntu as mint is based on ubuntu"
[09:39] <ikonia> I've been watching it for a few weeks now to get an idea of how many are deciding to use #ubuntu and how many are pushed/suggested
[09:44] <k1l> well, i dont want to judge about their standard of support. but if they push the users to get help in #ubuntu or the user come to #ubuntu because they dont feel helped in their channels i dont think that is going to help them build a solid community
[09:46] <ikonia> it's not
[09:46] <ikonia> it's a very small group
[09:47] <ikonia> (from an IRC point of view)
[09:47] <ikonia> their forums seem to be more active, but not great either
[19:17] <bazhang><EMAIL_ADDRESS><---- meepsheep again
[19:22] <io> ahh. I should just make the ban infinite in that case


[03:01] <poolie> hi
[03:02] <mkanat> Hey poolie. :-)
[04:55]  * AfC is wondering why the Inserting stream: Estimate keeps growing slowly. Can't you just cache the current history size in the tip record?
[05:01] <fullermd> It's just checking to see if you're paying attention   ;)
[05:30] <lifeless> AfC: it grows as we find more stuff you don't have
[05:30] <AfC> lifeless: Right. I get that. But
[05:30] <AfC> lifeless: would it be possible to a) cache total size (any commit knows this) +
[05:31] <AfC> lifeless: or s/size # of revisions or.../
[05:31] <AfC> lifeless: + b)  express a % of that size that's been reached?
[05:31] <AfC> ie, just express the total target; if we get there zooooooooom fast, great! if we chug slowly, well, fine
[05:31] <lifeless> its not obvious to me how to make that work with the arbitrary DAGs that occur
[05:32] <lifeless> including partial history scenarios
[05:32] <AfC> but showing a/b of a moving target is ... well, anyway I wouldn't be here offering the thought otherwise
[05:32] <AfC> {shrug} just do revision count?
[05:32] <AfC> anyway
[05:32] <lifeless> so revision count
[05:32] <lifeless> we send revisions last
[05:33] <lifeless> doing revision count results in no change for 95% of the push/pull, then a sudden blat and its done.
[05:33] <lifeless> I'm not saying the current impl is ideal
[05:34] <AfC> lifeless: no informatio of "this tip := this many texts" or something like that?
[05:34] <AfC> (if not, pity)
[05:34] <AfC> anyway, if there was something reasonably static that isn't known at  *download* time but IS known at (say) *commit* time then perhaps it would be "more" useful...
[05:35] <AfC> as a y in x/y
[05:35] <lifeless> so, if you include a vector clock in the rev
[05:35] <lifeless> purely informational
[05:35] <AfC> yeah
[05:35] <lifeless> we could in principle use it - but the problem is that the db storing texts etc is not one dimensional
[05:36] <AfC> well, fair enough
[05:36] <AfC> pity though
[05:36] <lifeless> so there is no local reference to tell us if we have 0% or 100% of each vector until we do graph traversal
[05:36] <AfC> thanks for taking the time to explain
[05:36] <lifeless> its possible something can be done - but as I say, its non obvious to me what shape that would take
[07:28] <vila> hi all
[07:44] <inada-n> Hi, all.
[07:44] <inada-n> https://bugs.launchpad.net/bzr/+bug/172383
[07:45] <inada-n> Is this bug still in bzr?
[07:46] <inada-n> My fellow worker can successfully add decomposed dirname recursively with bzr-2.3b5 on HFS+.
[07:48] <vila> inada-n: Hey Naoki ! AFAIK, there are still grey areas there, so tell him to report any bug it encounters
[07:49] <inada-n> OKey. I'll ask him to use bzr-2.3b5 continually.
[07:49] <vila> inada-n: thanks
[09:56] <TheSaw> Greetings
[13:23] <sobersabre> hi
[13:23] <sobersabre> I've got merging question.
[13:24] <sobersabre> I have 2 branches not related to each other. let's assume both are local master branches.
[13:24] <sobersabre> let's name their folder /b1, /b2
[13:25] <sobersabre> I want to create a folder /stuff
[13:25] <sobersabre> and to merge under it both b1 and b2, so I have ls /stuff: b1, b2,
[13:25] <sobersabre> but so that b1,b2 are the contents of /b1, /b2
[13:25] <sobersabre> hopefully all the commits are inside the rev. history of /stuff
[13:26] <sobersabre> is this possible ?
[13:27] <vila> sobersabre: yes
[13:27] <vila> :)
[13:28] <maxb> Quick question, what format are b1 and b2 in?
[13:28] <maxb> In particular whether they are rich-root or poor-root
[13:28] <vila> in b1 : bzr join b2 (with recent enough bzr formats as maxb points out)
[13:29] <vila> sobersabre: 'join' will put b2 contents directly in b1 so move stuff around in subdirs if you prefer
[13:29] <maxb> I'm slightly unsure what would happen if both branches originated in poor-root formats
[13:29] <vila> maxb: further merges won't work very well IIRC
[13:29] <maxb> But, would the join even work?
[13:32] <vila> I think so
[13:32] <vila> ...or not but in this case there should be an error message
[13:33] <maxb> bzr: ERROR: File id {TREE_ROOT} already exists in inventory as InventoryDirectory('TREE_ROOT', u'p1', parent_id='tree_root-20110125133320-07vztq0cyp7mymdc-1', revision=None)
[13:34] <vila> O_o
[13:34] <vila> format ?
[13:34] <maxb> that was attempting to join two pack-0.92 subdirs into a 2a
[13:35] <vila> ouch, cross-format ! now you're naughty
[14:01] <maxb> jelmer: Hi. So, the reason for the bzr-git test failures is that bzr core has changed from emitting "Created tag foo." on stdout to emitting it on stderr in 2.3
[14:17] <maxb> jelmer: And the dulwich test failures appear to be because urlparse actually behaves differently there
[14:21] <vila> maxb: jelmer is on the move these days, he will be hard to reach
[14:21] <maxb> np, I'll file bugs too, was just opportunistically continuing a conversation from yesterday
[14:22] <vila> ok, I wanted to make sure you were waiting in vain ;)
[14:30] <maxb> File bug 707438 and bug 707434 ftr
[15:59] <jam> morning all
[15:59] <jam> I'm just giving Empathy a try, so sorry if I miss notifications, etc.
[16:05] <jam> hey vila, can you send me a tell? I want to make sure I get it
[16:05] <vila> jam: morning jam !
[16:06] <vila> one more without your nick
[16:06] <jam> I think it pops up a little bubble, rather than playing a noise, and I tend to just ignore it. :(
[16:06] <vila> by the way, do you have a patch for the wt2 failing test ? I saw a brief mail exchange with jelmer but can't find a mp for it
[16:09] <jam> vila: no mp, I just posted something to the mailing list, and wanted to get feedback on it
[16:09] <jam> I can turn it into something, I guess
[16:11] <jam> wow... I'm installing all of the launchpad dependencies, and suddenly *all* of my theming died
[16:12] <vila> sounds unrelated from this side of the ocean...
[16:12] <jam> well, going back into "Appearance" fixed it all back
[16:13] <jam> vila: I would think it would be unrelated, except launchpad-dependencies installs about 50 packages
[16:13] <jam> and messes with your /etc/hosts and all sorts of stuff
[16:13] <jam> (rocketfuel-setup)
[16:13] <vila> yeah, too much to chew at once :)
[16:56] <jam> vila: https://code.launchpad.net/~jameinel/bzr/wt-case-insensitive/+merge/47423
[16:57] <vila> waiting for lp to refresh...
[16:57] <vila> it's failing on OSX too
[16:58] <jam> vila: refreshed
[16:58] <jam> Please test it on Mac OSX
[16:58] <jam> I'm currently logged into Ubuntu, so I can't guarantee that the change fixes it for Windows
[16:58] <jam> but if it does for OSX, then I'm pretty sure
[16:59] <jam> vila: do you remember how to configure gwibber for status.canonical.com?
[16:59] <vila> can you remind me the -s invocation ?
[16:59] <jam> I rebuilt my install, to give it more space
[16:59] <jam> vila: "bzr selftest -s bt.per_workingtree case_sensitive"
[17:00] <vila> fixed :)
[17:01] <vila> jam: aproved
[17:05] <jam> vila: I seem to remember I needed to add a special ppa to get status.canonical.com to work, but I don't remember what it was
[17:05] <vila> oh, yeah, sorry miss that
[17:05] <vila> I use gwibber-bugs-unstable here
[17:06] <vila> and install gwibber, gwibber-service and gwibber-service-statusnet
[17:07] <vila> 2.91.2-0maverick1 for all of them
[17:07] <jam> vila: ppa:gwibber-bugs/unstable ?
[17:07] <vila> I don't remember the precise invocation
[17:08] <vila> the url I have is http://ppa.lp.net/gwibber-bugs/unstable so yeah, this should work
[17:17] <maxb> Hm. I am noticing that for directories, loggerhead displays the revision and timestamp of when they were created as the "last changed"
[17:17] <maxb> I suppose that figuring out the last change in a subtree is possibly non-trivial in bzr?
[17:30] <jam> maxb: correct
[17:33] <maxb> I wonder if it would actually be more accurate to show nothing in the last-changed columns in loggerhead there
[17:33] <jam> maxb: we don't store a recursive 'last-modified' by directory
[17:33] <jam> it would be faster :)
[17:34] <maxb> The thing is, being told that the "src" directory of your active project last changed n revision 2 in 2003 is manifestly a lie
[17:34] <jam> maxb: that was the last time that the directory object itself was changed
[17:34] <jam> not a lie
[17:34] <jam> just probably not what people expect
[17:35] <vila> maxb: almost all the file systems I know of do the same...
[17:35] <jam> vila: true enough. 'ls' reports similar info
[17:35]  * maxb is attempting to sell bzr at work, and is anticipating complaints vs. svn
[17:35] <vila> poor reason to do it too, but still, kind of explain why we did the same
[17:37] <maxb> What does change a directory other than creating it?
[17:39] <vila> maxb: adding, removing, renaming a file
[17:39] <maxb> *ah*
[17:39] <vila> at least on file systems
[17:40] <maxb> hmm
[17:40] <maxb> bzr seems to consider changes to children don't count at all
[17:45] <vila> yes, like file systems: mkdir -p foo; cd foo ; touch bar ; ls -al; sleep 60 ; touch bar; ls -al; cd ..
[17:54] <jam> maxb: vila should have said "adding, removing, renaming *the directory*"
[17:55] <vila> jam: adding a children *to* the directory isn't seen as a change ? Argh
[17:55] <jam> vila: nope
[17:55]  * vila bangs head and EOD
[18:38] <jfkw> Using Gentoo Linux package emacs-vcs, lightweight checkout bzr trunk, 117M. For the last week or so bzr pull's have been gigantic, sometimes GB.
[18:39] <jfkw> #emacs suggested I ask here. Have deleted checkout and am rerunning, will see if building tree runs quicker.
[18:42] <jfkw> Fresh checkout worked very well. Any tip I can pass along to other Gentoo users about why the checkout might have gotten to that state?
[18:46] <maxb> jfkw: Are you pulling over a smart or dumb transport?
[18:47] <maxb> i.e. what is the pull source URL
[18:49] <cody-somerville> abentley, Hey
[18:49] <abentley> cody-somerville, hey.
[18:50] <cody-somerville> abentley, What would make bzr-pipeline's sync-pipeline think a new branch needs to be created for a pipe? Its currently failing for me trying to create a new pipe that already exists remotely.
[18:51] <abentley> cody-somerville, if there's no pipe with the correct name in the remote pipeline, it creates it.
[18:51] <cody-somerville> $ bzr sync-pipeline
[18:51] <cody-somerville> Creating new pipe "sg-2.x"
[18:51] <cody-somerville> bzr: ERROR: Branch in the way at bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/sg-2.x/.
[18:52] <abentley> cody-somerville, Right.
[18:52] <cody-somerville> I've already synced sg-2.x before as you can see
[18:53] <abentley> cody-somerville, No, that demonstrates that you've push or synced it, and if you only pushed it, then it won't be part of the remote pipeline.
[18:53] <cody-somerville> abentley, Well, I did sync it.
[18:54] <cody-somerville> abentley, so should I just delete the sg-2.x branch on launchpad?
[18:54] <abentley> cody-somerville, what's another pipe in the remote pipeline?
[18:54] <cody-somerville> bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/misc-oem-patches/ is the pipe before sg-2.x
[18:55] <jfkw> maxb: /usr/portage/distfiles/bzr-src/emacs-trunk $ bzr info Lightweight checkout (format: 2a) Location: light checkout root: . checkout of branch: bzr://bzr.savannah.gnu.org/emacs/trunk/ shared repository: bzr://bzr.savannah.gnu.org/emacs/
[18:55] <maxb> hmm, so it is a smart server
[18:55] <maxb> In that case, this goes beyond my knowledge
[18:57] <abentley> cody-somerville, does "bzr show-pipeline" show the exact same list as "bzr show-pipeline bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/misc-oem-patches/" ?
[19:00] <cody-somerville> abentley, Yes except for the new pipe I'm trying to sync called default-lb-root-command-to-sudo-linux32-for-i386
[19:01] <abentley> cody-somerville, is that at the beginning of the pipeline?
[19:01] <cody-somerville> abentley, no, after the first
[19:02] <abentley> cody-somerville, I can't see anything wrong with your setup.  I guess this is a bug that I didn't know about.
[19:03] <cody-somerville> abentley, Anything I can do to debug?
[19:05] <abentley> cody-somerville, run "bzr missing" to compare your local and remote copies of sg-2.x
[19:07] <cody-somerville> I had to use "bzr missing :push" and I have 2 extra revisions locally
[19:09] <abentley> cody-somerville, could you re-run sync-pipeline with "bzr -Derror"?
[19:10] <cody-somerville> http://pastebin.ubuntu.com/558218/
[19:13] <abentley> cody-somerville, thanks.  I don't think I can do much more without a way to reproduce it.  I'm guessing they're big branches?
[19:14] <cody-somerville> nope
[19:16] <abentley> cody-somerville, okay, could you upload exact copies of your pipes to devpad?
[19:17] <cody-somerville> abentley, using sync-pipeline? lol
[19:17] <abentley> cody-somerville, no, file-by-file exact copies.
[19:18] <cody-somerville> abentley, okay if I upload a tarball?
[19:18] <abentley> cody-somerville, sounds good.
[19:21] <abentley> cody-somerville, include the shared repository, if there is one.
[19:25] <cody-somerville> abentley, okay, all uploaded to my home dir on devpad
[19:26] <abentley> cody-somerville, thanks.  I've been mirroring the remote pipeline.  Give me a sec to verify it.
[19:38] <cody-somerville> abentley, hmm... I'm going through the code in pdb
[19:39] <cody-somerville> abentley, for some reason, remote_manager.list_pipes() is only returning the first pipe in the pipeline
[19:40] <abentley> cody-somerville, and the first pipe is "live-build"?
[19:40] <cody-somerville> abentley, yup
[19:40] <cody-somerville> (Pdb) p remote_pipes
[19:40] <cody-somerville> [(u'live-build', RemoteBranch(bzr+ssh://bazaar.launchpad.net/~oem-solutions-cdimage/live-build/live-build/))]
[19:41] <abentley> cody-somerville, indeed, live-build does not link to the next pipe in the pipeline.
[19:43] <abentley> cody-somerville, I am going to update the branch.conf in "live-build".
[19:44] <cody-somerville> I wonder what could have caused that.
[19:45] <cody-somerville> abentley, btw, I really enjoy using pipeline (even though I'm still figuring out the best ways to use it).
[19:45] <abentley> cody-somerville, I would guess a new copy of live-build was pushed at some point.
[19:46] <abentley> cody-somerville, I'm glad.  That's certainly a big pipeline you've got goingl.
[19:47] <abentley> cody-somerville, anyhow, I think it's fixed.  Please try sync-pipeline.
[19:47] <cody-somerville> abentley, since it seems like the other pipes in the pipeline have all the info about the rest of the pipeline, maybe it would be possible for sync-pipeline to figure out how to repair the remote pipeline in cases like this?
[19:48] <abentley> cody-somerville, yes, it should.  Right now, it doesn't even notice the inconsistency, though.  I've got a bug for that.
[19:49] <cody-somerville> abentley, Does it look like I'm using pipes right? What I'm doing is creating a new pipe for each patch I create on top of upstream like in the example.
[19:50] <cody-somerville> abentley, I think having the ability to rebase would be useful FYI
[19:51] <abentley> cody-somerville, yes, it looks like you're using it "right", but I don't do packaging, so please let me know if my ideas are impractical.
[19:51] <cody-somerville> abentley, I'm not using this so much for managing the packaging but instead patches directly against upstream that I want to submit upstream
[19:52] <cody-somerville> abentley, I have a single pipe at the end that I use to maintain my changes to the debian packaging provided by upstream and document changes made in my pipes.
[19:53] <cody-somerville> I think I might want to start modify the changelog in each individual pipe and then merging the changelog as I go along so that when I remove a pipe (say upstream accepted it), I can easily merge out the changelog entry along with any straggling delta.
[19:53] <abentley> cody-somerville, do the patches depend on one another?
[19:53] <cody-somerville> abentley, most don't
[19:56] <abentley> cody-somerville, I'm not sure pipeline is the correct tool, then.  I would try to maintain independent patches as separate branches.  What do you like about pipeline for what you're doing?
[19:57] <cody-somerville> abentley, bzr pump :-)
[19:58] <cody-somerville> abentley, and bzr sync-pipeline
[19:58] <cody-somerville> abentley, and bzr show-pipeline
[19:58] <cody-somerville> abentley, and bzr add-pipe is fast
[19:58] <cody-somerville> abentley, and I can decide where in the pipeline I want my patch to be very easily
[19:58] <cody-somerville> abentley, and can easily see the changes introduced in a range of pipes
[19:59] <abentley> cody-somerville, so for your use case, it would be good to have a tool designed to manage an integration branch.
[20:00] <cody-somerville> and I know that pipes closer to the top are closer to upstream's branch and pipes lower in the pipe are further diverged.
[20:01] <abentley> cody-somerville, where each patch was an independent branch, but they still all got merged into the integration branch in a pump-like operation.
[20:01] <cody-somerville> abentley, I like how I only have one directory with everything in it
[20:01] <abentley> cody-somerville, pipeline could be that tool, but the UI could become a nightmare if done poorly.
[20:02] <abentley> Which is why I haven't done it yet.
[20:02] <cody-somerville> I personally think pipeline should become a part of bzr
[20:02] <abentley> cody-somerville, apparently they're looking at something like that.
[20:03] <abentley> cody-somerville, You can also get fast branching by explicitly using a shared repository and a lightweight checkout.
[20:05] <abentley> cody-somerville, you can get branches-all-in-one-directory with the "bzr-colo" plugin.
[20:06] <abentley> cody-somerville, not to discourage you from using bzr-pipeline, just to let you know that not everything is pipeline-specific.
[20:06] <cody-somerville> ok
[20:07] <abentley> cody-somerville, In fact, I tried to use existing tech wherever I could.
[20:17] <abentley> cody-somerville, anyhow, is sync-pipeline working properly now?
[20:29] <cody-somerville> abentley, yup
[20:29] <abentley> cody-somerville, great.
[20:56] <vanguard> I have some tags in my branch that I do not want, I removed them but they come again and again through pull/push. What can I do?
[21:07] <maxb> vanguard: the only way to get rid of a tag is to explicitly delete them from all branches in which they exist
[21:09] <vanguard> and not pull/push in the meantime?
[21:09] <vanguard> how do I get rid of the tag in lp?
[21:10] <maxb> bzr tag -d lp:foo --delete tagname
[21:57] <vanguard> maxb: thanks, I'll try that. I just have the branches on three machines myself, +lp + whoever else ... endeavor to go :D
[23:08] <maxb> woo, fixed dulwich except on lpia
[23:30] <jam> maxb: what's funky about lpia?
[23:30] <jam> (just wondering why it would be fixed everywhere but there)