Hi, On Tue, Apr 9, 2024 at 2:18 PM Stéphane Glondu <glo...@debian.org> wrote: > > Dear Bo, > > Le 08/04/2024 à 17:05, Bo YU a écrit : > > I am looking for a sponsor for my package "bisect-ppx": > > [...] > > I've reviewed the packaging and I have a few comments. > > Standards-Version is not the latest. > > Upstream copyright years are missing in debian/copyright. > > A .cma file is in a "OPT:" line in an .install.in file. >
Done. > I would not override dh_dwz nor dh_strip. My opinion is that what you > are trying to fix are deficiencies of the toolchain that should be fixed > there. First to address dh_strip issue. From what I've researched. The issue was raised by the static library generated from bisect_ppx did not obey the standard static library name scheme. The dh_strip[0] will strip the static library with `lib-*` prefix. But as we can observe the building: ``` I: libbisect-ppx-ocaml-dev: unstripped-static-library (bisect__Runtime.o) [usr/lib/ocaml/bisect_ppx/runtime/bisect.a] I: libbisect-ppx-ocaml-dev: unstripped-static-library (bisect_common.o) [usr/lib/ocaml/bisect_ppx/common/bisect_common.a] I: libbisect-ppx-ocaml-dev: unstripped-static-library (bisect_ppx__Exclude.o bisect_ppx__Exclude_lexer.o bisect_ppx__Exclude_parser.o bisect_ppx __Exclusions.o bisect_ppx__Instrument.o bisect_ppx__Register.o) [usr/lib/ocaml/bisect_ppx/bisect_ppx.a] ``` 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. 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`. [0]: https://github.com/Debian/debhelper/blob/master/dh_strip#L239C2-L244C27 [1]: https://lists.debian.org/debian-mentors/2015/10/msg00027.html [2]: https://github.com/aantron/bisect_ppx/issues/439 > > It is not right to override source-contains-prebuilt-javascript-object > in this case; you should filter the .js file out and make sure the > package works without it. Or get the actual sources and build from them. > Or find it in another Debian package. (These are just examples of how to > tackle the issue.) Okay, I repacked it by removing the prebuilt javascript file and put its source code which pulled from upstream into debian/missing-sources and then to get the file during the building. > > I am wondering about long-term maintainability of the manpage. I suppose > you've generated the manpage from running the command with --help? > Please make a rule to automatically generate it. Done. All commits I have pushed into the salsa [3] and mentor[4]. Thanks for your time again and please let me know any issues. BR, Bo [3]: https://salsa.debian.org/ocaml-team/bisect-ppx [4]: https://mentors.debian.net/package/bisect-ppx/ > > > Thank you for your work, > > -- > Stéphane >
