En réponse à Sven LUTHER [EMAIL PROTECTED]:
Hello Jerome.
Hello,
There was a question about cameleon compilation on debian on the
caml-list today, about someone who is not able to build cameleon on a
unstable debian system. Here is what he says :
I followed the instructions in the
En réponse à Jérôme Marant [EMAIL PROTECTED]:
I'm going to answer him this afternoon (I don't have currently
a copy of his message).
Well, I managed to answer :-)
Cheers,
--
Jérôme Marant [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://marant.org
--
To UNSUBSCRIBE, email to
On Wed, Oct 09, 2002 at 10:02:48AM +0200, Jérôme Marant wrote:
En réponse à Sven LUTHER [EMAIL PROTECTED]:
Hello Jerome.
Hello,
There was a question about cameleon compilation on debian on the
caml-list today, about someone who is not able to build cameleon on a
unstable debian
En réponse à Sven LUTHER [EMAIL PROTECTED]:
The packages are ready. I'm justing doing some bits of extra testing
before I upload them on a stagging area.
Mmm, why not in unstable directly ?
Because configwin needs to be removed from the archive first since
cameleon provides it.
Cheers,
On Wed, Oct 09, 2002 at 12:59:23PM +0200, Sven LUTHER wrote:
What as that to do with it ?
The problem is that the name of the already uploaded version of
configwin is the same as the name of the package that will be provided
by cameleon (with name I mean name of the binary package).
So
On Wed, Oct 09, 2002 at 01:38:02PM +0200, Stefano Zacchiroli wrote:
On Wed, Oct 09, 2002 at 12:59:23PM +0200, Sven LUTHER wrote:
What as that to do with it ?
The problem is that the name of the already uploaded version of
configwin is the same as the name of the package that will be
En réponse à Sven LUTHER [EMAIL PROTECTED]:
What as that to do with it ?
I had ocaml providing ocamltk in the archive long before ocamltk was
finally removed. The pool mechanism can handle that, no problem.
Just do a Provides, conflict and replaces configwin, and everything
will
be
On Wed, Oct 09, 2002 at 02:02:12PM +0200, Jérôme Marant wrote:
En réponse à Sven LUTHER [EMAIL PROTECTED]:
What as that to do with it ?
I had ocaml providing ocamltk in the archive long before ocamltk was
finally removed. The pool mechanism can handle that, no problem.
Just do a
En réponse à Sven LUTHER [EMAIL PROTECTED]:
Well, no. It is quite different here. I do build a
libconfigwin-ocaml-dev package from the cameleon source
and such a package already exist in the
archive and is built from the configwin source.
But if you don't release a newer version of
On Wed, Oct 09, 2002 at 02:12:26PM +0200, Jérôme Marant wrote:
En réponse à Sven LUTHER [EMAIL PROTECTED]:
Well, no. It is quite different here. I do build a
libconfigwin-ocaml-dev package from the cameleon source
and such a package already exist in the
archive and is built from
Jérôme Marant [EMAIL PROTECTED] writes:
(That said, you can do all that and upload to a staging area all the
same).
I also want to ensure everything works fine before uploading: people
will be able to test and report remaining bugs.
Isn't what unstable is made for ?
--
Rémi
En réponse à Sven LUTHER [EMAIL PROTECTED]:
I'm pretty sure that katie would reject it because the pool is
managed through a database indexed by (at least) package name.
Not package source name ?
Both I think. The madison script works with both.
And what do you want to do, ask
En réponse à Remi VANICAT [EMAIL PROTECTED]:
Jérôme Marant [EMAIL PROTECTED] writes:
(That said, you can do all that and upload to a staging area all
the
same).
I also want to ensure everything works fine before uploading:
people
will be able to test and report remaining
On Mon, Sep 30, 2002 at 11:26:27AM +0200, Jérôme Marant wrote:
Hello,
I have almost finished the preparation of the Cameleon packages
(Thanks Dimitri Ara for upstream fixes).
However, I still have some wonderings:
- as defined by upstream, all cameleon libraries are being
En réponse à Sven LUTHER [EMAIL PROTECTED]:
Hello Jerome.
Hello,
There was a question about cameleon compilation on debian on the
caml-list today, about someone who is not able to build cameleon on a
unstable debian system. Here is what he says :
I followed the instructions in the
En réponse à Jérôme Marant [EMAIL PROTECTED]:
I'm going to answer him this afternoon (I don't have currently
a copy of his message).
Well, I managed to answer :-)
Cheers,
--
Jérôme Marant [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://marant.org
On Wed, Oct 09, 2002 at 10:02:48AM +0200, Jérôme Marant wrote:
En réponse à Sven LUTHER [EMAIL PROTECTED]:
Hello Jerome.
Hello,
There was a question about cameleon compilation on debian on the
caml-list today, about someone who is not able to build cameleon on a
unstable debian
En réponse à Sven LUTHER [EMAIL PROTECTED]:
The packages are ready. I'm justing doing some bits of extra testing
before I upload them on a stagging area.
Mmm, why not in unstable directly ?
Because configwin needs to be removed from the archive first since
cameleon provides it.
Cheers,
On Wed, Oct 09, 2002 at 11:42:24AM +0200, Jérôme Marant wrote:
En réponse à Sven LUTHER [EMAIL PROTECTED]:
The packages are ready. I'm justing doing some bits of extra testing
before I upload them on a stagging area.
Mmm, why not in unstable directly ?
Because configwin needs to
On Wed, Oct 09, 2002 at 12:59:23PM +0200, Sven LUTHER wrote:
What as that to do with it ?
The problem is that the name of the already uploaded version of
configwin is the same as the name of the package that will be provided
by cameleon (with name I mean name of the binary package).
So probably
On Wed, Oct 09, 2002 at 01:38:02PM +0200, Stefano Zacchiroli wrote:
On Wed, Oct 09, 2002 at 12:59:23PM +0200, Sven LUTHER wrote:
What as that to do with it ?
The problem is that the name of the already uploaded version of
configwin is the same as the name of the package that will be
En réponse à Sven LUTHER [EMAIL PROTECTED]:
What as that to do with it ?
I had ocaml providing ocamltk in the archive long before ocamltk was
finally removed. The pool mechanism can handle that, no problem.
Just do a Provides, conflict and replaces configwin, and everything
will
be
On Wed, Oct 09, 2002 at 02:02:12PM +0200, Jérôme Marant wrote:
En réponse à Sven LUTHER [EMAIL PROTECTED]:
What as that to do with it ?
I had ocaml providing ocamltk in the archive long before ocamltk was
finally removed. The pool mechanism can handle that, no problem.
Just do a
En réponse à Sven LUTHER [EMAIL PROTECTED]:
Well, no. It is quite different here. I do build a
libconfigwin-ocaml-dev package from the cameleon source
and such a package already exist in the
archive and is built from the configwin source.
But if you don't release a newer version of
On Wed, Oct 09, 2002 at 02:12:26PM +0200, Jérôme Marant wrote:
En réponse à Sven LUTHER [EMAIL PROTECTED]:
Well, no. It is quite different here. I do build a
libconfigwin-ocaml-dev package from the cameleon source
and such a package already exist in the
archive and is built from the
En réponse à Remi VANICAT [EMAIL PROTECTED]:
Jérôme Marant [EMAIL PROTECTED] writes:
(That said, you can do all that and upload to a staging area all
the
same).
I also want to ensure everything works fine before uploading:
people
will be able to test and report remaining
Hello again,
I forgot one item:
- currently all the cameleon packages have the same version
as cameleon, i.e. 1.1. For instance, Zoggy is version 1.1.
However, those components have their own version and their own
changelog file. Should I set the proper version to each
package (for
- create some empty directory containing only the META information
Ugly. In that case it is better just to create META.package1 ...
META.packagen and put them in a directory looked for by findlib
(e.g. /usr/lib/ocaml)
Cheers,
On Mon, Sep 30, 2002 at 12:01:56PM +0200, Claudio Sacerdoti Coen wrote:
- create some empty directory containing only the META information
Ugly. In that case it is better just to create META.package1 ...
META.packagen and put them in a directory looked for by findlib
(e.g.
On Mon, Sep 30, 2002 at 12:00:09PM +0200, Remi VANICAT wrote:
Jérôme Marant [EMAIL PROTECTED] writes:
Hello,
I have almost finished the preparation of the Cameleon packages
(Thanks Dimitri Ara for upstream fixes).
However, I still have some wonderings:
- as defined by
Hello,
Here is one answer, i'm reading all the mails abouts cameleon... more answers wil come
;-)
- currently all the cameleon packages have the same version
as cameleon, i.e. 1.1. For instance, Zoggy is version 1.1.
However, those components have their own version and their
On Mon, 30 Sep 2002 14:13:54 +0200
Jérôme Marant [EMAIL PROTECTED] wrote:
On Mon, Sep 30, 2002 at 01:57:35PM +0200, Maxence Guesdon wrote:
I can do this. However, I don't know what Maxence intends to
do with versionning.
All tools and libs should be assigned the same version
On Mon, Sep 30, 2002 at 02:22:59PM +0200, Maxence Guesdon wrote:
Hum, yes, but not for all. For example, cameleon native and bytecode versions
differ because the bytecode version allows the plug-in loading, but native version is
faster. For tools where native and byte code versions do the
Can I currently put several META files in the same directory the
way you describe here, i.e. META.zoggy, META.report and so on ?
Yes, you can.
[BTW, mine was not a suggestion to user /usr/lib/ocaml to store the
META.xxx. It was just an example. A META directory would be much better]
On Mon, Sep 30, 2002 at 02:06:00PM +0200, Maxence Guesdon wrote:
Hello again,
- what naming policy should I use for ocaml program that have
a quite generic name (for example report). Should I use
a ocaml- prefix? How do we consider a program name is
too generic?
My two
On Mon, Sep 30, 2002 at 02:24:06PM +0200, J?r?me Marant wrote:
On Mon, Sep 30, 2002 at 02:22:59PM +0200, Maxence Guesdon wrote:
Hum, yes, but not for all. For example, cameleon native and bytecode versions
differ because the bytecode version allows the plug-in loading, but native
On Mon, Sep 30, 2002 at 03:32:47PM +0200, Sven Luther wrote:
This leaves more flexibility to the user, and would allow to do a
binary:all package build even on a native code supporting arch.
Which is only true for libraries. It isn't for binaries since
standalone byteocde programs embed
On Mon, Sep 30, 2002 at 03:34:06PM +0200, Sven Luther wrote:
This is _way_ different :) I strongly agree with you about libraries.
For libraries, you have to ship both, i think the policy says this, but
i am not sure, will check.
Anyway, my concern was about binaries, not libraires.
/usr/lib/ocaml/cameleon (where cameleon libraries are being installed)
would do, right?
No, unless that directory is added to the path in /etc/ocamlfind.conf.
Cheers,
C.S.C.
--
On Mon, Sep 30, 2002 at 03:44:49PM +0200, Sven Luther wrote:
On Mon, Sep 30, 2002 at 03:28:29PM +0200, J?r?me Marant wrote:
On Mon, Sep 30, 2002 at 03:32:47PM +0200, Sven Luther wrote:
This leaves more flexibility to the user, and would allow to do a
binary:all package build even on a
On Mon, Sep 30, 2002 at 03:39:21PM +0200, Claudio Sacerdoti Coen wrote:
/usr/lib/ocaml/cameleon (where cameleon libraries are being installed)
would do, right?
No, unless that directory is added to the path in /etc/ocamlfind.conf.
Ah OK. Thank you.
--
Jérôme Marant
--
To
Hello,
I have almost finished the preparation of the Cameleon packages
(Thanks Dimitri Ara for upstream fixes).
However, I still have some wonderings:
- as defined by upstream, all cameleon libraries are being
installed in /usr/lib/ocaml/cameleon, so how do I manage
META files?
Hello again,
I forgot one item:
- currently all the cameleon packages have the same version
as cameleon, i.e. 1.1. For instance, Zoggy is version 1.1.
However, those components have their own version and their own
changelog file. Should I set the proper version to each
package (for
Jérôme Marant [EMAIL PROTECTED] writes:
Hello,
I have almost finished the preparation of the Cameleon packages
(Thanks Dimitri Ara for upstream fixes).
However, I still have some wonderings:
- as defined by upstream, all cameleon libraries are being
installed in
- create some empty directory containing only the META information
Ugly. In that case it is better just to create META.package1 ...
META.packagen and put them in a directory looked for by findlib
(e.g. /usr/lib/ocaml)
Cheers,
Jérôme Marant [EMAIL PROTECTED] writes:
Hello again,
I forgot one item:
- currently all the cameleon packages have the same version
as cameleon, i.e. 1.1. For instance, Zoggy is version 1.1.
However, those components have their own version and their own
changelog file. Should I
Claudio Sacerdoti Coen [EMAIL PROTECTED] writes:
- create some empty directory containing only the META information
Ugly. In that case it is better just to create META.package1 ...
META.packagen and put them in a directory looked for by findlib
(e.g. /usr/lib/ocaml)
Yes I forget this
On Mon, Sep 30, 2002 at 12:01:56PM +0200, Claudio Sacerdoti Coen wrote:
- create some empty directory containing only the META information
Ugly. In that case it is better just to create META.package1 ...
META.packagen and put them in a directory looked for by findlib
(e.g.
Sven LUTHER [EMAIL PROTECTED] writes:
On Mon, Sep 30, 2002 at 12:01:56PM +0200, Claudio Sacerdoti Coen wrote:
- create some empty directory containing only the META information
Ugly. In that case it is better just to create META.package1 ...
META.packagen and put them in a directory
On Mon, Sep 30, 2002 at 12:01:56PM +0200, Claudio Sacerdoti Coen wrote:
- create some empty directory containing only the META information
Ugly. In that case it is better just to create META.package1 ...
META.packagen and put them in a directory looked for by findlib
(e.g.
On Mon, Sep 30, 2002 at 12:00:09PM +0200, Remi VANICAT wrote:
Jérôme Marant [EMAIL PROTECTED] writes:
Hello,
I have almost finished the preparation of the Cameleon packages
(Thanks Dimitri Ara for upstream fixes).
However, I still have some wonderings:
- as defined by
Hello,
Here is one answer, i'm reading all the mails abouts cameleon... more answers
wil come ;-)
- currently all the cameleon packages have the same version
as cameleon, i.e. 1.1. For instance, Zoggy is version 1.1.
However, those components have their own version and their
On Mon, Sep 30, 2002 at 02:06:00PM +0200, Maxence Guesdon wrote:
Hello again,
- what naming policy should I use for ocaml program that have
a quite generic name (for example report). Should I use
a ocaml- prefix? How do we consider a program name is
too generic?
My two
On Mon, Sep 30, 2002 at 02:18:20PM +0200, Maxence Guesdon wrote:
On Mon, 30 Sep 2002 14:13:54 +0200
Jérôme Marant [EMAIL PROTECTED] wrote:
On Mon, Sep 30, 2002 at 01:57:35PM +0200, Maxence Guesdon wrote:
I can do this. However, I don't know what Maxence intends to
do with
Hum, yes, but not for all. For example, cameleon native and bytecode
versions differ because the bytecode version allows the plug-in loading,
but native version is faster. For tools where native and byte code versions
do the same, I agree that I should only compile byt OR native. I'll
On Mon, Sep 30, 2002 at 02:22:59PM +0200, Maxence Guesdon wrote:
Hum, yes, but not for all. For example, cameleon native and bytecode
versions differ because the bytecode version allows the plug-in loading,
but native version is faster. For tools where native and byte code
Can I currently put several META files in the same directory the
way you describe here, i.e. META.zoggy, META.report and so on ?
Yes, you can.
[BTW, mine was not a suggestion to user /usr/lib/ocaml to store the
META.xxx. It was just an example. A META directory would be much better]
On Mon, Sep 30, 2002 at 02:06:00PM +0200, Maxence Guesdon wrote:
Hello again,
- what naming policy should I use for ocaml program that have
a quite generic name (for example report). Should I use
a ocaml- prefix? How do we consider a program name is
too generic?
My two
On Mon, Sep 30, 2002 at 02:24:06PM +0200, J?r?me Marant wrote:
On Mon, Sep 30, 2002 at 02:22:59PM +0200, Maxence Guesdon wrote:
Hum, yes, but not for all. For example, cameleon native and bytecode
versions differ because the bytecode version allows the plug-in
loading, but
On Mon, Sep 30, 2002 at 03:32:47PM +0200, Sven Luther wrote:
This leaves more flexibility to the user, and would allow to do a
binary:all package build even on a native code supporting arch.
Which is only true for libraries. It isn't for binaries since
standalone byteocde programs embed
On Mon, Sep 30, 2002 at 03:34:06PM +0200, Sven Luther wrote:
This is _way_ different :) I strongly agree with you about libraries.
For libraries, you have to ship both, i think the policy says this, but
i am not sure, will check.
Anyway, my concern was about binaries, not libraires.
On Mon, Sep 30, 2002 at 03:28:29PM +0200, J?r?me Marant wrote:
On Mon, Sep 30, 2002 at 03:32:47PM +0200, Sven Luther wrote:
This leaves more flexibility to the user, and would allow to do a
binary:all package build even on a native code supporting arch.
Which is only true for
/usr/lib/ocaml/cameleon (where cameleon libraries are being installed)
would do, right?
No, unless that directory is added to the path in /etc/ocamlfind.conf.
Cheers,
C.S.C.
--
On Mon, Sep 30, 2002 at 03:44:49PM +0200, Sven Luther wrote:
On Mon, Sep 30, 2002 at 03:28:29PM +0200, J?r?me Marant wrote:
On Mon, Sep 30, 2002 at 03:32:47PM +0200, Sven Luther wrote:
This leaves more flexibility to the user, and would allow to do a
binary:all package build even on a
On Mon, Sep 30, 2002 at 03:39:21PM +0200, Claudio Sacerdoti Coen wrote:
/usr/lib/ocaml/cameleon (where cameleon libraries are being installed)
would do, right?
No, unless that directory is added to the path in /etc/ocamlfind.conf.
Ah OK. Thank you.
--
Jérôme Marant
On Mon, Sep 30, 2002 at 03:39:54PM +0200, J?r?me Marant wrote:
On Mon, Sep 30, 2002 at 03:44:49PM +0200, Sven Luther wrote:
On Mon, Sep 30, 2002 at 03:28:29PM +0200, J?r?me Marant wrote:
On Mon, Sep 30, 2002 at 03:32:47PM +0200, Sven Luther wrote:
This leaves more flexibility to the
66 matches
Mail list logo
