Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Hi,
Thanks for your review and loop in me with #1017530.
On Mon, Apr 15, 2024 at 2:03 PM Stéphane Glondu <glondu@debian.org> wrote:
>
> Dear Bo,
>
> Le 14/04/2024 à 16:30, Bo YU a écrit :
...
> > ```
> > In fact, the original solution is that I refer to this[1]. But I am
> > not sure if this is a toolchain issue or not, so I have reported this
> > to upstream[2] also. The workaround for this issue I could think of:
> > 1. Keep those lintian messages here and open a reportbug to track the
> > issue until upstream fix the issue;
> > 2. Use the solution like [1] as my previous post and open a reportbug
> > to track the issue until upstream fix the issue;
> > 3. Wait to upstream to fix this issue;
> > 4. Persuading the maintainers of debhelper to strip static library
> > with broader name scheme.But I think this is not a good wishlist.:)
> > Personally I prefer to option 2 still.
>
> Thank you for looking into this, I wasn't expecting that!
>
> By a "toolchain issue", I meant an issue in debhelper or lintian (or
> maybe in dh-ocaml or ocaml itself). This is definitely not an upstream
> issue (of bisect-ppx), as all OCaml packages face it.
>
> One possible fix would be to change dh_strip, for example by telling it
> to strip $FOO.a if $FOO.cmxa exists, if this is correct (I'm not sure: I
> don't know why lib*.a are stripped in the first place). That would be
> your option 4. Or fix lintian to not issue the warning for $FOO.a if
> $FOO.cmxa exists. Right now, I don't know which option is correct.
>
> But this should not hinder bisect-ppx packaging, so I would go to option
> 1 first, then investigate which of my two options is the correct one.
Okay, I can do some experimental/feedback on these both tools here also.
>
> > For dh_dwz issue. It seems that the issue will be fixed by passing
> > `--no-dwz-multifile` arg. In my understanding, there is two ELF
> > binaries on the debug package, so the no-mutlifile arg can assure
> > dropping `../.dwz/../.debug`.
>
> Again, I've seen this issue several times with OCaml packages, but I
> didn't bother to investigate. It looks like another toolchain issue,
> which should be fixed in a more central package, not in bisect-ppx
> itself. So just leave the lintian warnings as is.
It seems the issue should be fixed on lintian side as your analyst.
But unfortunately, this is one lintian error that will lead to
ftp-master auto-rejected if uploaded:
```
E: libbisect-ppx-ocaml-dbgsym: stripped-library
[usr/lib/debug/.dwz/x86_64-linux-gnu/libbisect-ppx-ocaml.debug]
E: libbisect-ppx-ocaml-dev-dbgsym: stripped-library
[usr/lib/debug/.dwz/x86_64-linux-gnu/libbisect-ppx-ocaml-dev.debug]
```
I tried many attempts but failed. One common workaround is shipping
one lintian-override via dh_lintian, like[0] and [1]. Although the
error was gone, but we will get another error:
```
libbisect-ppx-ocaml-dev-dbgsym: non-debug-file-in-debug-package
[usr/share/lintian/overrides/libbisect-ppx-ocaml-dev-dbgsym]
```
Passing `--no-dwz-multifile` to dh_dwz maybe has side effects on the
debug package but it seems this is a workaround if we can upload to
upstable.And
I will open two separate reportbugs to track these issues once the
package unloaded to unstable.
Thanks again.
BR,
Bo
[0]: https://www.mail-archive.com/pkg-kde-talk@alioth-lists.debian.net/msg00457.html
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820310#22
>
>
> Cheers,
>
> --
> Stéphane
>
Reply to: