[00:01] <lifeless> igc: hai
[00:09] <igc> morning all
[00:09] <igc> hi lifeless
[00:10] <poolie> hi igc
[00:10] <igc> hi poolie, jam
[00:11] <lifeless> igc: have you used netbeans as a datasource for benching?
[00:12] <igc> lifeless: no
[00:12] <lifeless> igc: I ask, because one of the drizzle folk was bemoaning the lack of a bzr scm module
[00:12] <lifeless> so I pulled the thing... 1.7GB, 90K files
[00:12] <lifeless> 133K commits
[00:13] <igc> lifeless: as in an addon for NetBeans?
[00:13] <lifeless> yeah
[00:13] <lifeless> their addons are all in tree
[00:13] <lifeless> _pain_
[00:13] <igc> lifeless: yuk
[00:14] <igc> lifeless: it was nice to see qbzr-eclipse 0.7 out overnight
[00:14] <igc> and I'm pretty sure there's someone working on a C++ Builder/Delphi integration along those same lines
[00:15] <igc> lifeless: http://bazaar-vcs.org/IDEIntegration/Guide
[00:16] <igc> lifeless: I'm pretty sure nick put together the original qbzr-eclipse integration in around 2 days
[00:17] <igc> lifeless: so it's typically easy to get *something* useful going
[00:18] <igc> lifeless: my main reluctance with doing an integration myself is ongoing ownership - it's better if someone using a given IDE everyday owns it IMO
[00:20] <lifeless> igc: I agree; I don't really like the different UI that qbzr-* gives though
[00:20] <ronny> igc: are you Ian Clatworthy?
[00:21] <igc> roony: yes
[00:21] <igc> ronny: ^
[00:21] <ronny> igc: great, well, what do people do that do api-level integration instead of subprocess levle integration :P
[00:22] <igc> ronny: I'm not sure I understand the question ...
[00:23] <igc> ronny: you can always call into bzrlib and into qbzr itself if you want
[00:23]  * ronny is the author of anyvc, a vcs abstraction lib, i just import bzr instead of calling to it
[00:23] <igc> though the qbzr API has no stability guarantees
[00:25] <igc> ronny: the point behind using the qbzr applets is to same the engineering time required to design, develop and test 30-40 dialogs
[00:25] <ronny> igc: well, does it have version metadata, and some more convience tools for common ops than bzrlibs?
[00:26] <ronny> igc: im not sure if qbzr wil lbe that helpfull for me, as i need the dialogs for other vcs's, too
[00:28] <igc> ronny: right. Down the track. I'd hope to see qbzr working in combination with bzr-svn, etc. to provide a common GUI over multiple VCSs but it sounds like you're solving a different problem
[00:29] <ronny> igc: yup, i'll probably have to support the svn integrations anyway at some point
[00:33] <jelmer> fwiw the combination of qbzr and bzr-svn should already work
[00:33] <jelmer> John Szakmeister did quite a bit of testing with it and reported bugs
[00:40] <lifeless> igc: hg fastexport is kinda slow :(
[00:41] <igc> lifeless: yep
[00:42] <igc> lifeless: on packs, so it bzr-fast-export; 2a is a much happier place for bulk data export/import
[00:42] <igc> s/it/is/
[00:43] <lifeless> yeah
[00:43] <lifeless> I should hope so :P
[00:48] <poolie> igc, so i liked your wishlist blog postn
[00:49] <poolie> but i think we need to distinguish "things that will actually block 2.0" from "things we'd like to do" :-/
[00:49] <poolie> because that list is pretty incompatible with hitting karmic
[00:50] <igc> poolie: yep
[00:51] <poolie> 2.0 is kind of trying to be two different things
[00:51] <poolie> the release that makes 2a the stable format
[00:51] <poolie> and the "everything's great and finished" release
[00:53] <fullermd> It's also trying to be the "Crap, we have to hit karmic" release...
[00:54] <igc> poolie: no, it's not the later
[00:54] <igc> poolie: 2.0 is trying to be 2.0
[00:55] <igc> poolie: that does mean a new format
[00:55] <igc> poolie: it also means "now's a god time to take another look at Bazaar if you're not using it"
[00:55] <igc> good
[00:55] <poolie> sure
[00:56] <poolie> i guess i'm glad you're raising these things but the week we're trying to freeze the code is a
[00:56] <poolie> well, maybe not a great time
[00:57] <poolie> :/
[00:57] <igc> poolie: that's not totally fair ...
[00:57] <igc> I've been raising better packaging for weeks and weeks now on multiple email lists
[00:57] <poolie> that's true
[00:58] <poolie> -> phone
[01:28] <flacoste> if I use bzr-svn to merge a svn branch onto the trunk, will svn grok the merge?
[01:28] <lifeless> jelmer: ^
[01:29] <flacoste> i was talking with a guy last week at Agile2009 who use git-svn
[01:29] <flacoste> on windows
[01:29] <flacoste> he finds it painfully slow
[01:29] <flacoste> and that was another pain point for him
[01:29] <flacoste> i want him to have another try at bzr
[01:29] <flacoste> he try it out last year
[01:30] <lifeless> bbs fooding
[01:46] <igc> hi jelmer
[01:47] <igc> jelmer: I think qbzr is working over bzr-svn
[01:47] <igc> jlemer: I wonder if we need some tweaks though, e.g. a gui way of doing a dpush" or whatever name we selected for that operation
[01:48] <igc> jelmer: ^^^
[02:11] <lifeless> jelmer: ping
[02:27] <igc> bbiab
[02:39] <poolie> spiv: hi, late call?
[02:42] <spiv> poolie: sure
[02:42] <poolie> will call in 2m
[03:00] <spiv> Hmm, jam's mail server is bouncing mail.
[03:44] <rbelem> anyone knows which command in !bzr shows just the changes from a given revision?
[03:44] <bob2> what is !bzr?
[03:44] <rbelem> bob2, ops... typo
[03:44] <rbelem> :D
[03:45] <fullermd> The logical counterpart of ~bzr
[03:45] <rbelem> ehehehe
[03:46] <bob2> bzr diff -c xxx
[03:47] <rbelem> bob2, that was exactly what I was wanting
[03:47] <rbelem> thanks a lot!
[03:52]  * rbelem leaving
[03:56]  * igc lunch
[04:50] <andrewks> is there a way to make bzr missing walk up a sequence of branches?
[05:06] <AfC> up?
[05:08] <tbradshaw> LarstiQ: a status update:.  After recompiling subvertpy, I was able to get things to commit properly to the svn repo!  Thanks again for your help earlier today.
[05:41] <andrewks> AfC: transitive relationships.  the parent of the parent branch, etc
[05:45] <AfC> andrewks: so, to my knowledge, no, that's not built in. But it wouldn't be _that_ hard to [shell] script, especially if you assume that branches are sanely set-up, and that `bzr diff -r ancestor:` does what you want it to in each branch. Or you could parse `bzr info` output. etc
[05:45] <andrewks> yes, I'm going with sane locations for now.  This isn't something I have to do often
[05:48] <fullermd> AFAIK it all chains fine, so things like "parent:parent::parent" would DTRT.
[05:48] <fullermd> Also really screw up your brain trying to read, but hey, you can't have everything...
[05:50] <fullermd> Or maybe it doesn't 'cuz my brain is screwed up.  It's probably too late for anything I say to be worth listening to today...
[06:00] <AfC> fullermd: hm. Not so sure about that: `bzr status -r ancestor:ancestor:` just now didn't work
[07:20] <vila> hi all
[07:43] <poolie> hi vila
[07:43] <vila> hey !
[07:46] <lifeless> https://bugs.launchpad.net/bzr/+bug/422403
[07:46] <lifeless> hi vila
[07:48] <vila> add --forward to that and we should be quite close to the slowest possible context
[07:49] <lifeless> he runs this all the time
[07:49] <lifeless> to see what he has pulled
[07:49] <vila> I think Ian answer makes sense, drop -n0
[07:49] <vila> drill down only when needed
[07:50] <vila> that's the only work around I can think of
[07:50] <poolie> spm: actually maybe we should talk here
[07:50] <spm> poolie: heh. indeed. just reading now.
[07:50] <poolie> vila: well, it can be an open bug still
[07:50] <poolie> let's make sure it's deduped and clear: takes too long to start showing revisions for indented less
[07:50] <vila> until we are able to calculate revnos lazily, that bug will remain open... lol, fully agree poolie :)
[07:50] <poolie> sure
[07:51] <spm> poolie: err. I'm not sure I can do that - I think I fail on the "friendly sysadmin" part???
[07:51] <poolie> saying it depends on the other bug is ok
[07:51] <poolie> damn
[07:51] <poolie> need 3 wise men too
[07:51] <lifeless> [he didn't tell me he used -0 :P]
[07:51] <vila> lifeless: they just love to trick us :-)
[07:52] <poolie> it might be worth drilling into why he's doing this
[07:52] <poolie> is it that he really wants to see all the history and -n0 is the best way
[07:52] <spm> poolie: yeah, that looks fairly straight forward. shall I start to make it so?
[07:53] <poolie> well, i guess you'll still need incremental revnos
[07:53] <poolie> spm, yes, how about turning off pqm first
[07:53] <poolie> at least for that branch, or globally
[07:53] <poolie> and let's make an extra adhoc backup of it, then run check
[07:53] <spm> globally for bzr, yes. backups is good.
[07:55] <vila> poolie: we have incremental revnos if we display mainline revisions only :-) We start at the top and decrement, easy.
[07:55] <vila> s/top/tip/
[07:57] <poolie> right
[07:59] <spm> poolie: lifeless: I can't help but feel I'm missing something really obvious here. the master location is (pqm config) /home/pqm/archives/thelove/bzr/2.0 but that's only a 44Kb directory. 1.18 etc are the same. ??
[08:00] <poolie> spm, that's probably a bzr branch with no working tree
[08:00] <poolie> what does bzr info show you?
[08:00] <spm> poolie: it is; would it really be that small tho?
[08:00] <vila> spm: and a shared repo above it
[08:01] <spm> right. yes.
[08:01] <spm> shared repository: /home/pqm/archives/thelove/bzr
[08:01] <spm>   repository branch: .
[08:02] <vila> spm: 44Kb now sounds even too much :)
[08:02] <lifeless> spm: cd to /home/pqm/archives/thelove/bzr
[08:02] <lifeless> spm: upgrade *that*
[08:02] <spm> vila: heh. well a sum total of 570Mb is more the ballpark I was expecting.
[08:02] <lifeless> spm: same as launchpad, shared repo.
[08:02] <poolie> ok
[08:02] <poolie> so tar up the whole thing before starting?
[08:02] <poolie> and then run check in there
[08:03] <poolie> oh also we should check what version of bzr you're using there
[08:04] <vila> not sure, it will make a difference when run locally, but upgrading the test slaves, I noticed huge differences in performances between 1.17, 1.18 and 2.1dev, I think 2.0rc1 at least is needed here (or did spiv patch regarding IDS landed in bzr.dev only ?)
[08:04] <spm> so tarball: ~/archives/thelove/bzr-backup-2.0.tar fwiw
[08:05] <spm> we have bzr 1.17 locally; I can moderately easy create a special bzr of any version needed?
[08:05] <poolie> using 2.0rc1 would be good
[08:05] <poolie> or the ppa nightly
[08:05] <spm> ppa's is hard. build from source/branch is easy
[08:06] <spm> amusingly :-)
[08:06] <vila> lp:bzr/2.0 then
[08:06] <vila> hmm, wait
[08:06] <poolie> yes, that'd be good
[08:07] <lifeless> vila: need 2.0 on launchpad before it will be fast :P
[08:07] <lifeless> poolie: re conversion performance: this is what spiv and I meant by 'very slow without network deltas'
[08:08] <lifeless> poolie: its not hanging, its doing millions of little round trips on the VFS
[08:08] <vila> lifeless: it already makes a difference when pulling from lp
[08:08] <poolie> lifeless: it's not doing any network io
[08:08] <poolie> as observed by trace
[08:08] <lifeless> poolie: oh, thats extremely odd
[08:08] <poolie> strace*
[08:09] <vila> poolie: but didn't you have CPU consumed ?
[08:09] <lifeless> did you try ctrl-\ and inspect?
[08:09] <poolie> yes, that's the bug i filed
[08:09] <lifeless> ok
[08:09] <poolie> now i'm fixing bug 341535 :)
[08:09] <lifeless> looks like a server bug of some sort
[08:09] <lifeless> hmm
[08:10] <vila> I didn't comment on the bug, but I had symptoms pretty close to yours (poolie) except my pulls finished...
[08:12] <vila> spm: so, lp:bzr/2.0 is already a bit more than 2.0rc1, nothing to be worried about I think, but if you keep notes on the upgrade it will be good to note the revno you used
[08:13] <spm> vila: 'kk
[08:14] <spm> btw. "Setting ssh/sftp usernames for launchpad.net." how do I stop bzr from doing that? it creates that )(*^)*(&^(%^&%$&*%^$*&%ing authentication.conf file and hence fails to connect. I assume by not using lp:bzr/blah syntax
[08:15] <vila> err, how do you connect ?
[08:15] <vila> you use bzr-pqm user right ?
[08:15] <vila> on lp I mean
[08:15] <spm> bzr branch bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.0 bzr-2.0 <== works; bzr branch lp:bzr/2.0 bzr-2.0 <== fails
[08:15] <spiv> Why is the existence of the authentication.conf a problem?  Because it's putting in 'spm' rather than 'bzr-pqm'?
[08:16] <spm> spiv: tbh, I don't precisely know, but using that lp:bzr breaks it totally. it's bzr-pqm, I'm sudo'd as the pqm user.
[08:16] <vila> sudo doesn't matter, what is you $HOME ?
[08:16] <spm> oh that's right - we have aliases "somewhere" that map users keys to branches or somesuch.
[08:17] <vila> authentication.conf is such a map !
[08:17] <spm> .ssh/config
[08:17] <vila> also
[08:17] <vila> but looked at after :)
[08:18] <spm> ISTR that the issue is around the *other* accesses that this uid has; all with diff keys
[08:18] <vila> spm:  what is your $HOME ?
[08:18] <spm>  /home/pqm
[08:19] <vila> what is /home/pqm/.bazaar/authentication.conf  content?
[08:20] <vila> LOL, I never went to https://edge.launchpad.net/~bzr-pqm before :D
[08:21] <spm> vila: [Launchpad] host = .launchpad.net ;; scheme = ssh ;; user = launchpad-pqm
[08:22] <vila> so launchpad-pqm should be bzr-pqm ? Oooooooh, that's the problem ! It's used for launchpad and bzr right ?
[08:23] <spm> vila: launchpad no, but other projects yes.
[08:24] <spm> sorta.
[08:24] <vila> spm: and they need that launchpad-pqm identity ?
[08:24] <spm> heh. they have their own. like bzr-pqm :-)
[08:24] <spiv> The same PQM instance is used for multiple projects?
[08:24] <spm> yeha. what spiv said. thanks andrew :-)
[08:25] <spiv> That seems strange to me, no wonder we're having trouble :)
[08:26] <vila> haaa, I think I get it, the lp directory service  is the one that create auth.conf, so that explains the difference
[08:26] <poolie> nice image for pqm :)
[08:26] <vila> poolie: made me LOL yes :)
[08:26] <spm> huh. default balleny doesn't have pyrex installed, just the bzr pqm chroot does.
[08:27] <poolie> vila, so on bugs like the pqm speed one, can we change the description/subject to something reflecting the general bug?
[08:28] <vila> spm: strictly speaking the lp dir. service is wrong here, it shouldn't create an auth.conf file because... using different users to connect to the same host is not a case that auth.conf can handle (I think(
[08:29] <vila> poolie: pqm speed bug ? # ?
[08:29] <poolie> sorry, i meant log speed
[08:29] <spm> vila: fair enough
[08:30] <vila> spm: the bad news is that the only work-around I can think of is 1) stop using  lp: shortcuts, 2) always mention user@bazaar.launchpad.net in urls
[08:31] <spiv> Or set BZR_HOME differently for each pqm 'instance', as a substitute for having different system users.
[08:31] <spm> vila: heh. 1, we'd kinda figured out, if not enunciated clearly. 2. ?
[08:31] <spm> spiv: ahhh. that's easily doable I 'spect
[08:32] <vila> spm: spiv idea is better :)
[08:33] <vila> spm: same effect: the user is explicit so auth.conf is not injecting a bad one anymore
[08:33] <spm> vila: spiv is more than just a teddy bear; you heard it here first.
[08:33] <vila> dropping bear ?
[08:33] <spm> vila: ah. right.
[08:35] <spm> vila: so the upgrade/check. /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/bzr-2.0/bzr revno /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/bzr-2.0 ==> 4647
[08:38] <poolie> seems about right
[08:39] <poolie> we should try check on it?
[08:39] <spm> is running atm. just "/.../bzr check"  yes?
[08:40] <spm> err.. in /home/pqm/archives/thelove/bzr to be more precise
[08:40] <poolie> right
[08:41] <poolie> and did you tell pqm to stop processing mails?
[08:41] <poolie> thanks for doing it today btw, i know it's getting late
[08:43] <spm> poolie: aye, processing bzr ones at any rate. is cool, I had to work later today anyway.
[08:43] <vila> we can't 'bzr log' without showing any revnos at all ? Did we lose that or did I dream it ?
[08:43] <poolie> i don't recall having that
[08:43] <poolie> it might be useful
[08:43] <vila> I thought --show-ids was doing that but no
[08:49] <vila> poolie: I think you should create a 2.1 milestone,
[08:49] <poolie> good idea
[08:50] <vila> creating 2.1 release branch may wait though
[08:50] <poolie> vila, it should be something different, like --no-revnos
[08:50] <vila> poolie: I agree
[08:50] <poolie> vila, do you want me in particular to do it?
[08:50] <poolie> i don't mind, but don't you have access?
[08:51] <poolie> lifeless: i'm trying a conversion here and getting
[08:51] <vila> oh no, it was just that I wanted to check with you first (you may have had (sp ?) a reason for not creating it)
[08:51] <poolie> bzr: ERROR: The file id "mpregen-20070411063203-5x9z7i73add0d6f6-1" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x4372650>.
[08:53] <vila> poolie: it was also mentioned in https://code.edge.launchpad.net/~vila/bzr/releasing-clarified/+merge/10854 and really that's a new *series* that should be created :)
[08:53] <poolie> right, it should be both
[08:53] <poolie> though, um
[08:53] <vila> :)
[08:53] <poolie> actually i'm not sure how this will interact and whether the milestone should be on trunk or on the 2.1 series
[08:54] <poolie> probably the second, for the final release
[08:54] <poolie> were you wanting to target something now?
[08:54] <vila> no
[08:54] <vila> but someone want, and in principle, since bzr.dev now says 2.1dev, 2.1 should exist
[08:55] <vila> that's why I repeat the "create milestone" mantra several times in releasing.txt, because that's the one that is the most often forgotten
[08:55] <vila> but no urgency, just something I wanted to get out of my mind and onto the RM shoulders :)
[08:56] <vila> (that's the famous: "you can sleep now, that's not *your* problem anymore" joke :)
[08:58] <poolie> :)
[08:58] <vila> poolie: bzr-gtk create milestones in the trunk series, I'm not sure that's better, but just have a look at https://edge.launchpad.net/bzr-gtk/+series
[09:00] <spm> fyi: bzr check still running. just going afk for a bit; will be back in 10.
[09:00] <poolie> vila, they may not branch for releases?
[09:02] <poolie> vila, my point about the bug title is: don't mention "1233 revisions" or "on mysql" unless it really is specific to that case
[09:02] <vila> indeed. I did the last two releases, but I just followed the existing practice. In retrospect, I'm almost sure it wasn't really a conscious decision, just a simplification that lp allowed
[09:02] <poolie> users always make them specific but i'm sure it's clearer if we make them as general as is appropriate
[09:02] <poolie> helps with removing dupes etc
[09:02] <poolie> i'll do a 2.1 series now
[09:02] <poolie> the little diagram is interesting
[09:03] <vila> poolie: good point
[09:04] <vila> yes, that's why I pointed you there
[09:04] <lifeless> poolie: when did you last check your repo ;)
[09:04] <jml> lifeless, "Handing over to a machine to do CI is just as expensive as handing to a colleague." -- Handing over to a machine is probably a little cheaper
[09:04] <vila> it captures the release process amazingly
[09:04] <lifeless> vila: the other thing forgotten is 'create NEWS headers'
[09:04] <poolie> lifeless: just now :-O
[09:04] <jml> (advogato sucks for replies)
[09:04] <vila> lifeless: I mentioned it in the cover letter
[09:04] <lifeless> jml: for you, not for the machine :)
[09:05] <vila> I thought you read it there first, but that's just more telepathy obviously :)
[09:05] <vila> oh, no *create*, yes, I forgot that, I thought you were referring to NEWS header ordering with overlapping releases
[09:06] <vila> but both are tied anyway
[09:06] <lifeless> :P
[09:07] <poolie> lifeless: i'm just checking it again now in a clean local branch
[09:07] <jml> lifeless, when you hand off to humans, you almost always have to transfer knowledge. that's less commonly true for machines.
[09:07] <lifeless> poolie: also are you upgrading with the latest ?
[09:07] <jml> although there's probably an argument-by-different-definition to be made there
[09:07] <poolie> yes, trunk as of today
[09:07] <poolie> i might use 2.0 instead though
[09:08] <lifeless> jml: How about this: When you hand off to a human, you can stop worrying, but the act of handing costs more. When you hand off to a machine, you know its coming back to you if it fails, so there is some cognitive load.
[09:08] <lifeless> jml: And I'm asserting that these, while different, are approximately the same
[09:09] <lifeless> jml: what blog site did you end up using?
[09:10] <jml> lifeless, I use blogger.
[09:10] <lifeless> what would you like to see them improve?
[09:10] <jml> lifeless, I think I'll use wordpress for my next project though.
[09:10] <lifeless> hosted or self-run?
[09:10] <jml> lifeless, ease of pasting code samples :)
[09:11] <lifeless> and why wordpress?
[09:11] <jml> lifeless, I host my own blogs currently, blogger sftps them to my site
[09:11] <lifeless> interesting; and does your feedback too?
[09:11] <lifeless> to your site, or from your site?
[09:12] <jml> blogger uploads to my site
[09:12] <lifeless> nice
[09:12] <jml> I actually have no idea how comments work, but they do work.
[09:12] <jml> lifeless, wordpress because it seems to have the biggest community and all the blogs I see that look good & use free software seem to use wordpress
[09:13] <poolie> lifeless: i just reproduced this failure on a fresh branch of bzr from lp into a fresh directory :/
[09:13] <jml> it's also quite flexible.
[09:13] <lifeless> poolie: \o/ dogfooding
[09:13] <lifeless> jml: and you'll self host again?
[09:14] <jml> how do I get pqm-submit to not care about the fact that I lack a local copy of the branch I want to submit?
[09:14] <jml> lifeless, probably.
[09:14] <lifeless> though I understand that for wordpress that means more than it did/does for blogger
[09:14] <lifeless> jml: patch it
[09:14] <lifeless> jml: its on my 'do it the next time it annoys me' list.
[09:15] <vila> jml: what are you submitting then ? pqm-submit is more or less supposed to ensures that *you* are submitting *this*
[09:16] <jml> vila, I'm submitting a patch on someone else's behalf.
[09:17] <vila> jml: irrelevant :) In principle you still need to "sign" *this*, where is *this* ?
[09:17] <lifeless> vila: nah, thats recent
[09:17] <lifeless> vila: pqm-submit is 'tell pqm what to do'
[09:17] <lifeless> vila: there is no good reason to prevent clueful use being convenient.
[09:18] <vila> lifeless: I know, hence my "in principle" and "more or less"
[09:18] <lifeless> vila: I'm arguing the principle is unclear :)
[09:18] <lifeless> like the bug on switch. boy that hurt :(
[09:18] <jml> here's what I want
[09:19] <vila> We agree :) I'm trying to avoid popularizing a hole I dislike in pqm-submit :-)
[09:19] <jml> (as a hacker of Launchpad)
[09:19] <lifeless> a fast test suite
[09:19] <jml> a way of submitting an approved merge to land, conditional on tests passing
[09:19] <lifeless> a great user experience
[09:19] <vila> lifeless: :D
[09:19] <poolie> i'm posting a reproduction on bug 422423
[09:19] <jml> a way of submitting an approved merge to land
[09:19] <poolie> it's just a tarball from lp
[09:19] <jml> lifeless, those too.
[09:20] <poolie> i have to go out with S now, but i'll come back and look at this
[09:20] <poolie> spm, we'd probably better not proceed until we get to the bottom of it
[09:20] <lifeless> jml: please, its pretty obvious; take the code, opportunistically fix it. Use it and submit a merge.
[09:20] <lifeless> jml: (like I did for removable :P)
[09:20] <jml> lifeless, suree.
[09:20] <lifeless> jml: by obvious I mean that the code is small and simple.
[09:22] <jml> lifeless, yeah, I'll do it the next time I get a chance
[09:22] <jml> but I don't have any more time to hack this evening
[09:22]  * igc dinner
[09:22] <jml> and if I did, I really ought to use it to pack, not hack.
[09:25] <spm> poolie: ok, at this stage the check actually failed.
[09:26] <poolie> interesting
[09:26] <poolie> so
[09:26] <poolie> we should probably reenable pqm, and not proceed further until we know what's causing this
[09:26] <spm> https://pastebin.canonical.com/21673/
[09:26] <spm> oki
[09:27] <spm> bzr pqm re-enabled
[09:29] <poolie> thanks
[09:29] <poolie> i'm going to look at it tomorrow, or at most later tonight
[09:29] <poolie> spm is that pastebin before it failed??
[09:29] <poolie> it has no errors
[09:30] <vila> found error:Internal check failed: revno does not match len(mainline) 1649 != 1674
[09:30] <spm> I'm not sure how serious an error that is? recommendations to RTFM will be ignored. :-)
[09:34] <vila> that's a bit strange, and I can't see if it's for 0.8 or 1.8... 1.8 has 3766 revisions in the mainline anyway...
[09:39] <vila> spm: ok, 0.8 has 1674 revisions so that's the one
[09:41] <vila> spm: I'm pretty sure reconcile will fix that
[11:05] <spirov92> I have 2 branches in the same directory, let's say branch1 and branch2, with a similar file structure. Can I copy branch1/lib/some_file.php to branch2/lib/some_file.php using bzr?
[11:19] <emmajane> ping poolie
[13:45] <johnf> abentley: will you be doing a 2.0.0 release of bzrtools?
[13:45] <abentley> johnf: Yes.
[13:46] <johnf> jelmer: same question for bzr-svn :)
[13:46] <jelmer> johnf: I'm going to release a bzr-svn matching bzr 2.0, probably bzr-svn 1.0
[13:46] <jelmer> johnf: not sure yet for bzr-git
[13:57] <jelmer> has anybody seen james_w recently?
[15:03] <igc> night all
[15:22] <CameronP> HI there!
[15:22] <CameronP> I just installed bzr!
[15:23] <CameronP> Trying to merge my first lot of changes back to main branch - through tortoise bzr , i cant find a way to merge
[16:13] <jam> is anyone else seeing launchpad be a bit slow to load today?
[19:50] <Kobaz> how do you perminantly remove something from a branch
[19:51] <luks> you can't
[19:51] <Kobaz> aww, i thought i remember reading something somewhere that you could
[19:52] <jelmer> you can remove a revision from a *branch* by using "bzr uncommit"
[19:52] <Kobaz> uncommit only removes from the head it seems
[20:08] <garyvdm> Kobaz: You can do it, by branching it to a new branch, and deleting the old branch. This won't remove it from other branches that may have the revision.
[20:08] <Kobaz> k
[20:09] <Kobaz> so if you like, delete stuff, and then branch?
[20:09] <Kobaz> or do uncommits, and then branch?
[20:09] <garyvdm> Hi jelmer
[20:11] <garyvdm> jelmer: was going to ask if you knew of any code that uses ui.get_username, other than bzr-svn, but I see that bzrlib/config.py uses it.
[20:14] <garyvdm> do uncommits, and then branch
[20:57] <lifeless> moin
[21:00] <lifeless> jam: ping
[21:00] <jam> morning lifeless
[21:00] <lifeless> howzitgoing?
[21:03] <jam> pretty good
[21:03] <lifeless> jam: so, recompressing
[21:05] <jam> I'm trying to evaluate real-world effect. but making branching from scratch significantly slower isn't a real gain, IMO
[21:05] <jam> if it was only incremental, then maybe
[21:06] <lifeless> Without this we will still fragment
[21:06] <lifeless> sue to incremental pushes to common repos
[21:06] <lifeless> s/sue/due/
[21:07] <jfroy|work> jelmer: wasn't there a way to see the svn revision associated with a particular bzr revision? I can't seem to find that info anywhere.
[21:07] <lifeless> now, I desire us to have a hybrid, but its not clear to me that we should block 2.0 on having a hybrid
[21:08] <jam> lifeless: incremental pushes will eventually autopack
[21:08] <jam> so we won't fragment in the same way that we were
[21:09] <lifeless> jam: yes, but that argument applies to the prior code too
[21:09] <lifeless> there were two causes of fragmentation: separate push events, and group filtering
[21:10] <lifeless> there is currently one cause of combining - pack
[21:10] <jam> lifeless: sure, though the latter was a much bigger portion of it
[21:10] <jam> lifeless: well, autopack combines
[21:10] <lifeless> jam: yes
[21:10] <jam> so incremental push /pulling has a chance to pack everything but the initial stuff
[21:10] <lifeless> jam: I'm not classing autopack as fundamentally different
[21:11] <lifeless> jam: except that the user doesn't /choose/ it
[21:11] <lifeless> jam: right
[21:11] <lifeless> so an initial pull of LP, with large amounts of history, is going to take ages before the next auto-complete-pack
[21:12] <lifeless> but the data that was pulled will be read from many many times
[21:12] <lifeless> wow! hg fast export has sbeen running for 24 hours now
[21:12] <lifeless> still not finished
[21:12] <jam> lifeless: exporting what?
[21:12] <lifeless> netbeans
[21:13] <lifeless> 40G stream so far
[21:13] <lifeless> I was looking at the chance of quick-hack to make an hg plugin for it
[21:14] <lifeless> sadly way to high a cost to fit in opportunistic coding time
[21:14] <lifeless> but having done hg branch (1.6G ofdata, 90K files, 133K revs), I figured I may as well get a test case for 2a from it
[21:14] <jam> lifeless: do you mean a bzr plugin for netbeans ?
[21:15] <lifeless> yes
[21:15]  * lifeless adds caffeine
[21:16] <jam> argh.... with a fresh windows install, I decided to try py26, overall nice, but now pycrypto spewes 2 deprecation warnings everytime I connect via ssh :(
[21:16] <lifeless> urgh
[21:16] <lifeless> rmeinds me
[21:16] <jam> I think there is an open bug about pycrypto and python2.6
[21:17] <lifeless> I should send the python 2.6 fixes to pyrex upstream
[21:17] <jam> but they haven't released a new pycrypto yet
[21:17] <jam> lifeless: the Exception issues?
[21:17] <lifeless> yeah
[21:17] <jam> lifeless: I'd rather we switched to cython :)
[21:17] <lifeless> jam: I want us to reevaluate our external deps
[21:18] <lifeless> I'd like cython, testresources, testscenarios, subunit, sphinx, all to become hard build deps
[21:18] <lifeless> We also need to start versioning the output of cython so we can build it on pqm
[21:18] <lifeless> and elsewhere
[21:19] <lifeless> have you converted mysql-server into 2a?
[21:19] <jam> lifeless: not recently, but I did do testing in the past w/ mysql
[21:20] <lifeless> I'm going to talk focusedly at drizzle today
[21:20] <lifeless> mtaylor: ^
[21:20] <beuno> mwhudson, +1 to upgrade loggerhead to 2a?  it's alrady 1.9-rr anyway...
[21:20] <jam> lifeless: so I think there is distinctly several possible tradeoff points for the balance between recompression on the fly none, some, all. I think unordered + none is a better tradeoff today than all, and we can write a 'some' implementation for the next release.
[21:21] <mtaylor> lifeless: ola
[21:21] <jam> lifeless: http://bazaar-vcs.org/Roadmap/BrisbaneCore/Details scroll down to: $ du mysql-5.1-test
[21:21] <lifeless> mtaylor: drizzle should upgrade to 2a
[21:21] <jam> mysql 5.1 at that stage went from 501MB => 170MB on disk
[21:22] <mtaylor> lifeless: it's ready for us to convert all of our branches?
[21:22] <lvh> apparently so!
[21:22] <lvh> dash is doing it for twisted
[21:22] <lvh> and twisted is super important
[21:22] <jam> lvh: launchpad itself has been using it for a while
[21:23] <lifeless> mtaylor: the bug you encountered on libcpuinfo is fixed
[21:23] <mtaylor> ok. cool
[21:23] <lvh> jam: yeah, apparently my fears of pre-release non-default repo formats eating my data is unfounded
[21:23] <mtaylor> lifeless: what's the version of bzr that it requires?
[21:23] <lvh> s/is/are/
[21:23] <lifeless> 2.0rc1 should be pretty damn solid, even though we have landed more bug fixes since
[21:23] <lvh> mtaylor: 1.16 or something.
[21:23] <lifeless> mtaylor: I suggest 2.0rc1
[21:23] <lvh> mtaylor: it's been around for a few releases
[21:24] <lvh> 2, I believe
[21:24] <lifeless> mtaylor: 1.16 and up can read-write it
[21:24] <lifeless> mtaylor: but there are bugs in those versions that make it desirable to upgrade all the way
[21:24] <mtaylor> so, I have to get about 50 people to upgrade their bzr ... so I need to be real specific. do I need to have them upgrade to 1.16? or to 2.0rc1?
[21:24] <lvh> lifeless: if I want to use 2a for my branch I have to wait until the maintainer for the main project updates everything to 2a first, right?
[21:24] <mwhudson> beuno: sure
[21:25] <lifeless> lvh: if they are on a rich-root format, you can upgrade early and send bundles
[21:25] <lifeless> lvh: if they aren't on a rich root format, you have to wait
[21:25] <lvh> I think they are.
[21:25] <beuno> Peng_, upgrading LH to 2a
[21:26] <jam> lifeless: it seems the bazaar wiki will lock you out if you hit Preview too frequently... :(
[21:26] <lifeless> jam: lol
[21:26]  * mtaylor now considers whether to upgrade all of our branches to 2a while brian is at burningman
[21:27] <lifeless> mtaylor: let me get an estimate for drizzle
[21:27] <jam> and, of course, it doesn't tell you how long the lockout period is, and it warns that submitting too soon may increase the lockout time...
[21:27] <jam> is it seconds, minutes, an hour?
[21:27] <jam> argh
[21:27] <lifeless> #is
[21:28] <lifeless> 8-way machines <3
[21:28] <lifeless> hah, conversion error
[21:29] <mtaylor> heh.
[21:29]  * mtaylor will wait until that is fixed :)
[21:29] <beuno> anyone know how to remove a backup.bzr dir from LP?  hitchhiker tracebacks when using rm
[21:29]  * lifeless reconciles drizzle
[21:30] <beuno> abentley, ^ any ideas?
[21:30] <lifeless> beuno: whats the traceback?
[21:30] <lifeless> beuno: also, I know that lftp works
[21:30] <mtaylor> beuno: lftp
[21:30] <abentley> beuno: rmtree.
[21:30] <beuno> wow
[21:30] <beuno> that's it, rmtree
[21:30] <beuno> thanks abentley
[21:30] <beuno> and lifeless and mtaylor
[21:30] <abentley> beuno: np
[21:31] <beuno> we really need to fix this to smoothen upgrades
[21:31]  * mtaylor AGREES
[21:31] <abentley> beuno: See also: https://answers.edge.launchpad.net/launchpad/+faq/675
[21:31]  * mtaylor would sort of love it if there were a button on launchpad that said "upgrade"
[21:31] <beuno> mtaylor, rockstar had that on his plate for a while
[21:31] <beuno> I even got a nice icon for him
[21:31] <beuno> but something... happened
[21:32] <mtaylor> hewh
[21:32]  * rockstar looks up
[21:32] <mtaylor> rockstar: bzr branch upgrade button ftw?
[21:32] <lifeless> mtaylor: There is a bug. Put it in your wishlist for lp :)
[21:32] <lifeless> unless you've done one already
[21:33] <mtaylor> lifeless: prolly have :)
[21:33] <mtaylor> lifeless: I think around the time I upgraded drizzle to 1.9
[21:33] <lifeless> mtaylor: there is a thread on lp-users
[21:33] <lifeless> mtaylor: about 3 wishes for lp
[21:34] <lifeless> mtaylor: it is to that that I refer
[21:34] <mtaylor> oh, right
[21:35] <lifeless> I'm getting 6 GB of ram for this machine today
[21:35] <lifeless> \o/
[21:35] <rockstar> mtaylor, so, the work is basically done, except that we need to actually upgrade the branch without blocking your work.
[21:35] <lifeless> rockstar: really?
[21:35] <lifeless> rockstar: I would have thought blocking there work was expected
[21:35] <rockstar> lifeless, you were there when Mark told us we need to.
[21:36] <rockstar> (it was at lunch at AllHands)
[21:36] <lifeless> rockstar: oh right. sadness
[21:36] <rockstar> lifeless, it's not a big deal, and actually an excellent point.  However, then we got other things.  I'm sure we'll get back to it soon after 3.0
[21:37] <lifeless> rockstar: well if its easy to go great, its obviously better than blocking. OTOH I still think that most projects are so small they wouldn't notice or care
[21:37] <lifeless> s/to go/to do/
[21:38] <lifeless> jam: I want to use knowngraph in reconcile/check
[21:38] <lifeless> jam: can you think of any gotchas?
[21:38] <rockstar> lifeless, I think the most difficult thing to worry about is the chicken and egg upgrading of stacked branches.
[21:38] <lifeless> rockstar: we've fixed that upstream
[21:39] <lifeless> rockstar: bzr upgrade URL_of_stacking_branch just works now
[21:39] <lifeless> you can't use the branch till thats done - so lp should do a reverse graph walk and fix them up
[21:40] <rockstar> lifeless, oh, awesome.  I think I have some projects to upgrade then.
[21:40] <lifeless> use 2.0rc1
[21:40] <jam> lifeless: I don't know of any specific gotchas, other than you need to have the whole graph, but you should have that for check/reconcile
[21:40] <lifeless> not because its strictly needed for that
[21:40] <lifeless> but it has the most fixes
[21:40] <jam> It doesn't currently expose a way to get the individual parents
[21:40] <jam> but garyvdm put together a patch for that
[21:41] <lifeless> bugger :( reconciled drizzle fails to upgrade too.
[21:41]  * lifeless bugginates
[21:41] <garyvdm> Hi jam and lifeless
[21:41] <jam> so garyvdm, was the code you were using already using iter_merge_sort?
[21:41] <jam> (the code you 'improved' to start using KnownGraph)
[21:42] <jam> I believe it is Branch.iter_merge_sorted_revisions()
[21:42] <jam> as if you want to look for a perf improvement, it iter_merge_sorted_revisions was updated to use KnownGraph internally
[21:42] <garyvdm> jam: let me have a look
[21:42] <jam> so you may need to compare between versions of bzr, rather than qbzr w/ vs w/o KnownGraph support
[21:44] <garyvdm> jam: I we were previously using bzrlib.tsort.merge_sort
[21:44] <garyvdm> Not Branch.iter_merge_sorted_revisions, because we have to handle multiple branches
[21:44] <jam> ah, ok
[21:46] <garyvdm> jam: If you are intrested: lp:~garyvdm/qbzr/knowngraph
[21:46] <garyvdm> jam: I need so time to profile it in detail to see why it is not faster.
[21:46] <jam> garyvdm: taking a look
[21:50] <jam> garyvdm: so... the *biggest* improvement you could get is switching to the find_ancestry stuff, which doesn't yet support multiple sources
[21:50] <jam> merge_sort itself is probably at most a second or so of your runtime
[21:51] <garyvdm> Jam: I agree
[21:52] <garyvdm> jam: I also can only initialy load the mainline. That would be a big win.
[21:55] <jam> garyvdm: you might try something like this: http://paste.ubuntu.com/263407/
[21:56] <jam> and see if that gets you somewhere nice
[22:12] <lifeless> hi garyvdm
[22:17] <lifeless> jam: https://bugs.edge.launchpad.net/bzr/+bug/422849
[22:17] <jam> lifeless: I don't know anything offhand other than: https://bugs.launchpad.net/bugs/422423
[22:18] <jam> which Martin just reported
[22:18] <lifeless> I'll track this one down
[22:18] <lifeless> and see if it fixes martins after that
[22:18] <lifeless> could be a common cause with different visible effects
[22:19] <jam> obviously the guess is that there is a problem with the computation of the delta
[22:19] <lifeless> :)
[22:20] <lifeless> I'll be getting more conversion timing data
[22:20] <lifeless> as well
[22:22] <jam> istr converting mysql took about 2 days on a rather old machine
[22:23] <lifeless> typo
[22:23] <lifeless> I meant 'fetch timing'
[22:23] <lifeless> I will be doing this netbeans repo test conversion
[22:24] <lifeless> partly to say to the sun folks how great it is :)
[22:24] <lifeless> and also to see how we do: 1G of 1.7G are manifests.
[22:24] <emmajane> poolie, morning
[22:24] <poolie> hello emmajane, lifeless
[22:25] <lifeless> hi poolie
[22:25] <lifeless> poolie: 'Slack' is highly entertaining. I think I'm an eve :P
[22:25] <poolie> hm
[22:25] <poolie> i don't recall that bit, is that one of the personas?
[22:26] <lifeless> poolie: yes, the first one
[22:26] <lifeless> seeks growth & challenge
[22:30] <lifeless> poolie: so you know, drizzle isn't converting to 2a either
[22:31] <lifeless> I'm investigating now. It may have a common cause with the error you had yesterday. Or maybe not.
[22:31] <poolie> because, not yet, or because?
[22:31] <poolie> oh i see
[22:31] <lifeless> 'fails to convert'
[22:31] <poolie> i was going to work today with igc on content filtering
[22:31] <poolie> anyhow breakfast first
[22:31] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/422849
[22:31] <lifeless> Once I know the cause I'll target it etc
[22:32] <lifeless> still gathering details/assessing
[22:34] <poolie> hm
[22:34] <poolie> i tested mysql a little while ago
[22:34] <poolie> i could retest it, which would narrow the problem to whatever time window that was
[22:34] <poolie> i was thinking i
[22:34] <lifeless> drizzle != mysql though, different history
[22:34] <poolie> ... well i was but i'll tell you later
[22:34] <poolie> true
[22:35] <beuno> HPSS calls: 8670 (8668 vfs)
[22:35] <beuno> \o/
[22:35] <beuno> (upgrading LH to 2a)
[22:35] <lifeless> WTB: network upgrade.
[22:35] <beuno> :)
[22:40] <beuno> mwhudson, Peng_, lh is on 2a
[22:41]  * mwhudson runs upgrade locally
[23:47] <lifeless> mtaylor: drizzle only drops 14MB in 2a
[23:47] <lifeless> mtaylor: what do you have in there..binaries?
[23:49] <lifeless> found the bug
[23:54] <igc> morning
[23:59] <mtaylor> lifeless: nope. no binaries for us!
[23:59] <lifeless> spiv: what tests would be the closest ones to the ones you changed in your ids-only-necessary-texts for bug 422849
[23:59] <mtaylor> lifeless: why don't we drop more?
[23:59] <lifeless> mtaylor: I don't know yet