Bug#784050: RFA: ocaml-deriving -- deriving functions from type declarations in OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: normal

Hello,

Currently, ocaml-deriving has no human maintainers. It is maintained by
the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502141044.20046.95016.report...@zetta.zrh.le-gall.net

Bug#784042: RFA: ocaml-data-notation -- Store data using OCaml notation

[Sylvain Le Gall]

Package: wnpp
Severity: normal

Hello,

Currently, ocaml-data-notation has no human maintainers. It is maintained by the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502124739.16844.39340.report...@zetta.zrh.le-gall.net

Bug#784039: RFA: ocaml-gettext -- OCaml internationalization library

[Sylvain Le Gall]

Package: wnpp
Severity: normal

Hello,

Currently, ocaml-gettext has no human maintainers. It is maintained by the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502124348.15304.36016.report...@zetta.zrh.le-gall.net

Bug#784037: RFA: ocaml-inotify -- OCaml bindings for the inotify API

[Sylvain Le Gall]

Package: wnpp
Severity: normal

Hello,

Currently, ocaml-inotify has no human maintainers. It is maintained by the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502124052.14785.74570.report...@zetta.zrh.le-gall.net

Bug#784036: RFA: ocamlgsl -- GNU scientific library for OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: normal

Hello,

Currently, ocamlgsl has no human maintainers. It is maintained by the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502123931.14516.70112.report...@zetta.zrh.le-gall.net

Bug#784035: RFA: ocamlify -- include files in OCaml code

[Sylvain Le Gall]

Package: wnpp
Severity: normal

Hello,

Currently, ocamlify has no human maintainers. It is maintained by the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502123813.14178.93456.report...@zetta.zrh.le-gall.net

Bug#784033: RFA: gmetadom -- GDome2 DOM implementation

[Sylvain Le Gall]

Package: wnpp
Severity: normal

Hello,

Currently, gmetadom has no human maintainers. It is maintained by the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502123451.13492.79443.report...@zetta.zrh.le-gall.net

Bug#784034: RFA: ocamlmod -- generate OCaml modules from source files

[Sylvain Le Gall]

Package: wnpp
Severity: normal

Hello,

Currently, ocamlmod has no human maintainers. It is maintained by the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502123626.13836.10462.report...@zetta.zrh.le-gall.net

Bug#784032: RFA: xstr -- OCaml library for frequent string operations

[Sylvain Le Gall]

Package: wnpp
Severity: normal

Hello,

Currently, xstr has no human maintainers. It is maintained by the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502123247.12956.98455.report...@zetta.zrh.le-gall.net

Bug#784031: RFA: camltemplate -- library for generating text from templates

[Sylvain Le Gall]

Package: wnpp
Severity: normal

Hello,

Currently, camltemplate has no human maintainers. It is maintained by the
Debian OCaml team because of the need of transition coordination, but
needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502122550.11366.46484.report...@zetta.zrh.le-gall.net

Re: RFC ounit 2.0.0, ocaml-expect 0.0.5, oasis 0.4.2

[Sylvain Le Gall]

Anyone can have a look at this?

Thanks
Sylvain

On 06-03-2014, Sylvain Le Gall  wrote:
> Hi all,
>
> I just pushed to git the latest version of ounit/ocaml-expect and oasis.
> Can any Debian OCaml Maintainer, who should be less rusty than me, have
> a look at this commit and tell me if it is ok to proceed with the
> upload.
>
> http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/ounit.git
> http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/ocaml-expect.git
> http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/oasis.git
>
> Thanks,
> Sylvain Le Gall
> -- 
> Website:  http://sylvain.le-gall.net/
>
>

Cheers,
Sylvain Le Gall
-- 
Website:  http://sylvain.le-gall.net/


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnli1mhg.2rq.gil...@le-gall.net

RFC ounit 2.0.0, ocaml-expect 0.0.5, oasis 0.4.2

[Sylvain Le Gall]

Hi all,

I just pushed to git the latest version of ounit/ocaml-expect and oasis.
Can any Debian OCaml Maintainer, who should be less rusty than me, have
a look at this commit and tell me if it is ok to proceed with the
upload.

http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/ounit.git
http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/ocaml-expect.git
http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/oasis.git

Thanks,
Sylvain Le Gall
-- 
Website:  http://sylvain.le-gall.net/


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnlhfgoi.dsa.gil...@le-gall.net

Re: Please review: ocamlmod 0.0.4

[Sylvain Le Gall]

On 26-06-2013, Hendrik Tews  wrote:
> Sylvain Le Gall  writes:
>
>>
>> - update man page (option -o, a single module file_)
>>
>
>Not sure to understand that.
>
> ocamlmod -help describes option -o, which is missing in the man
> page.
>
> Additionally, the man page says "a single module files", which
> should be "a single module file".
>
>>   + fix hyphen-used-as-minus-sign
>
> this is the lintian tag, see
> http://lintian.debian.org/tags/hyphen-used-as-minus-sign.html
>
> What I don't understand about this tag is that lintian reports it
> for pandoc generated man pages but not for my handwritten ones.
>
> BTW, I am glad you (seem to have) changed your mind and left your
> name in Uploaders!
>

Unfortunately, I didn't really change my mind. This is one of the last
upload I do -- and I need to have a human uploaders in this field. After
the upload I should remove it and let someone else pick it up. However,
I am thinking about setting myself as DM to still be able to help on
particular topics.

But you know, my retirement is more about honesty wrt to all the OCaml
packages maintainers than because I want to leave. Staying in the group
and thinking that I can do actual work would be a lie and I don't want
to prevent other people to do a good job.

Cheers,
Sylvain Le Gall
-- 
Website:  http://sylvain.le-gall.net/


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnkslg8s.rfh.gil...@le-gall.net

Re: Please review: ocamlmod 0.0.4

[Sylvain Le Gall]

On 25-06-2013, Hendrik Tews  wrote:
> Hi,
>
> I don't know the standard, but I would
>
> - use debhelper compat level 9
>

Done

> - delete the cleaner line in gbp.conf
>

Done

> - enable the tests (-configure --enable-tests)
>

They will fail, I need to fix them (although this is just a very minor
problem).

> - enable native compilation
>

This is not the default upstream. I keep a TODO for the next version.

> - not call ocamlc setup -doc

Done

>
> - update man page (option -o, a single module file_)
>

Not sure to understand that.

> - fix most of the lintian warnings:
>   + fix Vcs fields

Done

>   + update the copyright file

Done

>   + add a watch file

Done

>   + remove empty /usr/lib/OCaml

Done.

>   + fix hyphen-used-as-minus-sign

Don't understand this one.

>   + fix allows to in man page

Done.

>
> For many of these points you can just copy from ocaml-fileutils.
>
> Bye,
>
> Hendrik
>
>

Cheers,
Sylvain Le Gall
-- 
Website:  http://sylvain.le-gall.net/


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnksk9ok.rfh.gil...@le-gall.net

Re: Please review: ocamlmod 0.0.4

[Sylvain Le Gall]

On 25-06-2013, Hendrik Tews  wrote:
> Hi,
>
> I don't know the standard, but I would
>
> - use debhelper compat level 9
>
> - delete the cleaner line in gbp.conf
>
> - enable the tests (-configure --enable-tests)
>
> - enable native compilation
>
> - not call ocamlc setup -doc
>
> - update man page (option -o, a single module file_)
>
> - fix most of the lintian warnings:
>   + fix Vcs fields
>   + update the copyright file
>   + add a watch file
>   + remove empty /usr/lib/OCaml
>   + fix hyphen-used-as-minus-sign
>   + fix allows to in man page
>

How do I get this warnings ?

Running on my system:
$ lintian ../ocamlmod_0.0.4-1.dsc

Gives me no warning at all

$ lintian --version
Lintian v2.5.13

> For many of these points you can just copy from ocaml-fileutils.
>
> Bye,
>
> Hendrik
>
>

Cheers,
Sylvain Le Gall
-- 
Website:  http://sylvain.le-gall.net/


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnksk813.rfh.gil...@le-gall.net

Please review: ocamlify 0.0.2

[Sylvain Le Gall]

Same reason as for ocamlmod 0.0.4, if someone can review the package
before for upload.

As an upstream, I did a fresh release so that we won't have any problem
with OCaml 4 migration wrt setup.ml and Scanf bug.

Cheers,
Sylvain Le Gall
-- 
Website:  http://sylvain.le-gall.net/


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnksk5np.rfh.gil...@le-gall.net

Please review: ocamlmod 0.0.4

[Sylvain Le Gall]

Since I didn't do any packaging for a long time, I would like that
someone review my latest commit to ocamlmod packages.

This is a one liner in term of code (I have just injected the orig
tarball and updated the changelog entry), but maybe can see if it meets
the latest OCaml packaging standards.

Thanks in advance,
Sylvain Le Gall
-- 
Website:  http://sylvain.le-gall.net/


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnksk349.rfh.gil...@le-gall.net

Bug#711452: liboasis-ocaml: Needs to depend on ocamlbuild in the META file.

[Sylvain Le Gall]

