Log file Viewer

[05:35:39] <agronholm> eh? why the hell is it using ASCII to decode the setup.cfg?

[05:37:43] <mgedmin> misconfigured locale for the user installing it?

[05:38:04] <agronholm> nobody else has ever complained about a problem like this

[05:38:32] <mgedmin> that's a strong statement

[05:38:50] <agronholm> at least I haven't seen anyone do so

[05:39:18] <mgedmin> I had to add a LC_ALL=C build into my tox.ini for one of the packages because people try to install it on servers before actually setting up the locales correctly

[05:39:28] <mgedmin> (and some people don't care about setting up their locale correctly)

[05:40:14] <mgedmin> otoh, guessing from the /Users path, this is a mac, and I'm surprised it doesn't come with a UTF-8 locale out of the box

[05:40:28] <agronholm> I thought mac defaulted to UTF-8

[05:41:54] <mgedmin> if f209 were still here we could ask for more details

[05:42:21] <agronholm> opts.read([filename])

[05:42:31] <agronholm> lacking the "encoding" parameter

[05:42:37] <agronholm> so it defaults to ascii

[05:42:43] <mgedmin> really?

[05:42:50] <agronholm> the question is -- why have I never encountered this before?

[05:43:10] <mgedmin> ascii, not locale.getpreferredencoding() (or however you spell it)?

[05:43:57] <agronholm> let me try it here

[05:44:15] <mgedmin> I just did: configparser uses the locale encoding

[05:44:59] <agronholm> also -- this uses the old version of APScheduler -- 3.x no longer has non-ascii characters in setup.cfg

[05:45:23] <agronholm> quite a corner case we have here

[05:51:35] <mgedmin> from long.tail import problems

[05:52:12] <agronholm> mgedmin: actually...I looked at apscheduler 2's setup.cfg -- no non-ascii characters there either

[05:52:18] <agronholm> so I'm mystified

[05:52:20] <mgedmin> huh

[05:52:32] <agronholm> ditto with setup.py

[05:52:48] <mgedmin> could be a ~/.pydistutils.cfg?

[05:53:07] <agronholm> none is provided in the distro at least

[05:53:34] <mgedmin> also none of the earlier packages were affected

[05:54:19] <mgedmin> "author = Alex Grönholm" in setup.cfg in APScheduler-2.1.1.tar.gz

[05:54:25] <mgedmin> there's your non-ascii char

[05:57:26] <agronholm> hm, I suppose I was looking at 2.1.2

[05:57:37] <agronholm> though I have no recollection of putting something like that there

[05:57:49] <agronholm> maybe I did

[05:57:54] <mgedmin> oh, it's your package!

[05:57:58] <mgedmin> I didn't realize :)

[05:58:01] <agronholm> NOW you figured it out? :)

[06:00:20] <agronholm> ok, mystery solved -- there was a bunch of metadata there, originally meant for distutils2

[06:00:35] <agronholm> and I threw it out before releasing 2.1.2

[10:16:21] <mgedmin> Error: https://pypi.python.org/packages/source/i/ipaddr/ipaddr-2.1.11.tar.gz#md5=f2c7852f95862715f92e7d089dc3f2cf returned a bad status line. The server might be down, ''

[10:16:24] <mgedmin> says my buildout

[16:47:24] <consfearacy> pip keeps giving me a 'ssl' error at first line, how to get rid of it?

[18:07:12] <natefoo> so just in case i'm missing something, there has not been any recent progress on the lack of distinction between UCS2/UCS4 in the platform string and allowing distribution of binary wheels for linux, has there?

[18:08:42] <dstufft> natefoo: not yet, it needs someone to put in the effort to make it happen

[18:09:15] <natefoo> i'm willing to put in the effort, i've been barking up this tree for 5+ years... https://mail.python.org/pipermail/distutils-sig/2010-January/015345.html

[18:11:32] <DanielHolth> natefoo it should be easy

[18:11:36] <dstufft> natefoo: https://bitbucket.org/pypa/pypi-metadata-formats/issue/15/enhance-the-platform-tag-definition-for https://bitbucket.org/pypa/pypi-metadata-formats/issue/25/handle-abi-compatibility-on-windows-python are the important issues I think

