[00:00] helloooo spiv [00:05] Hey, go enjoy your weekend while you still have it :P [00:05] Morning poolie [00:09] hi there spiv [00:17] * jelmer waves from DebConf [00:17] hi jelmer [00:17] have fun [01:32] heya jelmer [01:42] spiv, so you're going to be pilot this week? === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv [01:43] Apparently so! :) [01:47] it's negotiable :) [01:55] jelmer: in bug 811460 you link me to bug 811460. is 811460 a 'please allow import-dsc to only bring in debian/' , or would that be a separate issue? [01:55] Launchpad bug 811460 in bzr-builddeb "please allow multiple debian/ dirs in one repo" [Undecided,New] https://launchpad.net/bugs/811460 [01:55] oh, i pated it three times [01:55] bug 331986 is what the send and third references were meant to be [01:56] Launchpad bug 331986 in bzr-builddeb "import-dsc doesn't work for merged build" [Medium,Triaged] https://launchpad.net/bugs/331986 [03:02] Hi, I've just proposed a merge (https://code.launchpad.net/~thomir/bzr/fig-bug-747958/+merge/69023) to fix bug #747958. I'd welcome any feedback. [03:02] Ubuntu bug 69023 in ppscsi (Ubuntu) "ppscsi won't build with module-assistant under kernel 2.6.17-10-generic (or newer)" [Undecided,Confirmed] [03:02] Launchpad bug 747958 in Bazaar "values given to make_log_request_dict are overridden" [Medium,Confirmed] https://launchpad.net/bugs/747958 [03:11] thanks for the patch thomi, i'll have a look after lunch, or spiv will [03:40] can bzr compress its repo? or parts of its repo? i've not found anything obvious in the commands list [03:52] kgoetz: it's already compressed (and it automatically repacks it gradually from time-to-time to keep it well compressed) [03:53] kgoetz: but you can use 'bzr pack' to trigger that manually, although it's unusual to do so. [03:57] spiv: ok. i'll just put up with it then. [04:47] kgoetz: 'put up with'...? [04:50] poolie: 870kb of .bzr when i have 8kb of text 'top level' (it tar cjf's down to 250k, so i thought some of the old history might be properly compressable. other then historical interest itsnot useful for reference anymore) [05:07] kgoetz: you can see if there are files in obsolete_packs [05:07] they can safely be deleted [05:07] bzr will delete them itself later [05:39] jelmer: given you're patching lp, you might like to idle in #launchpad-dev [05:39] jelmer: we're talking sprdata atm :> [06:08] spiv i might send my einval patch to 2.4 [06:26] oh, poolies gone [06:26] well, thanks for the tip :) [06:26] half the repo size is obsolete_packs [06:27] it'll get cleared up shortly-ish [06:27] if bzr handles it i'll leve them alone. thanks [06:27] every 10 commits at most [06:29] hm, i thought it only stuck around at all to avoid races [06:29] bob2: sure, but we don't check obsolete_packs on every write to the repo, just on every repacking of it. [06:30] spiv: why not? Once the repack is done, why further waste the disk space? [06:30] AfC: many popular OSes lie about persistence, and / or have no cheap way to record that something matters without triggering immediate IO [06:31] spiv: ahhh, right [06:31] bob2: checking on every write would itself be a race condition :> [06:32] i've seen the $magic happen every 10 commits. i'm on 172 atm, so i'll see what happens in 8 commits (: [06:32] kgoetz: is this a project with many (k's) or large (10's of MB's or more) files ? [06:35] lifeless: no, nothing like it. its my cv. formerly (until 3 commits ago) stored in xml (+~20 supporting files), now in rst [06:35] lifeless: so two files, one 8kb one 1kb [06:35] got to dash, catch you later [06:35] and thanks for the help :) [06:36] kgoetz: so thats why 50% space is in the obsolete packs [06:37] kgoetz: because your data is small, and the individual commits don't contain compressed data - its only as they repack that compression happens. [06:37] kgoetz: obsolete_packs isn't transmitted on push/pull. [06:45] Is it possible to just commit a portion of the changes of a modified working branch to the checkout branch? e.g. just the contents of one subdirectory, as opposed to them all that have changed. [06:45] lifeless: can I ask a favour? I have an approved branch for bzr-builddeb, but it turns out I'm not in the (moderated) team that can commit to it and you are. Would you mind pushing lp:~spiv/bzr-builddeb/trunk-merge-of-use-dpkg-mergechangelogs to trunk? [06:46] lifeless: normally I'd just join the team, but I'm fairly sure this is the last change I'll be making to that code :) [06:46] KombuchaKip: sure, just 'commit SUBDIR' [06:46] poolie: Roger. Thanks. [06:46] poolie: What about if I've unbound and I rebind to the upstream? Still ok to do that? [06:47] hm [06:47] commit makes a new revision on whatever branch the tree addresses at the time you run it [06:47] what's the concern? [06:48] poolie: If I've made many commits to my unbound local branch, when I rebind and commit to upstream, will the upstreams revision number be incremented just by one, or by N, N being the number of local commits I've made since unbinding? [06:49] you will make one new upstream commit (which will be numbered N+1) which will be a merge of all your local commits [06:49] it doesn't matter what's in the comimts [06:54] poolie: /wave [06:55] hi jam [06:55] I'm feeling a bit ill today, so I'm probably going to be a bit in-and-out. [06:55] But I figured I could say hi, at least. [06:55] i'm finishing the fdatasync branch === jam1 is now known as jam [06:55] sorry to hear that; it's nice to see you [06:56] hm if this is always on, it's probably going to slow down the test suite on magnetic disks [06:56] anyway, off to take the kid to school, I'll see you in a bit [06:56] poolie: Thanks. [07:21] spiv: am really EODish now, but will dig around for a branch etc tomorrow if jelmer doesn't do it. [07:21] lifeless: thanks! [07:43] * jelmer waves [07:44] poolie: thanks for the feedback - I've made the changes and re-pushed. [07:44] thanks thomi [07:44] no worries. It'll be good to get that fixed... means I can clean up some work-around code in sloecode :) [07:48] cool [07:49] thomi: thanks for returning to that bug! [07:49] what was the selftest error you got? [07:49] you can file a bug or question for that [07:49] it's supposed to be clean, or at least to give a clean message if you're missing something we need [07:49] spiv: it snowed, so I couldn't go to work. I was bored ;) [07:52] thomi: I hope it snows more often then ;) [07:53] I'm browsing the bzr bug list right now. Can't find any more easy looking ones though ;) [07:53] Although I regularly run into #82555 [07:58] thomi there are some bugs tagged easy [07:58] bug 82555 [07:58] Launchpad bug 82555 in Bazaar "Merging to an empty branch doesn't work" [High,Confirmed] https://launchpad.net/bugs/82555 [07:59] spiv: while you're looking at bzr-builddeb, can you perhaps review https://code.launchpad.net/~jelmer/bzr-builddeb/contains-upstream-source/+merge/69017? It's a one line change (and some tests) [08:02] jelmer: done! [08:02] thanks :) [08:06] thomi: i have an easy fun useful bug which is to add a system-wide configuration file [08:06] you just need to arrange for it to be opened and then to go into the Stack objects in config.py [08:08] hola chicos [08:08] och aye [08:09] salut [08:10] jelmer: if you could land my bzr-builddeb change that'd be great (should just be a simple push, see mp comments) [08:10] * spiv is done for the day. [08:15] spiv: will do [08:27] dch keeps adding username@hostname instead of using my email address. Where do I configure that? [08:27] EMAIL or DEBEMAIL should do it? [08:27] no configuration file? [08:28] no [08:35] morning all! [08:39] hi mgz [08:39] i'm just reading your test patch [08:39] it sounds good [08:40] hey poolie [09:20] mgz i might have another go at https://code.launchpad.net/~mbp/bzr/test-errors/+merge/64485 [09:20] thanks for narrowing it down [09:27] * fullermd slaps qdiff for not having any exit function. [09:37] jelmer: you had told me lp:gcc has about 2K tags... More like 200K it seems :-) http://launchpadlibrarian.net/73597623/vcs-imports-gcc-trunk.log === idnaria is now known as idnar [09:50] jimis: the numbers there are a progress indicator [09:50] jimis: it's the number of revisions [10:00] jelmer: I see, it was too much to be real :-) [10:04] lifeless: thanks for rthe info above [10:23] Gah. The new package branch up-to-dateness checking throws an exception in foreign branches [10:27] maxb: that shouldbe fixed in the foreign branch plugins [10:29] Seems like a workaround in the new code would be the friendly thing to do, to avoid making compatibility more bumpy than it needs to be [10:30] well, arguably this was a big in the foreign branch plugins [10:31] *bug [10:42] can I permanently set (with some config file) the option --diff-options=-p? [10:50] jimis: you can set an alias for diff that sets that option [10:50] see 'bzr help alias' [10:50] jimis: bzr alias diff="diff --diff-options=-p" [10:58] thanks [11:07] Is there a way to apply a specific commit from another branch? [11:08] jimis: bzr merge -c REVNUM BRANCH [11:10] jelmer: thanks, I was using merge -r and I got all changes until that revision :-) [11:12] "bzr help merge" is not clear about the difference === bigjools is now known as bigjools-afk === bigjools-afk is now known as bigjools === med_out is now known as medberry [14:31] Is there any estimated timeframe for getting OS X (py2.7) installers up? === joey` is now known as joey [15:51] afternoon. [16:16] hi mgz === deryck is now known as deryck[lunch] === medberry is now known as med_out [17:34] what is the difference between bzr pull and bzr merge [17:42] pull is for updating when you are strictly-behind in progress [17:43] merge is for re-combining two divergent trees of history. === deryck[lunch] is now known as deryck [17:59] Hi [18:00] What representations of the file contents exist in bzr at run-time? Is it only passed around as plain strings in-memory, or is there some stream-based abstraction somewhere? [18:05] they tend to be passed around as chunks, but still tend to be held in entirety in memory [18:05] Hm [18:05] there are a bunch of different problems on the really-big-files angle [18:06] Yeah, I start to understand what's going on. [18:07] I assume having a real "chunk" class which can convert to string if required but tries not to would require an extensive rewrite? [18:09] perhaps not, part of the issue with the content filtering line you're trying is that they've just not been widely used yet, [18:09] so there are probably a whole bunch of little issues that need ironing out with the core bzr code [18:10] big files generally don't work well because there's no benefit using any of the VCS techniques on them [18:10] Hm. I'll be trying to get a prototype working which side-steps the issue and handles large-files manually (using a stream approach) but it would be much easier if the content filter wouldn't get the complete file contents as input. [18:11] Yeah, I see your point, that's why I thought that a thin wrapper which behaves like a string but optionally allows you to query the size would be the easiest/fastest-to-add solution. [18:11] In 99% of the cases, you would just pass it around but if needed, you could try to use the stream interface (diff, content filters.) [18:12] For instance, I'm using a checkout with Bzr to store large binary files. [18:12] yeah, and you (and others on the mailing list) are right that there are benefits from being able to keep your not-usefully-versioned files in the repo along with the rest of the stuff [18:13] I wonder if you could get your code working against the current chunks interface, then see what changes would be needed to work against an iterable rather than a list [18:13] Ok [18:13] The problem with the chunks interface is that I'll be storing only a hash in the file so I can keep the binary blobs completely off the repository. [18:14] This is going to be a glorified hack which creates the bin files on update and uses a pre-commit hook to check/update the hash file. [18:14] 'evening Anteru, mgz [18:14] Evening jelmer [18:15] * mgz waves at jelmer [18:19] Anyone here who developed a plugin on Windows? [18:20] Anteru: it shouldn't be all that different than on linux [18:20] I'm wondering how to debug it; tried to print from the plugin but either it doesn't get called or the print goes elsewhere. [18:20] And I can't get PyDev/Eclipse to run bzr commands ... should I get bzr source + a python 2.6 interpreter? [18:23] trace.mutteras you noted in your list post plus tail on .bzr.log should work [18:23] Thanks [18:50] I think "bzr duff" should return ascii art of Duff beer [18:51] you could write a plugin for that :P [18:52] * timrc is tempted [18:53] timrc: I think it should punish you as well, by making you wait - like sl [18:57] jelmer, lol.. the sad truth is, sometimes I find myself intentionally typing 'sl' === med_out is now known as medberry === yofel_ is now known as yofel [22:22] hi all [22:46] any way to remove a tag from a local commit? [22:47] ah, I found it [22:58] hey poolie [22:59] hi jelmer