[03:24] <irsyadano> Hi
[03:28] <tomreyn> hello there
[10:47] <darkdevil> hi
[10:48] <Guest6019> hi
[11:00] <camyyy> hi
[15:07] <xu-irc93w> hi
[15:08] <xu-irc93w> wutz
[20:48] <nexuiz15> where i can find motherboard compatibility list for motherboard with socket am5
[20:50] <gnrp> nexuiz15: I don't think there is a sensible one. Rather find a mainboard you want and then check whether it's compatible
[20:50] <gnrp> but I'd say that mostly, the exact mainboard does not matter so much as long as the important components (audio, network, chipset) are compatible
[20:54] <nexuiz15> I don't know where i can find this (audio, network, chipset compatible)
[20:58] <nexuiz15> I only study linux
[20:59] <gnrp> nexuiz15: Hm, sorry, the other way round... what do you want to achieve?
[21:01] <nexuiz15> I wont bay new motherboard, but i don't know will it work with linux
[21:03] <gnrp> nexuiz15: Which one do you have?
[21:04] <gnrp> in most cases, you have to try it out though. There often might be a minor quirk that some few people realize and the majority not, or the other way round
[21:05] <nexuiz15> for socket AM2 i know some motherboard. for  AM5 nothing
[21:05] <gnrp> ah, sorry, I misunderstood you
[21:06] <gnrp> I'd say you better find one that you like, and then one can check whether it is compatible
[21:06] <gnrp> the other way round, one full list of compatible notebooks, is barely anywhere
[21:09] <nexuiz15> not for notebook. for PC
[21:09] <gnrp> uhm, sorry, components, not notebooks
[21:17] <nexuiz15> i not programmer. i can only install xubuntu.
[21:19] <nexuiz15> bat i need upgrade pc
[21:19] <gnrp> nexuiz15: Yeah, but what I mean is: Check your favourite store for the mainboard that you want and that is in your price range. Or check whichever you would take. And then only afterwards you check whether it is compatible


