pmxbot IRC Log Viewer

[12:25:58] <ionelmc> wooot

[12:25:59] <ionelmc> CertificateError: hostname u'pypi.python.org' doesn't match either of '*.c.ssl.fastly.net', 'c.ssl.fastly.net', '*.target.com'

[12:26:13] <ionelmc> that's with pip 1.4.1

[12:28:19] <jaraco> ionelmc: I believe that issue stems from an older SSL implementation that doesn't support a certain SSL feature.

[12:28:30] <jaraco> SNI

[12:28:47] <jaraco> dstufft would know better how to work around the issue

[12:29:01] <dstufft> SAN

[12:29:02] <dstufft> not SNI

[12:29:09] <dstufft> yay for TLA

[12:29:21] <ionelmc> well this was on drone.io ci server

[12:29:32] <ionelmc> i've ran the build again, and it works

[12:29:39] <dstufft> actually wait what

[12:29:42] <Ivo> what doesn't support SAN? an old OpenSSL?

[12:29:45] <ionelmc> seems that they have some broken server in the pool

[12:29:45] <dstufft> it said *.target.com?

[12:29:55] <ionelmc> that's what she said

[12:30:14] <Ivo> Maybe target decided to start taking security seriously!

[12:30:42] <ionelmc> does pypi use fastly's cdn?

[12:30:44] <dstufft> yea

[12:30:56] <dstufft> we switched over to a new certificate last night, a wildcard

[12:30:58] <dstufft> *.python.org

[12:31:05] <dstufft> looks like you're using the new certificate

[12:31:16] <ionelmc> could be some temp issue on fastly's side

[12:31:21] <dstufft> (that's the one on Fastl'y C0

[12:31:43] <dstufft> I'm wondering if maybe one of Fastly's nodes didn't get the new certificate with the star cert added to the SAN

[12:31:45] <Ivo> Doesn't Fastly's cert have like 50 DNs on it

[12:33:00] <dstufft> fastly has 3 different certs

[12:33:14] <dstufft> with a bunch of names in SANs yes

[12:34:19] <dstufft> ionelmc: was there any other names mentioned in the error?

[12:34:43] <ionelmc> dstufft: this is all i got https://drone.io/github.com/ionelmc/python-aspectlib/4

[12:34:53] <ionelmc> it doesn't happen anymore

[12:35:12] <Ivo> ephemerael bug?

[12:36:00] <ionelmc> ah yes, the mythical ephemeral bug

[12:36:02] <ionelmc> :)

[12:36:30] <dstufft> well you'll probably connect to different fastly nodes each time you run

[12:36:45] <dstufft> if one of the Fastly nodes is using an old copy of their C cert, you'll get sporadic failures

[12:36:49] <ionelmc> well anyway, it's not an issue for me

[12:36:58] <dstufft> yea, I'm gonna ping them just to make sure

[12:37:02] <dstufft> thanks!

[12:37:07] <ionelmc> i'm just telling you in case you're looking for reasons to use different cdn =)

[12:38:54] <dstufft> :) We've been super happy with Fastly actually, they donate the service to the PSF too (A signifcant amount of it tbh, we've pushed ~71TB so far in March to the tune of just under 8k USD worth of service)

[12:46:16] <jaraco> !m Fastly

[12:46:16] <pmxbot> you're doing good work, Fastly!

[12:49:53] <dstufft> http://d.stufft.io/image/3N293j3i0S2w

[12:50:02] <dstufft> I don't think we're going to hit a billion requests this month :(

[12:50:07] <dstufft> maybe next month

[12:52:31] <ionelmc> 1B ?

[12:52:40] <ionelmc> "drive it like it's stolen" :-)

[12:59:00] <jezdez> dstufft: :D

[14:01:41] <Ivoz__> pfmoore: do you know of an issue for virtualenv where installing it creates a virtualenv2.7 script even though I installed it with python 3.3

[14:05:28] <Ivoz__> It's like somehow setup.py is being run with my python 2.7...

[14:05:57] <Ivoz__> Because I have a C:\Python33\Scripts\virtualenv-2.7.exe

[14:06:06] <Ivoz__> which just makes no sense =_=

[14:07:29] <pfmoore> Ivoz__: Nope, never seen that

[14:07:52] <pfmoore> Wait, did you install virtualenv from a wheel built with Python 2.7?

[14:07:56] <Ivoz__> well I'm literally getting that installed

[14:08:32] <pfmoore> If you didn't do --skip-scripts there's be a 2.7 exe in there from the wheel build

[14:08:34] <Ivoz__> pfmoore: pip is getting it from the pypi wheel which may well have been created by 2.7

[14:08:47] <pfmoore> Yeah, that could well be it.

