[00:02] <james_w> yeah
[00:02] <james_w> not tonight though
[00:04] <james_w> ah, I think it's just karmic that is affected
[00:05] <james_w> I missed that branch when fixing last time
[00:05] <james_w> so even if I had added the check it still wouldn't have caught this problem
[00:07] <johnf> jelmer: ping
[00:09] <SamB_XP_> barry: why did you decide to use the nightlies by accident ?
[00:16] <lifeless> james_w: it wouldn't have caught it? [oh because you wouldn't have added the check there :P]
[00:16] <lifeless> james_w: I'll see if johnf can fix it, its his daytime now.
[00:16] <lifeless> johnf: https://bugs.edge.launchpad.net/bzr/+bug/439100
[00:16] <ubottu> Launchpad bug 439100 in bzr "bzr: warning: some compiled extensions could not be loaded;" [Critical,Confirmed]
[00:16] <james_w> yeah
[00:16] <james_w> just add python-pyrex to build-depends
[00:17] <james_w> and then glob the .so files in the .install file I say
[00:17] <lifeless> so that dh_install errors if missing?
[00:17] <lifeless> uhm, I suspect the python stuff will interact badly
[00:18] <james_w> yeah
[00:18] <james_w> or just an "ls" glob in the rules file or something
[00:19] <lifeless> in particular if things change we'll break, so we shhouldn't alter the install mechanism
[00:19] <lifeless> james_w: yeah, I was thinking
[00:19] <lifeless> [ 7 -e `ls debian/pkg/.../*.so | wc -l` ]
[00:20] <lifeless> erm, not -e. equal.
[00:20] <johnf> so my question is what are the nightlies being built from because the other PPA packages are fine
[00:20] <johnf> Although I'm using a new method now which I need to document soon
[00:20] <lifeless> \o/
[00:21] <lifeless> you've probably discarded the karmic packaging
[00:21] <lifeless> the nightlies build using the packaging branches AIUI
[00:21] <lifeless> james_w: are the nightlies conceptually compatible with autoppa
[00:21] <james_w> not sure
[00:22] <james_w> the normal builds don't have a problem as they are built from the release tarballs
[00:22] <johnf> ahh the packaging branches don't have pyrex
[00:22] <james_w> with you don't need pyrex for
[00:22] <james_w> as the release manager does that step
[00:22] <james_w> so it's an uneeded dependency there
[00:22] <james_w> but just installing it everywhere makes it easier to manage
[00:22] <johnf> ok Let me document my new process using debian as a base and autoppa on top of that over the weekend and then let's switch the nightlies over to that process
[00:22] <lifeless> johnf: so I have two goals: a) fix it. b) put a rule in to catch regressions (e.g. if we change to cython)
[00:23] <johnf> lifeless: I think preference would be to catch it in the Makefile so that we solve this problem for all distributions. ie a make install should fail
[00:24] <johnf> in fact why don't we just make the make fail if pyrex is missing?
[00:27] <lifeless> different users
[00:27] <lifeless> we were going to start versioning the .c files
[00:44] <idnar> what exactly is the format of a bzr+ssh:// URL?
[00:44] <lifeless> std66
[00:44] <lifeless> which is to say, what you'd expect
[00:44] <lifeless> idnar: is there a particular thing that is troubling you?
[00:45] <idnar> I just don't know how to construct one, I've only ever worked with scp/rsync-style paths
[00:45] <lifeless> oh
[00:45] <lifeless> so the same as http:// urls
[00:45] <idnar> and I seem to be doing it wrong, because bzr tells me "Parent directory of [...] does not exist"
[00:45] <lifeless> rooted at /
[00:45] <idnar> I guess I need the absolute path to the home directory
[00:45] <lifeless>  bzr+ssh://[user[:password]@host/paths/home/here
[00:45] <lifeless> yes
[00:46] <lifeless> because we start the server when we connect, it doesn't have a build in chroot like http servers do
[00:48] <spiv> (If you have bzr.dev on the server, you can use a path starting with ~/ to be relative to the home directory on the server, e.g. bzr+ssh://myhost/~/myproj)
[00:48] <idnar> ah, I tried that, but this is with 1.16 or something
[00:48] <mzz> I keep forgetting where /~/ works. Is that only with bzr.dev with bzr+ssh currently?
[00:48] <spiv> mzz: yes
[00:48] <lifeless> idnar: we had a choice between // meaning root and / meaning homedir, or /~/ meaning homedir and / meaning root
[00:49] <mzz> ok
[00:49] <lifeless> we took the latter choice
[00:49] <lifeless> mzz: and sftp
[00:49] <lifeless> mzz: sftp has always worked
[00:49] <mzz> ahh, sftp is probably what I was confused with then.
[00:49] <mzz> oh well, no big deal either way, my name's not that long compared to the hostname and branch name usually
[00:50] <lifeless> idnar: 2.0. Its good. Get it.
[00:51] <mzz> yay, progress (although I really don't use bzr with any trees of sufficient size for it to matter all that much to me)
[00:52] <idnar> lifeless: we probably will once it's in lenny-backports
[00:54] <lifeless> idnar: I suspect that requires a request
[00:54] <lifeless> its in debian so should be trivial for the backport team to do
[00:59] <idnar> anyhow, it's pretty far down my list of priorities right now
[01:00] <lifeless> sure
[01:00] <lifeless> I'd drop them a mail though :)
[01:00] <idnar> 2a format seems like it'll be nice when we switch, though
[01:00] <lifeless> its rocking
[01:01] <idnar> we're currently using 1.6 format, I think
[01:02] <jelmer> /clear
[01:02] <idnar> whatever the minimum that supports stacking is
[01:02] <lifeless> 1.6
[01:02] <lifeless> 1.9 has faster indices
[01:02] <lifeless> 2a has faster everything
[01:02] <idnar> I think we could upgrade to 1.14, but I'll just wait until we can do 2a
[01:03] <lifeless> you can now
[01:03] <lifeless> but it is fragile < 2.0.0
[01:33] <mwhudson> Peng: can you explain in words of one syllable what the problems with loggerhead and yui3 final are?
[01:38] <mzz> that is not a lot of speech sound things. To say a thing with that rule in place is hard, but at the same time a bit fun
[01:41] <lifeless> mwhudson: does not work ? ;)
[01:41] <mwhudson> lifeless: ta
[01:41] <mwhudson> seems to be accurate in fact, surprisingly enough
[01:42] <mwhudson> it just doesn't work at all, for no very obvious reason
[01:43] <lifeless> if I can suggest unbundling yui - debian unbundle it anyway; make it a dependency
[01:44] <mwhudson> possibly a good idea
[01:44] <mwhudson> orthogonal though
[01:44] <lifeless> yes
[02:25] <Peng_> mwhudson: There's a new feature in YUI 3.0.0, where you basically do YUI.use('whatever', function() { my_code(); }). It's possible that the old style that Loggerhead uses doesn't work anymore. I didn't check, though.
[02:25] <Peng_> mwhudson: http://www.yuiblog.com/blog/2009/09/29/yui-3-0-0/
[02:25]  * Peng_ goes AFK again
[02:25] <mwhudson> Peng_: yes, that's right it seems
[02:26] <mwhudson> Peng_: it's not a new feature in yui 3 vs 3pr2, it's new compared to yui2
[02:26] <mwhudson> Peng_: thanks for the prod
[02:28] <emmajane> igc, I did see the email about the nav problem. I can replicate using browsershots.
[02:29] <emmajane> kirkland, I tried the snippets you gave me yesterday, but I'm getting an error on the results page.
[02:29] <emmajane> kirkland, http://bazaar-vcs.org/static/
[02:30] <emmajane> (just in case you still happen to be around :) )
[02:34] <emmajane> hrm
[02:34] <emmajane> let's try that again...
[02:34] <emmajane> igc, I did see the email about the nav problem. I can replicate using browsershots.
[02:34] <emmajane>  kirkland, I tried the snippets you gave me yesterday, but I'm getting an error on the results page.
[02:34] <emmajane> kirkland, http://bazaar-vcs.org/static/
[02:34] <emmajane> (just in case you still happen to be around :) )
[02:36] <kirkland> emmajane: these are wrong:
[02:36] <kirkland>   var googleSearchIframeName = "cse-search-results";
[02:36] <kirkland>   var googleSearchFormName = "cse-search-box";
[02:36] <kirkland> emmajane: mine look like this:
[02:36] <kirkland>                 var googleSearchIframeName = "results_003883529982892832976:ly2fmeg302s";
[02:36] <kirkland>                 var googleSearchFormName = "searchbox_003883529982892832976:ly2fmeg302s";
[02:37] <kirkland> emmajane: you need yours to make your google cx id or whatever
[02:37] <kirkland> emmajane: do you have access to the google custom search front end?
[02:37] <emmajane> kirkland, it's poolie's. I don't have all the controls as when I make my own.
[02:39] <kirkland> emmajane: gotcha
[02:39] <kirkland> emmajane: try this...
[02:39] <emmajane> I believe I'm: cx=009852948614216791564:dr5xzrczfnu
[02:40] <kirkland> emmajane: oh, there you go
[02:40] <kirkland> emmajane: http://pastebin.ubuntu.com/282607/
[02:40] <emmajane> so just results_009852948614216791564:dr5xzrczfnu (maybe?)
[02:40] <kirkland> emmajane: replace the _[0-9]* with that
[02:41] <kirkland> emmajane: yes, exactly
[02:41] <emmajane> with the :etc
[02:41] <kirkland>     <input type="hidden" name="cx" value="009852948614216791564" />
[02:41] <kirkland> emmajane: and that too
[02:41] <kirkland> emmajane: yes, with the :.*
[02:41] <emmajane> thanks :)
[02:41] <emmajane> I've found the documentation on this to be plentiful AND useless all at the same time. :/
[02:44] <kirkland> emmajane: :-)
[02:44] <kirkland> emmajane: it is a bit of a mystery
[02:44] <emmajane> kirkland, /me shakes her fist at the proprietary money makers. ;)
[02:45] <emmajane> ok. I've plugged that in and now I'm getting no error and no results locally. Just uploading to test.
[02:54] <emmajane> kirkland, hm. same thing as locally. no results. http://tools.hicktech.com/bzr-website/
[02:55]  * kirkland looks
[02:55] <lifeless> meep
[02:55] <lifeless> I've wandered into html land
[02:56] <emmajane> lifeless, avert your eyes! :)
[02:57] <lifeless> davidstrauss: its plone you're upstream on right?
[02:58] <emmajane> davidstrauss, you're meddling in plone now too?!
[02:58] <emmajane> davidstrauss, TRAITOR :)
[02:58] <kirkland> emmajane: change <form action="search.html" id="cse-search-box">
[02:58] <kirkland> emmajane: to id="searchbox_009852948614216791564:dr5xzrczfnu"
[02:59] <emmajane> ah
[02:59] <kirkland> emmajane: and also:
[02:59] <kirkland> <div id="cse-search-results"></div>
[03:00] <lifeless> emmajane: no, I was confused
[03:00] <lifeless> its drupal
[03:00] <kirkland> emmajane: to <div id="results_009852948614216791564:dr5xzrczfnu"></div>
[03:00] <lifeless> I knew it was some webby thing
[03:00] <emmajane> lifeless, LOL
[03:00] <emmajane> lifeless, plone. drupal. what's the diff? ;)
[03:00] <lifeless> exactly!
[03:00]  * emmajane grins
[03:01] <lifeless> so I was going to ask
[03:01] <lifeless> what does it do for test runs; web based reporting and so on, or very console orientated?
[03:01] <emmajane> lifeless, ummm. they have a bot and a farm.
[03:02] <emmajane> there's a testing suite which has web-based reporting and updates the issue queue to say if patches passed the suite.
[03:02] <emmajane> after that I start running out of words to repeat.
[03:02] <lifeless> ;)
[03:03] <lifeless> http://drupal.org/node/394888 seems relevant
[03:03] <emmajane> sdboyer, you know the answer to that ^^
[03:03] <emmajane> chx would know too if he were around.
[03:08] <lifeless> http://testing.drupal.org/ needs more google juice
[03:09]  * emmajane nods.
[03:09] <lifeless> jelmer: http://testing.drupal.org/pifr/file/1/13019
[03:12] <emmajane> lifeless, http://drupal.org/node/162788#comment-1697272 <-- example of integration with our issues queue.
[03:12] <emmajane> not sure if you wanted to see that bit though.
[03:12] <emmajane> http://drupal.org/node/162788#comment-1770146 <-- and failures
[03:13] <lifeless> emmajane: thats nice
[03:13] <emmajane> as much as we hate our issues queue, the test bot is pretty cool.
[03:14] <lifeless> http://build.samba.org/?function=Recent+Builds;tree=samba_4_0_test uses http://launchpad.net/subunit but does its html rendering via regex and guesswork
[03:14] <lifeless> so there is a bug on subunit to have a good html reporter
[03:14]  * emmajane nods
[03:16] <emmajane> lifeless, it can be a bit brutal to track down the right test (most of the time I'm doing docs patches and it's a wonky test that needs to be fixed), but generally I find it more useful than having nothing.
[03:16] <lifeless> does it file bugs automatically?
[03:16] <emmajane> hahaha
[03:16] <emmajane> no.
[03:16] <emmajane> :)
[03:17] <lifeless> so, how do you get the integration, you just say 'test XXX' when you file it?
[03:17] <emmajane> patches don't get accepted to core if they don't pass the bot.
[03:17] <emmajane> (which is the issue queue integration part).
[03:17] <emmajane> patches that are "red" don't go in.
[03:17] <lifeless> ok
[03:17] <lifeless> so you have a queue
[03:17] <emmajane> yah
[03:17] <lifeless> and if it passes it lands
[03:18] <lifeless> and if it fails it becomes an item in the issue queue?
[03:18] <emmajane> uploading a .patch triggers the bot to run the tests.
[03:18] <lifeless> its basically a prettier PQM :)
[03:18] <lifeless> I like
[03:18] <emmajane> then you hit reload on the issue a million times and eventually the place where you uploaded your patch turns green or red.
[03:18] <spm> Am trying to debug why 'bzr launchpad-login' (in a chroot) is returning "bzr: ERROR: Connection error: curl connection error (Problem with the SSL CA cert (path? access rights?))" any suggested flags? or is strace the best bet?
[03:19] <emmajane> lifeless, "normal people" don't ever look at testing.d.o they just wait to get the results back.
[03:19] <lifeless> emmajane: so you upload the patch to the bug tracker?
[03:19] <emmajane> lifeless, yup
[03:19] <lifeless> emmajane: very nice
[03:20] <emmajane> it seems to work for us. :)
[03:20] <lifeless> emmajane: is committing to core done by the bot, or someone taking a passed item and going 'doit'
[03:20] <emmajane> lifeless, one of two humans gets to commit to core.
[03:20] <lifeless> spm: apt-get remove python-curl
[03:20] <lifeless> spm: :P
[03:20] <emmajane> lifeless, we have a status on an issue which is, "ready to be committed"
[03:20] <lifeless> spm: (don't, I'm teasing)
[03:20] <spm> lifeless: ha ha. :-)
[03:20] <emmajane> lifeless, then either Dries or $co-maintainer will commit the patch.
[03:20] <lifeless> spm: its probably ca-certificates
[03:21] <spiv> spm: what lifeless just said; is the ca-certifcates package installed?
[03:21] <kirkland> emmajane: any luck?
[03:21] <emmajane> lifeless, contrib modules are, of course, totally different and don't have a testing suite unless the developer chooses to create one (but I don't believe that's part of the testing bot's job)
[03:21] <emmajane> kirkland, no. :(
[03:21] <emmajane> kirkland, back to Bad Request.
[03:21] <spm> lifeless: spiv: huh. no it isn't. lets try that then.
[03:21] <kirkland> emmajane: where's the latest?
[03:21] <emmajane> kirkland, Just trying to figure out what I did this time. :(
[03:21] <spiv> lifeless: thinking of subunit, is it time to add --subunit to make check?
[03:21] <kirkland> emmajane: it's working for me
[03:21] <lifeless> spiv: yes!
[03:22] <emmajane> arh. wrong tab.
[03:22] <kirkland> emmajane: http://tools.hicktech.com/bzr-website/search.html?cx=009852948614216791564%3Adr5xzrczfnu&cof=FORID%3A10&ie=UTF-8&q=emma&sa=Search#881
[03:22]  * emmajane bangs her head repeatedly.
[03:22] <emmajane> kirkland, you are like a Google-god.
[03:22] <emmajane> kirkland, thank you :)
[03:22] <lifeless> kirkland: so how did you get roped into this ;)
[03:23] <lifeless> [not why, how :P]
[03:23] <emmajane> lifeless, I think I threatened to cry...
[03:23]  * emmajane is classy like that
[03:23] <lifeless> lol
[03:23] <kirkland> lifeless: heh, not sure
[03:23] <lifeless> spiv: should I submit a pycon talk; I think I have about 5 hours to do that in.
[03:23] <kirkland> lifeless: i have a couple of semi-useful google-custom-searches up and around
[03:23] <lifeless> spiv: do they do travel assistance ever?
[03:23] <kirkland> lifeless: i think poolie outed me :-)
[03:23] <spiv> lifeless: I'm afraid I don't know.
[03:23] <emmajane> lifeless, I think hypa7ia is just working on hers. :)
[03:24] <kirkland> emmajane: results, formatting look nice
[03:24] <lifeless> spiv: bah, some python god :P
[03:24] <emmajane> kirkland, I'll never tell who outed you. I need to protect my sources. :)
[03:24] <kirkland> emmajane: heh
[03:25] <kirkland> emmajane, et al: enjoy ;-)
[03:25] <emmajane> bzr commit -m "Google Search is now working. Everyone buy kirkland a $drink."
[03:26] <kirkland> emmajane: heh!
[03:26] <lifeless> drink="bombay sapphire" \1
[03:26] <lifeless> spiv: would you like to do the honours [--subunit to trunk?]
[03:27] <spiv> lifeless: do we care about normal humans that might type "make check"?
[03:27] <lifeless> spiv: lets say we don't, and if we're wrong change it again
[03:28] <spiv> Heh.
[03:28] <spiv> Fair enough.
[03:28] <lifeless> its a fairly specialised interface
[03:28] <lifeless> spiv: alternatively, we can add a variable PQM can set
[03:28] <lifeless> but that seems like a round about way if few folk run 'make check'
[03:28] <spiv> lifeless: right
[03:29] <spiv> I'm ok with "just change it", as you say it's easy to undo if it causes trouble for someone.
[03:29] <lifeless> BasicOSX: hi!
[03:30] <lifeless> BasicOSX: I need feedback from you per bug ###(I forget, check your bugmail :P)
[03:30] <BasicOSX> hello
[03:32]  * igc lunch
[03:35] <davidstrauss> lifeless: Nope, but I can put you in touch with people from Plone.
[03:36] <spm> lifeless: spiv: fyi. that did it (ca-certs) have now moved onto a different problem, but progress :-)
[03:36] <emmajane> davidstrauss, turns out lifeless just doesn't know the difference between plone and drupal.
[03:36] <spiv> spm: cool
[03:37] <emmajane> :)
[03:37] <lifeless> davidstrauss: I don't really care about plone :P I was interested in the test discussion - see what emmajane and I covered after my gaffe
[03:38] <emmajane> lifeless, oh you'll never get to live it down. ;)
[03:39] <emmajane> davidstrauss, he was asking questions about the testing suite. I invented a couple of answers which may vaguely resemble the truth.
[03:39] <davidstrauss> emmajane: :-)
[03:41] <arkanes> are the pyrex-compiled C modules covered by the test suite?
[03:41] <lifeless> davidstrauss: did you end up getting your hudson foo on ?
[03:41] <lifeless> arkanes: yes
[03:41] <arkanes> yay
[03:41] <davidstrauss> lifeless: We're using Hudson for The Economist
[03:41] <arkanes> I experimeted with compiling them using cython instead, and I ran the test suite and everything was fine, but I wasn't sure if that was a good way to exercise them
[03:41] <lifeless> davidstrauss: yeah, when I ran into you in #hudson you were setting it up I think
[03:41] <davidstrauss> lifeless: And I am in touch with the developer of Bazaar-Hudson integration
[03:42] <arkanes> well, I ran bzr selftest, is that the right thing to do?
[03:42] <lifeless> arkanes: yup
[03:42] <lifeless> arkanes: as long as you've run make build
[03:42] <arkanes> hmm
[03:42] <arkanes> I did setup.py build insteadl
[03:42] <lifeless> (setup.py build -i
[03:42] <lifeless> it the inplace thats needed if you're testing in-tree
[03:43] <arkanes> I installed first, tested later :P
[03:43] <lifeless> thats fine
[03:44] <arkanes> cython support is somethign like a 4 line patch, correct procedure is to file a bug on launchpad & attach patch?
[03:45] <spiv> lifeless:
[03:45] <spiv> -	$(PYTHON) -Werror -O ./bzr selftest -1v $(tests)
[03:45] <spiv> +	$(PYTHON) -Werror -O ./bzr selftest -1v --subunit $(tests)
[03:45] <lifeless> arkanes: doc.bazaar-vcs.org/en, developer docs are there
[03:45] <lifeless> arkanes: that said, are you making it 'work with', or 'change it to use' cython ?
[03:45] <spiv> lifeless: look ok?  I guess -v is probably irrelevant now.
[03:45] <lifeless> spiv: -v is irrelevant
[03:45] <BasicOSX> lifeless:  not seeing request for feedback, got bug number?
[03:46] <arkanes> lifeless: work with
[03:46] <lifeless> spiv: separately I'd like to discard the -1, but that may need discussion
[03:46] <arkanes> lifeless: as in, fall back to cython if pyrex is not present
[03:46] <spiv> lifeless: yes
[03:46] <lifeless> arkanes: ok, cool. We don't want to depend on cython at this point as its not as widely available as pyrex (we support python 2.4 platforms)
[03:47] <arkanes> yeah, I use cython and don't keep pyrex around so I just wanted it to work in that environment
[03:47] <spiv> lifeless: if you make the test suite fast enough I'm sure people won't mind if -1 is left off ;)
[03:48] <spiv> lifeless: ok, pqm-submitting that to bzr.dev.
[03:48] <lifeless> spiv: well most submissions should land, and most failures may have multiple things wrong with them
[03:48] <lifeless> spiv: :)
[03:55] <spiv> lifeless: talk to oubiwann about PyCon, I think he knows stuff.
[03:56] <oubiwann> lifeless: you gonna submit?
[03:56] <spiv> lifeless: also, http://pqm.bazaar-vcs.org/: Running [ 3% 552 test(s) 3 failure(s) 5 errors(s) ] ...
[03:56] <oubiwann> (tomorrow's the last day for proposals)
[03:56] <spiv> Given the -1, I guess those are skips and known failures...
[03:57] <lifeless> oubiwann: looking at the web site stuff now
[03:57] <lifeless> spiv: \o/
[03:58] <lifeless> sexy
[03:58] <oubiwann> lifeless: awesome
[03:58] <lifeless> oubiwann: I'm wondering about aid
[03:58] <oubiwann> ah, yeah
[03:58] <oubiwann> it's not granted for speakers, but speakers are encouraged to apply
[03:58] <lifeless> 'we' don't seem to know who we'll send or not, so I have to work on the basis that I may be solo if I submit
[03:58] <oubiwann> (for aid)
[04:00] <lifeless> oubiwann: are you on TIP?
[04:07] <oubiwann> lifeless: TIP?
[04:10] <lifeless> testing in python
[04:10] <lifeless> oubiwann: this is what I would submit a pycon talk about: - would you come to see it? http://rbtcollins.wordpress.com/
[04:11]  * oubiwann checks it out
[04:12] <oubiwann> lifeless: oh HELLZ YEAH
[04:15] <lifeless> oubiwann: glad you like it :)
[04:28] <lifeless> vila: aren't you meant to be sleeping?
[04:31] <lifeless> spiv: I like the pqm output
[04:31] <lifeless> feels much more usable to me
[04:31] <lifeless> do you ?
[04:50] <emmajane> beuno, just got feedback from someone who couldn't find the option to download builds on code.edge.launchpad.net/bzr. Not sure if you wanted a UI bug submitted for LP?
[05:00] <arkanes> I've got a branch I'd like to submit back to bzr but the instructions on http://bazaar-vcs.org/BzrGivingBack conflict slightly with the launchpad UI, is "lp:bzr" the correct target branch?
[05:04] <emmajane> arkanes, you'll upload things to your own workspace on LP and then submit a merge request.
[05:04] <lifeless> oubiwann: http://us.pycon.org/2010/conference/proposals/127/
[05:04] <oubiwann> lifeless: thanks!
[05:04] <emmajane> arkanes, http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html#submitting-changes this has more info
[05:04] <lifeless> oubiwann: its insane
[05:04] <spiv> lifeless: yeah, it's much nicer to have the percentage.
[05:05] <lifeless> it thinks canonical's homepage is rbtcollins.wordpress.com.  I don't know how to fix that
[05:05] <spiv> lifeless: the non-zero failure and errors are a bit alarming, though.
[05:05] <lifeless> oubiwann: ^
[05:06] <spiv> lifeless: curiously, I saw "Current test: None
[05:06] <spiv> " at one point.
[05:06] <spiv> (67% of the way through)
[05:08] <lifeless> spiv: yes, it means one test finished, the next had not started
[05:09] <spiv> Yeah, not unreasonable.
[05:09] <lifeless> oubiwann: oh, I get it.  The bio 'link' links to affiliation, not the author. BAH
[05:10] <lifeless> >bah<
[05:19] <emmajane> Stating the obvious: We don't have a .dmg for installing Explorer and we don't seem to have install instructions.
[05:19] <emmajane> (on OSX)
[05:23] <emmajane> igc, ping?
[05:24] <igc> hi emmajane
[05:24] <emmajane> igc, hey :)
[05:24] <emmajane> igc, the woman who solved the nav bar problem for me is trying to install bzr! *woot!*
[05:24] <igc> excellent
[05:24] <emmajane> she's on OSX though and keeps getting errors that are getting progressively harder for me to google.
[05:24] <emmajane> she's trying to get Explorer working
[05:25] <igc> :-(
[05:25] <emmajane> yeah
[05:25] <emmajane> do you know anything about Explorer on OSX?
[05:25] <igc> she ready needs to wait for the desktop installer to arrive
[05:25] <igc> verterok is working on it
[05:25] <emmajane> cool!
[05:25] <emmajane> will it be ready "soon" or is it a long term project?
[05:25] <igc> emmajane: installing Qt on OS X is easy
[05:26] <igc> emmajane: but PyQt is a pain in the butt
[05:26] <emmajane> she's getting errors about SIP?
[05:26] <emmajane> yeah
[05:26] <igc> igc: I have done it in the past but it wasn't fun
[05:26] <emmajane> :/
[05:26] <emmajane> that's what she's running into as well.
[05:27] <igc> it's *ready* important verterok gets that installer done - hassle him when he's next online!
[05:27] <emmajane> <jacine> jacinembp:PyQt-mac-gpl-4.6 jacine$ python configure.py
[05:27] <emmajane> <jacine> Traceback (most recent call last):
[05:27] <emmajane> <jacine>   File "configure.py", line 37, in <module>
[05:27] <emmajane> <jacine>     import sipconfig
[05:27] <emmajane> <jacine> ImportError: No module named sipconfig
[05:27] <emmajane> that's as far as she got.
[05:27] <igc> emmajane: I can't remember sorry
[05:27] <verterok> emmajane, igc: hi :)
[05:28] <igc> emmajane: emailing the bzr-mac list is a good idea though
[05:28] <emmajane> verterok, hey ! :)
[05:28] <igc> hi verterok!
[05:28] <igc> I was hoping you'd pop up
[05:28] <jacine> hi! :)
[05:28]  * emmajane waves at jacine 
[05:28] <igc> hi jacine
[05:28] <jacine> hi emmajane, igc ;)
[05:29] <verterok> jacine: hi
[05:29] <emmajane> jacine is a designer/themer with Drupal and fixed the nav bar. We love jacine ! :)
[05:29] <jacine> thanks for helping me get started :)
[05:29] <jacine> hi verterok
[05:29] <verterok> emmajane, jacine: here is a somewhat good step by step to get PyQt installed: http://www.oak-tree.us/blog/index.php/2009/05/12/pyqt-mac
[05:30] <emmajane> verterok, can we get this added to the OSX install instructions either on the Wiki or in the Official Docs?
[05:30] <jacine> hmm, reading
[05:30] <verterok> igc: do you know if there is requirement on a specific pyqt/qt version? (for qbzr/explorer)
[05:30] <igc> verterok: Qt 4.4 or later
[05:30] <verterok> jacine: be carefull with the version ^ I don't know if qbzr works with PyQt 4.5
[05:30] <verterok> igc: oh, ok. thanks! :)
[05:30] <jacine> ok verterok, thx
[05:31] <emmajane> verterok, jacine is involved with the Drupal design community as well. Having an .dmg would make it way easier to promote bzr within Drupal. Is the installer going to be ready "soon" for OSX? I have no idea how hard these things are.
[05:31] <igc> verterok: Qt 4.5 should be fine - that's the version on jaunty
[05:31] <verterok> emmajane: we could add this to the wiki...don't know in which place :)
[05:32] <jacine> emmajane: ya, so far this is much harder to get running compared to CVS ;)
[05:32] <emmajane> verterok, http://bazaar-vcs.org/QBzr ?
[05:32] <emmajane> jacine, hehe
[05:32] <emmajane> jacine, y'think? ;)
[05:32] <jacine> hehe, and I have Xcode ;)
[05:32] <emmajane> verterok, and http://doc.bazaar-vcs.org/explorer/en/install-osx.html ?
[05:33] <verterok> emmajane: thanks to jfroy that showed me an alternative way of building the packages I think it's going to be easier than using the previous approach...but I still need to get it working ;)
[05:33] <emmajane> I had igc 's branch downloaded and ready to update the docs and then we just kept getting more nad more errors.
[05:33] <emmajane> \o/
[05:33] <emmajane> easier is gooder :)
[05:36] <verterok> emmajane, jacine: I'll work on this tomorrow, probably for OS X 10.5 first as I'll have access to my 10.4 ibook probably during the weekend
[05:36] <jacine> cool
[05:36] <emmajane> verterok, awesome. thank you! :)
[05:37] <emmajane> igc, search is working thanks to kirkland and the nav bar is working thanks to jacine :)
[05:37] <jacine> hehe ;)
[05:44] <igc> emmajane: that's great news - well done
[05:45] <emmajane> :)
[05:45] <igc> verterok: I'm happy to test your installer on 10.4 when it's ready
[05:46] <emmajane> I think jacine said she's on OSX?
[05:46] <emmajane> erg 10.5 rather
[05:46] <emmajane> <--- tired bear
[05:46] <jacine> yeah, 10.5 :)
[05:46] <igc> emmajane: must be time for some sleep soon :-)
[05:46] <emmajane> igc, yeah. the anticipation of Explorer almost working for jacine is keeping me up :)
[05:47] <jacine> haha ;) well, I'm gonna make it happen emmajane!
[05:47] <emmajane> WOOT!
[05:48] <igc> emmajane: another minor thing: the Bazaar logo is being clipped in ff 3.0 on jaunty. Can you move it right a bit?
[05:48] <emmajane> igc, it's probably easier just to make the text smaller?
[05:48] <igc> maybe left-align it with the Home area in the nav bar?
[05:49] <emmajane> it should have loads of room though. hm
[05:50] <emmajane> http://browsershots.org/screenshots/f8ab0781362b8fc8e1920f59c3cac3c4/ <-- from earlier tonight
[05:50] <emmajane> igc, is it your fonts?
[05:51] <emmajane> OOOoo. logo, not text.
[05:51] <emmajane> how wide is your browser?
[05:51] <igc> emmajane: how can I easily tell?
[05:51] <emmajane> is it basically the width of the page?
[05:51] <emmajane> the design rather
[05:52] <emmajane> I shifted the logo to the left so that it pointed into the middle of "home"
[05:52] <igc> emmajane: there's no horinzontal scrollbar fwiw
[05:52] <emmajane> but on narrower screens the amount of shift can be clipped.
[05:53] <kirkland> emmajane: \o/
[05:53] <emmajane> kirkland, :)
[05:53] <emmajane> kirkland, again, you rock! :)
[05:54] <igc> emmajane: I'm on 9.04 btw
[05:55] <emmajane> igc, I'm 9.04 FF 3.0.14.
[05:55] <emmajane> igc, if you make your window a tad wider, does the clip go away?
[05:55] <emmajane> I just want tomake sure I'm solving the right problem. :)
[05:55] <igc> emmajane: wider fixes the problem
[05:56]  * emmajane nods
[05:56] <igc> emmajane: it is truly center aligned with "Home" - that just is too far left
[05:56] <emmajane> let me add +30px to Home and leave the logo where it wants to be.
[05:57] <igc> emmajane: left-aligned with the text below will look better
[06:01] <emmajane> igc, uploaded
[06:01] <igc> emmajane: fixed. Thanks!
[06:02] <emmajane> awesome!
[06:02] <emmajane> igc, I saw your note about the news too
[06:02] <emmajane> I'm not loving it at the bottom, and don't mind if the headlines are in the banner space.
[06:02] <igc> emmajane: ah good
[06:03] <igc> emmajane: poolie wants it to look like news though
[06:03] <emmajane> i'm still feeling a bit gunshy about posting things to the list after the stuff last week.
[06:03] <igc> emmajane: so it needs a box and maybe some little news icon to highlight it if we move it there
[06:03] <emmajane> bleh
[06:03] <emmajane> dancing monkeys! :)
[06:03] <igc> emmajane: wecome to my world :-)
[06:04] <emmajane> lol
[06:04] <igc> emmajane: open source development isn't kind on the ego :-)
[06:04] <emmajane> igc, we still have some of the designer's time if you wanted me to ask him to solve it. but more direction is better than "be creative" ;)
[06:04] <emmajane> igc, heh. y'think? :)
[06:04] <igc> emmajane: there's a new critic every day!
[06:05] <igc> emmajane: I think we need approval in principle from poolie first
[06:05]  * emmajane nods
[06:05] <emmajane> there is time left there, so don't feel that you or I *needs* to solve it. :)
[06:06] <emmajane> to my eye I want the text on the left to be bigger so taht the news isn't lonely on the bottom right.
[06:06] <emmajane> I wanted to keep the logos as a divider/end of page summary (which is why I took them out of the left side)
[06:07] <emmajane> bigger/longer/other
[06:07] <emmajane> (for left text)
[06:08] <igc> emmajane: maajane: bumping the LHS up a text size is worth a try - it may stand out more then
[06:08] <igc> typo sorry
[06:08] <emmajane> kay
[06:15] <igc> bbiab
[06:15] <emmajane> hrm. if I do that the headings don't line up nicely. /me plays more
[06:16] <spm> beating my head against the brickwall here. "bzr: ERROR: Connection error: Unable to authenticate to SSH host as" AFAICT, we have the right ssh setup and all; but clearly not. Suggested places I could/should be looking?
[06:17] <spiv> As a bzr error?  I guess that means it's using paramiko...
[06:17] <spiv> I'm a bit surprised its not using OpenSSH.
[06:17] <spm> spiv: yeah, bzr info bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/ by way of example
[06:18] <spiv> Not that it should matter either way.
[06:18] <spm> spiv: ahhh. are you implying that's a different package we're missing? I don't have ssh (the binary) in this chroot so... ?
[06:19] <spiv> Well, bzr will happily enough fallback to paramiko if /usr/bin/ssh doesn't exist.
[06:19] <spiv> And judging from that error it appears to be doing so just fine.
[06:19] <spiv> But presumably it's trying either the wrong username and/or key.
[06:19] <spm> oh I dunno - it doesn't read as "happy" to me. fallback sure. ;-)
[06:20] <spiv> The 'fallback-to-paramiko' part is happy.  That doesn't mean that the rest of it is ;)
[06:20] <spm> heh
[06:21] <spm> so is the paramiko side going to be doing the right ~/.ssh/config bits? or... ?
[06:21] <spm> should i be adjusting in ~/.bazaar/authentication.conf ?
[06:22] <spiv> I think it'll prefer authentication.conf
[06:22] <spiv> I'm not sure if it will try use ~/.ssh at all.  I'm not very familiar with what config paramiko uses.
[06:22] <emmajane> igc, the bigger font size on LHS ends up being distracting.
[06:23] <spiv> (or our glue for it)
[06:23] <jacine> igc: verterok, emmajane!  got it! :)  Thank you so much!
[06:23] <emmajane> jacine, WOO! :)
[06:23] <spm> hmmm. 'k.
[06:23] <jacine> yay ;)
[06:23] <spiv> I'd be inclined to just install openssh-client, personally, because I know the config for that quite well :)
[06:23] <lifeless> paramiko doesn't use the ssh config, does it ?
[06:24] <emmajane> jacine, let me know what can be added where to make the instructions easier. I'm not sure if the installer will include everything verterok ?
[06:24] <jacine> emmajane: actually, this was perfect: http://www.oak-tree.us/blog/index.php/2009/05/12/pyqt-mac
[06:24] <spiv> lifeless: I don't *think* so, but I'm not at all sure.
[06:24] <emmajane> jacine, cool!
[06:24] <lifeless> ok, benefits of starting at 0630; gnight :)
[06:24]  * lifeless waves ciao
[06:24] <jacine> emmajane: i think we would just need to pull the other parts in...
[06:24] <spm> spiv: heh; from what I can see, the only missing piece'd be the specifying of the IdentityFile, as it's not the default
[06:24] <spm> night lifeless
[06:25] <spiv> lifeless: move to NZ already :P
[06:25] <spiv> lifeless: g'night :)
[06:25] <jacine> emmajane: gonna save the links and summarize what I did before that part and send it to ya... after I create a test project.
[06:25] <emmajane> jacine, awesome. I'm going to update the wiki right now to add that URL.
[06:26] <spm> spiv: ARGH. cp id_rsa-ODDNAME id_rsa and same for the .pub == success. ARGH.
[06:29] <emmajane> jacine, I updated the wiki to include that URL.
[06:29] <jacine> where is the wiki, sorry, tab overload here...
[06:30] <emmajane> http://bazaar-vcs.org/QBzr
[06:30] <jacine> thanks :)
[06:30] <emmajane> np
[06:32] <emmajane> verterok, https://twitter.com/joncruz/statuses/4518006753 <-- you've got volunteers to help with the installer. :)
[06:36] <emmajane> ok. sleep f'reals this time.
[06:37] <jacine> emmajane: I'll e-mail u a link to what I'm writing
[06:37] <jacine> thanks again for everything :)
[06:37] <jacine> u guys rock!
[06:37] <emmajane> jacine,  thanks for stickign with it. very very very much appreciated.
[06:37] <jacine> ;)
[06:38] <emmajane> jacine, also? thanks for fixing the nav bar. very^3 appreciated. :)
[06:38] <jacine> anytime emmajane :)
[06:38] <emmajane> :)
[06:38] <emmajane> don't be making offers like that ;)
[06:38] <jacine> hehe ;)
[08:04] <bialix> hello bzr
[08:05] <Peng_> Hi
=== AfC1 is now known as AfC
[08:39] <poolie> hello all
[08:40] <poolie> hi jelmer?
[08:52] <bialix> hi poolie
[08:53] <poolie> hello bialix
[08:53] <bialix> poolie: as I understand big announce is delayed so I'm planning to release qbzr 0.14.3 soon
[08:54] <bialix> there is several important bug fixes
[08:54] <bialix> I hope jam won't object to build another installer
[08:54] <poolie> ok
[08:55]  * bialix hopes there is still possible to update packages in Karmic
[08:57]  * igc dinner
[08:57] <poolie> sorry, back into meetings...
[08:57] <poolie> bialix: with bug fixes, yes
[08:58] <bialix> good
[10:06] <jelmer> poolie: hi
[10:13] <poolie> hi jelmer
[10:29] <StyXman> I have an original branch/repo where I've been commiting all my changes so far. now I setup a project in savanah, which gives me a bazaar repo, and I intend to import all the history there. should I branch the savannah repo, then pull from my repo into this branch, and then push into savannah? did I get it right?
[10:32] <Peng_> StyXman: Just push to Savannah from your original branch.
[10:36] <naoki> hi jelmer
[10:37] <jelmer> hi naoki
[10:37] <naoki> jelmer: I can branch from git:// on Windows!  https://bugs.launchpad.net/bzr-git/+bug/382125/comments/10
[10:37] <ubottu> Launchpad bug 382125 in bzr-git "Can't branch from remote repository on Windows" [Undecided,New]
[10:38] <naoki> I attached quick fix patch. Please confirm.
[10:41] <naoki> I think bzr-git may be a killer-app for bzr on Windows, because git on Windows requires msys or cygwin. Gread job! jelmer.
[10:51] <bialix> naoki: cool! \o/
[11:30] <jelmer> naoki: thanks
[11:31] <jelmer> naoki: couldn't we just eliminate that assert ?
[11:37] <naoki> jelmer: I tryed it, but next line also uses  "self.index"
[12:01] <jelmer> naoki: any chance you can try with current trunk?
[12:01] <jelmer> I've pushed an alternative fix
[12:08] <naoki> OK!
[12:08] <naoki> It works!
[12:11] <jelmer> naoki: great :-)
[12:11] <jelmer> naoki: what about the other warning?
[13:06] <jelmer> naoki: ?
[13:16] <SamB_XP> jelmer: you really need to get together with whoever does the bzr nightly PPA and figure out what's going on with bzr-doc ...
[13:24] <jelmer> SamB_XP: ? The PPA's are only for Ubuntu aren't they?
[15:21] <abentley> jam or vila: Where is the 2.0.0 branch?  I can't find it on https://code.edge.launchpad.net/~bzr-pqm/ or bazaar-vcs.org/bzr
[15:21] <jam> abentley: all pqm branches are now on launchpad
[15:21] <jam> 2.0.0 is ~bzr-pqm/bzr/2.0.0
[15:22] <jam> 2.0 stable is ~bzr-pqm/bzr/2.0
[15:22] <jam> trunk is ~bzr-pqm/bzr/bzr.dev
[15:23] <abentley> jam: Oh, I guess 2.0.0 is hidden because it's been merged into 2.0.
[15:23] <abentley> jam: Thanks.
[15:24] <jam> abentley: ah hidden from the main view?
[15:24] <jam> thats a shame
[15:24] <jam> given that we fully intend to continually 'merge up'
[15:24] <jam> 2.0.0 => 2.0 => bzr.dev
[15:25] <abentley> jam: Yeah.  I'm marking it as "development", which a new commit would do anyway.
[15:25] <jam> I'm pretty sure we don't expect another commit on 2.0.0
[15:26] <abentley> jam: I think the same thing won't happen to 2.0, because it's associated with a series.
[15:27] <abentley> jam: getting perfect rules for this stuff is hard...
[15:27] <jam> yeah
[15:30] <macflag> does bzr support database version control?
[15:31] <abentley> jam: The significance of 2.0.0 isn't the fact that it may or may not be under development, it's the fact that it corresponds with a release.
[15:31] <jam> abentley: yeah, but I think lp only has that for a series, right?
[15:31] <jam> macflag: not explicitly, though you can certainly version your sql dumps
[15:31] <abentley> jam: Right.
[15:31] <arkanes> so when I do "bzr pull" and there's some merges, is there a trivial option I can pass to bzr diff that's basically "diff this and the branch it was before I just updated", or do I have to look back and figure out what revision number that was?
[15:31] <macflag> jam: how economical and accurate is that?
[15:32] <arkanes> macflag: versioning databases is hard because they're running images, not something you can update with a textual diff
[15:32] <abentley> arkanes: I don't think there's a direct way, because we don't keep a record of what pull did.
[15:33] <arkanes> abentley: yeah I figured. i just do this so often, looking at the files changed in a pull and then wanting to know what got merged.
[15:33] <macflag> arkanes: i'm working with reasonably small databases, does this change your answer?
[15:33] <arkanes> macflag: not really
[15:34] <abentley> arkanes: You want to know which of your local changes were merged?
[15:34] <arkanes> macflag: the nature of a database is that it's a running image that you modify in place, rather than traditional development where you build something from an authorative source
[15:34] <arkanes> abentley: I don't have local changes, it was just updates from the pull
[15:35] <abentley> arkanes: When you say "wanting to know what got merged", what's an example of something that might have been merged?
[15:36] <arkanes> abentley: well in this specific case i updated by bzr.dev branch
[15:36] <macflag> arkanes: yeah i know, but *theoretically* there must be some format or "instantiation" to which i can convert a database, which is more suited for running diffs against, or am i wrong?
[15:37] <arkanes> and there was a change to doc/developers/HACKING.txt and I'm curious to know what that was, since I just started contributing
[15:37] <arkanes> macflag: sure, the sql dumps
[15:37] <Lo-lan-do> macflag: SQL dumps could be that, if you added something to guarantee that rows always get out in the same order.
[15:37] <arkanes> macflag: but without the cooperation of the database itself, and some smart diff tools (since a simple textual diff won't do), it can be awkward and error prone to do it
[15:38] <arkanes> macflag: if you're using an embedded database like sqlite, just sticking the binary DB file in there works too
[15:38] <abentley> arkanes: So I think you care about changes, not just merges.  Hmm, we've been talking about adding diff support to pull for ages, but it looks like that hasn't been done.
[15:39] <arkanes> abentley: sorry, yes, I want to know what changed, not specifically was merged
[15:39] <arkanes> I said merge because there was an M next to the file name :)
[15:39] <abentley> arkanes: You can always do "bzr pull -c $REVISION" where $REVISION is the one that modified HACKING.
[15:39] <abentley> arkanes: Sorry, diff -c ...
[15:39] <macflag> arkanes: i am not familiar with bzr, so by "embedded" do you mean bzr has such sqlite support?
[15:40] <arkanes> macflag: no
[15:40] <arkanes> macflag: sorry, getting a little misleading
[15:41] <arkanes> macflag: sqlite is a self-containted database, there is no server, so the single datafile contains the entire thing and versioning it as a binary file is sufficient to version the database
[15:42] <arkanes> it sounds like thats not what you're using though so don't get derailed :)
[15:42] <macflag> :)
[15:42] <arkanes> abentley: hmm it looks like -c is basically exactly what I want
[15:43] <macflag> arkanes: just curious, is "diff-able database support" something that we can expect vcs's to start to feature any time soon?
[15:43] <arkanes> maybe it should default to your current revision instead of making you look it up
[15:43] <arkanes> macflag: not really
[15:43] <macflag> arkanes: no demand, or too difficult?
[15:43] <arkanes> macflag: it's something that the database vendors need to start with, and they could use a vcs engine like BZR to implement
[15:43] <abentley> arkanes: Cool.
[15:44] <arkanes> yeah it gave me the diff I wanted
[15:44] <macflag> arkanes: so the answer is "it's not what vcs's are supposed to do", right?
[15:45] <arkanes> it's more that the way database engines are built makes them unsuitable for versioning by generic VCS tools
[15:46] <Meths> At the end of the day if you want to version control the DB schema you just version control a SQL create script.  If you want to version control data, that's what backups are for.
[15:46] <arkanes> versioning running objects in memory is a very different problem than versioning a filesystem tree
[15:47] <arkanes> document based stuff like couchdb should be more amenable
[15:47] <lifeless> abentley: would 'mature' work (for 2.0.0 ?)
[15:47] <lifeless> davidstrauss: bug 276449, if you could comment that would be great
[15:47] <ubottu> Launchpad bug 276449 in bzr "Bzr traceback when branching/pushing" [Undecided,Incomplete] https://launchpad.net/bugs/276449
[15:47] <macflag> is any other vcs system equipped for database versioning any better than bzr?
[15:47]  * lifeless crashes
[15:47] <abentley> lifeless: I don't remember the implications, but it's easy to find out.
[15:48] <Meths> macflag: Firstly you haven't defined "database versioning" - schema, data or both.
[15:48] <macflag> Meths: both
[15:49] <abentley> lifeless, jam: Mature looks like a good status for 2.0.0
[15:49] <Meths> macflag: Secondly all VCSs are pretty much the same, they can all version a SQL script but none will version a binary blob.
[15:50] <abentley> Meths: Most VCSes will version a binary blob, they just can't diff it.
[15:50] <Meths> macflag: So either use the DB backup system for your database to create backups at version changes (or whenever you need them) or dump the SQL at various intervals
[15:51] <macflag> Meths: also, what about data only?
[15:51] <Meths> abentley: ah, true
[15:51] <Meths> macflag: data can be dumped or backed up
[15:52] <Meths> macflag: It's data that takes you to dumping or backing up for the "both" scenario too
[15:52] <macflag> Meths: so i guess dealing with dumped data only would be absolutely fine, right?
[15:52] <macflag> Meths: actually i don't need to deal with both
[15:54] <Meths> macflag: Depends, the biggest issue with database versioning is that data for a new schema won't easily load back into an old schema, so versioning independently is just one big headache - hence all DBMSs support backups and none (AFAIK) support version control
[15:55] <macflag> Meths: for example, when / how often does mediawiki generate a new schema?
[15:55] <Meths> no idea, read their release notes
[15:56] <macflag> not so often i think, so i guess i could deal with such steps manually
[15:56] <macflag> and then i could stick to dumped data diffing
[16:01] <Lo-lan-do> When merge requests are sent to the bzr devs, they go to a pqm, right?
[16:04]  * Lo-lan-do thinks his 2009-05-07 patch should be either accepted or rejected
[16:04] <macflag> Lo-lan-do: what's the third option?
=== thekorn_ is now known as thekorn
[16:05] <Lo-lan-do> Apparently, "simply ignored".
[16:07] <Lo-lan-do> I'm tempted to add "presumed forgotten".
[16:07] <luks> that's quite popular option, unfortunatelly
[16:10] <Lo-lan-do> I thought pqm was there to keep track of merge requests?
[16:10] <abentley> Lo-lan-do: No, merge requests are tracked on Launchpad.
[16:10] <abentley> Lo-lan-do: PQM simply performs the merge when it's been approved.
[16:12] <Lo-lan-do> Ah, got it wrong then.  But my bundle sent to the list was forwarded to Launchpad though, right?
[16:13] <abentley> Lo-lan-do: No.  It would hopefully be tracked in bundle buggy, but that's not being used anymore.
[16:14] <Lo-lan-do> O-kay, so the bundle's status *is* "forgotten".
[16:15] <abentley> Lo-lan-do: Yes.  If you look at the list of unreviewed stuff on Launchpad, it's pretty short: https://code.edge.launchpad.net/bzr/+activereviews
[16:16] <Lo-lan-do> I see.
[16:17] <Lo-lan-do> I guess I'll rebase onto trunk and send a new bundle then.
[16:18] <abentley> Lo-lan-do: Sure.  You'll want to use merge@code.launchpad.net as the address and specify the branch on launchpad you want to merge into.
[16:19] <abentley> Lo-lan-do: I recommend lp:bzr
[16:21] <Lo-lan-do> Will do.  Currently converting the local branch to 2a, which seems to take some time.
[16:29] <abentley> james_w: I am making a custom "distribution" of bzr 2.0.0 with 4672:lp:/bzr/2.0 applied.  I am having trouble setting up the right version numbering so that zc.buildout likes it.  Any ideas?
[16:33] <jam> spiv: are you still around?
[16:37] <james_w> abentley: afraid not, I've never used buildout
[16:40] <jam> abentley: it seems to me that if you just did a custom 2.0.1b1 or rc1 would be easier
[16:40] <jam> take the current 2.0 branch, and package it
[16:42] <abentley> james_w: It installs packages using the standard setup.py foo.  I just don't know if it's appropriate to change bzrlib.version_info to (2, 0, 0, 'launchpad', 0) or what.
[16:42] <james_w> I think bzr will reject that
[16:43] <james_w> you could tweak the last number, but that may not be enough
[16:43] <james_w> you could make it (2, 0, '0lp', 'release', 0)
[16:43] <james_w> but that might not sort correctly
[16:43] <abentley> james_w: What's the right way to tweak a package number that has distro-specific changes?  Where your target version number is something like 2.0.0-ubuntu-1 ?
[16:44] <james_w> we don't tweak the version in setup.py
[16:44] <james_w> we just do it from the package version number
[16:44] <jam> abentley: if you look it bzrlib.__init__.py _format_version_tuple
[16:44] <jam> we only support 'alpha' 'beta' 'final' 'dev' and 'candidate' in that field
[16:45] <jam> all others must be pure integers ('%d' formatting)
[16:46] <jam> so I would recommend "2.0.1a1" if that works best for you
[16:50] <abentley> jam: Okay, I'll give that a go.
[16:52] <abentley> jam: Would deprecation warnings be suppressed for an alpha?
[16:52] <jam> abentley: no
[16:52] <jam> only for 'final'
[16:52] <jam> bzrlib.commands.main:
[16:53] <jam> # Is this a final release version? If so, we should suppress warnings
[16:53] <jam> if bzrlib.version_info[3] == 'final':
[16:53] <jam>     suppress_deprecation_warnings(override=False)
[16:53] <jam> though I've noticed that it doesn't actually work with python2.6, because something on my path is also adding a deprecation warning
[16:53] <abentley> jam: *facepalm*
[16:53] <jam> so you actually need "override=True".
[16:55] <poolie> hi jam, abentley
[16:56] <abentley> poolie: Hi.
[16:59] <jam> hi poolie
[17:03] <abentley> jam: I think I'm going to replace bzrlib.__version__ with '2.0.0-lp-1' in setup.py.
[17:08]  * Lo-lan-do ponders adding a --no-remember option to bzr push
[17:09] <Lo-lan-do> Would that have a chance of being accepted?
[17:10] <abentley> Lo-lan-do: bzr already has a --no-remember option.
[17:10] <jam> abentley: though I don't think we pay attention to it...
[17:11] <jam> in the case that there is no current default push location, it always gets set
[17:11] <jam> Lo-lan-do: you could probably turn the 'remember' field into a tri-state boolean (True, False, None)
[17:11] <jam> whatever you would call that other than boolean .. :)
[17:12] <jam> Lo-lan-do: or are you looking for a --forget option?
[17:12] <abentley> jam: We pay attention to it, it just disables a previous --remember.
[17:13] <jam> abentley: I just mean that internally --no-remember is equivalent to not passing --remember
[17:13] <jam> which is different than saying "don't remember this path even though there is nothing already set"
[17:13] <jam> if you change the run(..., remember=None) then we can tell the difference
[17:14] <abentley> jam: Sure.  I did write the code that adds those hidden inversion options.
[17:15] <abentley> jam: When it gets up to trinary, I usually use strings: "yes", "no", "auto".
[17:19] <Lo-lan-do> Sorry, my mum chose this particular moment to phone :-)
[17:19] <vila> abentley: Isn't it ternary ? I ask before I jokingly use tri-lean in French as opposed to boo-lean...
[17:20] <Lo-lan-do> I was thinking of making the remember a tristate, yes, *and* getting it not ignored when no default is set.
[17:21] <Lo-lan-do> But a --forget option would be nice, independently.
[17:21] <abentley> vila: It looks like ternary is preferred, but both are used.
[17:22] <vila> but otherwise, I've a strong preference for True, False, None myself as the extended boolean, because it perfectly matches to "I know it's true, I know it's false or I don't know"
[17:22] <vila> abentley: thks
[17:23] <abentley> vila: If None didn't evaluate to False in python, that would be okay with me, but I think explicit description of behavior is clearer.
[17:25] <vila> abentley: good point, my coding style generally compensates  that by using 'if xx is None' before attempting 'if xx'
[17:28] <Lo-lan-do> How long does it usually take for merge requests to show up on https://code.launchpad.net/bzr/+activereviews ?
[18:28] <jam> Lo-lan-do: usually fairly close to immediate, I believe
[18:29] <jam> are you sure you had the right submission target?
[18:30] <Lo-lan-do> I used "bzr send --mail-to merge@code.launchpad.net lp:bzr"
[18:31] <Lo-lan-do> (As suggested by abentley)
[18:40] <jam> Lo-lan-do: I have very little clue about merge-by-email, I always just push a branch up and click the "propose this branch for merging" link.
[18:41] <jam> poolie: poke on https://code.edge.launchpad.net/~jameinel/bzr/2.0-cache-cix/+merge/11465
[18:42] <jam> that, and you seem to have 2 branches 'approved for merging" on the active reviews page
[18:42] <_oggy> hi, i need to interface with an svn repo. the repo uses svn:externals. i know that up until a few months ago, bzr (and hence bzr-svn) didn't support nested trees. with 2.0 out, what's the current status of that?
[18:42] <Lo-lan-do> jam: I guess I could push my branch, but I don't see a link to propose it for merging.
[18:43] <jam> if you look on my page: https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple
[18:43] <jam> Branch Merges
[18:43] <jam> Propose for merging
[18:44] <jam> about in the middle of the page, towards the left
[18:44] <jam> though you may not see it for *my* branches
[18:45] <Lo-lan-do> Oh, so it needs to be on Launchpad?
[18:46] <Lo-lan-do> I mean, I can't propose to merge a branch hosted elsewhere?
[18:46] <jam> Lo-lan-do: well, you can have lp mirror it, but Launchpad certainly needs to know about it
[18:46] <jam> I think you can register the branch to launchpad, and then propose it from there
[18:47] <Lo-lan-do> I guess I'd need a Launchpad account anyway.
[18:47] <jam> Lo-lan-do: you'd have to ask abentley for more info about sending requests by mail. I believe he does so regularly, I've *never* done so
[18:47] <jam> Lo-lan-do: ah, I think you need to gpg sign your merge request with a key that LP recognizes
[18:47] <Lo-lan-do> I'd rather stick with emails, yes.
[18:47] <jam> so you still need an account for email access
[18:48] <jam> so if you'd rather
[18:48] <jam> send it to me, and I'll propose it
[19:12] <poolie> hi jam, Lo-lan-do
[19:12] <poolie> jam, poke for a review?
[19:13] <poolie> ok, though probably not tonight :/
[19:13] <jam> poolie: yeah, its been sitting there for ~1month
[19:13] <poolie> sorry
[19:13] <jam> someone else can do it, but I thought we wanted it in the 2.0.x series
[19:13] <poolie> we should also have a look at moving reviews from bb
[19:13] <jam> and I thought you explicitly requested it, thus I wanted to give you first dibs at reviews
[19:13] <poolie> or finishing them off
[20:54] <bialix> hello jam
[20:57] <jam> hi bialix
[20:59] <bialix> jam, I'm planning to release qbzr 0.14.3 very soon. In particular there is important bug fix for TBZR users (bug #433137). I'd like to know is you keen to build new installer or I should strongly suggest to windows people upgrade via qbzr installer
[20:59] <ubottu> Launchpad bug 433137 in qbzr/trunk "[master] qcommit should support tree root as valid initial selection with pending merges" [Critical,Fix released] https://launchpad.net/bugs/433137
[21:02] <bialix> anybody knows does 'root:' revision id is supported inside bzrlib or this is unrelated to bzrlib?
[21:02] <jam> bialix: I believe "root:" is a generic file id for loggerhead indicating the root of the tree, but I'm not positive
[21:02] <jam> I'll build an installer if this is serious enough
[21:03] <jam> though I wonder about getting bugfixes in to the 2.0.1 release, rather than forcing everything into the 2.0.0-XXX releases
[21:03] <bialix> jam: well, we have several duplicates of this bug already
[21:03] <bialix> maybe 2.0.1 is better
[21:04] <bialix> maybe
[21:05] <bialix> I hope website stuff will be released soon, so 2.0 will go out officially
[21:06] <bialix> but https://launchpad.net/bzr/2.0 does not provide any hints about ETA for 2.0.1
[21:07] <jparker1> the release notes for 2.0 mention an "upgrade guide"; where is this?
[21:08] <jam> bialix: official position is "when reasonable based on bugfixes landed in 2.0.x branch", but something like 1 month post 2.0.0, though again we are having difficulties getting 2.0.0 official announced
[21:09] <bialix> jparker1: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html
[21:09] <jam> jparker1: note that on http://doc.bazaar-vcs.org/latest/en/ there is a Search box
[21:09] <bialix> jam: official position is related to bzr core I suppose, right?
[21:09] <jam> i believe it is the approved statement in 'cycle.txt'
[21:13] <bialix> jam: any way I will build qbzr installer.
[21:29] <idnar> argh
[21:30] <idnar> do I have to add a new entry to locations.conf to override a more general one?
[21:30] <idnar> I was hoping I could just do eg. bzr push --remember <differentlocation>
[21:35] <hsn> how do i resolve Conflicting tags issue during push?
[21:38] <awilkins> Anyone tell me an editor that doesn't append a line terminator to the last line?
[21:39] <hsn> vim?
[21:40] <awilkins> Nope. vim, gedit, and nano all seem to append line terminators where there were none before... trying to edit "location" in a transplanted lightweight checkout
[21:40] <awilkins> But it doesn't like the linefeed
[21:41] <awilkins> Appears the answer to my question is "cat"
[21:42] <awilkins> cat > location
[21:42] <awilkins> file:///home/adrian/branch/location^D
[21:43] <fullermd> I woulda gone with `echo -n` myself.
[21:43] <awilkins> I remember using that before too
[21:43] <hsn> vim: help endofline ->  When writing a file and this option is off no <EOL> will be written for the last line in the file.
[21:43] <fullermd> Though I think vim has a....   yeah, what hsn said.
[21:43] <awilkins> hsn: I don't actually believe it though, did you read all the caveats in that
[21:44] <awilkins> I don't think I got it to work
[21:44] <awilkins> I remember wrestling with it
[21:45]  * awilkins tries again
[21:45] <fullermd> I've never tried using it, so it may be harder than it sounds.
[21:46] <fullermd> Alternate crazy solutions include editing with $WHATEVER, then using dd or head to cut off the \n  ;)
[21:47] <brmassa> guys, im getting bzr: "ERROR: Permission denied: "/bazaartest": [Errno 13] Permission denied"
[21:48] <brmassa> what should i do?
[21:48] <hsn> sudo
[21:49] <brmassa> hsn: is it for me?
[21:49] <awilkins> Aha, you have to pass -b to vim
[21:49] <awilkins> Then it automatically remembers the no-line-endingness
[21:53] <brmassa> ??
[22:00] <antoranz> Hi, guys!
[22:01] <antoranz> why doesn't bzr ask for ssh password (using bzr+ssh or sftp) on windows?
[22:02] <antoranz> it says that the only available methods to authenticate are password and keys.... but it doesn't ask for the password in the first place
[22:08] <bob2> sure the remote server supports paassword auth?
[22:09] <SiDi> Hi there
[22:09] <antoranz> well.... yes, I can login (server asking for the password) on that hohst by ssh
[22:09] <SiDi> Is there a method to allow people to code without them to have an account with an actual shell defined ?
[22:10] <SiDi> s/to code/to push code/
[22:10] <antoranz> when it fails, bzr says: supported auth types: ['publickey', 'keyboard-interactive']
[22:17] <antoranz> also, ssh password authentication works like a charm if I run bzr from a GNU/Linux box against that ssh server
[22:19] <awilkins> SiDi: If you set their shell to /bin/false in the /etc/passwd file that will prevent them using a shelll
[22:20] <awilkins> Or not .... http://www.semicomplete.com/articles/ssh-security/
[22:21] <SiDi> awilkins: but that'll break bzr+ssh:// :/
[22:21] <bob2> look in the contrib dir in the bzr source
[22:22] <SiDi> will do, thanks
[22:22] <awilkins> Which, /bin/false, or setting AllowGroups?
[22:23] <awilkins> /bin/false shouldn't break bzr+ssh:// AFAIk
[22:32] <awilkins> Ok, it does
[22:32] <awilkins> I'm an idiot
[22:34] <SiDi> awilkins: if it can make you feel better, i discovered it did by constating it
[22:45] <abentley> awilkins: bzr+ssh runs bzr on the remote machine.  That's all it needs to be able to run.
[22:54] <lifeless> moin
[23:08] <lifeless> davidstrauss: bug 276449, if you could comment that would be great
[23:08] <ubottu> Launchpad bug 276449 in bzr "Bzr traceback when branching/pushing" [Undecided,Incomplete] https://launchpad.net/bugs/276449
[23:26] <davidstrauss> lifeless: Sorry, that's pretty ancient
[23:26] <davidstrauss> lifeless: I'd have to contact that (former) client to get a copy
[23:37] <tolstoy> Are the loggerhead devs here?
[23:37] <tolstoy> Any reason loggerhead doesn't work using bzr 2.0?
[23:38] <tolstoy> AttributeError: 'module' object has no attribute 'ProgressBarStack'
[23:43] <igc> morning
[23:46] <tolstoy> Hm. Looks like something changed in bzrlib 2.0 that broke loggerhead.
[23:48] <lifeless> davidstrauss: no worries
[23:48] <lifeless> davidstrauss: I've closed it
[23:50] <zsquareplusc> tolstoy: i think launchpad uses bzr 2.0 and loggerhead. there should be a working version i'd guess
[23:51] <tolstoy> zsquareplusc: I was trying to pull down the latest, but I think I see where I messed that up.
[23:52] <lifeless> mwhudson: ^
[23:53] <mwhudson> tolstoy: what version of loggerhead are you using?
[23:53] <tolstoy> No idea.
[23:53] <mwhudson> tolstoy: i thought the latest release had the fix for that, certainly loggerhead trunk does
[23:53] <tolstoy> I think I have a "real" copy somewhere, and my running copy syncs with that, so I just need to figure out what directory I'm in. ;)
[23:53] <tolstoy> mwhudson: I'll see what I can pull.
[23:54] <tolstoy> Now on version 345, which is promising.
[23:55] <tolstoy> Oh, wait, that's not right. That's the one I already have.
[23:55] <tolstoy> Is this the right repo? http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/
[23:58] <tolstoy> mwhudson: The last revision I can see is May 13, 2009. That can't be right.
[23:58] <mwhudson> oh right
[23:58] <tolstoy> Did the repo change?
[23:58] <mwhudson> tolstoy: loggerhead trunk is now http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich
[23:58] <mwhudson> tolstoy: we upgraded to 2a