[00:01] <igc> moldy: where did the branches come from?
[00:02] <igc> moldy: iiuic, no common ancestor implies they have no history in common
[00:07] <moldy> igc: they come from a converted svn repository
[00:08] <igc> moldy: converted via bzr-svn or bzr-fastimport?
[00:08] <moldy> igc: bzr-svn
[00:09] <igc> moldy: I don't know much about bzr-svn sorry
[00:09] <igc> jelmer: still around today?
[00:09] <moldy> igc: as a last resort, i could manually create another branch off of branch a, apply the differences to branch b, and use that one as the new branch b (i don't desperately need all the history), but i am wondering if there is a better way
[00:09] <igc> moldy: see if jelmer or anyone else has a better idea first
[00:10] <igc> moldy: if not, that sounds ok to me
[00:19] <lifeless> moldy: were the branches in the svn repo created by doing 'cp', or by separate imports?
[00:20] <moldy> lifeless: i have no idea :)
[00:20] <moldy> lifeless: hm, now that i thinj about it, probably by "cp", but i cannot vouch for it :)
[00:21] <lifeless> if they were, I would expect bzr-svn to have joined them
[00:21] <lifeless> uhm, I suggest filing a bug on bzr-svn, if they have common ancestry in svn
[00:22] <moldy> hm, they have common history in svn
[00:23] <moldy> i ran bzr-svn on the whole repository
[00:24] <S11001001> is it kosher to use 2a repo format for all new repos if you only care about 1.17+ support?
[00:24] <moldy> but i also changed the layout a bit, so i joined stuff into the branches that had their own svn modules before, maybe that was the problem
[00:34] <lifeless> S11001001: yes, thats fine.
[00:34] <lifeless> 2a is usable [but not ideal] from 1.16 on
[00:34] <lifeless> S11001001: we will be strongly recommending 2.0 and above everywhere
[00:40] <bob2> probably silly question, but was the 2a upgrade issue fixed before trunk switched?
[01:08] <poolie> igc, hi
[01:08] <igc> hi poolie
[01:08] <poolie> so if putting sphinx onto hardy is hard, um
[01:09] <SamB> dangit, bzr help needs some sort of close-match spell checking when the edit distance is just a few characters between the user entry and what they actually wanted help on ...
[01:09] <poolie> SamB: i don't think bzr-guess does this but it would be an easy extension
[01:09] <SamB> say, "help revision-specs" instead of "help revisionspec"
[01:09] <SamB> poolie: heck, I think this is important enough to be in core!
[01:09] <poolie> igc, did it turn out you can't run it from source
[01:10] <igc> poolie: yet to try
[01:10] <SamB> especially for the non-command topics
[01:10] <SamB> which have rather arbitrary names
[01:10] <igc> poolie: I might get to it today
[01:10] <poolie> i just wondered
[01:10] <igc> polie: need to upgrade to 2a first
[01:10] <poolie> the issues lamont mentions may block it running from source too
[01:10] <poolie> in which case we might
[01:10] <igc> poolie: maybe
[01:10] <poolie> hm, i guess we could ask for a karmic chroot there
[01:11] <igc> poolie: let me try from source first
[01:12] <igc> poolie: karmic may be out before they get to it either way :-(
[01:12] <poolie> igc, from recent mail it looks like karmic may not be LTS
[01:13] <igc> poolie: I thought 10.4 was LTS
[01:13] <poolie> you also get into the problem that slightly exotic server hardware may not be supported by newer kernels
[01:13] <poolie> at least i think i recall that happening in going to hardy
[01:13] <poolie> right but karmic is not 10.4
[01:13] <poolie> it will be 9.10
[01:13] <igc> right
[01:14] <SamB> hmm ... my "bzr log" is silly and only looks in the current branch for revisions even when they're in the same repo, it seems :-(
[01:14] <poolie> so the earliest they'll probably want to upgrade the base os there is may 2010
[01:19] <lamont> poolie: it shouldn't be _hard_ to put sphinx in hardy
[01:20] <lamont> it just needs to not be self-build-depending...
[01:20] <lamont> for a round
[01:20] <poolie> i'm not sure what that means
[01:20] <poolie> is it getting rid of the circular dependency?
[01:20] <fullermd> SamB: Well, if they're not in the current branch, it's tough to get the revno...
[01:21] <SamB> bah!
[01:21] <lamont> poolie: I expect that the reason jinja2 build-depends sphinx is for its own docs?  is it possible to strip the sphinx-needs from jinja enough to build and have it work enough to build sphinx enough to build jinja-with-sphinx to build sphinx-with-full-jinja?
[01:21] <SamB> why can't it just skip that?
[01:21] <fullermd> I think the typical answer to things like that is "because your patch for it hasn't been merged'   :p
[01:21] <poolie> lamont: i expect that's true too, and that it is possible
[01:22] <SamB> or at least give a less scary-looking error that explains what went wrong a bit better ...
[01:22] <poolie> but i haven't looked at the source at all
[01:22] <lamont> poolie: it has to be.. it's just a question of how far back in history one has to go
[01:22] <fullermd> (note that the error you get is a NoSuchRevision, but it doesn't come from looking up the rev, it comes from branch.revision_id_to_dotted_revno()
[01:22] <poolie> oh, because it was not circular at the time it originally went into debian or ubuntu?
[01:22] <SamB> of course, I'm on an old build atm because I was hoping to figure out how to look at the changelog ...
[01:22] <poolie> Samb, i agree, file or dupe a bug
[01:22] <lamont> I admit I haven't been watching, but I expect that the decision on next-LTS won't be made until at least the next UDS, so it'll either be 10.04 or 10.10
[01:24] <igc> hi sidnei
[01:25] <sidnei> igc: oi
[01:25] <igc> sidnei: a questions fro you ...
[01:25] <lifeless> circular deps are sadness
[01:25] <sidnei> igc: shoot
[01:25] <igc> can I use/test the buildout stuff on linux
[01:25] <igc> I'm thinking of getting the image right ...
[01:25] <poolie> lifeless: did you see bialix's comments about 'apport's dependencies are so hard on windows'?
[01:26] <igc> then worrying about how the installer does something with it
[01:26] <lifeless> poolie: yes
[01:26] <lamont> poolie: and the real issue is that it needs a file that isn't even delivered by python in hardy... :(
[01:27] <lifeless> jml: poolie: 12 for lunch?
[01:27] <sidnei> igc: uhm. if i recall correctly, you should be able to run bootstrap.py then bin/buildout on linux
[01:27] <sidnei> igc: but after that it invokes a batch file
[01:27] <poolie> lifeless: sure, where?
[01:28] <lifeless> you had two restaurants you wanted to revisit
[01:28] <lifeless> so lets hunt down the second
[01:28] <poolie> wfm, i think you'll like it
[01:28] <sidnei> igc: that won't give you much other than fetching the dependencies though
[01:28] <igc> sidnei: and do you know how it packages python, qt and pyqt?
[01:29] <sidnei> igc: pyqt needs to be installed manually using the .exe installer into your global python interpreter, and so does a few other dependencies.
[01:29] <igc> sidnei: my xp partition is only a few G so I want to do as much work as I can elsewhere
[01:30] <sidnei> igc: and finally it uses py2exe which is basically black magic to me to pull all the dlls and dependent libs into library.zip
[01:30] <igc> sidnei: ah - so the qt stuff ends up in there?
[01:31] <sidnei> igc: i'm pretty confident that it does. haven't paid close attention.
[01:31] <sidnei> igc: the final step is just packaging it up with innosetup
[01:31] <igc> sidnei: and that's the bit I had planned to improve but ...
[01:31] <igc> it seems that's about 10% of the job
[01:32] <sidnei> igc: correct
[01:32] <igc> vs gathering everything, compiling it, etc.
[01:32] <SamB> jelmer: how come bzr-rebase is so outdated?
[01:33] <igc> sidnei: so adding more plugins basically comes down to editing the buildout.cfg file and build-installer.bat.in file right?
[01:33] <sidnei> igc: yes
[01:35] <igc> sidnei: I don't want to install cygwin. I have make installed. Does that sound ok?
[01:35] <sidnei> igc: yup, that's how i have it here
[01:35] <sidnei> igc: i actually install cygwin but don't use bash. i only put c:\cygwin\bin in %PATH%
[01:37] <sidnei> igc: i believe that a different way of achieving what you wanted would be to not use py2exe, but instead build a custom python install
[01:37] <sidnei> igc: i have code for doing that which we could possibly borrow
[01:38] <sidnei> igc: in fact, i think that would make things a lot easier for everyone including people building plugins
[01:38] <igc> bbiab
[01:39] <sidnei> me too. *wink*
[01:40] <jelmer> SamB: outdated in what sense?
[01:46] <jelmer> SamB_XP: outdated in what sense?
[01:50] <lifeless> poolie: so where should I meet thou?
[01:50] <AfC> lifeless: ping? [personal]
[01:54] <lifeless> spm: procedure change:
[01:55] <lifeless> new pqm branches need:
[01:55] <lifeless>  - bzr-core set as reviewer
[01:55] <lifeless>  - bzr-core subscribed to the branch
[01:55] <lifeless> because *reviewers are not notified*
[01:56] <spm> lifeless: oki; will add to docco. I assume the new branch we did last night needs this asap?
[01:56] <lifeless> done it
[01:56] <spm> awesome, ta.
[01:56] <lifeless> for 2.0 and bzr.dev
[01:56] <lifeless> only cause I'm in bzr-core and can thus do it
[01:56] <spm> :-)
[01:57] <spm> so..... what I'm hearing is you've got the tools to do this yourself; therefore our update needs are minimised? :-P
[01:58]  * spm looks forward in great anticipation to the response to that unsubtle troll
[02:01] <poolie> lifeless: i guess here
[02:02] <lifeless> poolie: ok, I'll drift your way
[02:02] <lifeless> jml: ^
[02:18] <jml> lifeless, I just got off the phone :)
[02:18] <jml> poolie, I'll probably be a little later than 12
[02:22] <poolie> np
[02:58] <moldy> bzr does not work directly over ssh, without a bzr server?
[02:59] <spiv> moldy: you can use sftp
[03:00] <spiv> moldy: but having bzr installed on the remote side and using bzr+ssh will be faster.
[03:00] <moldy> spiv: is it enough to have bzr installed, or do i need to have a server running?
[03:01] <spiv> It simply needs to be installed.
[03:01] <moldy> hm, does not seem to work for me
[03:01] <spiv> (And on PATH)
[03:02] <moldy> which bzr versions are compatible?
[03:02] <spiv> Does "ssh yourhost bzr --version" work?
[03:02] <moldy> yes
[03:02] <spiv> Basically all of them.
[03:02] <spiv> What specifically does "not seem to work" mean?
[03:02] <moldy> well, i have 1.15.1 against 0.11.0
[03:02] <spiv> Oh, ok.
[03:03] <moldy> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
[03:03] <spiv> 0.11 is pretty ancient, probably 1.15.1 won't work with that.
[03:03] <moldy> Server does not understand Bazaar network protocol 2, reconnecting.  (Upgrade the server to avoid this.)
[03:03] <moldy> bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: "error\x01Generic bzr smart protocol error: bad request u'bzr request 2'\
[03:03] <spiv> 0.11 was the very first version to have any sort of "bzr serve" support.
[03:03] <spiv> And it was basically just a glorified sftp, you may as well just use sftp :)
[03:03] <moldy> unfortunately, sftp doesn't work either :)
[03:03] <spiv> Oh?
[03:04] <spiv> That's pretty weird.
[03:04] <spiv> The error message is correct though, that upgrading the bzr on the server would fix your problem.
[03:04] <moldy> i think i will look for a backport of a more recent bzr version to debian etch
[03:05] <spiv> It's very unusual for sftp not to work.  Is that an intentional server configuration I wonder?
[03:06] <spiv> (0.11 is almost 3 years old, btw)
[03:06] <moldy> might be that my local bzr is broken, sftp itself works
[03:06] <spiv> What error do you get?
[03:07] <moldy> ah, it seems to be related to the svn plugin
[03:07] <moldy> i'm not sure why it uses that plugin when trying sftp, though
[03:07] <spiv> Ah.  You can try "bzr --no-plugins ..."
[03:10] <poolie> hello spiv
[03:11] <poolie> igc, did you file a bug or talk to someone about packaging explorer on ubuntu?
[03:11] <poolie> it'd be nice to have it
[03:12] <moldy> spm: thanks for your help. with a recent bzr on the remote side, it works
[03:12] <spiv> moldy: great!
[03:12] <spiv> poolie: good afternoon
[03:13] <poolie> oh so it is
[03:13] <poolie> how's stuff?
[03:13] <spiv> Well, my local repo passed "bzr check" so now it's in the throes of upgrade --2a.
[03:14] <xnox> Can I unshelve a change from branch a/ onto branch b/
[03:14] <xnox> if it was shelved inside branch a/
[03:14] <spiv> xnox: unshelve in a/ and then do "bzr merge --uncommitted ../a/" in b/ is probably simplest.
[03:15] <spiv> Otherwise all I can think of is copying the .bzr/checkout/shelf directory.
[03:16] <poolie> would be nice if you could
[03:17] <spiv> poolie: and I'm wondering what happened to my merge request yesterday, and wondering what the most painless way to resend it is when I'm in the middle of an upgrade...
[03:18] <xnox> spiv: thanks
[03:18] <thumper> whoever came up with merge --uncommitted was a genius
[03:22] <igc> poolie: it was with james_w I believe - I can't recall raising a bug, only emailing
[03:22] <igc> thumper: yes, I use it a lot (and no it wasn't me)
[04:10] <xnox> One more questions =) I've started to use bzr-svn to push to an svn repo. Is there a way to remember push login & password?
[04:47] <poolie> xnox: in auth.conf i think?
[04:48] <xnox> poolie: ok thanks I'll look into that
[05:13] <SamB> ... is there a way to commit in the style of "darcs record", which has a slightly better interface than "bzr shelve" to select what to inclue in the patch?
[05:13] <S11001001> SamB: interactive plugin
[05:14] <SamB> why does searchiong for "bzr darcs commit" (sans quotes) not seem to help me find that?
[05:14] <S11001001> branch http://bazaar.launchpad.net/~asabil/bzr-interactive/trunk as interactive into your plugins directory
[05:14] <SamB> S11001001: I know how to install a plugin
[05:14] <S11001001> just in case :)
[05:14] <SamB> and if I was having trouble finding it now that you told me the name, I would have asked ;-)
[05:16]  * igc lunch
[05:16] <S11001001> take care, because it doesn't work in dumb terminals (like emacs shell)
[05:17] <SamB> that's fine
[05:17] <SamB> I wasn't really going to use it there
[05:17] <SamB> and I don't think darcs really likes that either ;-)
[05:17] <S11001001> I have used it for some time now with darcs just fine
[05:17] <S11001001> also, the hunk finder is more eager in bzr-interactive
[05:18] <S11001001> whereas I think if hunks are separated by 1 line of context in darcs they will be treated separately, this is not so in interactive
[05:18] <SamB> oh, really?
[05:18] <SamB> doesn't the red highlighting confuse emacs?
[05:18] <SamB> S11001001: hmm, I don't remember darcs being that smart
[05:18] <S11001001> what highlighting?
[05:19] <SamB> well, usually of either things that darcs didn't get (non-ascii bytes) or a $ to mark the end of a line with trailing whitespace
[05:19] <SamB> (instead of the actual byte, it prints a red escape sequence)
[05:20] <S11001001> hmm, possibly I've never recorded any such things
[05:20] <SamB> (really annoying when you're writing programs using UTF-8 operators!)
[05:21] <SamB> well, I guess it would at worst look just slightly more horrible and less eyecatching than in a real terminal ;-)
[05:21] <SamB> ... and of course you can always use the Emacs terminal *emulator*
[05:21] <S11001001> icky, I like moving around my shell history like a text buffer
[05:21] <SamB> it can't do that?
[05:21] <SamB> aww :-(
[05:22] <SamB> well, I guess you'd have to switch modes first if it could
[05:22] <SamB> I mean, toggle something
[05:22] <SamB> to change the key bindings
[05:22] <SamB> so that they wouldn't go to the app
[05:25] <spiv> Less than 500 revisions left to upgrade.  Oof.
[05:26]  * SamB wonders how to get emacs to describe a keymap in an intelligable manner -- wishes it had more types :-(
[05:29] <SamB> S11001001: hmm, needs abit of work ...
[05:30] <S11001001> the developer is open to bundles :)
[05:30] <SamB> is it you?
[05:30] <SamB> anyway, was just pondering it ;-)
[05:30] <S11001001> not at all, I merely contributed -F support
[05:31] <SamB> ah
[05:31] <SamB> what's that for?
[05:32] <S11001001> it's supported by built-in commit, just was broken in the wrapper commit that interactive provides
[05:32] <SamB> ah
[05:32] <SamB> is that the one that takes the commit message from a file?
[05:32] <S11001001> I name my log files ++log in honor of arch
[05:33] <SamB> you ... honor ... arch ?!?  :-(
[05:34] <S11001001> I liked arch, kept using it until about the time bazaar-ng 1.5 was released
[05:36] <spiv> S11001001: and you call temp files ,,foo? :)
[05:36] <SamB> I can't like arch
[05:36] <S11001001> just 1 , actually
[05:36] <SamB> it has too many damn pointless concepts!
[05:36] <spiv> Heh.
[05:36] <S11001001> , is garbage that tla promises not to delete
[05:36] <SamB> or, at least, too many damn pointless components in a name
[05:37] <spiv> S11001001: <gollum>my precioussss</gollum>
[05:37] <S11001001> well I don't name my log files ++log instead of<EMAIL_ADDRESS>for nothing
[05:41] <SamB> I guess the thing is that I never tried arch until I was already hooked on darcs for the time being
[05:41] <SamB> now I'm not so much hooked on darcs, but still use it as one of my VCS yardsticks
[05:42] <S11001001> I don't think darcs existed back in 2004
[05:43] <SamB> not sure
[05:43] <SamB> I don't remember exactly when #haskell got me hooked
[05:43] <S11001001> hmm, actually it seems to have, but I didn't hear about it until 2007 anyway
[05:44] <SamB> yeah, I was pretty sure it was older than that ;-)
[05:44] <S11001001> it was the community standard for common lisp projects until recently
[05:47] <SamB> darcs?
[05:47] <SamB> or arch?
[05:48] <S11001001> darcs
[05:49] <SamB> did they start using git too or something?
[05:49] <SamB> or git, bzr. & hg too?
[05:49] <SamB> oops, s/./,/
[05:49] <S11001001> git, hg, and svn have all insinuated themselves
[05:49] <SamB> what the?
[05:49] <SamB> why svn?
[05:49] <SamB> ... is it because of google code?
[05:50] <S11001001> bknr.net svn is the new host for Edi Weitz's popular libraries, and clozure (an implementation increasing in popularity) also uses svn for source and binary distribution
[05:50] <SamB> oh, is clozure JVM-based?
[05:50] <S11001001> you're thinking of clojure :)
[05:50] <SamB> oh.
[05:50] <SamB> okay.
[05:51] <SamB> I was just trying to find an excuse for brain-deadedness
[05:51] <SamB> hmm ... how would I use emacs to search for a line that has $(HIDE) on it and isn't immediately preceded by one with $(SHOW) in it?
[05:52] <S11001001> Clozure was once OpenMCL, but MCL went and changed its license, and Clozure added GNU/Linux and Windows support, then x64 and x86
[05:53] <S11001001> surprisingly, porting to platforms other than OS X/PPC was a surefire way to increase popularity
[05:53] <SamB> no duh
[05:54] <SamB> especially with the PPC macs being discontinued
[05:54] <SamB> hmm, so they ... added support for PPC Windows before support for x86 anything?
[05:55] <SamB> was there even an MS Windows for PPC?
[05:55] <S11001001> it's a little weird, they added linux/x64, then windows/x64, then similarly for the x86
[05:56] <S11001001> IIRC, porting to the register-starved x86 was harder than amd64 support
[05:56] <mneptok> SamB: yes
[05:56] <SamB> ... I mean, I know arty in #reactos was working on porting that to PPC, but I forgot about whether there was an MS predecessor ;-)
[05:56] <mneptok> SamB: NT 3.5 was released for PPC. there may have been others.
[05:57] <mneptok> anyhow, such discussions are not really on-topic for #bzr
[05:58] <SamB> mneptok: yeah, but, was anyone asking a bzr question?
[05:58] <SamB> oh, I've got one!
[05:58] <mneptok> SamB: that's not really the point.
[05:58] <SamB> does bzr work on NT 3.5 PPC?
[05:59] <mneptok> SamB: walk into a police station at 3am and do a striptease. when they tell you that it's not a strip club, ask "well, was anyone being arrested?!"
[05:59] <SamB> mneptok: that's a bit different
[05:59] <SamB> I think they'd be arresting you for indecent exposure
[06:00] <mneptok> SamB: so please don't risk the same here.
[06:00] <SamB> or because they didn't want to see your dick
[06:01] <mneptok> SamB: such language *definitely* is not welcome in #bzr
[06:01] <SamB> oh, sorry.
[06:01] <SamB> should I have said "penis"?
[06:02] <mneptok> you should probably keep your mouth shut and be thought a fool, rather than open it and remove all doubt.
[06:04] <SamB> fine, fine, #haskell-blah, here I come ...
[06:04] <SamB> I should be fine there as long as I remember not to talk about Haskell ;-)
[06:24] <spiv> jml: regarding your comment about the puller from about 7:30pm yesterday: bug #424136
[06:24] <jml> oh yes?
[06:25] <spiv> jml: the problem appears to be that the assumption that "Branch.open" succeeds in tha face of rich-root mismatch in stacked-on/stackee is wrong.
[06:25]  * jml tries to parse that for the third time
[06:25] <spiv> jml: stacked-on: just changed from 1.9->2a
[06:26] <spiv> jml: my branch: just changed from 1.9->2a the hosted area, still 1.9 in the mirrored area
[06:27] <spiv> jml: puller: tries Branch.open(mirrored-my-branch), fails because 1.9 can't stack on 2a because 1.9 and 2a have different rich-root support.
[06:27] <spiv> jml: puller therefore gives an error rather than propagating the upgrade that would fix the error.
[06:27] <jml> spiv, I see.
[06:28] <jml> spiv, so we ought to catch those errors and upgrade as if we detected a format change?
[06:28] <spiv> jml: or open in a way that doesn't fail if stacking won't work.
[06:28] <jml> spiv, you're bringing back bad memories
[06:28] <jml> spiv, is that even possible?
[06:28] <spiv> e.g. BzrDir.open(...).open_repository()
[06:28] <jml> hmm
[06:29] <spiv> (because stacking is configured by the branch)
[06:29] <spiv> Or perhaps BzrDir.open(...).open_branch(ignore_fallbacks=True).
[06:29] <jml> perhaps.
[06:29] <spiv> Or potentially just catch the relevant exception.
[06:29] <jml> catching the exception seems like the most robust to me.
[06:30] <spiv> bzrlib.errors.IncompatibleRepositories I believe.
[06:31] <spiv> Well, not making inspecting the format of object A dependent on details like "A's config says stack on B, but B is not compatible" seems more robust to me :)
[06:31] <jml> spiv, yeah, fix bzr
[06:32] <jml> spiv, in the meantime the integration team will integrate :)
[06:32] <spiv> But I can understand that having a separate "check formats" and "now open it for actual use" phases might be awkward in your code.
[06:32] <jml> spiv, we already do something like that... icbw
[06:32] <spiv> bzr is working fine: it's refusing to do Branch.open because it can't be opened.
[06:33]  * jml actually dials up the code
[06:33] <spiv> The problem is your code says "give me a full branch object with fallbacks and everything" when (at this point) it just wants "give me the branch and repository formats"
[06:34] <jml> and what's the bzr API for that?
[06:35] <mwhudson> pretty sure there isn't one, or at least wasn't back when we wrote this
[06:37] <spiv> the_bzrdir.find_branch_format() / RepositoryFormat.find_format(the_bzrdir)
[06:38] <spiv> Or I suppose you could use BranchFormat.find_format(the_bzrdir) for consistency.
[06:49] <mtaylor> lifeless: I find the motu process/system quite frustrating
[06:50] <mtaylor> lifeless: not that you can do anything about it - I'm just complaining :)
[06:55] <jml> spiv, how do they interact with RemoteRepository
[06:55] <jml> et al
[07:00] <spiv> jml: IIRC you'd probably get back a RemoteRepository, still.
[07:01] <spiv> jml: anyway, catching IncompatibleRepositories would work fine for this case, and would probably be the most minimal change.
[07:01] <spiv> I don't really mind what you do so long as it works ;)
[07:08] <igc> spiv: can I request a 30 second review ...
[07:08] <igc> spiv: https://code.edge.launchpad.net/~ian-clatworthy/bzr/422533/+merge/10976
[07:09] <bialix> hello igc
[07:13] <vila> hi all
[07:13] <spiv> igc: heh
[07:14] <spiv> igc: 30 seconds was perhaps pessimistic :)
[07:14] <vila> igc: Can I request a 30 secs test for that one-liner since you obviously found a hole in the coverage ? :)
[07:15] <vila> igc: at least don't close the bug until you had that test...
[07:17] <igc> vila: it's a formatting issue of very low priority - I don't feel a test is necessary sorry
[07:19] <vila> it's untested code for which you had the test almost written since you encounter it, anybody else will spend more time on it
[07:20] <spiv> vila: I don't think a test is worth it.
[07:22] <spiv> It would be a test for the contents an error string; it's unlikely to regress, but adding a test would likely add needless friction if anyone *does* tweak the wording.
[07:24] <spiv> It's a different case I feel to what we test in test_errors (which are generally worthwhile tests).
[07:30] <vila> A test about an invalid property value is not worth it ?
[07:30] <vila> right, I'm still dreaming, let's reboot
[07:30] <vila> hi all, have a good day
[07:30] <igc> vila: w.r.t. bzr-upload, what version should I include in the Windows installer?
[07:30] <igc> vila: and in terms of help for it, all you need to do is ...
[07:31] <igc> add whatever text makes sense to the module docstring
[07:31] <igc> and the plugin guide generator will find it
[07:31] <vila> igc: thanks ! Time to move the README there
[07:31] <igc> vila: the Plugin Guide has one chapter per plugin
[07:32] <igc> the first section for each is the plugin help, then one section per command provided by the plugin
[07:32] <vila> igc: I intend to release 1.0 before bzr-2.0 so I'd like to have 1.0 there
[07:33] <igc> vila: if required, I guess plugins could have extra help topics, e.g. upload-tips
[07:33] <igc> vila: but if they do, I don't currently go looking for them ..,
[07:33] <igc> and I'm not sure how hard or otherwise it would be
[07:33] <vila> module doc string if perfect
[07:34] <vila> at least to address the problem of giving more exposure to the doc :)
[07:34] <igc> so for now, it's in the plugin top-level help or it's in help on a plugin command (or it doesn't make it into the Plugin Guide)
[08:20] <lifeless> mtaylor: tell me more later :)
[08:21] <mtaylor> lifeless: I will :)
[08:22] <jml> Conflict: can't delete lib/lazr because it is not empty.  Not deleting.
[08:22] <jml> 1 conflicts encountered.
[08:22] <jml> rm -rf lib/lazr
[08:22] <jml> bzr resolve lib/lazr
[08:22] <jml> (guess how many times I've had to do that this week!)
[08:25] <lifeless> poolie: I've done the bug status tweak I was mentioning earlier :)
[08:25]  * lifeless waves ciao
[08:25] <jml> lifeless, ciao
[08:43]  * quicksilver tries running bzr pull over GPRS. should be fun.
[08:44]  * quicksilver reflects that bzr+ssh would have been a better choice for a high latency link.
[08:58] <NET||abuse> hey guys, trying to use the upload command here,,
[08:58] <NET||abuse> the documentation is a little vague,
[08:58] <NET||abuse> however i've done bzr help upload.
[08:58] <vila> NET||abuse: did you read the README ?
[08:58] <NET||abuse> now what do i do to point it at a location?
[08:58] <NET||abuse> oh, it's in bzr by default on jaunty it looks like.
[08:58] <NET||abuse> didn't load the plugin files into my ~/.bazzar
[09:01]  * igc dinner
[09:02] <vila> NET||abuse: http://paste.ubuntu.com/264826/
[09:03] <NET||abuse> vila, yeh, i pulled down the source into my projects folder, have a copy of it now and am reading the README
[09:03] <NET||abuse> much appreciated,
[09:03] <NET||abuse> just trying to figure out,
[09:03] <NET||abuse> how do i upload a subdirectory of the main branch?
[09:04] <NET||abuse> i have other configurations for local testing and things in directories here, so i was just going to upload parts
[09:04] <NET||abuse> and i have an extra directory layer that isn't on the live server
[09:04] <vila> NET||abuse: You can't do that yet
[09:05] <NET||abuse> means i should be able to just upload the src/server directory, it holds my www application system and etc directories.
[09:05] <NET||abuse> arrg
[09:05] <vila> You can only upload a full branch working tree
[09:05] <NET||abuse> that's annoying.
[09:05] <NET||abuse> that's pretty much useless then.
[09:05] <NET||abuse> just have to do big scp transfers then
[09:05] <vila> there are various ways to address it, none available yet
[09:05] <NET||abuse> overwriting the whole site
[09:06] <vila> one way is to create a dedicated branch as a fork of your trunk and delete all unwanted stuff there
[09:06] <vila> you can then merge in that reduced branch and upload that
[09:08] <vila> NET||abuse: filing a bug report explaining your use case can only help defining the feature
[09:09] <vila> NET||abuse: or add your case description in bug #212677
[09:12] <NET||abuse> vila, ok, i'll add some description to that bug, bookmarked it.
[09:20] <vila> poolie, lifeless, spiv, igc: data point: I upgradeb ~200 branches in a shared repo over NFS without trouble (~400MB of data processed there)
[09:20] <vila> upgraded even
[09:21] <vila> funnily enough, the first 'bzr info' after that whined about a NFS stale on a FoRmAt file, once and never again :)
[09:29] <poolie> hello vila
[09:29] <poolie> vila, i wonder if they had a flaky network card or switch or something
[09:30] <vila> something weirder than that since the file disappear after several days, NFS is excluded as cause (IMHO)
[10:05] <Lo-lan-do> Hi all
[10:06] <Lo-lan-do> Is anyone in particular linked to Loggerhead?
[10:07] <Lo-lan-do> I guess it's jelmer again :-)
[10:09] <Lo-lan-do> jelmer: Any plans on uploading a recent Loggerhead to Debian?
[10:11] <poolie> Lo-lan-do: or mwh, but he's not a dd
[10:11] <Lo-lan-do> I'm going to need it for a client. I can do the required work (updating the packages and providing backports for Lenny) if needed, I'd just like to know in advance so it doesn't come as a surprise to them when I bill for my time.
[10:12] <Lo-lan-do> This could be said to be an offer for help, but I don't want to step on anyone's toes.
[10:21] <jelmer> Lo-lan-do: Hi!
[10:22] <jelmer> Lo-lan-do: You're more than welcome to help out with the loggerhead packaging
[10:22] <jml> g'night poolie
[10:22] <poolie> night!
[10:22] <jelmer> Lo-lan-do: I was going to update your patch to fix the use of libyui-js, but have been away since debconf9 so haven't had much time for that
[10:25] <poolie> nothing like a good night's sleep :)
[10:25] <jelmer> (-:
[10:29] <james_w> I put the latest loggerhead release in karmic the other day
[10:29] <james_w> it's on bzr.debian.org
[10:33] <jelmer> ah, great
[10:35] <AfC> Has there been a 2.0-rc2 release as yet?
[10:35]  * AfC is scared about the upgrade bug, and 2.0-rc1 is what Gentoo is shipping as ~arch right now
[10:38] <vila> AfC: not yet
[10:53] <luks> why do they ship release candidates?
[10:57] <AfC> luks: they never used to package Bazaar's rc's, but I guess someone was listening to the fact that the lead up to 2.0 is a bit different.
[10:58] <AfC> After all, we want people testing.
[11:01] <luks> yeah, but making ever Gentoo user a tester is probably not such a good idea :)
[11:02] <luks> +y
[11:09] <jelmer> james_w: did you manage to keep the yui stuff in loggerhead working?
[11:10] <james_w> was the patch not complete?
[11:12] <jelmer> james_w: it was complete but last time I attempted to merge a new upstream I had trouble keeping the yui-js patch applied and loggerhead working
[11:15] <james_w> hmm
[11:15] <james_w> there were no conflicts, but I don't understand why
[11:38] <lifeless> igc: something going south on this import :(
[11:38] <lifeless> 10:10:27 64000/133780 commits processed at 263/minute (:64000)
[11:38] <lifeless> 11:19:34 65000/133780 commits processed at 208/minute (:65000)
[11:38] <lifeless> still working on the next 1000
[11:38] <lifeless>  4847 robertc   20   0 6153m 4.8g 1208 D    0 83.8 375:11.54 python
[11:38] <lifeless>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
[12:05] <vila> bialix, bialix, where are you :-/
[12:06] <vila> naoki: ping
[12:06] <vila> naoki: You're the one I need ! revno 171 broke the test farm installer build
[12:07] <vila> naoki: revno 171 of tortoisebzr I meant
[12:07] <vila> naoki: http://paste.ubuntu.com/264900/
[12:25] <Lo-lan-do> jelmer: Okay, thanks.  I'll keep in touch however things work out.
[12:54] <jelmer> hmm, bzr-stats seems to think that lifeless, jam, igc and vila are the same person
[12:56] <vila> jelmer: hehe, I mentioned that some weeks ago :)
[12:57] <vila> I don't know when it occured, I wonder if --authors may have tricked it but that should have occurred months ago when we landed bbc
[12:58] <Lo-lan-do> It's all a cabal anyway.
[12:58] <vila> jelmer: Where did you run it ?
[13:02] <jelmer> vila: bzr.dev
[13:03] <vila> wow, just ran it on an upgraded bzr.dev, snappy :)
[13:04] <vila> jelmer: so, that's really weird becase jam and vila survive but steal from each other anyway :D
[13:04] <vila> lifeless and igc disappear completely though, shame
[13:05] <vila> given only those four are involved, I'd say --author tricked bzr-stats, 90% sure :)
[13:08] <jelmer> I'll have a look at it when I find some time
[13:08] <jelmer> Yeah, 2a is teh awesome
[13:09] <jelmer> I know I'm repeating myself, but I'm really looking forward to 2.0 !
[13:09] <vila> :)
[13:18] <jelmer> lifeless: how would a test have multiple statusses?
[13:19] <bialix> vila: are you summon me up?
[13:20] <vila> wow, magic bialix ! How did you know ? 8-)
[13:21] <vila> I wanted to tell you to tell naoki about: http://paste.ubuntu.com/264900/, but I'm sure you already know that, did it, and I've just to pull tbzr again for the fix...
[13:23] <mortehu> I get this on commit: bzr: ERROR: Cannot commit to branch BzrBranch6('file:///me/app/'). It is bound to BzrBranch6('file:///other/app/'), which is bound to file:///other/app/.
[13:23] <vila> mortehu: no more than one level of binding
[13:24] <mortehu> I see.  I'll have to read up on how this works.
[13:24] <bialix> vila: ?
[13:25] <vila> bialix: yes ?
[13:25] <vila> bialix: I wanted to tell you to tell naoki about: http://paste.ubuntu.com/264900/, but I'm sure you already know that, did it, and I've just to pull tbzr again for the fix...
[13:25] <bialix> I don't understand
[13:25] <bialix> https://bugs.launchpad.net/tortoisebzr/
[13:25] <bialix> you need this I guess
[13:26] <vila> k
[13:27] <mortehu> vila: You did notice that the last two paths in the error message were identical?
[13:27] <vila> mortehu: no
[13:27] <vila> that;s weird
[13:30] <bialix> vila: naoki said something about removing some dependencies from tbzr build so he can build with other compiler or sdk
[13:30] <bialix> vila: so maybe there is difference in build environment between him and your slave
[13:30] <vila> I filed a bug
[13:31] <vila> bu g#424303
[13:31] <vila> bug #424303
[13:33] <bialix> ok
[13:35] <vila> mortehu: what is your setup ? Can you issue 'bzr info' in each branch involved /
[13:35] <vila> ?
[13:36] <mortehu> Checkout (format: pack-0.92) Location: branch root
[13:37] <vila> mortehu: don't spam the channel, use a paste service instead and copy the whole output
[13:37] <mortehu> That was the whole output.
[13:38] <vila> >-/
[13:38] <vila> bzr version
[13:38] <mortehu> 1.5
[13:38] <vila> ouch, what os are you using ?
[13:38] <mortehu> It's some other dude's repository (I normally use something else).  He went to sleep. :)
[13:39] <mortehu> Debian
[13:40] <vila> 1.5 is... more than year old... but I'm surprised we can't get more info... try 'bzr info -v' ?
[13:40] <mortehu> I'll just put the files in his working copy and have him commit in the morning.
[13:41] <mortehu> Thanks for your time, by the way.
[13:41] <vila> mmmm, branch6... did we even support that in 1.5 ?
[13:42] <vila> yes we did
[14:51] <mthaddon> not sure if anyone's around who can help here, but I'm testing the upgrade of the bzr PQM instance and running into problems because the existing format is pack-0.92 but current lp:pqm is 1.14-rich-root or 1.9-rich-root - can I convert the current branch to the right format?
[14:54] <jelmer> mthaddon: I think so
[14:54] <jelmer> mthaddon: At least, can't think of any reason why that would be a bad idea
[14:55] <mthaddon> jelmer: so how would I do that? bzr upgrade --1.14-rich-root ?
[14:55] <jelmer> mthaddon: yep
[14:56]  * mthaddon gives it a go
[14:56] <mthaddon> jelmer: cool, worked a treat, thx
[14:59] <jam> jelmer: that would be a rather prolific person, then
[15:00] <jam> jelmer: Unittest doesn't declare that you can't call both addError and addSuccess from the same test
[15:00] <jam> I've seen it getting a successful run, and then an error during cleanup
[15:00] <jam> or even 2 errors :)
[15:00] <jam> morning vila
[15:01] <vila> morning jam
[15:26] <Kobaz> bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was         made: 'chroot-163675084:///project/base/'.")
[15:26] <Kobaz> i upgraded bzr on my server and now i get that
[15:26] <Kobaz> i'm using bzr+https://
[15:26] <Kobaz> with the bzr-smart thingee
[15:34] <jelmer> did the submit branch for bzr change recently?
[15:34] <jam> Kobaz: known bug, I'll try to track it down for you
[15:34] <jam> jelmer: yes
[15:34] <jam> it is now on LP
[15:35] <Kobaz> jam: yeah i found the bug, it poped up in 1.16
[15:35] <jelmer> Should I just be using lp:bzr?
[15:35] <jam> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
[15:35] <jelmer> jam: thanks!
[15:35] <Kobaz> supposidly was fixed in 1.17
[15:35] <Kobaz> but it's still happening in 1.17
[15:35] <Kobaz> https://bugs.launchpad.net/bzr/+bug/400535
[15:35] <Kobaz> looks like a regression
[15:35] <jam> Kobaz: actually 348308
[15:35] <jam> bug 348308
[15:35] <jam> there is a workaround in that bug report
[15:37] <Kobaz> hm
[15:38] <Kobaz> is there anything obviously bad about using the workaround?
[15:38] <Kobaz> or should i stick with what i've been using: 1.13
[15:39] <jam> Kobaz: generally I would recommend newer bzr's for a variety of reasons
[15:39] <jam> I don't think the workaround is that bad
[15:39] <jam> we really need to get something like that into a real fix
[15:40] <Kobaz> what's major between 1.13 and 1.17?
[15:41] <jam> Kobaz: significantly better streaming + stacking support, support for the 2a format repository which is the default in 2.0 (to be released in the next week or two)
[15:41] <jam> I can point you to NEWS if you want details
[15:42] <Kobaz> k sure
[15:42] <Kobaz> hmm
[15:43] <jam> Kobaz: http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html
[15:43] <Kobaz> okay, the workaround appears to be working
[15:44] <rockstar> jam, hi
[15:44] <jam> hey rockstar
[15:44] <rockstar> jam, I seem to have a brokenness in my tarmac trunk that is preventing me from merging a branch.
[15:45] <rockstar> (I originally thought it was a tarmac bug, but bzr reports the same error, hiding the spectacular traceback)
[15:46] <rockstar> jam, pastebin -> https://pastebin.canonical.com/21836/
[15:46] <rockstar> Shoot, that probably should have gone to p.u.c
[15:46] <jam> rockstar: we use p.c.c fairly often here
[15:47]  * rockstar is still getting used to working on Free Software every day.
[15:48] <jam> rockstar: so I *think* that xml 5 is non-rich-root
[15:49] <jam> which means it shouldn't be existing in your rich-root format repo
[15:49] <jam> trying to do 'bzr pull' I'm getting the same error
[15:49] <rockstar> jam, target branch for merge is 2a
[15:50] <rockstar> jam, also, it's possible that your branch is pre-upgrade, so pulling in gets the same error.
[15:50] <jam> that isn't what I see here: https://code.edge.launchpad.net/~rockstar/tarmac/main
[15:50] <rockstar> jam, chk inventories == 2a, right?
[15:50] <jam> rockstar: yes
[15:50] <rockstar> abentley, ^^
[15:50] <jam> ah...
[15:51] <jam> Development repository format
[15:51] <jam> which would be... --dev6 or so
[15:51] <jam> certainly something weird going on...
[15:51] <jam> I wonder if you merged a broken bundle but had it successfully merge
[15:52] <rockstar> How do I find that out?
[15:52] <abentley> rockstar: looking...
[15:52] <jam> rockstar: I'm trying to lftp mirror it to check
[15:52] <rockstar> abentley, for background, it looks like tarmac trunk is broken.
[15:52] <jam> also, there should be 0 xml inventories in chk inventory land
[15:53] <rockstar> jam, I thought I remembered you talking about that at AllHands.
[15:54] <jam> rockstar: downloading now
[15:55] <abentley> jam: if you need an exact mirror, you can use "hitchhiker mirror . $LOCAL_PATH"
[15:56] <jam> abentley: thanks
[15:56] <jam> so... once I did the mirror using lftp, it doesn't seem broken on this end... :(
[15:56] <jam> hm... I wonder about bzr 1.17 on lp versus bzr.dev locally
[15:57] <jam> ah, or cross-format issues
[15:57] <jam> checking a few things
[15:58] <jam> rockstar: so your trunk is in --dev6-rich-root and not --2a
[15:58] <jam> which might be a problm
[15:58] <jam> I'm guessing bzr 1.17 is trying to send the revisions using the generic streaming code
[15:58] <jam> which was broken until recently fixed (prob bzr 1.18 required)
[15:58] <rockstar> Hm, how'd that happen?  I specified --2a on the upgrade.
[15:58] <jam> rockstar: bzr info sftp://bazaar.launchpad.net/~rockstar/tarmac/main/
[15:59] <jam> Repository branch (format: development6-rich-root)
[15:59] <rockstar> :/
[15:59] <jam> so 1.17 is probably trying to cross-format stream by casting to XML inventories, and newer bzr's don't like it
[15:59] <jam> and they shouldn't, because xml5 wasn't actually compatible with --dev6, we just didn't realize it in time
[16:00] <jam> rockstar: can you do a similar 'bzr info' check?
[16:00] <jam> I'm wondering about a problem between the hosted side
[16:00] <jam> and the mirrored side
[16:00] <jam> as I'm pretty sure *my* sftp access gives me the mirror
[16:00] <rockstar> repository: Development repository format - rich roots, group compression and chk inventories
[16:00] <jam> rockstar: that would be --dev6
[16:00] <jam> so my suggesstion...
[16:00] <jam> 'bzr upgrade --2a'
[16:01] <jam> possibly prefixed with
[16:01] <jam> hitchhiker lp:tarmac rmtree backup.bzr
[16:02] <rockstar> Also, if I upgrade my branch locally, and push, the pushed version won't get upgraded, so I need to rmtree .bzr as well, right?
[16:02] <jam> rockstar: when you push, we preserve
[16:03] <jam> I was actually meaning "bzr upgrade --2a lp:tarmac"
[16:03] <jam> so upgrade the remote
[16:03] <jam> but yeah, you could do it the other way as well
[16:03] <jam> bzr push --use-existing, etc.
[16:03] <rockstar> Okay, great.
[16:05] <nealmcb> Sometimes I clone an individual file in a project and then it evolves on its own.  is there any way to track that in bzr?
[16:06] <nealmcb> e.g. so I could go to the clone, ask for a history, and find out that earlier history was in the file it was cloned from?
[16:08] <rockstar> nealmcb, how are you cloning the individual file?
[16:08] <awilkins> nealmcb: No, Bazaar has no model for copying files as yet
[16:08] <nealmcb> rockstar: now I 'clone it' with cp....
[16:08] <nealmcb> awilkins: do you know of others that do?
[16:09] <nealmcb> not a big deal, but I like meta information :)
[16:09] <awilkins> Subversion will let you do it. I don't know about Mercurial or git, but I suspect git might by dint of the way it works internally
[16:09] <luks> svn does :)
[16:10] <nealmcb> thanks
[16:14] <rockstar> jam, I just did an upgrade and a fresh branch, and I still get: Development repository format - rich roots, group compression and chk inventories
[16:14] <michaelforrest> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'ProgressBarStack'
[16:15] <rockstar> jam, this is a new shared repo as well, created with bzr init-repo --2a
[16:15] <vila> jam: hurrah ! #412930 approved :-D
[16:15] <vila> michaelforrest: out-of-date bzr-gtk plugin ?
[16:15] <bialix> vila: oho
[16:15] <jam> rockstar: unfortunately it looks like RepositoryFormat2a doesn't have its own get_format_string
[16:15] <rockstar> jam, but it merges this time...  O_o
[16:16] <jam> so it is re-using the old one
[16:16] <rockstar> jam, is that a bug?
[16:16] <bialix> vila: can you kick the build of tbzr as of revno.171?
[16:16] <jam> sorry, it is get_format_description( that we need
[16:16] <jam> anyway, yeah, I'm reporting it as a bug
[16:16] <jam> should be easy to fix
[16:16] <vila> bialix: kicked
[16:16] <bialix> vila: I think revno.172 introduced that problem with build
[16:17] <vila> ha 171, no, I don't have that level of detail, I thought it wsa a new revision, sorry
[16:17] <michaelforrest> hurray! thanks vila.
[16:18] <vila> I used qlog and searched for the last revision that modified the file and got the revision I indicated
[16:19] <bialix> vila: in revno 172 naoki removed definition of ARGB typedef, I think this is root of problem
[16:19] <vila> bialix: ohh, I see what you mean,
[16:19] <vila> I just run qlog again
[16:20] <vila> bialix: I think you're right but the way the build works today, I can only use the tip of the branch
[16:21] <bialix> well, I'm not sure it will be good idea to commit there just to check this idea
[16:21] <vila> let's wait for naoki input then
[16:23] <bialix> vila: oki
[16:24] <bialix> what is "square dancing"?
[16:24] <bialix> emmajane: ^
[16:24] <vila> bialix: not sure, I think it north american folk dance :)
[16:25] <vila> bialix: not sure, I think it's a north american folk dance :)
[16:25] <emmajane> vila, aye :)
[16:25] <emmajane> bialix, google for "square dance tutorials" :)
[16:26] <vila> emmajane: clicking images for that search gives.... suprising results :)
[16:26] <emmajane> vila, lots of poofy skirts?
[16:28] <vila> not exactly... nothing wrong either, just not really related
[16:28] <emmajane> heh
[16:28] <emmajane> maybe google.ca gives different results.
[16:29] <bialix> not sure about google results.
[16:29] <bialix> it's a dancing on the streets?
[16:30] <abentley> bialix: The "square" means that people are arranged in a square, facing each other.  It doesn't refer to city squares.
[16:30] <emmajane> bialix, did you look at the slides?
[16:30] <vila> argh, grrr, google.fr !  I can go to localized version when *I* want thank you very much
[16:30] <emmajane> bialix, there are actually pictures and links in the slides.
[16:30] <bialix> which slides?
[16:30] <emmajane> bialix, that I dented
[16:30] <emmajane> bialix, I assume that's what you're referring to?
[16:31] <bialix> I'm not sure
[16:31] <awilkins> Bah, being back at work sucks
[16:31] <vila> awilkins: go back to vacations
[16:31] <awilkins> Just got my reminder to do my pointless weekly blog
[16:31] <bialix> ok, nm
[16:32] <awilkins> My manager wants me to set up 15 user profiles that take 10 minutes each and I'll also have to badger people for their passwords to do it. Which is silly.
[16:32] <awilkins> And now i'll stop whining
[16:33]  * emmajane blinks.
[16:38] <jam> awilkins: script it :)
[16:39] <jam> make sure the script includes a poorly written email asking users for their passwords
[16:39] <vila> jam: ROTFL
[16:39] <awilkins> jam: It's a fricking GUI :-(  I have the sources :-)  They are horrible :-(
[16:39] <vila> go directly to jail don't get the 20.000 FF :)
[16:40] <awilkins> Freedom Fries? I'd be one FF if I ate 20,000 Freedom Fries :-p
[16:41] <Lo-lan-do> FusionForge!
[16:41] <vila> awilkins: close but no cigar :) Very close: French Francs, I didn't play monopoly since more than... the time we switch to Euro :)
[16:42] <Lo-lan-do> (Note that FusionForge now supports Bazaar, although the pluginisn't quite complete yet)
[16:42]  * awilkins knew it was French Francs, which is why the joke about Freedom Fries was funny. ish.
[16:42] <Lo-lan-do> (But it will be soonish, see above for my reasons)
[16:42] <jelmer> Lo-lan-do: w00t!
[16:42] <jelmer> Lo-lan-do: Any idea when that sort of stuff would end up on alioth?
[16:43] <Lo-lan-do> jelmer: It's *already* on alioth :-)
[16:43] <vila> awilkins: I thought you were british and that the fries joke was north-american only :)
[16:43] <Lo-lan-do> But the incompleteness shows: no commit stats and no Loggerhead.
[16:44] <awilkins> I am British, but we hear enough of the American news to know the phrase "Cheese-eating Surrender Monkey"
[16:44] <Lo-lan-do> I recently completed/fixed the git plugin for another customer. bzr is next.
[16:45] <vila> Never went to war myself, I can speak about the surrender part, but I like cheese and I'm a monkey :)
[16:45]  * Lo-lan-do fills up the Channel Tunnel
[16:45] <awilkins> There's a bloke who wants to open a British restaurant in Italy... partly to show case our cheeses (which are different, but good too)
[16:46] <vila> british cheese ? I thought you eat only dutch cheese :D
[16:46] <awilkins> vila: Edam is like plastic
[16:46] <Lo-lan-do> If I ever go on a month-long tour of Europe, I'll be sure to taste stuff besides the typical.
[16:46] <vila> let's start some european civil war to start the week-end :D
[16:47] <awilkins> vila: We have some of the greats, like cheddar, stilton, stinking bishop
[16:47] <awilkins> I do like Jarlsberg
[16:47] <Lo-lan-do> English cheese, German wine, Greek beer, and so on.
[16:48] <awilkins> I was shocked to find myself liking _Amercian_ beer
[16:48] <awilkins> But only the local stuff from microbreweries
[16:48] <vila> ..and counting ? I went to visit some friend last week-end and he said: "See, we do some wine and some cheese here", to which I replied: "Funny, nearly every french can say that, whaterver region they are from, they do some local wine and cheese !" :-D
[16:48] <Lo-lan-do> The only beer I managed to like is (kill me now) Kriek.
[16:49] <vila> Lo-lan-do: Belge une fois ?
[16:49] <Lo-lan-do> I am not!
[16:50] <awilkins> I like kriek. And framboise
[16:50] <vila> No offence meant :)
[16:50]  * Lo-lan-do is a garlic-stinking, pastis-drinking, smelly-cheese-eating Frenchman
[16:50] <Lo-lan-do> No moustache though, sorry.  It itches.
[16:57] <tbradshaw> hmmm
[16:57] <tbradshaw> so I'm getting a bzr error on the creation of a fresh local repo?
[16:57] <luks> are you?
[16:58] <tbradshaw> indeed, but it seems so unlikely. :/
[16:58] <tbradshaw> http://pastebin.projects.quakecon.org/67
[16:59] <luks> you are misunderstanding bzr concepts
[16:59] <luks> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#core-concepts
[17:00] <tbradshaw> what am I misunderstanding?
[17:00] <tbradshaw> is it just that "status" doesn't operate on a repostory?
[17:00] <luks> yes
[17:00] <tbradshaw> which would make sense, of course, but I wouldn't expect an error in that case
[17:00] <luks> why not?
[17:01] <luks> it's like running "cat" on a directory
[17:01] <tbradshaw> because a command with unfulfilled prerequisites shouldn't execute?
[17:01] <luks> it doesn't, and it tells you why
[17:01] <tbradshaw> cat on a directory gives a very reasonable response. :)
[17:02] <tbradshaw> but, anyway, I don't mean to get into a critique on software behavior
[17:02] <tbradshaw> I'm satisfied knowing that bzr doesn't work on repositories and I was just misusing it
[17:02] <luks> bzr st tells you that there is no working tree
[17:02] <luks> so it can't operate
[17:02] <tbradshaw> indeed
[17:03] <tbradshaw> the curiousity was that it gives an error on an nonexistent directory
[17:03] <tbradshaw> which lead me to believe an error during construction, rather than a simple misuse
[17:03] <tbradshaw> but, that's okay, it's still just a user error. :D
[17:03] <luks> that's where it would expect the working tree to be defined
[17:03] <luks> I agree the error message should be nicer
[17:04] <luks> if you want to "work" with bzr, you need to create a branch
[17:04] <tbradshaw> thanks for pointing out the difference, however.
[17:04] <luks> which is done using: bzr init
[17:04] <luks> bzr init-repo just creates a container for revisions
[17:04] <tbradshaw> yes, my intention was to create a local repository, such that I could store some related branches
[17:04] <tbradshaw> I had just been using bzr status liberally as a "sanity check"
[17:04] <luks> yep, then you need bzr init inside that directory
[17:05] <luks> you can run bzr info as a sanity check
[17:05] <tbradshaw> and so when my "sanity check" failed, I ran for help
[17:05] <tbradshaw> ah!
[17:05] <luks> it will tell you what is in the current directory
[17:05] <luks> but status is strictly a working tree operation
[17:05] <tbradshaw> so I should also bzr init?  Or would I go right to branching?
[17:05] <tbradshaw> my hope is to set up my local repository
[17:06] <tbradshaw> such that I have ./trunk
[17:06] <tbradshaw> and ./username/branches
[17:06] <luks> if you already have a branch somewhere, you can use bzr branch
[17:06] <tbradshaw> if that sounds reasonable
[17:06] <luks> I thought you are creating a new project
[17:06] <tbradshaw> no sir, launchpad stuff
[17:06] <tbradshaw> I just haven't done the local repository before
[17:06] <luks> ah, bzr branch is it then
[17:07] <tbradshaw> is it necessary for additional branches to be directly in the local repository?
[17:07] <tbradshaw> or can the local repository have some directory structure of it's own?
[17:08] <tbradshaw> ala, is it okay to mkdir branches, then branch other things from launchpad into that directory?
[17:08] <luks> no, you can have subdirectories there
[17:08] <luks> bzr will look for the repository in all parent directories until it finds one
[17:08] <Lo-lan-do> You can have branches separately.  Read about "lightweight checkouts".
[17:08] <Lo-lan-do> Hm.  Maybe I'm replying to the wrong question.  Ignore me please :-)
[17:09] <tbradshaw> :)
[17:10] <tbradshaw> yeah, that looks exactly how I had hoped it when when done
[17:10] <tbradshaw> thanks for setting me straight luks
[17:10] <tbradshaw> I appreciate the time and instruction. :)
[17:10] <luks> sorry about the first reaction :)
[17:10] <luks> I thought you are a git user trying to use bzr as git :P
[17:10] <luks> withuot reading the documentation
[17:11] <tbradshaw> ha ha!  Nope.  Just a longtime svn user, still trying to wrap my head around distributed version control.  I'm about 85% of the way there. :)
[17:11] <tbradshaw> but I make some poor assumptions sometimes, as you noticed.
[17:12] <tbradshaw> anyway, thanks again. :)
[17:14] <garyvdm> Hi igc
[17:15] <igc> hi
[17:17] <igc> night all
[17:34] <mthaddon> about to update PQM after the current run, if anyone's interested
[17:34] <michaelforrest> is bzr viz supposed to support viewing differences between multiple branches?
[17:35] <michaelforrest> I don't know how collaboration is supposed to work if I can't get a project overview like the github network graph..
[17:35] <garyvdm> michaelforrest: It can do it if the first branch has all the revisions that are in the second branch
[17:35] <michaelforrest> yeah that doesn't really help me
[17:35] <garyvdm> michaelforrest: If not, it fails silently.
[17:35] <michaelforrest> I want to see everything everyone's done
[17:35] <garyvdm> michaelforrest: qlog is much better at that
[17:35] <michaelforrest> so I can see if there's anything worth taking
[17:35] <michaelforrest> what is qlog?
[17:36] <michaelforrest> a plugin?
[17:36] <garyvdm> michaelforrest: simialar to viz, but better, found in qbzr plugin.
[17:36] <michaelforrest> ok
[17:36] <michaelforrest> I'll try that
[17:36] <michaelforrest> thanks
[17:36] <michaelforrest> oh, except... I'm on a Mac!
[17:37] <garyvdm> :-( - I believe that it is possible to run qbzr on a mac, but the installation is difficult.
[17:38] <garyvdm> michaelforrest: specifically the pyqt install.
[17:38] <michaelforrest> I'll see if macports does the job
[17:39] <luks> it seems there is a py25-pyqt4 port
[17:39] <luks> so it should work, it will just take some time
[17:39] <michaelforrest> ah ,thanks luks
[17:39] <garyvdm> Hi luks
[17:40] <luks> hi garyvdm
[17:40] <garyvdm> luks: I'm working on: http://bazaar-vcs.org/qbzr/Blueprint/BrowseRedesign
[17:40] <garyvdm> bbl - Dinner
[17:41] <luks> the mockup looks good
[17:41] <luks> but implementing it will be harder, as it's not exactly standard UI
[18:49] <naoki_> I'm sorry. I fixed tbzr build error.
[18:50] <naoki_> I can't build trunk directly because I don't have VC++2008 Std.
[18:52] <naoki_> I don't know autobuild environment. Is it build another branch?
[18:52] <jam> naoki_: we have buildbot running on a win2k3 machine
[18:53] <jam> http://babune.ladeuil.net:26862/waterfall
[18:53] <vila> naoki_: still no good, but I'm not sure the bot got your last revision
[18:53] <naoki_> For example, (1) push to lp:tortoisebzr/pre-trunk, (2) autobuild (3) push to lp:tortoisebzr
[18:53] <jam> specifically something like: http://babune.ladeuil.net:26862/builders/installer-dev-plugin-dev
[18:53] <vila> jam: it looks like my pqm submission go in a black hole... no feedback mail :-/
[18:54] <jam> vila: are you using the right submit branch?
[18:54] <jam> blackholes suck, though...
[18:54] <jam> it seems to happen often with pqm
[18:54] <vila> I used bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev, should I use http instead ?
[18:55] <vila> trying, will pass around later, dinner time
[19:00] <jam> vila: yes, http
[19:37] <vila> jam: even more obscure, I have mail in bazaar-commits for my submissions !
[19:41] <vila> jam: that is, the mails are accurate, but the revisions are nowhere to be seen, neither in the old trunk nor the new one...
[19:43] <vila> finally, the submission to http came back as failure: nothing to merge
[20:15] <BasicOSX> Great job on 2a, love it!
[20:26] <jam> vila: so... when you submit to pqm it does the merge and commit locally, and the pushes that to lp
[20:26] <jam> it is *possible* for that push to fail
[20:26] <jam> in the past we had problems with redundant packs after autopack, etc
[20:26] <jam> and that tends to kill pqm but give it 'nothing to do'
[20:27] <jam> because its local branch has the revisions merged
[20:27] <jam> thanks BasicOSX
[20:27] <jam> yeah, I just branched 'bzr.dev' from scratch in about 3m30s
[20:27] <jam> down from 12m+ last I used it
[20:27] <BasicOSX> yeah, same here. Amazing speed increase
[20:27] <vila> jam: yup, I came to the same conclusion, the merge went fine, the push failed, no idea how to track that further though without a LOSA :-/
[20:28] <jam> vila: Not possible, as far as I know
[20:28] <jam> mthaddon ,or spm ?
[20:28] <mthaddon> vila: how can I help?
[20:28] <vila> ho !
[20:28] <jam> mthaddon: it would seem that pqm successfully merged something but failed to push it to lp
[20:28] <vila> mthaddon: it seems that pqm can't push to lp
[20:28] <jam> can you check pqm's logs?
[20:29] <mthaddon> jam: sure - when did this (not) happen
[20:29] <jam> vila knows for sure
[20:29] <jam> maybe 3 hours ago
[20:29] <vila> I think I did the submission 2h30 ago
[20:30] <jam> vila: yeah, and the email is sent post push, not post commit
[20:30] <jam> so that also would fit the symptoms
[20:30] <mthaddon> jam, vila: https://pastebin.canonical.com/21854/
[20:30] <jam> mthaddon, vila: looks like a direct bug in pqm
[20:31] <jam> something got a string pointing to a branch, and thought it was getting a Branch object
[20:31] <jam> perhaps aliasing of a variable?
[20:31] <mthaddon> jam: possibly not - https://pastebin.canonical.com/21856/
[20:32] <jam> mthaddon: well, that could be a factor too, but certainly pqm shouldn't be treating a string as a Branch object :)
[20:32] <vila> damn it, can you check the authentication.conf file
[20:32] <jam> the latter may have triggered the former, though
[20:33] <vila> mthaddon: if auth.conf exists in ~/.bazaar and user is not bzr-pqm... that will explain why spm called auth.conf with poetic names
[20:33] <vila> mthaddon, jam : that's in addition to the direct pqm bug of course
[20:35] <mthaddon> https://pastebin.canonical.com/21858/ is from .ssh/config and the public key seems to match https://edge.launchpad.net/~bzr-pqm/+sshkeys
[20:35] <vila> mthaddon: at worse, you should check with spm about auth.conf, my memory of the discussion is that you shouldn't use lp: on pqm only bzr+ssh urls
[20:35] <mthaddon> vila: I tried it again with bzr+ssh urls - got the same
[20:35] <vila> mthaddon: but what appear in ~/.bazaar/authentication.conf ?
[20:35] <mthaddon> although for some reason auth.conf has launchpad-pqm user :(
[20:35] <vila> mthaddon: if you don't specify a user in the url, auth.conf will provide it
[20:36] <vila> here we are....
[20:36] <nxvl_> hi! i was wondering about the "--fixes" option, in the docs it says i can close multiple bugs, but it doesn't say how the parameters need to be passed
[20:36] <mthaddon> was updated 2009-09-04 14:47
[20:36] <vila> so,  the solution is to remove auth.conf
[20:36] <nxvl_> as in space separated, comma separated, a --fixes option for each
[20:36] <vila> but we need to understand how and whem it came back
[20:36] <mthaddon> vila: why would that have been created?
[20:36] <vila> mthaddon: *you* tell me :-D
[20:37] <vila> my 8-ball can't read the logs there :)
[20:37] <mthaddon> vila: which logs?
[20:37] <vila> mthaddon: It was a joke, I have no idea where to look :-/
[20:37] <vila> .bzr.log certainly, but for what command ?
[20:37] <mthaddon> yeah, me neither :(
[20:38] <vila> Some command that use lp: certainly since that is the one that trigger the creation of the [launchpad] section in auth.conf,
[20:38] <mthaddon> vila: should I just remove that file for the moment?
[20:39] <vila> but I don't know precisely which... lp-login ? What did bazaar.conf says ?
[20:39] <vila> mthaddon: yes
[20:39] <mthaddon> vila: oh, hang on a sec...
[20:39] <vila> err
[20:39] <vila> hang on
[20:39] <mthaddon> so I did an upgrade of PQM earlier
[20:39] <vila> what hour ?
[20:39] <mthaddon> let me confirm
[20:39] <vila> in pqm time so we can relate to 'was updated 2009-09-04 14:47'
[20:40] <mthaddon> about three hours ago...
[20:40] <mthaddon> so this is sounding promising - if we just remove this file we should be good
[20:40] <mthaddon> which I've now done
[20:41] <vila> in bzr trunk you should now be able to try: 'bzr missing :push' and it should tell you about 2 missing revisions
[20:42] <mthaddon> I'm not really sure what directory that'd be from, locally - let me see if I can find anything
[20:42] <vila> ,bzr.log should give you some hints
[20:44] <mthaddon> vila: https://pastebin.canonical.com/21859/ <-- gah!
[20:45] <vila> mthaddon: 'bzr info' ?
[20:45]  * vila wonders what escudero maps to...
[20:46] <mthaddon> https://pastebin.canonical.com/21860/
[20:47] <vila> mthaddon: 8-( I'm lost
[20:48] <vila> lifeless, jam: wrong setup on escudero ?
[20:49] <jam> nxvl: --fixes A --fixes B --fixes C I believe
[20:49] <nxvl> jam: thnk you!
[20:50] <vila> nxvl: I confirm, I used it last today (sry missed the question)
[20:50] <jam> vila: pqm shouldn't be pushing to escudero directly
[20:50] <jam> I believe it pushes based on the submit branch
[20:50] <jam> and its internal config
[20:50] <mthaddon> well at least bzr ls bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev is working now
[20:50] <jam> whatever maps http://bazaar.lp.net/... => bzr+ssh://...
[20:50] <nxvl> vila: :D
[20:51] <mthaddon> vila: I see two revnos diff between that dir locally and bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev - should I just push to there?
[20:52] <jam> mthaddon: sure
[20:52] <vila> mthaddon: that's what I want yes, thanks :)
[20:52] <mthaddon> jam, vila: ok, done
[20:52] <mthaddon> now up to revno 4674
[20:52] <vila> mthaddon: what I hope though, is that you won't have to do it for every submission :)
[20:52] <mthaddon> :)
[20:53] <vila> mthaddon: thanks a ton !
[20:53] <mthaddon> sure - I'll keep my fingers crossed
[20:55] <vila> mthaddon: we should check with spm about that authentication.conf mess, there is a bug waiting to be fixed there :)
[20:57] <vila> may be even some in pqm, no feedback is really bad in these circumstances
[20:57]  * vila EODing SWEing :)
[21:00]  * fullermd SBI NRZ's to vila.
[21:01] <jam> well, I think someone like lifeless gets an email when pqm crashes like this
[21:01] <jam> but it doesn't help the submitter much
[21:01] <jam> until he wakes up and notices :)
[21:21] <kfogel> LarstiQ: https://code.edge.launchpad.net/~kfogel/bzr-hookless-email/byte-limit/+merge/11233  :-)
[21:39] <lifeless> jam: crashes how?
[21:40] <lifeless> jam: also, how to get a memory trace from a running bzr process?
[21:40] <lifeless>  4847 robertc   20   0 6284m 4.8g 1200 D    0 84.1 379:17.46 python
[21:40] <jam> lifeless: pqm was crashing by failing to push to lp:bzr
[21:40] <jam> it seems that ~/.bazaar/auth.conf  got set
[21:40] <jam> and so it was trying to login as someone like spm
[21:40] <jam> in doing so
[21:40] <jam> it failed to send a message to vila about his merge
[21:41] <jam> it would successfully merge, run the tests, commit, push would fail
[21:41] <jam> no email
[21:41] <lifeless>  fixed in pqm trunk
[21:41] <lifeless> I think
[21:41] <jam> also, there was a bug about "parent_branch" being a string
[21:41] <lifeless> theres an RT ticket for deployment alreadyt
[21:41] <jam> when it thought it should be a Branch object
[21:41] <jam> for memory trace
[21:41] <jam> bzr branch lp:~jameinel/+junk/py_memory_dump
[21:41] <jam> setup.py install (needs pyrex)
[21:41] <jam> then
[21:42] <jam> SIQUIT
[21:42] <jam> from memory_dump import scanner
[21:42] <jam> scanner.dump_gc_objects('foo.json')
[21:42] <jam> though right now I'm making decent use of
[21:42] <jam> trace.debug_memory()
[21:42] <jam> which just uses /proc/PID/status
[21:43] <lifeless> this is the netbeans import
[21:43] <lifeless> its now 6:42
[21:43] <lifeless> 11:19:34 65000/133780 commits processed at 208/minute (:65000)
[21:43] <lifeless> was the last output
[21:43] <lifeless> its been thrashing for 19 hours
[21:47] <jam> lifeless: well, IIRC from igc, if you just do 'bzr fast-import foo.fi' the fast-import code caches all texts in memory
[21:47] <jam> there was something about doing a 2-pass system
[21:47] <jam> which allows the code to know what texts will be referenced again
[21:47] <jam> which has been implemented, I believe
[21:47] <lifeless> jam: I think it caches refs to them; its a 129G .fi file:
[21:47] <jam> but igc knows better
[21:47] <jam> lifeless: no, it caches the texts
[21:48] <jam> see igc's recent comments about how fast-import isn't ready to scale to really-big-imports
[21:48] <jam> at least, that is what I understood from various threads
[21:48] <lifeless> hes being doing kernel and openoffice
[21:48] <jam> lifeless: with 2 passes
[21:48] <jam> I would assume
[21:48] <jam> 1 pass generates a map
[21:48] <jam> used in the second pass
[21:48] <lifeless> anyhow, I'm going to get a trace, file a bug, and zerg it :P
[21:54] <RenatoSilva> hey what's this? http://pastie.org/606334
[21:55] <Xavura> It's a URI.
[21:55] <Xavura> :x
[21:59] <RenatoSilva> how to solve that error? is it a bzr bug?
[22:01] <jam> so lifeless on my networking issues
[22:01] <jam> I came back late at night from my slower Linux server, and branched all of bzr.dev in 3.5min
[22:01] <jam> which was great
[22:01] <jam> though my last time on the Windows box was 14min
[22:01] <jam> (both post-pack)
[22:02] <jam> Unfortunately I didn't try again to see if it was time of day, versus windows/linux
[22:02] <jam> I did test right now, and I can get about 1.5MB/s (byte not bit) on my wireless network from a local server
[22:02] <jam> on windows (using rsync)
[22:03] <jam> I wonder if maybe our code that does some cpu processing while reading is causing problems on windows
[22:04] <lifeless> that would show up with the window being full
[22:05] <lifeless> we can tell the os we want it to be bigger
[22:05] <lifeless> uhm
[22:05] <lifeless> rephrase
[22:05] <lifeless> 'it might be paramiko'
[22:05] <lifeless> I suggest trying paramiko on linux, from the same machine
[22:05] <lifeless> [as few variables changed as we can]
[22:06] <fullermd> RenatoSilva: It's some plugin being out of sync with your bzr.
[22:06] <fullermd> RenatoSilva: rebase, maybe?
[22:11] <mthaddon> lifeless: PQM upgrade seems to be busted
[22:11] <mthaddon> for U1 at least
[22:12] <mthaddon> lifeless: https://pastebin.canonical.com/21864/
[22:12] <lifeless> mthaddon: did the new dep get installed?
[22:12] <mthaddon> lifeless: it did, yep
[22:12] <lifeless> oh fnar fnar that looks like a bug
[22:12] <lifeless> gimme a sec I'll check trunk
[22:13] <mthaddon> thx
[22:14] <lifeless> ok just delete the parameter on that line
[22:14] <lifeless> it passed tests. Clearly that line isn't tested :(
[22:15] <mthaddon> lifeless: erm, which parameter on which line?
[22:15] <statik> mthaddon: the same patch I already pasted :)
[22:15] <mthaddon> ah!
[22:17] <lifeless> pushing rev with it in it anyhow
[22:17] <lifeless> statik: mthaddon: sorry about that
[22:17] <statik> no worries
[22:17] <lifeless> gimme a week with nothing else queued, I could really sort pqm out
[22:18] <mthaddon> lifeless: I think we can fit one of those in around about April 2035
[22:18] <lifeless> that soon? :)
[22:19] <mthaddon> yeah, I'm being optimistic
[22:20] <lifeless> jam: ok, dumping that json; whats the easiest tool to use to answer 'where did 6G of ram go' ?
[22:20] <RenatoSilva> fullermd: what's rebase and out of sync with bzr?
[22:21] <jam> lifeless: cat foo.json | sort | uniq | sort [something to sort on the size column] > sorted.json
[22:21] <jam> there is also
[22:21] <jam> memory_dump.loader
[22:22] <jam> om = memory_dump.loader.load('dumpfile.json')
[22:22] <jam> s = om.summarize()
[22:22] <jam> print s
[22:22] <jam> print s.summaries[0]
[22:22] <jam> the introspection stuff could certainly use more work
[22:22] <jam> but it may be a start
[22:23] <jam> I also have a branch of runsnakerun that can load them an compute square maps, etc
[22:23] <jam> but at 6GB, rsr is pretty useless
[22:23] <jam> there are probably enough objects that just loading the dump is going to be a couple G
[22:27] <fullermd> RenatoSilva: Well, it's on your list of plugins.  The erroring function sounds like something I think is in rebase.
[22:27] <RenatoSilva> what's rebase?
[22:27] <fullermd> The plugin.
[22:28] <RenatoSilva> bzr pull -----> not a branch
[22:28] <RenatoSilva> how to solve this
[22:28] <RenatoSilva> I just want to make it work
[22:29] <fullermd> Well, presumably it's installed from a release, so it would need one in sync with your bzr.  I don't really know details; I don't use rebase.
[22:29] <fullermd> (I don't know for sure rebase is what's causing your problem either, but I know I've heard that error before related to plugins, and rebase seems the most likely suspect)
[22:30] <bialix> I've got error in tests in my plugin:   File "bzrlib\commands.pyo", line 212, in get_cmd_object --> BzrCommandError: unknown command "init"
[22:30] <RenatoSilva> I don't use rebase either, I did not even know that thing ever exist
[22:30] <bialix> what I should do?
[22:30] <jam> RenatoSilva: the error is a known bug in bzr's 1.17 win32 installer because it bundled a version of bzr-rebase that caused 'bzr help commands' to fail.
[22:30] <jam> use a different installer
[22:30] <jam> 1.18rc1
[22:30] <jam> etc.
[22:30] <bialix> invoke install_bzr_command_hooks for those tests?
[22:31] <jam> RenatoSilva: note that there are no known real problems with 1.17, just that 'bzr help commands' is unhappy
[22:31] <bialix> dear core devs, can you give me advice?
[22:31] <RenatoSilva> jam: official release is still 1.17? Ok at least I know the cause, I guess I'll wait for the fix in official release or so
[22:31] <jam> RenatoSilva: 'bzr pull ==> not a branch' probably means you don't have a branch... either the source or the target
[22:31] <RenatoSilva> jam: rebase is not a branch
[22:32] <RenatoSilva> btw, I'd run bzr help commands to know how to see/change my user name that go into commits
[22:32] <RenatoSilva> since I won't install RCs, I ask here, how? :)
[22:33] <bialix> lifeless: should I run install_bzr_command_hooks for my tests if I need get_cmd_object to work?
[22:33] <jam> RenatoSilva: bzr help commands --no-plugnis
[22:33] <jam> bzr help commands --no-plugins
[22:33] <jam> bzr whoami
[22:35] <lifeless> bialix: the main one in bzrlib? no
[22:35] <RenatoSilva> yeah, whoami!!!!!
[22:35] <RenatoSilva> jam: thanks!
[22:36] <bialix> lifeless: so why my test failed on get_cmd_object then?
[22:36] <lifeless> bialix: I'm not here today - if jam can't give you a hand perhaps post to the  list?
[22:36] <bialix> ok
[22:36] <bialix> jam: can you give me advice about get_cmd_object?
[22:36] <RenatoSilva> the whoami is stored for each OS user in his profile right?
[22:38] <lifeless> bialix: I would guess though that you've overridden setUp()
[22:38] <lifeless> and not called the base class setUp
[22:38] <lifeless> or something like that
[22:38] <bialix> lifeless: no
[22:39] <jam> RenatoSilva: yes
[22:39] <jam> bialix: I don't know much about it, without having a bit more background of how the test is failing
[22:39] <jam> however, I'm also done for the weekend...
[22:40] <bialix> ok, thanks guys for making bzrlib api harder to use
[22:40] <RenatoSilva> ok tahnks
[22:41] <lifeless> bialix: that makes me sad, that you say that
[22:41] <lifeless> bialix: I'm sorry its giving you trouble; if you mail the list I'll be happy to help figure it out, but I can't today.
[22:41] <bialix> lifeless: I found that you invoke install_hook in the test_commands.py
[22:41] <lifeless> I'm doing breakfast then out finding stuff for my brothers birthday
[22:42] <lifeless> bialix: yes, but thats to test that the hooks work
[22:42] <bialix> it's not the part of TestCase setUp()
[22:42] <lifeless> all normal bzrlib tests have the commands registered by default
[22:42] <bialix> perhaps when I run selftest -s bp.scmproj it won't
[22:44] <lifeless> bialix: the hooks are setup by doing run_bzr_command
[22:45] <bialix> and I'm using run_bzr()
[22:45] <lifeless> bialix: if you don't call run_bzr_catch_errors or run_bzr_catch_user_errors at all, they won't be registered
[22:45] <lifeless> bialix: why?
[22:46] <bialix> because it works for my plugin
[22:47] <lifeless> well, if you want to call it directly, yes then you will need to install the hooks manually.
[22:47] <bialix> yep, explicit call to install_hook helps
[22:47] <bialix> thanks
[22:47] <lifeless> calling it directly will mean you don't get error formatting
[22:47] <lifeless> its better to call one of the run_bzr_catch variants
[22:49] <bialix> lifeless: no, I need only run_bzr()
[22:50] <lifeless> bialix: why?
[22:51] <bialix> because I run bzr commands as in-process
[22:51] <lifeless> in the test suite or your ui?
[22:52] <bialix> in my backend
[22:53] <lifeless> sounds like you have an implementation of run_bzr_catch_user_errors
[22:53] <lifeless> can you not just use it directly?
[22:54] <bialix> lifeless: you said you're busy ;-) I'm just want to release my plugin and make its test suite pass again after 7 months of not running it
[22:55] <bialix> even if it ugly inside
[22:55] <lifeless> kk
[22:56] <bialix> it working in the end
[22:59] <bialix> all tests passed, everybody happy
[22:59] <RenatoSilva> How to delete the latest revision from Launchpad branch?
[23:01] <RenatoSilva> Anything better than branch+uncommit+revert+delete+push?
[23:01] <bialix> uncommit lp:xxx ?
[23:02] <RenatoSilva> bialix: it will uncommit directly in the lp copy?
[23:02] <bialix> it should
[23:03] <RenatoSilva> cool, but I won't get uncommited stuff when I branch it, or will I?
[23:03] <bialix> but I'm not sure what is lp copy for you
[23:03] <bialix> no, you don't get
[23:04] <RenatoSilva> launchpad's copy of the branch, not local copy
[23:04] <bialix> I'd rather to not use term "copy"
[23:05] <RenatoSilva> why
[23:06] <bialix> because they are different branches
[23:06] <bialix> you're working with dvcs in the end
[23:08] <bialix> RenatoSilva: those branches like twins: they seems similar but have different wives
[23:16] <RenatoSilva> bialix: ok got it, but with copy I meant same revisions, non-diverged
[23:17] <bialix> is the wall of white house still white when you to trun round the corner?


[05:48] <juergh> lotuspsychje: ack. maybe that's a good thing then since that is our under control.
[05:48] <juergh> meh. dyslexic. need more coffee...
[17:25] <hggdh> is it already known that 20.04 'crash' is failing to work with the 5.15.0-1037 kernel (at least)?
[17:26] <hggdh> crash fails with "Dwarf Error: wrong version in compilation unit header (is 5, should be 2, 3, or 4) [in module /usr/lib/debug/boot/vmlinux-5.15.0-1037-azure]"
[17:26] <hggdh> if needed, I can open a bug on this