[07:02]  * spiv winds up for the day
[09:49] <poolie> hi there vila?
[09:49] <vila> poolie: Hey !
[09:50] <poolie> happy new year
[09:50] <vila> hehe
[09:51] <vila> Happy new year to all bzrastas (-ristas ?) :)
[10:02] <jelmer> hi vila, poolie
[10:02] <jelmer> happy new year :-)
[10:02] <poolie> hi jelmer, happy new yera
[10:02] <vila> heya jelmer !
[10:02] <vila> jelmer: happy new year ! And a bzr-ish one for that matter ;D
[10:10] <jelmer> thanks!
[10:35] <poolie> jelmer, oh, i guess you're now officially on the bzr team? or from monday?
[10:40] <jelmer> poolie: from Monday as far as I know
[10:40] <poolie> k
[10:40] <poolie> see you then
[10:41] <poolie> ok i should really go
[10:41] <poolie> good night
[10:42] <jelmer> poolie: yep, see you in Dallas :-)
[10:42] <jelmer> g'night
[13:36] <hsn> how many memory bzr needs? entire repo in memory?
[13:36] <hsn> i have 1G repo and bzr needs 1.3GB RAM
[13:36] <hsn> 70k revisions
[15:22] <voidspace> when will the RandomPool_DeprecationWarning be fixed in a released version of bzr?
[15:23] <voidspace> can't you do an emergency release that silences the warning?
[15:23] <voidspace> :-)
[15:26] <vila> voidspace: afaik, it's silenced in stable releases, what os/bzr versions are you using ?
[15:26] <voidspace> Mac OS X
[15:26] <voidspace> bzr 2.3b4 installed with pip
[15:27] <voidspace> Python 2.6
[15:27]  * maxb points to the beta nature of that release
[15:27] <vila> right, so neither a stable version nor an installer where we carry the relevant fix :)
[15:27] <voidspace> maxb: and beta means using deprecated pycrypto code is ok
[15:27] <voidspace> vila: what version is the fix in?
[15:27] <voidspace> I upgrade using "pip install -U bzr"
[15:27] <maxb> s/fix/suppression of warnings when running a production release/
[15:28] <vila> voidspace: so to answer your initial question: we do release installers for stable bzr without this warning
[15:28] <voidspace> vila: what version is the fix in?
[15:28] <maxb> There is no fix
[15:28] <voidspace> I will install that specific version with pip
[15:28] <maxb> There is a suppression of warnings when running a production release
[15:28] <vila> voidspace: the problem is not in bzr, it's in pycrypto iirc that is used by paramiko
[15:28] <voidspace> what version should I use to not get the deprecation warning
[15:28] <vila> none have been released
[15:28] <maxb> Any actual (non-beta) release
[15:29] <vila> hmm
[15:29] <voidspace> hah...
[15:29] <jelmer> voidspace: we submitted a fix for paramiko but it hasn't been merged yet
[15:29] <voidspace> you could silence the warning from within bzr in the meantime
[15:29] <voidspace> using the warnings module
[15:29] <vila> jelmer: I think we aren't talking about the same issue and maxb is right ;)
[15:29] <vila> voidspace: really ? care to submit a patch ?
[15:29] <maxb> voidspace: We could and do, in *released* versions of bzr. But not in development versions.
[15:30] <vila> voidspace: make sure we don't already do that for *released* versions though
[15:30] <jelmer> vila: https://github.com/robey/paramiko/pull/8
[15:30] <jelmer> is that a different one?
[15:32] <vila> jelmer: oh no, you're damn right, I was thinking about *another* one you proposed upstream
[15:32] <voidspace> ok, so I downgraded to 2.2.2 and don't see the warning - thanks very much
[15:32] <voidspace> you still interested in a patch to silence the warning for the development version, or not needed?
[15:33] <vila> voidspace: no, I was joking :) We want the warning while running dev and beta versions
[15:34] <vila> voidspace: but what is pip ?
[15:34] <voidspace> pip is pretty much the standard Python package installation tool within the Python community
[15:34] <maxb> Why did pip install 2.3b4 when our PyPI record says 2.2.2?
[15:34] <voidspace> it installs packages from PyPI
[15:34] <voidspace> and "pip install -U package" gets you the latest released version of any package
[15:35]  * vila bangs head
[15:35] <vila> why did it pick 2.3b4 dang it !
[15:35] <voidspace> I'm just checking what happens if I install bzr into a virtualenv with pip
[15:35] <voidspace> seeing what version it gets
[15:36] <voidspace> if I go to the PyPI page I see 2.2.2 as the latest version
[15:36] <vila> ha, we had ronny running into troubles with virtualenv last time,
[15:36] <voidspace> but you don't have a package for download on PyPI itself - so it maybe scraping download pages to find the latest version
[15:37] <vila> which prompted me to update the pypi page in a way that I thought address his problems
[15:37] <voidspace> right - so if I create a virtualenv and then just do a straight "pip install bzr" it gets 2.3b4
[15:37] <vila> bummer
[15:37] <voidspace> hosting python packages on pypi may be the best way to solve it
[15:37] <voidspace> python setup.py sdist upload
[15:37] <voidspace> maybe...
[15:38] <vila> I did try that iirc but there was some trouble with generated C files (we require pyrex but don't support all versions)
[15:38] <voidspace> ah, right
[15:38] <voidspace> ouch
[15:39] <voidspace> it maybe worth complaining to the pip guys
[15:39] <vila> if you know a way to fix that... then a patch will be welcome :)
[15:39] <voidspace> the pyrex issue? I've never worked with pyrex I'm afraid
[15:40] <voidspace> although using distribute / setuptools will allow you to optionally express build dependencies (including versions) in the setup.py
[15:40] <voidspace> I believe
[15:40] <voidspace> by optionally I mean you can make the use of distribute / setuptools optional within your setup.py
[15:40] <vila> yeah, it may well be a bug in our setup.py
[15:41] <vila> out of curiosity, why didn't you use the osx installers ? And do you get the extensions built correctly with pip ?
[15:53] <voidspace> vila: sorry - had issues with my irc client
[15:54] <voidspace> vila: I use pip to manage my Python packages on OS X
[15:54] <voidspace> vila: it seems to work fine, so it never occurred to me to *look* for OS X installers
[15:54] <vila> make sense
[15:54] <voidspace> easy_install *also* installs 2.3b4
[15:54] <vila> voidspace: no warnings about extensions then ?
[15:55] <voidspace> they scrape html to find the most recent release (if packages aren't available for download from pypi): http://paste.pocoo.org/show/314715/
[15:55] <vila> probably the same root cause
[15:55] <voidspace> vila: it seems to compile them, I can show you the output
[15:56] <voidspace> vila: full output of pip install bzr
[15:56] <voidspace> http://paste.pocoo.org/show/314716/
[15:56] <vila> voidspace: a better test would be to run 'bzr selftest', be aware it can take some time though (and may be start with 'bzr selftest --no-plugins', just in case)
[15:56] <jelmer> voidspace: btw, while you're here..
[15:56] <voidspace> ok, I'll need to install the test dependencies then
[15:56] <voidspace> jelmer: yes
[15:57] <jelmer> voidspace: I noticed "python2.7 -m unittest" works while "python2.6 -m unittest2" doesn't (it seems I need python2.6 -m unittest.__main__). Is that intentional?
[15:57] <jelmer> ehm, unittest2.__main__ that is
[15:57] <voidspace> jelmer: the ability to execute a *package* with "-m" is new in 2.7
[15:57] <voidspace> jelmer: so yes, you could say it is intentional
[15:57] <voidspace> jelmer: that is why there is a unit2 script
[15:58] <jelmer> voidspace: ah, previously it was only possible to execute modules ?
[15:58] <voidspace> jelmer: correct
[15:58] <jelmer> voidspace: ok, just checking. Thanks!
[15:58] <vila> voidspace: no pyrex trying cython... wow, this should work ok and dodge the pyrex compat issue
[15:58] <voidspace> vila: running selftest without plugins, 1 failure so far - I'll provide output on completion
[15:59] <vila> voidspace: thanks !
[15:59] <vila> voidspace: and what osx version ?
[16:00] <voidspace> vila: 10.6
[16:00] <vila> ok, cool
[16:00] <voidspace> Python 2.6
[16:00] <voidspace> I can try with alternative versions of Python too if it is useful
[16:00] <vila> yup, I saw 2.6 mentioned earlier
[16:01] <vila> voidspace: not yet, we're ironing out the last problems in 2.7 on natty for now
[16:01] <voidspace> ok
[16:02] <vila> so, apart from picking the "wrong" version pip output seems perfect to me
[16:02] <voidspace> right
[16:02] <vila> I had a patch for for the MIN/MAX warning but it get lost
[16:02] <voidspace> using 2.3b4 was working fine for me apart from the damn DeprecationWarning :-)
[16:03] <vila> now, for the "wrong" version, *our* intent (as in the bzr project) is to guide people to the stable releases first
[16:03] <voidspace> I do most of my work with bzr from inside Ubuntu though
[16:03] <voidspace> vila: yeah - understood
[16:03] <vila> but let them try the betas at will
[16:03] <voidspace> vila: it is because pip and easy_install scrape your download pages
[16:03] <vila> that's why the pypi page mention both links... errr wait
[16:04] <vila> they scrape which page exactly ?
[16:04] <voidspace> vila: yeah, I wonder if your release package is "badly" named
[16:04] <vila> on pypi ?
[16:04] <voidspace> vila: the url - yeah
[16:05] <voidspace> vila: you may be able to put a hint in the url (a # fragment) that informs pip / easy_install that is the version it should use
[16:05] <voidspace> vila: let me see if carljm in #pip has an idea about this
[16:05] <vila> voidspace: that would be awesome !
[16:10] <voidspace> vila: ok, so the following for easy_install and *may* work for pip too
[16:10] <voidspace> vila: from: http://peak.telecommunity.com/DevCenter/setuptools#making-your-package-available-for-easyinstall
[16:11] <voidspace> vila: in pypi add #egg=bzr to the download url
[16:12] <voidspace> vila: worth a try anyway :-)
[16:13] <vila> I've updated the pypi page with #egg=bzr, can you re-try ?
[16:13] <voidspace> yep
[16:13] <vila> voidspace: that is, I didn't upload a tarball, only modified the url
[16:13] <voidspace> vila: understood, that's what I was suggesting
[16:14] <vila> ok, no cache to care about for pip ?
[16:15] <vila> . o O (If it works *that* would be quite an easter egg...)
[16:16] <voidspace> vila: nah, looks like easy_install *still* scrapes the html in preference to using the download url
[16:16] <voidspace> vila: *sigh*
[16:17] <voidspace> vila: that # fragment trick is only for when your download urls don't point to a standard project-version.tgz format, which yours do already
[16:17] <voidspace> vila: so my mistake, sorry
[16:17] <vila> voidspace: no problem, was worth a try
[16:22] <voidspace> vila: just for your info, the page that pip & easy_install are scraping and looking for "the most recent version" on is: https://launchpad.net/bzr/+download
[16:22] <voidspace> vila: not sure there is anything you can do about that
[16:23] <voidspace> now we have pep 386 defining version schemes it should be possible for pip to switch to most recent *stable* version unless you explicitly tell it you want betas
[16:23] <voidspace> which would be nice
[16:23] <voidspace> but hasn't happened yet
[16:24] <vila> hmm, interesting
[16:24] <vila> but where did it get this page...
[16:24] <voidspace> 17000 / 24000 tests run...
[16:24] <voidspace> from this one: http://wiki.bazaar.canonical.com/SourceDownloads#Source%20Downloads
[16:25] <voidspace> which it got from this one: http://wiki.bazaar.canonical.com/Download/
[16:25] <vila> shudder
[16:25] <voidspace> and that one is the one you link to...
[16:25] <vila> yup
[16:25] <vila> but there is a download url right in the pypi page....
[16:26] <vila> probably they do that to catch up with people not updating the page ?
[16:30] <voidspace> not sure
[16:30] <voidspace> they don't pay any special attention to the download_url at all it seems
[16:32] <vila> bah, and all of that is from 'setup.py register' so even modifying the page will be good only for small tests like we did
[16:33] <vila> but good nough to understand, thanks for the hints voidspace
[16:33] <vila> enough, ha, first typo of the year :)
[16:33] <vila> 4 days !
[16:34] <voidspace> that's pretty good
[16:34] <voidspace> I usually make several a day
[16:34] <voidspace> heck, several an hour
[16:35] <vila> voidspace: if the download_url is a "primary url" then pip should give it some preference or ... nah, won't fly, may not be the most recent one
[16:35] <vila> voidspace: so, we're back to square one for your annoying warning :)
[16:36] <vila> voidspace: knowing that we won't change our policy for betas, what is acceptable as workarounds for you ?
[16:36] <voidspace> bzr selftest output ready
[16:36] <voidspace> from inside a Python 2.6 virtualenv
[16:36] <voidspace> http://paste.pocoo.org/show/314738/
[16:37] <vila> voidspace: the relevant code is in bzrlib/library_state.py line 73
[16:37] <voidspace> spoiler alert: FAILED (failures=10, known_failure_count=74)
[16:37] <voidspace> vila: well, I've solved my particular problem by switching back to stable
[16:38] <voidspace> vila: although given that you *intend* for betas to be *tried* by end users (is this the case?) I would expect them to be free of DeprecationWarnings
[16:38] <voidspace> vila: but solving the general case, so that "ordinary users" get the latest stable from pip / easy_install rather than the beta seems to be harder
[16:38] <voidspace> vila: but I'm sure not insolvable
[16:39] <voidspace> vila: I will ruminate 'pon the topic
[16:39] <vila> voidspace: well, we expect them to understand they can encounter rough edges while running betas, yes
[16:40] <voidspace> vila: hmm... according to carljm pip *is* trying the download_url first but gets a 404 and then resorts to scraping
[16:40] <voidspace> vila: see http://paste.pocoo.org/show/314737/
[16:40] <vila> voidspace: for the selftest result, only 10 failures is pretty good, knowing that I never heard about running the tests under virtualenv
[16:40] <voidspace> vila: but obviously the download url *isn't* a 404
[16:40] <voidspace> vila: hah, cool
[16:40] <voidspace> vila: so something weird is going on
[16:40] <vila> voidspace: a 404 or a 30x (redirect) ?
[16:41] <voidspace> vila: pip seems convinced it is getting a 404
[16:41] <voidspace> it's possible it "casts" all non-200 codes to 404, but most python web client libraries follow redirects transparently, so it shouldn't even see the redirect
[16:41] <vila> not from here, but it's a redirect
[16:42] <vila> hmm
[16:42] <vila> could be a launchpad bug
[16:42] <voidspace> well - I can fetch that url from urllib2 or wget fine
[16:42] <voidspace> so I don't think so
[16:42] <vila> that's worth investigating, but try for yourself with a browser
[16:43] <voidspace> I have :-)
[16:43] <vila> sorry, msgs cross on the wire :)
[16:43] <voidspace> haha
[16:43] <voidspace> brb
[16:43] <vila> voidspace: well, if you can with urllib2 and pip can't...
[16:44] <vila> voidspace: ok, you're smarter than pip, but still :)
[16:44] <voidspace> yeah, it may just be reporting the redirect as a 404 rather than following the damn redirect
[16:44] <voidspace> which would be unreasonably dumb
[16:46] <vila> but now that you mentioned it, I think ronny was having the same problem... pip not following the redirects
[16:46] <vila> or was it easy_install, or a shared "feature" ;)
[16:50] <voidspace> vila: do you want me to run `bzr selftest` outside of a virtualenv by the way?
[16:51] <voidspace> vila: to see if any of the failures are caused by the virtualenv or are general to Mac OS X
[16:53] <vila> voidspace: there is http://babune.ladeuil.net:24842/, so I know the status on osx for 10.5 and 10.6 so far
[16:53] <voidspace> ok
[16:54] <voidspace> I could try it under virtualenv on ubuntu
[16:54] <voidspace> that may just be creating work for you though... :-)
[16:56] <vila> hehe, fixing failing tests is the true path to avoid bugs :)
[17:04] <vila> voidspace: re-reading the test failures, I'd say, some of them I've already seen, so probably fixed in 2.3b*5*, some others are weird (no nodename, blah blah) and may be due to virtualenv doing strange things with the network stack ?
[17:05] <voidspace> virtualenv shouldn't affect the network stack in any way
[17:05] <voidspace> trying on ubuntu
[17:05] <vila> voidspace: in any case, you've already been very helpful, but if you can reproduce the same failures on Ubuntu and virtualenv, filing a bug may help us track the issue
[17:06] <voidspace> ok - selftest is now running on Ubuntu under virtualenv
[17:06] <vila> voidspace: I haven't used virtualenv myself and won't be able to try in the coming weeks but I'll subscribe to such a bug
[17:06] <voidspace> ok
[17:06] <voidspace> for python development virtualenv is awesome :-)
[17:09] <vila> voidspace: python itself you mean ?
[17:09]  * mgedmin grumbles about '/tmp/sandbox/bin/pip install bzr' finding a ./bzr directory -- where I keep my repos -- and deciding it should use that instead of looking up a 'bzr' package on pypi
[17:10] <voidspace> vila: no, I mean for developing *with* python
[17:11] <voidspace> vila: buildout is good too, but more work to use
[17:11] <voidspace> vila: but buildout recipes are more powerful
[17:11] <voidspace> vila: virtualenv allows you to create isolated (repeatable) sandboxed installs of Python and sets of dependencies
[17:11] <voidspace> vila: which you can blow away by just deleting
[17:12] <voidspace> vila: so you can work on stuff without installing system wide - and can easily install different (incompatible) sets of dependencies into different virtualenvs
[17:12] <vila> oh right, well, I use virtual machines for that :) But I also need to test verious OSes so, different problem ;) But yeah, even if I don't have such need today, I see the point
[17:16] <voidspace> right
[17:35] <voidspace> vila: many less failures on ubuntu under virtualenv, so it looks like the other failures are OS X related
[17:36] <voidspace> vila: or specific to my system...
[17:36] <voidspace> vila: http://paste.pocoo.org/show/314762/
[17:36] <voidspace> vila: do you want me to report a bug here?
[17:37] <vila> hmm, these are totally different failures, and probably fixed too
[17:37] <vila> if you want to report a bug, do it for the osx failures instead
[17:37] <voidspace> ok
[17:37] <voidspace> I'll do that  - at least they are on launchpad then
[17:38] <vila> yup, we could de-dupe them if needed
[17:38] <vila> voidspace: if there is a simple recipe to use virtualenv and reproduce the problem, you'll get bonus points ;D
[17:38] <voidspace> haha
[17:39] <voidspace> they'll have to be OS X instructions - running under Ubuntu doesn't reproduce the bugs
[17:39] <voidspace> so not sure how useful they would be to you anyway...
[17:52] <Buttons840> i would like to see only what files have changed instead of a full diff?
[17:52] <voidspace> bzr st
[17:55] <Buttons840> sorry, i wasn't clear; i want to see all the files that have changed since revision 1 and i'm on revision 22
[17:55] <Buttons840> perhaps status can still be used?  i'm looking at the breif option of diff right now though
[18:04] <Buttons840> status -r1    no so difficult i guess; thanks
[21:47] <mathrick> hey, bzr-svn doesn't build in daily ppa, fails some tests
[21:48] <mathrick> that does bad things to the deps, since stable bzr-svn hates the idea of having bzr >2.2
[21:59] <maxb> Interesting. And weird.
[22:01] <maxb> Might be something as simple as the tests never having been run in a non-UTF8 locale :-/
[22:05] <mathrick> quite possible
[22:05] <mathrick> non-UTF-8 locales are an abomination unto Lord and man alike
[23:15] <abadger1999> No jam :-(
[23:15]  * abadger1999 replies via email even though it's just for clarification now.
[23:34] <poolie> hi abadger1999
[23:34] <abadger1999> poolie: Hi
[23:36] <poolie> this is about using 2.5 or 2.6?
[23:37] <abadger1999> poolie: 2.4 actually -- I care about 2.4, 2.6, and 2.7 atm.
[23:38] <abadger1999> (RHEL5, RHEL6, and Fedora)
[23:38] <poolie> rhel5 is python2.4
[23:38] <poolie> ?
[23:38] <abadger1999> Correct
[23:39] <poolie> for how long do you think that will remain relevant?
[23:39] <poolie> years more?
[23:40] <abadger1999> 3 years, 3 months to go until EOL :-(
[23:40] <abadger1999> relevancy is hard to guage -- RHEL6 only just came out.
[23:41] <abadger1999> It usually takes several years before a new release makes it so that we can tell people "Can't you just upgrade that server/computer lab/etc to a newer version"
[23:42] <abadger1999> and have them sheepsihly say, yeah, I need to do that.
[23:42] <poolie> right
[23:47] <abadger1999> Note: I'm not the maintainer of bzr in RHEL6 (bzr made it into RHEL6 itself!  Yay!) , I'm just maintaining it in EPEL for RHEL5  and comaintaining it in EPEL.
[23:47] <abadger1999> Err Fedora
[23:53] <poolie> great