Bug#1052230: FTBFS with OCaml 4.14.1

[Thomas Calderon]

Thanks Stephane,

We are (over)due to update Caml-Crush to upstream some of the
changes/patches that were made to keep it compatible with newer versions of
Debian.
Thanks for looking into it.

Thomas

On Wed, Sep 20, 2023 at 9:39 AM Stéphane Glondu  wrote:

> Control: reassign -1 src:ocamlnet
> Control: retitle -1 "Missing build-dependency on pkg-config"
> Control: affects -1 src:caml-crush
>
> Le 20/09/2023 à 10:19, Stéphane Glondu a écrit :
> > The failure seems to be unrelated to OCaml 4.14.1, as the failure is
> > reproducible in current unstable with OCaml 4.13.1... Hence, raising
> > severity to serious.
>
> All this boils down to missing -lgnutls in nettls-gnutls, which seems to
> be fixed by adding pkg-config to ocamlnet's Build-Depends.
>
>
> Cheers,
>
> --
> Stéphane
>

Bug#973153: caml-crush: FTBFS: ocamlopt: OCaml has been configured with -force-safe-string: -unsafe-string is not available.

[Thomas Calderon]

I believe this is resolved in 1.0.12-1 published in unstable but I forgot
to add the *Closes* reference to the Changelog.

On Fri, Aug 20, 2021 at 10:51 AM Simon Chopin 
wrote:

