Hi, Quoting Stéphane Glondu (2021-01-06 16:02:05) > Le 24/12/2020 à 17:37, Johannes 'josch' Schauer a écrit : > > my package botch FTBFS on armel, mips64el and mipsel: > > > > https://buildd.debian.org/status/package.php?p=botch > > > > The reason is, that when calling dose-deb-coinstall it fails with "unknown > > option --verbose". Upon further investigation, it turns out, that the dose3 > > source package builds invalid binaries on armel, mips64el and mipsel. > > You can reproduce the problem by building dose3 on a mipsel porter box > > with: > > > > $ apt-get source dose3 --build > > > > You then end up with the following identical working binaries: > > > > dose3-5.0.1/_build/applications/deb-coinstall.byte > > dose3-5.0.1/debian/tmp/usr/bin/dose-deb-coinstall > > > > But surprisingly, this one is different and also doesn't work as > > expected: > > > > $ dose3-5.0.1/debian/dose-extra/usr/bin/dose-deb-coinstall --help > > unknown option --help > > > > Funnily, the other non-working binaries, have the exact same md5sum: > > > > $ find dose3-5.0.1/ -type f -print0 | xargs -0 md5sum | grep 0261218e050b5c5c7ee1988fd1d4e5da > > 0261218e050b5c5c7ee1988fd1d4e5da dose3-5.0.1/debian/dose-extra/usr/bin/dose-deb-coinstall > > 0261218e050b5c5c7ee1988fd1d4e5da dose3-5.0.1/debian/dose-extra/usr/bin/dose-ceve > > 0261218e050b5c5c7ee1988fd1d4e5da dose3-5.0.1/debian/dose-distcheck/usr/bin/dose-distcheck > > > > I don't understand how this problem or what makes these three different from > > the other utilities built by the dose3 source package or how the error is only > > introduced when moving the binaries from debian/tmp to debian/dose-*. > > I can reproduce the problem in an amd64 chroot by first removing > /usr/bin/ocamlopt* and /usr/lib/ocaml/dynlink.cmx* (nice trick to > reproduce a fast bytecode environment). > > My suspicion was stripped custom bytecode executables... and this is > indeed the case. > > In Debian OCaml < 4.11, there was a Debian-specific patch that made > stripping custom bytecode executables possible. In (upstream) OCaml > 4.11, the feature was added, under a new command-line option > (-output-complete-exe). In Debian, I patched OCaml so that the new > feature is triggered with -custom... only if a specific environment > variable (OCAML_CUSTOM_USE_OUTPUT_COMPLETE_EXE) is set. This variable is > set by /usr/share/ocaml/ocamlvars.mk, included by the debian/rules of > most packages... but not the one of dose3. This is why this issue > happens only with dose3. > > > Maybe you have an idea of how to proceed? > > Possible fixes are: > > 1. do not strip dose3 executables > 2. include /usr/share/ocaml/ocamlvars.mk in dose3's debian/rules > 3. directly use -output-complete-exe instead of -custom > 4. do not use -custom nor -output-complete-exe at all > > I tried 2 (which is actually 3) and it does not work because > -output-complete-exe is incompatible with -a, and -a and -custom are > used together somewhere in dose3 build system. > > 1 should be easy to implement (empty override of dh_strip) and upload, > if urgent. > > I am currently looking into 4. awesome, thank you for your input! We are currently changing the buildsystem of dose3 to dune, so the problem might even become moot (I didn't try yet). But in case it doesn't I now know what to try out. :) Since this is not a src:ocaml bug, feel free to close this. Also, why I am in contact with you, could you also comment on https://salsa.debian.org/ocaml-team/camlbz2/-/commit/2fb669b0ae4a37417ac32bcbeca0055173b4d8bd#note_209628 Thanks! cheers, josch
Attachment:
signature.asc
Description: signature