00:13 <marmoute> You could call it CFoo 2.8 ;-)

12:31 <cfbolz> I understand that it's all a mess for packagers :-(. but I also remember the days when we had to move from 2.4->2.5->2.6->2.7 in two versions, pypy and cpy, and every one of them broke rpython and it was all super annoying

13:41 <mgorny> The main problem is that py27 is swiss cheese, speaking security wise

13:42 <mgorny> I've been able to strip pypy2.7 in Gentoo quite a lot to make it useless beyond what's needed by rpython

13:42 <mgorny> But doing the same to cpython is much harder

13:42 <cfbolz> mgorny: right, that makes sense

13:42 <cfbolz> because cpython is not modular enough?

14:23 <mgorny> mostly because pypy is using cffi while cpython has awful makefiles with lots of C

14:43 <antocuni> I'm not sure to understand: why is "security" a problem here? If you use CPython *only* to compile pypy and remove it afterwards, most the the security problems simply don't apply?

14:43 <antocuni> unless I'm missing something

14:45 <nimaje> you still have it in the package repos then, so someone could install it and use it for something else where security matters more

15:10 <mgorny> basically what nimaje said

15:10 <mgorny> i'm planning to make it harder to install accidentally but it still "feels" wrong to have something that dangerous around

15:11 <mgorny> and as i said, i expect more trouble with things like system libraries changing

15:11 <mgorny> i'm going to guess without looking that python2.7 fails to build correctly with clang-16

15:11 <mgorny> (it's much more strict than older versions)

16:25 <mattip> mgorny: would it help if we provided a binary "pypy2.7 compiler" package that has only what is needed to run rpython to build pypy3,

16:25 <mattip> with no _ssl, _sqlite3, and most of the stdlib removed?

16:42 <mgorny> no real difference for me

16:42 <mgorny> as i already do that ;-)

17:55 <mattip> ahh, cool. Would it help Gentoo if we created the binary artifact for download from https://downloads.python.org/pypy/ ?

18:09 <mgorny> nope, we're not into binary artifacts

18:12 <LarstiQ> mgorny: surely there is a bottom for bootstrapping?

18:26 <mgorny> we bootstrap using py2.7, then rebuild using itself ;-)

19:20 <antocuni> how do you bootstrap gcc? (genuine question, I don't really know)

19:39 <cfbolz> antocuni: it's not an answer to your question, but I love this paper: https://arxiv.org/abs/2202.09231

19:44 <cfbolz> ah, it has a section on getting gcc from scratch, page 8

19:48 <lazka> another option is you cross compile

19:55 <cfbolz> sure, but it's a much more satisfying puzzle to think about what you would have to do if you can't ;-)

20:34 <antocuni> cfbolz: well, if I understand correctly they start with a TinyC binary, which makes sense

20:34 <antocuni> but mgorny point is that they don't want to use any binary, which sounds difficult/impossible?

20:35 <cfbolz> antocuni: you can go all the way back to a tiny hand-assembled binary, if you simply work hard enough :-P

20:35 <antocuni> sure :)

20:36 <antocuni> but indeed, it's fascinating that the modern way to bootstrap gcc is to compile an old version first