[14:08:57] <Ivoz__> but why is the wheel have scripts already

[14:09:02] <pfmoore> Must get on with the PR to make --skip-scripts the default...

[14:09:26] <Ivoz__> oh because the name is getting specified at build time...

[14:09:41] <dstufft> hm

[14:09:51] <pfmoore> Yep, build the wheel on 2.7 and don't specify --skip-scripts and you get 2.7 scripts.

[14:09:59] <dstufft> I thought I had used --skip-scripts for all of those

[14:10:00] <pfmoore> I thought pip ignored them though.

[14:11:08] <pfmoore> I'm gonna do a PR for wheel to skip scripts always. It'd be nice to get a new release out with that plus the --universal/--python-tag stuff in.

[14:11:54] <pfmoore> BTW, do wheel releases still need @dholth to do them, or can anyone in pypa do them now? (Not that I want to bypass Daniel, just curious)

[14:13:55] <pfmoore> Just checked, virtualenv 1.11.4 wheel (got via pip wheel virtualenv) doesn't include a virtualenv-2.7.exe script.

[14:14:23] <Ivoz__> https://github.com/pypa/virtualenv/issues/586

[14:14:43] <pfmoore> Ivoz__: Could you have picked up a wheel you built yourself at some point? local files specified via -f in pip.ini somewhere?

[14:15:05] <Ivoz__> pfmoore: no, its pypi wheel.

[14:15:54] <Ivoz__> pfmoore: https://github.com/pypa/virtualenv/blob/develop/setup.py#L12 gets interpolated at build time, when the wheel is built, and so that is the script name that gets installed eventually

[14:16:39] <Ivoz__> no matter the python version

[14:16:58] <pfmoore> Yeah, just reproduced it.

[14:18:39] <pfmoore> That entry point can probably just be omitted. There's no way atm to specify target-version-specific entry points

[14:19:31] <pfmoore> See https://github.com/pypa/pip/blob/develop/pip/wheel.py#L237

[14:21:00] <pfmoore> Needs a metadata change to allow some sort of "append Python version to entry point" flag on an entry point.

[14:21:16] <Ivoz__> pfmoore: wheel on pypi is controlled by 'joeforker'

[14:21:29] <pfmoore> hmm....

[14:21:47] <Ivoz__> which I assume is dholth's username

[14:22:00] <Ivoz__> unless he's getting someone else to release it for him

[14:23:44] <Ivoz__> you can see the owner at the bottom of the page https://pypi.python.org/pypi/wheel/

[14:24:33] <pfmoore> Ta. As I said, just curious, cos I didn't know how this works (I don't even know how we release pip etc...)

[14:27:43] <Ivoz__> pfmoore: have you tried uploading a package to pypi before?

[14:28:53] <pfmoore> Only test, and only once I think.

[14:29:34] <pfmoore> I'm a bad case of "those that can, so, those that can't, develop packaging systems" :-)

[14:29:51] <Ivoz__> simplistically its just python setup.py register && python setup.py sdist bdist_wheel upload

[14:30:18] <dstufft> *cough* use twine

[14:30:56] <Ivoz__> *simplistically*

[14:33:04] <Ivoz__> dstufft: I almost want to poll reddit and HN python mac users about whether we should put in the hack for os x system python or not

[14:34:16] <Ivoz__> My opinion isn't much good atm, I'm too blinded by hatred for apple

[14:34:57] <Alex_Gaynor> dstufft: any idea what might cause https://travis-ci.org/pyca/cryptography/jobs/21759424#L783 -- it installs fine locally with defaults and --no-use-wheel

[14:35:27] <dstufft> dunno offhand

[14:35:31] <dstufft> can look later

[14:35:36] <dstufft> debugging SSL issues on pypi atm

[14:36:16] <Alex_Gaynor> Bad cert on one of the PoPs?

[14:39:05] <Alex_Gaynor> dstufft: it's a tox bug, sorry for the noise.

[14:42:33] <Ivoz__> Alex_Gaynor: you have any opinion on if pip should try to fix the build bug for apple python?

[14:42:51] <Alex_Gaynor> I'm not sure :/

[14:43:40] <Ivoz__> I don't know whether to be worried that apple will see us 'fix' it and then think everything is fine

[14:46:24] <Ivoz__> dstufft: > claiming that the host name doesn't patch ^_^

[14:46:47] <Ivoz__> noight

[16:28:00] <wsanchez> Alex_Gaynor: That bug will be fixed.

[16:28:14] <Alex_Gaynor> wsanchez: I'm sure the answer is "no comment", but soon?

[16:29:26] <wsanchez> :-)