[18:13:27] <natefoo> would this also be necessary? https://bitbucket.org/pypa/wheel/issue/63/backport-soabi-to-python-2

[18:13:48] <DanielHolth> Yes, that's the easy one.

[18:14:05] <DanielHolth> The slightly trickier one will be figuring out whether you want to truncate a hash of /etc/os-release or what for the platform tag.

[18:14:47] <DanielHolth> If you write the detection code for wheel issue #63 I will be happy to help you to insert the tag into the list.

[18:15:27] <natefoo> okay, i can do that.

[18:16:16] <natefoo> how import is distro detection? i build all our eggs on an old etch install and they work with every distro that's been released since.

[18:16:27] <natefoo> (including rhel derivatives)

[18:18:43] <DanielHolth> That's a pretty good strategy if your eggs don't dynamically link with the system.

[18:18:54] <DanielHolth> Or perhaps if they only use certain stable libraries.

[18:19:03] <DanielHolth> That are also common.

[18:20:11] <DanielHolth> Unfortunately AFAIK the answer to your question is "it depends" which is why wheel does not solve that problem currently.

[18:20:36] <natefoo> true, i build and statically link things like libpq for psycgop2.

[18:21:30] <DanielHolth> If you can improve the situation that would be great.

[18:23:21] <natefoo> ok. so are the guidelines posted by Nick Coghlan on #63 the correct way forward?

[18:24:35] <DanielHolth> Looks good. Today pip has its own copy of pep425tags that has diverged from the wheel implementation in order to support OSX better.

[18:24:39] <DanielHolth> You would edit that too.

[18:25:22] <DanielHolth> bdist_wheel would probably need to have a new flag that caused it to generate wheels with the more accurate tagging.

[18:25:50] <DanielHolth> (otherwise it would generate wheels with tags that would not be recognized by current versions of pip)

[18:29:28] <natefoo> alright, i'll see what i can do. thanks for the guidance.

[19:31:28] <hannes3> so i installed some tool with "pip install --user". it wrote to ~/.local/lib/python3.4/ ... . how can i use it now? do i have to update some path variable?

[19:42:35] <natefoo> DanielHolth: should i avoid platform.linux_distribution()?

[19:45:52] <natefoo> hannes3: either PYTHONPATH=..., or use a virtualenv.

[19:46:32] <tdsmith> python should know about the --user path already, shouldn't it?

[19:47:20] <natefoo> dunno, i've never used it.

[19:48:49] <hannes3> oh argh, actually it gave it an executable in ~/.local/bin(

[19:49:00] <hannes3> i can use that before i get confused with all this =)

[19:49:01] <hannes3> thanks

[20:06:49] <DanielHolth> natefoo that looks useful

[20:11:31] <natefoo> ok

[20:13:00] <natefoo> should it be left up to the person building the distribution as to how specific the tags should be for that build?

[20:15:04] <natefoo> and, well, having the distribution as part of the platform tag does make it fairly hard to do binary compatibility even across distro versions, if i understand pep 425.

[20:17:02] <DanielHolth> A third idea would be to allow users to place an arbitrary tag in that slot with an environment or configuration variable

[20:17:58] <natefoo> i see there's an astersk in the pep, so i suppose that would take care of it if the linux distro is appended to the standard distutils platform string.

[20:18:44] <natefoo> arbitrary is good as long as they match the format pip will be looking for exactly. =)

[20:25:32] <DanielHolth> It would be good for an organization who had "compatible os #1" in the platform tag slot, they could upload wheels to a company index and ensure that only certain machines would download that wheel

[20:26:39] <natefoo> ok, understood.

[20:27:17] <DanielHolth> Compared to the current advice of having separate indexes for each OS

[20:27:27] <DanielHolth> (each linux variant)

[20:28:08] <natefoo> yuck

[20:28:57] <DanielHolth> or just building more things locall

[22:14:38] <hwgasdfasdf> _habnabit: hi

