| === joshuablount is now known as joshuaAFKblount | ||
| * LeoNerd unsubs from the mailing list | 00:18 | |
| LeoNerd | This is just waaaaay too busy for me to keep up with :/ | 00:18 |
|---|---|---|
| jelmer | LeoNerd, hmm? I thought it was actually pretty quiet lately.. | 00:50 |
| poolie | jml, hi? | 02:11 |
| * igc lunch | 03:01 | |
| jml | poolie: hi | 03:17 |
| jml | poolie: I'm not at work today. | 03:17 |
| poolie | hi | 04:09 |
| poolie | jml, i just realized that | 04:09 |
| poolie | enjoy your holidays | 04:10 |
| === mw is now known as mw|out | ||
| DBO | is it possible to make one bzr branch just eat all the files of another bzr branch that has no common ancestor | 04:19 |
| 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:47 |
| poolie | sorry | 04:50 |
| bobesponja | hi | 07:17 |
| bobesponja | is there a way to do a partial checkout of a branch? | 07:17 |
| igc | bobesponja: not yet. See http://bazaar-vcs.org/FilteredViews for the latest on progress towards this feature. | 07:21 |
| bobesponja | ok thanks | 07:36 |
| === Tobbe|autoaway is now known as Tobbe | ||
| igc | time for my xmas holiday/break | 08:04 |
| igc | see you all next year | 08:05 |
| === Tobbe is now known as Tobbe|autoaway | ||
| === Tobbe|autoaway is now known as Tobbe | ||
| === thekorn_ is now known as thekorn | ||
| CaMason | Hi guys.. I just tried to so a bzr branch over sftp on Vista x64, and I got a BSOD :o | 14:40 |
| CaMason | if I do a branch on my linux machine, then copy that over to windows, will it work | 14:41 |
| CaMason | ? | 14:41 |
| Jc2k | xD | 15:22 |
| jelmer | Jc2k, hi | 15:55 |
| === Tobbe is now known as Tobbe|autoaway | ||
| === Hydrogen is now known as MerryChristmas | ||
| jam | bzr co | 16:48 |
| jam | mt | 16:48 |
| 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:49 |
| LarstiQ | rexbron: could you give some more context? What are you trying to do? | 16:50 |
| jelmer | rexbron, yes, I think it's mentioned in the bzr-builddeb docs (can't remember off the top of my head) | 16:52 |
| 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:53 |
| * LarstiQ looks at bd docs | 16:54 | |
| LarstiQ | rexbron: I'd assume regular bazaar configuration mechanisms | 16:54 |
| * 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:55 |
| LarstiQ | right :) | 16:56 |
| 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? | 16:59 |
| james_w | rexbron: it is, yes | 17:04 |
| james_w | http://jameswestby.net/bzr/builddeb/user_manual/configuration.html | 17:05 |
| 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:06 |
| 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:07 |
| 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:09 |
| james_w | not sure about that | 17:10 |
| 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:11 |
| 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:12 |
| 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:15 |
| 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:17 |
| rexbron | james_w: so now it all comes down to getting someone motivated to do it ;) | 17:20 |
| james_w | heh :-) | 17:21 |
| 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:30 |
| rexbron | james_w: I am really wondering what the best way to go about this is | 17:57 |
| === Tobbe|autoaway is now known as Tobbe | ||
| 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:03 |
| james_w | I don't see how | 18:04 |
| rexbron | james_w: basically specifying a section like [PROFILES] | 18:15 |
| james_w | ah | 18:16 |
| james_w | yeah, that could work | 18:16 |
| 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:17 |
| 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:18 |
| rexbron | james_w: or better might be rather than have a section called profiles, just use the profile name there instead | 18:21 |
| james_w | rexbron: yeah, I agree | 18:23 |
| 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:26 |
| dash | so, i'm adding debian packaging to a project I developed in bzr | 18:27 |
| dash | it uses autotools | 18:27 |
| 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:28 |
| dash | any ideas? :) | 18:32 |
| james_w | dash: http://jameswestby.net/bzr/builddeb/user_manual/hooks.html | 18:47 |
| dash | aha, hooks | 18:47 |
| dash | i should have read that. :) | 18:48 |
| dash | that does the trick | 18:50 |
| dash | james_w: thank you. hope your Christmas is full of merges and conflict-free. :) | 18:51 |
| james_w | heh. thanks :-) | 18:53 |
| rexbron | james_w: I think I just got it to work :D | 19:07 |
| james_w | cool | 19:07 |
| Jc2k | jelmer: hi | 19:31 |
| jelmer | Jc2k, hi! | 19:43 |
| jelmer | Jc2k, I've added a dul-fetch-pack command that seems to work | 19:43 |
| Jc2k | cool! | 19:43 |
| jelmer | Jc2k: Your upload-pack command doesn't seem tested yet in the server? | 19:45 |
| * 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:49 | |
| 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:52 |
| 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:54 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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')]} | 19:59 |
| 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:00 |
| 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:03 |
| james_w | I think that was a bug fixed in a recent client | 20:06 |
| * rexbron goes to see if it hit jaunty | 20:06 | |
| 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:10 |
| james_w | rexbron: yes, if you have a fixed client | 20:11 |
| 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:13 |
| jelmer | And deterministic | 20:14 |
| === phinze_ is now known as phinze | ||
| LarstiQ | hmm | 20:14 |
| Jc2k | it means lots of people can push at once and not collide | 20:15 |
| 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:16 |
| Jc2k | just the objects | 20:17 |
| LarstiQ | how would people collide then if not for the naming? | 20:17 |
| 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:18 |
| rexbron | I just noticed that the bzr PPA does not build packages for Jaunty, would this be possible? | 20:19 |
| 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:22 |
| 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:26 |
| === asac_ is now known as asac | ||
| 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:45 | |
| * LarstiQ offers jc2k his 3 kilo laptop in exchange for the mini laptop | 20:46 | |
| * Jc2k has an XPS GEN2 at home, so declines :p | 20:49 | |
| 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:50 |
| jelmer | hmm, looks like the delta resolution can use some more work. It works, it's just not very fast | 20:59 |
| Jc2k | also pushed some protocol doc. its not much atm, but adds a bit more to upstream docs. | 21:01 |
| rexbron | bzr-bd review request: https://code.edge.launchpad.net/~rexbron/bzr-builddeb/trunk.profiles/+merge/2535 | 21:08 |
| === pbor is now known as pbor|out | ||
| === fawek is now known as fawek|away | ||
| 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:13 |
| 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:14 |
| jelmer | rexbron, ah, ok | 21:15 |
| jelmer | rexbron, that makes more sense | 21:15 |
| rexbron | james_w and I discussed this earlier today and came to the conclusion that this is more extendable solution | 21:16 |
| jelmer | Jc2k, hmm, if I send "have" lines the server suddenly hangs up on me | 21:37 |
| Jc2k | jelmer: i havent tested that yet - got distracted by the corrupt packs | 21:41 |
| 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:42 |
| ubottu | 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:42 |
| 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:43 |
| 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:45 |
| Peng_ | jelmer: Ok. Thank you. :) | 21:46 |
| 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:00 |
| 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:01 |
| asabil | jelmer: yeah sure, I will try to push a branch when I get more confident about my checks | 22:02 |
| 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:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| jelmer | Jc2k, ^ | 22:17 |
| * Jc2k merges, commits, pushes | 22:17 | |
| 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:18 |
| 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:19 |
| Jc2k | i think we can factor some of client and server code out into protocol.py ? | 22:21 |
| Jc2k | like the pkt_line stuff and sideband stuff. | 22:22 |
| Jc2k | and possbily capabilities | 22:22 |
| === cprov is now known as cprov-out | ||
| jelmer | Jc2k, yeah, I think that would be useful | 22:48 |
| 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:49 |
| Jc2k | jelmer: going to write some tests that poke the server stuff via protocol.py | 22:51 |
| 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:57 |
| Jc2k | though i wrote some of this on work time so i should probably check.. | 22:58 |
| 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 | 22:59 |
| 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:00 |
| Jc2k | blocking hell it is, i guess :o | 23:01 |
| Jc2k | or i could make my test case yield | 23:01 |
| Jc2k | i dont have enough brain for that tonight.. | 23:02 |
| 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:04 |
| Jc2k | all so messy. | 23:05 |
| Jc2k | i might just wait to see how you test the client :P | 23:06 |
| jelmer | heh, ok | 23:10 |
| jelmer | cycling time, back in ~45 min | 23:10 |
| 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 | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!