Bug#978024: regression: 4.11.1 broke dose3 on bytecode arches

[Stéphane Glondu <glondu@debian.org>]

Control: reassign -1 dose3

Hello,

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.


Cheers,

-- 
Stéphane