[22:15:14] <_habnabit> dstufft, did the cert on https://pypi.python.org change recently? it looks like the CN is www.python.org and pypi.python.org is in a SAN now, and i don't remember what it was like before, so i don't know if this is new or not. hwgasdfasdf is getting an error validating the cert, and i don't know if it's because of SANs or something else: http://paste.pound-python.org/show/PIrkpdQKLSeihwTOOp4N/

[22:16:11] <_habnabit> hwgasdfasdf, can you pastebin the output of `host pypi.python.org` and `dig +trace pypi.python.org` from that box?

[22:16:20] <dstufft> It's been a SAN since 2013 or so

[22:16:32] <dstufft> MAy 2013? something like that

[22:16:37] <dstufft> whenever we switched to Fastly.

[22:16:44] <hwgasdfasdf> pypi.python.org is an alias for python.map.fastly.net. python.map.fastly.net has address 23.235.47.223

[22:17:02] <_habnabit> dstufft, ah okay

[22:17:09] <dstufft> hwgasdfasdf: what version of pip is this

[22:17:32] <dstufft> pip supports SANs in every version that verifies TLS except maybe 1.3 (it may there too, I don't rightly know)

[22:17:36] <hwgasdfasdf> whatever got installed with virtualenv 12.1.1

[22:17:54] <_habnabit> it's doing a pip version check, so i think it's >6

[22:18:08] <hwgasdfasdf> I'm not getting anything on the dig

[22:18:24] <dstufft> oh

[22:18:27] <hwgasdfasdf> connection timed out, no servers could be reached was the final error

[22:18:27] <dstufft> yea

[22:18:28] <dstufft> pip 6 then

[22:19:02] <dstufft> how old is your OpenSSL

[22:19:11] <hwgasdfasdf> probably ancient

[22:19:24] <dstufft> it's possible it doesn't support sha256 certificates

[22:19:37] <dstufft> alternatively if your on a Linux system you might be using the system store

[22:19:41] <dstufft> and that might not support digicert

[22:19:59] <hwgasdfasdf> it's all customized up the wazoo to be 'more secure'

[22:20:06] <hwgasdfasdf> it's a very non standard everything on this box

[22:20:42] <dstufft> can download https://raw.githubusercontent.com/pypa/pip/develop/pip/_vendor/requests/cacert.pem and try to do pip install --cert /path/to/that/cacert.pem and see if it works?

[22:22:09] <hwgasdfasdf> yeah, i can't even wget that, i'll have to download it on a different box and get to this box a different way

[22:22:16] <_habnabit> haha dang

[22:22:52] <hwgasdfasdf> wget throws a bunch of ssl errors too

[22:22:56] <hwgasdfasdf> ok, i got the file there now

[22:23:08] <dstufft> github uses digicert too I think

[22:24:12] <hwgasdfasdf> pretty much the same thing using that cert file

[22:24:18] <hwgasdfasdf> I'll try with the -v just a sec

[22:26:04] <hwgasdfasdf> http://pastebin.com/qyjhAxsK

[22:26:07] <hwgasdfasdf> looks very similar

[22:26:30] <dstufft> hwgasdfasdf: what version of Python is this

[22:26:42] <hwgasdfasdf> 2.7.5

[22:27:15] <dstufft> hwgasdfasdf: python -c "import ssl; print(ssl.OPENSSL_VERSION)"

[22:27:19] <dstufft> what's that say

[22:27:48] <hwgasdfasdf> haha, oh my

[22:27:50] <hwgasdfasdf> OpenSSL 0.9.8a 11 Oct 2005

[22:28:08] <dstufft> might be a sha256 issue then

[22:28:31] <dstufft> unfortinately I don't think we can work around a sha256 issues

[22:28:43] <dstufft> we only have a sha256 certificate

[22:28:51] <hwgasdfasdf> so basically the box needs a newer openssl

[22:29:18] <dstufft> that's my guess, #python-requests might have another idea though, pip just uses requests under the covers

[22:29:47] <hwgasdfasdf> wish they'd install at least python 2.7.9 as well, but getting anything changed in this image is a nightmare

[22:31:24] <hwgasdfasdf> ok, well at least a I have a good narative to submit an interesting support ticket now!