| === glyph_ is now known as glyph | ||
| * spiv winds up for the day | 07:02 | |
| poolie | hi there vila? | 09:49 |
|---|---|---|
| vila | poolie: Hey ! | 09:49 |
| poolie | happy new year | 09:50 |
| vila | hehe | 09:50 |
| vila | Happy new year to all bzrastas (-ristas ?) :) | 09:51 |
| 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:02 |
| jelmer | thanks! | 10:10 |
| poolie | jelmer, oh, i guess you're now officially on the bzr team? or from monday? | 10:35 |
| jelmer | poolie: from Monday as far as I know | 10:40 |
| poolie | k | 10:40 |
| poolie | see you then | 10:40 |
| poolie | ok i should really go | 10:41 |
| poolie | good night | 10:41 |
| jelmer | poolie: yep, see you in Dallas :-) | 10:42 |
| jelmer | g'night | 10:42 |
| === frakturfreak_ is now known as frakturfreak | ||
| === oubiwann is now known as oubiwann_ | ||
| === oubiwann_ is now known as oubiwann | ||
| 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 | 13:36 |
| === smoser` is now known as smoser | ||
| voidspace | when will the RandomPool_DeprecationWarning be fixed in a released version of bzr? | 15:22 |
| voidspace | can't you do an emergency release that silences the warning? | 15:23 |
| voidspace | :-) | 15:23 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:32 |
| vila | voidspace: no, I was joking :) We want the warning while running dev and beta versions | 15:33 |
| 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:34 |
| * 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| vila | out of curiosity, why didn't you use the osx installers ? And do you get the extensions built correctly with pip ? | 15:41 |
| === deryck is now known as deryck[lunch] | ||
| === Ursinha is now known as Ursinha-afk | ||
| voidspace | vila: sorry - had issues with my irc client | 15:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| vila | voidspace: thanks ! | 15:59 |
| vila | voidspace: and what osx version ? | 15:59 |
| 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:00 |
| vila | voidspace: not yet, we're ironing out the last problems in 2.7 on natty for now | 16:01 |
| voidspace | ok | 16:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:10 |
| voidspace | vila: in pypi add #egg=bzr to the download url | 16:11 |
| voidspace | vila: worth a try anyway :-) | 16:12 |
| 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:13 |
| vila | ok, no cache to care about for pip ? | 16:14 |
| vila | . o O (If it works *that* would be quite an easter egg...) | 16:15 |
| voidspace | vila: nah, looks like easy_install *still* scrapes the html in preference to using the download url | 16:16 |
| voidspace | vila: *sigh* | 16:16 |
| 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:17 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| vila | probably they do that to catch up with people not updating the page ? | 16:26 |
| voidspace | not sure | 16:30 |
| voidspace | they don't pay any special attention to the download_url at all it seems | 16:30 |
| 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:32 |
| vila | but good nough to understand, thanks for the hints voidspace | 16:33 |
| === beuno is now known as beuno-lunch | ||
| vila | enough, ha, first typo of the year :) | 16:33 |
| vila | 4 days ! | 16:33 |
| voidspace | that's pretty good | 16:34 |
| voidspace | I usually make several a day | 16:34 |
| voidspace | heck, several an hour | 16:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| voidspace | vila: do you want me to run `bzr selftest` outside of a virtualenv by the way? | 16:50 |
| voidspace | vila: to see if any of the failures are caused by the virtualenv or are general to Mac OS X | 16:51 |
| 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:53 |
| voidspace | I could try it under virtualenv on ubuntu | 16:54 |
| voidspace | that may just be creating work for you though... :-) | 16:54 |
| vila | hehe, fixing failing tests is the true path to avoid bugs :) | 16:56 |
| === deryck[lunch] is now known as deryck | ||
| 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:04 |
| 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:05 |
| 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:06 |
| 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:09 | |
| === Ursinha-afk is now known as Ursinha | ||
| voidspace | vila: no, I mean for developing *with* python | 17:10 |
| 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:11 |
| === Ursinha is now known as Ursinha-afk | ||
| 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 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| 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:12 |
| voidspace | right | 17:16 |
| === beuno-lunch is now known as beuno | ||
| voidspace | vila: many less failures on ubuntu under virtualenv, so it looks like the other failures are OS X related | 17:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| Buttons840 | i would like to see only what files have changed instead of a full diff? | 17:52 |
| voidspace | bzr st | 17:52 |
| 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 | 17:55 |
| Buttons840 | status -r1 no so difficult i guess; thanks | 18:04 |
| === Ursinha is now known as Ursinha-afk | ||
| === daveb_ is now known as Croepha | ||
| mathrick | hey, bzr-svn doesn't build in daily ppa, fails some tests | 21:47 |
| mathrick | that does bad things to the deps, since stable bzr-svn hates the idea of having bzr >2.2 | 21:48 |
| maxb | Interesting. And weird. | 21:59 |
| maxb | Might be something as simple as the tests never having been run in a non-UTF8 locale :-/ | 22:01 |
| mathrick | quite possible | 22:05 |
| mathrick | non-UTF-8 locales are an abomination unto Lord and man alike | 22:05 |
| abadger1999 | No jam :-( | 23:15 |
| * abadger1999 replies via email even though it's just for clarification now. | 23:15 | |
| poolie | hi abadger1999 | 23:34 |
| abadger1999 | poolie: Hi | 23:34 |
| poolie | this is about using 2.5 or 2.6? | 23:36 |
| abadger1999 | poolie: 2.4 actually -- I care about 2.4, 2.6, and 2.7 atm. | 23:37 |
| abadger1999 | (RHEL5, RHEL6, and Fedora) | 23:38 |
| poolie | rhel5 is python2.4 | 23:38 |
| poolie | ? | 23:38 |
| abadger1999 | Correct | 23:38 |
| poolie | for how long do you think that will remain relevant? | 23:39 |
| poolie | years more? | 23:39 |
| abadger1999 | 3 years, 3 months to go until EOL :-( | 23:40 |
| abadger1999 | relevancy is hard to guage -- RHEL6 only just came out. | 23:40 |
| 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:41 |
| abadger1999 | and have them sheepsihly say, yeah, I need to do that. | 23:42 |
| poolie | right | 23:42 |
| 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:47 |
| poolie | great | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!