[00:00] <jelmer> helloooo spiv
[00:05] <spiv> Hey, go enjoy your weekend while you still have it :P
[00:05] <spiv> Morning poolie
[00:09] <poolie> hi there spiv
[00:17]  * jelmer waves from DebConf
[00:17] <poolie> hi jelmer
[00:17] <poolie> have fun
[01:32] <spm> heya jelmer
[01:42] <poolie> spiv, so you're going to be pilot this week?
[01:43] <spiv> Apparently so! :)
[01:47] <poolie> it's negotiable :)
[01:55] <kgoetz> 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] <kgoetz> oh, i pated it three times
[01:55] <kgoetz> bug 331986  is what the send and third references were meant to be
[03:02] <thomi> 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:11] <poolie> thanks for the patch thomi, i'll have a look after lunch, or spiv will
[03:40] <kgoetz> can bzr compress its repo? or parts of its repo? i've not found anything obvious in the commands list
[03:52] <spiv> kgoetz: it's already compressed (and it automatically repacks it gradually from time-to-time to keep it well compressed)
[03:53] <spiv> kgoetz: but you can use 'bzr pack' to trigger that manually, although it's unusual to do so.
[03:57] <kgoetz> spiv: ok. i'll just put up with it then.
[04:47] <poolie> kgoetz: 'put up with'...?
[04:50] <kgoetz> 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] <poolie> kgoetz: you can see if there are files in obsolete_packs
[05:07] <poolie> they can safely be deleted
[05:07] <poolie> bzr will delete them itself later
[05:39] <lifeless> jelmer: given you're patching lp, you might like to idle in #launchpad-dev
[05:39] <lifeless> jelmer: we're talking sprdata atm :>
[06:08] <poolie> spiv i might send my einval patch to 2.4
[06:26] <kgoetz> oh, poolies gone
[06:26] <kgoetz> well, thanks for the tip :)
[06:26] <kgoetz> half the repo size is obsolete_packs
[06:27] <bob2> it'll get cleared up shortly-ish
[06:27] <kgoetz> if bzr handles it i'll leve them alone. thanks
[06:27] <lifeless> every 10 commits at most
[06:29] <bob2> hm, i thought it only stuck around at all to avoid races
[06:29] <spiv> bob2: sure, but we don't check obsolete_packs on every write to the repo, just on every repacking of it.
[06:30] <AfC> spiv: why not? Once the repack is done, why further waste the disk space?
[06:30] <lifeless> AfC: many popular OSes lie about persistence, and / or have no cheap way to record that something matters without triggering immediate IO
[06:31] <bob2> spiv: ahhh, right
[06:31] <lifeless> bob2: checking on every write would itself be a race condition :>
[06:32] <kgoetz> 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] <lifeless> kgoetz: is this a project with many (k's) or large (10's of MB's or more) files ?
[06:35] <kgoetz> lifeless: no, nothing like it. its my cv. formerly (until 3 commits ago) stored in xml (+~20 supporting files), now in rst
[06:35] <kgoetz> lifeless: so two files, one 8kb one 1kb
[06:35] <kgoetz> got to dash, catch you later
[06:35] <kgoetz> and thanks for the help :)
[06:36] <lifeless> kgoetz: so thats why 50% space is in the obsolete packs
[06:37] <lifeless> 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] <lifeless> kgoetz: obsolete_packs isn't transmitted on push/pull.
[06:45] <KombuchaKip> 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] <spiv> 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] <spiv> 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] <poolie> KombuchaKip: sure, just 'commit SUBDIR'
[06:46] <KombuchaKip> poolie: Roger. Thanks.
[06:46] <KombuchaKip> poolie: What about if I've unbound and I rebind to the upstream? Still ok to do that?
[06:47] <poolie> hm
[06:47] <poolie> commit makes a new revision on whatever branch the tree addresses at the time you run it
[06:47] <poolie> what's the concern?
[06:48] <KombuchaKip> 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] <poolie> 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] <poolie> it doesn't matter what's in the comimts
[06:54] <jam1> poolie: /wave
[06:55] <poolie> hi jam
[06:55] <jam1> I'm feeling a bit ill today, so I'm probably going to be a bit in-and-out.
[06:55] <jam1> But I figured I could say hi, at least.
[06:55] <poolie> i'm finishing the fdatasync branch
[06:55] <poolie> sorry to hear that; it's nice to see you
[06:56] <poolie> hm if this is always on, it's probably going to slow down the test suite on magnetic disks
[06:56] <jam> anyway, off to take the kid to school, I'll see you in a bit
[06:56] <KombuchaKip> poolie: Thanks.
[07:21] <lifeless> spiv: am really EODish now, but will dig around for a branch etc tomorrow if jelmer doesn't do it.
[07:21] <spiv> lifeless: thanks!
[07:43]  * jelmer waves
[07:44] <thomi> poolie: thanks for the feedback - I've made the changes and re-pushed.
[07:44] <poolie> thanks thomi
[07:44] <thomi> no worries. It'll be good to get that fixed... means I can clean up some work-around code in sloecode :)
[07:48] <poolie> cool
[07:49] <spiv> thomi: thanks for returning to that bug!
[07:49] <poolie> what was the selftest error you got?
[07:49] <poolie> you can file a bug or question for that
[07:49] <poolie> it's supposed to be clean, or at least to give a clean message if you're missing something we need
[07:49] <thomi> spiv: it snowed, so I couldn't go to work. I was bored ;)
[07:52] <spiv> thomi: I hope it snows more often then ;)
[07:53] <thomi> I'm browsing the bzr bug list right now. Can't find any more easy looking ones though ;)
[07:53] <thomi> Although I regularly run into #82555
[07:58] <poolie> thomi there are some bugs tagged easy
[07:58] <poolie> bug 82555
[07:59] <jelmer> 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] <spiv> jelmer: done!
[08:02] <jelmer> thanks :)
[08:06] <poolie> thomi: i have an easy fun useful bug which is to add a system-wide configuration file
[08:06] <poolie> you just need to arrange for it to be opened and then to go into the Stack objects in config.py
[08:08] <Riddell> hola chicos
[08:08] <poolie> och aye
[08:09] <spiv> salut
[08:10] <spiv> 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] <jelmer> spiv: will do
[08:27] <jo-erlend> dch keeps adding username@hostname instead of using my email address. Where do I configure that?
[08:27] <poolie> EMAIL or DEBEMAIL should do it?
[08:27] <jo-erlend> no configuration file?
[08:28] <Riddell> no
[08:35] <mgz> morning all!
[08:39] <poolie> hi mgz
[08:39] <poolie> i'm just reading your test patch
[08:39] <poolie> it sounds good
[08:40] <mgz> hey poolie
[09:20] <poolie> mgz i might have another go at https://code.launchpad.net/~mbp/bzr/test-errors/+merge/64485
[09:20] <poolie> thanks for narrowing it down
[09:27]  * fullermd slaps qdiff for not having any exit function.
[09:37] <jimis> 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
[09:50] <jelmer> jimis: the numbers there are a progress indicator
[09:50] <jelmer> jimis: it's the number of revisions
[10:00] <jimis> jelmer: I see, it was too much to be real :-)
[10:04] <kgoetz> lifeless: thanks for rthe info above
[10:23] <maxb> Gah. The new package branch up-to-dateness checking throws an exception in foreign branches
[10:27] <jelmer> maxb: that shouldbe fixed in the foreign branch plugins
[10:29] <maxb> 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] <jelmer> well, arguably this was a big in the foreign branch plugins
[10:31] <jelmer> *bug
[10:42] <jimis> can I permanently set (with some config file) the option --diff-options=-p?
[10:50] <jelmer> jimis: you can set an alias for diff that sets that option
[10:50] <jelmer> see 'bzr help alias'
[10:50] <jam> jimis: bzr alias diff="diff --diff-options=-p"
[10:58] <jimis> thanks
[11:07] <jimis> Is there a way to apply a specific commit from another branch?
[11:08] <jelmer> jimis: bzr merge -c REVNUM BRANCH
[11:10] <jimis> jelmer: thanks, I was using merge -r and I got all changes until that revision :-)
[11:12] <jimis> "bzr help merge" is not clear about the difference
[14:31] <notmyname> Is there any estimated timeframe for getting OS X (py2.7) installers up?
[15:51] <mgz> afternoon.
[16:16] <jelmer> hi mgz
[17:34] <lxsameer> what is the difference between bzr pull and bzr merge
[17:42] <LeoNerd> pull is for updating when you are strictly-behind in progress
[17:43] <LeoNerd> merge is for re-combining two divergent trees of history.
[17:59] <Anteru> Hi
[18:00] <Anteru> 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] <mgz> they tend to be passed around as chunks, but still tend to be held in entirety in memory
[18:05] <Anteru> Hm
[18:05] <mgz> there are a bunch of different problems on the really-big-files angle
[18:06] <Anteru> Yeah, I start to understand what's going on.
[18:07] <Anteru> 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] <mgz> 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] <mgz> so there are probably a whole bunch of little issues that need ironing out with the core bzr code
[18:10] <mgz> big files generally don't work well because there's no benefit using any of the VCS techniques on them
[18:10] <Anteru> 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] <Anteru> 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] <Anteru> 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] <Anteru> For instance, I'm using a checkout with Bzr to store large binary files.
[18:12] <mgz> 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] <mgz> 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] <Anteru> Ok
[18:13] <Anteru> 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] <Anteru> 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] <jelmer> 'evening Anteru, mgz
[18:14] <Anteru> Evening jelmer
[18:15]  * mgz waves at jelmer
[18:19] <Anteru> Anyone here who developed a plugin on Windows?
[18:20] <jelmer> Anteru: it shouldn't be all that different than on linux
[18:20] <Anteru> 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] <Anteru> And I can't get PyDev/Eclipse to run bzr commands ... should I get bzr source + a python 2.6 interpreter?
[18:23] <mgz> trace.mutteras you noted in your list post plus tail on .bzr.log should work
[18:23] <Anteru> Thanks
[18:50] <timrc> I think "bzr duff" should return ascii art of Duff beer
[18:51] <mgz> you could write a plugin for that :P
[18:52]  * timrc is tempted
[18:53] <jelmer> timrc: I think it should punish you as well, by making you wait - like sl
[18:57] <timrc> jelmer, lol.. the sad truth is, sometimes I find myself intentionally typing 'sl'
[22:22] <poolie> hi all
[22:46] <teratorn> any way to remove a tag from a local commit?
[22:47] <teratorn> ah, I found it
[22:58] <jelmer> hey poolie
[22:59] <poolie> hi jelmer