[00:19] fullermd, is it broken or just not loading? [00:23] bzr: ERROR: exceptions.AttributeError: 'GlobalConfig' object has no attribute '_get_filename' [00:29] looks like r5395, which appears to try and keep compat, wonder why it broke. [00:30] ask vila tomorrow fullermd. [00:30] Oh, cool. I'll tell him you made me pounce him first thing ;) [00:34] good evening... === dOxxx1 is now known as dOxxx [00:35] jelmer: Are r302-305 of bzr-fastimport compatible with bzr 2.3.0? I'm currently building r301 with the mac installers. Can I update it to r305? [00:35] hi d0 [00:35] dOxxx, [00:35] hey poolie [00:36] poolie: do you know the state of bzr-fastimport compatibility with bzr 2.3? [00:36] there hasn't been a release since 2009 :P [00:37] i don't know [00:37] it was somewhat of ian's own project, though it is obviously useful to have generally [00:37] jelmer expressed an interest in looking after it [00:37] I see [00:39] lifeless, what is 'pipefile in makefile' [00:40] pipefail sorry [00:40] ah [00:40] *if* you make bzr selftest --subunit exit with nonzero [00:40] then you'l *also* need to set pipefail [00:40] otherwise the exit code will be ignored and swallowed by the pipeline [00:40] if we make it exit nonzero, we should no longer need a pipeline afaics [00:41] or do we? [00:41] thats an option too [00:41] depends on whether you want a human summary or not [00:41] pqm can interpret subunit for you these days [00:41] [which is another thing you might want to do in tarmac) [00:43] so... [00:43] does pqm do anything with the selftest.log file, or is that just there so we can run subunit-stats on it? [00:43] or another way to ask is, what is the interface expected by pqm? [00:43] just that you'll emit subunit to stdout? [01:01] pqm looks at stdout [01:01] and at the overall exit status [01:10] Urgh, transition from python-central to python-support in 2.3.0-1 packaging. That'll be fun. I'll need to do something special for hardy IIRC [01:11] dOxxx: bzr-fastimport 305 is in sid. I think you may safely assume that that means it's compatible with 2.3.0 [01:12] but yes, a release would be nice :-) [01:12] FWIW my list of things that appear to need releases based on the ppas is: [01:13] bzr-fastimport bzr-gtk bzr-loom bzr-rewrite bzr-svn python-fastimport qbzr [01:49] james_w: https://bugs.launchpad.net/udd/+bug/653307 just gets more and more confusing and alarming [01:49] erk [01:50] any idea how that could happen? [01:58] james_w: in general, yes, but as I said in comment #7 I don't see any suspicious code at all [01:59] hmm [01:59] james_w: the way it generates commits seems completely typical and kosher [01:59] spiv, you re-imported that package from nothing? [02:00] I haven't, but I thought all the affected packages had all their branches deleted? [02:00] Or rather, I did reimport locally, and with no trouble [02:00] Although it's almost impossible to imagine seeing this problem during a signel, intial import run. [02:01] Because that all happens in a single, shared inventory. [02:01] s/inventory/repository/ [02:01] yeah, we deleted all the branches, but didn't re-import with the newer bzr [02:01] so I wonder if it's still a fixed bug? [02:02] * spiv rereviews the fixed bugs in 2.1 vs now [02:02] (because it's not the non-canonical one that had seemed likely, although I'm very glad we aren't using that version of bzr anymore!) === Ursinha is now known as Ursinha-gone [02:09] james_w: is there an easy way to do a local test run of just importing squeezy and then a second run to import sid? [02:10] spiv, I don't think so [02:10] * spiv hmms [02:12] james_w: I'm still puzzled by the Feb 2010 timestamps on the files in the supposedly-deleted-then-recreated branches, too. [02:13] spiv, why's that? [02:13] james_w: well I'd expect Jan 2011, as that's when the new branches were pushed to LP? [02:14] spiv, true [02:14] spiv, are you talking about working tree files after a checkout, or the branch/repo files on LP? [02:14] Repo files, e.g. look at http://bazaar.launchpad.net/~ubuntu-branches/debian/squeeze/dsdo/squeeze/.bzr/repository/packs/ [02:16] hmm [02:16] 2010, you're right, that doesn't make a lot of sense [02:16] Compre e.g. http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/packs/ in case you're wondering if it's something weird in the webserver :) [02:18] So if for some reason the old branches weren't deleted we're *still* at the point where we haven't ruled out "ancient bzr/udd/builddeb/launchpad bug, fresh import will fix" [02:18] But I'm not sure how thaey can't be deleted, because I'm preetty sure I was watching it happen :) [02:19] yeah [02:20] unless deleting via the webservice doesn't nuke things like we assumed [02:20] but that seems very unlikely given that branches on disk are based on db ids [02:21] maybe we need to try delete + reimport again [02:21] 00/00/c9/3e is quite an old id too fwiw [02:21] new branches are up in the 00/01/xx/xx space [02:22] so old branch seems to be the most likely candidate right now [02:22] mwhudson: higher, apparently: 00/06/0f/2a is the natty branch of dsdo [02:22] spiv: oh ok [02:22] my point still stands :) [02:23] (time to start planning for expanding that ID column? :) [02:24] maxb: thanks :) [02:25] spiv: nah, you guys just have to implement colocated branches soon! [02:25] * mwhudson afk for a bit [02:27] hmm. bzr-gtk build failure in natty [02:28] * maxb creates a cowbuilder chroot [02:51] "Xvfb failed to start" [02:51] This is NOT a useful error message :-( [02:52] (bzr-gtk/jaunty) [02:52] nope :) [02:52] Just for complete bizarreness, it works fine on hardy and karmic [03:05] hm, i was just surprised by some debcommit behavior, which i suppose is an issue there, not bzr. but maybe someone can enlighten me anyway... [03:05] make a bunch of changes to files, but only 'bzr add foo bar' [03:05] dch -a ; debcommit [03:06] i would have expected a new commit with just a, b, and debian/changelog [03:06] instead, i got everything. :-/ [03:08] um, you are familiar with git i guess? [03:08] i suppose this expectation comes from the fact that i'm used to git's index. :( [03:08] bzr ci commits all changes by default [03:08] there is nothing like the index [03:08] yes, it is my fault [03:08] it does what everyone else in the world expects :P [03:08] bzr ci is like git commit -a i think? [03:08] mwhudson: yes [03:08] no [03:08] yeah [03:08] it does'nt add new files [03:08] no? [03:08] oh right [03:08] ah [03:09] all versioned files are recorded, unknown files remain unknown. [03:09] gone files become unversioned and are deleted in the commit [03:09] lifeless: i mean, sure, i'm not here to start a holy war. but a large portion of "everyone else" uses git. :-/ [03:10] but of course, the fault is mine in this case for having wrong expectations. [03:10] re-reading the debcommit man page, i see that i should just call it with the files i want to commit next time [03:14] ok, now this question *is* related to bzr -- i just did a bzr uncommit to recover from the bad debcommit [03:15] it actually puts my tree back in the state before i did the debcommit, with uncommitted changes in the tree [03:15] thats right [03:15] that is actually quite nice, but i am confused why it behaved that way? my reading of the uncommit man page makes me think that the -r -1 commit should just completely go away [03:15] it undoes the commit [03:15] as if it'd never happened at all [03:15] the act of committing doesn't change the files you have on disk. [03:16] so neither does the act of uncommitting. [03:16] interesting [03:16] it also makes sense, the way you describe what commit/uncommit does [03:17] lifeless: thanks for the help, i appreciate it [03:17] anytime [03:18] (et al) [03:34] whoops: http://package-import.ubuntu.com/status/libdbusmenu.html [03:37] james_w: where "whoops" == "upgrade to bzr 2.3 broke stuff"? [03:38] I assume so [03:38] I only asked for an upgrade to 2.1.3, FWIW :) [03:38] heh :-) [03:39] I don't see it in the release notes [05:38] hi all [05:54] spiv, are you around? [05:55] is https://code.launchpad.net/~spiv/bzr/fetch-all-tags-309682/+merge/42910 ready for re-review, or still WIP? [05:59] poolie: I am, sort of [05:59] poolie: power is still out, but jsut for my flat [05:59] huh [05:59] poolie: so currently chasing that up! [05:59] good luck [05:59] i was just going to quickly see if there was anything i should review [05:59] but, perhaps i should instead do the whoami bug [06:00] poolie: Off the top of my head all my patches are ready for rereview [06:01] (It's a shame that's not a cleear yes/no at a glance, I wonder if I should do something differently) [06:02] maybe you should resubmit when you get all the existing stuff done? [06:02] that's not just you; i think just generally it's not clear when it wants more review [06:06] *nod* [06:26] * spiv has just run extension cables from the stairwell to the kitchen so the fridge can have power [07:00] . o O (spiv: Safety first: make sure the beers stay cold, errrr the milk ! I meant the milk !) [07:00] hi all ! [07:01] fullermd: Oh dear, so sorry, I meant to look at that and... forgot :-/ [07:04] fullermd: but note that `bzr config mypush` (backquotes) can ~replace 'bm:mypush' starting with 2.3 and poolie suggested 'config:mypush' [07:04] hi vila [07:05] poolie: hey ! [07:11] * fullermd goes crosseyed trying to parse that... [07:13] fullermd: huh ? And I thought you had some perl background... I didn't even quote single chars there... [07:14] Well, I _lexed_ it just fine :p [07:14] vila: perl has more use of shift-numbers = eg !&^%#@#*(&^)( [07:15] if it doesn't look like line noise, it's not perl :-) [07:19] spm: what's wrong with 'if ($c !~ /^%.*$/)' ? Crystal clear ! [07:20] dear lord. I can parse that. AAAAAAAAAAAAA [07:20] :-) [07:20] Oh, good. Now you're talking sense. [07:21] haha [07:22] spm: see ? This perl-is-noise meme is just crap ! :D [07:23] xml now... [07:23] * spm digs up some old line noise captures to compare vs actual perl code, and finds the comparison... similar [07:23] XML definitely isn't line noise. [07:23] Line noise serves an actual _purpose_... [07:24] fullermd: 1, vila/spm: 0 [07:24] LOL [07:25] ha, found back one of my favorite: 'local $/ ;' without comment :) [07:26] Yes, I have memories of stabbing people for crap like that... [07:26] Not legally actionable memories, of course. I feel a sudden burst of amnesia... [07:26] for those reading from home, this set the line separator to None so the next read on the *default* file will read until the end of file [07:26] fullermd: very useful trick, you should remember to put it inside a block to limit its side-effect though ;) [07:26] It's so much more self-documenting to just $x = join '', [07:30] my $text ; { local $/ ; $text = ; } isn't that bad [07:31] with a '# Slurp it into memory' comment just above [07:33] I still prefer the join. It doesn't need a comment, or screwing with magic vars. [07:36] bah, no magic vars ? You spoil the fun ! [07:37] Oh, no, I enhance it. I only use my OWN magic vars. Any fool can look up the _language's_ magic to work from; I like the bar for touching my code to be higher than that :p [07:40] local ftw ! [07:44] Any real win has global effect :p [07:50] spiv: wow, bzr@jubany upgraded to 2.3b5 !!?! [07:51] spiv: this means I should track *that* into bzr-package-importer so we also get that after the migration... [07:51] spiv: I did not dare to do it, but since you did... :) [08:12] *headdesk* [08:13] So, properly removing bzr's internal copy of configobj shows us that.... hardy's python-configobj lacks features which causes test failures [08:13] . o O (Quickly throw a pillow on maxb's desk) [08:13] don't do that then ? [08:14] ah well, I'll just back out the removal in the hardy PPA [08:16] yay unit tests, I suppose [08:17] indeed, we may miss some about the features we really require from configobj though [08:18] I dunno. I mean, it's hardly a coincidence that unit tests are responsible for a huge percentage of test failures... [08:20] maxb, how long has hardy got to run? [08:20] we could probably stop building bzr 2.4 for that [08:25] desktop EOL at hardy release. server EOL at S-series release [08:25] erm [08:25] * hardy: desktop EOL at natty release. server EOL at S-series release [08:25] Z-series ? :D [08:26] I am tempted to propose we drop all Jaunty packages, though [08:26] Taylor series? [08:26] maxb: +1 [08:26] Jaunty is EOL already. Just no-one has turned off PPA for support for it [08:27] I'll send an email to make it official [08:30] hmm [08:31] Except, dropping jaunty doesn't actually result in saved effort, since pretty much any backporting effort you need, is needed to get back so far as hardy too [08:32] right [08:32] i wonder if building _new_ bzr series onto hardy is worth while [08:33] perhaps we should separately backport configobj? [08:33] but as i recall that gets complicated because of dependencies from other programs [08:33] and i think it's hard to get new configobj working there [08:34] bzr includes a copy of configobj - but we removed it in these packages because Debian folks picked up on the unnecessary duplication. So we just need to unremove it on hardy [08:35] poolie: well, we had to decide what kind of support we want to provide for hardy, main includes bzr-1.3.1 only so I'd say we'd better limit ourselves to the stable ppa as I don't think we will ever be allowed to release even 2.0 there [08:35] (there == hardy-updates) [08:36] It's now possible to get download count info out of the LP API. We should see how many downloads bzr 2.3.0/hardy gets [08:37] right [08:37] maxb, i was thinking of removing it from the upstream tree too [08:37] anyhow, i should go [08:37] good night to you [08:37] right, but that won't tell us how many hardy sites may want to upgrade [08:37] poolie: g'night [08:38] vila, i wonder how many people want to upgrade bzr and don't even want to go to lucid [08:38] probably some [08:38] removing a copy of configobj would be nice but it's not a big win [08:38] anyhow, really goodby [08:38] yup, probably not that much and we can tell them to use the ppa [08:39] * fullermd . o O ( bzr said I needed to upgrade my old Ubuntu, so I installed FreeBSD... ) [08:40] ENOMATCH: Ubuntu or * better*, don't forget the better :-p [08:41] :P [08:44] 2.3.0 port update: http://www.freebsd.org/cgi/query-pr.cgi?pr=154496 [08:44] miwi@ is fairly consistent, so probably committed in the next few days. [08:47] interesting diff... [08:48] Howso? [08:48] fullermd: the summary it provides is due to the FreeBSD process right ? [08:48] I mean, it gives an overview of which files were added (none removed apparently which is a bit weird) [08:49] ha, sorry, yes it does [08:49] * fullermd isn't sure what you mean by 'summary'... [08:49] pkg-list [08:50] pkg-plist, as in 'packing list'. Yeah, list of the files, so that deleting a package knows what to delete. [08:50] right [08:51] the whole diff contains almost no noise for a human reader (considering SHA as noise is a bit extreme but you get the idea) [08:52] Well, changing the big number in the launchpadlibrarian URL every upgrade is noisy for me :p [08:52] fullermd: blame your packaging system for not being able to follow redirections ? :-D [08:53] But yah, it's not an overly verbose process. The pkg-descr change I've meant to do the last handful of upgrades, but kept forgetting :p [08:53] Well, it's _able_. In fact, it goes to significant lengths to _avoid_ it :p [08:53] why ? [08:53] (for a number of reasons, most of which are probably bad...) [08:53] ha [08:54] some good ones worth mentioning maybe ? [08:54] The only potentially good one I've ever heard has to do with those "brilliant" sites which respond with redirects instead of 404's to nonexistent files, and that sort of garbage. [08:55] by the way, did I already asked you about some way to get a list of plugins with their releases/revids/revnos from The Ports ? [08:55] Leads to user confusion when the downloaded tarball fails the SIZE/SHA256 check because it contains 10k of HTML instead of... y'know. A tarball... [08:55] hmm [08:55] bad sites, bad, bad, bad [08:55] Not sure you did. I can't offhand thing of a totally automated way... [08:56] no urgency but it would be nice [08:56] Only one I manage is bzrtools. C-S maintains a half dozen of them I think... [08:56] freshports probably has a list somewhere you can pull of "all ports that depend on X"; most of those are probably plugins. [08:58] Don't see one offhand. Well, can script it out of INDEX pretty easily, I imagine. [09:00] Ideally as a perl one-liner, with over half the characters requiring the shift key. Naturally :p [09:00] Shift Copy/Shift Paste :D [09:02] fullermd: If you can propose a mp with a script in tools/packaging, I'll gladly help refine it (long term thingie, may not find its way in 2.3, yada yada) [09:08] Hmm... well, still too readable, but... [09:08] http://pastebin.com/Ysa4khCk [09:09] wow [09:10] do you really need the progress bar there ? (/\|/) :D [09:10] Hey, INDEX is a big file :p [09:11] Feel free to add a 'local $/;' on to the beginning if it makes you happy ;) [09:11] lol [09:12] Alternately: `grep bazaar-ng /usr/ports/INDEX-8 | cut -f1 -d\|`. But who wants to waste all that time with a pipeline? [09:12] 8 is for FreeBSD8 right ? [09:12] (and that also lists bazaar-ng itself, which obviously doesn't depend on bzr, so you waste a bunch of electrons outputting that...) [09:13] Yah. Though I doubt that particular list changes across versions much... [09:13] copy/pasted into my freebsd8/INSTALL tip&tricks file [09:16] Very good. You'll receive my invoice shortly 8-} [09:17] hehe [09:17] . o O (fullermd.debt.beers++) [09:22] hehe [09:22] jelmer: morning ! [09:25] bonjour! === Ursinha-gone is now known as Ursinha [09:39] fullermd: bug 712935, if you want to subscribe [09:39] Launchpad bug 712935 in Bazaar Bookmarks Plugin "_get_filename deprecated in bzr-2.3" [Undecided,In progress] https://launchpad.net/bugs/712935 [10:34] vila: 2.3.0 uploaded to Debian [10:34] \o/ [10:37] fullermd: mind to test https://code.launchpad.net/~vila/bzr-bookmarks/712935-2.3-compat/+merge/48589 ? [10:43] fullermd: no test suite for the plugin :-/ I did a bunch of manual tests but I may have missed some [10:44] vila: if I reassign bzr-bookmarks to you, will it solve the problem? :) [10:44] luks: wow, instant feedback ! [10:44] luks: ideally you'll assign it to ~bzr (I think) so any bzr dev can participate [10:44] ok [10:45] luks: And thanks for pioneering this config area ! [10:45] luks: you had many good insights showing in the code... [10:46] well, it was always just a hack :) [10:46] anyway, the problem is reassigned [10:46] if you could create a native LP branch and merge your changes, it would be great [10:46] because now I can't :) [10:46] luks: Great ! [10:46] er, the project [10:46] (reassigned) [10:47] I'll look into it asap [10:47] fullermd: feedback even more highly welcome ;) === oubiwann_ is now known as oubiwann === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === vila 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 | 2.2.4 and 2.3.0 are frozen. Release plugins ! Build installers ! (rm vila) [13:42] vila: Thanks for approving my udd just-cleanup branch. Can I also ask you to land it, as I am not in ~udd ? [13:43] vila: mac installer 2.3 branch is pushed [13:44] maxb: gimme a sec but I won't forget [13:44] dOxxx: great, [13:44] dOxxx: I just froze 2.2.4 but I don't think we want OSX installers for it, 2.3 is the new stable [13:45] yah I saw your email [13:45] dOxxx: if you know someone with an OSX 10.5 host... [13:45] actually, I do... sec [13:47] vila: Craig Sawyer csawyer@yumaed.org, he let me access a OSX 10.5 machine on his network a few times last year until you started building them. [13:47] vila: I don't know if I have time to get it done today though [13:48] dOxxx: if you can forward him the 2.3.0 has gone gold mail so he get the pointers that would be great [13:48] vila: well, he wasn't the one doing the building, he just gave me ssh access to the machine. [13:49] dOxxx: oh, well, then this will need a bit of discussion with him, drop him a note to close the loop then ? [13:50] vila: I'll email you both [13:50] dOxxx: excellent ! === oubiwann is now known as oubiwann_ === oubiwann is now known as oubiwann_ [14:15] maxb: done [14:16] thanks [14:16] maxb: but not deployed yet [14:16] maxb: doesn't really matter, just mentioning [14:16] It has no operational effect, it just makes developer's lives more pleasant [14:18] maxb: indeed ;) [14:19] ah, thanks vila [14:19] sorry for not landing it straight away maxb [14:19] james_w: my pleasure [14:19] no rush. Just didn't want it to sit and be forgotten [14:49] jelmer: The last revision in lp:bzr-builddeb introduces a new bug. It looks like you missed one call to db.has_pristine_tar_delta(rev) in your refactor [14:53] maxb: looking === jasono is now known as Guest68493 === zyga is now known as zyga-food === beuno is now known as beuno-lunch [16:17] hi room. I've just started with bzr and I'm wondering: I have a website created for one client where code base is going to be used for another client (allowed), how do I do this? [16:18] trond-: you should be able to create a clone use "bzr branch" === Ursinha is now known as Ursinha-afk [16:20] jelmer, ok. so then brz branch (name of directory) (name of new/other existing directory)? [16:20] trond-: yep [16:21] see also the documentation [16:22] jelmer, I will. Thanks :) just needed the first direction === Ursinha-afk is now known as Ursinha [16:22] trond-: name of new, yes. other existing directory... likely to fail [16:26] vila, yup. it did. :) [16:26] good :) === jasono is now known as Guest97621 [16:29] vila: thanks for the reviews :) [16:29] np ;) [16:30] warming up for next week :) [16:31] fullermd caught you about the bookmarks plugins I see vila. [16:32] I'm a bit suprised it broke, your commit looked like it tried to retain compat. [16:32] mgz: hehe, I will feel less gulty when it'll be merged in core (feature wise) [16:32] mgz: err, really ? That's wasn't my intent ;) [16:33] mgz: err, really ? That wasn't my intent ;) [16:33] Without a test suite, I played it safe and tested my patch against 2.3 err 2.4b1 only [16:34] * vila is bad :) [16:34] tsk! [16:35] ah, I see, you detect the old api but didn't continue to provide it. [16:36] mgz: ha ! right, yeah, that's only by fixing bookmarks that I realized I left a hole in the compatibility [16:37] . o O (Freudian slip to push to the new API ? Well hidden...) [16:37] python doesn't make this stuff easy. [16:38] dynamic typing is both a blessing and a curse :) [16:58] errr, wth is going on ? 57 branches in the active reviews page ? [17:01] I see a normal number on , which page are you looking at? [17:01] https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev/+activereviews [17:01] how did I arrive there ??? [17:02] click the back button ;) [17:02] from here: https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev [17:02] dOxxx: hehe, no, previous tab :D [17:02] ...maybe that's a launchpad change to that link. [17:02] heh [17:02] and from here: https://code.launchpad.net/~jelmer/bzr/extra-branch-formats/+merge/48608 I clicked the Merge Into: lp:bzr link... [17:03] the weird thing is that these two branches are supposed to be the same one... [17:03] hmm that seems wrong [17:03] looks like launchpad is resolving lp:bzr wrong? [17:06] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/changes/12274 <- that page is slightly annoying to try and read [17:07] launchpad's multiline commit messages don't really work with the loggerhead output [17:07] got it, the long page shows the wips [17:07] no idea why [17:08] bug 707808 [17:08] Launchpad bug 707808 in Launchpad itself "Unmerged revisions list does not exclude merged revisions" [Critical,Fix released] https://launchpad.net/bugs/707808 [17:08] ...nope, not that [17:10] bah, too much stuff. [17:10] "some launchpad change". === beuno-lunch is now known as beuno === deryck is now known as deryck[lunch] [17:25] :) === zyga-food is now known as zyga-fk === zyga-fk is now known as zyga-afk === deryck[lunch] is now known as deryck [18:37] jam: -Dxxx Critical ? Isn't it a bit excessive ? We know we'll blame mgz anyway, don't be too hasrsh :D [18:37] vila: it's poolies fault [18:37] and I've tracked it down [18:37] ...whaddidibreak? [18:37] but yes critical [18:37] vila: We used to track how many bytes a command took. we now *always* get 0 [18:38] IMO, that is a regression [18:38] hence critiacl [18:38] critical [18:38] not data loss critical [18:38] but I probably would have blocked the release if I had known [18:39] mgz: you didn't break it, though I suspected you first, too :) [18:39] :D [18:39] I thought the get_transport() stuff changed us tracking the bytes transferred [18:39] but we still tracked it. [18:39] but it turns out we through away the info right before we went to log it [18:39] threw away [18:41] vila: also, -Dbytes only shows it to the user. we always log it so that we can go back and see if a command is being reasonable [18:42] will people throw pots at me if -Dthing is important not to break, it should have tests? [18:42] +I say [18:43] jam: what I don't get is how none of us saw it before, I'm running from trunk and most of my usages are from the command line... [18:43] ...hmmm, wait, is it for all operations or for uploads ? [18:43] Nah, I also push manually... [18:44] mgz: I didn't suspect you for one second :) But between you and jelmer, I thought it would be funniest with you :D [18:45] vila: all operations [18:45] jam: we have switched and tested multiple times around the hack-around-the-hook [18:45] and yes, I run bzr.dev [18:45] what happens is that if the number of bytes is 0, then it doesn't print anything [18:45]