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