[00:03] <Noldorin> jelmer, how's bzr-git and whatnot going anyway? :-)
[00:03] <Noldorin> dw, won't pester you about my issue this time heh
[00:04] <jelmer> Noldorin: mostly working on finishing some of the other stuff I've been working on at the moment, will get back to it after I finish this
[00:05] <jelmer> (faster smart server, feature flags, colocated branches, multi-tarball support in UDD)
[00:06] <Noldorin> cool :-)
[00:07] <Noldorin> what's UDD though?
[00:07] <Noldorin> also not familiar with feature flags heh
[00:07] <wgz> Noldorin: on the grounds negative results are useful too, it would be great if you could post to the bzr list saying what you tried on the sshd front and how it failed
[00:07]  * jelmer waves to wgz
[00:07] <Noldorin> wgz, heh, i've largely forgot now. it was a traumatic experience. but i may be able to summarise the basics still.
[00:23] <jelmer> g'night all
[00:31] <wgz> night jelmer!
[01:18] <Noldorin> night jelmer
[07:55] <vila> hi all
[08:05]  * vila entering 2.5b4 freezing
[08:05] <vila> thanks to whoever merged up 2.4 to trunk, one less hassle :)
[08:26] <vila> mgz, wgz: Can you run 'BZR_PLUGIN_PATH=-site make po/bzr.pot' in bzr.dev and look at the resulting diff
[08:27] <vila> there seem to be more stuff for the registry options (good) but also some deletions (not all  good)
[08:28] <vila> not to mention the irritating spurious line numbers changes but that's a different topic (I still think there should be a way to use filters to avoid that)
[08:30] <vila> mgz, wgz: concretely, I'm concerned about '--strict' and '--directory' options for push being deleted
[08:30] <vila> the rest seems fine
[08:31] <vila> jelmer, poolie, mgz: about to commit -m 'release 2.5b4', so: pqm.lock(RM)
[08:32] <vila> scratch that: pqm.unlock()
[08:36] <lifeless> deleting -d? why?
[08:36] <lifeless> also, can we please unbreak resolve --all path-to-tree ?
[08:36] <vila> bug # ?
[08:37] <vila> resolve --all is evil in general just don't use it
[08:38] <lifeless> perhaps
[08:38] <vila> -d is not deleted from the command, only from the .pot file which may be related to mgz deleting some global options which is why I want him to check
[08:38] <vila> lifeless: I mean, --all remove the conflicts without trying to resolve them nor clean up, this should not be needed anymore
[08:39] <vila> lifeless: if you encounter case where it breaks, please file bugs
[08:39] <lifeless> vila: I use it every time someone deletes a directory from LP
[08:39] <lifeless> vila: and we get directories that can't be removed or whatever
[08:39] <lifeless> its the simplest way to get things correct
[08:40] <vila> lifeless: resolve --take-other ? bzr.transform.orphan_policy=move ?
[08:40] <lifeless> vila: far too hard
[08:40] <vila> Did I miss a smiley there ?
[08:40] <lifeless> no
[08:40] <vila> --take-other is too much compared to --all ??
[08:41] <lifeless> to remember that it exists when --all will DTRT, yes.
[08:41] <vila> --all will not do the right thing
[08:41] <lifeless> vila: you say that, but it does
[08:42] <vila> hmm, I've seen it involved in too many bug reports to agree there, but if it works for you, you know why :)
[08:43] <lifeless> https://bugs.launchpad.net/bzr/+bug/901580
[08:43] <vila> but you started with 'can we please unbreak resolve --all path-to-tree ?' so I'm a bit confused
[08:43] <lifeless> yes, I would like that command to work as it used to.
[08:46] <vila> lifeless: when did it start failing ?
[08:46] <vila> I don't remember recent changes there
[08:46] <lifeless> vila: I'm not sure, 2.4 probably
[08:46] <lifeless> I'm not tracking .dev these days
[08:46] <lifeless> Not deliberately, just seems to have happened
[08:54] <vila> jelmer, poolie, mgz: about to submit 'release 2.5b4', so: pqm.lock(RM)
[08:59] <mgz> morning!
[09:27] <vila> jelmer, poolie, mgz: pqm.unlock(), double-check your submissions against lp:bzr, news entries in particular should now go into 2.5b5
[09:27] <vila> mgz: hey !
[09:27] <vila> mgz: did you read the log here ?
[09:27] <vila> mgz: or should I re-paste ?
[09:33] <mgz> ah, I've not yet, but will do so
[09:35] <mgz> vila: when I last checked, the pot changes were all correct, but I haven't looked at a full b3->b4 diff
[09:36] <vila> mgz: may be '--strict' and '--directory' were dupes ? Anyway, if you can double-check and tell me, that would be nice :)
[09:38] <mgz> heh, xgettext comlains about po-merge plugin, amusing (I guess that's why you said -site :)
[09:38] <mgz> +p
[09:39] <mgz> "utf8" -> "utf-8" works.
[09:41] <vila> yeah, already fixed, silly python for using emacs markup with an encoding that is not recognized by emacs
[09:44] <mgz> ha, I see the issue
[09:44] <mgz> I make dpush a public command, which added the help for that
[09:45] <mgz> and it appears 'after' push, so the options with the same help text get attributed to dpush and removed from push
[09:45] <vila> huh ? --strict doesn't mention 'push' literally ?
[09:46] <mgz> is says "Refuse to push..." which is also true for dpush
[09:46] <vila> hehe
[09:46] <vila> ok, a bit weird but good enough :)
[09:50] <mgz> everything else looks fine
[09:50] <vila> mgz: cool, thanks for checking !
[09:53] <mgz> vila: if I remove the deduping code in export_pot, both headers get printed when combined by the gettext tools in the make step
[09:53] <mgz> providing that as an option and using it from the makefile may be a good thing
[09:54] <mgz> ie, rather than removing the entry and adding it further down, the diff is then:
[09:54] <mgz> +# help of 'directory' option of 'dpush' command # help of 'directory' option of 'push' command
[09:54] <vila> s/when/then/ ?
[09:54] <mgz> -#: bzrlib/builtins.py:1158
[09:54] <mgz> +#: bzrlib/builtins.py:1158 bzrlib/foreign.py:271
[09:54] <vila> oh, far better no ?
[09:54] <mgz> yeah.
[09:55] <vila> also, make po/bzr.pot^W^W export-pot is a bit verbose, if you're tweaking around, can you add a -v option ?
[09:56] <vila> tag wishlist ;)
[10:07] <mgz> hm, should I do a b4 release today then?
[10:07] <vila> mgz: yup
[10:07] <vila> mgz: did you receive my freeze mail or is it another one that get lost ?
[10:08] <mgz> that one arrived :)
[10:08] <vila> ha good
[10:40] <Mez> Hey.  I've just shelved something - now trying to unshelve it, I get
[10:41] <Mez> bzr: ERROR: No such file: None
[10:41] <Mez> how do I fix this?
[10:42] <Mez> bzr 1.13.1
[10:42] <Mez> (this bug is apparently fixed in 1.13 ?
[10:44] <vila> Mez: wow, 1.13 is 2.5 years old, what distro/OS are you using ?
[10:44] <Mez> a box that's still running jaunty :(
[10:44] <Mez> Cause someone f**ked up when they created the dev machines.
[10:44] <vila> correction, 1.23.*2* is 2.5 years old
[10:45] <vila> correction of the correction, 1.13.*2* is 2.5 years old
[10:45] <wgz> bug 319790 which *vila* says it fixed in 1.13 but I wouldn't trust him :)
[10:46] <Mez> yeah - I'm viewing that now
[10:46] <Mez> going to poke a backport onto the server
[10:46] <wgz> using a non-ancient bzr would obviously help, or you could apply the patch from the bug and see if it works then :)
[10:48] <vila> jaunty EOLed long ago we don't even have a PPA for it ;-/
[10:48] <Mez> yeah - I know.... :(
[10:50] <vila> Mez: looking at the patch and the bug comments, I agree with mgz, applying it locally is probably the shortest and safest way to get you unblocked
[10:50] <vila> Mez: do you have admin rights on this machine ?
[10:51] <Mez> yes.
[10:51] <Mez> vila: also - that patch in that bug is present in this version :(
[10:51] <vila> Merwin: Great ! Quick ! While nobody watch, upgrade to oneiric !
[10:51] <vila> argh
[10:51] <Mez> I think you just confused Merwin.
[10:51] <vila> Merwin: sorry, bad completion :-/
[10:52]  * vila curses xchat
[10:52] <Mez> vila - I wish I was allowed.
[10:52] <vila> Mez: Yeah, just kidding to remove some pain from your shoulders ;)
[10:53] <vila> so, patch already applied ? Make sure you use the right bzr (bzr version)
[10:54] <Mez> we've only got one install of bzr on there.
[10:54] <Mez> (1.13.1
[10:54] <vila> :-/
[10:55] <Mez> hmm
[10:56]  * Mez wonders if he can sshmount that box to his and then use his version of bzr
[10:56] <fullermd> You could just run a newer version out of your homedir.
[10:56] <Mez> Not without upgrading python
[10:56] <fullermd> I said new_ER_, not necessarily new_EST_.
[10:56] <vila> 2.4 should still work with your version of python (which is ?)
[10:56] <fullermd> bzr has required py2.4 since...  I dunno.  Ever?
[10:56] <fullermd> Certainly 1.3.
[10:56] <fullermd> (13)
[10:57] <Mez> Couldn't install the lucid version on jaunty - it required a higher verison of python-support
[10:57] <fullermd> Binary packages are always more strict.
[10:58] <Mez> Ninjas
[10:58] <fullermd> The latest 2.3 from tarball should be fine.
[10:58] <Mez> Ninja *
[10:58] <Mez> I just mounted the box via sshfs to my machine
[10:58] <Mez> then bzr unshelved on my machine
[10:58] <vila> ha crap even my jaunty vm is toasted :-/
[11:00] <vila> Mez: Pfew, good move ;)
[11:00] <vila> Mez: unblocked then /
[11:00] <vila> ?
[11:00] <Mez> yeah... lol
[11:00] <Mez> (I added the new files to the main repo"
[11:00]  * vila stop cursing xchat and blames its keyboard instead
[11:01]  * Mez <3 bzr but hates it when things like this happen because he has to deal with dodgyness
[11:02] <Mez> Now all I need is stacked branches working :)
[11:02] <Mez> not stacked...
[11:02] <Mez> nested?
[11:02] <vila> colocated ? :)
[11:02] <Mez> vila: is what cologated?
[11:03] <vila> stacked branches, colocated branches, nested trees, the later is not fully implemented yet
[11:03] <vila> Mez: A set of branches for a single working tree all in the same .bzr directory
[11:03] <Mez> whatever the bzr terminology for the equivalent of externals
[11:03] <vila> Mez: more like the default git setup
[11:04] <vila> nested trees then
[11:04] <vila> but there are various plugins that already address some use cases
[11:04] <vila> bzr-externals, scmproj
[11:06] <Mez> not too sure I understand colocated branches.
[11:08] <vila> Mez: It mainly matters for big working trees where you don't want to have one for every branch you work on but instead shares it (to avoid long recompiles for example). So you just switch from one branch to another but stay in the same dir
[11:09] <vila> Mez: you could do that with bzr already as long as you maintain your branches in a separate hierarchy and use a checkout
[11:09] <Mez> vila - I was going to say - we already do that XD
[11:09] <vila> right, but some people find the actual setup too complex or just can't figure how to get there
[11:12]  * Mez setup a nice bzr system
[11:12] <Mez> but we have some issues with the codebases that we have to work on /systems
[11:23] <mgz> is there a shortcut for deleting all tags from a branch that doesn't have those revisions present?
[11:23] <mgz> I know pushing to it will propogate them again, but can try squishing
[12:25] <jelmer> vila: 2.5b4 uploaded to Debian and Ubuntu
[12:33] <mgz> darn slow connection, you beat me :D
[12:34] <mgz> I did have to test some installer changes first, so can't just blame ISP
[13:03] <wgz> dammit, final tests fail.
[13:05] <wgz> runtime location change did break qbzr
[13:24] <jelmer> it seems some of the gpg tests are still broken on sid
[13:24]  * jelmer drops python-gpgme from the builddeps again
[13:26] <wgz> okay, revert and rebuild works
[13:38] <Merwin> hi guys
[13:38] <vila> jelmer: \o/
[13:38] <vila> jelmer: file a bug for this gpg failure ?
[13:38] <mgz> remind me to unbreak my SxS after lunch
[13:39] <vila> . o O (SxS... looks like a car reference...)
[13:39] <Merwin> We are using bzr (4-5 peoples on the same repo, commiting many times a day). We have branches (not checkout). Each time someone push somethings, we have to do a bzr merge, and then a commit before pushing
[13:39] <Merwin> The problem is that in bzr qlog, we finally only see "Merge" "Merge" "Merge" and we have to open each node to see what have been commited
[13:40] <Merwin> Is there a way to avoid that ?
[13:40] <vila> Merwin: that's the idea yes, the commit message after the merge is supposed to be a summary
[13:40] <mgz> Merwin: having an integraty bot thingy really helps here
[13:41] <Merwin> humf
[13:41] <vila> Merwin: what would like ?
[13:41] <vila> s//you/
[13:41] <Merwin> So if I commit, merge, commit, push
[13:41] <Merwin> I'll have to write twice the same commit :p
[13:41] <mgz> he wants a pretty mailine like bzr has
[13:41] <mgz> *mainline
[13:42] <vila> yup, but in terms of workflow
[13:43] <Merwin> vila, with git you can avoid this by not commiting the merge, and just push your own commits
[13:43] <Merwin> Maybe this is like a checkout+local commits in bzr ?
[13:43] <vila> Merwin: but then you get a straight mainline
[13:43] <jelmer> Merwin: what commands would you use in git?
[13:45] <Merwin> jelmer, humf I didn't remember lemme check
[13:45] <Merwin> vila, yep, but we have a small team, we would prefer this
[13:46] <vila> the smallest team starts at 2 and even there you'll have to merge when both people commit on top on a shared revision
[13:46] <vila> unless you use a central branch and checkouts to make sure you're always up-to-date when you commit
[13:47] <Merwin> jelmer, with a rebase :)
[13:47] <Merwin> vila, are localcommits pushed ?
[13:47] <Merwin> (in chekcout mode)
[13:48]  * fullermd continues to advocate that the phrase "local commits" be struck from the checkout lexicon.
[13:49] <vila> if you use a checkout there is no local commits, they always occur on the shared branch unless you use --local in which case you're not using the central branch anymore so you're back to square one and you have to merge locally to resync
[13:49] <Merwin> humf
[13:49] <Merwin> Ok, so there is no alternative ;)
[13:50] <Merwin> It's not really important anyway
[13:50] <vila> or too many... the bzr-rewrite plugin provides a rebase command if you're into that
[14:43] <ccxCZ> problems with bzr-svn
[14:44] <jelmer> ccxCZ: can you elaborate? :-)
[14:44] <ccxCZ> http://paste.pocoo.org/show/517983/ << previously failed on different revno
[14:45] <ccxCZ> so I assume the http is unreliable and bzr-svn fails instead of retrying
[14:45] <jelmer> ccxCZ: right
[14:46] <ccxCZ> is there some easy workaround?
[14:46] <jelmer> ccxCZ: pull into the branch X revisions at a time
[14:47] <ccxCZ> branch -r 1 and then pull -r with increments?
[14:48] <jelmer> ccxCZ: yep
[14:48] <ccxCZ> hmm still seems to fetch whole svn history
[14:48] <jelmer> ccxCZ: it'll cache the history metadata first
[14:48] <jelmer> ccxCZ: after that it tries to fetch the content of the individual revisions
[14:49] <jelmer> ccxCZ: that first step is basically just running "svn log -v"
[14:50] <ccxCZ> failed
[14:50] <jelmer> ccxCZ: what failed exactly?
[14:50] <ccxCZ> bzr: ERROR: A Subversion remote access command failed: REPORT of '/svn/e/!svn/bc/63093': Could not read response body: Connection reset by peer (http://svn.enlightenment.org)
[14:50] <jelmer> ccxCZ: what's the command you're running?
[14:50] <ccxCZ> bzr branch -r 1 http://svn.enlightenment.org/svn/e/trunk trunk
[14:51] <jelmer> ccxCZ: does "svn log --with-all-revprops --xml -v http://svn.enlightenment.org/svn/e" work?
[14:52] <ccxCZ> recieving...
[14:55] <ccxCZ> ...slow...
[14:57] <ccxCZ> 46187 to go (from 66033)
[14:57] <jelmer> ccxCZ: I tried it here as well, and it hung up on me
[14:57] <ccxCZ> subversion/libsvn_ra_neon/util.c:608: (apr_err=175002)
[14:57] <ccxCZ> svn: REPORT of '/svn/e/!svn/bc/66033': Could not read chunk size: connection was closed by server (http://svn.enlightenment.org)
[14:57] <jelmer> so it's mostly an issue of an unreliable server :-(
[14:57] <ccxCZ> yeah
[14:58] <jelmer> one way to work around it might be to create a local clone with svnmirror
[14:58] <jelmer> and then run bzr-svn against that
[14:58] <ccxCZ> there is such thing? I was on brink of installing svk for that
[15:00] <jelmer> ccxCZ: it's part of svn itself
[15:02] <ccxCZ> I see no such command here and neither as a subcommand of svn{,admin}
[15:03] <ccxCZ> hmm, maybe it's in extras?
[15:03] <jelmer> ccxCZ: sorry, it's named svnsync
[15:08] <ccxCZ> gaargh svn, now I remember why I ran away from you
[15:11] <ccxCZ> okay, managed to create a repo and now syncing revisions
[15:13] <ccxCZ> wouldn't it be better to ask only for necessary data when doing branch -r 1?
[15:13] <ccxCZ> https://code.launchpad.net/~vcs-imports/enlightenment/trunk btw
[16:02] <saper> hi, I did "bzr launchpad-login" sucessfully (I have SSH key there) but I get "Permission denied (public key)" when doing "bzr branch lp:movim", since I don't have any rights on this project. How do I "bzr branch" anonymously while being "lp-loggedin" ?
[16:02] <fullermd> That's an ssh error, not a LP permissions error.
[16:04] <saper> thanks. seems like my session couldn't talk to ssh-agent. fixed by logging-in again, thanks!
[17:36] <jordan> I have a noob question -- I just installed the bzr-gtk package on ubuntu 11.10, but am not seeing an executable for it. How do I start it up? :)
[17:43] <jelmer> jordan: it's a plugin for bzr
[17:43] <jelmer> jordan: e.g. "bzr viz"
[17:44] <jordan> d'oh
[17:44] <jordan> jelmer, ty
[21:33] <jelmer> g'morning poolie
[21:38] <poolie> hi there jelmer
[21:38] <poolie> jelmer, that is nice to hear about multiple tarballs
[21:43] <jelmer> poolie: from the standup you mean?
[21:43] <jelmer> it's a bit disappointing how long that's taking
[21:51] <poolie> is it slowing down because of anything in particular, like is it hard to test?
[21:52] <jelmer> I thought I'd finished it - and it seemed to be working, but getting rid of some of the last issues has required some significant changes in bzr-builddeb
[22:00] <poolie> bugs.launchpad.net/judge is now enabled, jelmer
[22:00] <poolie> i know it's probably buggy
[22:00] <poolie> s//buggy
[22:00] <poolie> some stuff is hardcoded
[22:00] <jelmer> poolie: thanks!
[22:01] <jelmer> I don't remember what the bug was I wanted to report, but I'll file it next time I run into it
[22:01] <jelmer> it did work well for some other stuff, comparing pypy to python2
[22:02] <poolie> specifically N is hardcoded which is a bit ridiculous
[22:06] <jelmer> it must depend on what N actually is, though, right ? :-)
[22:11] <Noldorin> hi jelmer, poolie
[22:11] <poolie> hi there
[22:31] <lifeless> poolie: have you taken today off?
[22:31] <lifeless> poolie: or are you here?
[22:32] <poolie> both :(
[22:32] <poolie> but i hope to go out soon
[22:32] <poolie> what's up?
[22:32]  * lifeless twistches
[22:32] <lifeless> oh, I was going to suggest a bit of a chat, if you wanted
[22:32] <poolie> that would be nice
[22:32] <poolie> voip/pots/skype?
[22:33] <lifeless> skype or pots
[22:34] <poolie> will just finish something here, 2m