Package: liboasis-ocaml
Version: 0.3.0-1
Severity: normal
Tags: patch

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
$ oasis setup -setup-update dynamic
$ make
ocaml setup.ml -build
File "setup.ml", line 1, characters 0-1:
Error: Reference to undefined global `Ocamlbuild_plugin'
make: *** [build] Erreur 2

There is a missing dependency on ocamlbuild in the META file. The bug
will be fixed upstream as well.

The patch attached fix the bug.

Regards
Sylvain 

*** End of the template - remove these lines ***


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages liboasis-ocaml depends on:
ii  libc6  2.17-5
ii  libfindlib-ocaml [libfindlib-ocaml-8p7u5]  1.3.1-1
ii  libodn-ocaml [libodn-ocaml-9gxf8]  0.0.8-1
ii  ocaml-base-nox [ocaml-base-nox-3.12.1] 3.12.1-4

liboasis-ocaml recommends no packages.

Versions of packages liboasis-ocaml suggests:
pn  liboasis-ocaml-doc  

-- no debconf information
diff --git a/src/oasis/META b/src/oasis/META
index 88e7165..903ea3a 100644
--- a/src/oasis/META
+++ b/src/oasis/META
@@ -20,7 +20,7 @@
 
 
 # OASIS_START
-# DO NOT EDIT (digest: d471c9d7d5a1ce73f9fe3fdfbd92627e)
+# DO NOT EDIT (digest: b0f33f22f3fba881e821ce61ae4d4b8b)
 version = "0.3.1"
 description = "_oasis file functions"
 requires = "unix odn"
@@ -52,7 +52,7 @@ package "cli" (
 package "builtin-plugins" (
  version = "0.3.1"
  description = "_oasis file functions"
- requires = "oasis oasis.base"
+ requires = "oasis oasis.base ocamlbuild"
  archive(byte) = "builtin-plugins.cma"
  archive(byte, plugin) = "builtin-plugins.cma"
  archive(native) = "builtin-plugins.cmxa"

Bug#711451: oasis: Depends on liboasis-ocaml-dev to enable dynamic mode.

[Sylvain Le Gall]

Package: oasis
Version: 0.3.0-1
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

Setting up a project with:
$> apt-get install oasis
$> oasis setup -setup-update dynamic
$> make
ocaml setup.ml -build
File "setup.ml", line 7, characters 0-16:
Error: Unbound module OASISDynRun
make: *** [build] Erreur 2

Solution:
$> apt-get install liboasis-ocaml-dev

Turns out that setup.ml is a toplevel script and that in order to use
OASISDynRun, you need OASISDynRun.cmi.

You can solve the problem by depending on liboasis-ocaml-dev or by
moving the *.cmi of the -dev package to liboasis-ocaml.

Regards
Sylvain

*** End of the template - remove these lines ***


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages oasis depends on:
ii  libfindlib-ocaml [libfindlib-ocaml-8p7u5]  1.3.1-1
ii  liboasis-ocaml [liboasis-ocaml-iw5j4]  0.3.0-1
ii  libodn-ocaml [libodn-ocaml-9gxf8]  0.0.8-1
ii  ocaml-base-nox [ocaml-base-nox-3.12.1] 3.12.1-4

oasis recommends no packages.

Versions of packages oasis suggests:
pn  liboasis-ocaml-doc  

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130606223038.28073.53897.report...@zetta.zrh.le-gall.net

Re: ocaml-dangling-cmi for ocamlify generated files

[Sylvain Le Gall]

2013/5/29 Hendrik Tews :
> Hi,
>
> oasis 0.3 src/oasis/OASISData.mlify from which ocamlify generates
> a .ml, which is then compiled. When installing OASISData.cmi in
> the -dev package lintian reports a ocaml-dangling-cmi. The
> trouble is that there is no .mli available or generated and the
> generated .ml file is not readable.
>
> In order to deal with this warning, I would ask upstream to
> supply a .mli file, either by writing it manually or by enhancing
> ocamlify to generate it. One could of course also ignore or
> override this tag for generated .ml files.

That is a good point, I never thought about (as an upstream of oasis
and ocamlify).

So here you have an immediate solution to fix the problem:
- run "ocamlbuild src/oasis/OASISData.inferred.mli" after building the
project (ocaml setup.ml -build)
- copy _build/src/oasis/OASISData.inferred.mli to src/oasis/OASISData.mli

This way you fix the problem of the lintian report, without any
upstream release.

To solve the problem on a longer term,  there are two solutions:

1. ocamlify should take as an input file OASISData.mli, with this content:

var oasissys_ml: string (* source "OASISSys.ml" *)
var oasissyslight_ml: string (* source "OASISSysLight.ml" *)
...

2. ocamlify generate the .mli and oasis look for the .mli or
.inferred.mli in _build

2. is probably easier to implement but less readable than 1.

Cheers
Sylvain


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOCAUGPrhWWjcBcDUpt8G7axX8b=czuL-AFJoW-ZcgojD=q...@mail.gmail.com

Re: [OASIS-devel] updated oasis

[Sylvain Le Gall]

2013/5/29 Hendrik Tews :
> Hi,
>
> I imported a new upstream version of oasis and fixed several
> points in the package.
>

I was planning to do it, but I am glad to see you pick the job.

> I had to omit the library builtin-plugins.cma from the packaging
> because of a peculiar dh_ocaml error. builtin-plugins.cma is
> built via
>
>  ocamlfind ocamlc -a -I +ocamlbuild ocamlbuildlib.cma ... -o 
> src/builtin-plugins.cma
>
> It therefore includes a copy of ocamlbuildlib.cma and dh_ocaml
> says
>
> E: Error: unit Ocamlbuild_plugin exported in 
> liboasis-ocaml-dev/liboasis-ocaml v0.3.0-1 but already exported by 
> ocaml-nox/ocaml-base-nox v3.12.1-4
> E: Error running /usr/bin/ocaml-md5sums  --md5sums-dir 
> debian/liboasis-ocaml-dev//var/lib/ocaml/md5sums --load-info 
> debian/liboasis-ocaml-dev.oinfo.debhelper dep at /usr/bin/dh_ocaml line 462.
>
>
> I believe the inclusion of ocamlbuildlib.cma is an error in the
> oasis build procedure. Note that builtin-plugins.cmxs is build
> without a copy of ocamlbuildlib and is therefore included in the
> package.
>

True, the error was on line 212 in _tags. This is fixed.

I have pushed every fix to my repository on github:
https://github.com/gildor478/oasis/commits/master

Thanks for the report.

Cheers
Sylvain


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOCAUGNTm=gqoqbkmbrd8qbrn0mbe4yt__sptwmtnrtnng9...@mail.gmail.com

Time to retire?

[Sylvain Le Gall]

Hi fellows Ocaml package maintainers,

Writing this email is not really easy for me. Over the past couple of
years, I wished to devote more time to Debian and my OSS activities. I
must acknowledge that this is beyond what I can do.

So rather than continue to lie and send false signals that I will resume
my Debian activities, it is maybe time to retire.

Tonight, I'll remove myself from the few packages I am still an
uploader.

I'll send the corresponding email to officialy retire in a couple of
days.

I will maybe provide a little help for packaging (as I continue to
maintain some packages on my own server), but you should consider me as
retired. If I can keep my account on alioth, I'll maybe do a few commit
directly, ping me if you think this is not ok.

Thanks to everyone for the great OCaml packages and the years of fun
doing it together.

Cheers,
Sylvain Le Gall
--
Website:  http://sylvain.le-gall.net/


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnkq6t29.905.gil...@le-gall.net

Re: OCaml transition plans

[Sylvain Le Gall]

On 08-05-2013, Lifeng Sun  wrote:
>
>
> * packages with latest version compatible with ocaml-3.12
>
 package latest ver
 ocaml-expect   0.0.3
 ocamlmod   0.0.3
 ocaml-csv  1.2.6
 ocaml-fileutils0.4.4
 oasis  0.3.0
 ounit  1.1.2


Will take care of these one.

> * packages with latest version requires ocaml >=3D 4.00.0
>
> package   latest verbuild-dep
 ocaml-data-notation0.0.10   type-conv >=3D 108.07.01

Will take care of this one as well.

>
>
> * packages without new upstream release
>
> camlbz2, ocamlify
>

There was probably an update of ocamlify in between, if not I'll do it
in due time.

Cheers,
Sylvain Le Gall
--
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnkolb7h.57k.gil...@gallu.homelinux.org

Re: OCaml transition plans

[Sylvain Le Gall]

On 08-05-2013, Stéphane Glondu  wrote:
> Hello,
>
>
> [1] https://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransition

The page is 404.

Cheers,
Sylvain Le Gall
--
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnkolb2q.57k.gil...@gallu.homelinux.org

Re: Orphaning some of my packages

[Sylvain Le Gall]

Hi,

2012/9/21 Hendrik Tews :
> Sylvain Le Gall  writes:
>
>Here is the list of packages that have no other uploaders
>after this operation:
>
>* ocamlp3l
>
> I can find camlp3l and ocamlp3l, but no Debian package of that
> name. Where is this?

In the git repository only, I suppose. I just went through my "git
checkout"ed packages, so maybe it has never been released.

>
> Sylvain, for the orphaned packages, could you comment on which
> are actively maintained upstream?
>
>

This is only IMHO, as a matter of fact an OCaml package that has not
been updated for years doesn't mean it is orphaned upstream:

Active upstream with releases:
* camomile
* ocaml-extunix
* ocaml-sqlexpr
* ounit
* sexplib310
* uuidm

Active upstream without many releases:
* ocaml-benchmark
* atdgen
* biniou
* caml2html
* camlmix
* cppo
* easy-format
* mikmatch
* ocaml-atd
* ocamlgsl

Inactive or MIA upstream:
* ocaml-deriving
* ocaml-dbus
* ocaml-inifiles
* ocaml-inotify
* tophide
* xstr
* xstrp4
* yojson

* ocamlp3l

Don't know:
* gmetadom

>* sexplib310
>
> Sexplib and typeconf has been included into Jane Streets Core. Am
> I right in assuming that the next janest-core packge will provide
> sexplib310 and type-conf?
>

It remains separate packages. Jane Street provides (AFAIK), either a
big archive containing all its libraries or a set of smaller archives
(type-conv, binprot, sexplib, core...). Also, since they all have
adopted the same numbering scheme (108.01), you can choose to migrate
to the whole archive.

>
> To judge the importance of the orphaned packages, I made the
> following table:
>
> Popcon  Squeeze?  reverse dep
>
> atdgen   9
> biniou  27  atdgen yojson
> caml2html6  easy-format biniou ocaml-atd yojson atdgen
> camlmix  1  caml2html easy-format biniou ocaml-atd 
> yojson atdgen
> camomile   413 yes  ocaml-batteries
> cppo 5
> easy-format  1  biniou OCaml-atd yojson atdgen
> gmetadom 14410 yes  lablgtkmathview
> mikmatch 5
> ocaml-atd9
> ocaml-benchmark 17 yes
> ocaml-dbus  36 yes
> ocaml-deriving   4
> ocaml-extunix   11
> ocamlgsl66 yes  orpie
> ocaml-inifiles   7
> ocaml-inotify   18 yes
> ocaml-sqlexpr5
> ounit  225 yes  cudf ocaml-expect ocaml-extunix 
> ocaml-reins
> sexplib310  58 yes  occinelle
> tophide  5
> uuidm   24 yes
> xstr70 yes
> xstrp4   3
> yojson  26  atdgen
>
>
> Many of these packages have a rather low popcon count, but many
> of them are not in Squeeze, so their popularity might rise after
> the release.

Popcon count for OCaml packages, in general, is quite low. OCaml
libraries remain in the long tail of package installed. I think this
is related to the "static compilation" scheme of OCaml. Since you
don't need to install a library along the program that uses it, you
only count "dev machine" that will install your package. And OCaml
Debian computer used for development around the world is probably a
small percent of Debian computer using the libraries. Although, this
is only my take on this.

>
> In the above list, only sexplib310, camomile, gmetadom and
> ocamlgsl have reverse dependencies not in the list. That is only
> removing sexplib310, camomile, gmetadom or ocamlgsl will affect
> packages not in this list.
>
> Depending on time I probably have a look at one or the other
> package.
>

Thx for the analysis.
Sylvain


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOCAUGNMmB3T-GLvTgp76Z7nPpzp1WfC4GOVpFsVWcsit8=s...@mail.gmail.com

Orphaning some of my packages

[Sylvain Le Gall]

Hi,

It is not a big news that I am a lot less involved in Debian. I wish
to focus on OASIS a lot more and in order to do that I need to give up
on certain tasks. I remove myself as an uploader from most of my
packages. Here is the list of packages that have no other uploaders
after this operation:

* atdgen
* biniou
* caml2html
* camlmix
* camomile
* cppo
* easy-format
* gmetadom
* mikmatch
* ocaml-atd
* ocaml-benchmark
* ocaml-dbus
* ocaml-deriving
* ocaml-extunix
* ocamlgsl
* ocaml-inifiles
* ocaml-inotify
* ocamlp3l
* ocaml-sqlexpr
* ounit
* sexplib310
* tophide
* uuidm
* xstr
* xstrp4
* yojson

I am still an active Debian user of these packages, but don't have
enough time to maintain the Debian packaging seriously. If you think
that some of these packages are not useful, just ask for their removal
of the archive, but maybe keep their git repository.

I will only continue to spend my packaging time on the following packages:
* oasis
* ocamlmod
* ocamlify
* ocaml-gettext
* ocaml-fileutils
* ocaml-data-notation

If I ever wanted to create new packages, I'll submit an RFP and will
probably provide a git repository for it with initial packaging done
(like ocamlrss). But I will not upload it, so that the Debian OCaml
packaging team will not have an extra burden.

I have removed my name from most of the packages, but won't upload
them until the freeze is over.

Please CC me, I don't read frequently debian-ocaml-maint@l.d.o.

Cheers
Sylvain


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caocaugpjjw0dhkvx0mfrm2ae0a96jmda0caga0sbqozrvsw...@mail.gmail.com

Re: oasis 0.3.0, tonight (GMT)

[Sylvain Le Gall]

On 28-06-2012, Mehdi Dogguy  wrote:
> On 28/06/12 15:19, Sylvain Le Gall wrote:
>>
>> oasis 0.2 is quite old and has one important bug that will prevent
>> any setup.ml generated with it to compile with OCaml 4.00.
>
> Good thing that Wheezy doesn't have OCaml 4.00.x. Whatever will bring
> OCaml 4.00.x to Wheezy users can also bring oasis 3.0.
>

Seems you make your choice, so. I'll need your help tonight for a couple
of package review (oasis 0.2.0-X+1 with Scanf patch ~1line, oasis
0.3.0-1 and ocamlmod).

Will you be available ? Do we plan a meeting at a certain time tonight ?

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjuoog9.drt.gil...@gallu.homelinux.org

Re: oasis 0.3.0, tonight (GMT)

[Sylvain Le Gall]

Hello,

On 28-06-2012, Mehdi Dogguy  wrote:
> On 28/06/12 13:23, Sylvain Le Gall wrote:
>>
>> Does anybody have reasons to veto a new upstream so close to the
>> freeze?
>>
>
> I do wonder if doing this race is really a serious thing to do…
>
> Sid's oasis doesn't look broken and has been tested/used by our users.
> Putting a new upstream release in sid so close to the freeze doesn't
> sound a great idea to me, IMHO. To serve stable users interests, you may
> upload oasis 3.0 in sid once Wheezy released and then upload it in
> backports so that stable users can install it. For now, putting oasis
> 3.0 in experimental seems to be our best option. IMHO, being a leaf
> package doesn't justify an upload to sid.
>

oasis 0.2 is quite old and has one important bug that will prevent any
setup.ml generated with it to compile with OCaml 4.00. Although, I won't
argue on the short notice. If you feel more comfortable with an old
version of oasis, it is ok for me. I just think it will be "almost"
useless for any dev done with Wheezy, targetting OCaml 3.12 and 4.00. 

So here 2 options:
1. upload 0.3 to experimental and patch the OCaml 4.00 bug in oasis 0.2
2. take the risk of oasis 0.3 in sid (mitigated, it is not like we have
   thousands of critical users or possible security bugs or rev-deps).

I'll propose you a package tonight and you'll just have to pick the best
option for you. 

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjuomek.drt.gil...@gallu.homelinux.org

oasis 0.3.0, tonight (GMT)

[Sylvain Le Gall]

Hi all,

I plan to release oasis 0.3.0 tonight. Since we are ultra-close to the
freeze (and that my Debian packaging skills needs to be upgraded), is it
possible to get a quick review of my packaging when I will be done
tonight?

Does anybody have reasons to veto a new upstream so close to the freeze?

oasis should have not rev-deps so it won't create problems all around.

I am also planning upgrades of the package requirement (hence
ocamlmod/ocamlify which has no other reverse deps has well).

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjuofkv.drt.gil...@gallu.homelinux.org

Bug#670474: libpgocaml-ocaml-dev: Conflicts between extlib and camomile about UChar

[Sylvain Le Gall]

Hi,

2012/4/27 Mehdi Dogguy 

> On 04/26/2012 02:07 AM, Sylvain Le Gall wrote:
> >
> > extlib and camomile both exports UChar and doesn't agree on this
> > interface. This prevents to use pgocaml with any packages that uses
> > batteries (e.g. sqlexpr).
> >
>
> FWIW, I don't think building pgocaml with Batteries instead of extlib is
> the right fix for this issue ; this does only move the problem elsewhere
> (as you said in your report). So I'd rather leave this bugreport open
> for now.
>
> If both libraries export a same module name but with different
> signature/implementation, such clashes are expected. That's how OCaml is
> designed. You can either re-assign this bug to both extlib *and*
> camomille and have both upstream agree on a different module name than
> UChar (or rename it in only one of the libraries)… or reassign to OCaml.
> I guess the former is easier to fix than the latter :)
>

I submitted the bug upstream:
http://code.google.com/p/ocaml-extlib/issues/detail?id=23

Though, since pgocaml 1.5 offers the possibility to switch, it is possible
to switch... That is the reason why this bug is about pgocaml rather than
extlib.

Regards
Sylvain Le Gall

Bug#670474: libpgocaml-ocaml-dev: Conflicts between extlib and camomile about UChar

[Sylvain Le Gall]

Package: libpgocaml-ocaml-dev
Version: 1.4-2+b1
Severity: important

Dear Maintainer,

extlib and camomile both exports UChar and doesn't agree on this
interface. This prevents to use pgocaml with any packages that uses
batteries (e.g. sqlexpr).

Step to reproduce the bug:
$ ocaml
#use "topfind";;
#thread;;
#require "pgocaml";;
#require "sqlexpr";;
The files /usr/lib/ocaml/camomile/camomile.cma
and /usr/lib/ocaml/extlib/extLib.cma
disagree over interface UChar

It seems possible to build pgocaml using batteries, starting with
version 1.5. It will solve this conflict, but the conflict betweens
extlib and camomile will remain.

Cheers
Sylvain Le Gall

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libpgocaml-ocaml-dev depends on:
ii  camlp4 [camlp4-3.12.1]   3.12.1-2
ii  libc62.13-30
ii  libcalendar-ocaml-dev [libcalendar-ocaml-dev-pm5s8]  2.03-1+b2
ii  libcsv-ocaml-dev [libcsv-ocaml-dev-dk5h1]1.2.2-1+b1
ii  libextlib-ocaml-dev [libextlib-ocaml-dev-jshx0]  1.5.2-1+b1
ii  libpcre-ocaml-dev [libpcre-ocaml-dev-xu8a5]  6.2.5-1
ii  libpcre3 1:8.30-4
ii  libpgocaml-ocaml [libpgocaml-ocaml-8yz73]1.4-2+b1
ii  ocaml-nox [ocaml-nox-3.12.1] 3.12.1-2

Versions of packages libpgocaml-ocaml-dev recommends:
ii  ocaml-findlib  1.2.8+debian-1

Versions of packages libpgocaml-ocaml-dev suggests:
pn  postgresql  

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120426000749.9984.63398.reportbug@localhost

Re: Help sought for compiling guestfs-browser

[Sylvain Le Gall]

Hello,

On 31-07-2011, Hilko Bengen  wrote:
> Hi,
>
> I am trying to compile guestfs-browser[1], at the moment because I want
> to see if it's usable, but with the possible intent to package it. (I
> have just uploaded libguestfs and various bindings to experimental.)
>
> I have installed everything needed by the configure script
> (libcamomile-ocaml-data and libcamomile-ocaml-dev from experimental) and
> that works nicely. However, I get a bunch of compiler errors, as shown
> below[2].
>
> Does anyone have an idea what might be going wrong?
>
> Cheers,
> -Hilko
>
> [1] 
> http://people.redhat.com/~rjones/guestfs-browser/files/guestfs-browser-0.2.1.tar.gz
>
> [2]
>
> $ make
> ocamlfind ocamldep -package 
> libvirt,guestfs,hivex,lablgtk2,extlib,xml-light,calendar,camomile,threads,bitstring,bitstring.syntax
>  -syntax bitstring cmdline.mli config.mli deviceSet.mli filetree_markup.mli 
> filetree.mli menu_about.mli menu_open_disk.mli menu_open_uri.mli 
> op_checksum_file.mli op_copy_regvalue.mli op_disk_usage.mli 
> op_download_as_reg.mli op_download_dir_find0.mli op_download_dir_tarball.mli 
> op_download_file.mli op_file_information.mli op_file_properties.mli 
> op_inspection_dialog.mli op_view_file.mli slave.mli slave_types.mli 
> slave_utils.mli utils.mli window.mli cmdline.ml deviceSet.ml 
> filetree_markup.ml filetree.ml main.ml menu_about.ml menu_open_disk.ml 
> menu_open_uri.ml op_checksum_file.ml op_copy_regvalue.ml op_disk_usage.ml 
> op_download_as_reg.ml op_download_dir_find0.ml op_download_dir_tarball.ml 
> op_download_file.ml op_file_information.ml op_file_properties.ml 
> op_inspection_dialog.ml op_view_file.ml slave.ml slave_types.ml 
> slave_utils.ml throbber.ml utils.ml w
 indow.ml | \
> /bin/sed -e :a -e '/ *\\$/N; s/ *\\\n */ /; ta' | \
> sort > .depend-t

Can you give us the version of bitstring, ocaml and camomile?

BTW, your command line seems wrong, it should be -syntax camlp4o rather
than -syntax bitstring.

> No level labelled ";" in entry "expr"
> Failure: "Grammar.extend"
> Preprocessing error on file cmdline.mli
> No level labelled ";" in entry "expr"
> Failure: "Grammar.extend"

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnj3ckhi.9th.gil...@gallu.homelinux.org

Re: Automatic dependencies for shared modules

[Sylvain Le Gall]

On 22-06-2011, Mehdi Dogguy  wrote:
> On 06/22/2011 10:30 PM, Stéphane Glondu wrote:
>> Le 22/06/2011 22:27, Mehdi Dogguy a écrit :
>>>> I'd like to upload an updated dh_ocaml package soon, so as to fix
>>>> the experimental liquidsoap package. Let me know if this ok for the
>>>> team.
>>>>
>>>
>>> We don't have any major transition going on, so I don't see why we
>>> should hold back this upload. So, please go ahead!
>>
>> Actually, there is the type-conv transition ongoing... but I don't
>> foresee any issue in uploading dh-ocaml now.
>>

I don't think there will be any problem about that.

>
> That's why I said "major" :p
>

Hey!!! That is a major transition for me ;-)

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnj04mr2.9th.gil...@gallu.homelinux.org

Re: oasis

[Sylvain Le Gall]

Hello,

On 02-06-2011, Daniel Bünzli  wrote:
> Hello Sylvain,
>
> I didn't get your answer (please keep me on the cc).
>
>> As far as oasis and uuidm is concerned, the migration to oasis is quite
>> simple. I already crafted a tool to manage oasis package in debian
>> (oasis2debian:
>
> So packagers only need an _oasis file describing the library and voilà ?
>
> The situation now is that I have an ad-hoc build script which has
> various targets to build and install the libraries. My plan is to
> remove these scripts from the distributions and replace them by an
> _oasis file. Is that all what you need ?
>

Well, there are two parts:
1 - _oasis describes build dependencies, from this file a tool like
oasis2debian can deduce build dependencies and what documentation is
built 
2 - setup.ml, generated from _oasis using "oasis setup", is a standard
entry point in the build system.

But all this remains helpers to write a debian packages from _oasis, the
tool is still in development and IHMO a Debian packager will still need
to review by hand the changes made by the tool.

But I think, it is safe enough to say that _oasis + setup.ml is enough
to have a good package.

BTW, you can keep you custom scripts and call them through oasis using
"BuildType: custom" "XCustomBuild: myscript.sh".

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniuh5q2.ks.gil...@gallu.homelinux.org

Re: oasis

[Sylvain Le Gall]

Hello,

On 30-05-2011, Daniel Bünzli  wrote:
> Hello,
>
> I will eventually update all my software packages to use oasis. Since
> people already did package some of this software [1] I'd be glad to
> hear from them on what is the most appropriate and simple way to work
> for them given the oasis hypothesis (I plan to remove my ad-hoc
> installation scripts).
>
> http://packages.debian.org/squeeze/libxmlm-ocaml-dev
> http://packages.debian.org/squeeze/libuuidm-ocaml-dev
> http://packages.debian.org/squeeze/libreact-ocaml-dev

As far as oasis and uuidm is concerned, the migration to oasis is quite
simple. I already crafted a tool to manage oasis package in debian
(oasis2debian:
http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/oasis2debian.git;a=summary
)

For other people, you should have a look at debian/rules of oasis
package:
http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/oasis.git;a=blob;f=debian/rules;h=adbb6d7bb351adb37118bea0f4a0a35fd03194e4;hb=HEAD

Right now, it uses override, but it should become a real buildsystem (as
dh understand it).

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniu82ns.ks.gil...@gallu.homelinux.org

[VAC] 16th -> 24th April

[Sylvain Le Gall]

Hello all,

I will be on vacation for a week. All my packages are team maintained,
see with debian-ocaml-maint@l.d.o for NMU. No internet access at all
because it will be real vacation ;-)

Cheers
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110411221431.gi3...@yocto.gallu.homelinux.org

Bug#620838: dh-ocaml: dh_ocaml doesn't depend on -dev packages even when runtime package requires it

[Sylvain Le Gall]

Package: dh-ocaml
Version: 0.9.6
Severity: normal


While building the package oasis, I saw a difference in liboasis-ocaml
and liboasis-ocaml-dev dependencies list: ocamlgraph and fileutils are
missing from the runtime package.

It should be related to the fact that they don't ship runtime packages
(pure ocaml packages). However, the runtime package of liboasis-ocaml
contains *.cma libraries that really need the libraries provided by
libocamlgraph-ocaml-dev and libfileutils-ocaml-dev.

Cheers
Sylvain Le Gall


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-vserver-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

dh-ocaml depends on no packages.

Versions of packages dh-ocaml recommends:
ii  debhelper 8.1.2  helper programs for debian/rules
ii  ocaml-nox 3.11.2-4   ML implementation with a class-bas

Versions of packages dh-ocaml suggests:
ii  git [git-core]   1:1.7.4.1-5 fast, scalable, distributed revisi
ii  git-core 1:1.7.4.1-5 fast, scalable, distributed revisi

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110404151613.15999.23157.report...@yocto.gallu.homelinux.org

Re: Transition to OCaml 3.12.0...

[Sylvain Le Gall]

Hello,

On 10-03-2011, David MENTRE  wrote:
> Hello Stéphane,
>
> 2011/3/10 Stéphane Glondu :
>> After #613848 is done.
>
> Could we have a message on this list when the transition is started,
> so has to avoid upgrading or installing packages during it? Thank you.


What would be really great, would be to have a state per ocaml package
telling you which one you should not upgrade in fact and which one you
should upgrade.

For example, I am always afraid to broke current transition by uploading
new package versions. I think it should be ok to upload "leaf" packages,
but I am not sure ("leaf" is e.g. ocaml-sqlexpr).

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrninjtik.81n.gil...@gallu.homelinux.org

Re: dh and ocamlvars.mk

[Sylvain Le Gall]

Hello,

On 26-02-2011, Eric Cooper  wrote:
> I'm changing the ocaml packages I maintain from cdbs to dh.
>
> The comment at the top of /usr/share/ocaml/ocamlvars.mk makes it sound
> cdbs-specific, but the actual variable definitions would be useful for
> dh as well.  Can I assume that it will remain safe to include this
> file for dh as well as cdbs debian/rules files?
>

It was cdbs specific, but should be useable now with dh as well. Do you
know that there is a "--with ocaml" for dh 7 ?

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnimj1cb.81n.gil...@gallu.homelinux.org

Bug#615260: libinifiles-ocaml-dev: missing html documentation

[Sylvain Le Gall]

Package: libinifiles-ocaml-dev
Version: 1.2-1
Severity: normal


We should create and install the HTML documentation.

Cheers
Sylvain Le Gall


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libinifiles-ocaml-dev depends on:
ii  libinifiles-ocaml [libinifile 1.2-1  read and write .ini files for OCam
ii  libpcre-ocaml-dev [libpcre-oc 6.0.1-3OCaml bindings for PCRE (Perl Comp
ii  ocaml-nox [ocaml-nox-3.11.2]  3.11.2-2   ML implementation with a class-bas

Versions of packages libinifiles-ocaml-dev recommends:
ii  ocaml-findlib 1.2.6+debian-1 management tool for OCaml librarie

libinifiles-ocaml-dev suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110226150709.5785.10006.reportbug@localhost

Re: Bug#613848: Transition to OCaml 3.12.0...

[Sylvain Le Gall]

On 18-02-2011, Stéphane Glondu  wrote:
> Le 10/02/2011 10:12, Sylvain Le Gall a écrit :
>> I also have a pair of packages to update (sexplib, type-conv, bin-prot,
>> ounit). Since some of them will break the distribution and should
>> trigger the need to binNMU some other packages, I am not sure how to
>> proceed: 1) upload new version during the transition, 2) do it before
>> and ask for binNMU or 3) do it before and don't ask for binNMU
>
> I've just realized that the last upstream release of type-conv and
> sexplib310 don't compile with ocaml 3.11.2. So for these two, we have no
> choice, we have to do 1).
>
> I've updated sexplib310 packaging in git, and upstream changes look
> pretty invasive (we are several versions behind). Work has to be done to
> make sure all rdeps build, and I'd rather stick to the version currently
> in unstable if this work is not done before we start the OCaml transition.
>
> The latest upstream of type-conv seems to be already packaged in git.
> Sylvain, what are your feeling about updating it during OCaml
> transition? If you are unsure, I've got a patch to make the version
> currently in unstable compile with OCaml 3.12.

I am ok for an upload during 3.12 transition of sexplib/type-conv, rdeps
are not that big. It will only delay janest-core AFAIK.

>
> ounit is already in experimental and seems ready to be part of #613848
> (but I'd like to have confirmation).

I can upload it to unstable, it is in a good shape.

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnilsj6r.krm.gil...@gallu.homelinux.org

Re: build-dep-graph and ocaml-debian-status disabled

[Sylvain Le Gall]

On 16-02-2011, Stefano Zacchiroli  wrote:
>
> Prodded by the alioth admins due to disk space utilization, I discovered
> that I was still maintaining in my homepage a couple of services linked
>=66rom the OCaml team (wiki) page:
>
> - build-dep-graph (the tool in our svn at /trunk/tools/build-dep-graph)
> - ocaml-debian-status (ditto at /trunk/tools/ocaml-debian-status)
>
> I've no idea whether they were still used or not (and I didn't have time
> to check up to now), but for sure they are disabled since this morning
> and I've removed them from my home dir. The code is still safe in SVN
> though, if you discover they are needed, it would be nice to setup them
> again in the home dir of the pkg-ocaml-maint project (where I should
> have set up them in the very beginning). All in all, I've the impression
> they are no longer needed since quite some time, superseded by the
> transition monitor.
>
> Cheers.
>
> PS please Cc:-me on reply *if* you want to get my attention

I setup the build-dep-graph stuff last year:

gildor@alioth:~/build-dep-graph$ crontab -l
# m h  dom mon dow   command
05 00   *   *   *   (cd $HOME/build-dep-graph && svn up ; make update install) 
> /dev/null

Seems we were overwriting each other stuff since one year. At least
there is nothing to change after you stop your script, for this part.

Concerning the ocaml-debian-status, I think the transition monitor is
made for this task. 


Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniln6ma.krm.gil...@gallu.homelinux.org

Re: Transition to OCaml 3.12.0...

[Sylvain Le Gall]

On 10-02-2011, Ralf Treinen  wrote:
> Hello,
>
> On Mon, Feb 07, 2011 at 03:14:52PM +0100, Stéphane Glondu wrote:
>
>> All packages not in the table should be safely binNMU-ed. The table
>> summarizes work that will need to be done manually. Please have a
>> look, check your packages, and put your name in the slots you want
>> to handle yourself.
>
> I have some packages that would be binNMU-ed, but that I would like to 
> update before starting the process. What would be the timeframe for
> doing that? If we could have at least one week or so before the migration
> starts that would be great.
>

I also have a pair of packages to update (sexplib, type-conv, bin-prot,
ounit). Since some of them will break the distribution and should
trigger the need to binNMU some other packages, I am not sure how to
proceed: 1) upload new version during the transition, 2) do it before
and ask for binNMU or 3) do it before and don't ask for binNMU

1) let us use the transition binNMU for ocaml 3.12 upgrade and package
upgrade which makes sense because some new versions are here to fix 3.12
build. But with 1), if something fails we will have a longer 3.12
upgrade.

2) should be the standard path outside the 3.12 upgrade but can delay
significantly the start of the upgrade

3) will let unstable in a broken state until the transition finished...

What should I (we) do?

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnil7av3.981.gil...@gallu.homelinux.org

Re: Transition to OCaml 3.12.0...

[Sylvain Le Gall]

Hi,

On 08-02-2011, Stéphane Glondu  wrote:
> Le 08/02/2011 09:02, Mehdi Dogguy a écrit :
>
>> AFAIK, other packages FTBFSing have patches too... so, it should be easy
>> to get around those build failures. (Unless I misunderstood something).
>
> Could you point me to those patches? I agree, some of the FTBFSes can be
> easily fixed, but ocamlgsl one (for example) doesn't seem obvious to me,
> and I don't have time to investigate it myself.
>

The ocamlgsl package is already a PAS and should not probably not be
built on armel. 

See the error in the build log:
#error "Architectures with double-word alignment for doubles are not supported"

But maybe you are referring to something else.

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnil22dt.981.gil...@gallu.homelinux.org

Bug#611213: unison-gtk: Missing dependency on unison package

[Sylvain Le Gall]

Hello,

On Wed, Jan 26, 2011 at 09:14:35PM +0100, Dominique Dumont wrote:
> Package: unison-gtk
> Version: 2.32.52-1
> Severity: normal
> 
> Hello
> 
> Looks like unison-gtk is not usable if unison is not installed. 
>  But unison is not listed in the dependency list.
> 
> Could you add this dependency ?
> 

That should not happen, because unison-gtk is unison + gtk interface.

Could you give me the output that lead you to this conclusion ?

N.B. if you use unison with ssh, unison must be installed on the target
computer as well.

Cheers
Sylvain

-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110126212142.ge27...@yocto.gallu.homelinux.org

Slow retirement

[Sylvain Le Gall]

Hi all fellow pkg-ocaml-maintainers,

Since a few days, I am considering to retire from various extra
activities I had, like Debian. The reasons are quite simple: I want to
spend more time with my family and I just buy a house that will need
some work. 

My first child was born 3 years ago, and I have been struggling to keep
my Debian activities at an acceptable level since then. 

This is not a formal retirement, I will still be around for at least 6
months. However, I would like that other people begin to take care of
some of my important packages, esp. unison. We will have time to talk
about this after squeeze release.

Cheers,
Sylvain Le Gall
-- 
My company: http://www.ocamlcore.com
Linkedin:   http://fr.linkedin.com/in/sylvainlegall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniib9dp.118.gil...@gallu.homelinux.org

Re: List of FTBFS in Ubuntu

[Sylvain Le Gall]

On 03-12-2010, Stéphane Glondu  wrote:
> This is a multi-part message in MIME format.
> --030406090201010307010801
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> Le 03/12/2010 16:24, Sylvain Le Gall a =C3=A9crit :
>>> There is a problem with inversion of flags for library in pcre-ocaml. =
> I

[...]

>> (the patch is from Magnus Therning)
>
> I independently came up with the attached patch against the version in
> git (didn't check yours), and checked that cameleon, cduce, ceve, galax,
> json-wheel, matita, ocsigen and pkglab build successfully. I pushed it
> for reference; however, the next sid version will (most likely) be a new
> upstream release. Has a patch been forwarded upstream, BTW?
>

I don't think so. I was part of the discussion and probably asked
Magnus, which is the patch's author and Arch Linux packager, to forward
it -- though I don't remember precisely.

Maybe you can contact Magnus about this and see if your patch apply to
the version in Arch Linux. AFAIK, the version in Arch is the latest
version and the bug is still there.

Regards
Sylvain


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnifj1ul.r67.gil...@gallu.homelinux.org

Re: List of FTBFS in Ubuntu

[Sylvain Le Gall]

On 03-12-2010, Sylvain Le Gall  wrote:
> On 03-12-2010, Ralf Treinen  wrote:
>> On Fri, Dec 03, 2010 at 08:43:23AM +0100, Lucas Nussbaum wrote:
>>
>>> >From time to time, I do archive rebuilds for Ubuntu too, and I thought
>>> that the results would be interesting for DDs as well, since a FTBFS in
>>> Ubuntu might indicate that the package will FTBFS in the future in
>>> Debian, due to toolchain changes for example.
>>
>>> http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi.
>>
>> Thanks, Lucas, that is useful.
>>
>> There are quite some problems related to pcre (several ocaml packages
>> are bitten by that, but not only). Any idea to what this may be due?
>>
>
> There is a problem with inversion of flags for library in pcre-ocaml. I
> had a discussion about this issue with Arch Linux pcre-ocaml (and oasis)
> maintainer. 
>

On 06/11/10 21:10, Sylvain Le Gall wrote:   


> On Sat, Nov 06, 2010 at 08:54:13PM +, Magnus Therning wrote:  
>           
>   
>> On 06/11/10 17:34, Sylvain Le Gall wrote:

>> I found a rather hackish way to fix it.  'ocamlobjinfo' now says 
>>  
>>
>>  
>>  
>>
>>Extra C object files: -lpcre_stubs -L/usr/lib -lpcre -lpcre_stubs 
>>  
>>
>>  
>>  
>>
>> Not the clean fix I would have liked, but it soves the problem. :-)  
>>  
>>
>>  
>>  
>>
>> Now I only have some minor clean-ups and then I can update OASIS and its 
>>  
>>
>> dependencies.
>>  
>>
>>  
>>  
>>
>> Thanks for your help with this!  
>>  
>>
>>  
>>  
>>
>   
>   
>   
> Do you fix it in the pcre-ocaml package? or just for ocaml-expect build?  
>  

Re: List of FTBFS in Ubuntu

[Sylvain Le Gall]

On 03-12-2010, Ralf Treinen  wrote:
> On Fri, Dec 03, 2010 at 08:43:23AM +0100, Lucas Nussbaum wrote:
>
>> >From time to time, I do archive rebuilds for Ubuntu too, and I thought
>> that the results would be interesting for DDs as well, since a FTBFS in
>> Ubuntu might indicate that the package will FTBFS in the future in
>> Debian, due to toolchain changes for example.
>
>> http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi.
>
> Thanks, Lucas, that is useful.
>
> There are quite some problems related to pcre (several ocaml packages
> are bitten by that, but not only). Any idea to what this may be due?
>

There is a problem with inversion of flags for library in pcre-ocaml. I
had a discussion about this issue with Arch Linux pcre-ocaml (and oasis)
maintainer. 

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnifi2hc.r67.gil...@gallu.homelinux.org

Bug#605741: ITP: caml2html -- HTML and LaTeX colored syntax from OCaml source files

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: caml2html
  Version : 1.4.1
  Upstream Author : Martin Jambon
* URL : http://martin.jambon.free.fr/caml2html.html
* License : GPL-2
  Programming Lang: OCaml
  Description : HTML and LaTeX colored syntax from OCaml source files
Caml2html provides a command-line executable which converts a set of
OCaml source files into a HTML or LaTeX document with colored syntax. A
library is also provided for building web-page generators that would
color OCaml code appropriately. 



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202224132.32344.62165.report...@zetta.gallu.homelinux.org

Bug#605683: ITP: ocaml-sqlexpr -- type-safe access to SQL DB in OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: ocaml-sqlexpr
  Version : 0.2.3
  Upstream Author : Mauricio Fernandez
* URL : http://github.com/mfp/ocaml-sqlexpr
* License : LGPL-2.1 with OCaml linking exception
  Programming Lang: OCaml
  Description : type-safe access to SQLite DB in OCaml

  Minimalistic library and syntax extension for type-safe, convenient execution
  of SQL statements. Currently compatible with Sqlite3.
  .
  Sqlexpr features:
   * automated prepared statement caching, param binding, data extraction, error
 checking (including automatic stmt reset to avoid BUSY/LOCKED errors in
 subsequent queries), stmt finalization on db close, etc.
   * HOFs like iter, fold, transaction
   * support for different concurrency models: everything is functorized over a
 THREAD monad, so you can for instance do concurrent folds/iters with Lwt
   * support for SQL stmt syntax checks and some extra semantic checking (column
 names, etc)



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202113319.21761.95696.report...@zetta.gallu.homelinux.org

Bug#605682: ITP: ocaml-deriving -- deriving functions from type declarations in OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: ocaml-deriving
  Version : 0.1.1a
  Upstream Author : Jeremy Yallop
* URL : http://code.google.com/p/deriving/
* License : MIT
  Programming Lang: OCaml
  Description : deriving functions from type declarations in OCaml

Camlp4 extension to OCaml for deriving functions from type declarations.
Includes derivers for pretty-printing, type-safe marshalling with
structure-sharing, dynamic typing, equality, and more.



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202112747.21519.42292.report...@zetta.gallu.homelinux.org

Bug#605681: ITP: yojson -- JSON library for OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: yojson
  Version : 0.8.1
  Upstream Author : Martin Jambon
* URL : http://martin.jambon.free.fr/yojson.html
* License : BSD3
  Programming Lang: OCaml
  Description : JSON library for OCaml

Yojson is an optimized parsing and printing library for the JSON format.
It addresses a few shortcomings of json-wheel including 3x speed
improvement, polymorphic variants and optional syntax for tuples and
variants. 
.
It is a replacement for json-wheel (libjson-wheel-ocaml-dev).



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202112053.21353.22031.report...@zetta.gallu.homelinux.org

Bug#605680: ITP: easy-format -- text generation with indentation made easy(ier) for OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: easy-format
  Version : 1.0.0
  Upstream Author : Martin Jambon
* URL : http://martin.jambon.free.fr/easy-format.html
* License : BSD3
  Programming Lang: OCaml
  Description : text generation with indentation made easy(ier) for OCaml

This module offers a simplified interface to the Format module of the
standard library. Input data must be converted into a tree using 3 kinds
of nodes: atoms, lists and labelled nodes. Each node is bound to its own
formatting parameters and a single function call produces the formatted
output. 





-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202111757.21306.45343.report...@zetta.gallu.homelinux.org

Bug#605677: ITP: cppo -- Cpp for OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: cppo
  Version : 0.9.0
  Upstream Author : Martin Jambon
* URL : http://martin.jambon.free.fr/cppo.html
* License : BSD3
  Programming Lang: OCaml
  Description : Cpp for OCaml

Cppo is an OCaml-friendly implementation of cpp, the C preprocessor. 
It can replace camlp4 for preprocessing.



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202111507.21261.25651.report...@zetta.gallu.homelinux.org

Bug#605675: ITP: camltemplate -- configurable library for generating text from templates in OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: camltemplate
  Version : 1.0.2
  Upstream Author : Benjamin Geer
* URL : http://camltemplate.forge.ocamlcore.org/
* License : GPL-2+
  Programming Lang: OCaml
  Description : configurable library for generating text from templates in 
OCaml

 CamlTemplate is library for generating text from templates in OCaml. It
 can be used to generate web pages, scripts, SQL queries, XML documents
 and other sorts of text.



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2010120253.21155.17807.report...@zetta.gallu.homelinux.org

Bug#605674: ITP: camlmix -- preprocessor which converts text with embedded OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: camlmix
  Version : 1.3.0
  Upstream Author : Martin Jambon
* URL : http://martin.jambon.free.fr/camlmix/
* License : BSD3
  Programming Lang: OCaml
  Description : preprocessor which converts text with embedded OCaml

Camlmix is a generic preprocessor which converts text with embedded
OCaml into an OCaml program with embedded text. It produces text
documents from one or several templates. OCaml toplevel statements are
inserted between '## ... ##', and OCaml string expressions between 
'##= ...  ##'.



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202110447.19888.12933.report...@zetta.gallu.homelinux.org

Bug#605672: ITP: biniou -- Flexible binary data format in OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: biniou
  Version : 0.9.1
  Upstream Author : Martin Jambon
* URL : http://martin.jambon.free.fr/biniou.html
* License : BSD3
  Programming Lang: OCaml
  Description : Flexible binary data format in OCaml

Biniou is a binary data format designed for speed, safety, ease of use
and backward compatibility as protocols evolve. Biniou is vastly
equivalent to JSON in terms of functionality but allows implementations
about 4 times as fast (see godi-yojson for comparison), with 25-35%
space savings. Biniou data can be decoded into human-readable form
without knowledge of type definitions except for field and variant names
which are represented by 31-bit hashes. 



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202110121.19529.31069.report...@zetta.gallu.homelinux.org

Bug#605671: ITP: atdgen -- Code generator for biniou and JSON serialization

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: atdgen
  Version : 1.0.1
  Upstream Author : Martin Jambon
* URL : http://oss.wink.com/atdgen/
* License : BSD3
  Programming Lang: OCaml
  Description : Code generator for biniou and JSON serialization

Atdgen is a command-line program that takes as input type definitions in
the ATD syntax and produces OCaml code suitable for data serialization
and deserialization. Two data formats are currently supported, these are
biniou and JSON. 



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202105843.19472.99478.report...@zetta.gallu.homelinux.org

Bug#605670: ITP: atd -- Syntax for cross-language data types in OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: atd
  Version : 0.9.2
  Upstream Author : Martin Jambon
* URL : http://oss.wink.com/atd/
* License : BSD3
  Programming Lang: OCaml
  Description : Syntax for cross-language data types in OCaml

ATD stands for Adjustable Type Definitions. It is a type definition
language designed to accomodate a variety of programming languages and
data formats by the means of target-specific annotations. It supports
sum types, parametrized types and inheritance. The library provides a
parser and other tools useful for manipulating ATD type definitions.
The reference manual gives a complete description of the syntax. 



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202105611.19337.78289.report...@zetta.gallu.homelinux.org

Bug#605669: ITP: tophide -- Hides toplevel values whose name starts with an underscore.

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: tophide
  Version : 1.0.0
  Upstream Author : Martin Jambon
* URL : http://martin.jambon.free.fr/ocaml.html
* License : BSD3
  Programming Lang: OCaml
  Description : Hides toplevel values whose name starts with an underscore.

Tophide hides toplevel values whose name starts with an underscore. This
is useful for some Camlp4 syntax extensions that produce lots of global
identifiers that should remain hidden. 



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202105226.19295.46431.report...@zetta.gallu.homelinux.org

Bug#605652: ITP: ocaml-inifiles -- read and write .ini for OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: ocaml-inifiles
  Version : 1.2
  Upstream Author : Eric Stokes
* URL : http://homepage.mac.com/letaris/
* License : LGPL-2.1+
  Programming Lang: OCaml
  Description : read and write .ini for OCaml

  This library allow to read and write .ini files. It features
  an object oriented interface to manipulate inifiles. It allows
  sections listing and operation on several inifiles grouped in
  a directory.



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101201161318.30245.24704.report...@localhost

Bug#605635: ITP: mikmatch -- camlp4 extension for pattern matching with regexps

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: mikmatch
  Version : 1.0.2
  Upstream Author : Martin Jambon
* URL : http://martin.jambon.free.fr/micmatch.html
* License : BSD3
  Programming Lang: OCaml
  Description : camlp4 extension for pattern matching with regexps

 Mikmatch provides enhanced pattern matching with regexps for OCaml.
 .
 The goal of Mikmatch is to make text-oriented programs even easier to write,
 read and run without losing the unique and powerful features of OCaml.
 Mikmatch provides a concise and highly readable syntax for regular
 expressions, and integrates it into the syntax of OCaml thanks to Camlp4.
 .
 The implementation of Mikmatch consists essentially of:
  * a library which is loaded by the OCaml preprocessor (Camlp4) and
defines sophisticated "macros", i.e. the modified syntax;
  * a traditional library (runtime) which is required by the programs that
use the Mikmatch syntax;
  * a dedicated 'mikmatch' command which can be used as a replacement for
'ocaml' in scripts or as an interactive toplevel. It performs automatically
these steps: preprocessing, compilation and execution.



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202001634.3383.39917.report...@yocto.gallu.homelinux.org

Bug#605634: ITP: ocaml-inifiles -- read and write .ini files for OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: ocaml-inifiles
  Version : 1.2
  Upstream Author : Eric Stokes
* URL : http://homepage.mac.com/letaris/
* License : LGPL-2.1
  Programming Lang: OCaml
  Description : read and write .ini files for OCaml

 This library allow to read and write .ini files. It features
 an object oriented interface to manipulate inifiles. It allows
 sections listing and operation on several inifiles grouped in
 a directory.





-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101202001232.3259.92799.report...@yocto.gallu.homelinux.org

Bug#605575: ITP: xstrp4 -- camlp4 extension that expands brace expansions in OCaml string

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: xstrp4
  Version : 1.8
  Upstream Author : Gerd Stolpmann
* URL : http://projects.camlcity.org/projects/xstrp4.html
* License : MIT
  Programming Lang: OCaml
  Description : camlp4 extension that expands brace expansions in OCaml 
string

  This camlp4 syntax extension interprets the dollar notation ${name} in
  strings and in included files.
  .
  It can:
   * include whole file in your OCaml code
   * define a format '%x' conversion to display variables
   * interpolate '$x' as well as '${x}
   * take into account record field and module names



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101201130634.14022.54375.report...@localhost

Bug#604636: libcamlimages-ocaml-dev: does not install oFreetype.cmi

[Sylvain Le Gall]

On Tue, Nov 23, 2010 at 11:47:28AM +0200, ygrek wrote:
> Package: libcamlimages-ocaml-dev
> Version: 1:3.0.1-5+b3
> Severity: normal
> 
> oFreetype.cmi is created during build but is not installed. So OFreetype
> is present in cma but is not accessible because of cmi absence.
> 
> $ ls src/oFreetype.*
> src/oFreetype.cmi
> src/oFreetype.cmo
> src/oFreetype.cmx
> src/oFreetype.ml
> src/oFreetype.o
> 
> $ ls /usr/lib/ocaml/camlimages/oFreetype.*
> ls: cannot access /usr/lib/ocaml/camlimages/oFreetype.*: No such file or 
> directory
> 
> Maybe there are some other modules with this problem..
> 

Upstream author seems to distribute freetype.mli to access freetype.
Maybe he wants to keep oFreetype internal.

Cheers
Sylvain Le Gall



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101123101715.gp20...@yocto.gallu.homelinux.org

Re: names of distribution-branches in the git repository

[Sylvain Le Gall]

On 23-11-2010, Ralf Treinen  wrote:
> On Mon, Nov 22, 2010 at 02:15:27PM +0000, Sylvain Le Gall wrote:
>> On 22-11-2010, Mehdi Dogguy  wrote:
>> > On 22/11/2010 14:15, Sylvain Le Gall wrote:
>> >> 
>> >> May I suggest my own summary, about this feature (trying to solve 
>> >> conflicts between all opinions):
>> >
>> > I think that we all agreed on Stéphane's proposal (at least, those
>> > who raised their voice here). Didn't we? :)
>> 
>> The only thing, I had against Stéphane proposal was about */upstream.
>> But as you see in the summary, I change my mind about that.
>
> I didn't.
>
> All changes to the upstream branch are local, and are not supposed to be
> pushed to the central repository (which usually means that they are
> only temporary and should not even be comitted). When I do changes
> on upstream then it is to try changes, and when I am satisfied I 
> put them into a quilt patch on the the debian branch and undo them on
> my upstream branch.

The $distrib/upstream will only contain change made by upstream, not by
you. We just keep the same scheme as with master and upstream but
git-buildpackage need to have an upstream branch as a reference.

Example: 
- git-import-orig in experimental/master will commit upstream tarball in
  experimental/upstream
- if you made change to something outside debian/ in experimental/master
  you can store it into debian/patches 

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnien4ad.r67.gil...@gallu.homelinux.org

Re: names of distribution-branches in the git repository

[Sylvain Le Gall]

On 22-11-2010, Mehdi Dogguy  wrote:
> On 22/11/2010 15:15, Sylvain Le Gall wrote:
>
> I'm not sure it's relevant then. I would not keep the history if I'm
> reworking from scratch. ymmv
>
>>> I'm not sure that we should enforce anything on how/from what the 
>>> branches were created here.
>>> 
>>>> - set debian/gbp.conf accordingly (upstream-branch and 
>>>> debian-branch)
>>>> 
>>> 
>>> Why? or did you forget to add "in $distrib/debian"?
>> 
>> I mean that we should add/change upstream-branch = upstream to 
>> upstream-branch = $distrib/upstream
>> 
>> and debian-branch = master to debian-branch = $distrib/master
>> 
>
> Yeah, I did understand that. But, I wouldn't not commit that on "master".
> The default remains "sid", IMHO.

I am talking about a commit in $distrib/master not master.

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniel5pj.r67.gil...@gallu.homelinux.org

Re: names of distribution-branches in the git repository

[Sylvain Le Gall]

On 22-11-2010, Mehdi Dogguy  wrote:
> On 22/11/2010 14:15, Sylvain Le Gall wrote:
>> 
>> May I suggest my own summary, about this feature (trying to solve 
>> conflicts between all opinions):
>
> I think that we all agreed on Stéphane's proposal (at least, those
> who raised their voice here). Didn't we? :)

The only thing, I had against Stéphane proposal was about */upstream.
But as you see in the summary, I change my mind about that.

Stéphane's proposal seems reasonable to me.

>
>> - in the Debian OCaml reference:
>> 
>> - if we package something for anything else than sid:
>> 
>> - create a set of branch $distrib/master, $distrib/upstream forked
>> from the master, upstream branches (E.g. squeeze/master,
>> squeeze/upstream)
>> 
>
> Why adding the condition "forked from"? What if I want to rework my
> packaging from scratch? and What if the new upstream release has nothing
> to do with previous releases? It $distrib < sid, then ok… but in this
> case, it should be forked from "debian/$distrib's_version" and
> "upstream/$distrib's_version" IMHO.
>

Forked from scratch -> you can work from scratch with history. Even if
you delete everything, you can keep history of this big change...

> I'm not sure that we should enforce anything on how/from what the branches
> were created here.
>
>> - set debian/gbp.conf accordingly (upstream-branch and debian-branch)
>> 
>
> Why? or did you forget to add "in $distrib/debian"?

I mean that we should add/change
upstream-branch = upstream 
to 
upstream-branch = $distrib/upstream

and 
debian-branch = master 
to
debian-branch = $distrib/master

>
>> - the pristine-tar branch remains the same
>
> pristine-tar branch should not be branched… since it's just a directory
> with known versions (as I see it).
>
>> - in dom-git-checkout:
>> 
>> - if */master exists, display an information note listing other 
>> branches.  E.g.: You checkout master but experimental/master and 
>> squeeze/master also exists
>> 
>> - add an option (-t $distrib) to fetch/checkout $distrib/upstream and 
>> $distrib/master, with a special keyword "all" that ifetch all $distrib
>
> Seems reasonable for me.
>
>> - in dom-new-git-repo:
>> 
>> - add an option (-t $distrib) to fork upstream and master branches 
>> remotely and check them out locally.
>> 
>
> How do you fork from something that doesn't exist? (e.g. master). Is this
> option relevant here?
>

My idea is that dom-new-git-repo should do the forks for us.

Maybe we should not use the script dom-new-git-repo for that. Maybe we
can use a script called dom-fork-git-repo or something similar...


Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniekunv.r67.gil...@gallu.homelinux.org

Re: names of distribution-branches in the git repository

[Sylvain Le Gall]

On 20-11-2010, Ralf Treinen  wrote:
> Hi,
>
> these days we are (or ar least we should be) mostly using the experimental
> distribution for uploads. In that case it seems reasonable to put 
> modifications on a git branch that is specific to that distribution.
> This of course also applies to other branches, like for backporting.
>
> It would be nice if we could agree on canonical names for these branches
> in the git repository. Personally, I have been using "master-experimental",
> which is a PITA to type, but I also have seen "experimetal" which is 
> probably less acurate but much more convenient.
>
> I suggest that we add to the dom packaging reference that branches intended
> for primary release into a distribution should be named like that
> distribution, that is experimental, squeeze, whatever-backport, etc, with
> the exception that the branch for sid is called master. Does that sound
> reasonable?
>
> In that case I would also suggest that dom-git-checkout also pulls the
> experimental branch when it exists.
>
>


May I suggest my own summary, about this feature (trying to solve
conflicts between all opinions):
- in the Debian OCaml reference:
  - if we package something for anything else than sid:
- create a set of branch $distrib/master, $distrib/upstream forked
  from the master, upstream branches (E.g. squeeze/master,
  squeeze/upstream)
- set debian/gbp.conf accordingly (upstream-branch and
  debian-branch) 
- the pristine-tar branch remains the same
- in dom-git-checkout:
  - if */master exists, display an information note listing other
branches.  E.g.: You checkout master but experimental/master and
squeeze/master also exists
  - add an option (-t $distrib) to fetch/checkout $distrib/upstream and
$distrib/master, with a special keyword "all" that ifetch all
$distrib
- in dom-new-git-repo:
  - add an option (-t $distrib) to fork upstream and master branches
    remotely and check them out locally.

What do you think about this?

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniekr85.r67.gil...@gallu.homelinux.org

Re: names of distribution-branches in the git repository

[Sylvain Le Gall]

Hello,

On 22-11-2010, Stéphane Glondu  wrote:
> Le 22/11/2010 09:54, Sylvain Le Gall a écrit :
>> Is experimental/upstream mandatory? I thought it was possible to inject
>> upstream tarball in upstream branch and merge into master (or
>> experimental/master).
>
> Then the upstream of the master branch doesn't correspond to any head?
>
> It is convenient to have a name for the base of the patch series, and
> dom-{apply,save}-patches use that. Committing stuff in the upstream
> branch not meant for master might confuse these tools (and those who are
> used to them :). The upstream branch also plays a role in gbp, so it
> might get confused too. For example, when you don't use pristine-tar,
> which might happen temporarily when you make snapshots, gbp uses that
> branch to generate a tarball. Moreover, branches are cheap in git, and
> cost next to nothing when they are an ancestor of another branch.
>
> In short, experimental/upstream might not be mandatory, but having it is
> convenient and avoids confusion IMHO.

Concerning the role in gbp, it uses branch + tag:

(I disable the pristine-tar)
gbp:info: ocaml-extunix_0.0.1.orig.tar.gz does not exist, creating from 
'upstream/0.0.1'

AFAIC, I never touch anything in upstream branch, so I won't be confused
;-)

My point is that upstream branch is upstream and master (or
experimental/master) should refer to upstream + tag. It seems to be the
case and I think it is a consistent choice. 

So even if branches are cheap, I would prefer to have a single upstream
branch. After all we only follow one upstream.

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniekhjf.r67.gil...@gallu.homelinux.org

Re: names of distribution-branches in the git repository

[Sylvain Le Gall]

On 21-11-2010, Stéphane Glondu  wrote:
> Le 20/11/2010 12:05, Ralf Treinen a écrit :
>> I suggest that we add to the dom packaging reference that branches intended
>> for primary release into a distribution should be named like that
>> distribution, that is experimental, squeeze, whatever-backport, etc, with
>> the exception that the branch for sid is called master. Does that sound
>> reasonable?
>
> My own practice is to use git-buildpackage's defaults (master, upstream)
> for unstable, and prefix them by "experimental/" (e.g.
> experimental/master and experimental/upstream) for experimental. For
> $codename, I would similarly create $codename/master and
> $codename/upstream. I'd like to see this adopted by the team.
>
> Having two git branches (master/upstream) per Debian branch is IMHO
> cleaner, and also fits better with git-buildpackage. I got used to it
> and saw nothing better so far. I find the name "experimental" ambiguous,
> and the words look in the wrong order in master-experimental. And
> upstream/$whatever conclicts with git-buildpackage's default name for
> the upstream branch. Starting names with $branch/ doesn't conflict with
> gbp's defaults, and forces to use an additionnal component name that
> makes the name meaningful gbp-wise.
>
> I don't branch pristine-tar (and BTW I don't even always commit there
> tarballs I don't upload to the official archive, especially snapshots),
> given the fact that files once there are there forever, and new files
> don't disturb tools (gbp, pristine-tar itself).
>
>

Is experimental/upstream mandatory? I thought it was possible to inject
upstream tarball in upstream branch and merge into master (or
experimental/master).

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniekbu1.r67.gil...@gallu.homelinux.org

Re: names of distribution-branches in the git repository

[Sylvain Le Gall]

On 20-11-2010, Ralf Treinen  wrote:
> Hi,
>
> these days we are (or ar least we should be) mostly using the experimental
> distribution for uploads. In that case it seems reasonable to put 
> modifications on a git branch that is specific to that distribution.
> This of course also applies to other branches, like for backporting.
>
> It would be nice if we could agree on canonical names for these branches
> in the git repository. Personally, I have been using "master-experimental",
> which is a PITA to type, but I also have seen "experimetal" which is 
> probably less acurate but much more convenient.
>
> I suggest that we add to the dom packaging reference that branches intended
> for primary release into a distribution should be named like that
> distribution, that is experimental, squeeze, whatever-backport, etc, with
> the exception that the branch for sid is called master. Does that sound
> reasonable?
>
> In that case I would also suggest that dom-git-checkout also pulls the
> experimental branch when it exists.
>

I agree on everything, but would vote for the "experimental" name. My
reason: you won't have upstream-experimental or
pristine-tar-experimental.

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniefbel.r67.gil...@gallu.homelinux.org

RFC: oasis2debian, a tool to create and maintain a debian/ using _oasis

[Sylvain Le Gall]

Hello all,

I work on this tool since a week and it is now ready for a peer review.
It is a quite simple tool that helps to translate an _oasis to a debian
directory.

It can do several things, depending on the content of _oasis:
- package split: 
  - if only exec -> 1 binary pkg
  - if exec + lib -> 1 bin (libXXX-ocaml-bin) + dev ( -ocaml-dev) + runtime 
(-ocaml)
  - if more than 2 docs -> add a -ocaml-doc package
- package name:
  - if one findlib hierarchy (e.g. expect, expect.str and expect.pcre)
use its base name (e.g. expect)
  - otherwise name of the source with ocaml- removed
- take care of creating .doc-base for documentation defined in _oasis by
  translating Document section of _oasis 
- create debian/rules using debhelper 7, override target to use 
  "ocaml setup.ml TARGET"
- create debian/control: use package split and compute build
  dependencies using BuildDepends of _oasis (for lib/exec that will be
  built), use dh_ocaml for the rest
- create debian/copyright: use _oasis fields to define copyright holders
  and license texts to copy
- create *.install and *.install.in files to move the result of the
  package build into various binary packages

The sole "conflicting" choice, I had to make, is the split of
dev/runtime. I decided to place META and *.cma into the runtime package.
I took this decision, considering the fact that plugins may need it...

You can fetch it from our git repository:
git+ssh://git.debian.org//git/pkg-ocaml-maint/packages/oasis2debian.git

You will need to patch and install xstrp4 1.7:
http://projects.camlcity.org/projects/xstrp4.html

(both of these will be packaged in a short term future)

I have generated a debian/ directory for the following project:
git+ssh://git.debian.org/git/pkg-ocaml-maint/packages/ocamlify.git
git+ssh://git.debian.org/git/pkg-ocaml-maint/packages/ocaml-data-notation.git
git+ssh://git.debian.org/git/pkg-ocaml-maint/packages/ocaml-expect.git
git+ssh://git.debian.org/git/pkg-ocaml-maint/packages/ocaml-extunix.git

Feel free to browse the already generated debian/ and make me comments
about them, so that I can at least correct the tool. They are lintian
clean and can build in a pbuilder. 

If you have any _oasis in your project, it can also be a good time to
see if my oasis2debian tool works correctly on your sources. 

Thank you in advance for your feedback.

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniee8q4.r67.gil...@gallu.homelinux.org

ITP: ocaml-extunix -- Extended functions for OCaml Unix module

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: ocaml-extunix
  Version : 0.0.1
  Upstream Author : ygrek, Sylvain Le Gall, Stephane Glondu 
* URL : http://extunix.forge.ocamlcore.org/
* License : LGPL-2.1 with OCaml linking exception
  Programming Lang: OCaml
  Description : Extended functions for OCaml Unix module

Thin bindings to various low-level system APIs (often non-portable)
which are not covered by Unix module.
.
Example functions:
 * uname
 * statvfs
 * fsync
 * fadvise
 * fallocate
 * atfile
 * dirfd
 * eventfd
 * signalfd
 * ...


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101119223331.21843.95583.report...@yocto.gallu.homelinux.org

Bug#603830: ITP: oasis -- Architecture for building OCaml libraries and applications

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: oasis
  Version : 0.2.0
  Upstream Author : Sylvain Le Gall
* URL : http://oasis.forge.ocamlcore.org/
* License : LGPL-2.1 with OCaml linking exception
  Programming Lang: OCaml
  Description : Architecture for building OCaml libraries and applications

This program generates a full configure, build and install system for your
application. It starts with a simple `_oasis` file at the toplevel of your
project and creates everything required.

It uses external tools like OCamlbuild and it can be considered as the glue
between various subsystems that do the job. It should support the following
tools:

- OCamlbuild
- OMake
- OCamlMakefile
- ocaml-autoconf

It also features a do-it-yourself command line invocation and an internal
configure/install scheme. Libraries are managed through findlib. It has been
tested on GNU Linux and Windows.

It also allows to have standard entry points and description. It helps to
integrates your libraries and software with third parties tools like GODI.



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101117174909.22509.5029.report...@yocto.gallu.homelinux.org

Bug#603829: ITP: ocaml-expect -- Expect-like framework in OCaml

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: ocaml-expect
  Version : 0.0.2
  Upstream Author : Sylvain Le Gall
* URL : http://forge.ocamlcore.org/projects/ocaml-expect/
* License : LGPL-2.1 with OCaml linking exception
  Programming Lang: OCaml
  Description : Expect-like framework in OCaml

This is a simple implementation of `expect` to help building unitary
testing of interactive program.

It helps to receive question and send answers from an interactive
process. You can match the question using a regular expression (Str or
Pcre). You can also use a timeout to ensure that the process answer in
time.



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101117174456.22479.89892.report...@yocto.gallu.homelinux.org

Bug#603828: ITP: ocaml-data-notation -- Store data using OCaml notation

[Sylvain Le Gall]

Package: wnpp
Severity: wishlist
Owner: Sylvain Le Gall 


* Package name: ocaml-data-notation
  Version : 0.0.3
  Upstream Author : Sylvain Le Gall
* URL : http://forge.ocamlcore.org/projects/odn
* License : LGPL-2.1 with OCaml linking exception
  Programming Lang: OCaml
  Description : Store data using OCaml notation

This library uses type-conv to dump OCaml data structure using OCaml
data notation. This kind of data dumping helps to write OCaml code
generator, like OASIS.





-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101117174051.22435.62869.report...@yocto.gallu.homelinux.org

Bug#591891: libdbus-ocaml-dev: Possible conflict between 2 OCaml bindings: dBus and ssl

[Sylvain Le Gall]

Hello,


On Mon, Nov 08, 2010 at 05:04:19PM +0100, Gregory Bellier wrote:
> I forgot to say the only info I can get from "ocamldebug" are those :
> 
[...]
> 
> After the step 3456, it froze. I hope this can help.

I acknowledge the bug. I can reproduce it, but I really don't know what
is happening.

When you say you contacted upstream, you talk about ocaml-ssl or
ocaml-dbus?

Cheers
Sylvain Le Gall



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101109110310.gk19...@yocto.gallu.homelinux.org

Bug#591891: libdbus-ocaml-dev: Possible conflict between 2 OCaml bindings: dBus and ssl

[Sylvain Le Gall]

On Tue, Nov 09, 2010 at 12:08:51PM +0100, Gregory Bellier wrote:
> Hi,
> 
> 2010/11/9 Sylvain Le Gall 
> 
> 
> When you say you contacted upstream, you talk about ocaml-ssl or
> ocaml-dbus?
> 
> 
> I meant ocaml-dbus.

Try upstream of ocaml-ssl. Maybe he will be more helpful regarding this
issue.

Cheers
Sylvain Le Gall





-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101109112347.gl19...@yocto.gallu.homelinux.org

Bug#602314: please let unison create hardlinks

[Sylvain Le Gall]

Hello,

On Wed, Nov 03, 2010 at 06:14:14PM +0100, martin f krafft wrote:
> Package: unison
> Version: 2.32.52-1
> Severity: wishlist
> 
> Thanks to storing content hashes, unison can SHORTCUT copying remote
> files by using already present local files as source. It sounds like
> it would be just a small step towards letting unison hardlink those
> files instead, falling back to copying if the hardlink fails.
> 

I am not sure to understand what you ask. Hardlinks and copies are not
the same thing. AFAIU, if you hardlink a file to a different filename
and make a change to one of these files, it will also appear in the
other file. You don't have this effect with copies. If the remote file
is not an hardlink, there is no point making the local file an hardlink.

Are you really sure about this feature? Could you explain to me how you
expect it to work?

Cheers
Sylvain Le Gall


signature.asc
Description: Digital signature

Bug#602298: [libounit-ocaml-dev] force "unit" return type in OUnit.bracket for typesafety

[Sylvain Le Gall]

On Wed, Nov 03, 2010 at 03:38:42PM +0100, Joost Yervante Damad wrote:
> On Wednesday 03 November 2010 15:34:26 Sylvain Le Gall wrote:
> > forwarded 602298
> > https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=799&group_id
> > =162&atid=732
> > 
> > thanks
> > 
> > Hello,
> > 
> > On Wed, Nov 03, 2010 at 03:13:20PM +0100, Joost Yervante Damad wrote:
> > > Package: libounit-ocaml-dev
> > > Version: 1.0.3-5.0.2
> > 
> > What a strange version number? Did you recompile it yourself?
> 
> Yeah, now you mention it. Things I added locally:
>  - stacktrace support on testcase failure due to exception
>  - compile ounit with -g for better stacktrace support in general
> 

Everything has been integrated into OUnit 1.1.0.
http://ounit.forge.ocamlcore.org

I'll wait the end of the freeze to upload it.

Cheers
Sylvain Le Gall





-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101103163325.gk28...@yocto.gallu.homelinux.org

Bug#602298: [libounit-ocaml-dev] force "unit" return type in OUnit.bracket for typesafety

[Sylvain Le Gall]

forwarded 602298 
https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=799&group_id=162&atid=732

thanks

Hello,

On Wed, Nov 03, 2010 at 03:13:20PM +0100, Joost Yervante Damad wrote:
> Package: libounit-ocaml-dev
> Version: 1.0.3-5.0.2

What a strange version number? Did you recompile it yourself?

> Severity: wishlist
> Tags: patch
> 
> --- Please enter the report below this line. ---
> 
> It would be useful to make return value of the testfunction f and teardown in 
> OUnit.bracket "unit" to enforce typing to avoid accidentally returning a 
> monadic type causing partial execution of a testcase. (e.g. when using Lwt)
> 
> See attached patch for a proposed solution.
> 

I thought about it while I release OUnit 1.1.0. It will probably make it
into 1.2.0.

Cheers
Sylvain Le Gall





-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101103143426.gi28...@yocto.gallu.homelinux.org

Bug#600408: ocaml: Building OCaml with LOCAL_CALLBACK_BYTECODE enabled

[Sylvain Le Gall]

[Ce message a aussi été publié sur gmane.test.]
On 19-10-2010, Sylvain Le Gall  wrote:
> Try to cc the bug as well as the mailing list (for the record).
>
> On 17-10-2010, Sylvain Le Gall  wrote:
>> On 16-10-2010, Guillaume Yziquel  wrote:
>>> Le Sunday 17 Oct 2010 à 00:10:41 (+0200), Stéphane Glondu a écrit :
>>>> Le 16/10/2010 23:24, Guillaume Yziquel a écrit :
>>>> > Package: ocaml
>>>> > Version: 3.12.0-1~38
>>>> > Severity: normal
>>>> 
>>>
>>>> > [...] and digging into
>>>> > the callbacks.c file, I discovered that OCaml in Debian is not built
>>>> > with the LOCAL_CALLBACK_BYTECODE macro enabled.
>>>> 
>>>> Why should it be?
>>>
>>> To me, the question is "why shouldn't it be?".
>>>
>>
>> [...]
>>
>>>> > It seems to me that the current situation might be a can of worms and
>>>> > segfaults, and I'm wondering whether it would not be a good idea to
>>>> > build OCaml with LOCAL_CALLBACK_BYTECODE enabled.
>>>> 
>>>> Where did you get that from? Is this LOCAL_CALLBACK_BYTECODE documented
>>>> somewhere? The only usage I see is in byterun/callback.c, and I don't
>>>> see why it should matter here (we are just using the standard bytecode
>>>> interpreter).
>>>
>>> Haven't found documentation on LOCAL_CALLBACK_BYTECODE anywhere. I'm
>>> stumbling on it doing painful gdb debugging.
>>>
>>> I do not think that the comments in callbacks.c are very enlightening as
>>> to the proper usage of LOCAL_CALLBACK_BYTECODE. I'm not saying that it
>>> should be changed, but I do not see why it should be kept this way.
>>>
>>
>> The effect of this seems to be quite tricky and "maybe" not worth
>> using a different set of options than the default OCaml one. Since,
>> Debian packaging do nothing to disable this macro and that upstream
>> doesn't enable it or even document it, I am not sure it is a good idea
>> to change it in Debian.
>>
>> This doesn't mean that this is not a problem and that it doesn't cause
>> segfault. I just think this issue should be dealt with upstream directly
>> so that he can integrate in OCaml 3.12.1 a sane default for this option. 
>>
>> Regards,
>> Sylvain Le Gall
>>
>>
>> -- 
>> To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>> Archive: http://lists.debian.org/slrnibligp.fmh.gil...@gallu.homelinux.org
>>
>>
>
> Regards,
> Sylvain Le Gall
>
>
> -- 
> To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/slrnibqn5c.nk3.gil...@gallu.homelinux.org
>
>

Regards,
Sylvain Le Gall



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnibqngv.r67.gil...@gallu.homelinux.org

Re: Bug#600408: ocaml: Building OCaml with LOCAL_CALLBACK_BYTECODE enabled

[Sylvain Le Gall]

Try to cc the bug as well as the mailing list (for the record).

On 17-10-2010, Sylvain Le Gall  wrote:
> On 16-10-2010, Guillaume Yziquel  wrote:
>> Le Sunday 17 Oct 2010 à 00:10:41 (+0200), Stéphane Glondu a écrit :
>>> Le 16/10/2010 23:24, Guillaume Yziquel a écrit :
>>> > Package: ocaml
>>> > Version: 3.12.0-1~38
>>> > Severity: normal
>>> 
>>
>>> > [...] and digging into
>>> > the callbacks.c file, I discovered that OCaml in Debian is not built
>>> > with the LOCAL_CALLBACK_BYTECODE macro enabled.
>>> 
>>> Why should it be?
>>
>> To me, the question is "why shouldn't it be?".
>>
>
> [...]
>
>>> > It seems to me that the current situation might be a can of worms and
>>> > segfaults, and I'm wondering whether it would not be a good idea to
>>> > build OCaml with LOCAL_CALLBACK_BYTECODE enabled.
>>> 
>>> Where did you get that from? Is this LOCAL_CALLBACK_BYTECODE documented
>>> somewhere? The only usage I see is in byterun/callback.c, and I don't
>>> see why it should matter here (we are just using the standard bytecode
>>> interpreter).
>>
>> Haven't found documentation on LOCAL_CALLBACK_BYTECODE anywhere. I'm
>> stumbling on it doing painful gdb debugging.
>>
>> I do not think that the comments in callbacks.c are very enlightening as
>> to the proper usage of LOCAL_CALLBACK_BYTECODE. I'm not saying that it
>> should be changed, but I do not see why it should be kept this way.
>>
>
> The effect of this seems to be quite tricky and "maybe" not worth
> using a different set of options than the default OCaml one. Since,
> Debian packaging do nothing to disable this macro and that upstream
> doesn't enable it or even document it, I am not sure it is a good idea
> to change it in Debian.
>
> This doesn't mean that this is not a problem and that it doesn't cause
> segfault. I just think this issue should be dealt with upstream directly
> so that he can integrate in OCaml 3.12.1 a sane default for this option. 
>
> Regards,
> Sylvain Le Gall
>
>
> -- 
> To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/slrnibligp.fmh.gil...@gallu.homelinux.org
>
>

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnibqn5c.nk3.gil...@gallu.homelinux.org

Bug#588095: downgrade severity

[Sylvain Le Gall]

severity 588095 normal
thanks

Cheers
Sylvain Le Gall



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101019074346.gf28...@yocto.gallu.homelinux.org

Re: Bug#588095: Should be grave?

[Sylvain Le Gall]

severity 588095 normal
thanks


On 18-10-2010, Ivan Jager  wrote:
> severity 588095 grave
> thanks
>
> I believe this should have been severity grave, on the basis that
> it "makes the package in question unusable or mostly so".
>
> I'd say mostly so in this case, since everything in
> /usr/share/doc/libcore-ocaml-doc/html/core-api/ is useless,
> although at least some of the files for the extended-api seems to
> have content. (Although presumably if you're using the extended
> API you're also using the core API...)
>
> If I am wrong, feel free to change it back. I don't mean to step
> on any toes, but this bug should at least get some attention
> before the release.
>

While the problem is important and make the library hard to understand,
I don't think it is a release blocking issue. The problem is taken into
account but we will deal with it after the release.

Thanks to highlight this issue, ping us again after the release of
Squeeze.

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnibqijd.rgu.gil...@gallu.homelinux.org

Re: Bug#600408: ocaml: Building OCaml with LOCAL_CALLBACK_BYTECODE enabled

[Sylvain Le Gall]

On 16-10-2010, Guillaume Yziquel  wrote:
> Le Sunday 17 Oct 2010 à 00:10:41 (+0200), Stéphane Glondu a écrit :
>> Le 16/10/2010 23:24, Guillaume Yziquel a écrit :
>> > Package: ocaml
>> > Version: 3.12.0-1~38
>> > Severity: normal
>> 
>
>> > [...] and digging into
>> > the callbacks.c file, I discovered that OCaml in Debian is not built
>> > with the LOCAL_CALLBACK_BYTECODE macro enabled.
>> 
>> Why should it be?
>
> To me, the question is "why shouldn't it be?".
>

[...]

>> > It seems to me that the current situation might be a can of worms and
>> > segfaults, and I'm wondering whether it would not be a good idea to
>> > build OCaml with LOCAL_CALLBACK_BYTECODE enabled.
>> 
>> Where did you get that from? Is this LOCAL_CALLBACK_BYTECODE documented
>> somewhere? The only usage I see is in byterun/callback.c, and I don't
>> see why it should matter here (we are just using the standard bytecode
>> interpreter).
>
> Haven't found documentation on LOCAL_CALLBACK_BYTECODE anywhere. I'm
> stumbling on it doing painful gdb debugging.
>
> I do not think that the comments in callbacks.c are very enlightening as
> to the proper usage of LOCAL_CALLBACK_BYTECODE. I'm not saying that it
> should be changed, but I do not see why it should be kept this way.
>

The effect of this seems to be quite tricky and "maybe" not worth
using a different set of options than the default OCaml one. Since,
Debian packaging do nothing to disable this macro and that upstream
doesn't enable it or even document it, I am not sure it is a good idea
to change it in Debian.

This doesn't mean that this is not a problem and that it doesn't cause
segfault. I just think this issue should be dealt with upstream directly
so that he can integrate in OCaml 3.12.1 a sane default for this option. 

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnibligp.fmh.gil...@gallu.homelinux.org

Re: Bug#599215: Homonymous modules that will conflict in META makes dh-ocaml choke.

[Sylvain Le Gall]

Hello,

On 05-10-2010, Guillaume Yziquel  wrote:
> Package: dh-ocaml
> Version: 1.0.0~6
> Severity: normal
>
>
> I've been working on an OCaml-Python binding. An I'm currently trying to 
> create
> Debian packages for it. As Python may have multiple binaries for different 
> versions
> of the interpreter, from 2.4 to 3.2, I'm trying to generate automatically 
> packages
> libpython2.4-ocaml-dev to libpython3.2-dev.
>
> As it would impossible to load simultaneously two different versions of the 
> python
> interpreter shared library, it seems natural that these different packages 
> conflict
> in META files (not in Debian's control file).
>
> However, there will be, in each of these libpythonX.X-ocaml-dev packages, an
> oCamlPython.cm[xo] binary/bytecode, without the oCamlPython.cmi file. This is 
> to
> be able to load statically the interpreter. Much like the lablgtk.init 
> findlib package.
>
> I would not like to be able to rename the oCamlPython files upstream 
> (although I will
> presumably be forced to). Keep in mind that they cannot be loaded 
> simultaneously because
> of the META file conflict. The problem is that dh-ocaml fails with
>
> dh_ocaml -s 
> E: Error: unit OCamlPython exported in libpython3.2-ocaml-dev v0.90-2 but 
> already exported by libpython-ocaml-dev v0.90-1
>

Without renaming the file, you can add a dummy function in it, that will
modify the signature and allow computation of dependencies. When
dh_ocaml compute it takes into account the module name and the hash
exported/imported.

If you add a dummy function:

let is_v2_7 = true

include Python.Interpreter (struct end)

or 

let is_v3_2 = true

include Python.Interpreter (struct end)

You should modify the signature of the module and solve the dependency
problem (and the error reported above).

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniau2gg.fmh.gil...@gallu.homelinux.org

Bug#599284: cduce: inconsistent assumption wit curl

[Sylvain Le Gall]

Package: cduce
Version: 0.5.3-2+b2
Severity: grave
Justification: renders package unusable


When trying to compile something with cduce, I get this:

File "_none_", line 1, characters 0-1:
Error: Files /usr/lib/ocaml/cduce/cduce_lib.cmxa
  and /usr/lib/ocaml/curl/curl.cmxa
  make inconsistent assumptions over interface Curl

A binNMU should be scheduled to solve this bug.

Regards
Sylvain Le Gall

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/3 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cduce depends on:
ii  libc62.11.2-6Embedded GNU C Library: Shared lib
ii  libcurl-ocaml-dev0.5.3-1 OCaml libcurl bindings (Developmen
ii  libcurl3-gnutls  7.21.1-1Multi-protocol file transfer libra
ii  libexpat-ocaml-dev   0.9.1+debian1-7 OCaml expat bindings
ii  libexpat12.0.1-7 XML parsing C library - runtime li
ii  libocamlnet-ocaml-dev2.2.9-8 OCaml application-level Internet l
ii  libpcre3 8.02-1.1Perl 5 Compatible Regular Expressi
ii  ocaml-nox [ocaml-nox-3.1 3.11.2-1ML implementation with a class-bas
ii  ocaml-ulex   1.1-2   OCaml lexer generator with Unicode

cduce recommends no packages.

cduce suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101006115033.7407.96519.report...@localhost

Re: Bug#599093: dh_ocaml: warns on not resolving dependencies on modules contained in the application

[Sylvain Le Gall]

On 05-10-2010, Stéphane Glondu  wrote:
> Le 05/10/2010 14:56, Stéphane Glondu a écrit :
>>> Ralf, do you know how to make the difference between internal/external?
>>> Can we trust that every unresolved symbols are externals?
>> 
>> How can symbols be unresolved in OCaml executables?
>
> C stubs can be "unresolved", and IIRC dh_ocaml uses dependencies between
> ocaml interfaces to find dependencies to dynamic stubs (dll*.so files).
> This approach is good to find ABI-zed dependencies, but warnings
> generated in this case won't be relevant most of the time.
>
> However, we also have access to dynamic stub dependencies in the
> bytecode executables, so I propose we still use OCaml interfaces to find
> ABI-zed dependencies, get rid of the warning for so-called "unresolved"
> symbols on the OCaml side, and issue warnings for dll*.so that cannot be
> found.
>

Fine for me. Since I added this warning, I was not sure if it was really
mandatory or not. 

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrniamb6s.fmh.gil...@gallu.homelinux.org

Re: Bug#599093: dh_ocaml: warns on not resolving dependencies on modules contained in the application

[Sylvain Le Gall]

On 04-10-2010, Ralf Treinen  wrote:
> On Mon, Oct 04, 2010 at 08:32:21PM +0200, Mehdi Dogguy wrote:
>> severity 599093 wishlist
>> tags 599093 + moreinfo
>> thanks
>> 
>> On 10/04/2010 05:41 PM, Ralf Treinen wrote:
>> > Package: dh-ocaml Version: 0.9.6 Severity: normal
>> > 
>> > dh_ocaml spits out a list of warnings concerning modules that are in 
>> > fact defined in the application program itself, which is annoying. 
>> > Example bibtex2html (which is compiled to bytecode, if that 
>> > matters):
>> > 
>> 
>> I don't know what's the purpose of this bug and how you want us to deal
>> with it. So, I'm adding appropriate tags and reducing the severity.
>> 
>> Note that those warnings are important to be sure that all external
>> modules are resolved.
>
> They are not external. They are internal to the program.
>

When implementing this warning, we don't know how to be sure that we
don't miss a dependency.

Ralf, do you know how to make the difference between internal/external?
Can we trust that every unresolved symbols are externals?

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnialt67.fmh.gil...@gallu.homelinux.org

Bug#596622: Fwd: Re: [haXe] haXe source & ocaml library extlib

[Sylvain Le Gall]

Hello,

In gmane.linux.debian.devel.ocaml, you wrote:
>
> Le 14/09/2010 22:24, Jens Peter Secher a =E9crit :
>> Hi Nicolas,
>>
>> Your ocaml library extlib seems to be distributed from both Google Code
>> [1] and from your Motion-Twin CVS repository, which gives me some
>> problems when packaging haXe 2.06 for Debian because the official
>> packaging of extlib tracks the Google Code version, not the Motion-Twin
>> one, see [2].  Do you plan to release the updated version of extlib on
>> Google Code, or should the extlib Debian package track the Motion-Twin
>> CVS instead?
>
> The current extlib status is a bit awkward : I was the main contributor=20
> and project initiator, then the project went unactive. And since it was=20
> hosted on SourceForge with many slowdowns and maintenance, I moved the=20
> repository on MT CVS. A few years after, the project was moved to Google=20
> Code by other people and might have evolved differently than my local=20
> repository.
>
> Merging both would surely be feasible but to be honest I don't have much=20
> time for it ATM.
>
> Maybe you can try to get in touch with extLib maintainers and find a way=20
> to get this done if they have interest in it.
>

Your best option right now, is to create a patch that adds the feature
you need (i.e. "the new output_strings functionality"). And submit it to
the BTS of the extlib project.

http://code.google.com/p/ocaml-extlib/issues/list

Regards,
Sylvain Le Gall



-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100915201746.ga12...@centi.ks368928.kimsufi.com

Bug#596842: libgettext-ocaml-dev not installable in sid

[Sylvain Le Gall]

Hello,


On Tue, Sep 14, 2010 at 04:12:17PM +0200, Ralf Treinen wrote:
> Package: libgettext-ocaml-dev
> Version: 0.3.3-1+b1
> Severity: grave
> User: trei...@debian.org
> Usertags: edos-uninstallable
> 
> libgettext-ocaml-dev is currently not installable in sid, probably needs
> bin-NMU due to a new version of libfileutils-ocaml-dev :
> 
> libgettext-ocaml-dev (= 0.3.3-1+b1) depends on missing: -
> libfileutils-ocaml-dev-c2hd0
> 

I just send a binNMU request.

Cheers
Sylvain Le Gall





-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100914162533.gb9...@yocto.gallu.homelinux.org

Re: overhaul of the debian ocaml policy

[Sylvain Le Gall]

On 05-09-2010, Ralf Treinen  wrote:
> Hi everybody,
>
> On Sun, Aug 15, 2010 at 10:39:06PM +0200, Ralf Treinen wrote:
>
>> I think I now have a draft of an update of our policy. This work
>> is simply a continuation of the work started by Sylvain who did already
>> the splitting in policy and reference that we had discussed earlier.
>
>> git+ssh://git.debian.org//git/pkg-ocaml-maint/packages/dh-ocaml.git
>> branch: policy-update
>
> I cannot see a consensus on the question of tagging debian-specific
> META files that was brought up by Sylvain. Hence, I did not put 
> anything on this topic in the policy for now.
>

Better than to have nothing, I think that we should use a comment at the
beginning of the META file, when it has been written by a Debian packager:

# This META file is delivered by the Debian distribution.
version = ...
description = ...

This doesn't imply non-standard field and is at least an information
about the fact upstream doesn't provide one. It is grep-able and you
can even
grep -E "^# This META File is delivered by the .* distribution\." 
which should at least partially satisfied F. Monnier.

I think it is the most reasonnable way to do things.

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrni8787r.skq.gil...@gallu.homelinux.org

Re: debian and upstream (was: overhaul of the debian ocaml policy)

[Sylvain Le Gall]

I cross-post this thread to debian-proje...@l.d.o. As Ralf Treinen said,
this is a general question rather than an OCaml specific question.

Summary:

Ralf Treinen is reviewing the OCaml packaging policy and we discussed a
point about adding features to upstream package. We would like to share
this discussion with other Debian packagers to know what is the best
practice.

Point of view 1:

We can add features to upstream software. Debian goal is to deliver
non-broken software and we should even improve it.

It includes fixing examples, documentation and the software itself. One
of the example was adding a way to detect user's locale setting which
was not accepted upstream because of portability issue on Windows.

Point of view 2:

We should limit patches to upstream software to packaging matter:
- fix the build system to make it compile on Debian
- fix security bugs

The benefit of this approach for a packager are:
- patches only apply to things most of DD or DM know: build system for
  example, so it is easier for anyone to understand the meaning of
  patches (while adding features can be tougher to understand for
  newcomers)
- patches are easier to maintain on the long-term
- no difference of behavior for the software between Linux
  distributions

We don't exclude doing more specific patches, but this should only be
temporary and hopefully immediatly sent upstream.


POV2 is a little bit more documented than POV1, because I support POV1.
Maybe Ralf or others can extend POV1. 

Thank you for giving us your opinions/best practices/experiences about
this.

Regards,
Sylvain Le Gall

On 24-08-2010, Ralf Treinen wrote:
> On Mon, Aug 23, 2010 at 03:19:21PM +0200, Stéphane Glondu wrote:
>> Le 23/08/2010 11:13, Ralf Treinen a écrit :
>> >>>> Whenever you patch the source, IMHO, you limit the patch to:
>> >>>> - fix the build system to make it compile on Debian (source -> binary
>> >>>>   package, new OCaml version)
>> >>>> - fix security bugs
>> >>>
>> >>> Certainly not. We do add features (I am speaking here of debian packages
>> >>> in general, not only of ocaml libraries), and we fix things that are
>> >>> broken.
>> 
>> Not any feature. I would tend to agree with Sylvain on this one. It may
>> cause portability issues with non-Debian users, and can make the
>> packaging harder to maintain and update (see advi, for example).
>
> The situation with advi has improved a lot. Currently, the debian patch set
> is very small.
>
> Besides, I do not see why we shouldn't add any feature. Of course,
> we should try to cooperate with upstream and have changes integrated
> upstream, but there are various reasons why this is not possible. In that
> case, our priority should be the quality of the software provided by
> our packages. 
>
>> If the patch is committed upstream, then I guess it's ok to put it in
>> the Debian package if it is backward compatible somehow... but still,
>> care should be taken and I wouldn't do that if I wasn't following
>> upstream development more than for my average package.
>> 
>> Upstream development should be done upstream (I don't say that the
>> packager should not contribute...). A package is perfect when the
>> packaging is trivial and there are no patches.
>
> This is the ideal situation, I agree. However, there are two sides who
> have to cooperate to maintain that ideal situation.
>
> But this is really getting off topic now. This discussion would be more
> appropriate for debian-project.
>


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrni771bb.e23.gil...@gallu.homelinux.org

Re: overhaul of the debian ocaml policy

[Sylvain Le Gall]

Hello,

On 24-08-2010, David MENTRE  wrote:
> 2010/8/23 Ralf Treinen :
>> PS: I just looked up the bug report, which reveals what distro the bug
>> reporter is using.
>
> Ubuntu.
>

Nevermind, the bug report was aggressive be it from Ubuntu or
Debian user.

>>  He rather should complain to his distro when they
>> are just copying our stuff and then, on top of it, get it wrong (as I
>> deduce from the fact that he could not rebuild his package).
>
> There are no OCaml developers in Ubuntu. The bug report would come
> back to Debian. And Ubuntu people are hardly ever patching Debian
> OCaml packages 
> (https://bentobako.org/ubuntu-ocaml-status/raw/ubuntu-patches.html).
>
>Maybe some Debian developers should understand that a
> significant part of Debian OCaml work users are on Ubuntu. Rather than
> a competitor, Ubuntu offers a wider exposition to Debian Developers
> work.
>

We understand that and we (I) asked our DPL to talk about this subject
at the Ubuntu conference. Basicaly, the idea was to coordinate release
for sub-projects (like OCaml packaging) to know when to do a snapshot. I
don't know if this idea has been accepted.

But I think the problem will remain as long as their won't be an
official Ubuntu developpers attached to OCaml packages. Some people are
already doing a great share of this job though (like D. Mentre ;-)

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrni77077.e23.gil...@gallu.homelinux.org

Re: overhaul of the debian ocaml policy

[Sylvain Le Gall]

On 23-08-2010, Ralf Treinen  wrote:
> On Mon, Aug 23, 2010 at 01:30:25AM +0200, Florent Monnier wrote:
>> Le dimanche 22 août 2010 01:12:58, Sylvain Le Gall a écrit :
>> [...]
>> > > For example if we use:
>> > > origin="packaging::Debian"
>> > > origin="packaging::Mandriva"
>> > > 
>> > > then one can get the list of the added META with this single command:
>> > > $ grep -l packaging `ocamlc -where`/*/META
>> > > 
>> > > But if we use:
>> > > origin="Debian"
>> > > origin="Mandriva"
>> > > then the user has to know which distro he's using first, before to grep
>> > > it as a keyword.
>> > > and in this example you can't use "origin" as a keyword too, because you
>> > > can't prevent an upstream to use an "origin" field too, for example:
>> > > origin="janest"
>> > > OK one can grep "origin" to display its content, but not *filter* the
>> > > META files that come from packagers.
>> > > 
>> > > I hope what I mean is clearer now, is it?
>> > 
>> > Yes it is.
>> > 
>> > I propose something like:
>> > 
>> > origin = "debian-packagers"
>> > 
>> > or
>> > 
>> > createdby = "debian-packagers"
>> 
>> I find the string "debian-packagers" fine!
>
> The problem is that these strings should be removed once upstream
> incorporates the META file, which should be the ultimate goal. A string
> like "origin" is easily mistaken for "original author", and the risk
> is that people will leave them in in order to give credits.
>
> For that reason, I'll rather propose something like "meta-not-yet-upstream".
> This way it is clear when it has to be removed.
>

meta-not-yet-upstream = "debian-package-only" ?

Sending the META to upstream should be done with a 
"grep -v meta-not-yet-upstream"

We could say that this value should be one line...

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrni74gh0.e23.gil...@gallu.homelinux.org

Re: overhaul of the debian ocaml policy

[Sylvain Le Gall]

On 23-08-2010, Ralf Treinen  wrote:
> On Mon, Aug 23, 2010 at 08:56:33AM +0000, Sylvain Le Gall wrote:
>> On 23-08-2010, Ralf Treinen  wrote:
>> > On Sun, Aug 22, 2010 at 03:07:02PM +0000, Sylvain Le Gall wrote:
>> >> On 22-08-2010, Ralf Treinen  wrote:
>> >
>> > [...]
>> >> > What is the reason to mandate a special field or comment in the META
>> >> > field when it is created by debian? We are patching sources all the time
>> >> > both for end user applications and develpment packages, without 
>> >> > attaching
>> >> > an extra warning sign. What makes META files so special that warrants
>> >> > an exception to that rule?
>> >> >
>> >> 
>> >> Whenever you patch the source, IMHO, you limit the patch to:
>> >> - fix the build system to make it compile on Debian (source -> binary
>> >>   package, new OCaml version)
>> >> - fix security bugs
>> >
>> > Certainly not. We do add features (I am speaking here of debian packages
>> > in general, not only of ocaml libraries), and we fix things that are
>> > broken.
>> >
>> 
>> Could you be more precise about the features we add. I don't have
>> examples in mind. I don't consider that FHS compliance is a feature for
>> example but I don't see any commmon case where Debian packagers add a
>> new function to a library.
>
> Looking through the hevea changelog:
>
>   * Modify hevea and imagen such that pictures are by default generated in
> png instead of gif. Added options -gif to hevea and imagen for generation
> of gif. Modify man pages accordingly.
>
> For that one we even had a discussion on this mailing list whether we
> should stay with png even when the gif patent expired (the answer was yes)
>
>  * removed spurious space in the definition of \cyan in html/color.hva
> (patch sent in by Salvador Abreu  - thanks!).
> Closes: Bug#136243.  
>
>  * Added an option "-charset" to specify the charset to be printed in the
> META tag. The default is the output of "locale charmap"
> (closes: Bug#165447) .
>
>  * Don't insert a full stop in info output after reference "Up: (dir)"
> (file: infoRef.mll, closes: Bug#179377).
>
>  * Installed improved imagen script by Francois-Rene Rideau
> .
>
> and more. We also have improvements of documentation, additions of
> examples, and so on. The bug fixes and the code are communicated to
> upstream, who usually will use them (but a fixed release will be 
> published much later), or something doesn't agree.
>

Are you not afraid of portability problem with other distro not shipping
these changes?

Doc and examples are ok because they don't imply incompatibilities. I am
always afraid of mixing packager/upstream task...

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrni74g7e.e23.gil...@gallu.homelinux.org

Re: overhaul of the debian ocaml policy

[Sylvain Le Gall]

On 23-08-2010, Ralf Treinen  wrote:
> On Mon, Aug 23, 2010 at 08:56:33AM +0000, Sylvain Le Gall wrote:
>
>> At the beginning, I was adding wrapper scripts to mldonkey
>> (create/delete users, set password) and I had been criticized for this
>> because I was adding too advanced features...
>
> Criticized by whom? Did you give in? 
>

My preferred one:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484674


 * Why all of the Debian-specific utilities in debian/utils?  This is
  just vanity.  Please, ship the upstream software, not your own.


At this time, I was in the process to give maintainership to Mehdi, so
he probably closed this bug.

This is probably not the vast majority of users. But there is a little
truth in what he said. Sharing patches is very important and we should
try to automate this as much as possible.

The field I propose can be a way to automatically send it to upstream
authors. This is just an idea, don't know if it is worth.

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrni74g2o.e23.gil...@gallu.homelinux.org