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