Some (build) problems with lang/haxe

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Some (build) problems with lang/haxe

Matthias Kilian
Hi,

this happens for me on amd64-current (OpenBSD 6.6-current (GENERIC.MP)
#11: Wed Feb 26 09:47:43 MST 2020), ports tree from about the same
time:

I've noticed that lang/haxe tries to download some files at build
time using curl, which fails when using dpb or setting PORTS_PRIVSEP=Yes
(which everyone should do) and blocking outgoing traffic for user
_pbuild (which is the default):

[...]
Running[8]: (cd _build/default/src/generator/data && /usr/local/bin/curl -L -s https://www.unicode.org/Public/12.1.0/ucd/DerivedCoreProperties.txt -o DerivedCoreProperties.txt)
[...]
Running[11]: (cd _build/default/src/generator/data && /usr/local/bin/curl -L -s https://www.unicode.org/Public/12.1.0/ucd/extracted/DerivedGeneralCategory.txt -o DerivedGeneralCategory.txt)
[...]
Running[13]: (cd _build/default/src/generator/data && /usr/local/bin/curl -L -s https://www.unicode.org/Public/12.1.0/ucd/PropList.txt -o PropList.txt)
Command [11] exited with code 7:
$ (cd _build/default/src/generator/data && /usr/local/bin/curl -L -s https://www.unicode.org/Public/12.1.0/ucd/extracted/DerivedGeneralCategory.txt -o DerivedGeneralCategory.txt)
[...]
Command [8] exited with code 7:
$ (cd _build/default/src/generator/data && /usr/local/bin/curl -L -s https://www.unicode.org/Public/12.1.0/ucd/DerivedCoreProperties.txt -o DerivedCoreProperties.txt)
[...]
Command [13] exited with code 7:
$ (cd _build/default/src/generator/data && /usr/local/bin/curl -L -s https://www.unicode.org/Public/12.1.0/ucd/PropList.txt -o PropList.txt)
[...]

Traces of those commands appear in
haxe-ocamldeps/sedlex/src/generator/data/dune within WRKDIR, but I
don't know much about ocaml and the build system used by lang/haxe.

This should be fixed, and maybe shielded against happening again
(for people *not* using PORTS_PRIVSEP etc.) by copying /bin/false
to WRKDIR/bin (I didn't try wether that would help).

Furthermore, maybe related or not (I guess not, because otherwise
regulat bulk builders would see this problem, too, as they're fore
sure blocking traffic from _pbuild), my build fails later at this
point:

Running[42]: (cd _build/default && /usr/local/bin/ocamlopt.opt -w @1..3@5..28@30..39@43@46..47@49..57@61..62-40 -strict-sequence -strict-formats -short-paths -keep-locs -w -9 -g -I src/syntax/.sedlex_ppx.objs/byte -I src/syntax/.sedlex_ppx.objs/native -I /home/ports/pobj/p2/haxe-4.0.5/haxe-4.0.5/ocamldeps/gen/_build/install/default/lib/gen -I /home/ports/pobj/p2/haxe-4.0.5/haxe-4.0.5/ocamldeps/ocaml-migrate-parsetree/_build/install/default/lib/ocaml-migrate-parsetree -I /home/ports/pobj/p2/haxe-4.0.5/haxe-4.0.5/ocamldeps/ppx_derivers/_build/install/default/lib/ppx_derivers -I /home/ports/pobj/p2/haxe-4.0.5/haxe-4.0.5/ocamldeps/ppx_tools_versioned/_build/install/default/lib/ppx_tools_versioned -I /home/ports/pobj/p2/haxe-4.0.5/haxe-4.0.5/ocamldeps/ppx_tools_versioned/_build/install/default/lib/ppx_tools_versioned/metaquot_405 -I /usr/local/lib/ocaml/bytes -I /usr/local/lib/ocaml/compiler-libs -I src/lib/.sedlex.objs/byte -I src/lib/.sedlex.objs/native -intf-suffix .ml -no-alias-deps -opaque -open Sedlex_ppx -o src/syntax/.sedlex_ppx.objs/native/sedlex_ppx__Ppx_sedlex.cmx -c -impl src/syntax/ppx_sedlex.pp.ml)
gmake: *** [Makefile:10: build] Error 1
*** Error 2 in lang/haxe (Makefile:82 'do-build')
[...]

I'm using dpb -uR, so my packages aren't always rebuilt (only if
dpb detects a package signature change), but at least my ocaml-related
packages are relatively fresh -- here's a list of the packages
lang/haxe directly depends on:

-rw-r--r--  3 root     _pbuild     645371 Dec  3 21:58 boehm-gc-7.6.0p4.tgz
-rw-rw-r--  2 _pbuild  _pbuild   13112517 Feb 28 12:53 dune-1.11.3p0.tgz
-rw-rw-r--  2 _pbuild  _pbuild    1287755 Feb 28 22:30 findlib-1.8.1p1.tgz
-rw-r--r--  3 root     _pbuild     281287 Dec  8 18:21 nekovm-2.3.0p0.tgz
-rw-r--r--  3 root     _pbuild  134363455 Feb 26 15:28 ocaml-4.09.0.tgz
-rw-r--r--  3 root     _pbuild    7751250 Feb 26 17:01 ocaml-camlp5-7.11.tgz
-rw-r--r--  3 root     _pbuild     804617 Feb 26 16:24 ocaml-cppo-1.6.6p1.tgz
-rw-r--r--  3 root     _pbuild    1253138 Oct 27 02:00 pcre-8.41p2.tgz

Ciao,
        Kili

Reply | Threaded
Open this post in threaded view
|

Re: Some (build) problems with lang/haxe

Thomas Frohwein-2
On Fri, Feb 28, 2020, at 3:58 PM, Matthias Kilian wrote:

> Hi,
>
> this happens for me on amd64-current (OpenBSD 6.6-current (GENERIC.MP)
> #11: Wed Feb 26 09:47:43 MST 2020), ports tree from about the same
> time:
>
> I've noticed that lang/haxe tries to download some files at build
> time using curl, which fails when using dpb or setting PORTS_PRIVSEP=Yes
> (which everyone should do) and blocking outgoing traffic for user
> _pbuild (which is the default):
>
> [...]
> Running[8]: (cd _build/default/src/generator/data &&
> /usr/local/bin/curl -L -s
> https://www.unicode.org/Public/12.1.0/ucd/DerivedCoreProperties.txt -o
> DerivedCoreProperties.txt)
> [...]
> Running[11]: (cd _build/default/src/generator/data &&
> /usr/local/bin/curl -L -s
> https://www.unicode.org/Public/12.1.0/ucd/extracted/DerivedGeneralCategory.txt -o DerivedGeneralCategory.txt)
> [...]
> Running[13]: (cd _build/default/src/generator/data &&
> /usr/local/bin/curl -L -s
> https://www.unicode.org/Public/12.1.0/ucd/PropList.txt -o PropList.txt)
> Command [11] exited with code 7:
> $ (cd _build/default/src/generator/data && /usr/local/bin/curl -L -s
> https://www.unicode.org/Public/12.1.0/ucd/extracted/DerivedGeneralCategory.txt -o DerivedGeneralCategory.txt)
> [...]
> Command [8] exited with code 7:
> $ (cd _build/default/src/generator/data && /usr/local/bin/curl -L -s
> https://www.unicode.org/Public/12.1.0/ucd/DerivedCoreProperties.txt -o
> DerivedCoreProperties.txt)
> [...]
> Command [13] exited with code 7:
> $ (cd _build/default/src/generator/data && /usr/local/bin/curl -L -s
> https://www.unicode.org/Public/12.1.0/ucd/PropList.txt -o PropList.txt)
> [...]

Hi,

Thanks for identifying this issue. I have tried to look over my build logs before committing, but this escaped me. Unfortunately, the OCaml/opam/dune build ecosystem is very obscure claiming to take care of (or hide) "most of the low-level details of OCaml compilation" [1].

This shouldn't have happened. I'll mark the port BROKEN again; it clearly needs more time than what was noticed before. I'm sorry that this snuck in undetected.

[1] https://github.com/ocaml/dune