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