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