00:50 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5523 [default]

01:20 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-s390x/builds/1380 [default]

01:41 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/646 [default]

05:00 <bbot2> Started: http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/3033 [default]

07:12 <bbot2> Success: http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/3033 [default]

09:25 <arigato> can someone with a mac try to "pip install cffi==1.14.3"? Please check that you're really downloading

09:25 <arigato> ``cffi-1.14.3-2-*.whl`` (note the ``-2-``)

09:26 <arigato> experimenting with an actual feature of pypi to add "build numbers" inside release numbers, which as far as I can tell is the solution to many problems I have encountered and seen others encounter, but is somehow kept quiet about

10:29 <mattip> seems to work as advertised, even on python2 in my macos vm. I can't copy/paste out the actual output, but it picked up the 1.14.3-2 wheel

10:48 <arigato> thank you!

13:22 <mattip> I wonder how long I should wait after rc2 before releasing

13:22 <mattip> it's been ~24 hours with no comments

13:27 <dstufft> arigato: you might be the first person to actually use build numbers

13:43 <mgorny> mattip: i'm still testing

13:43 <mgorny> it's not that easy

13:53 <mattip> mgorny: is there something from our end that would make it easier?

13:53 <mattip> (and thanks for testing)

13:55 <mgorny> mattip: XFAIL on tests known to fail? ;-)

13:57 <mattip> hmm. I wonder if we could do that in our strange RegrTest class in lib-python/conftest.py,

13:58 <mattip> but somehow convince the buildbot summary page to show the tests are xfailed

13:58 <mattip> ahh, no it would need to be in the test files for it to help you

13:59 <mattip> does unittest support that?

14:00 <mgorny> yes

14:00 <mgorny> but it would mean we have to keep diff against original tests

14:01 <mgorny> hmm, unless CPython upstream would accept conditional xfails for pypy ;-)

14:01 <mgorny> but right now i want to test some random python software

14:01 <mgorny> + found ugly bug in my recent packages that i need to fix

14:13 <mgorny> mattip: https://docs.python.org/3/library/unittest.html#unittest.expectedFailure

14:14 <mgorny> https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures here's with example

14:20 <mattip> thanks

15:56 <mgorny> i'm going to try to test against pypy3.7 all packages that are installed to my system and were tested with pypy3.6 before

18:06 <arigato> dstufft: I'm still confused because it seems to be a feature that is there and that is the answer to various problems, but it's never mentioned. Is that out of some sense of "you shouldn't do that, it was a bad idea for pypi to introduce build numbers"?

18:07 <arigato> e.g. it would have avoided literally weeks of delay for the aarch wheels for cffi

18:07 <arigato> plus a failure of several hours to pip install cffi on macosx

18:08 <dstufft> arigato: I think the answer is nobody has ever used them, and so nobody is really sure if they actually work, or remembers they exist lol

18:30 <arigato> dstufft: I hope you don't mind if I go around stackoverflow and add a new answer to a few of the questions asking precisely that

18:31 <dstufft> arigato: of course not, I'm stoked it actually works

18:31 <arigato> :-)

18:32 <arigato> it seems to work even if you just rename the file before "twine upload", ignoring the fact that the wheel's internal metadata doesn't actually contain the corresponding "Build: NN" entry. But as far as I can tell, this "Build:" is never used anywhere

18:32 <dstufft> like any feature it can probably be abused in ways that we'd prefer people didn't do, but at the end of the day, projects are generally free to manage themselves how they like

18:33 <arigato> yes, I added a footer to my answer saying that. I think it's a very reasonable answer to "oops, one of the wheels was badly built, let's delete it and re-upload just that wheel"

18:34 <arigato> particularly in the cffi's original case which was "cool, let's add a wheel for a new platform, but oops, it's broken and we need to delete it but we can't upload a fixed one then"

18:42 <dstufft> yea those are ideal cases for it

18:46 <mgorny> mattip: have you ever seen anything like that: https://dpaste.com/GX7JQ37D8#line-65 ?

18:46 <mgorny> it happened just once, on next attempt the package built fine

18:50 <arigato> mgorny: that's obscure, indeed

18:53 <arigato> this code is theoretically fragile, the same error could occur very rarely (also on CPython) I think

18:54 <mgorny> if i understand correctly, it means socket.__dict__ changed

18:54 <arigato> yes

18:54 <arigato> unsure what, but maybe there is a __del__ that wrote to socket.__dict__?

18:56 <mgorny> even if, i don't see how that could've happened in middle of _convert() method

18:56 <mgorny> unless i'm mistaken, it should be evaluated immediately

18:56 <arigato> no, that's possible (but hard) in CPython, and less rare in PyPy

18:56 <arigato> __del__ methods run at random times

18:57 <arigato> (always with pypy, and with CPython only if the object is referenced from a gc cycle)

18:57 <mgorny> hrm

18:57 <arigato> (but isn't itself part of this gc cycle)

18:58 <mgorny> would a possible solution be to block gc while modules are being imported?

18:58 <mgorny> well, workaround

18:59 <arigato> well, no, the same problem can occur at any time. here it happens to occur while modules are imported

19:00 <arigato> an immediate fix would be to change enum.py to use something safe, like "for name in list(source)"

19:00 <arigato> (note that Python 2.7 was saner, by the fact that .keys() returned a list, which avoids this kind of issues and others)

19:01 <mgorny> still ,it seems somewhat crazy that socket.__dict__ would randomly change like that

19:01 <arigato> I agree

19:01 <arigato> I guess we can try to run "pypy3 -c 'import socket'" in a loop until it hits the same crash

19:02 <arigato> maybe by varying internal parameters like "--jit threshold=NUMBER"

19:10 <mgorny> i'll file a bug about it once i finish testing

20:18 <arigato> thank you

20:37 <mgorny> so far 20 failed packages

20:38 <mgorny> but gotta check if they weren't broken before