[00:17] <damd> hi.
[00:17] <damd> i can't push because there is a lock caused by me C-c'ing out of an earlier push
[00:17] <damd> bzr break-lock does nothing
[00:17] <damd> any ideas?
[00:18] <mwhudson> damd: try bzr break-lock :push
[00:18] <spiv> mwhudson: beat me to it :)
[00:19] <damd> ah, thanks
[01:20] <inada-n> mathrick: bzr-git can use dulwich from plugins/git/_lib/dulwich
[01:34] <poolie> hi inada-n, spiv
[02:08] <mathrick> inada-n: ah, that's useful
[02:08] <mathrick> does it hold true for other plugins too?
[03:12] <spiv> Hmm, 'perf top' during a parallel selftest run claims ~10% of the time is spent during deque_ass_item.
[03:13] <spiv> Perhaps just a measurement artefact?
[03:16] <spiv> grep doesn't show any obvious places that do 'some_deque[foo] = ...'
[03:17] <mwhudson> could be in subunit?
[03:20] <spiv> mwhudson: I grepped, bzrlib, subunit and testtools
[03:21] <mwhudson> ah
[03:21] <spiv> I'm assuming that python only invokes the sq_ass_item slot in the obvious case of sq[item] = value
[03:22] <spiv> Anyway, it's probably nothing I can quickly improve while getting actual work done... :)
[04:19] <pbouf77> Trying to setup the bzr_access script. When I try to do a test bzr co bzr+ssh://bzr@server/trunk, it asks me for a password..
[04:33] <spiv> pbouf77: but you expected publickey auth?
[04:34] <spiv> pbouf77: I'd try 'ssh -v -l bzr server' to double-check how the SSH client is trying to auth (assuming you are using OpenSSH as the SSH client)
[04:35] <spiv> pbouf77: and also check that the permissions on ~/.ssh and its contents are sufficiently restricted, sshd will probably ignore them if not, although it will hopefully log about it somewhere if that's the case
[04:38] <pbouf77> spiv: yeah publickey. Ok I tried your command, I'm not sure how to interpret the output though
[04:38] <spiv> pbouf77: basically look for lines about 'publickey' or 'trying key ...' and see if what's it's doing (or not doing) matches what you expect
[04:39] <spiv> pbouf77: e.g. if the client is never trying any key, that's a clue :)
[04:39]  * spiv -> late lunch
[04:39] <pbouf77> the bzr user's .ssh dir has perms drwx------
[04:40] <pbouf77> It does seem to be trying keys, "Offering public key: ..." shows up a couple of times, then "Trying private key: ..." then it tries password
[04:41] <pbouf77> also the authorized_keys file has perms -rw-------
[04:45] <poolie> pbouf77, have a look in auth.log
[04:48] <pbouf77> nothing gets added to that log when I try the ssh -v -l bzr server command..
[04:52] <poolie> that's /var/log/auth.log
[04:52] <poolie> really?
[04:53] <poolie> that'd be on the server, not on the client
[04:54] <pbouf77> yep
[04:54] <pbouf77> checked client too for good measure though ;)
[05:14] <pbouf77> arrgh. Ok, I think I see what happened. Serves me right for using pico instead of vim.
[05:14] <pbouf77> somehow my publickey got linebreaks added when I pasted it in
[05:15] <pbouf77> so now I can get as far as "bzr: ERROR: Not a branch: ...". I'm just happy to see a different error message though. :)
[05:17] <pbouf77> ... and that one was much easier to overcome. Looks like I'm on my way.
[05:17] <pbouf77> Thx all for the help.
[07:23] <vila> hi all !
[07:24] <poolie> hi vila, how are you
[07:24] <vila> fine ! the package importer had some troubles this night ?
[07:30] <poolie> over the weekend
[07:30] <poolie> james shut it down; i sent a mail
[07:31] <poolie> we should get it up again
[07:32] <vila> "we" == losas, is "when" known ?
[07:39]  * fullermd waves at vila.
[07:45] <poolie> spiv, i just noticed https://bugs.launchpad.net/bzr/+bug/401646 which seems a lot like the other things you did
[07:50] <vila> fullermd: so, did you test bookmarks with 2.3 ?
[07:50] <fullermd> Insofar as "it doesn't crash anymore, and one of 'em seemed to resolve correctly.
[07:51] <vila> k
[08:00] <fullermd> So, is 2.3 expected to be all peachy with py2.7?
[08:04] <vila> peachy ?
[08:04] <fullermd> Happy.  Solid and unproblematic.
[08:06] <vila> python 2.7 is the default in natty, 2.3 is targeted at natty, if they don't fit, they will be fixed :)
[08:08] <fullermd> Cool.
[08:08] <fullermd> Plan apparently is to move to 2.7 default on FreeBSD in ~March.
[08:09] <vila> the full test suite has been passing for quite some time and the betas were deployed there, so I'm pretty confident we'll know soon enough if anything *new* breaks
[08:10] <vila> Debian releasing, FreeBSD using python2.7 before Ubuntu, what's next ?
[08:11] <fullermd> You know Duke Nukem Forever is coming out, right?   ;)
[08:12] <vila> That's it, I can relax now, just a bad dream...
[08:13] <fullermd> "[...] on May 3, 2011 in North America and May 6, 2011 internationally!"
[08:13] <vila> Seeing is believing
[08:13] <fullermd> That means we're running out of time to port bzr to perl 6...
[08:15] <vila> bah, you always say that and then you actually stop sleeping at night and get things done...
[08:15] <poolie> ok i might call it a night
[08:15] <vila> . o O (how timely ;)
[08:15] <poolie> see you later guys
[08:15] <vila> poolie: see you
[08:15] <poolie> vila can you try to work out about getting the package-importer going?
[08:16] <vila> poolie: it's quite unclear to me at the moment *when* this should be restarted
[08:16] <vila> poolie: did the packaging branches got re-stacked yet ?
[08:17] <vila> poolie: should we restart on jubany ?
[08:20] <fullermd> Sadly, work leaves me no sleep to stop taking...
[08:22] <vila> I think you're on the right track... 1) stop working .... 4) profit... err wait
[08:40] <spiv> poolie: (even though you're not here) it is!  I'll queue it up, may as well fix that class of things thoroughly.
[08:51] <jelmer> hey spiv, vila, fullermd
[08:51] <vila> heya jelmer !
[08:52] <spiv> jelmer: hey :)
[08:53] <spiv> jelmer: I made https://code.launchpad.net/~vcs-imports/vim/trunk today (they seem to have switched from svn to hg), should I go ahead and make it the dev focus?  (I'm guessing you're more up-to-date on the code import stuff than me...)
[08:54] <jelmer> spiv: Yeah, please do :)
[08:56] <spiv> jelmer: done, thanks :)
[09:05] <wgrant> Unstacking can be achieved just by opening the branch and calling set_stacked_on_url(None), right?
[09:05] <wgrant> It seems to work, but I am probably missing something crucial.
[09:06] <vila> wgrant: some revisions may need to copied from one repository to the other ?
[09:06] <vila> s/to copied/to be copied/
[09:06] <wgrant> vila: Doesn't that method do that?
[09:06] <wgrant> At least it takes forever over HPSS.
[09:06] <wgrant> Yeah, it populates the repository.
[09:07] <vila> oh, if it takes forever, there are good changes it does it indeed :-/
[09:07] <wgrant> But I have a script we can run on crowberry to do it all quickly for sid.
[09:08] <wgrant> Since hpss unstacking is far too slow, even from the DC.
[09:08] <vila> wgrant: ha, great, I wasn't sure you were working in that, yes, that's what should be done
[09:08] <wgrant> http://pastebin.ubuntu.com/563762/
[09:08] <vila> s!in that!in/on that!
[09:09] <wgrant> Well, it was going to be tiny, so I thought I might as well try.
[09:11] <vila> wgrant: sounds correct, but I don't know lp internals :-/
[09:12] <vila> wgrant: I'm a bit surprised you need to set 'stacked_on' on both objects though...
[09:12] <wgrant> vila: Right, but I was wondering about bzr internals.
[09:12] <wgrant> set_stacked_on_url seems to handle the locking stuff itself.
[09:12] <vila> wgrant: yes, it has a @needs_write_lock
[09:16] <vila> wgrant: I think you should add some comments in that scripts (at least explaining the overall intent) and fire a mp against lp:udd
[09:16] <vila> wgrant: even if we don't use it until the next debian release, that will still keep track of the packaging branches layout
[09:17] <vila> wgrant: and keep us informed about how this script is going on and when it ends so we can restart the package importer ?
[09:18] <vila> wgrant: but first of all: thanks for your help here (my god, where are my manners...)
[09:20] <wgrant> vila: It probably belongs in the LP tree, given that it needs to be run on crowberry.
[09:22] <vila> wgrant: right, it needs to be run on crowberry, but how a newcomer (on lp or udd) will know that ?
[09:23] <vila> wgrant: i.e. won't it  be lost in the lp tree ?
[09:24] <lifeless> if its going to run on crowberry, it should be in the project that has the code fro running on crowberry :)
[09:25] <vila> Oh, I thought that was what dependencies were about...
[09:26] <lifeless> vila: this is an lp script, using internal lp modules
[09:27] <lifeless> we don't publish that as an API - and won't for the forseeable future
[09:28] <vila> fair enough, I'm just trying to track important bits regarding package importer sanity
[10:38] <vila> wgrant: any news ?
[10:45] <wgrant> vila: Apparently we are going to turn the importer back on, let it push up 22000 new branches, and clean up afterwards.
[10:45] <vila> *blink*
[10:45] <wgrant> Hopefully neither jubany nor crowberry will explode :)
[11:03] <jelmer> hmm, stacked branches don't support directory service lookups?
[11:03] <jelmer> I can't stack onto "lp:gedit"
[11:56] <maxb> jelmer: no, and even more annoying, LP doesn't support stacking on bazaar.launchpad.net/+branch/... either
[16:45] <jelmer> statik
[16:45] <jelmer> argh
[16:46] <jelmer> sorry, wrong mouse button
[16:48] <jelmer> vila: LarstiQ sends his regards
[16:48] <vila> jelmer: \o/
[16:48] <vila> jelmer: please proxy my best regards too ;)
[16:49] <jelmer> will do :)
[16:56] <jelmer> vila: is there a 2.3.1 planned yet?
[16:56] <vila> yes
[16:56] <jelmer> for when?
[16:56] <vila> but, like in a month
[16:56] <vila> ha, just a sec
[16:57] <vila> 2011-03-03 so far, err, no wait, I'll be in vacations :-.
[16:59] <vila> jelmer: well, dunno how we'll do it, but around this date anyway
[17:00] <jelmer> vila: that gives me a good enough idea, thanks :)
[17:02] <jelmer> vila: I found out there were quite a few bzr-gtk MPs that had been sitting there for more than half a year :-/
[17:02] <vila> jelmer: yeah, I saw the mails :-/
[17:57] <maxb> jelmer: Oh, speaking of bzr-gtk, we should make sure that the missing-credits.pickle-in-tarball bug doesn't recur this release.
[17:57] <jelmer> yeah :/
[18:01] <maxb> Personally I was thinking of just checking a copy into the branch, disabling all the automatic updating, and putting it on a release checklist to update it manually
[18:06] <jelmer> I think it might make sense to require it being run upon commits in trunk
[18:06] <jelmer> but yeah, checking it in seems reasonable
[18:12] <maxb> The problem with requiring it run upon commits to trunk is then every normal commit to trunk has to be followed by a credits.pickle update.
[18:13] <jelmer> the merge commit can include it
[19:56] <Buttons840> i have a .../level_a/level_b/...   the files/folders in level_b are revisioned, but i would now like to revision level_a while maintaining the changes to level_b?
[20:03] <GaryvdM> Buttons840: create branch at a, bzr join; commit, add a, commit
[20:03] <GaryvdM> jelmer: ping
[20:04] <GaryvdM> Buttons840: bzr join being the key...
[20:17] <jelmer> GaryvdM: hi
[20:18] <GaryvdM> Hi jelmer
[20:18] <GaryvdM> I want to ask, what version of bzr-svn should I use for bzr 2.3.0 windows installer.
[20:19] <GaryvdM> Latest from trunk (r3515) or r3475, as used in debian?
[20:19] <GaryvdM> jelmer ^
[20:24] <jelmer> GaryvdM: that's a good question
[20:24] <jelmer> I guess current trunk
[20:24] <GaryvdM> Ok
[20:25] <GaryvdM> And I'll do another build if you do a release. :-)
[20:27] <maxb> I wonder when we should push 2.3.0 out to the Ubuntu PPA.
[20:29] <GaryvdM> Hi maxb
[20:30] <GaryvdM> What plugins in the ppa are not compatible with 2.3 yet?
[20:30] <maxb> They're all compatible, but for some of them that's by being snapshots
[20:31] <GaryvdM> By snapshots, do you mean revision from trunk, rather than release version?
[20:31] <maxb> yes
[20:32] <maxb> bzr-fastimport (and python-fastimport)
[20:32] <maxb> bzr-gtk
[20:32] <maxb> bzr-loom
[20:32] <maxb> bzr-rewrite
[20:32] <maxb> bzr-svn
[20:32] <maxb> are the snapshot versions
[20:32] <GaryvdM> Then IMO, I'm sure it ok.
[20:46] <bbutz> I think I'm using reverse cherrypicking wrong
[20:47] <bbutz> I'll reverse merge a feature branch out of my trunk, and then I won't ever be able to merge that branch back in
[21:15] <awilkins> bbutz, If you've already merged the branch, it's not going to do it again (automatically)
[21:15] <awilkins> bbutz, You could cherry-pick it back in again :-)
[21:16] <bbutz> awilkins: was thinking about doing that, but now sad that all the branches I've made off trunk since are having some sense of the reverse merge and causing trouble
[21:53] <cbz> does bzr have an equivalent to svn:externals?
[21:53] <jelmer> cbz: not in the core, but there are some plugins that provide similar functionality
[21:54] <jelmer> e.g. the bzr-externals plugin
[21:54] <cbz> Okay, i'll take a look.
[21:54] <cbz> Also, is there some documentation on bzr internals? (I'm thinking similiar to the internals discussions in the mercurial and progit books)
[21:54] <cbz> Just t rying to understand the bzr conceptual model a little bit better
[22:00] <jelmer> cbz: there are some in the developers docs, in doc/developer in the source distribution
[22:01] <jelmer> g'morning poolie
[22:02] <jelmer> hi jam
[22:02] <jam> hi jelmerr, not around for a lot longer. but good to say hi :)
[22:02] <cbz> Thanks. I just wondered why none of the bazaar documentation doesn't include it (whereas in hg, you get a fairly detailed discussion of revlogs and filelogs)
[22:03] <jam> have a feverish son sitting in my lap while I type. Apparently I'm the go-to guy for fever. He won't sit with my wife right now
[22:03] <cbz> Similiarly git, where the progit book talks about object packs
[22:03] <jam> cbz: git is built around its data format. bzr tries to abstract it away
[22:03] <LeoNerd> bzr's had about 4 different data formats over the years, no? :)
[22:04] <jam> for example, you can use .git as your storage back end (for some levels of fidelity)
[22:04] <cbz> Okay, but even if it abstracts it away, isn't the abstract 'format' itself worth knowing, to understand how bzr works in a bit more detail?
[22:04] <jelmer> jam: :)
[22:04] <jam> cbz: pydoc bzrlib.repository.Repository ?
[22:04] <cbz> I'll take a look thanks.
[22:05] <poolie> hi jam
[22:05] <poolie> sorry k is ill
[22:06] <jam> poolie: yeah.
[22:06] <cbz> hmm.
[22:07]  * jelmer frees his hands of plates
[22:08] <jelmer> jam: That came out wrong, I was smiling to your greeting. I'm sorry to hear he's sick too :-/
[22:08] <jam> jelmer: I thought you were smiling about using .git as the back end. so no hard feelings here :)
[22:09] <jelmer> jam: heh, ok. Just making sure :)
[22:11] <jelmer> Anyway, I'd better be off too
[22:11] <jelmer> jam: See you later, and I hope he gets well soon
[22:11] <jam> have a good night, jelmer
[22:12] <spiv> cbz: I just landed a little bit more about that in the dev docs yesterday, it's in http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html
[22:14] <spiv> cbz: that doc is pretty abstract, and still pretty rough, but hopefully it helps
[22:27] <poolie> jam i feel i must be missing the point about hook naming
[22:27] <poolie> i agree about saving memory at load time, but surely this is a tiny microoptimization compared to just loading less code
[23:11] <cbz> spiv: thanks, that might be better. it appears to me that by the time i've hit the Repository code, the abstraction itself has been 'lost' in favour of translating into the underlying storage model
[23:27] <spiv> cbz: it depends on which operations you want to do, but generally speaking yes :/
[23:30] <poolie> hi spv
[23:30] <poolie> spiv, so bug 401646 looks feasible?
[23:31] <spiv> poolie: I haven't looked at the code yet, but I expect it'll be able to use the infrastructure I landed yesterday
[23:32] <spiv> So, probably straightforward
[23:33] <poolie> cool
[23:42] <kkrev> do the nested branches demonstrated in the centralized workflow tutorial contain complete copies of the source?  In our case that would be a ton of disk space.