> Source: caml-crush
> Followup-For: Bug #973153
>
> There's a PR upstream to deal with this:
>
> https://github.com/caml-pkcs11/caml-crush/pull/46
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers impish
>   APT policy: (500, 'impish'), (50, 'impish-proposed')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.13.0-14-generic (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>

Bug#990363: caml-crush: FTBFS with OpenSSL 3.0

[Thomas Calderon]

Thanks for the report.
I've been meaning to push an update to fix some other issues with Caml
Crush and recent Ocaml versions.


On Sun, Jun 27, 2021 at 11:45 AM Kurt Roeckx  wrote:

> Package: caml-crush
> Version: 1.0.10-4
>
> Hi,
>
> Your package is failing to build against OpenSSL 3.0 beta 1. The
> log file show:
> configure:6589: checking for SSL_get_peer_certificate in -lssl
> configure:6614: gcc -o conftest -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -I/usr/lib/ocaml -Wdate-time -D_FORTIFY_SOURCE=2
> -I/usr/lib/ocaml -Wl,-z,relro conftest.c -lssl  -lc  >&5
> /usr/bin/ld: /tmp/cc4uEWWT.o: in function `main':
> ./build-SERVER/conftest.c:38: undefined reference to
> `SSL_get_peer_certificate'
> collect2: error: ld returned 1 exit status
> configure:6614: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "cam-crush"
> | #define PACKAGE_TARNAME "cam-crush"
> | #define PACKAGE_VERSION "1.0.10"
> | #define PACKAGE_STRING "cam-crush 1.0.10"
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | #define STDC_HEADERS 1
> | #define HAVE_SYS_TYPES_H 1
> | #define HAVE_SYS_STAT_H 1
> | #define HAVE_STDLIB_H 1
> | #define HAVE_STRING_H 1
> | #define HAVE_MEMORY_H 1
> | #define HAVE_STRINGS_H 1
> | #define HAVE_INTTYPES_H 1
> | #define HAVE_STDINT_H 1
> | #define HAVE_UNISTD_H 1
> | #define HAVE_CAML_MLVALUES_H 1
> | #define HAVE_CAML_CAMLIDLRUNTIME_H 1
> | #define HAVE_DLFCN_H 1
> | #define HAVE_PTHREAD_H 1
> | #define HAVE_RPC_RPC_H 1
> | #define HAVE_RPC_CLNT_H 1
> | #define HAVE_LIBC 1
> | #define HAVE_OPENSSL_SSL_H 1
> | /* end confdefs.h.  */
> |
> | /* Override any GCC internal prototype to avoid an error.
> |Use char because int might match the return type of a GCC
> |builtin and then its argument prototype would still apply.  */
> | #ifdef __cplusplus
> | extern "C"
> | #endif
> | char SSL_get_peer_certificate ();
> | int
> | main ()
> | {
> | return SSL_get_peer_certificate ();
> |   ;
> |   return 0;
> | }
> configure:6623: result: no
> configure:6628: error: Cannot find symbol in openssl library.
>
> The function has been renamed, and the old name deprecated in 3.0.
> The header file actually has a define from the old name to the new
> name:
> #  ifndef OPENSSL_NO_DEPRECATED_3_0
> #   define SSL_get_peer_certificate SSL_get1_peer_certificate
> #  endif
>
> The easy fix is to actually include ssl.h when looking for
> symbol, so that you actually look for the renamed symbol.
>
>
> Kurt
>

Bug#959625: caml-crush: FTBFS: SP line 7: Not found a value in env for: session

[Thomas Calderon]

Hello,

I've released a new version of the package that addresses the issue with
coccinelle, I've then attempted to push the new package on ftpmaster-anon
as sources only.

Let me know if this was the right process.

Thanks!

Thomas Calderon


On Sun, 3 May 2020, 14:12 Lucas Nussbaum,  wrote:

> Source: caml-crush
> Version: 1.0.8-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200501 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > make[3]: Entering directory
> '/<>/build-SERVER/src/bindings-pkcs11'
> > camlidl -header ../../../src/bindings-pkcs11/pkcs11.idl
> > cat ../../../src/bindings-pkcs11/pkcs11_stubs.c | sed -e
> 's/Begin_roots_block(\(.*\)).*/Begin_roots_block(\1);/g' | sed -e
> 's/Begin_root(\(.*\)).*/Begin_root(\1);/g' | sed -e
> 's/End_roots(\(.*\)).*/End_roots(\1);/g' > ./tmp
> > mv ./tmp ../../../src/bindings-pkcs11/pkcs11_stubs.c
> > #Sed to patch (GetSlotList/GetMechList/FindObjects/GetObjectSize)
> > sed -i "s/* int/\* nativeint/g" ../../../src/bindings-pkcs11/pkcs11.mli
> > sed -i "s/* int/\* nativeint/g" ../../../src/bindings-pkcs11/pkcs11.ml
> > spatch --no-show-diff --in-place --sp-file
> ../../../src/bindings-pkcs11/pkcs11_stubs.cocci
> ../../../src/bindings-pkcs11/pkcs11_stubs.c
> > init_defs_builtins: /usr/bin/../lib/coccinelle/standard.h
> > warning: line 96: _ctxs, previously declared as a metavariable, is used
> as an identifier
> > warning: line 97: _ctx, previously declared as a metavariable, is used
> as an identifier
> > warning: line 97: _ctxs, previously declared as a metavariable, is used
> as an identifier
> > warning: line 98: _c1, previously declared as a metavariable, is used as
> an identifier
> > warning: line 99: _c2, previously declared as a metavariable, is used as
> an identifier
> > warning: line 104: _v3, previously declared as a metavariable, is used
> as an identifier
> > warning: line 104: _c2, previously declared as a metavariable, is used
> as an identifier
> > warning: line 104: _ctx, previously declared as a metavariable, is used
> as an identifier
> > warning: line 105: _c2, previously declared as a metavariable, is used
> as an identifier
> > warning: line 105: _v3, previously declared as a metavariable, is used
> as an identifier
> > warning: line 802: _ctxs, previously declared as a metavariable, is used
> as an identifier
> > warning: line 821: _ctxs, previously declared as a metavariable, is used
> as an identifier
> > HANDLING: ../../../src/bindings-pkcs11/pkcs11_stubs.c
> > #Sed because spatch is not able to preprocess
> > sed -i 's/^_CAMLIDL_EXTERN_C/extern/g'
> ../../../src/bindings-pkcs11/pkcs11.h
> > #Sed to change the structure packing pragma in WIN32 mode: CamlIDL fixes
> it to 8 while
> > #PKCS11 header fixes it to 1 => this can create binary interoperability
> issues
> > sed -i 's/push,8/push,1\/* Replaced for PKCS11 compatibiliy *\//g'
> ../../../src/bindings-pkcs11/pkcs11.h
> > spatch --no-show-diff --in-place --sp-file
> ../../../src/bindings-pkcs11/pkcs11.cocci
> ../../../src/bindings-pkcs11/pkcs11.h
> > init_defs_builtins: /usr/bin/../lib/coccinelle/standard.h
> > HANDLING: ../../../src/bindings-pkcs11/pkcs11.h
> > SP line 7: Not found a value in env for: session
> > make[3]: *** [Makefile:37: idl] Error 255
>
> The full build log is available from:
>http://qa-logs.debian.net/2020/05/01/caml-crush_1.0.8-1_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
>

Bug#959625: caml-crush: FTBFS: SP line 7: Not found a value in env for: session

[Thomas Calderon]

Hello,

Thanks for reaching out.
I will have a look it sounds like coccinelle (spatch) has changed behavior
and is now returning an error at compile-time, I will investigate this week.

Cheers,

Thomas

On Sun, May 3, 2020 at 2:12 PM Lucas Nussbaum  wrote:

> Source: caml-crush
> Version: 1.0.8-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200501 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > make[3]: Entering directory
> '/<>/build-SERVER/src/bindings-pkcs11'
> > camlidl -header ../../../src/bindings-pkcs11/pkcs11.idl
> > cat ../../../src/bindings-pkcs11/pkcs11_stubs.c | sed -e
> 's/Begin_roots_block(\(.*\)).*/Begin_roots_block(\1);/g' | sed -e
> 's/Begin_root(\(.*\)).*/Begin_root(\1);/g' | sed -e
> 's/End_roots(\(.*\)).*/End_roots(\1);/g' > ./tmp
> > mv ./tmp ../../../src/bindings-pkcs11/pkcs11_stubs.c
> > #Sed to patch (GetSlotList/GetMechList/FindObjects/GetObjectSize)
> > sed -i "s/* int/\* nativeint/g" ../../../src/bindings-pkcs11/pkcs11.mli
> > sed -i "s/* int/\* nativeint/g" ../../../src/bindings-pkcs11/pkcs11.ml
> > spatch --no-show-diff --in-place --sp-file
> ../../../src/bindings-pkcs11/pkcs11_stubs.cocci
> ../../../src/bindings-pkcs11/pkcs11_stubs.c
> > init_defs_builtins: /usr/bin/../lib/coccinelle/standard.h
> > warning: line 96: _ctxs, previously declared as a metavariable, is used
> as an identifier
> > warning: line 97: _ctx, previously declared as a metavariable, is used
> as an identifier
> > warning: line 97: _ctxs, previously declared as a metavariable, is used
> as an identifier
> > warning: line 98: _c1, previously declared as a metavariable, is used as
> an identifier
> > warning: line 99: _c2, previously declared as a metavariable, is used as
> an identifier
> > warning: line 104: _v3, previously declared as a metavariable, is used
> as an identifier
> > warning: line 104: _c2, previously declared as a metavariable, is used
> as an identifier
> > warning: line 104: _ctx, previously declared as a metavariable, is used
> as an identifier
> > warning: line 105: _c2, previously declared as a metavariable, is used
> as an identifier
> > warning: line 105: _v3, previously declared as a metavariable, is used
> as an identifier
> > warning: line 802: _ctxs, previously declared as a metavariable, is used
> as an identifier
> > warning: line 821: _ctxs, previously declared as a metavariable, is used
> as an identifier
> > HANDLING: ../../../src/bindings-pkcs11/pkcs11_stubs.c
> > #Sed because spatch is not able to preprocess
> > sed -i 's/^_CAMLIDL_EXTERN_C/extern/g'
> ../../../src/bindings-pkcs11/pkcs11.h
> > #Sed to change the structure packing pragma in WIN32 mode: CamlIDL fixes
> it to 8 while
> > #PKCS11 header fixes it to 1 => this can create binary interoperability
> issues
> > sed -i 's/push,8/push,1\/* Replaced for PKCS11 compatibiliy *\//g'
> ../../../src/bindings-pkcs11/pkcs11.h
> > spatch --no-show-diff --in-place --sp-file
> ../../../src/bindings-pkcs11/pkcs11.cocci
> ../../../src/bindings-pkcs11/pkcs11.h
> > init_defs_builtins: /usr/bin/../lib/coccinelle/standard.h
> > HANDLING: ../../../src/bindings-pkcs11/pkcs11.h
> > SP line 7: Not found a value in env for: session
> > make[3]: *** [Makefile:37: idl] Error 255
>
> The full build log is available from:
>http://qa-logs.debian.net/2020/05/01/caml-crush_1.0.8-1_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
>

Bug#929450: caml-crush, build-dependencies unsatisfiable on armel

[Thomas Calderon]

I don't think I have access or permissions to rename/reassign the bug to
ftpmaster so they can remove the armel binaries.

How can I move this forward so that the package doesn't get autoremoved
next week?

Thanks,

Thomas

On Fri, Jun 14, 2019 at 2:28 PM Thomas Calderon 
wrote:

> OK, let's have them removed, when I will push an updated version, I will
> make sure to remove armel from the list of targets.
>
> Do I need to do anything else for now?
>
> Thanks,
>
> Thomas
>
> On Thu, Jun 13, 2019 at 8:02 PM Peter Green 
> wrote:
>
>> On 13/06/19 10:00, Thomas Calderon wrote:
>> > Hi there,
>> >
>> > It's unfortunate that OCaml has removed the support for ocamlopt for
>> armel, it sounds like CamlCrush will not be able to ship for armel.
>> > Is it required that I create an updated Debian release excluding armel
>> as a target or as you said, ftpmaster can just remove the binaries?
>> Removing the binaries is enough in cases like this, they won't be rebuilt
>> until/unless their build-dependencies become available again.
>>
>> I'm not sure if the binary removal will propagate automatically from
>> unstable to testing during the freeze or if one needs to ask the release
>> team for that.
>>
>>

Bug#929450: caml-crush, build-dependencies unsatisfiable on armel

[Thomas Calderon]

OK, let's have them removed, when I will push an updated version, I will
make sure to remove armel from the list of targets.

Do I need to do anything else for now?

Thanks,

Thomas

On Thu, Jun 13, 2019 at 8:02 PM Peter Green 
wrote:

> On 13/06/19 10:00, Thomas Calderon wrote:
> > Hi there,
> >
> > It's unfortunate that OCaml has removed the support for ocamlopt for
> armel, it sounds like CamlCrush will not be able to ship for armel.
> > Is it required that I create an updated Debian release excluding armel
> as a target or as you said, ftpmaster can just remove the binaries?
> Removing the binaries is enough in cases like this, they won't be rebuilt
> until/unless their build-dependencies become available again.
>
> I'm not sure if the binary removal will propagate automatically from
> unstable to testing during the freeze or if one needs to ask the release
> team for that.
>
>

Bug#929450: caml-crush, build-dependencies unsatisfiable on armel

[Thomas Calderon]

Hi there,

It's unfortunate that OCaml has removed the support for ocamlopt for armel,
it sounds like CamlCrush will not be able to ship for armel.
Is it required that I create an updated Debian release excluding armel as a
target or as you said, ftpmaster can just remove the binaries?
I would have thought that I have to specifically exclude it in the
Architecture field?

Thanks,

Thomas

On Thu, May 23, 2019 at 7:15 PM plugwash 
wrote:

> package: caml-crush
> tags: buster,sid
> severity: serious
> x-debbugs-cc: debian-ocaml-ma...@lists.debian.org
>
> caml-crush build-depends on ocaml-native-compilers. In stretch this was
> a real package. In buster it is a virtual package provided by ocaml-base
> on most architectures, but does not seem to exist at all on armel. In
> the ocaml changelog I see "drop support for ocamlopt on armel as
> suggested by upstream" which I suspect reflects this change.
>
> If this package can be reasonablly made to work without
> ocaml-native-compilers on armel then you should do so, if you belive it
> is not reasonable to support this package on armel please
> reassign/retitle this to ftpmaster so they can remove the armel binaries.
>

Bug#828256: caml-crush: FTBFS with openssl 1.1.0

[Thomas Calderon]

Hello Kurt,

We have released Caml Crush version 1.0.8 to address this issue.
I have uploaded the new package to mentors.debian.net and will ask my
sponsor to review and push it forward.

Best regards,

Thomas Calderon

On Sun, Jun 26, 2016 at 11:21 AM, Kurt Roeckx <k...@roeckx.be> wrote:

> Source: caml-crush
> Version: 1.0.7-1
> Severity: important
> Control: block 827061 by -1
>
> Hi,
>
> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> OpenSSL this package fail to build.  A log of that build can be found at:
>
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/caml-crush_1.0.7-1_amd64-20160529-1409
>
> On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various
> of the
> reasons why it might fail.  There are also updated man pages at
> https://www.openssl.org/docs/manmaster/ that should contain useful
> information.
>
> There is a libssl-dev package available in experimental that contains a
> recent
> snapshot, I suggest you try building against that to see if everything
> works.
>
> If you have problems making things work, feel free to contact us.
>
>
> Kurt
>

Bug#810703: caml-crush-server: unowned directory after purge: /var/lib/pkcs11proxyd/

[Thomas Calderon]

Hi Andreas,

OK thanks for clarifying.
Yes that is the home directory of the user created for the daemon.

I will then reassign the bug to piuparts,

Cheers,

Thomas

On Mon, Jan 11, 2016 at 3:16 PM, Andreas Beckmann <a...@debian.org> wrote:

> On 2016-01-11 16:02, Thomas Calderon wrote:
> > Hi Andreas,
> >
> > Thanks for the bug report.
> >
> > It is not clear to me what is causing the issue as there is no postrm
> > action/file in the caml-crush-server package that remove files or the
> > dedicated user/group.
> > Hence, I don't understand how piuparts can trigger this error.
> >
> > When manually calling "dpkg -P caml-crush-server", the
> > /var/lib/pkcs11proxyd directory stays owned by the users created at
> > post-install on my machine.
> >
> > Could it be an artifact or am I missing something from the log you sent?
>
> This is not about user/group ownership of the directory but about the
> package ownership (not) known to dpkg. Since that is created in
> postinst, dpkg does not know anything about it, and piuparts sorts it
> into the "unowned leftovers" category.
>
> Is that the home directory of the user running that service? In that
> case we could add it to a ignore list in piuparts. Please reassign the
> bug if we should do so.
>
>
> Andreas
>

Bug#810703: caml-crush-server: unowned directory after purge: /var/lib/pkcs11proxyd/

[Thomas Calderon]

Hi Andreas,

Thanks for the bug report.

It is not clear to me what is causing the issue as there is no postrm
action/file in the caml-crush-server package that remove files or the
dedicated user/group.
Hence, I don't understand how piuparts can trigger this error.

When manually calling "dpkg -P caml-crush-server", the
/var/lib/pkcs11proxyd directory stays owned by the users created at
post-install on my machine.

Could it be an artifact or am I missing something from the log you sent?

Cheers,

Thomas

On Mon, Jan 11, 2016 at 11:49 AM, Andreas Beckmann  wrote:

> Package: caml-crush-server
> Version: 1.0.7-1
> Severity: important
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package left unowned
> directories on the system after purge, which is a violation of
> policy 6.8:
>
>
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails
>
> Filing this as important as having a piuparts clean archive is a release
> goal since lenny.
>
> The maintainer scripts create (and later remove) a file in that
> directory. Manual directory removal may be not appropriate as this
> directory is shared between several packages.
>
> If the package would ship this as an empty directory, dpkg would take
> care of the creation and removal (if it's empty).
>
> >From the attached log (scroll to the bottom...):
>
> 0m39.4s ERROR: FAIL: Package purging left files on system:
>   /var/lib/pkcs11proxyd/ not owned
>
>
> cheers,
>
> Andreas
>

Bug#804327: caml-crush: FTBFS: OCaml package ssl not found

[Thomas Calderon]

Just to let you know that a new release was made and the package is now up
on http://mentors.debian.net/package/caml-crush.

Cheers,

Thomas

On Mon, Nov 9, 2015 at 8:37 PM, Thomas Calderon <calderon.tho...@gmail.com>
wrote:

> Hello,
>
> This issue was tracked down and is linked to the following:
>   - Source package had no direct dependency on
> libocaml-ssl/libocaml-ssl-net which was pulled by Ocamlnet
>   - OCamlnet was bumped to 4.x in Sid, switching to GnuTLS which breaks
> their TLS API and do not require Ocaml-ssl any longer
>
> Anyway the upstream Caml Crush is being worked on to support both older
> and newer 4.x Ocamlnet and a release should be made this week.
> Once this is done, I will push an updated Debian package.
>
> Cheers,
>
> Thomas
>
>
> On Sun, Nov 8, 2015 at 9:43 PM, Kurt Roeckx <k...@roeckx.be> wrote:
>
>> On Sun, Nov 08, 2015 at 09:33:03PM +, Thomas Calderon wrote:
>> > Hello Kurt,
>> >
>> > Do you know if the ocaml SSL library has changed or been removed has a
>> > consequence of your cleanup?
>> > That could explain why the configure script does not find it any longer.
>>
>> I'm not sure what the ocaml ssl package is.  From the brief look
>> at the configure script it looked the support multiple things, but
>> I have no idea what it's really searching for.
>>
>> But I couldn't find any reference to the SSLv3_* functions in your
>> package, so it might not be related to my change.
>>
>>
>> Kurt
>>
>>
>

Bug#804327: caml-crush: FTBFS: OCaml package ssl not found

[Thomas Calderon]

Hello,

This issue was tracked down and is linked to the following:
  - Source package had no direct dependency on
libocaml-ssl/libocaml-ssl-net which was pulled by Ocamlnet
  - OCamlnet was bumped to 4.x in Sid, switching to GnuTLS which breaks
their TLS API and do not require Ocaml-ssl any longer

Anyway the upstream Caml Crush is being worked on to support both older and
newer 4.x Ocamlnet and a release should be made this week.
Once this is done, I will push an updated Debian package.

Cheers,

Thomas


On Sun, Nov 8, 2015 at 9:43 PM, Kurt Roeckx <k...@roeckx.be> wrote:

> On Sun, Nov 08, 2015 at 09:33:03PM +0000, Thomas Calderon wrote:
> > Hello Kurt,
> >
> > Do you know if the ocaml SSL library has changed or been removed has a
> > consequence of your cleanup?
> > That could explain why the configure script does not find it any longer.
>
> I'm not sure what the ocaml ssl package is.  From the brief look
> at the configure script it looked the support multiple things, but
> I have no idea what it's really searching for.
>
> But I couldn't find any reference to the SSLv3_* functions in your
> package, so it might not be related to my change.
>
>
> Kurt
>
>

Bug#804327: caml-crush: FTBFS: OCaml package ssl not found

[Thomas Calderon]

Hello Kurt,

Do you know if the ocaml SSL library has changed or been removed has a
consequence of your cleanup?
That could explain why the configure script does not find it any longer.

In any case I will look into that this week.

Cheers,

Thomas
On 7 Nov 2015 12:33, "Kurt Roeckx"  wrote:

> Source: caml-crush
> Version: 1.0.6-1
> Severity: serious
> Control: block 797926 by -1
>
> Hi,
>
> Your package is failing to build with the following error:
> configure:4778: Using OCaml RPC over ssl for server side ...
> configure:4782: checking OCaml package ssl
> configure:4789: error: not found
>
>
>
> Kurt
>

Bug#770449: ITP, RFS for Caml Crush package

[Thomas Calderon]

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

[Thomas Calderon]

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

[Thomas Calderon]

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: RFS: caml-crush/1.0.3-1 [ITP]

[Thomas Calderon]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package caml-crush

* Package name: caml-crush
  Version : 1.0.3-1
  Upstream Author : Ryad Benadjila, Thomas Calderon, Marion Daubignard
* URL : https://github.com/ANSSI-FR/caml-crush
* License : CeCILL-B
  Section : net

It builds those binary packages:

  caml-crush-clients - Caml Crush: an OCaml PKCS#11 filtering proxy -
clients
  caml-crush-server - Caml Crush: an OCaml PKCS#11 filtering proxy - server

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/caml-crush


Alternatively, one can download the package with dget using this command:

  dget -x
http://mentors.debian.net/debian/pool/main/c/caml-crush/caml-crush_1.0.3-1.dsc

More information about hello can be obtained from
https://github.com/ANSSI-FR/caml-crush.



Regards,

Thomas Calderon

Bug#770296: ITP: caml-crush -- Caml Crush: an OCaml PKCS#11 filtering proxy

[Thomas Calderon]

Package: wnpp
Owner: Thomas Calderon calderon.tho...@gmail.com
Severity: wishlist

* Package name: caml-crush
  Version : 1.0.3
  Upstream Author : Ryad Benadjila, Thomas Calderon, Marion Daubignard
* URL : https://github.com/ANSSI-FR/caml-crush
* License : CeCILL-B
  Programming Lang: OCaml, C
  Description : Caml Crush: an OCaml PKCS#11 filtering proxy

This software is a computer program whose purpose is to implement a PKCS#11
proxy as well as a PKCS#11 filter with security features in mind. For
instance, the filtering engine allows to:
  * dynamically block PKCS#11 attacks
  * disable PKCS#11 functions and weak mechanisms
  * perform object filtering on a resource
  * force read-only use of the cryptographic resource