es instead, 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 capab
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
Stefano Zacchiroli a écrit :
>> While playing with the ssl_client.ml example, I ended up correcting two
>> issues:
>> * ssl_client.ml must use:
>> let cl_ctx = Ssl.create_context Ssl.TLSv1 Ssl.Client_context in
>> to use the correct function from ocaml-ssl
>> * The example segfaulted..
>
>
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:
http:
[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
Depends:
ocam
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.
w version of OCaml has been 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 thos
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
dependencie
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
gath
.deb: package says priority 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
n 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
-BEGI
Romain Beauxis wrote:
>>> Does anyone understand the report ?
>>> http://experimental.debian.net/fetch.php?&pkg=findlib&ver=1.2.1-4%7Ebpo40
>>> %2B1&arch=powerpc&stamp=1207867698&file=log&as=raw
>> Probably the same problem you could have with experimental
>
> Doesn't happen on experimental:
> htt
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
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
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:
http://glondu.net/debian/pool/experi
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=file&rev=0&sc=1
It successfully generated the following repos:
http://git.debian.org/
in git:
> http://git.debian.org/?p=pkg-ocaml-maint/packages/ocaml-dbus.git;a=summary
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 wi
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 w
ll be no longer 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]
heers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ubs.so):
Also fixed in svn.
Thank you 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
iD8DBQFIRBthBg8odvzgPaoRAmgiAJ4qEGtrvZCwTiVd
ocaml-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
n it, with "sudo ocsigen -V". You 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
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 PR
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 sc
Julien Cristau a écrit :
The following commit has been merged in the master branch:
commit c8bdd9e0fc12634749a2d0c7c5f678c49f7747dc
Author: Stephane Glondu <[EMAIL PROTECTED]>
Date: Tue Jul 8 13:56:53 2008 +0200
Copy config.{sub,guess} in pre-config phase instead of clean
Why?
Because
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 patches
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' fail
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
s
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
shellscript
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=1&rev=5877
> Log:
> [svn-buildpackage] Tagging camlpdf (0.3-3)
>
> Added:
> tags/packages/camlpdf/0.3-3/
> - copied from r5876, trunk/pa
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/
> histo
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 new-d-
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
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 setu
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 releas
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 subj
code to the -custom case.
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
n be used for an even better patch IMHO (probably trivial to
implement for perl gurus, 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
ion must have added some fuzz in the mess.
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
@"; done|grep 'Force custom: YES'
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, em
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
sh
/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
h or closed if not relevant any more.
Cheers,
--
Stéphane Glondu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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:
ec
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 t
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
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 ca
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
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 (>
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. Runn
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:
*
[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 PROTE
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
> /usr/lib/apac
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 c
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
> sy
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". Trou
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 i
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.
> Rejecte
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 p
heers,
--
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 erro
dep on, say, ocaml-nox (>= 3.11), even 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...@li
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-
lgl is in B but not in A
Note 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
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 u
f action to follow?
If you want to test/use 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 Glo
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 "unsubscr
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, sinc
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 alr
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
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 i
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
1 - 100 of 2275 matches
Mail list logo
