- Package:
- ocamlbuild
- Source:
- ocamlbuild
- Description:
- Build tool for building OCaml libraries and programs
- Submitter:
- Mònica RamÃrez Arceda
- Date:
- 2021-07-17 09:48:04 UTC
- Severity:
- important
- Tags:
Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: http://people.debian.org/~lucas/logs/2011/09/23/bin-prot_1.3.1-3_lsid64.buildlog A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot. Internet was not accessible from the build systems.
tags 642706 + unreproducible thanks Le 24/09/2011 19:53, Mònica Ramírez Arceda a écrit : I cannot reproduce this. Can anyone else? Cheers,
I get the same error. Here's what I did to reproduce it. $ apt-get source libbin-prot-camlp4-dev $ cd bin-prot-1.3.1/ $ DIST=sid ARCH=amd64 git-pbuilder update $ pdebuild --pbuilder cowbuilder -- --basepath /var/cache/pbuilder/base-sid-amd64.cow
Le 25/09/2011 00:00, Eric Cooper a écrit : Well... this is very strange. The same steps (except that my chroot is in /var/cache/pbuilder/base.cow) do not produce any error on amd64. But I get the error on i386 and armel. Same symptoms with bug #642835. Investigating... Cheers,
tags 642706 - unreproducible thanks Le 25/09/2011 15:38, Stéphane Glondu a écrit : In my amd64 sid chroot, /bin/sh was symlinked to bash. After linking it to dash, I can reproduce the error. The error disappears if I downgrade dash to 0.5.5.1-7.4. I'm not yet sure who's to blame here... I'm putting dash maintainers in the loop. Cheers,
Yes, I had /bin/sh -> dash in my chroot also. Nice detective work.
block 642835 by 642922 block 642706 by 642922 severity 642922 serious thanks Le 25/09/2011 19:28, Stéphane Glondu a écrit : Raising severity, since it blocks serious bugs. Cheers,
severity 642922 important quit Stéphane Glondu wrote: [...] Thanks for letting me know. This is important (and a regression), but it should be possible to work around in ocamlbuild as easily as using "bash", so I don't see why that would make it release-critical. I'll investigate further to see if the underlying problem is an assumption in the relevant scripts that would be violated by ksh93, too, or just a dash bug. Thanks, Jonathan
Hi, Mònica Ramírez Arceda wrote: [...] Thanks again for all your work in tracking these down! I assume bin-prot/sid and sexplib310 build correctly again against dash 0.5.7-2. So what should be done with these bugs? I am tempted to say: - lower severity to important, since we have a workaround - reassign to current ocaml-nox - merge and mark as forwarded to http://caml.inria.fr/mantis/view.php?id=5371 Does that sound reasonable? Jonathan who is looking forward to having a few fewer RC bugs on his radar :)
merge 642706 642835 severity 642706 important reassign 642706 ocaml-nox found 642706 3.12.0-7 retitle 642706 ocamlbuild: questionable job control forwarded 642706 http://caml.inria.fr/mantis/view.php?id=5371 affects 642706 src:bin-prot src:sexplib310 thanks Le 16/10/2011 13:04, Jonathan Nieder a écrit : Agreed.
Herbert Xu wrote: [...] <https://github.com/ocaml/ocamlbuild/issues/164>, but https://github.com/ocaml/ocamlbuild/commit/00e05f686e15b07ac4268fcd10cf3738a5c28467 was applied with the proposed fix in ocamlbuild 0.9.0. I suspect this means that the ocamlbuild bug was indeed fixed, and that we should be able to reinstate the patch. Except... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642835;msg=55 says the bug is present in ocamlbuild 0.10.1. Ximin, do you remember where that version number came from? Is it possible that the bug is *not* present in that version? Thanks, Jonathan
❦ 27 May 2020 08:42 -07, Jonathan Nieder: Once bullseye is released, would it be possible to reinstate the patch? Or maybe in experimental. This way, it will be easier to check if the problem is still present. Moreover, everyone should not carry the burden of failures from ocamlbuild to correctly track processes. Another workaround would be to use bash for ocamlbuild if the problem is still here. While the footprint of /bin/sh is small, it is not zero and since most shells optimize this use case, many programs assume they can spawn process through `/bin/sh -c` at no cost. In my case, I was curious why processes spawned by i3 and its ecosystem were all leaving a /bin/sh instance behind.