[16:34:00] <wsanchez> I worked around it in CalendarServer is a way that's not likely to be damaging to anything, FWIW. And I wouldn't worry about the "well now they don't have to fix it" thing, though I totally get that.

[16:34:57] <wsanchez> (sh, sorry):

[16:34:57] <wsanchez> if [ "$(uname -s)" == "Darwin" ]; then

[16:34:57] <wsanchez> if "${python}" -c 'import distutils.sysconfig; print distutils.sysconfig.get_config_var("CFLAGS")' \

[16:34:59] <wsanchez> | grep -e -mno-fused-madd > /dev/null; then

[16:35:01] <wsanchez> export ARCHFLAGS="-Wno-error=unused-command-line-argument-hard-error-in-future";

[16:35:03] <wsanchez> fi;

[16:35:05] <wsanchez> fi;

[16:35:36] <wsanchez> That is, if Darwin and -mno-fused-madd, set os.environ["ARCHFLAGS"].

[16:42:15] <dstufft> wsanchez: do you think pip should fix it?

[16:42:23] <dstufft> in the interim

[16:50:51] <wsanchez> I would if it's easy. I don't suspect it'll be needed for long, but it's not gonna be fixed in a week.

[16:51:47] <Alex_Gaynor> dstufft: you should fix the __pycache__ for pypy n debian first :-(

[16:52:28] <dstufft> Alex_Gaynor: if I'm going to make a release for __pycache__ I want to get any other common issues like that into it that we're going to fix

[16:52:37] <Alex_Gaynor> dstufft: coolio

[16:52:47] <dstufft> gonna make a milesetone for 1.5.5 I guess

[19:04:16] <tomprince> dstufft: Installing msi is easier to automate than installing exe.

[19:04:40] <dstufft> tomprince: yea, #twisted-dev talked me down from proposing to rm -rf msi :]

[19:22:03] <dstufft> glyph: so yea, I'm looking into the feasability of making the PyPI upload API be simply "post your file to this url and we'll inspect it and figure things out from there"

[19:22:31] <dstufft> which requires Warehouse/PyPI to be able to reach inside the files and pull files out of it

[21:18:47] <glyph> dstufft: Sorry, I sort of drifted off into work stuff

[21:19:28] <dstufft> glyph: np!

[21:20:43] <glyph> dstufft: so, MSIs are not the best. They're hella better than EXEs (which I guess you accept now) but if wheels just worked perfectly we wouldn't need either.

[21:20:52] <glyph> dstufft: It needs to be easier to set up pip though. :-\

[21:21:08] <glyph> dstufft: maybe a new release of python2.7 that includes it? :-)

[21:21:17] <dstufft> glyph: I doubt i'll convince them of that :(

[21:21:24] <dstufft> maybe I can convince them to make an installer

[21:21:28] <dstufft> that includes it

[21:21:53] <glyph> dstufft: you're not going to be at the language summit, are you?

[21:21:58] <glyph> dstufft: I will make the installer

[21:22:02] <glyph> dstufft: I just want them to put a link to it

[21:23:24] <dstufft> glyph: no I won't be at pycon at all

[21:23:46] <dstufft> glyph: I can go bother python-dev about putting a link to a 2.7 + pip installer

[21:25:14] <glyph> dstufft: If you could do that that would be _amazing_.

[21:25:22] <glyph> If you have any success I'd like to hear about it before pycon, I'm giving a talk that will mention this :)

[22:26:09] <unstable> In my requirements.txt .. there is some package djangosaml2 that is broken on django 1.6. It is missing one small patch, that I can see is added to the project on bitbucket.

[22:26:23] <unstable> I don't know how pypi works exact, though I"m guessing they have to update their pypi somehow.

[22:26:43] <unstable> In the mean time, can I just link to their bitbucket git link directly in the requirements.txt?

[22:30:24] <unstable> To top it off, they're using mercurial

[22:33:07] <Ivoz__> unstable: yes, you should be able to do an editable install

[22:33:20] <Ivoz__> unstable: -e hg:https://bitbucket...

[22:33:42] <tomprince> Do you even need it to be an editable install?

[22:36:48] <unstable> -e hg+ssh://bitbucket.org/lgs/djangosaml2#egg=djangosaml2

[22:37:06] <unstable> Cannot find command 'hg'

[22:37:10] <unstable> Is there some pip plugin I need?

[22:37:57] <unstable> o, I guess I need hg on my local system

[22:38:01] <Ivo> unstable: hg is the name of the mercurial client, you'll need to install it to checkout a mercurial repositroy using pip or otherwise

[22:39:25] <unstable> ok, everything seems to be working now.

[22:39:30] <unstable> Thanks for the help, I appreciate it.

Log file Viewer

Help | Karma | Search:

#pypa logs for Friday the 28th of March, 2014