Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Hi, On Tue, Apr 16, 2024 at 1:45 PM Stéphane Glondu wrote: > > Hi, > > Le 15/04/2024 à 17:12, Bo YU a écrit : > >> 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 agree. > > I've pushed two minor changes. Please review them. Then, I will upload > the package. Okay, thanks. I have checked the two commits. LGTM. > > > I will open two separate reportbugs to track these issues once the > > package unloaded to unstable. > > Thank you for your work. Thanks for your work also and patience for me:) BR, Bo > > > Cheers, > > -- > Stéphane
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Hi, Le 15/04/2024 à 17:12, Bo YU a écrit : 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 agree. I've pushed two minor changes. Please review them. Then, I will upload the package. I will open two separate reportbugs to track these issues once the package unloaded to unstable. Thank you for your work. Cheers, -- Stéphane
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 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 >
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Dear Bo, Le 14/04/2024 à 16:30, Bo YU a écrit : 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. 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. 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. Cheers, -- Stéphane
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Hi, On Tue, Apr 9, 2024 at 2:18 PM Stéphane Glondu 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 >
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Hi! Thanks for your review of it quickly. On Tue, Apr 9, 2024 at 2:18 PM Stéphane Glondu 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. Now is the latest Standards-Version 4.7.0? Just noticed the announcement from the d-announcement mail list some days ago. > > Upstream copyright years are missing in debian/copyright. > > A .cma file is in a "OPT:" line in an .install.in file. Both above are easy to fix for me.:) > > 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. Here I want to get some help with how to fix the issue. In your view, which toolchain is the most likely cause of this problem? I mean dh_* or just bisect-ppx build toolchain itself. For these OCaml packages I packaged in the past weeks, it was about two packages has the same issue. This will cost more time given I known a little about OCaml but I will fix the issue definitely. > > 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.) I think repacking it should be fixed the issue, but is it overuse? Is it possible has another solution to fix it? like this[0] to be noticed when I was trying to fix another ftbfs issue. [0]: https://salsa.debian.org/ocaml-team/opam/-/blob/master/debian/gbp.conf?ref_type=heads#L4 > > 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. > Ok, got it. Thanks for your time again. I will fix these issue ASAP. BR, Bo
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
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. 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. 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.) 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. Thank you for your work, -- Stéphane
Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "bisect-ppx": * Package name : bisect-ppx Version : 2.8.3-1 Upstream contact : Xavier Clerc , * URL : https://github.com/aantron/bisect_ppx * License : Expat * Vcs : https://salsa.debian.org/ocaml-team/bisect-ppx Section : ocaml The source builds the following binary packages: libbisect-ppx-ocaml - Code coverage for OCaml and ReScript (runtime files) libbisect-ppx-ocaml-dev - Code coverage for OCaml and ReScript (dev files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/bisect-ppx/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/b/bisect-ppx/bisect-ppx_2.8.3-1.dsc Changes for the initial release: bisect-ppx (2.8.3-1) UNRELEASED; urgency=low . * Initial release. (Closes: #1068621) -- Regards, -- Bo YU signature.asc Description: PGP signature
