From matti.picus at gmail.com Thu Oct 1 04:43:12 2020 From: matti.picus at gmail.com (Matti Picus) Date: Thu, 1 Oct 2020 11:43:12 +0300 Subject: [pypy-dev] About PySide2 In-Reply-To: References: Message-ID: <4a285924-3089-e924-28c2-94d6b7b6e350@gmail.com> On 10/1/20 12:12 AM, Mustafa Ulubas wrote: > Hi there, > > Hope you are doing well. > > I'm currently working on a project which I'm trying to use PyPy in > order to speed up our simulation?processes. There are a couple of > dependencies that our project has including PySide2. > > I've tried to install PySide2 into PyPy however?I couldn't. From what > I understand as a result of my investigations, currently, PyPy doesn't > support PySide2. > > First of all, is that true? Does PyPy really not support it? > > Is there any way to install it? > > I'll be waiting for your response. > > Thanks in advance. > > Mustafa > Hi. Thanks for trying PyPy. I tried to build PySide2 with PyPy back in July, and both PySide2 and PyPy were adjusted to support the recent 7.3.2 release. With that, you will need to build from source, which can be painful. For getting a binary build, I think your best bet would be to use conda. Support right now is not in place, but there are intentions to make it work. On the performance side, it is expected that the interface layer via the C-API will be slower than CPython, while your pure python code may run faster than CPython. Matti From hodgestar at gmail.com Thu Oct 1 11:53:32 2020 From: hodgestar at gmail.com (Simon Cross) Date: Thu, 1 Oct 2020 17:53:32 +0200 Subject: [pypy-dev] [hpy-dev] Re: Interaction between HPy_CAST and HPy_AsPyObject In-Reply-To: References: Message-ID: The plan looks good! From Srinivasa.KempapuraPadmanabha at arm.com Wed Oct 7 06:35:18 2020 From: Srinivasa.KempapuraPadmanabha at arm.com (Srinivasa Kempapura Padmanabha) Date: Wed, 7 Oct 2020 10:35:18 +0000 Subject: [pypy-dev] Pypy on aarch64 (rhe7) has issues with bzip2-libs Message-ID: Hi, When I extract the pypy prebuild package as instructions provided in the site. I see that the binary fails to run ./bin/pypy3: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory We have installed bzip2 1.0.6 but still I see somewhere that the package requires other compatible version of it. /usr/lib64/libbz2.so /usr/lib64/libbz2.so.1 /usr/lib64/libbz2.so.1.0.6 Can you please provide more details on that [A close up of a sign Description automatically generated] Srinivasa Kempapura Padmanabha | Staff Engineer Technology Operations Services Group Email & SFB & Teams: srikem01 at arm.com Mobile: +91 9980633788 Bagmane World technology Center- SEZ, Citrine Block 11th Floor, Marathahalli ORR, Mahadevapura, Bangalore -560048, India IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1686 bytes Desc: image001.jpg URL: From niklas.bivald at enplore.com Wed Oct 7 11:50:18 2020 From: niklas.bivald at enplore.com (Niklas B) Date: Wed, 7 Oct 2020 17:50:18 +0200 Subject: [pypy-dev] Pypy on aarch64 (rhe7) has issues with bzip2-libs In-Reply-To: References: Message-ID: What OS and version are you running on? Regards, Niklas > On 7 Oct 2020, at 12:35, Srinivasa Kempapura Padmanabha wrote: > > Hi, > > When I extract the pypy prebuild package as instructions provided in the site. I see that the binary fails to run > > ./bin/pypy3: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory > > We have installed bzip2 1.0.6 but still I see somewhere that the package requires other compatible version of it. > > /usr/lib64/libbz2.so > /usr/lib64/libbz2.so.1 > /usr/lib64/libbz2.so.1.0.6 > > Can you please provide more details on that > > > > > Srinivasa Kempapura Padmanabha | Staff Engineer > Technology Operations Services Group > Email & SFB & Teams: srikem01 at arm.com > Mobile: +91 9980633788 > Bagmane World technology Center- SEZ, Citrine Block 11th Floor, Marathahalli ORR, Mahadevapura, Bangalore -560048, India > > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Wed Oct 7 12:45:23 2020 From: matti.picus at gmail.com (Matti Picus) Date: Wed, 7 Oct 2020 19:45:23 +0300 Subject: [pypy-dev] Pypy on aarch64 (rhe7) has issues with bzip2-libs In-Reply-To: References: Message-ID: On 10/7/20 1:35 PM, Srinivasa Kempapura Padmanabha wrote: > > Hi, > > When I extract the pypy prebuild package as instructions provided in > the site. I see that the binary fails to run > > ./bin/pypy3: error while loading shared libraries: libbz2.so.1.0: > cannot open shared object file: No such file or directory > > We have installed bzip2 1.0.6 but still I see somewhere that the > package requires other compatible version of it. > > /usr/lib64/libbz2.so > > /usr/lib64/libbz2.so.1 > > /usr/lib64/libbz2.so.1.0.6 > > Can you please provide more details on that > I think you need to make a symlink to the needed so sudo ln -s /usr/lib64/libbz2.so.1.0 /usr/lib64/libbz2.so.1.0.6 What OS are you using? Matti From wlavrijsen at lbl.gov Wed Oct 7 13:30:17 2020 From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov) Date: Wed, 7 Oct 2020 10:30:17 -0700 (PDT) Subject: [pypy-dev] pypy and pyproject.toml Message-ID: Hi, pip 21 is (likely) going to drop the fallback of running `setup.py install` if wheels can not be build. I've been using that fallback b/c wheels are not installed immediately on completion and do not respect the dependency order for build-time, whereas `setup.py install` does. With a "pyproject.toml" file, which pip supports, I can control the build environment again and that works quite nicely for CPython. For PyPy, however, I am unable to make selections based on the PyPy version. I can make selections based on the PyPy Python version, e.g. 2.7, 3.5, etc., but I'm talking about the actual PyPy version (e.g. 7.2.0). Does anyone know how to add a marker based on the PyPy version in a pyproject.toml file? Or, how else to enforce build dependencies for pip in the same way that can be done with the pyproject.toml file? Thanks, Wim -- WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net From ulubas9090 at gmail.com Wed Oct 7 18:04:04 2020 From: ulubas9090 at gmail.com (Mustafa Ulubas) Date: Wed, 7 Oct 2020 23:04:04 +0100 Subject: [pypy-dev] About PySide2 Message-ID: ?Hello there, I?m looking for someone who can help me to build-install PySide2 into PyPy. That?d be really helpful and appreciated if there is anyone. Thanks Mustafa From matti.picus at gmail.com Wed Oct 7 23:26:03 2020 From: matti.picus at gmail.com (Matti Picus) Date: Thu, 8 Oct 2020 06:26:03 +0300 Subject: [pypy-dev] pypy and pyproject.toml In-Reply-To: References: Message-ID: <68e3467d-52b9-167d-099e-b7ef6165da14@gmail.com> An HTML attachment was scrubbed... URL: From Srinivasa.KempapuraPadmanabha at arm.com Thu Oct 8 01:42:38 2020 From: Srinivasa.KempapuraPadmanabha at arm.com (Srinivasa Kempapura Padmanabha) Date: Thu, 8 Oct 2020 05:42:38 +0000 Subject: [pypy-dev] Pypy on aarch64 (rhe7) has issues with bzip2-libs In-Reply-To: References: Message-ID: <9E6EB8ED-90EB-495F-8485-9E03B2D42A2D@arm.com> Hi, I am running on rhe7 aarch64, I tried but it din't work. Regards, ?On 07/10/20, 10:16 PM, "Matti Picus" wrote: On 10/7/20 1:35 PM, Srinivasa Kempapura Padmanabha wrote: > > Hi, > > When I extract the pypy prebuild package as instructions provided in > the site. I see that the binary fails to run > > ./bin/pypy3: error while loading shared libraries: libbz2.so.1.0: > cannot open shared object file: No such file or directory > > We have installed bzip2 1.0.6 but still I see somewhere that the > package requires other compatible version of it. > > /usr/lib64/libbz2.so > > /usr/lib64/libbz2.so.1 > > /usr/lib64/libbz2.so.1.0.6 > > Can you please provide more details on that > I think you need to make a symlink to the needed so sudo ln -s /usr/lib64/libbz2.so.1.0 /usr/lib64/libbz2.so.1.0.6 What OS are you using? Matti IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From armin.rigo at gmail.com Thu Oct 8 04:05:33 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Thu, 8 Oct 2020 10:05:33 +0200 Subject: [pypy-dev] Pypy on aarch64 (rhe7) has issues with bzip2-libs In-Reply-To: <9E6EB8ED-90EB-495F-8485-9E03B2D42A2D@arm.com> References: <9E6EB8ED-90EB-495F-8485-9E03B2D42A2D@arm.com> Message-ID: Hi, On Thu, 8 Oct 2020 at 07:42, Srinivasa Kempapura Padmanabha wrote: > I am running on rhe7 aarch64, I tried but it din't work. You have to run `ldconfig` (without arguments, as root) for the system to pick up the new symlink. A bient?t, Armin From armin.rigo at gmail.com Thu Oct 8 04:07:59 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Thu, 8 Oct 2020 10:07:59 +0200 Subject: [pypy-dev] Pypy on aarch64 (rhe7) has issues with bzip2-libs In-Reply-To: References: <9E6EB8ED-90EB-495F-8485-9E03B2D42A2D@arm.com> Message-ID: ... ah, also the command given by matti has the arguments in the wrong order (I think). It should be sudo ln -s /usr/lib64/libbz2.so.1.0.6 /usr/lib64/libbz2.so.1.0 Armin From Srinivasa.KempapuraPadmanabha at arm.com Thu Oct 8 04:21:59 2020 From: Srinivasa.KempapuraPadmanabha at arm.com (Srinivasa Kempapura Padmanabha) Date: Thu, 8 Oct 2020 08:21:59 +0000 Subject: [pypy-dev] Pypy on aarch64 (rhe7) has issues with bzip2-libs In-Reply-To: References: <9E6EB8ED-90EB-495F-8485-9E03B2D42A2D@arm.com> Message-ID: I think it's looking for /usr/lib64/libbz2.so.1.0.0 which I am not sure if that's compatible I have created the symbolic link and yet idn't work Srinivasa Kempapura Padmanabha | Staff Engineer Technology Operations Services Group Email & SFB & Teams: srikem01 at arm.com Mobile: +91 9980633788 Bagmane World technology Center- SEZ, Citrine Block 11th Floor, Marathahalli ORR, Mahadevapura, Bangalore -560048, India ?On 08/10/20, 1:39 PM, "Armin Rigo" wrote: ... ah, also the command given by matti has the arguments in the wrong order (I think). It should be sudo ln -s /usr/lib64/libbz2.so.1.0.6 /usr/lib64/libbz2.so.1.0 Armin IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From armin.rigo at gmail.com Thu Oct 8 06:44:33 2020 From: armin.rigo at gmail.com (Armin Rigo) Date: Thu, 8 Oct 2020 12:44:33 +0200 Subject: [pypy-dev] Pypy on aarch64 (rhe7) has issues with bzip2-libs In-Reply-To: References: <9E6EB8ED-90EB-495F-8485-9E03B2D42A2D@arm.com> Message-ID: Hi, On Thu, 8 Oct 2020 at 10:22, Srinivasa Kempapura Padmanabha wrote: > I think it's looking for /usr/lib64/libbz2.so.1.0.0 which I am not sure if that's compatible It should be, if it differs only in the last digit. > I have created the symbolic link and yet idn't work Sorry, I can't help you more. Maybe if you described with more details what "didn't work"? What are you running and what error message are you getting? Armin From Srinivasa.KempapuraPadmanabha at arm.com Thu Oct 8 07:43:30 2020 From: Srinivasa.KempapuraPadmanabha at arm.com (Srinivasa Kempapura Padmanabha) Date: Thu, 8 Oct 2020 11:43:30 +0000 Subject: [pypy-dev] Pypy on aarch64 (rhe7) has issues with bzip2-libs In-Reply-To: References: <9E6EB8ED-90EB-495F-8485-9E03B2D42A2D@arm.com> Message-ID: <7F07BE8D-8474-4606-BF30-2FAC6DA0E8B3@arm.com> Hi, Thank you so much for your response, I tried all methods including patchelf as well. But it din't help, hence initiated mail thread. However, I will also find if there is something else missing on my env. No, worries. Let me send you the complete details in sometime with snapshot but for now, please see the following I have downloaded and symlinked the libbz2.so libraries in customized path and then append that path to LD_LIBRARY_PATH, followed by it launched pypy which even didnt run. Please note, I am instlalling pypy in customized path. # download and extract the pypy for arm arch. Host: > pwd /workspace/usr/workspace/pypy3.6-v7.2.0-aarch64/bin # launch pypy, gives error host> ./pypy3 ./pypy3: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory si-b6-24:srikem01 > ldd ./py pypy3* pypy3.debug Host : > ldd ./pypy3 ./pypy3: /lib64/libtinfo.so.5: no version information available (required by /workspace/usr /workspace/pypy3.6-v7.2.0-aarch64/bin/./libpypy3-c.so) linux-vdso.so.1 => (0x0000ffff80270000) libpypy3-c.so => /workspace/usr/workspace/pypy3.6-v7.2.0-aarch64/bin/./libpypy3-c.so (0x0000ffff7ce10000) libc.so.6 => /lib/libc.so.6 (0x0000ffff7cc80000) libutil.so.1 => /lib64/libutil.so.1 (0x0000ffff7cc20000) libdl.so.2 => /lib64/libdl.so.2 (0x0000ffff7cbf0000) libbz2.so.1.0 => not found libexpat.so.1 => /lib64/libexpat.so.1 (0x0000ffff7cba0000) libm.so.6 => /lib64/libm.so.6 (0x0000ffff7cae0000) libz.so.1 => /lib64/libz.so.1 (0x0000ffff7caa0000) libffi.so.6 => /lib64/libffi.so.6 (0x0000ffff7ca70000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000ffff7ca20000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffff7c9e0000) /lib/ld-linux-aarch64.so.1 (0x0000aaaab0830000) # locate if I have libbz2 so Host: > locate libbz2 /usr/lib64/libbz2.so /usr/lib64/libbz2.so.1 /usr/lib64/libbz2.so.1.0.6 # ldd to libpypy > ldd libpypy3-c.so ./libpypy3-c.so: /lib64/libtinfo.so.5: no version information available (required by ./libpypy3-c.so) linux-vdso.so.1 => (0x0000ffffa6480000) libutil.so.1 => /lib64/libutil.so.1 (0x0000ffffa2fe0000) libdl.so.2 => /lib64/libdl.so.2 (0x0000ffffa2fb0000) libbz2.so.1.0 => not found libexpat.so.1 => /lib64/libexpat.so.1 (0x0000ffffa2f60000) libm.so.6 => /lib64/libm.so.6 (0x0000ffffa2ea0000) libz.so.1 => /lib64/libz.so.1 (0x0000ffffa2e60000) libffi.so.6 => /lib64/libffi.so.6 (0x0000ffffa2e30000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000ffffa2de0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffffa2da0000) libc.so.6 => /lib/libc.so.6 (0x0000ffffa2c10000) /lib/ld-linux-aarch64.so.1 (0x0000aaaad4050000) But libtinfo actually exists > locate libtinfo.so.5 /usr/lib64/libtinfo.so.5 /usr/lib64/libtinfo.so.5.9 #Append the LD_LIBRARY_PATH to have /usr/lib64 host > setenv LD_LIBRARY_PATH /lib:/usr/lib:/usr/lib64 host > ls libpypy3-c.so libpypy3-c.so.debug pypy3 pypy3.debug host > ./libpypy3-c.so Segmentation fault host > ldd ./libpypy3-c.so ./libpypy3-c.so: /usr/lib64/libtinfo.so.5: no version information available (required by ./libpypy3-c.so) linux-vdso.so.1 => (0x0000ffffa9050000) libutil.so.1 => /usr/lib64/libutil.so.1 (0x0000ffffa5be0000) libdl.so.2 => /usr/lib64/libdl.so.2 (0x0000ffffa5bb0000) libbz2.so.1.0 => not found libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x0000ffffa5b30000) libm.so.6 => /usr/lib64/libm.so.6 (0x0000ffffa5a70000) libz.so.1 => /usr/lib64/libz.so.1 (0x0000ffffa5a30000) libffi.so.6 => /usr/lib64/libffi.so.6 (0x0000ffffa5a00000) libtinfo.so.5 => /usr/lib64/libtinfo.so.5 (0x0000ffffa59b0000) libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x0000ffffa5970000) libc.so.6 => /lib/libc.so.6 (0x0000ffffa57e0000) /lib/ld-linux-aarch64.so.1 (0x0000aaaade890000) host > ldd /usr/lib64/libtinfo.so.5 linux-vdso.so.1 => (0x0000ffffb1960000) libc.so.6 => /lib/libc.so.6 (0x0000ffffb1770000) /lib/ld-linux-aarch64.so.1 (0x0000aaaae5410000) host > rpm -qf /usr/lib64/libtinfo.so.5 ncurses-libs-5.9-14.20130511.el7_4.aarch64 host > Regards, Srini ?On 08/10/20, 4:16 PM, "Armin Rigo" wrote: Hi, On Thu, 8 Oct 2020 at 10:22, Srinivasa Kempapura Padmanabha wrote: > I think it's looking for /usr/lib64/libbz2.so.1.0.0 which I am not sure if that's compatible It should be, if it differs only in the last digit. > I have created the symbolic link and yet idn't work Sorry, I can't help you more. Maybe if you described with more details what "didn't work"? What are you running and what error message are you getting? Armin IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From Srinivasa.KempapuraPadmanabha at arm.com Fri Oct 9 04:25:20 2020 From: Srinivasa.KempapuraPadmanabha at arm.com (Srinivasa Kempapura Padmanabha) Date: Fri, 9 Oct 2020 08:25:20 +0000 Subject: [pypy-dev] Pypy on aarch64 (rhe7) has issues with bzip2-libs In-Reply-To: <7F07BE8D-8474-4606-BF30-2FAC6DA0E8B3@arm.com> References: <9E6EB8ED-90EB-495F-8485-9E03B2D42A2D@arm.com> <7F07BE8D-8474-4606-BF30-2FAC6DA0E8B3@arm.com> Message-ID: <2BDCA900-6BE3-43D0-9363-9FC3D1F038D6@arm.com> Hi, I made everything work, I have extracted bzip and development packages of it to customized path and then set the LD path and also I have created symbolic link to libbz2.so.1 to 1.0.6 But, since we setup in customized path, we have to manual set the LD path which we are not supposed to do it. Regards, Srinivasa ?On 08/10/20, 5:13 PM, "Srinivasa Kempapura Padmanabha" wrote: Hi, Thank you so much for your response, I tried all methods including patchelf as well. But it din't help, hence initiated mail thread. However, I will also find if there is something else missing on my env. No, worries. Let me send you the complete details in sometime with snapshot but for now, please see the following I have downloaded and symlinked the libbz2.so libraries in customized path and then append that path to LD_LIBRARY_PATH, followed by it launched pypy which even didnt run. Please note, I am instlalling pypy in customized path. # download and extract the pypy for arm arch. Host: > pwd /workspace/usr/workspace/pypy3.6-v7.2.0-aarch64/bin # launch pypy, gives error host> ./pypy3 ./pypy3: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory si-b6-24:srikem01 > ldd ./py pypy3* pypy3.debug Host : > ldd ./pypy3 ./pypy3: /lib64/libtinfo.so.5: no version information available (required by /workspace/usr /workspace/pypy3.6-v7.2.0-aarch64/bin/./libpypy3-c.so) linux-vdso.so.1 => (0x0000ffff80270000) libpypy3-c.so => /workspace/usr/workspace/pypy3.6-v7.2.0-aarch64/bin/./libpypy3-c.so (0x0000ffff7ce10000) libc.so.6 => /lib/libc.so.6 (0x0000ffff7cc80000) libutil.so.1 => /lib64/libutil.so.1 (0x0000ffff7cc20000) libdl.so.2 => /lib64/libdl.so.2 (0x0000ffff7cbf0000) libbz2.so.1.0 => not found libexpat.so.1 => /lib64/libexpat.so.1 (0x0000ffff7cba0000) libm.so.6 => /lib64/libm.so.6 (0x0000ffff7cae0000) libz.so.1 => /lib64/libz.so.1 (0x0000ffff7caa0000) libffi.so.6 => /lib64/libffi.so.6 (0x0000ffff7ca70000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000ffff7ca20000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffff7c9e0000) /lib/ld-linux-aarch64.so.1 (0x0000aaaab0830000) # locate if I have libbz2 so Host: > locate libbz2 /usr/lib64/libbz2.so /usr/lib64/libbz2.so.1 /usr/lib64/libbz2.so.1.0.6 # ldd to libpypy > ldd libpypy3-c.so ./libpypy3-c.so: /lib64/libtinfo.so.5: no version information available (required by ./libpypy3-c.so) linux-vdso.so.1 => (0x0000ffffa6480000) libutil.so.1 => /lib64/libutil.so.1 (0x0000ffffa2fe0000) libdl.so.2 => /lib64/libdl.so.2 (0x0000ffffa2fb0000) libbz2.so.1.0 => not found libexpat.so.1 => /lib64/libexpat.so.1 (0x0000ffffa2f60000) libm.so.6 => /lib64/libm.so.6 (0x0000ffffa2ea0000) libz.so.1 => /lib64/libz.so.1 (0x0000ffffa2e60000) libffi.so.6 => /lib64/libffi.so.6 (0x0000ffffa2e30000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000ffffa2de0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000ffffa2da0000) libc.so.6 => /lib/libc.so.6 (0x0000ffffa2c10000) /lib/ld-linux-aarch64.so.1 (0x0000aaaad4050000) But libtinfo actually exists > locate libtinfo.so.5 /usr/lib64/libtinfo.so.5 /usr/lib64/libtinfo.so.5.9 #Append the LD_LIBRARY_PATH to have /usr/lib64 host > setenv LD_LIBRARY_PATH /lib:/usr/lib:/usr/lib64 host > ls libpypy3-c.so libpypy3-c.so.debug pypy3 pypy3.debug host > ./libpypy3-c.so Segmentation fault host > ldd ./libpypy3-c.so ./libpypy3-c.so: /usr/lib64/libtinfo.so.5: no version information available (required by ./libpypy3-c.so) linux-vdso.so.1 => (0x0000ffffa9050000) libutil.so.1 => /usr/lib64/libutil.so.1 (0x0000ffffa5be0000) libdl.so.2 => /usr/lib64/libdl.so.2 (0x0000ffffa5bb0000) libbz2.so.1.0 => not found libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x0000ffffa5b30000) libm.so.6 => /usr/lib64/libm.so.6 (0x0000ffffa5a70000) libz.so.1 => /usr/lib64/libz.so.1 (0x0000ffffa5a30000) libffi.so.6 => /usr/lib64/libffi.so.6 (0x0000ffffa5a00000) libtinfo.so.5 => /usr/lib64/libtinfo.so.5 (0x0000ffffa59b0000) libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x0000ffffa5970000) libc.so.6 => /lib/libc.so.6 (0x0000ffffa57e0000) /lib/ld-linux-aarch64.so.1 (0x0000aaaade890000) host > ldd /usr/lib64/libtinfo.so.5 linux-vdso.so.1 => (0x0000ffffb1960000) libc.so.6 => /lib/libc.so.6 (0x0000ffffb1770000) /lib/ld-linux-aarch64.so.1 (0x0000aaaae5410000) host > rpm -qf /usr/lib64/libtinfo.so.5 ncurses-libs-5.9-14.20130511.el7_4.aarch64 host > Regards, Srini On 08/10/20, 4:16 PM, "Armin Rigo" wrote: Hi, On Thu, 8 Oct 2020 at 10:22, Srinivasa Kempapura Padmanabha wrote: > I think it's looking for /usr/lib64/libbz2.so.1.0.0 which I am not sure if that's compatible It should be, if it differs only in the last digit. > I have created the symbolic link and yet idn't work Sorry, I can't help you more. Maybe if you described with more details what "didn't work"? What are you running and what error message are you getting? Armin IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From wlavrijsen at lbl.gov Sat Oct 10 18:51:53 2020 From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov) Date: Sat, 10 Oct 2020 15:51:53 -0700 (PDT) Subject: [pypy-dev] pypy and pyproject.toml In-Reply-To: <68e3467d-52b9-167d-099e-b7ef6165da14@gmail.com> References: <68e3467d-52b9-167d-099e-b7ef6165da14@gmail.com> Message-ID: Matti, > Although implementation_version looks promising, it is defined as > "sys.implementation.version" which is an alias to the python version. > "implementation" is also not helpful. does pypy even have a sys.implementation? (My installation doesn't?) For now, I'm simply breaking the build environment, which forces a fallback to setup.py install. At least this will work until pip 21 is out, although rumor has it that pip 21 may not break that just yet. Best regards, Wim -- WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net From andrewsmedina at gmail.com Fri Oct 16 09:57:38 2020 From: andrewsmedina at gmail.com (Andrews Medina) Date: Fri, 16 Oct 2020 10:57:38 -0300 Subject: [pypy-dev] Help to contribute Message-ID: Hi! I'm want to get some time for week to contribute to pypy. I already have sent a few pr's approved in the past with small py3.x lib fixes. Do you think that this is a good way to restart to contribute? There is a branch for 3.8 or there are things to fix in 3.7? Best regards, -- Andrews Medina -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Sat Oct 17 17:35:59 2020 From: matti.picus at gmail.com (Matti Picus) Date: Sun, 18 Oct 2020 00:35:59 +0300 Subject: [pypy-dev] Help to contribute In-Reply-To: References: Message-ID: <5fa368aa-3572-798f-a1d2-c3f537630096@gmail.com> On 10/16/20 4:57 PM, Andrews Medina wrote: > Hi! > > I'm want to get some time for week to contribute to pypy. I already > have sent a few pr's approved in the past with small py3.x lib fixes. > Do you think that this is a good way to restart to contribute? There > is a branch for 3.8 or there are things to fix in 3.7? > > Best regards, > > -- > Andrews Medina > Sounds great. The failing 3.7 tests can be seen on the buildbot http://buildbot.pypy.org/summary?branch=py3.7. Remember that we try not to change the lib-python tests without good reason. Those come from CPython and are the "golden results" by definition. Also we have moved development to https://foss.heptapod.net/pypy/pypy, so you will need to request that we add you as a developer to the site so you can push new branches. Please disregard heptapod's recommendation to use "topic branches", we have decided to stick with the "named branches" from bitbucket days. Matti From andrewsmedina at gmail.com Sat Oct 17 19:31:03 2020 From: andrewsmedina at gmail.com (Andrews Medina) Date: Sat, 17 Oct 2020 20:31:03 -0300 Subject: [pypy-dev] Help to contribute In-Reply-To: <5fa368aa-3572-798f-a1d2-c3f537630096@gmail.com> References: <5fa368aa-3572-798f-a1d2-c3f537630096@gmail.com> Message-ID: Thanks for the tips. I will choose a failing module and I will try to fix it. I hope to send a pull request soon. On Sat, Oct 17, 2020 at 6:36 PM Matti Picus wrote: > > > On 10/16/20 4:57 PM, Andrews Medina wrote: > > Hi! > > > > I'm want to get some time for week to contribute to pypy. I already > > have sent a few pr's approved in the past with small py3.x lib fixes. > > Do you think that this is a good way to restart to contribute? There > > is a branch for 3.8 or there are things to fix in 3.7? > > > > Best regards, > > > > -- > > Andrews Medina > > > > Sounds great. The failing 3.7 tests can be seen on the buildbot > http://buildbot.pypy.org/summary?branch=py3.7. Remember that we try not > to change the lib-python tests without good reason. Those come from > CPython and are the "golden results" by definition. > > > Also we have moved development to https://foss.heptapod.net/pypy/pypy, > so you will need to request that we add you as a developer to the site > so you can push new branches. Please disregard heptapod's recommendation > to use "topic branches", we have decided to stick with the "named > branches" from bitbucket days. > > > Matti > -- Andrews Medina www.andrewsmedina.com From matti.picus at gmail.com Sun Oct 18 08:48:44 2020 From: matti.picus at gmail.com (Matti Picus) Date: Sun, 18 Oct 2020 15:48:44 +0300 Subject: [pypy-dev] summary of PyPy progess since the 7.3.2 release Message-ID: <2a05946f-ea07-b5b1-8ead-9c081c1e0223@gmail.com> We have made some good progress since the 7.3.2 release, it seems our activity is on an uptick. To keep the wave going, here is the status of the various things that have seen work lately with some "call to actions". This is my summary so it probably contains some errors. I will not call out specific contributors, since I would probably miss a few, but a big thanks to all of them. default python2.7 ----------------- The stdlib was updated to 2.7.18 We are still missing some basic cpyext compatability that users have asked for, I have started marking these issues with "cpyext" py3.6 ------- The stdlib was updated to 3.6.12 There are a number of failures around weakref py3.7 ------- The stdlib was updated to 3.7.4 for the release. There are numerous lib-python failures There is a mysterious (to me) crash in the lib-python tests on windows The regex library still needs updating to match upstream Windows ------- There is a win64 branch off default! It appears to have no fewer failures than the default branch, but cpyext and micronumpy are disabled. There is also a win64-py3.6 branch, which translates but has problems running untranslated tests, I think due to some problem with the rsocket module and addresses. hpy_universal ------------- The hpy backend module is active on the py3.6 branch and all its children. It is disabled on 32 bit and fails win64-py3.6 own tests. speed.pypy.org -------------------- We should switch the landing page to show benchmarks on the python3 versions. This is a web-stack/devops task more than a rpython one, so might be a good place to get different contributors involved. pypy + conda ------------ Main packages like scikit-learn, scikit-image, scipy are all available on linux64 + arm64 + macOS on conda. The current situation can be seen by going to https://conda-forge.org/status/, scrolling down 1/2 way to the "pypy migration" section, clicking the purple "in pr" button. "typed-ast" is the biggest blocker, and will not be solved soon. I think it is a false-positive for many of the children packages: they are not really dependent on it. Help here would be looking at the failures of your favorite package and nudging the upstream team to add PyPy to their CI, fix those failures, then fix the conda recipe and get it merged. Any help would be welcome: whether coding, specific hints where things might be going wrong, marketing to get the work out that pypy + conda is usable, help getting sponsors or? coders to move the windows branch forward, help with conda feedstock recipes, ... Matti From vano at mail.mipt.ru Thu Oct 29 21:27:54 2020 From: vano at mail.mipt.ru (Ivan Pozdeev) Date: Fri, 30 Oct 2020 04:27:54 +0300 Subject: [pypy-dev] Checksums for some old releases changed Message-ID: <7e3acba1-7ec4-b531-590c-29b6001b13f6@mail.mipt.ru> When rechecking URLs in installation scripts in Pyenv to fix any invalid ones since the project has moved from BitBucket ( https://github.com/pyenv/pyenv/pull/1692 ) , I noticed that checksums for downloads for some old PyPy releases have changed. See the altered hashes in this diff to see which exactly: https://github.com/pyenv/pyenv/pull/1692/files . Could someone explain why? Were the archives repackaged or something? -- Regards, Ivan From matti.picus at gmail.com Fri Oct 30 02:53:55 2020 From: matti.picus at gmail.com (Matti Picus) Date: Fri, 30 Oct 2020 08:53:55 +0200 Subject: [pypy-dev] Checksums for some old releases changed In-Reply-To: <7e3acba1-7ec4-b531-590c-29b6001b13f6@mail.mipt.ru> References: <7e3acba1-7ec4-b531-590c-29b6001b13f6@mail.mipt.ru> Message-ID: <556b1e56-2e1e-63c0-96b1-87325ef0c797@gmail.com> On 10/30/20 3:27 AM, Ivan Pozdeev via pypy-dev wrote: > When rechecking URLs in installation scripts in Pyenv to fix any > invalid ones since the project has moved from BitBucket ( > https://github.com/pyenv/pyenv/pull/1692 ) , > I noticed that checksums for downloads for some old PyPy releases have > changed. > > See the altered hashes in this diff to see which exactly: > https://github.com/pyenv/pyenv/pull/1692/files . > > Could someone explain why? Were the archives repackaged or something? Thanks for the heads-up. If I read the diff correctly from that PR, there is are two tarballs whose hash changed in the transition from https://bitbucket.org/pypy/pypy/get to https://downloads.python.org/pypy: pypy3-v5.10.1-osx64-2.tar.bz2 pypy-4.0.0-win32.zip It is hard to say what might have happened. Perhaps the safe thing to do is to remove them. Matti For completeness, here is a summary of the other changes in that PR: These changed in the transition from bitbucket/squeaky/portable-pypy to bitbucket-archive.softwareheritage.org pypy3.5-5.7-beta-linux_x86_64-portable.tar.bz2 pypy3.5-5.8-1-beta-linux_x86_64-portable.tar.bz2 pypy-5.1.1-linux_x86_64-portable.tar.bz2 pypy-5.0.1-linux_x86_64-portable.tar.bz2 pypy-4.0.1-linux_x86_64-portable.tar.bz2 pypy-4.0-linux_x86_64-portable.tar.bz2 these were renamed release-2.5.0.tar.bz2 -> pypy-2.5.0-src.tar.bz2 release-2.4.0.tar.bz2 -> pypy-2.4.0-src.tar.bz2 release-2.3.1.tar.bz2 -> pypy-2.3.1-src.tar.bz2 pypy-1.5-src.tar.bz2 -> pypy-release-1.5.tar.gz and these were removed pypy-1.5-linux.tar.bz2 pypy-1.5-linux64.tar.bz2 pypy-1.5-osx64.tar.bz2 pypy-1.5-win32.zip There are also changes to stackless python that are not related to PyPy.