[00:00] <bob2> uh-huh
[00:00] <malibu> bob2: I have many files (work related) that I don't want out there..
[00:00] <jpds> malibu: rdiff-backup.
[00:00] <bob2> tahoe in no way implies storing data with random people
[00:01] <bob2> if you choose to do so, they are carefully encrypted
[00:01] <wgrant> rdiff-backup is awesome.
[00:01] <bob2> it does sound more like you want unison, though
[00:02] <malibu> bob2: Lol.. well I saw "cloud" in the summary and it turned me off@!
[00:06] <malibu> Yes, unison does sound interesting
[00:10] <lifeless> poolie: http://github.com/droundy/iolaus looks interestingish
[00:19] <poolie> interesting
[00:22] <mathrick> yep!
[00:23] <malibu> the thing that makes me leery about unison (and now I remember being here before) is that it points to some guys user directory to download it
[00:23] <malibu> Although the documentation seems to be really good
[00:32] <jelmer> mwhudson, pong
[00:32] <mwhudson> jelmer: hi
[00:32] <jelmer> hello
[00:32] <mwhudson> jelmer: i'd very much like a reply to the latest "plan for incremental code imports" mail
[00:34] <jelmer> mwhudson, a recent one, from after friday ?
[00:37] <mwhudson> jelmer: hm, i don't have anything from you on the subject since tuesday
[00:37] <mwhudson> jelmer: can you resent your latest?
[00:38] <jelmer> perhaps I missed an email
[00:38]  * jelmer looks
[00:38] <mwhudson> jelmer: lots of worrying about topological sorting
[00:39] <ed-209> I'm writing a small app in 2.7.0 that generates a SQLite DB but chokes when I try to add foreign key constraints.  What version of SQLite DBs does Mono.Data.SqliteClient generate?
[00:39] <Peng> ed-209: Wrong channel?
[00:39] <ed-209> oh ya
[00:39] <ed-209> Reading is Fundamental I guess
[00:42] <jelmer> mwhudson, found it
[00:47] <mwhudson> jelmer: anything to talk about now?
[00:48] <jelmer> mwhudson, I'm replying to your email
[00:49] <mwhudson> jelmer: cool
[00:49] <jelmer> also, I just switched to dvorak - so a bit slow still :)
[00:50] <Peng> Enjoying it so far?
[00:51] <mwhudson> :-)
[00:54] <jelmer> peng: typing 8 times slower than usual is *really* frustrating
[00:54] <jelmer> hopefully it'll get better soon
[00:55] <jelmer> sent
[00:55] <jelmer> mwhudson, ^
[00:56] <Peng> If I typed 8 times slower than usual, wow, I couldn't use a computer at all.
[00:57] <mwhudson> jelmer: thanks
[00:57] <jelmer> mwhudson, that's exactly what it feels like
[00:57] <mwhudson> jelmer: you can't even talk to the right person in irc!
[00:57] <jelmer> s/mwhudson/peng
[00:57] <jelmer> mwhudson, :)
[01:01] <meoblast001> hi
[01:01] <wgrant> I tried to switch to Dvorak a couple of years ago, but never got really fast, so I switched back.
[01:02] <meoblast001> i'm told git does not store old revisions of binary files, is this true for Bazaar?
[01:02] <wgrant> But now whenever I think about typing, I unknowingly switch to Dvorak.
[01:02] <Peng> meoblast001: Bazaar does not distinguish between text and binary files.
[01:02] <maxb> meoblast001: I don't think that's true of git, let alone bazaar
[01:03] <meoblast001> ah, so i've been lied to
[01:03] <Peng> Indeed. I'd be very surprised if Git did that.
[01:03] <wgrant> It would make Git pretty useless.
[01:03] <jelmer> wgrant, this is my 4th try :)
[01:05] <lifeless> spiv: ping
[01:05] <igc> hi all
[01:05] <lifeless> spiv: are you on today? I'd like to point you at some polish on the merge hook you did
[01:06] <mwhudson> jelmer: in import_git_objects, can we just limit the times we go around the last for loop?
[01:06] <mwhudson> jelmer: i'm not sure what the "while heads:" loop is doing
[01:20] <malibu> How do I retrieve older versions of files with unison?
[01:20] <bob2> you don't
[01:20] <bob2> it's a sync tool
[01:20] <malibu> Oh but I want versions.. unison won't work for me
[01:21] <malibu> So unison isn't much more then rsync then
[01:22] <jelmer> mwhudson, yeah
[01:22] <mwhudson> jelmer: cool
[01:23] <mwhudson> jelmer: any idea how to test this?
[01:27] <malibu> I basically want protection from anything... such as deleting a file by accident
[01:27] <malibu> I think I might use unison, but also take an incremental backup of the repo a few times a day
[01:49]  * wgrant wishes that bzr would warn when it had a bad email address set.
[02:59] <_Andrew> Hi
[03:01] <_Andrew> Anyone else have a problem where you can't commit through a mounted smb partition unless you do it as root?
[03:02] <_Andrew> My /etc/fstab line looks like this...
[03:02] <_Andrew> /computer/repo /mnt/repo cifs rw,username=user,password=pass,noauto,users,group,exec,dev,suid 0  0
[03:02] <_Andrew> Any ideas?
[03:02] <lifeless> well, what error do you get?
[03:03] <_Andrew> It says permissions denied code 13
[03:03] <_Andrew> Cannot lock lock dir
[03:04] <_Andrew> I'm guessing it's how I setup the mount?
[03:04] <lifeless> that suggests that you don't have permission to lock things
[03:04] <lifeless> if your working tree is on the mount, this could be an OS lock, or a dirlock, where we rename a directory to take the lock.
[03:05] <lifeless> if your working tree is not on the mount, then its only going to be a dirlock; check your users permissions to .bzr/repository/ .bzr/repository/lock and .bzr/branch and .bzr/repository/lock
[03:06] <_Andrew> ok
[03:06] <_Andrew> thanks
[03:08] <_Andrew> Could it be because when I crate a file on the mount it create is with no permissions to write?
[03:08] <_Andrew> create**
[03:09] <lifeless> that would be a problem
[03:39] <lifeless> poolie: I don't know the number that its a dupe of
[03:39] <lifeless> poolie: but I'm very sure its a dupe
[03:42] <poolie> mm it looked familiar
[03:42] <lifeless> it was a smart server code path
[03:42] <lifeless> issue
[03:47]  * igc lunch
[04:03] <poolie> igc, around?
[04:32] <igc> hi poolie: back from lunch now
[04:50] <thumper> just to confirm, if a bug was fixed for 2.0.1 it was also in the 2.1.x branch?
[04:54] <lifeless> check the bug, it should have separate tasks
[04:54] <lifeless> but generally, yes. it would have been fixed in trunk as well. and trunk became 2.1.x recently
[04:57] <thumper> lifeless: https://bugs.edge.launchpad.net/launchpad-code/+bug/3918
[04:57] <thumper> lifeless: only one bzr task
[04:58] <lifeless> should be fixed in 2.1.x then
[04:58] <thumper> ta
[04:58] <lifeless> damn I love noise cancelling headphones
[05:33] <spiv> lifeless: not today, thu and fri
[05:35] <lifeless> so on tue,wed only?
[05:36] <spiv> lifeless: no, off mon,tue,wed, and on thu,fri currently.
[05:36] <lifeless> kk
[05:37] <AfC> How come `bzr ls` shows .~N~ revert files? It's not a problem, of course. Just a bit weird.
[05:37] <lifeless> with no options it acts like 'ls'
[05:37] <lifeless> AIUI
[05:37] <spiv> lifeless: damn ambiguous language :)
[05:38] <lifeless> spiv: I thought it was lovely and clear... and possibly wrong :)
[05:38] <spiv> :)
[05:51] <AfC> lifeless: er, not really. [when recursing] it leaves out [children of] ignored file paths. So why would it show ~ files?
[05:52] <lifeless> AfC: file a bug please ;)
[05:53] <AfC> anyway, I just thought it was weird.
[05:53] <lifeless> it is - thus me wanting a bug ;)
[05:53] <AfC> seeing as how there is a --ignored flag
[05:53] <AfC> ok
[06:03] <AfC> lifeless: https://bugs.launchpad.net/bzr/+bug/522015 filed for you
[06:05] <lifeless> thanks
[06:17] <poolie> AfC, so the problem is actually that it shows ignored files but does not recurse into them?
[06:17] <poolie> spiv, lifeless, https://lists.launchpad.net/launchpad-dev/msg02590.html may be of interest
[06:18] <lifeless> poolie: have you seen ground control ?
[06:18] <lifeless> (i'm glad hydrazine is coming along)
[06:19] <poolie> only briefly
[06:19] <poolie> does it cover bug stuff?
[06:19] <AfC> poolie: I should think that the problem is that it's showing unversioned files. The recursion interaction may be complicating things
[06:19] <poolie> so the bug is 'i wish bzr ls excluded ignored files by default'?
[06:20] <poolie> igc, so regarding annotate
[06:20] <poolie> it would be good to fix
[06:20] <AfC> um isn't it supposed to?
[06:20] <AfC> I mean, otherwise, why the --ignored option?
[06:20] <lifeless> I'd say that being inconsistent is a bug
[06:20] <lifeless> either recurse into and show ignores, or do neither
[06:20] <igc> poolie: hi poolie
[06:20] <AfC> and meanwhile, if you do `bzr ls -R` it does not list contents of ignored [top level] directories]
[06:21] <poolie> igc, so we should probably ask first whether you have anything else yet unfinished
[06:21] <poolie> you, or we
[06:21] <poolie> afc, ls --ignored means "only ignored"
[06:21] <AfC> which is what you'd expect given the whole "ls me what's versioned" expectation
[06:21] <poolie> i don't know if that's really the ideal behaviour
[06:21] <AfC> poolie: [oh]
[06:22] <lifeless> AfC: poolie is being very reflective ;)
[06:22] <AfC> lifeless: just so long as he's not being recursive
[06:22] <poolie> iow shiny
[06:22] <AfC> anyway, I would have thought it wouldn't list any ignored files at all. Seeing as how it seems to ignore some (but not others) I'd say that's the bug
[06:22] <spiv> poolie: (re hydrazine) interesting!  I was just realising earlier today that I can slowly read email and browse the web while holding the baby by carefully driving my laptop with my toes :)
[06:23] <spiv> poolie: a mail client with good key bindings certainly helps when doing that!
[06:23] <poolie> or, carefully hold the baby between your knees and type faster :)
[06:23] <poolie> so i do think in principle one ought to be able to get through bug triage faster by typing than clicking
[06:23] <poolie> it may even be possible on top of this
[06:24] <poolie> s/on top of this/starting from the basic approach of hydrazine
[06:24] <spiv> (Turns out http://en.wikipedia.org/wiki/Morton%27s_toe is not just a random mutation but a distinct advantage ;)
[06:26] <lifeless> spiv: so, you and the statue of liberty huh
[07:06] <JesseW__> What is the difference between a "master branch" and a "parent branch" and are there any other types of branches?
[07:07] <lifeless> a master branch is the branch a bound branch synchronises with
[07:07] <lifeless> a parent branch is the branch that 'pull' and 'merge' will read from by default if you don't supply a url
[07:11] <poolie> spiv, can the cleanup work systematically get rid of TooManyConcurrentRequests etc?
[07:11] <poolie> or could we turn them into eg a warning?
[07:12] <JesseW> lifeless: thanks -- and there are no other kinds?
[07:15] <Peng> It's not like they're different _types_ of branches. A branch just has e.g. "parent_location = foo" in its branch.conf.
[07:16] <Peng> There are several others -- submit (bzr send's default destination), public (used as the public location by 'bzr send' and Loggerhead), and probably more.
[07:16] <Peng> The stacked-on branch, if you're using stacking.
[07:17] <JesseW> Peng: great, that was the sort of thing I wanted to know... so, these are effectively branch properties, that specify various relationships with other branches?  Is there a full list anywhere?
[07:26] <Peng> JesseW: Dunno if there's a full list, aside from digging through the source dode. We definitely listed most of them. :P
[07:30] <spiv> poolie: off the top of my head, only if we get pretty strict about replacing try/finally blocks that might issue smart requests in finallys with the more robust cleanup helpers
[07:30] <JesseW> Peng: cool, thanks.
[07:30] <spiv> poolie: and that's pretty hard to do short of forbidding finally: entirely in test_source
[07:30] <spiv> poolie: but,
[07:31] <spiv> poolie: I think the only_raises decorator that is already on unlock methods in 2.1 will have fixed the majority of cases
[07:31] <spiv> poolie: so 100% seems very hard, but we may already be Good Enough
[07:32] <spiv> (also, potentially except clauses could be troublesome too, so even banning finally perhaps wouldn't be sufficient)
[07:32] <spiv> poolie: I'll be very interested to see how many reports of TMCR we get involving 2.1
[08:07]  * igc dinner
[09:11] <dholbach> hola
[09:11] <dholbach> is bug 522041 known already?
[09:20] <Peng> Yes, and I'm 99% sure it's been fixed.
[09:20] <Peng> dholbach: https://launchpad.net/bugs/515597
[09:20] <dholbach> nice, hope the fix gets into Ubuntu quickly! :)
[09:22] <Peng> dholbach: Ehh, you could edit your bzr install -- it's a _really_ trivial change.
[09:23] <dholbach> Peng: I'm sure I'm not the only one having the problem
[09:25] <Peng> dholbach: Yeah, you're not the only one.
[09:26] <Peng> If you didn't read them, the bugs say the fix will be in 2.1.0 final. I dunno when that will get into Ubuntu.
[09:26] <Peng> It was also said that the bug probably isn't in 2.0, so backporting is not a concern.
[09:27] <dholbach> yep, seems to be a problem "only" in ubuntu lucid and debian experimental right now
[09:28] <poolie> dholbach, it may be fixed in the nightly ppa
[09:28] <poolie> anyhow, good night
[11:37] <mathrick> jelmer: ewww, dvorak
[11:37] <mathrick> it's snake oil, don't believe it
[11:39] <mathrick> malibu: have you looked at that git-based FS thing?
[11:44] <marienz> woo dvorak
[11:45] <idnar> dvorak ftw
[11:46] <idnar> but yeah, learning a new keyboard layout is painful
[11:46] <idnar> it gets easier after the first 5 layouts, though ;)
[11:46]  * marienz blinks
[11:46] <marienz> that is a lot of layouts
[11:48] <fullermd> Well, compared to 101!, it's a pretty small sampling of the choices   :p
[11:48] <idnar> I don't actually know 5 layouts; but languages get easier after the first 5, so I figure keyboard layouts should be the same ;)
[12:45] <gerard_> lifeless: did you unban the guy that kept rejoining and leaving?
[13:26] <slestak> somehow I have gotten to branches on lp linked.  I have a project branch that has my dotfiles repo lited as its parent
[13:26] <slestak> i am sure this is soemthign I did, but I do not want to merge these two.
[13:27] <slestak> could someone pls help me sep these two?
[13:27] <slestak> this is the branch in question, https://code.launchpad.net/~slestak989/+junk/pt
[13:27] <slestak> bzr info shows dotfiles as its parent which is not correct
[13:28] <maxb> I don't think the parent of a launchpad branch actually has any meaning
[13:28] <maxb> If you actually care to look for it, you can find all kinds of people's random local paths in there
[13:29] <slestak> but if I try to sync my workstation to this, it will try to pull in vimrc and whatnot
[13:29] <maxb> huh?
[13:30] <slestak> This was not liek this on Friday, so I thought I would be able to rollback whatever transaction did this
[13:30] <slestak> in the pt dir, if I do bzr missing, it says i am missing every revision in dotfiles
[13:31] <maxb> The value in the launchpad branch is irrelevant for that
[13:31] <maxb> It's the value in your local branch that you're running 'bzr missing' in that matters there
[13:32] <slestak> so that is what I need to correct
[13:32] <maxb> Just do a 'bzr pull --remember' from whatever branch you actually want
[13:33] <slestak> this workign dir is actually the most receent, so I need to push.
[13:33] <slestak> i wonder if this will try to push to dotfiles?
[13:34] <slestak> the help for pull says it will only work for non-diverged branches.  I think these can be considered diverged.
[13:37] <slestak> so try the merge to resolve diverge, or try the pull --remember?  either can be reverted right?
[13:44] <fullermd> Wait...   is the actual _problem_ anything other than "this branch's 'parent' doesn't make sense"?
[13:44] <fullermd> 'cuz if that's the whole problem, there's not a problem...
[13:44] <slestak> fullermd: i am concerned that on my workstation, If I do bzr pull it will pull down src from lp that doesnt belong in this bracnh
[13:45] <slestak> i can revert it if it doesnt work out right?  just try it and dont commit until verify?
[13:46] <fullermd> Well, first off, pull won't pull unless what you're pulling is a superset of what you have (unless you --overwrite of course).  So if two branches are unrelated, pull won't do anything.
[13:46] <fullermd> Second, if you're worried about the effect of the parent branch of the _branch on lp_, on anything you do locally, don't.
[13:47] <slestak> but when I say bzr missing, it lists every revision for dotfiles
[13:47] <fullermd> Saved locations like 'parent' (and 'push', etc) don't imply any linkage between the branches.  They just provide defaults for certain commands.
[13:47] <slestak> add a -v and it shows all of my vim setup.
[13:48] <slestak> I think I see what maxb was saying,  do a pull --remember to set it to the pt branch on lp i want
[13:48] <fullermd> The parent branch of a branch on LP wouldn't matter.
[13:48] <fullermd> Parent just sets the default for pull (and sometimes a few other commands)
[13:48] <slestak> this is the parent branch on my workstation I an discussing
[13:49] <fullermd> Ah.  Well, don't pull then   8-}
[13:50] <fullermd> (not that it'll do anything unless the branches are related, as above)
[13:50] <slestak> too late, lol
[13:50] <slestak> sokay.  it did what both of you said, pulled nothing.
[13:51] <slestak> and --remember did what was expected
[13:51] <slestak> sorry for drama, trying to work bzr into my workflow
[14:09] <igc> night all
[14:10] <rubbs> night
[14:17] <asac> hi ... what does "format: unnamed" mean?
[14:22] <fullermd> It means there's no name for the combination of formats at the given location.
[14:23] <fullermd> Try info -v for the details.
[14:25] <asac> fullermd: hmm. how can that happen?
[14:25] <fullermd> Oh, any number of ways.
[14:25] <asac> for example?
[14:25] <asac> if i merge a branch with a different format?
[14:26] <asac> can i get the branch straight again ;)?
[14:26] <fullermd> Branch format from upstream.  Upgrading one parts but not another.  Various combinations of formats given to init and init-repo.
[14:26] <fullermd> It's not un-straight.  It's just unnamed.
[14:28] <maxb> asac: The most common way it happens is when bzr 2.x combines the latest working tree format with an older branch/repo format.
[14:29] <maxb> This is an unfortunate UI wart, since it obscures the interesting information unless you know to read bzr info -v and interpret it
[14:31] <asac> hmm
[14:31] <asac> so the problem is that i got a branch submission that i cant merge. it seems to use rich-root, but the guy did it on a recent checkout - i assume it means he ran upgrade before submission?
[14:32] <fullermd> Not necessarily.  He could have branched it into an existing RR repository.
[14:32] <asac> sigh
[14:33] <jelmer> asac: Is there a reason you can't upgrade to 2a or another rich root format yourself?
[14:33] <asac> since when does 2a exist?
[14:34] <jpds> asac: karmic.
[14:34] <jelmer> asac: it was introduced in bzr 2.0
[14:34] <asac> right
[14:34] <asac> so until hardy is eol i dont want to do that ;)
[14:34] <asac> but i guess its already too late :(
[14:34] <asac> since our branch somehow morphed into unnamed from pack-0.92
[14:34] <fullermd> 2a isn't the only rich root format.  rich-root-pack dates to 1.0 for instance.
[14:34] <jelmer> asac: alternatively you could switch to 1.0-rich-root, that's bidirectionally compatible with 2a
[14:35] <jelmer> asac: that was introduced before 1.3.1 which is in hardy
[14:36] <asac> thx will think about it ... but i just want to stay on pack-0.92 ... why is bzr so bad to me :(
[14:39] <asac> is there a way to prevent changes to branch format on commits of a branch?
[14:39] <asac> like the "always on top" ... a "never morph branch format" ?
[14:40] <fullermd> Being distributed is kinda antithecal to being able to tie down what other people can do on other branches.
[14:40] <asac> well i dont mind of what the peers do on their own
[14:40] <asac> i just want to ensure that the online branch doesnt change his format
[14:40] <jelmer> asac: fwiw you can always communicate branches in other formats freely, the only situation in which this doesn't work is from a rich root format to a non-rich-root format
[14:41] <fullermd> Branches don't just change their format; somebody changes 'em.  An existing branch won't change unless you upgrade it.
[14:41] <asac> right
[14:41] <asac> but when i do a bzr merge lp:dirtybranch
[14:41] <asac> bzr commit
[14:41] <jelmer> asac: That won't upgrade your branch
[14:41] <asac> and that changes my local branch format without a warning its not really an explicit decision
[14:42] <asac> then how did the online firefox-3.6 branch got upgraded to unnamed?
[14:42] <jelmer> asac: what's the url of that branch?
[14:42] <asac> anyway ... i guess i need to live with this and hope for the best :(
[14:42] <jelmer> asac: Somebody must've run bzr upgrade on it
[14:42] <asac> http://launchpad.net/~mozillateam/firefox/firefox-3.6.head
[14:43] <asac> i only ran bzr upgrade --pack-0.92 on it
[14:43] <asac> i doubt someone else did
[14:43] <fullermd> Standalone branch (format: pack-0.92)
[14:43] <jelmer> asac: according to bzr info that's still pack-0.92
[14:43] <asac> oh
[14:43] <asac> its xulrunner-1.9.2.head
[14:44] <asac> i think
[14:44] <asac> heh
[14:45] <asac> seems its all fine ... hell do i feel bad. sorry
[14:45] <asac> let me complain to the guy that confirmed it was unnamend ;)
[14:46] <jelmer> asac: it may be that when he cloned that branch locally he ended up in an "unnamed" format
[14:46] <asac> probably
[14:46]  * asac happy
[14:46] <jelmer> asac: the "unnamed" bit is confusing indeed
[14:50] <asac> so the reporter has this for  fresh checkout: http://pastebin.com/f13c46178
[14:51] <asac> i have http://pastebin.com/f230277fa
[14:51] <asac> in one case its Working tree format 6
[14:51] <asac> (the unnamed one that is)
[14:51] <fullermd> That's what you'd expect from a 2+ version of bzr.
[14:51] <asac> for me its working tree format 4
[14:51] <asac> fullermd: i have Bazaar (bzr) 2.1.0rc2
[14:51] <asac> he has 2.0.4
[14:52] <asac> seems 2.0 upgrades the working tree format to 6 while 2.1.0 doesnt
[14:52] <asac> so guess that was a bug in karmic bzr?
[14:52] <asac> thats 2.0.4
[14:54] <fullermd> No, 2.1 does it too.
[14:54] <asac> why not for me?
[14:54] <asac> 15:51 < asac> i have http://pastebin.com/f230277fa
[14:54] <fullermd> Because you're using http; it's preserving it over that.
[14:54] <asac> thats bzr info -v
[14:54] <asac> omg
[14:55] <fullermd> Probably some side effect of the format hiding over the smart server.  Dunno.
[14:55] <fullermd> Anyway, WT format doesn't matter anywhere except locally.
[14:55]  * asac happy that thats the case
[14:56] <asac> you are right
[14:56] <asac> over ssh i get the unnamed thing
[14:56]  * asac scared
[14:56] <asac> ok thanks
[15:46] <guilhembi> I'm doing "bzr check -v" on a shared repository (which should take 40 hours), I wonder if -vv would have given interesting info? Or is -v ok?
[15:46] <maxb> I thought bzr's -v was just on/off, not level based?
[15:47] <guilhembi> ah, maybe... :-)
[15:47] <guilhembi> ok, I'll see after 40 hours.
[16:04] <fullermd> I'm not sure -v does anything on check anyway...
[16:12] <henninge> Are there any plans or is anybody working on providing context managers for Tree locks?
[16:12] <jelmer> henninge: I'm not aware of any plans.
[16:13] <henninge> I just implemented one locally in a Launchpad branch and thought this should really be in Tree code.
[16:14] <henninge> jelmer: I am not too familiar with the class structure in bzr but is Tree the class that implementes the locking?
[16:14]  * henninge goes to browse bzr code.
[16:15] <jelmer> henninge: no - a Branch, Repository and Tree are all three lockable but they call out to another class to worry about the actual locks
[16:16] <henninge> ok, now I remember reading the tree locks use branch locks.
[16:16] <henninge> jelmer: should I file a bug about it to start with?
[16:16] <jelmer> henninge, please do
[16:16] <henninge> cool
[16:26] <henninge> jelmer: https://bugs.edge.launchpad.net/bzr/+bug/522195
[16:30] <jelmer> henninge-afk, thanks
[17:35] <Azag> hi
[17:35] <Azag> how I can set a branch as default branch?
[17:36] <Kinnison> Do you mean on launchpad?
[17:36] <Azag> yes
[17:37] <Kinnison> IIRC you set it as the development focus
[17:37] <Kinnison> visit the project page and click "edit details"
[17:37] <Kinnison> scroll to near the bottom
[17:37] <Kinnison> see the dev focus dropdown?
[17:37] <Kinnison> select something from there
[17:37] <Kinnison> That should do it
[17:38] <Azag> in that part
[17:38] <Azag> show
[17:38] <Azag> Development focus:
 trunck
[17:40] <Azag> but when I try: bzr co lp:<my-project> it say me that there is not default branch
[17:43] <Kinnison> What is your package project called?
[17:43]  * Kinnison will look
[17:44] <Azag> Kinnison: shareit-server
[17:44] <james_w> Azag: go to https://code.launchpad.net/<my-project> and there should be a link you can click to set the branch for htat
[17:45] <Azag> I see
[17:45] <Azag> thnx
[17:45] <Kinnison> cool
[17:45] <Azag> jeje, I was looking in the worng page
[17:45] <Azag> thanks Kinnison and james_w
[17:45] <Azag> :)
[17:45] <Kinnison> tbf, it's not completely obvious to me because all my projects already have focusses :-)
[18:39] <Azag> how I can download a bzr branch without a rsa directory
[18:39] <Azag> Warning: Permanently added 'bazaar.launchpad.net,91.189.90.11' (RSA) to the list of known hosts.
[18:39] <Azag> Permission denied (publickey).
[18:39] <Azag> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[18:39] <Azag>  
[18:40] <mwhudson> jelmer: test_log_verbose (bzrlib.plugins.git.tests.test_blackbox.TestGitBlackBox) just errored for me, is this bzr's fault?
[18:41] <mwhudson> bah
[18:44] <jelmer> mwhudson, no idea - what's the error exactyl?
[18:45] <mwhudson> jelmer: http://pastebin.ubuntu.com/377039/
[18:46] <jelmer> mwhudson, ah
[18:46] <jelmer> mwhudson, that's a bzr bug
[18:46] <mwhudson> ok
[18:46] <jelmer> mwhudson, I submitted a merge request for it, not sure what the current status is
[18:50] <mwhudson> jelmer: shoving this information about how many revisions to import through all the layers is no real fun :/
[19:25] <lifeless> gerard_1: thanks
[19:27] <gerard_> lifeless: I was happy to remember it ;)
[19:33] <lifeless> james_w: ping, bzr-builder ppa watching; hows that going? [I'm sure its a case of ETIME
[19:33] <lifeless> :)]
[19:35] <__monty__> Could someone have a look at this, the last comment in particular?
[19:36] <__monty__> *https://code.launchpad.net/~toonn/bzr/no-repo-error-message/+merge/17039 This of course. (forgot the link)
[20:02] <aleksander_m> hi all. Can anyone tell me why the shared-repository (bzr init-repo PROJECT) is needed when using the distributed development approach?
[20:03] <fullermd> It's not strictly needed.  It's useful for saving space when you [would otherwise] have multiple copies of the same history.
[20:05] <aleksander_m> fullermod: humm.. what do you mean?
[20:05] <lifeless> fullermd: might be clearer to say its optional
[20:06] <lifeless> aleksander_m: its optional; shared repository lets multiple branches reuse the same storage database ('repository')
[20:06] <aleksander_m> aha, understood
[20:13] <aleksander_m> another question... when using bzr push to publish commits in the main branch, it happened to me that one of my colleagues didn't do a pull in the mirror branch first, so he pushed his changes but overwrote already pushed changes... is there any way to avoid this?
[20:14] <fullermd> It wouldn't discard other existing changes unless he did push --overwrite; that requires intention.
[20:14] <fullermd> Or do you mean that the existing changes are now showing up in a merge, rather than on mainline like they previously were?
[20:15] <aleksander_m> hum.... you got me
[20:15] <aleksander_m> can't remember
[20:15] <fullermd> Look at `bzr log -n0`.  If the already-pushed changes you're thinking are overwritten show up in some of the indented revs, it's the latter case.
[20:15] <fullermd> If the problem is actually the former...  smack your colleague around for using --overwrite   :)
[20:16] <fullermd> Either situation can also be prevented by setting a branch config option to preserve the mainline.  I'll remember what it's called in a second...
[20:16] <fullermd> append_revisions_only I think?
[20:17] <fullermd> Yeah, that's it.
[20:20] <aleksander_m> will take a look at it
[20:20] <aleksander_m> fullermod: thanks
[20:21] <aleksander_m> s\fullermod\fullermd
[20:42] <lifeless> james_w: hi
[20:43] <james_w> hi lifeless
[20:44] <lifeless> james_w: did you see my ping about builder?
[20:45] <james_w> I did
[20:45] <james_w> it's still on my list
[20:45] <lifeless> kk
[20:45] <james_w> I have spent time on it
[20:46] <james_w> I'm just not happy with some of the interaction that the oauth stuff forces on the user
[20:46] <james_w> so I'm thinking of better ways to structure it
[20:46] <lifeless> ok. if you want a sounding board let me know
[20:47] <james_w> for instance, it only checks whether it has the needed credentials right at the end, after it has gone through the process of building etc.
[20:48] <james_w> and I don't think it should open a webbrowser if it doesn't have the credentials then wait forever for response, as that doesn't fit well with some situations it is expected to be used in
[20:50] <lifeless> james_w: I can see the concern, however it only happens when someone uses this option :)
[20:51] <james_w> that's true, but I don't think they should be punished for using it :-)
[20:52] <poolie> hello lifeless
[20:54] <lifeless> hi poolie
[20:54] <lifeless> james_w: neither do I
[20:54] <lifeless> james_w: but I've learnt to be wary about overgeneralising UI problems
[20:55] <james_w> yes
[21:45] <shakaran> hi, I use Lucid, and I can't install bzr-svn: http://pastebin.com/d3e9b5fe4
[21:51] <mkanat> mwhudson: ping. Any info about the hangs?
[21:51] <mwhudson> mkanat: no
[21:51] <mwhudson> not yet
[21:51] <mkanat> mwhudson: Okay. Why did I think that they weren't happening anymore?
[21:52] <mwhudson> well, they are significantly less frequent
[21:52] <mwhudson> now
[21:52] <mwhudson> so you have to wait a while to get the full picture
[22:00] <mkanat> mwhudson: Okay. Francis said it was every 3 days?
[22:00] <mwhudson> on average
[22:00] <mkanat> mwhudson: Okay.
[22:00] <mwhudson> there was a crash last night, but i'm not sure if the admin did the stack trace thingy
[22:00] <mwhudson> (which i had to rewrite last week, fun)
[22:00] <mkanat> mwhudson: Ahhh.
[22:03] <mkanat> mwhudson: Are the hang logs similar to the last one you showed me, where there are several minutes of nothing in the log, before the restart?
[22:04] <mwhudson> mkanat: i don't know
[22:57] <mkanat> mwhudson: Okay. Do the LOSAs know to get the stack trace the next time the process hangs?
[22:57] <mwhudson> mkanat: i hope so
[22:57] <mwhudson> mkanat: i'm on the phone and have been for a while, i'm not completely ignoring you :-)
[22:57] <mkanat> mwhudson: Ahh, okay. :-) I think I commented on the bug about it several weeks ago, but I haven't gotten a stack trace since then, so I assume that some other form of communication is required?
[22:58] <mwhudson> mkanat: welcome to life in a distributed company!
[22:59] <mkanat> mwhudson: Well, yeah, I'm familiar with it from all the years of working with Mozilla. :-) I assume that the "follow the official process and then also ping people on IRC" solution is similar? :-)
[22:59] <mwhudson> mkanat: yes
[22:59] <mkanat> Okay. :-)
[23:00] <mkanat> losa ping ? :-)
[23:00] <mwhudson> mkanat: ideally we want codebrowse to fall over when i'm working
[23:00] <lifeless> mwhudson: well
[23:00] <lifeless> mwhudson: I beg to differ ;)
[23:01] <mwhudson> lifeless: in a very particular way of course
[23:01] <lifeless> Ideally no fall overs at all:)
[23:01] <lifeless> we want it to learn to run
[23:03] <igc> morning
[23:03] <igc> hi lifeless
[23:09] <lifeless> hi igc