Bug#770449: ITP, RFS for Caml Crush package
On 12/12/2014 17:53, Stéphane Glondu wrote: Le 02/12/2014 13:34, Thomas Calderon a écrit : 1. I have split the debian-related files from the master branch. I will now use upstream and debian branches instead. Therefore, release tarballs will not contain this directory. $ tar tf ../caml-crush_1.0.4.orig.tar.gz|grep debian caml-crush-1.0.4/debian/ caml-crush-1.0.4/debian/caml-crush-clients.install caml-crush-1.0.4/debian/caml-crush-clients.lintian-overrides caml-crush-1.0.4/debian/caml-crush-server.init [...] Is that intentional? 2. You were right, there was no valid reason to have the SOs directly in /usr/lib, I moved them to /usr/lib/triplet/caml-crush. This has indeed the positive effect of suppressing the lintian issues. 3. I switched to the Debian-pkcs11proxyd system account and group. 4. Since we rely on OCaml native compilers, I switched from the ocaml-nox build dependency to ocaml-native-compilers and have Architecture: any instead. 5. Since Caml Crush does not (yet) support using bytecode-only architecture, we rely on ocaml-native-compilers to restrict the supported architectures. Fine. I have uploaded a new version on mentors.debian.net Also, could you make a single changelog entry for the initial release? Cheers, Hi Stéphane, I've fixed the remaining debian directory in the upstream archive (issue related to a misplaced git tag) and I have issued a single Changelog for the Initial release. The latest version is available on mentors.debian.net Regards, -- Cordialement, Thomas Calderon Laboratoire architectures matérielles et logicielles Sous-direction expertise ANSSI Tél: 01 71 75 88 55 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770449: ITP, RFS for Caml Crush package
Le 02/12/2014 13:34, Thomas Calderon a écrit : 1. I have split the debian-related files from the master branch. I will now use upstream and debian branches instead. Therefore, release tarballs will not contain this directory. $ tar tf ../caml-crush_1.0.4.orig.tar.gz|grep debian caml-crush-1.0.4/debian/ caml-crush-1.0.4/debian/caml-crush-clients.install caml-crush-1.0.4/debian/caml-crush-clients.lintian-overrides caml-crush-1.0.4/debian/caml-crush-server.init [...] Is that intentional? 2. You were right, there was no valid reason to have the SOs directly in /usr/lib, I moved them to /usr/lib/triplet/caml-crush. This has indeed the positive effect of suppressing the lintian issues. 3. I switched to the Debian-pkcs11proxyd system account and group. 4. Since we rely on OCaml native compilers, I switched from the ocaml-nox build dependency to ocaml-native-compilers and have Architecture: any instead. 5. Since Caml Crush does not (yet) support using bytecode-only architecture, we rely on ocaml-native-compilers to restrict the supported architectures. Fine. I have uploaded a new version on mentors.debian.net Also, could you make a single changelog entry for the initial release? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770449: ITP, RFS for Caml Crush package
On 02/12/2014 13:34, Thomas Calderon wrote: On 24/11/2014 18:01, Stéphane Glondu wrote: Le 21/11/2014 13:31, Thomas Calderon a écrit : I submitted an ITP (#770296) and an RFS (#770449) request regarding the packaging of Caml Crush. [...] First remarks: 1. There is a debian directory in the upstream tarball, is that intentional? Keep in mind that is is ignored in favour of the one in .debian.tar.xz; the two agree for now, but this might change in the future. 2. Shouldn't the SOs of caml-crush-clients be installed in their own directory? Have you compared with existing PKCS#11 providers? Moreover, this might remove the need for Lintian overrides. 3. Consider the Account Naming section of [1]. 4. Why do you enumerate architectures instead of using Architecture: any? Is the lack of arm64 on purpose? 5. I am suspicious about the package not using dh-ocaml. Especially on bytecode architectures. [1] https://wiki.debian.org/AccountHandlingInMaintainerScripts Cheers, Hi, Thanks for the initial review. 1. I have split the debian-related files from the master branch. I will now use upstream and debian branches instead. Therefore, release tarballs will not contain this directory. 2. You were right, there was no valid reason to have the SOs directly in /usr/lib, I moved them to /usr/lib/triplet/caml-crush. This has indeed the positive effect of suppressing the lintian issues. 3. I switched to the Debian-pkcs11proxyd system account and group. 4. Since we rely on OCaml native compilers, I switched from the ocaml-nox build dependency to ocaml-native-compilers and have Architecture: any instead. 5. Since Caml Crush does not (yet) support using bytecode-only architecture, we rely on ocaml-native-compilers to restrict the supported architectures. I have uploaded a new version on mentors.debian.net Regards, Hi Stephane, Did you have the time to look at the up-to-date package I uploaded to mentors (1.0.4) ? -- Cordialement, Thomas Calderon Laboratoire architectures matérielles et logicielles Sous-direction expertise ANSSI Tél: 01 71 75 88 55 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770449: ITP, RFS for Caml Crush package
On 24/11/2014 18:01, Stéphane Glondu wrote: Le 21/11/2014 13:31, Thomas Calderon a écrit : I submitted an ITP (#770296) and an RFS (#770449) request regarding the packaging of Caml Crush. [...] First remarks: 1. There is a debian directory in the upstream tarball, is that intentional? Keep in mind that is is ignored in favour of the one in .debian.tar.xz; the two agree for now, but this might change in the future. 2. Shouldn't the SOs of caml-crush-clients be installed in their own directory? Have you compared with existing PKCS#11 providers? Moreover, this might remove the need for Lintian overrides. 3. Consider the Account Naming section of [1]. 4. Why do you enumerate architectures instead of using Architecture: any? Is the lack of arm64 on purpose? 5. I am suspicious about the package not using dh-ocaml. Especially on bytecode architectures. [1] https://wiki.debian.org/AccountHandlingInMaintainerScripts Cheers, Hi, Thanks for the initial review. 1. I have split the debian-related files from the master branch. I will now use upstream and debian branches instead. Therefore, release tarballs will not contain this directory. 2. You were right, there was no valid reason to have the SOs directly in /usr/lib, I moved them to /usr/lib/triplet/caml-crush. This has indeed the positive effect of suppressing the lintian issues. 3. I switched to the Debian-pkcs11proxyd system account and group. 4. Since we rely on OCaml native compilers, I switched from the ocaml-nox build dependency to ocaml-native-compilers and have Architecture: any instead. 5. Since Caml Crush does not (yet) support using bytecode-only architecture, we rely on ocaml-native-compilers to restrict the supported architectures. I have uploaded a new version on mentors.debian.net Regards, -- Cordialement, Thomas Calderon Laboratoire architectures matérielles et logicielles Sous-direction expertise ANSSI Tél: 01 71 75 88 55 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770449: ITP, RFS for Caml Crush package
Le 21/11/2014 13:31, Thomas Calderon a écrit : I submitted an ITP (#770296) and an RFS (#770449) request regarding the packaging of Caml Crush. [...] First remarks: 1. There is a debian directory in the upstream tarball, is that intentional? Keep in mind that is is ignored in favour of the one in .debian.tar.xz; the two agree for now, but this might change in the future. 2. Shouldn't the SOs of caml-crush-clients be installed in their own directory? Have you compared with existing PKCS#11 providers? Moreover, this might remove the need for Lintian overrides. 3. Consider the Account Naming section of [1]. 4. Why do you enumerate architectures instead of using Architecture: any? Is the lack of arm64 on purpose? 5. I am suspicious about the package not using dh-ocaml. Especially on bytecode architectures. [1] https://wiki.debian.org/AccountHandlingInMaintainerScripts Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
