give-back pypy{,3} on ppc64el
Now that the buildds have the new kernel with CVE-2019-12817 fixed, pypy and pypy3 should build. Works for me on the porterbox. gb pypy_7.1.1+dfsg-1 pypy3_7.1.1+dfsg-1 . ppc64el Thanks, SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Please give-back pypy on ppc64el
Hi, I think I've got on top of pypy's build timeout issues, but we recently got a stuck build on ppc64el (usually one of the fastest architectures, rarely timing out). So probably a bug that caused something to lock-up rather than a timeout issue. gb pypy_7.0.0+dfsg-2 . ppc64el Thanks! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: give-back pypy on {armel,mips,mips64el,ppc64,sh4} (timeouts)
Hi Héctor (2017.11.28_11:56:09_+0200) Thank you for getting that done. > It would be even better if you could tweak the tests making sure there > is some output coming out before 150 min Yes, of course. Unfortunately, this isn't tests, it's the translation system, and I'm not entirely sure where to add more dot() calls to improve this. It's something I must talk to upstream about. We're probably exhausting RAM and thrashing a bit, towards the end of the build, where I think we're currently a little light on dot() calls. I need to learn more about that part of the system to be able to contribute a patch... SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: give-back pypy on {armel,mips,mips64el,ppc64,sh4} (timeouts)
Hi Héctor (2017.11.25_13:21:01_+0200) > Updated it on armel hosts. If that works and none beats me, I'll do > mips/mips64el and ppc64 next. Looks like it timed out again, with the same 150 min timeout SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
give-back pypy on {armel,mips,mips64el,ppc64,sh4} (timeouts)
pypy 5.9.0+dfsg-1 timed out on a bunch of buildds. Can we bump the timeout again? bunk filed #878479 about this too. ppc64 failed very early in the build, trying to find expat, but I can't reproduce that failure on pizzetti, it looks like it would build to completion, if pizzetti had more RAM. So, gb pypy_5.9.0+dfsg-1 . armel mips mips64el ppc64 sh4 Thanks, SR -- Stefano Rivera http://tumbleweed.org.za/
Please give-back python-cffi on arm64
Hi, python-cffi FTBFS on arm64 because of a libffi bug (#785756). A version fixing that bug just hit unstable. So, please, gb python-cffi_1.1.2-1 . arm64 gb python-cffi_1.1.2-2 . arm64 (The second one is for an upload in experimental) Thanks, SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150708202547.gj3...@bach.rivera.co.za
give-back pypy on mips (and blacklist on small buildds)
Hi debian-wb-team (2014.05.06_21:30:06_+0200)
> pypy 2.2.1+dfsg-2 built successfully on arm{el,hf} \o/ Finally we have
> buildds that are big enough.
>
> However, -3, failed on armhf because hoiby doesn't have enough RAM. Can
> we restrict it to hasse and henze (and any other >= 2GB RAM buildds),
> and give it back, please?
The same thing happened in mips. ball isn't big enough, but lucatelli
and corelli have been able to build it successfully in the past
(sometimes with some prodding).
gb pypy_2.2.1+dfsg-3 . mips
Thanks,
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 461 1230 C: +27 72 419 8559
--
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140513135247.ga3...@bach.rivera.co.za
Re: give-back pypy on armhf (and blacklist on small buildds)
Hi Hector (2014.05.07_11:11:33_+0200) > Assuming you mean big armhf buildds, it is already done. Thanks. I meant both armhf and armel. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140513134750.gl3...@bach.rivera.co.za
give-back pypy on armhf (and blacklist on small buildds)
Hi,
pypy 2.2.1+dfsg-2 built successfully on arm{el,hf} \o/ Finally we have
buildds that are big enough.
However, -3, failed on armhf because hoiby doesn't have enough RAM. Can
we restrict it to hasse and henze (and any other >= 2GB RAM buildds),
and give it back, please?
And I guess, similarly, restrict it to the big armel buildds.
gb pypy_2.2.1+dfsg-3 . armhf
Thanks,
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 461 1230 C: +27 72 419 8559
signature.asc
Description: Digital signature
Re: Please retry failed pypy builds on armel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 We have it built on i386 now, after blacklisting the buildd it kept failing on (unfortunately, I can't reproduce the problem). Can we retry on armel again? It used to build successfully on the 1.5GB boards. Alternatively, can I do a binary upload? I can reliably get it to build on my 2GB chromebook and ipa. It has never built successfully for armhf in Debian, because there haven't been buildds big enough (yet). Again, I can do it locally / on ipa, and would be happy to if the ARM porters approve. SR - -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Debian :: The Universal Operating System iQIcBAEBCgAGBQJS3EfzAAoJEACQ/CG1zRrM+nwP/1UJTbp9dYsmSmgxqQF94Han 1lzmZOzPemD6Ytb0N1vNDZjqJMlUAsRYmy8u0XgC/syhvnDImI6SmRtN6kJz8mtD pMism/w5iNkaGxPCuiR5b5TkeZPpNgtnhVTPMTMEDKZmx1n52XYk/gTykUa34/zd ZnMHIt5aKYnO0LdG3uqd94BttDbs7rEpKk7qRIy3VC725l70G+YuOK+XFK/Qv89l RBoK6Z9xAgX+/211JoGpRuptquctpXh8EwV1J1t0PTTRXWaIN+qq8kSeaIUTe4iK 5Tv8riieAxTK4CpPuw0pnauv1+D7UPIAP0Mktm2iRDVZZ6yYLhsIG7lstfIFJYlA 7F7Dok289RhOC/hxPNiUFchZheZ98W+VJndBmzI8x6tjZ116hFTd0Dk+6l47qJrs +3wstzlRuBH18YT1ysbb8qVyOffIdZXffqF1yIwwcpSnxSIQm0FMBbBVLSoh4LYT FOtVrWjxtdr27fWzKxroaFyal0LP6Xjcp1+nsKuljd5mU2pVtHQDwyKJ/ys+v62G Kxp9pVKc+AhaIDyJUxczOiWeCkX91k3IKe7nMEXJbbJFKCzVH8PdAvKFKKQSK42Q PBnysWbw5nmlF1oPUDBWZQBNPb6kESEvoosLSMh5AcbPVgLe/t2JXRXZaVIEoV9A ffbwuWkdzmao+U5Pnk2Z =MHFG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140119214732.gk3...@bach.rivera.co.za
Re: Please retry failed pypy builds on i386 and armel
Hi Kurt (2013.12.01_14:44:20_+0200) > I gave it back, we'll see what happens. Great, same failure on i386 :/ I tried locally (twice), and it built without issue. Retry again? I could also upload one of my builds, but I'd prefer it to build on a buildd. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131202182533.gz3...@bach.rivera.co.za
Re: Please retry failed pypy builds on i386 and armel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Hector (2013.12.01_03:56:26_+0200) > 2013/11/30 Stefano Rivera : > > PyPy usually builds on i386 (without any trouble) and armel (fairly > > slowly). The lastest upload timed out on both. We should retry (and > > possibly raise the timeouts a bit). > > > > gb pypy_2.2.1+dfsg-1 . i386 armel > > On armel: > E: Caught signal ‘Terminated’: terminating immediately > Build killed with signal TERM after 600 minutes of inactivity > > It is already increased. And re-looking at the i386 timeout, it's something I've seen before - probably failing to clean up a subprocess, and never temininating. Unfortunately I've never figured that one out, it happens occasionally. Increasing the i386 timeout wouldn't help. SR - -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Debian :: The Universal Operating System iQIcBAEBCgAGBQJSmpghAAoJEACQ/CG1zRrMwSkP/0xXl2sJ5nb2z9Z/EzYOaGrt VQ2Xq/A6llkaXae+b53N9qrqTZqJtgpRZTCMdLDdJbdZ3qzwCyn2wHP23G/zO6g2 svDzfMixyIze0hWaxMUzCnIiW9z4FSISXpqWNTy+uABLUNwhYuS1veSAlUKNUIlT Kph43Qy2cKrWfwKgOggVAMjnCkl/SSno/nqH3o2RKOyXXGUypdMxqoA0CRld8kmU ZxpjL5TSxt8Ouh+CMarpT9Ywc6P/DYTqV4+Tfiypcyxzy9BwZ9GJ6hweMurAd58j 9Jtk6ttDYDfjFu6IcSBX4uMUyNwRLyL66/XNP7g6LFWwokBUsvKTqnZWP510PaaE IIWnBzH7iaocpP/2xQ9vvPG5h6WFx/rPN7HLm5HiQ3DfBlKOhH52nU+ZJxEQandJ 0aM+Ky1zlc46jJYEoTeQtwOY2E/sB1UezOO++ieyWnsC1Kbc99TRavFu+V1Kt/1c lsSoP3QD3MHCXX0GWu/HhereQ1YoCdtMFJAkGbYLwCBa+KDKt1T8osUSJlKgLJf+ PKxFL7dMCOceFBXcoIB6xMnlrPmSmjwUnGFEr99qPFuucz+YapGNnMsfEw+Jg8Kx qOczQ4UKIMs3iE3qKhofVNYMjm2lrjtlswXGYqqcAYUFdU/i9iztA6U2wqkeARjn rGhZKMeCbbOW4McGKqwx =wnjc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131201020001.gw3...@bach.rivera.co.za
Please retry failed pypy builds on i386 and armel
PyPy usually builds on i386 (without any trouble) and armel (fairly slowly). The lastest upload timed out on both. We should retry (and possibly raise the timeouts a bit). gb pypy_2.2.1+dfsg-1 . i386 armel Thanks, SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 signature.asc Description: Digital signature
give-back pypy on sparc
Please give-back pypy on sparc, for another try. https://buildd.debian.org/status/logs.php?pkg=pypy&arch=sparc Pypy is a beast to build, with a fairly chequered build history, but has had reasonable luck on sparc in the past. In this case, it looks like we ran out of memory during profiling for PGO. 2.0.0+dfsg-1 was almost identical, and built successfully, so I reckon we should just retry it. I haven't seen memory errors during PGO before, if this becomes a problem, we can disable PGO on this arch... gb pypy_2.0.2+dfsg-1 . sparc Thanks, SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 signature.asc Description: Digital signature
Re: PyPy and its heavy memory requirements
Hi Philipp (2012.01.23_13:35:03_+0200) > > * zappa (s390x, not s390) > > * zemlinsky (s390x, not s390) zemlinksy looks like it had enough RAM a > > few weeks ago (1.7+dfsg-3), but not any more... > > For s390x you get enough virtual memory. The decision if it's RAM or > swap shouldn't matter, should it? It's almost certain to timeout if it's swapped to a normal hard drive (note the timeouts on ia64 that I can't explain) I'll exempt s390x or just zemlinsky from this check, as you say it's fast enough. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 signature.asc Description: Digital signature
PyPy and its heavy memory requirements
I've got a pypy package in experimental, which won't build on many of our buildds. Upstream hasn't ported to hurd, please P-a-s hurd-i386. There's a high memory requirement. It requires ~2G RAM on 32bit and ~4G on 64bit. The reason for this is that it introspects imported Python modules to generate C. This leads to very unpredictable memory use, which isn't going to handle being swapped-out well. On some architectures, we have some buildds that are too small (according to LDAP). Can it please be blacklisted on: * zappa (s390x, not s390) * zemlinsky (s390x, not s390) zemlinksy looks like it had enough RAM a few weeks ago (1.7+dfsg-3), but not any more... If the blacklisting must be done by the individual buildd admin teams, please let me know. On some architectures, we have no buildds (listed in LDAP) that are big enough. I don't know if you'd rather blacklist it on all the current buildds or block it with P-a-s. The archs are: * armel * armhf * mipsel We have mips buildds with 1.8G RAM (corelli, lucatelli), that may be able to handle it. I can reduce the check in debian/rules and see what happens, once we've blacklisted appropriately for the other architectures and buildds. Can it be blacklisted on: * ball * mayr All the ia64 buildds should have enough RAM, yet I'm getting timeouts on caballero and mundy. It builds fine for me on merulo, which has less RAM than mundy. Are there any other memory-hungry processes on mundy or caballero? Please also give back on the archs where there are bigger builders: gb pypy_1.7+dfsg-5 . s390x ia64 Sorry for the long e-mail, it's a big, demanding package. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 signature.asc Description: Digital signature
experimental: give-back re2 (on a faster buildd?)
Hi Debian (2011.05.03_07:00:11_+0200)
> * Source package: re2
> * Version: 0+hg57+dfsg-1
> * Architecture: mipsel
> * State: failed
> * Suite: experimental
> * Builder: monteverdi.ayous.org
> * Build log:
> https://buildd.debian.org/fetch.cgi?pkg=re2&arch=mipsel&ver=0%2Bhg57%2Bdfsg-1&stamp=1304398725&file=log
gb re2_0+hg57+dfsg-1 . mipsel
Looks like the (rather comprehensive) test suite isn't outputting dots
fast enough. Can you increase the timeout / give it back to a faster
buildd?
It's a parallel build & test suite, but also rather slow.
The test-runner attempts to output a . for every line of verbose input
and flush the dot:
| #!/bin/sh
| printf "\n%-40s running\n" $1
| if bash -c "set -o pipefail; $1 2>&1 | tee $1.log | awk '{printf \".\";
fflush() }'" 2>/dev/null
| then
| printf "\n%-40s PASS\n" $1
| else
| printf "\n%-40s FAIL; Output:\n" $1
| cat $1.log
| exit 1
| fi
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127
--
To UNSUBSCRIBE, email to debian-wb-team-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110503075300.gd1...@bach.rivera.co.za
