[00:18]  * LeoNerd unsubs from the mailing list
[00:18] <LeoNerd> This is just waaaaay too busy for me to keep up with :/
[00:50] <jelmer> LeoNerd, hmm? I thought it was actually pretty quiet lately..
[02:11] <poolie> jml, hi?
[03:01]  * igc lunch
[03:17] <jml> poolie: hi
[03:17] <jml> poolie: I'm not at work today.
[04:09] <poolie> hi
[04:09] <poolie> jml, i just realized that
[04:10] <poolie> enjoy your holidays
[04:19] <DBO> is it possible to make one bzr branch just eat all the files of another bzr branch that has no common ancestor
[04:47] <poolie> DBO, 'bzr merge -r 0.. OTHER_BRANCH'
[04:47] <DBO> poolie, slightly too late =(
[04:47] <DBO> just did it all by hand
[04:50] <poolie> sorry
[07:17] <bobesponja> hi
[07:17] <bobesponja> is there a way to do a partial checkout of a branch?
[07:21] <igc> bobesponja: not yet. See http://bazaar-vcs.org/FilteredViews for the latest on progress towards this feature.
[07:36] <bobesponja> ok thanks
[08:04] <igc> time for my xmas holiday/break
[08:05] <igc> see you all next year
[14:40] <CaMason> Hi guys.. I just tried to so a bzr branch over sftp on Vista x64, and I got a BSOD :o
[14:41] <CaMason> if I do a branch on my linux machine, then copy that over to windows, will it work
[14:41] <CaMason> ?
[15:22] <Jc2k> xD
[15:55] <jelmer> Jc2k, hi
[16:48] <jam> bzr co
[16:48] <jam> mt
[16:49] <rexbron> hello, is it possible to change the dpkg-buildpackage command that --source uses in bzr-builddeb?
[16:49] <rexbron> ie. via an environment var or something?
[16:50] <LarstiQ> rexbron: could you give some more context? What are you trying to do?
[16:52] <jelmer> rexbron, yes, I think it's mentioned in the bzr-builddeb docs (can't remember off the top of my head)
[16:53] <rexbron> LarstiQ: in the bzr-bd man page is states that --source defaults to "dpkg-buildpackage -rfakeroot -us -uc -S". Looking closer, I see it mentions that it can use config files, but no reference is made as to 1) where those config files should be/are and 2) the format those config files should take
[16:54]  * LarstiQ looks at bd docs
[16:54] <LarstiQ> rexbron: I'd assume regular bazaar configuration mechanisms
[16:55]  * rexbron found the README :P
[16:55] <LarstiQ> rexbron: the README states, .bzr-builddeb/local.conf in the package directory, ~/.bazaar/builddeb.conf and .bzr-builddeb/default.conf in the package directory
[16:56] <LarstiQ> right :)
[16:59] <rexbron> 199 		    The command used to build a source package if the ``--short`` or ``-S``
[16:59] <rexbron> 200 	69.1.7 	    options are used.
[16:59] <rexbron> hmm, is --short supposed to be --source?
[17:04] <james_w> rexbron: it is, yes
[17:05] <james_w> http://jameswestby.net/bzr/builddeb/user_manual/configuration.html
[17:06] <rexbron> james_w: what would be the best way of adding additonal export profiles? ie. my builder command for the archives would be different from the one I would use for revu.
[17:06] <rexbron> is it possible to do so from the .conf files?
[17:06] <james_w> not currently
[17:06] <james_w> I want to add that sort of ability, but I've not come up with a good way to do it yet
[17:07] <rexbron> james_w: is this a planned feature already? Shall I draw up a spec?
[17:07] <james_w> if you have a good idea of how it should work I would love to hear it
[17:09] <rexbron> james_w: just thinking here, the same way that we can pull the value of builder from config file, perhaps it would be possible to also define a way to have bzr-bd associate command-line switches
[17:09] <rexbron> something along the lines of if --revu is passed and is in a .conf file, use this builder string
[17:10] <james_w> not sure about that
[17:11] <james_w> you could have "--builder-profile revu" which makes it look up "revu-builder" in the configuration
[17:11] <rexbron> and a short alias for brevity :)
[17:11] <james_w> :-)
[17:12] <rexbron> that would simpify things for me and strikes me as something that people will want as Ubuntu moves towards bzr and bzr-bd as the primary tools for handeling packages
[17:15] <james_w> probably
[17:15] <james_w> we also need a way to easily add e.g. "-sa" to the build
[17:15] <james_w> separate "profiles" to do that seems like a bit of overkill
[17:17] <rexbron> james_w: profiles would be an extendable way to impliment that, while seeming like overkill would prevent this sort of problem from ocuring further down the line. I would sugget that either bzr-bd or another package in ubuntu ship a set of commonly used profiles.
[17:17] <james_w> yup
[17:20] <rexbron> james_w: so now it all comes down to getting someone motivated to do it ;)
[17:21] <james_w> heh :-)
[17:30] <rexbron> james_w: I'll take a stab at it, but I am a real amature
[17:30] <james_w> it shouldn't be too hard
[17:30] <james_w> famous last words :-)
[17:30] <james_w> that would be great though, thanks
[17:57] <rexbron> james_w: I am really wondering what the best way to go about this is
[18:03] <rexbron> james_w: I am wondering if implementing something like the way hooks work...
[18:03] <rexbron> would be the best way to go
[18:04] <james_w> I don't see how
[18:15] <rexbron> james_w: basically specifying a section like [PROFILES]
[18:16] <james_w> ah
[18:16] <james_w> yeah, that could work
[18:17] <rexbron> and either specifying profile = revu
[18:17] <rexbron> builder = ..
[18:17] <rexbron> and so on an so forth
[18:17] <rexbron> or whether it would be better to merge the profile name into the variable
[18:18] <james_w> revu = debuild --whatever
[18:18] <james_w> would work
[18:18] <james_w> or it could go in to the [BUILDDEB] section as "revu-builder"
[18:21] <rexbron> james_w: or better might be rather than have a section called profiles, just use the profile name there instead
[18:23] <james_w> rexbron: yeah, I agree
[18:26] <dash> anybody know who I could talk to about bzr-builddeb? :)
[18:26] <james_w> heh
[18:26] <dash> aha
[18:26] <james_w> hello dash
[18:26] <dash> that name looks familiar. :)
[18:27] <dash> so, i'm adding debian packaging to a project I developed in bzr
[18:27] <dash> it uses autotools
[18:28] <dash> i don't keep 'configure' and other generated stuff in the repo, just the sources (configure.ac, Makefile.am)
[18:28] <dash> is there a way to get bzr-builddeb to run autoreconf before starting dpkg-buildpackage?
[18:28] <dash> i could added it to debian/rules, but I wouldn't want to run it if building from a tarball
[18:32] <dash> any ideas? :)
[18:47] <james_w> dash: http://jameswestby.net/bzr/builddeb/user_manual/hooks.html
[18:47] <dash> aha, hooks
[18:48] <dash> i should have read that. :)
[18:50] <dash> that does the trick
[18:51] <dash> james_w: thank you. hope your Christmas is full of merges and conflict-free. :)
[18:53] <james_w> heh. thanks :-)
[19:07] <rexbron> james_w: I think I just got it to work :D
[19:07] <james_w> cool
[19:31] <Jc2k> jelmer: hi
[19:43] <jelmer> Jc2k, hi!
[19:43] <jelmer> Jc2k, I've added a dul-fetch-pack command that seems to work
[19:43] <Jc2k> cool!
[19:45] <jelmer> Jc2k: Your upload-pack command doesn't seem tested yet in the server?
[19:49]  * jelmer now needs to figure out how the pack filename is determined
[19:49] <Jc2k> pack-sha1ofpack.pack
[19:49] <Jc2k> ?
[19:49]  * Jc2k is on phone
[19:52] <jelmer> Jc2k, it's a sha1, but I'm not quite sure of what yet. It's not the sha1 of the pack file or its index at least
[19:54] <Jc2k> i just assumed it was the sha1 of the pack (minus the 20 byte sha footer) :(
[19:54] <Arjen> jelmer: I think you can find the answer in pack-write.c (if you're talking about Git packfiles)
[19:56] <Jc2k> jelmer: am gonna pull the git backend out of the daemon and into dulwich/server.py (planning to add dul-receive-pack and dul-upload-pack)
[19:56] <jelmer> Arjen: That assumes the sha1 is already calculated elsewhere (it uses sha1 in struct packed_git)
[19:56] <Jc2k> unless there is a better place
[19:57] <jelmer> Jc2k, you mean dul-receive-pack and dul-upload-pack as separate binaries ? :-/
[19:57] <Jc2k> jelmer: just for testing purposes - they'll basically be little stubs..
[19:58] <jelmer> Jc2k, ah, ok
[19:58] <Jc2k> jelmer: then i can plumb them directly to git with git-fetch-pack --exec=dul-upload-pack or whatever the syntax is]
[19:58] <rexbron> Interesting error: https://code.edge.launchpad.net/~rexbron/bzr-builddeb/trunk.profiles
[19:58] <jelmer> Jc2k: So dul-daemon will still be using the internal code?
[19:58] <rexbron> something about an internal check failing
[19:59] <Jc2k> jelmer: yeah, it becomes about 3 lines importing TCPGitServer and GitBackend and then calling TCPGitServer.serve_forever
[19:59] <jelmer> Jc2k: Ah, makes sense
[19:59] <rexbron> Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x2def190> has delta references to items not in its repository: {'inventories': [('jw+debian@jameswestby.net-20081202164232-17kqr0tsvqy3ebyi',)], 'texts': [('config.py-20060816235838-wk9rk801k2fdaihy-3', 'jw+debian@jameswestby.net-20080529233852-6p0p3xd8198fx20t'), ('readme-20060917150309-xbse5n20p61fw62z-1', 'jw+debian@jameswestby.net-20080910170020
[19:59] <rexbron> -6helfl8ag97p4sgt')]}
[20:00] <jelmer> rexbron, is this a stacked branch?
[20:00] <Jc2k> jelmer: don't worry, im not going to start doing forky things :p
[20:00] <rexbron> jelmer: yes, but this is only LP's side only
[20:00] <rexbron> s/only//
[20:03] <jelmer> rexbron, looks like a stacking bug to me, there were some issues like this fixed recently
[20:03] <rexbron> jelmer: would it be a client or server side bug?
[20:03] <jelmer> rexbron, no idea, sorry
[20:06] <james_w> I think that was a bug fixed in a recent client
[20:06]  * rexbron goes to see if it hit jaunty
[20:10] <jelmer> Jc2k, found it
[20:10] <jelmer> Jc2k, it's the sha1 over the object sha1s in the pack
[20:10] <rexbron> james_w: would deleting the branch and re-pushing it potentially avoid the error
[20:11] <james_w> rexbron: yes, if you have a fixed client
[20:13] <LarstiQ> jelmer: so then you know not to fetch the pack if you have all objects, or what?
[20:13] <jelmer> LarstiQ, I think the main intent is that it would be unique
[20:14] <jelmer> And deterministic
[20:14] <LarstiQ> hmm
[20:15] <Jc2k> it means lots of people can push at once and not collide
[20:16] <LarstiQ> Jc2k: ah yes, and if the pack is already there, no need to push it, since all your object are there
[20:16] <Jc2k> well, it doesnt care about the pack
[20:17] <Jc2k> just the objects
[20:17] <LarstiQ> how would people collide then if not for the naming?
[20:18] <Jc2k> the objects would be duplicated :)
[20:18] <Jc2k> git just checks all pack indexes until it finds a match, so objects can be duplicated until the next git repack
[20:18] <LarstiQ> ah
[20:19] <rexbron> I just noticed that the bzr PPA does not build packages for Jaunty, would this be possible?
[20:22] <LarstiQ> ~/bzr/+archive has loggerhead-1.10 for jaunty
[20:22] <LarstiQ> rexbron: https://edge.launchpad.net/~bzr-nightly-ppa/+archive though
[20:22] <rexbron> LarstiQ: thanks
[20:26] <asabil> jelmer: I just checked out dulwich, and ran the unit tests, it seems like 1 test case is failing
[20:26] <asabil> is that a known issue ?
[20:45] <Jc2k> jelmer: pushed dul-upload-pack and dul-receive-pack, untested atm (on a mini mini laptop which is making me want to cry)
[20:45] <Jc2k> jelmer: what are you thinking about re tests and the server code?
[20:45]  * Jc2k wants tests v v v v much
[20:46]  * LarstiQ offers jc2k his 3 kilo laptop in exchange for the mini laptop
[20:49]  * Jc2k has an XPS GEN2 at home, so declines :p
[20:50] <jelmer> asabil, yeah, that's right. I haven't checkout out what's causing it yet
[20:50] <jelmer> Jc2k, Yeah, we need heavy testing
[20:50]  * Jc2k agrees
[20:50] <Jc2k> i wanted to test it directly against the client side git components
[20:59] <jelmer> hmm, looks like the delta resolution can use some more work. It works, it's just not very fast
[21:01] <Jc2k> also pushed some protocol doc. its not much atm, but adds a bit more to upstream docs.
[21:08] <rexbron> bzr-bd review request: https://code.edge.launchpad.net/~rexbron/bzr-builddeb/trunk.profiles/+merge/2535
[21:13] <jelmer> rexbron, this seems pretty similar to "source-builder" setting in the bzr-builddeb config?
[21:13] <rexbron> jelmer: what if you have multiple targets for your source builds?
[21:13] <jelmer> rexbron, what do you mean with multiple targets specifically?
[21:14] <rexbron> jelmer: I need to use different dpkg-buildpackage options to upload to REVU as I would for the main ubuntu archives.
[21:14] <rexbron> for example, revu always requires a full-source upload
[21:15] <jelmer> rexbron, ah, ok
[21:15] <jelmer> rexbron, that makes more sense
[21:16] <rexbron> james_w and I discussed this earlier today and came to the conclusion that this is more extendable solution
[21:37] <jelmer> Jc2k, hmm, if I send "have" lines the server suddenly hangs up on me
[21:41] <Jc2k> jelmer: i havent tested that yet - got distracted by the corrupt packs
[21:42] <Peng_> jelmer: Not to try to rush you, but is anything going to become of 308353, or am I gonna be stuck on bzr-svn 0.4 or something?
[21:42] <Peng_> Err, bug 308353
[21:43] <Jc2k> jelmer: will have a look when i've wrapped my mums xmas present!
[21:43] <Peng_> Like I said, I'm not trying to rush you. I'd just like to know it's somewhere on your todo list.
[21:45] <jelmer> Peng_, I *may* get to it in the next two days, otherwise it'll probably be in one of the first days of the new year
[21:46] <Peng_> jelmer: Ok. Thank you. :)
[22:00] <asabil> jelmer: concerning the test failure in dulwich, I think the test case is wrong
[22:00] <asabil> the ordering of the expected result seems reverted
[22:00] <asabil> s/revert/invert/
[22:00] <Jc2k> jelmer: hang up with no error, or something else?
[22:01] <jelmer> Jc2k, never mind that, I've already fixed it
[22:01] <jelmer> asabil, as I said, I haven't really looked into it yet
[22:01] <jelmer> asabil, patches welcome, though :-)
[22:02] <asabil> jelmer: yeah sure, I will try to push a branch when I get more confident about my checks
[22:10] <jelmer> ah, I know why the delta resolving is slow
[22:10] <jelmer> it's in an infinite loop :-P
[22:10] <Jc2k> :p
[22:12] <Jc2k> jelmer: do you have any thoughts on testing server.py?
[22:12] <Jc2k> if not im going to knock up something that should work, but im not sure where it lands on the dirty scale
[22:13] <jelmer> Jc2k, well, some ad-hoc tests won't hurt
[22:13] <jelmer> Jc2k, It would also be nice to test the client against the server
[22:13] <jelmer> but it's also good to test outside of that, to make sure they're not both broken :-)
[22:13] <Jc2k> :]
[22:14] <Jc2k> i was thinking dummy backend + pre-recorded streams to replay at client
[22:14] <Jc2k> **SERVER
[22:14] <Jc2k> idef send_fn(data): sys.stdout.write(data) sys.stdout.flush()
[22:14] <Jc2k> oops
[22:14] <Jc2k> damn tiny laptop
[22:15] <Jc2k> is the client pushed somewhere?
[22:15] <Jc2k> i merged lp:jelmer
[22:15] <Jc2k> /dul/trunk
[22:15] <jelmer> http://people.samba.org/bzr/jelmer/dulwich/trunk
[22:17] <jelmer> Jc2k, ^
[22:17]  * Jc2k merges, commits, pushes
[22:18] <jelmer> Jc2k: hardcoding some streams doesn't seem to ugly to me
[22:18] <jelmer> the main issue would be the readability, and the size of the tests
[22:19] <Jc2k> i was going to reuse the pkt line stuff from server.py
[22:19] <Jc2k> so it would be a bit less eww..
[22:19] <Jc2k> i wanted to try integrating dul-* foo into the git test suite if its not too bad..
[22:21] <Jc2k> i think we can factor some of client and server code out into protocol.py ?
[22:22] <Jc2k> like the pkt_line stuff and sideband stuff.
[22:22] <Jc2k> and possbily capabilities
[22:48] <jelmer> Jc2k, yeah, I think that would be useful
[22:49] <Jc2k> jelmer: just pushed a protocol.py and made client and server use it
[22:49] <Jc2k> im a bit drunk and theres no coverage so YMMV :)
[22:49] <Jc2k> *test
[22:51] <Jc2k> jelmer: going to write some tests that poke the server stuff via protocol.py
[22:57] <Jc2k> jelmer: how about an object with 2 read/write pairs
[22:57] <jelmer> Jc2k: :-)
[22:57] <jelmer> Jc2k, btw, do you have any objection to having all new code being GPLv2+ like bzrlib rather than GPLv2?
[22:57] <Jc2k> none at all
[22:58] <Jc2k> though i wrote some of this on work time so i should probably check..
[22:59] <jelmer> Jc2k: k
[22:59] <Jc2k> tests: i dont want to enter blocking hell by trying to test my server directly, so was thinking about a buffer object where i created an expected conversation (a buffer to read from, and a buffer off what to expect the server to send)
[22:59] <Jc2k> THEN invoke the server handler with a read_fn and write_fn that just operate on the buffer
[23:00] <Jc2k> exploding if the output differs.
[23:00] <jelmer> that doesn't ensure that a packet in the read buffer comes before one in the write buffer and vice versa though?
[23:01] <Jc2k> blocking hell it is, i guess :o
[23:01] <Jc2k> or i could make my test case yield
[23:02] <Jc2k> i dont have enough brain for that tonight..
[23:04] <Jc2k> the conversation builder idea could be modified to be a single buffer of tuples ('r', 'foo'), ('w', 'bar'). the yieldy approach would just remove the buffer and be a pull instead of a push
[23:05] <Jc2k> all so messy.
[23:06] <Jc2k> i might just wait to see how you test the client :P
[23:10] <jelmer> heh, ok
[23:10] <jelmer> cycling time, back in ~45 min
[23:37] <Jc2k> jelmer: moved the send_cmd stuff as AFAIK its tcp/ip specific - so now the GitClient class should work for git+ssh:// access for when i start jabbing things with the git tests