[00:05] <jelmer> 'evening poolie, Noldorin
[00:06] <Noldorin> hi :-)
[00:06] <Noldorin> how's collocated branch project, i was going to ask?
[00:17] <jelmer> Noldorin: which bit in particular?
[00:18] <Noldorin> jelmer, all bits. lp, bzr, bzr-git :-)
[00:23] <poolie> hi jelmer
[00:23] <poolie> so my half-baked idea was that we should just merge the metadir colo stuff
[00:24] <poolie> putting it in a side branch has never seemed to work well, because people don't in practice test it much either as users or developers
[00:25] <poolie> also, once you ask users to test it at all, they will basically count on it
[00:25] <poolie> it's hard to do more than a smoke test without putting real data in
[00:25] <poolie> i think the most you can expect of that kind of tester is that they be willing to have a rougher ride than they normally did
[00:25] <poolie> which i suppose is kind of what dev formats went towards
[00:27] <jelmer> poolie: I'm a bit wary about using a side branch too, as it just means having to do lots of merge work (and probably bug fixing) later rather than continuously
[00:27] <poolie> that too
[00:27] <jelmer> poolie: John makes a good point about not being able to change it once it's landed though, especially as we're changing an existing format rather than introducing a new one
[00:27] <poolie> also, with the best of intentions, i don't things get the same level of review until they're actually going to come in
[00:28] <poolie> and also eventually landing them as one big bump makes things harder
[00:28] <poolie> that is true
[00:28] <poolie> i wonder if we can do something about saying "it will be stable by 2.5.0"
[00:28] <poolie> (and less stable during the betas)
[00:28] <poolie> generally speaking i don't like to make plans that rely on predictions like that but it's a tool we can use
[00:29] <jelmer> poolie: I think that might be a reasonable compromise
[00:30] <Noldorin> jelmer, hmm....?
[00:30] <Noldorin> poolie isn't hte only one here ;-)
[00:31] <jelmer> poolie: especially as I don't really expect us to make changes to the format, but it's nice if we can crawl back through the trap door if we really have to
[00:31] <jelmer> Noldorin: sorry
[00:31] <jelmer> Noldorin: we're talking about colocated branches though :)
[00:31] <Noldorin> it's ok
[00:31] <Noldorin> oh right
[00:31] <Noldorin> didn't notice
[00:31] <Noldorin> hehe
[00:32] <jelmer> Noldorin: so, the support for importing colocated branches on launchpad hasn't landed yet. No further changes are necessary to bzr-git
[00:32] <Noldorin> ok cool
[00:32] <Noldorin> and 2.5b1 coming soon?
[00:37] <jelmer> Noldorin: yes, the 15th - https://launchpad.net/bzr/+milestone/2.5b1
[00:37] <Noldorin> not soon enough ;-)
[00:37] <Noldorin> but okay
[00:37] <Noldorin> that's good
[00:37] <Noldorin> jelmer, when is LP support coming?/
[00:43] <jelmer> Noldorin: there's an approved branch that adds it, which still needs to land and then be deployed. So, hopefully a couple of days, perhaps more.
[00:43] <Noldorin> jelmer, probably by time of 2.5b1 release though right?
[01:10] <jelmer> Noldorin: probably, but they're unrelated
[01:13] <Noldorin> jelmer, in terms of release, yeah i'd presume so...ok godo to know :0
[06:04] <pippijn> hi
[06:05] <pippijn> how can I show the diff between my own repository and upstream?
[06:05] <bob2> diff or commits?
[06:05] <pippijn> diff
[06:06] <pippijn> I just need a complete patch against upstream
[06:07] <poolie> pippijn: probably 'bzr diff -rsubmit' or 'bzr diff -rancestor:UPSTREAM_URL'
[06:07] <poolie> inserting the right relative path there
[06:08] <pippijn> upstream is lp:inkscape, I think
[06:09] <pippijn> ah, I think it works
[06:11] <pippijn> yep
[06:11] <pippijn> thanks
[06:12] <pippijn> but it has to connect to upstream for this.. isn't this information also in my repo?
[06:25] <vila> hey guys !
[06:27] <lifeless> pippijn: the data is, but the information about what is current isn't.
[06:34] <pippijn> ok
[06:35] <lifeless> pippijn: you can have an explicit local mirror of lp:inkscape if you like
[06:36] <pippijn> it's ok for now
[06:36] <lifeless> it would then be up to you to pull in changes into that mirror, but you could diff when offline
[06:36] <pippijn> I'm not doing many diffs
[06:37] <pippijn> and I'm certainly not doing diffs when offline
[06:37] <pippijn> I'm only doing a diff when updating the patch in our (*puke*) svn repo
[06:40] <lifeless> heh :)
[06:55] <vila> vila_: Wrong machine ;)
[06:57] <vila> Land ! bzr committers, land ! With our new shiny pqm, running 'make check' is down to 23 mins ! \o/
[06:58] <vila> And that's without /tmp mounted as tmpfs AFAICS (S == say ;)
[07:03] <lifeless> vila: do you have --parallel=fork in place ?
[07:03] <vila> lifeless: not even :) But we don't need a losa for that, so I'm waiting for all losas tweakable stuff to be done before looking into it :)
[07:32] <poolie> hi lifeless, vila
[07:32] <vila> poolie: hello !
[07:38] <poolie> hi there
[07:47] <vila> I just did a 'bzr pull' on my bzr trunk and things look alarming !
[07:47] <vila> can anybody running from source try a 'bzr missing' ?
[07:47] <vila> I' afraid something may have gone wrong when switching on pqm maybe ??
[07:48] <poolie> hm
[07:50] <poolie> worked for me
[07:53] <lifeless> vila: alarming in what way?
[07:53] <poolie> what actually goes wrong?
[07:54] <vila> http://paste.ubuntu.com/685803/
[07:54] <vila> Note the 'Removed revisions'
[07:54] <vila> where are they gone ?
[07:55] <poolie>  ah, you should have said
[07:55] <poolie> good question
[07:55] <poolie> that does sound like something like the pqm branch being out of date
[07:56] <vila> ha, ok, they are still there
[07:56] <vila> look at revno 6124
[07:56] <poolie> they're still merged?
[07:57] <poolie> ok, so it was out of date, but jelmer's branch was based on the tip
[07:57] <poolie> that's probably why it didn't fail to push to lp
[07:57] <vila> yup
[07:57] <poolie> well, that's a bit unfortunate but i think not worth doing anything about now
[07:57] <vila> yup
[07:58] <vila> sorry for the false alarm but well, that was unexpected
[07:58] <lifeless> append_revision_only=False :P
[07:59] <vila> my thoughts exactly
[08:00] <poolie> could you get one of the losas to set that on our branches?
[08:00] <poolie> i don't see why not
[08:00] <vila> on the other hand pqm guarantees that under normal circumstances
[08:00] <poolie> obviously there is a bit of horse-has-bolted
[08:02] <vila> poolie: I kind of fear that it would make it harder to recover (we can ask for a push --overwrite if we want to fix such issues today)
[08:02] <poolie> that's true
[08:02] <poolie> so, we could ask them to push over it now and then remerge the later revisions
[08:03] <poolie> that's not really clearly objectively better
[08:03] <poolie> since none of the revisions that got pushed to the side were tagged for a release i think we should just live with it
[08:06] <vila> poolie: oh yes, let's just live with it
[08:07] <poolie> i'm glad you noticed though
[08:07] <poolie> you did have me a bit worried there was some horrible corruption :/
[08:10] <fullermd> I worry about corruption from vila all the time...
[08:10] <vila> fullermd: thanks for recognizing my hard work !
[08:10] <vila> I mean, I put a lot of effort into *not* fixing my tyops and such...
[08:11] <vila> Because it provides such an endless source of tests...
[08:11] <vila> stress tests even :)
[08:11] <fullermd> Oh, totally.  I mean, if you didn't, people might start thinking your were a chatbot!
[08:12] <vila> That's how you recognize aproject with a true TDD mentality: search for the most awkward member and nominate him as RM :-D
[09:09] <poolie> i hope eliz's mail doesn't turn into a futile thread about what's reasonable or not
[09:09] <poolie> there are a lot of things about windows that aren't reasonable
[09:11] <vila> one key point here is that it's hard to setup a windows dev machine
[09:12] <vila> as in: not documented enough or even automated
[09:22] <vila> 573 spurious import failures
[09:22] <vila> requeued
[09:25] <vila> interestingly 8 other ones were qualified as spurious and retried automatically
[09:25] <vila> i.e. the importer can already do that but not all cases are recognized
[09:30] <vila> jelmer (huh, where are you ?), Riddell : investigating http://package-import.ubuntu.com/status/73aaec3da59a46ab68e18ea8c195a6e7.html aka PristineTarError, it looks like pristine-tar can't recognize the bzip2 produced here
[09:32] <Riddell> I can't imagine what would be unusual about KDE's tars
[09:36] <Riddell> although I can recreate it locally
[09:36] <Riddell> "pristine-bz2 failed to reproduce build of kde-l10n-is_4.7.1.orig.tar.bz2"
[09:50] <poolie> o/ riddell
[09:50] <poolie> Riddell, vila, if either of you get a chance could you look into https://bugs.launchpad.net/udd/+bug/820671
[09:51] <vila> Riddell: yup, me neither
[09:54] <vila> Riddell: I digged a bit into pristine-tar itself, and well, once you found the code involved, it's basically try with this executable with this params and if you get a different result, barf
[09:55] <vila> Riddell: so while I can't imagine *what* is different in kde, it's still surprising that *only* kde packages have triggered that so far
[09:55] <Riddell> it works fine with older versions, just this version it doesn't like
[09:55] <vila> Riddell: did they jump on bzip2 wagon ahead of time ?
[09:56] <vila> which version of what ?
[09:56] <vila> Riddell: wag: 32bits/64bits ?
[09:56] <Riddell> pristine-tar from 4.6.90 to 4.7.0 works fine
[09:57] <vila> Riddell: hmm, thanks for the detail
[09:58] <Riddell> vila: I have an upstream asking for more information if he might be of use
[10:00] <vila> Riddell: you mean kde upstream or pristine-tar upstream ?
[10:00] <Riddell> vila: kde upstream
[10:01] <vila> Riddell: ha
[10:01] <poolie> i'm going to sign off soon
[10:01] <vila> my understandin gso far is that it's a pristine-tar bug, but they will indeed need more information
[10:01] <vila> poolie: enjoy your week-end !
[10:01] <poolie> thanks, i hope to
[10:05] <vila> Riddell: may be some change in bzip2 itself...
[10:05] <vila> Riddell: if this is the case, people producing the bz2 should not be able to reproduce the issue with pristine-tar ?
[10:06] <Riddell> that'll be a suse guy, I wonder if I can install pristine-tar on suse and try
[10:09] <vila> may be unrelated but the bz2 I'm looking at has root/root as user/group for all files
[10:10] <vila> nah, irrelevant, that's part of tar which bz2 don't read
[10:15] <Riddell> "<bcooksley> suse 11.4+ use bzip2 1.0.6, debian stable has 1.0.5"
[10:15] <Riddell> pristine-bz2 runs fine on suse with that tar
[10:15] <Riddell> next step would be to try upgrading bzip2 on debian and try it
[10:15]  * Riddell tries
[10:16] <Riddell> "The current version is 1.0.6, released 20 Sept 2010"  hmm, we're slacking
[10:21] <vila> Riddell: I tried running pristine-tar from sources and reproduced the issue...
[10:21] <vila> Riddell: that was yesterday though and maybe I missed some point or used the wrong sources... let me double-check
[10:21] <Riddell> vila: how do you mean pristine-tar from sources?
[10:22] <Riddell> hmm, installing bzip2 1.0.6 doesn't seem to help pristine-tar
[10:22] <Riddell> well that leaves one solution, move the UDD importer to a suse machine
[10:23] <Riddell> :)
[10:24] <vila> Riddell: bah, misread, that's bzip2 that needs to be updated ? But won't that break other tars ?
[10:24] <Riddell> I presume bzip2 is backwards compatible
[10:24] <Riddell> and mostly forwards compatible since these tars can be read by normals tools
[10:25] <Riddell> however it doesn't seem to help
[10:25] <vila> what I mean is that if we use a new bzip2 to recognize old ones, it may fails the way it fails today by using an old bzip2 to recognize new ones
[10:26] <vila> Riddell: that's confusing... do you see what I mean ?
[10:26] <vila> Guest27145: don't try to hide
[10:27] <Guest27145> :)
[10:27] <Riddell> vila: it might but surely it's going to be backwards compatible?
[10:27] <Riddell> I wonder if libbzip2 is to blame rather than bzip2
[10:28] <vila> Riddell: well, in this case, I'm afraid it means: so compatible you can't see a single difference :)
[10:30] <vila> Riddell: but it's up to pristine-tar devs to speak on that matter, I'm not sure I understand all the cases here nor the way to address them
[10:33] <jelmer_> vila, Riddell: have you seen bug 576119
[10:33] <jelmer_> ?
[10:33] <jelmer_> Debian bug 576119
[10:34] <vila> jelmer_: Yeah ! Of course not :)
[10:35] <jelmer_> The changelog entry mentions -t to try harder, which I don't think bzr-builddeb uses yet
[10:35] <jelmer_>        -t  Try harder to determine how to generate deltas of difficult bz2
[10:35] <jelmer_>            files.
[10:35] <jelmer_> worth a shot :)
[10:36] <Riddell> all programmes should have a -t Try harder option
[10:38] <jelmer_> heh
[10:38] <Riddell> "pristine-bz2 will have to try especially hard to reproduce kde-l10n-is_4.7.1.orig.tar.bz2 (This could take a long time.)" I can see it breaking sweat
[10:39] <jam> Riddell: I'm curious what it actually does. It sounds like it randomly samples time-stamps, whatever then bz2's it, then checks to see if the sha hash matches.
[10:39] <jam> Which IMO certainly does fall into the "try especially hard"
[10:39] <jam> having to indirect through *both* bz2 and sha would be terrible
[10:42] <vila> -t takes indeed far longer and... doesn't work here :-/
[10:42] <jelmer_> jam: it looks like it's indeed doing brute-forcing, but of the block size
[10:43] <jam> jelmer_: who uses bz2 that doesn't just use -9?
[10:43] <jam> (the default, and the highest level)
[10:43] <jelmer_> jam: pbzip2, which is used by the KDE folks
[10:44] <jelmer_> (p for parallel)
[11:17] <Riddell> if I install SUSE's bz2 RPM onto my ubuntu system then pristine tar works fine
[11:18] <Riddell> they do have some patches to it
[11:27] <jelmer_> Riddell: interesting
[11:31] <Riddell> this seems to be the offending patch  https://build.opensuse.org/package/view_file?file=bzip2-maxlen20.patch&package=bzip2&project=openSUSE%3AFactory&srcmd5=3ee4cf959e98e3ca50a881d1cdc13570
[11:35] <vila> Riddell: so, in effect, they *reverted* to generate the old (< 1.0.3) .bz2 files
[11:36] <Riddell> I guess so
[11:37] <vila> so if this patch is not there, bzip cannot produce such files and pristine-tar is doomed
[11:37] <vila> bzip2
[11:41] <vila> the weird thing is that it seems that pristine-tar includes zgz just for this purpose (and use 20 there not 17)
[11:43]  * vila lunch time
[11:55] <jelmer_> vila: Do you know how the merge tool code works?
[12:02] <Riddell> vila: shall I report a bug on pristine-tar or is there more we can look into?
[12:15] <vila> Riddell: I think you've found enough evidence for the pristine-tar maintainers to see (especially the url above and the failing .bz2 from the package importer)
[12:16] <vila> jelmer_: superficially yes
[12:16] <vila> . o O (It's a bit surprising that bzip2 website doesn't mention any VCS archive)
[12:18] <vila> Riddell: let me know how it goes, it would be nice to link that bug to a udd one too
[12:21] <jelmer_> vila: I'm pretty sure it's in git
[12:21] <jelmer_> vila: either way, lp:pristine-tar :)
[12:22] <vila> jelmer_: bzip2 :)
[12:22] <jelmer_> ah, sorry
[12:22] <vila> jelmer_: hehe np, I made exactly the same mistake while talking to Riddell :)
[12:23] <mthaddon> jelmer_: did you get an error email from PQM?
[12:24] <jelmer_> mthaddon: I don't think I did - I got a confirmation email to say one of my branches had landed
[12:24] <mthaddon> hmm, maybe it was just that the web UI was stale
[12:24] <mthaddon> ok, thx
[12:25] <mthaddon> vila: I think the web UI was just stale - carry on with your tests pls (one submission to any branch is fine - just want to make sure it goes through with tmpfs in place
[12:25]  * vila prepares
[12:25] <vila> mthaddon: I'll ping you first
[12:26] <jelmer_> I've just submitted another one
[12:27] <vila> jelmer_: against bzr.dev ? I'm preparing for older branches, 2.2 needs to be merged into 2.3 and up
[12:30] <jelmer_> vila: yep
[12:32] <vila> jelmer_: 1 failure (by the way, mthaddon is testing mounting /tmp as tmpfs so watch for related failures)
[12:33] <jelmer_> vila: Yeah, just noticed. Not sure what that's about
[12:33] <vila> mthaddon: I'm ready, waiting for your green light
[12:33] <jelmer_> vila: btw, did I mention I got the number of failures from running bzr.dev tests against bzr-svn down to less than 100 yesterday evening?
[12:33] <mthaddon> vila: go for it
[12:33] <vila> jelmer_: the messages about tags updated is... yummy :)
[12:33] <vila> jelmer_: no you didn't ! \o/
[12:34] <jelmer_> vila: yeah, I noticed. I'll have a look at it later today
[12:34] <vila> jelmer_: I didn't mean the bug I filed, I mean all other cases where it's great to have the feedbaclk ! :)
[12:35] <vila> back
[12:35] <vila> what with non-sense tyops !!1!!
[12:36] <jelmer_> vila: :)
[12:36] <vila> jelmer_: but now that I have a '1 tag(s) updated.' message, I wonder which tag it is :D
[12:36] <jelmer_> vila: yeah, that might be useful to mention too, indeed.
[12:37] <vila> jelmer_: I'll cowardly settle for a mutter() call :)
[12:37] <vila> hmm, looking at .bzr.log is... interesting, I didn't realize there was that much noise there ;)
[12:39] <jelmer_> vila: I think it makes sense to mention the updated tags in the output
[12:39] <jelmer_> I guess the only odd case is if somebody actually updates 200 tags
[12:39] <vila> well, I'd put it under -v with the revisions no ?
[12:41] <vila> and in this case, well, 200 or 1000, you get what you asked for ;)
[12:46] <vila> ha ha, xz incoming on jubany: http://package-import.ubuntu.com/status/pleiades.html#2011-09-09%2003:33:07.686923
[12:47] <vila> jelmer_: what did you sat about xz ?
[12:47] <vila> say
[12:56] <vila> mthaddon: no noticeable difference with tmpfs, that's.. unexpected
[12:57] <vila> mthaddon: you did the change *in* the chroot ?
[12:57] <mthaddon> vila: yep, in the chroot
[13:03] <jelmer_> vila: basically, xz is supported by bzr-builddeb; it happily calls pristine-tar
[13:03] <jelmer_> vila: however, pristine-tar doesn't support xz properly yet, so it will just generate a delta that consists of the entire file
[13:04] <vila> jelmer_: so we need a more recebt bzr-builddeb on jubany ?
[13:06] <jelmer_> vila: well, didn't you update it recently? that version should have included xz support already
[13:06] <jelmer_> however, even when we do have that it will be painful for big packages
[13:07] <vila> jelmer_: I did, revno 607
[13:07] <vila> jelmer_: well, jubany doesn't complain about pain ;) But here it fails
[13:09] <jelmer_> ah, the support is there but it assumes lzma rather than xz
[13:10] <vila> for the suffix ?
[13:12] <vila> jelmer_: nm, I can see the source... but the source suggests it handles .tar.xz fine, and with tests >-//
[13:13] <jelmer_> vila: that's just the upstream tarballs, not the stuff that's in debian
[13:13] <vila> ha ok
[13:16] <vila> mthaddon: my submission against 2.3 succeeded, I noticed the email is <pqm@cupussao> instead of <pqm@pqm.ubuntu.com> though
[13:17] <vila> mthaddon: Patch Queue Manager instead of Canonical.com Patch Queue Manager while I mention nits...
[13:17] <fullermd> Onoes, it's a free agent!
[13:18] <mthaddon> vila: should we remove the tmpfs since it doesn't speed things up?
[13:18] <jelmer_> vila: I'll upload a patch
[13:19] <mthaddon> vila: have fixed (I think) the pqm@cupuasso part
[13:19] <vila> mthaddon: yes, but that's the first time I see tmpfs *not* providing a huge boost
[13:20] <vila> mthaddon: may be I'm confused because it makes a real difference when running with --parallel=fork ...
[13:21] <jelmer_> vila:  lp:~jelmer/bzr-builddeb/tar-xz
[13:23] <vila> jelmer_: what do you want me to do with that ? Review ? Test on jubany ? Deploy on jubany ?
[13:26] <vila> jelmer_: oh, that's *instead of* not *in addition* ?!?!
[13:29] <vila> jelmer_: I'm confused, part of this patch seem to implement 'rather than' while other so 'in addition' >-}
[13:31] <jelmer_> vila: yeah - debian doesn't actually support .tar.lzma
[13:31] <jelmer_> (xz is the second version of lzma)
[13:33] <vila> jelmer_: ha, ok.
[14:00] <Noldorin__> wha'ts the difference between bzr pull and merge?
[14:01] <LeoNerd> pull is for when you are just behind on history, and just adding extra revisions
[14:01] <LeoNerd> merge is for when you have diverged history, in a branch, and need to reconcile changes changes from both sides
[14:21] <henninge> HI! Is there a PPA for bzr builder? I need to install bzr-bulider >=0.5 on lucid.
[14:22] <AuroraBorealis> what is bzr builder?
[14:25] <henninge> https://launchpad.net/bzr-builder
[14:25] <henninge> I don't know exactly, I just need it to satisfy a dependency ...
[14:25] <AuroraBorealis> what error is it giving?
[14:28] <henninge> I am installing a package on lucid that has bzr-builder >= 0.5 as a dependency
[14:28] <henninge> but only 0.2 is packaged
[14:29] <henninge> This not really a bzr question, I guess.
[14:29] <AuroraBorealis> hmm
[14:29] <AuroraBorealis> build it using checkinstall?
[14:30] <henninge> build what?
[14:30] <AuroraBorealis> checkinstall will prodce a deb
[14:30] <AuroraBorealis> i dunno if it will work with that though
[14:31] <henninge> dpkg-buildpackage -b
[14:31] <AuroraBorealis> building debs is like black magic. i have no idea how to do it otther then checkinstall =)
[14:31] <henninge> that's ok ;)
[14:41] <Noldorin> LeoNerd, so in certain cases merge and pull will do the same thing?
[14:42] <Noldorin> i.e. when branches haven't diverged
[14:42] <LeoNerd> Er.. pass. Not sure offhand. If there's no diversion I just pull
[14:42] <Noldorin> heh ok
[14:42] <AuroraBorealis> if the branch hasn't diverged then why are you merging :o
[14:42] <Noldorin> that's not my question
[14:42] <Noldorin> LeoNerd, there's also bzr merge --pull to confuse things more ;-)
[14:43] <Noldorin> hrmm
[14:44] <henninge> Noldorin: merge and pull are different.
[14:44] <Noldorin> how so?
[14:44] <Noldorin> in the case branches haven't diverged
[14:44] <Noldorin> seems identical to me
[14:44] <AuroraBorealis> doesn't pull/push make it a mirror?
[14:45] <henninge> Noldorin: pull will pull in multiple revisions and put them in your branch.
[14:45] <henninge> Nephyrin: merge will merge the revisions which you then need to commit.
[14:45] <henninge> Noldorin: ^
[14:45] <henninge> Noldorin: that creates only *one* revision  on your branch.
[14:45] <Noldorin> henninge, ohh, got it!
[14:46] <henninge> Noldorin: and merge --pull will use pull instead of merge if the branches have not diverged.
[14:47] <Noldorin> henninge, and just normal merge if they have diverged, right?
[14:48] <henninge> right
[14:48] <Noldorin> henninge, and bzr update is like bzr merge, except it replies to the working tree rather than the branch itself?
[14:49] <Noldorin> it applies*
[14:49] <Noldorin> oops
[14:49] <henninge> ah
[14:49] <henninge> It updates your working tree from your branch.
[14:50] <henninge> if you are wokring on a full branch and working tree, merge and pull will do that for you.
[14:50] <Noldorin> henninge, bzr update merges changes from the branch into the working tree, whereas bzr pull merges from another branch into the branch?
[14:50] <fullermd> Wow, that sounds like a wildly confusing way to explain it...
[14:50] <henninge> fullermd: possibly ;)
[14:50] <Noldorin> how would you explain it?
[14:51] <Noldorin> also, merge and pull don't change the working tree afaik...
[14:51] <henninge> also, I am not sure on all aspects of update tbh
[14:51] <fullermd> I dunno, but I'm pretty sure I wouldn't try drawing parallels between merge and update   :)
[14:51] <fullermd> Er.  Both change the working tree...
[14:51] <Noldorin> fullermd, they both do merging of a sorts :-P
[14:52] <fullermd> Well, so does 'pack'   :P
[14:52] <Noldorin> i don't use pack
[14:52] <Noldorin> that's out of the question
[14:53] <Noldorin> fullermd, so if you do a pull, then an update is not necessary after right?
[14:53] <Noldorin> to get to the latest rev.
[14:53] <fullermd> Correct.
[14:54] <Noldorin> fullermd, and bzr update automatically does a pull in 'bound' branches i suppose?
[14:54] <fullermd> Oh, you don't want to get me started there...
[14:55] <Noldorin> hah
[14:55] <Noldorin> is that right though?
[14:55] <Noldorin> more or less
[14:55] <fullermd> Sorta, sometimes.
[14:56] <Noldorin> hah
[14:56] <Noldorin> well bound branches make it like centralised VCS afaik
[14:56] <fullermd> And then sometimes it does a sort of horrific pivot double-merge and completely ruins your life.
[14:56] <Noldorin> that's how i think of them
[14:56] <Noldorin> fullermd, hah i think i'll ignore that for now :-)
[15:00] <Noldorin> thanks for clearing it up anyway
[15:42] <jelmer_> vila: still there ?
[15:42] <vila> jelmer_: yup
[15:43] <vila> jelmer_: I've tried setting up a bot to do reviews but once debugged he said: nah, I don't want to do that
[15:43] <jelmer_> vila: I think we should be good to update to the latest version of bzr-builddeb
[15:43] <jelmer_> the worst thing that can happen is that xz tarballs still don't work
[15:44] <vila> jelmer_: ok, my concerns were about things like 'Cope with move of features in bzr 2.5' and other 'compat with bzr-svn' stuff
[15:44] <jelmer_> vila: those should both be backwards compatible
[15:45] <vila> thanks for confirming
[15:45] <vila> jelmer_: also, if I can deploy from bzr-builddeb trunk, I know I don't leave a weird setup someone else will be confused by
[15:46] <vila> (carrying an uncommitted change to disable the merge hook is bad enough)
[15:46] <vila> jelmer.... come back !
[15:47] <jelmer> vila: sorry
[15:47] <vila> ha, good :)
[15:47] <jelmer> vila: what I was trying to say before the kernel on my other machine oopsed..
[15:47] <jelmer> vila: those two changes should only affect the test suite of bzr-builddeb anyway
[15:47] <vila> hehe, oops, sorry not funny :-/
[15:47] <vila> ok,
[15:47] <vila> did you get:
[15:48] <vila> jelmer_: also, if I can deploy from bzr-builddeb trunk, I know I don't leave a weird setup someone else will be confused by
[15:48] <vila> (carrying an uncommitted change to disable the merge hook is bad enough)
[15:48] <jelmer> I'm still not sure why that change is necessary
[15:48] <jelmer> where do we actually merge?
[15:48] <vila> jelmer: we need a newer dpkg-dev
[15:49] <jelmer> vila: yeah, but why is that relevant if that merge hook never gets called
[15:49] <jelmer> (also, could we perhaps automatically disable the merge hook in bzr-builddeb if a new enough dpkg-dev is not available)
[15:49] <vila> it got called
[15:50] <vila> that will work yeah
[15:52] <vila> jelmer: rt #47638 by the way
[16:01] <jelmer> vila: thanks
[16:01] <vila> jelmer: ?? what for ?
[16:02] <jelmer> vila, for that rt
[16:02] <vila> jelmer: it's a week old :-/
[16:02] <jelmer> vila: for mentioning the RT # :)
[16:02] <jelmer> ... the music
[16:02] <jelmer> .. the joy it's bringing
[16:02] <vila> oh :)
[16:02] <vila> really ? Funny you mention that while a police car was under my windows :)
[16:03] <vila> That's not me ! Help.asdffglkjjk6yq43t
[16:03] <jelmer> hehe :)
[16:03] <fullermd> Why did you throw a police car out your window?
[16:05] <vila> because I'm not done yet
[16:05] <vila> told them to come back later
[23:12] <Noldorin> hey jel
[23:12] <Noldorin> jelmer
[23:16] <Noldorin> i have a branch which i uncommit up to a certain revision, and then run bzr revert...it tells me the working tree is out of date thereafter -- why?