, or at least this possibility should be allowed and
explicitly mentioned in the policy.
Cheers,
--
Stéphane Glondu
Sven Luther a écrit :
If ocaml dynamic linking is now going to happen, the policy should be
adapted, and the separation will always be that whatever is needed at
runtime goes into the * package, and what is needed only at build time,
should go into the -dev packages.
This is what I thought.
Stefano Zacchiroli a écrit :
The above distinction leaves out bytecode objects and native code
objects; we currently ship both in libxxx-ocaml-dev. I find Stéphane
reasoning convincing on the point that bytecode objects should be part
of libxxx-ocaml. In a future where OCaml gains the
Stefano Zacchiroli a écrit :
In an ideal scenario, OCaml would work precisely as it does now for the
programmer, but store in the finally linked executables and libraries
only references to objects that will then be loaded dynamically at
runtime. If that were true, than your analogy with C
Stéphane Glondu a écrit :
[...] removing the others from build_order.txt
gives the file attached to this mail.
Oops... I forgot the attachment.
--
Stéphane
binNMU.txt
Description: application/pgp-keys
Stefano Zacchiroli a écrit :
[...] Better would be to write a script which
parses the information we already have about OCaml-related packages and
generate the needed lines to be inlined in the email.
I've written a script gen-binNMU-request.py (see svn) to generate these
lines from:
[EMAIL PROTECTED] a écrit :
Package: ocaml
While bytecode linking with the graphics library I got the following error.
Installing libx11-dev fixed it.
/usr/bin/ld: cannot find -lX11
% apt-cache depends ocaml
ocaml
Depends: ocaml-base
Depends: ocaml-base-3.10.0
ocaml-base
Stefano Zacchiroli a écrit :
What about screen scraping our status page? Alternatively, if you
prefer, I can put on line side by side to it a more machine
interpretable version of it (plain text, record oriented, tab-separated
or something such). What about it?
Ok, I took it into account.
released, and the migration to this new
version is ongoing. As a consequence, all ocaml-dependant packages in
unstable are uninstallable until they are rebuilt.
Cheers,
--
Stéphane Glondu
Julien Cristau a écrit :
Note that all architectures are not listed for each package: I took
archs where at least one binary package exists (or all if one
arch-independant binary package exists).
arch-independant packages are not rebuilt by binary NMUs, so you should
ignore those
Stefano Zacchiroli a écrit :
- Stephane, can you please fix the script?
Done.
--
Stéphane
Steve Langasek a écrit :
BinNMUs scheduled [...]
Rebuilding of ocamlnet failed. As far a I can tell, the reason is
ocamlnet depends on lablgtk2 and pcre-ocaml, but these dependencies do
not appear in http://pkg-ocaml-maint.alioth.debian.org/build_order.txt.
This seems to be the main blocker so
Stephane Glondu wrote:
I've investigated why build_order.txt was broken instead of using
directly the .dot file because the .dot file also seemed to be broken to
me... I will wait for an answer before going further...
Concerning the .dot file: build-dep-graph.py didn't handle well
Paolo Donadeo a écrit :
I recently updated my Debian box to OCaml 3.10.1. The Cryptokit library
stopped to work correctly, as it seems to be compiled without zlib
support. On my machine the following simple OCaml program compiles but
raises the Cryptokit.Compression_not_supported exception,
The problem was due to the CFLAGS parameter being (re-)defined in cdbs
makefiles, overriding the value computed by upstream's own Makefile.
It is now fixed in svn.
Cheers,
--
Stéphane
Stefano Zacchiroli a écrit :
[...] Settled them we can then prod the release managers asking them
whether it would be fine or not to go ahead with another binNMU-based
transition for OCaml 3.10.2, I frankly hope so.
I've updated the binNMU-generation script with all the suggestions I've
is optional,
override says extra.
The priority has been raised to optional on purpose, because ocsigen
(which is optional) depends on libsqlite3-ocaml-dev.
Cheers,
--
Stéphane Glondu
signature.asc
Description: OpenPGP digital signature
and ocaml-csv packages[1]. I also
contribute to many other packages maintained by the Debian OCaml
Team, and have write access to their repository.
[1] http://qa.debian.org/[EMAIL PROTECTED]
I am looking forward to becoming a Debian Maintainer.
Best regards,
- --
Stéphane Glondu
-BEGIN PGP
Romain Beauxis wrote:
Does anyone understand the report ?
http://experimental.debian.net/fetch.php?pkg=findlibver=1.2.1-4%7Ebpo40
%2B1arch=powerpcstamp=1207867698file=logas=raw
Probably the same problem you could have with experimental
Doesn't happen on experimental:
Romain Beauxis wrote:
I would propose to use versioned depends inside each binary package generated
by ocaml, that means for instance:
Depends: libc6 (= 2.7-1), libx11-6, ocaml-base-nox-3.10.1
replaced by
Depends: libc6 (= 2.7-1), libx11-6, ocaml-base-nox (= 3.10.1)
What do you think ?
Romain Beauxis wrote:
These are internal dependencies between ocaml-base and ocaml-nox packages.
ocaml-base depends on ocaml-nox-3.10.1 and I propose to change it to strict
versioned dependency since all these packages are built together, and also
because = 3.10.1 doesn't prevent 3.10.2 for
package libocamlnet-ocaml-dev
tags 475933 + unreproducible
thanks
Romain Beauxis wrote:
Apparently, ocamlnet fails to build with ocaml 3.10.2:
I've just compiled ocamlnet and its dependencies (in experimental)
without problem. The .debs are available there:
David MENTRE wrote:
Maybe libmlpcap-ocaml-dev should depend on libffcall1-dev? Is this
a bug or expected behaviour?
I think this is a bug. It is fixed in svn.
Cheers,
--
Stéphane
Mehdi Dogguy wrote:
Oh cool ! I'll put it then in the svn repository.
Maybe git instead?
--
Stéphane
Hello,
I've written (yet another) svn2git migration script¹ specialized for our
svn layout, that handles upstream branches.
¹
http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/tools/svn2git/glondu_svn2git.py?op=filerev=0sc=1
It successfully generated the following repos:
Jérémie Dimino has been working on this for a while, you might be
interested:
http://dimino.org/cgi-bin/darcsweb.cgi?r=obus;a=summary
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Stefano Zacchiroli wrote:
The idea is then to start doing sourceful uploads Sunday (better
Monday). Uploads should be done with a bit of care respecting build-dep
order and delaying dependent packages by one day (using delayed queues).
As tested with the last transition we will upload only
Romain Beauxis wrote:
http://wiki.debian.org/Teams/OCamlTaskForce/Transition3-10-2
I have a package with a pending bugfix that I would like to update during the
transition, how does this cope with binNMU ?
Does it introduce a binary incompatibility? If it doesn't, maybe it
would be wiser
Stefano Zacchiroli wrote:
On Sun, May 18, 2008 at 11:20:56AM +0200, Stéphane Glondu wrote:
I've written a wiki page with the process as I see it:
http://wiki.debian.org/Teams/OCamlTaskForce/Transition3-10-2
Thanks for this.
I don't get why you mention that camlp5 will FTBFS with the new
automatically upgraded.
(b) anything I can do to help get camlidl updated more quickly?
No.
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
for pointing this out!
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ia64 m68k mips mipsel powerpc s390 sparc
ocsigen dep-wait libsqlite3-ocaml-dev (= 1.2.0-1)
Thanks,
- --
Stéphane Glondu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIRBthBg8odvzgPaoRAmgiAJ4qEGtrvZCwTiVd3LA
-sqlite3 1.2.0, 2, alpha amd64 arm
armel hppa i386 ia64 m68k mips mipsel powerpc s390 sparc
ocsigen dep-wait libsqlite3-ocaml-dev (= 1.2.0-1)
Thanks,
--
Stéphane Glondu
signature.asc
Description: OpenPGP digital signature
may want to
change the port in /etc/ocsigen/ocsigen.conf (80 by default). If there
is no suspicious error message (especially concerning sqlite3), it
should be ok.
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Hi,
I have packaged lwt (see #487997) for Debian and I am looking for
someone to review and sponsor it. It is currently available as a git
repository at the team's location:
http://git.debian.org/?p=pkg-ocaml-maint/packages/lwt.git
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL
Stéphane Glondu a écrit :
The new release of ocaml-sqlite3 (1.2.0) invalidates some interfaces
that are used by ocsigen. Therefore, ocsigen must be rebuilt against
this new version.
ocsigen_1.0.0-1, Rebuild with ocaml-sqlite3 1.2.0, 2, alpha amd64 arm
armel hppa i386 ia64 m68k mips mipsel
Adeodato Simó a écrit :
I guess, then, that we can get away with the binNMU this time, but if
ocaml-sqlite3 changes again, a Conflicts against ocsigen would be
appropriate, could you take care of that, if the day arrives?
I will.
binNMU scheduled, anyway.
Thank you!
Cheers,
--
Stéphane
Hello,
I delved into OCaml packaging svn history and decided it was too complex
for a fully automated conversion keeping all the DAG-ish history.
Therefore, I modified my svn2git script so that it generates shell
scripts from svn log (XML) output. I then tuned the shell scripts for
this specific
Stefano Zacchiroli a écrit :
I delved into OCaml packaging svn history and decided it was too complex
for a fully automated conversion keeping all the DAG-ish history.
Therefore, I modified my svn2git script so that it generates shell
scripts from svn log (XML) output. I then tuned the shell
Rémi Vanicat a écrit :
When using rebase, one lose the history of the patch. One important
role of our VCS is to save this history, so i prefer to not use rebase
like that.
I beg to differ. Could you elaborate on this? IMHO, using rebase is the
cleanest way I've seen so far to maintain
Debian Installer wrote:
Rejected: md5sum for
/srv/ftp.debian.org/ftp/pool/main/l/lwt/lwt_1.1.0.orig.tar.gz doesn't match
lwt_1.1.0-2.dsc.
Rejected: size for
/srv/ftp.debian.org/ftp/pool/main/l/lwt/lwt_1.1.0.orig.tar.gz doesn't match
lwt_1.1.0-2.dsc.
Rejected: 'dpkg-source -x' failed for
Archive Administrator a écrit :
Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
findlib_1.2.1-5~ppa1.dsc
This looks like an upload, but a .changes file is missing, so the job
cannot be processed.
Don't bother, it's my fault.
--
Stéphane
--
Julien Cristau wrote:
Another reason would be because it is somehow
an unannounced (i.e. not in debian/patches) patch to upstream sources.
I don't understand that.
The explanation of Lintian tag patch-system-but-direct-changes-in-diff
summarizes my point.
Cheers,
--
Stéphane
Stefano Zacchiroli wrote:
After that, Stephane please remove the ocaml/ directory from svn ...
Now, git-buildpackage followed by debclean leaves a clean repository.
So I guess it's ok now to remove the ocaml/ directory from svn...
--
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Hi,
I am planning to package the upcoming (8.2) version of Coq (for
experimental). Several beta versions have already been released since
mid-June.
Since the move to git is kind of official now, I've first migrated the
existing repository to git. For this one also, I had to generate a
Eric Cooper wrote:
But when I try to run git-buildpackage, it doesn't check out the
upstream (master) source; it just runs debuild in a directory with
only debian/ in it, which of course fails. What am I missing?
git-buildpackage expects a branch with upstream and debian/ merged. It
uses
[EMAIL PROTECTED] wrote:
Author: toots
Date: Wed Jul 23 21:08:34 2008
New Revision: 5877
URL: http://svn.debian.org/wsvn/pkg-ocaml-maint/?sc=1rev=5877
Log:
[svn-buildpackage] Tagging camlpdf (0.3-3)
Added:
tags/packages/camlpdf/0.3-3/
- copied from r5876,
Stéphane Glondu a écrit :
[...] IIUC, you want to
de-debian-nativify it, and in the process, you want to remove all
history concerning debian/? How do you plan to keep a meaningful history
of debian packaging? It doesn't sound easy to me to plug the debian/
history into the upstream history
Eric Cooper wrote:
Thank you very much, Stéphane. That looks much better than my
attempt, so I've copied it to the official (pkg-ocaml-maint/packages)
location and will push further development there. Feel free to remove
your test/ copy.
What do you mean by copy? Did you use the
Stefano Zacchiroli wrote:
Personally, I love having a branch where I can plain directly with the
patched code, as it is an all win: code is ready to read / work on,
patches are stored as feature branches. I usually call it plainly
master, but it can well be upstream+patches, I've seen him in
Eric Cooper wrote:
So I did this using my tool, and I got this: [...]
I forgot to mention, your tool did a much better job than git-svn --
does it make sense to make it more widely available, or offer it as an
improvement to the git-svn maintainers?
My tool is very specific to our setup. At
Stefano Zacchiroli a écrit :
Just to let you know Fedora found a conflict with /usr/bin/parser from
Coq from another (non-OCaml) package, so we asked upstream Coq if
they could change the name of this program to be less generic, and
they have agreed to change it to coq-parser in the next
Debian Installer wrote:
Rejected: dm:[EMAIL PROTECTED] may not upload/NMU source package coq
It seems DM-Upload-Allowed doesn't have any effect in experimental...
Could someone be kind enough to upload it for me?
Thanks,
--
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
.
Attached is a patch (against OCaml 3.10.2) that implements this idea.
Any opinion?
Cheers,
--
Stéphane Glondu
From f574009ac90e3ea9b6d113fb7e98fa623e74aa84 Mon Sep 17 00:00:00 2001
From: Stephane Glondu [EMAIL PROTECTED]
Date: Sun, 17 Aug 2008 17:10:03 +0200
Subject: [PATCH] Embed bytecode in C object
, so I let them do so). But keep in mind that
Lintian would complain more during OCaml migrations.
This information can be useful to readers of bug #476417, so I also
CC'ed it.
Cheers,
--
Stéphane Glondu
signature.asc
Description: OpenPGP digital signature
.
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Julien Cristau wrote:
* debian/control: Add dependency ocaml-base | ocaml, to provide a real
package alternative to ocaml-base-$ABI, and satisfy lintian.
I'm not sure this change is correct, for what it's worth. lintian is
buggy there, and the ocaml interpreter needs to be the same
'
returns:
/usr/lib/ocaml/3.10.2/bjack/bjack.cma: Force custom: YES
/usr/lib/ocaml/3.10.2/ssl/ssl.cma: Force custom: YES
/usr/lib/ocaml/3.10.2/ssl/ssl_threads.cma: Force custom: YES
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe
The outcome of the discussion seems pretty clear now. I am cloning this
bug and reassigning to dh-ocaml as a reminder to update our policy.
--
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Richard Jones wrote:
Thanks, Richard and Dario, for help. The problem is actually the
absence of .cma, .cmxa and .a files in the Debian package. Downloading
the original source package [1] I found that the problem is present in
the source distribution itself. I'll send a note to Julien
Richard Jones wrote:
Hmmm -- shouldn't ocamlfind ... -package calendar pick this up?
It does. Actually, I think the problem is in PGOcaml itself (I've faced
a similar situation with nurpawiki): the compilation of each module
succeeds because .cmi files for each submodule are there (maybe they
/0.4.2-4, 1, alpha amd64 arm
armel hppa i386 ia64 m68k mips mipsel powerpc s390 sparc
ocsigen dep-wait ocaml-ssl (= 0.4.2-4)
Thanks,
--
Stéphane Glondu
signature.asc
Description: OpenPGP digital signature
if not relevant any more.
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
at this. In the
meantime, I'll try to use my Gmail account (sigh).
Have you tried:
http://lists.debian.org/whitelist/
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Eric Cooper wrote:
2. Figure out by hand which OCaml libraries need to be installed for
their runtime DLLs, and use conditional Makefile hackery to add them
to the Depends on bytecode-only archs. This is optimal but very
error-prone.
You can conditionally do something like this:
echo
Eric Cooper wrote:
2. Figure out by hand which OCaml libraries need to be installed for
their runtime DLLs, and use conditional Makefile hackery to add them
to the Depends on bytecode-only archs. This is optimal but very
error-prone.
You can conditionally do something like this:
echo
Stefano Zacchiroli wrote:
I would like to try out OCaml 3.11 in Debian as long as we have a
beta, and of course before the official release. It would boil down to
update the current packaging (now in git) for the new upstream
version, build the package, (maybe upload to experimental,) and
Stéphane Glondu wrote:
I would like to try out OCaml 3.11 in Debian as long as we have a
beta, and of course before the official release. [...]
I will have a look.
I have updated the ocaml source package. To build it, use:
git-buildpackage \
--git-pristine-tar \
--git-debian
Julien Cristau a écrit :
- I am not sure about call_ld_with_proper_flags.dpatch;
Meaning? [...]
I meant: I am not sure to have updated this patch properly.
[...] The idea here is that you can't pass the same flags to ld and
gcc, and ocamlopt sometimes uses one and sometimes the other,
Stefano Zacchiroli a écrit :
- .cmxs from ocaml are installed with ocaml-nox: they should be
elsewhere;
You mean that they should be elsewhere wrt #500036, right?
Yes. They should probably be with *.so, i.e. in ocaml-base-nox, along
with the corresponding *.cma.
If this is the case
Stefano Zacchiroli a écrit :
A new version of camlp5, compatible with 3.11, has been released. I will
package it later (and resume building other packages that depend on it)
if nobody else does it.
Thanks, but that definitely something less urgent that what was OCaml
itself. Even if there
Adeodato Simó a écrit :
The ocsigen package was affected by this bug. Please schedule a binNMU
for it on all architectures:
ocsigen_1.1.0-1, Rebuild against ocaml-ssl/0.4.2-4, 1, alpha amd64 arm
armel hppa i386 ia64 m68k mips mipsel powerpc s390 sparc
ocsigen dep-wait ocaml-ssl (= 0.4.2-4)
Dave Benjamin a écrit :
I installed libapache2-mod-ocamlnet and enabled the module using a2enmod
netcgi_apache. Apache 2 no longer starts, printing this message instead:
[...]
I tried to resolve the problem by:
1. Saving /usr/lib/ocaml/3.10.2 to /etc/ld.so.conf.d/ocaml.conf
2. Running
Stefano Zacchiroli wrote:
Alternatively, we can try adding an RPATH to
/usr/lib/apache2/modules/mod_netcgi_apache.so pointing to `ocamlc
-where`.
I got a bit rusty on the rpath issue [1,2], but I do think that in
this case it would be acceptable.
I agree, given that:
* we
[sorry for coming after the battle]
Luk Claes wrote:
t-p-u is a workaround so should only be used if unstable is no option.
So if posssible, please use use unstable.
Actually, there might be a problem because of libpcre3...
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL
Dave Benjamin wrote:
[...] I still can't get Apache to start:
$ sudo /etc/init.d/apache2 start
Starting web server: apache2apache2: Syntax error on line 187 of
/etc/apache2/apache2.conf: Syntax error on line 1 of
/etc/apache2/mods-enabled/netcgi_apache.load: Cannot load
Dave Benjamin wrote:
Maybe your system is not up-to-date w.r.t other (non-OCaml-related)
packages? Or there is some bad interaction with another Apache module?
I upgraded all of my Apache 2 packages to the latest versions and
disabled every module, re-enabling them one-by-one until I could
forwarded 504348 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504348
thanks
[NOTE: bug cloned, reopened and reassigned to ocaml]
Julien Cristau wrote:
Why do we care? The proper fix is easy enough, just add -lm to the
linker command line (libcamlrun_shared.so seems to also reference
Guido Guenther wrote:
+Vcs-Browser: http://git.debian.org/git/pkg-ocaml-maint/packages/virt-mem.git
Wouldn't
http://git.debian.org/?p=pkg-ocaml-maint/packages/virt-mem.git
be better?
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Romain Beauxis a écrit :
Sorry if I ask a dummy question, but I would like to be sure:
Is it fine to update and upload some of our packages to build against 3.11 in
experimental ?
I think you have to make an explicit dependency to ocaml (= 3.11) to
make the buildd daemons use the version in
Debian Installer wrote:
Rejected: md5sum for
/srv/ftp.debian.org/ftp/pool/main/f/findlib/findlib_1.2.1.orig.tar.gz doesn't
match findlib_1.2.1-6.dsc.
Rejected: size for
/srv/ftp.debian.org/ftp/pool/main/f/findlib/findlib_1.2.1.orig.tar.gz doesn't
match findlib_1.2.1-6.dsc.
Rejected:
Romain Beauxis a écrit :
A new upstream version (5.10) of camlp5 is available.
...and has been packaged for a while in our git repos...
This release adds support for ocaml 3.11, which will be
the default in sid, and is already available in experimental.
It would be nice to prepare a
,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Richard Jones wrote:
coq
--
Strange camlp4 problem, not yet resolved. Maybe just a missing
BuildRequires:
OCAMLClib/pp.mli
OCAMLC4 lib/pp.ml4
sh: camlp4o: command not found
File lib/pp.ml4, line 1, characters 0-1:
Error: Preprocessor error
This is
if there are
no 3.11-specific features in use? I guess it's better for
autobuilders, worse for backporters -- are there other reasons?
You guess right.
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
Goswin Brederlow a écrit :
Package: ocaml
Version: 3.10.2-3
Severity: normal
[...]
Please forward this upstream so ocaml can be made to call the
finalizers at exit.
Why don't you submit this bug to upstream yourself?
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to debian-ocaml
that packages are progressively being migrated from svn to git. So
the locations of packages might evolve.
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Stefano Zacchiroli a écrit :
Please forward this upstream so ocaml can be made to call the
finalizers at exit.
Why don't you submit this bug to upstream yourself?
This is not such a nice answer, don't you think? :)
Sorry, I didn't mean to offend/criticize. But it seemed weird to me that
the
Stefano Zacchiroli a écrit :
Proposal ahead. What if we provide a symbolic link as follows:
`ocamlc -where`/site-lib - `ocamlc -where`
?
I am not so fond of this. IMHO, Makefiles should be made in such a way
that changing the location of an installed library is easy (for example,
by using
pgocaml right now, you can make it work by
adapting pgocaml with the new API (pretty trivial, a few open at
beginning of .ml files should do it). Hints given in the mails you
quote. Maybe it is already done in upstream VCS.
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to debian-ocaml-maint
Richard Jones a écrit :
https://bugzilla.redhat.com/show_bug.cgi?id=478782
The same applies to the Debian package, BTW. And of course,
calendarLib.cmi must be installed.
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of
George Danchev a écrit :
1. apply the above mentioned patch against ocamldep as brought with ocaml-nox
package. That would be pretty dangerous, since ocaml-nox rdeps are exposed at
risk. Unlikely to be approved by the release team.
It seems the patch has already been applied upstream, since
I wrote in 4964c23c.7020...@glondu.net:
1. apply the above mentioned patch against ocamldep as brought with
ocaml-nox
package. That would be pretty dangerous, since ocaml-nox rdeps are exposed
at
risk. Unlikely to be approved by the release team.
It seems the patch has already been
Mike Furr wrote:
[things]
Obviously, I didn't see this mail when I wrote my previous one
(496548fd.2080...@glondu.net).
1) Remove ocamldep-omake from the package since it is not used by omake
itself. This may impact users who otherwise invoke it themselves (for
historical reasons).
This is
Evgeni Golov a écrit :
Did you also remove the binary from the .orig.tar.gz? We don't have the
source for it...
No, I didn't. Even though the source is not technically available (in
the archive, today), there is an advertised way to rebuild it with only
free tools... IMHO, it is not the same
Evgeni Golov a écrit :
BTW, there are many things that shouldn't be in the .orig.tar.gz (such
as CVS directories, for a start)... For future releases, it might be
relevant to repackage the upstream tarball.
Yupp, but thats a different issue, not relevant here and now :)
Sorry for the
George Danchev a écrit :
I strongly believe that removing 0.9.8.5-3-3 from both lenny and sid is the
way to go, since such a insane package as have been put together should have
never been uploaded to the archive in the first place [1]. Then prepare a new
and fixed package (sane orig.tar.gz
Florent Monnier a écrit :
I am a very new packager for Mandriva, and discovered that one can package
for
Mandriva even if he's not a Mandriva user because there are test machines on
which we can log on through ssh to do the tests and submit the package.
So my question is
is it possible
Alain Frisch a écrit :
Just so you can coordinate your efforts: I think Stéphane Glondu was
also working on extracting a clean patch against OCaml.
I've made significant progress today. I think I will also have a
candidate very soon, but since I've already started with a different
packaging
1 - 100 of 2165 matches
Mail list logo
