Le 13/07/2011 21:48, Ralf Treinen a écrit :
> Should *.cmxs files (native plugins for dynamic loading) go into the
> libxxx-ocaml or into libxxx-ocaml-dev package? I haved never used them
> myself for my projects but, as far as I understand, they may be necessary
> just to execute a certain binary.
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: tyxml
Version : 1.91
Upstream Author : Thorsten Ohl, Vincent Balat, and others
* URL : http://ocsigen.org/tyxml/install
* License : LGPL
Programming Lang: OCaml
D
Le 19/07/2011 10:31, Giorgio Marinelli a écrit :
New upstream version is available: 3.12.1
We are waiting for a slot from the release team, see [1]. If you need
it, there are unofficial packages available at [2].
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633304
[2] http://ocaml.de
Hello,
I am planning to upload ocamlnet 3.3.5 to unstable as soon as ocsigen
1.3.4-2 migrates to testing (unless there is a build failure in
experimental, but things look pretty good so far [1]). A few reverse
dependencies need fixing [2], and all of them are fixed in git, except
approx, for
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: ocaml-config-file
Version : 1.0
Upstream Author : Maxence Guesdon
* URL : http://config-file.forge.ocamlcore.org/
* License : LGPL-2+
Programming Lang: OCaml
Description
tags 615991 + moreinfo
thanks
ygrek wrote:
> src/netstring/doc/INSTALL.xml describes different ways how netstring.cma
> can be linked (alas not fully correct, but still). It should be
> installed with -dev or -doc package.
Is this still relevant with ocamlnet 3.3.5?
Cheers,
--
Stéphane
--
Hello,
I've recently uploaded many packages that needed update. For packages I
don't especially care about, I make the updates "Team uploads" and don't
spend much time on them. This gives the illusion that the packages are
well maintained [0], but they definitely need more care.
At least Stefano
Package: src:liquidsoap
Version: 1.0.0~beta2.1-3
Severity: serious
Tags: sid
Hi,
Your package fails to build with ocamlnet 3.3.5 on bytecode
architectures (and armel):
Relevant part:
> E: Error: unit Netsys_pollset_win32 exported in liquidsoap-plugin-lastfm but
> already exported by libocamlnet
tags 635326 + patch
thanks
Le 25/07/2011 09:41, Stéphane Glondu a écrit :
> Your package fails to build with ocamlnet 3.3.5 on bytecode
> architectures (and armel):
>
> Relevant part:
>> E: Error: unit Netsys_pollset_win32 exported in liquidsoap-plugin-lastfm but
>
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: lablgtk-extras
Version : 1.0
Upstream Author : Maxence Guesdon
* URL : http://gtk-extras.forge.ocamlcore.org/
* License : LGPL-2+
Programming Lang: OCaml
D
Package: wnpp
Severity: normal
Hello,
Currently, galax 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 o
Package: wnpp
Severity: normal
Hello,
Currently, pxp 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
Package: src:ocaml-batteries
Version: 1.2.2-1
Severity: important
Hello,
Your package fails to build with camomile 0.8.3-1 (available in
experimental).
Relevant part of the log:
> ocamlfind ocamlc -c -package camomile,num,str -I src -I libs -I testsuite -I
> libs/estring -I build/optcomp -I src
Package: src:galax
Version: 1.1-8
Severity: important
Hello,
Your package fails to build with camomile 0.8.3-1 (available in
experimental).
Relevant part of the log:
> /usr/bin/ocamlc -w m -I . -I . -I /usr/bin/../lib/ocaml -I
> /usr/lib/ocaml/pcre -I /usr/lib/ocaml/netstring -I /usr/lib/ocaml
Package: src:ocaml-gettext
Version: 0.3.3-1
Severity: important
Hello,
Your package fails to build with camomile 0.8.3-1 (available in
experimental).
Relevant part of the log:
> make[2]: Entering directory
> `/tmp/ocaml-gettext-0.3.3/libgettext-camomile-ocaml'
> ocamlfind ocamlc -package "get
Le 31/07/2011 21:55, Hilko Bengen a écrit :
> [...] (I
> have just uploaded libguestfs and various bindings to experimental.)
AFAICT, the upstream/1.10.5 tag is missing from the git repository (I
assume you are using git-buildpackage?), and the pristine-tar branch is
not up-to-date.
Also: libgues
Le 02/08/2011 11:39, Hilko Bengen a écrit :
> It compiles with camomile 0.8, but not with 0.7. Are there any plans to
> move the newer camomile package to unstable soon?
It won't happen before the current ocamlnet cluster [1] (ocamlnet and
camomile are entangled via galax) migrates to testing. Bes
tags 524908 + moreinfo
thanks
On Mon, 20 Apr 2009 20:46:03 +0200, Oto Havle wrote:
> OCaml programs which create Cairo surfaces via Cairo_bigarray leak memory.
> Following test program reproduces the bug. The program allocates many
> 100Mb arrays, but explicit garbage collector invocation should k
tags 524908 - moreinfo
tags 524908 + confirmed
found 524908 1:1.2.0-2
thanks
Le 02/08/2011 21:52, Oto Havle a écrit :
> [...] Note that I have 32-bit system.
I didn't take this into account, and I can indeed reproduce the bug in
an up-to-date i386 sid chroot, with version 1:1.2.0-2.
Cheers,
--
tags 524908 + help upstream
thanks
Le 03/08/2011 08:22, Stéphane Glondu a écrit :
[...] Note that I have 32-bit system.
I didn't take this into account, and I can indeed reproduce the bug in
an up-to-date i386 sid chroot, with version 1:1.2.0-2.
By looking a bit deeper, I can observe
Le 27/11/2007 18:05, Thomas Fischbacher a écrit :
http://nmag.soton.ac.uk/tf/pycaml.html
This link is broken.
(Note ad Debian developers: this fixes some major memory management bugs
that can cause crashes in the original pycaml module which is in Debian,
so, ideally, our variant should event
Le 04/04/2011 17:16, Sylvain Le Gall a écrit :
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-
Le 08/08/2011 21:59, Anders Peter Fugmann a écrit :
> Apache fails to start with the follwing errors:
> [...]
Is this new with 3.3.5-3 ? Can you provide a minimal apache
configuration snippet that triggers this error?
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-ocaml-maint-requ.
tags 637147 + upstream
thanks
Le 09/08/2011 22:39, Anders Peter Fugmann a écrit :
> I replaced apache2.conf with this:
>
> LoadModule netcgi_module /usr/lib/apache2/modules/mod_netcgi_apache.so
> NetcgiLoad pcre/pcre.cma
> NetcgiLoad netsys/netsys.cma
> #NetcgiLoad netstring/netstring.cma
> #Netc
Le 10/08/2011 10:00, Anders Fugmann a écrit :
That solves the problem.
Great.
May I suggest that the file /etc/apache2/mods-available/netcgi_apache.load
provides by the debian package is updated to reflect this.
Sure. Done in git.
--
Stéphane
--
To UNSUBSCRIBE, email to debian-ocaml-ma
Package: libc6
Version: 2.13-15
Severity: normal
Hello,
The test suite of ocaml-extunix 0.0.3-1 fails on armel because the
following program:
#include
int main() {
void *buffer[100];
return backtrace(buffer, 100);
}
returns 0. It returns with a non-zero status (3 everywhere I've
Le 15/09/2010 22:17, Sylvain Le Gall a écrit :
> 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
What the status
Le 16/08/2011 16:22, Gerd Stolpmann a écrit :
I've chosen a more radical approach for a permanent resolution: The next
version of Ocamlnet will support the additional directive NetcgiRequire.
It works like "#require" in a findlib-enabled toploop. All the
NetcgiLoad directives can then be replaced
Le 23/08/2011 22:35, Hilko Bengen a écrit :
The OCaml part of febootstrap does not build on architectures without a
native code compiler:
https://buildd.debian.org/status/fetch.php?pkg=febootstrap&arch=mips&ver=3.8-1&stamp=1314125941
Apparently, OCAMLBEST has been set to "byte" by the AC_PROG_O
Le 31/08/2011 17:31, Thomas Goirand a écrit :
> I have set debian-ocaml-maint@lists.debian.org as Cc: to this email, in
> the hope that the Debian OCaml task force can have a last look on my
> work. I'd appreciate comments, and I hope I didn't do mistakes this
> time. Please keep in mind that I don
Le 09/07/2011 13:35, Stéphane Glondu a écrit :
> OCaml 3.12.1 has been recently released. It is mostly bugfixes. I've
> rebuilt all packages that depend on ocaml, and I see no blocker to
> update it in Debian. I've planified the migration at [1] (I am
> planning to update a
On 09/07/2011 05:51 PM, Stéphane Glondu wrote:
>> OCaml 3.12.1 has been recently released. It is mostly bugfixes. I've
>> rebuilt all packages that depend on ocaml, and I see no blocker to
>> update it in Debian. I've planified the migration at [1] (I am
>> plann
tags 642706 + unreproducible
thanks
Le 24/09/2011 19:53, Mònica Ramírez Arceda a écrit :
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> [...]
I cannot reproduce this. Can anyone else?
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-ocaml-maint
Le 25/09/2011 00:00, Eric Cooper a écrit :
> I get the same error. Here's what I did to reproduce it.
>
> $ apt-get source libbin-prot-camlp4-dev
> $ cd bin-prot-1.3.1/
> $ DIST=sid ARCH=amd64 git-pbuilder update
> $ pdebuild --pbuilder cowbuilder -- --basepath
> /var/cache/pbuilder/base-sid-amd
tags 642706 - unreproducible
thanks
Le 25/09/2011 15:38, Stéphane Glondu a écrit :
>> I get the same error. Here's what I did to reproduce it.
>>
>> $ apt-get source libbin-prot-camlp4-dev
>> $ cd bin-prot-1.3.1/
>> $ DIST=sid ARCH=amd64 git-pbuilder update
g
--- dash-0.5.7/debian/changelog
+++ dash-0.5.7/debian/changelog
@@ -1,3 +1,10 @@
+dash (0.5.7-1.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Revert http://thread.gmane.org/gmane.comp.shells.dash/556
+
+ -- Stéphane Glondu Sun, 25 Sep 2011 19:05:10 +0200
+
dash (0.5.7-1) uns
block 642835 by 642922
block 642706 by 642922
severity 642922 serious
thanks
Le 25/09/2011 19:28, Stéphane Glondu a écrit :
> Bugs #642706 (bin-prot FTBFS) and #642835 (sexplib310 FTBFS) can be
> fixed by reverting the patch submitted at [1]. I don't understand why.
&g
tags 642935 + pending
thanks
Le 25/09/2011 21:19, Jonathan Nieder a écrit :
> + [ Jonathan Nieder ]
> + * debian/control: add Breaks against versions of dh-ocaml that
> +relied on the ocaml{dumpapprox,plugininfo,byteinfo} tools.
> [...]
> Breaks:
> + dh-ocaml (<< 1.0.0),
> ocaml-interp (<
reassign 642730 src:ocaml-http
severity 642730 important
affects 642730 src:matita
retitle 642730 ocaml-http: should use dh-ocaml 0.9
thanks
Le 24/09/2011 21:32, Mònica Ramírez Arceda a écrit :
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> [...]
>> Error: Fi
Le 28/09/2011 02:50, Michael Moorman a écrit :
> Going to bump this bug. I've been needing to maintain a PPA version of
> Unison 2.40 to keep track with the version of my fileserver. Due to
> unison's annoying inability to sync between different minor revisions, I
> repackaged the latest Ubuntu rev
>> obus, ocaml-usb, ocsigen and js-of-ocaml).
>>
>> My GnuPG key 0x66475AAF is signed by Debian Developers, including
>> Stéphane Glondu, Enrico Zini, and others.
>>
>> I look forward to becoming a Debian Maintainer.
>>
>
> I strongly supp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 29 Sep 2011 22:56:58 +0200
Source: ocaml-http
Binary: libhttp-ocaml-dev
Architecture: source amd64
Version: 0.1.4-4
Distribution: unstable
Urgency: low
Maintainer: Debian OCaml Maintainers
Changed-By: Stéphane Glondu
Le 26/09/2011 22:44, Jonathan Nieder a écrit :
>> I beg to differ. ocamlbuild uses libc's system(), it would be insane to
>> change that. It seems that darcs is also affected. There might be also
>> more packages affected...
>
> Got it --- I'll prepare an upload reverting the "sh -c" patch.
>
> M
On 10/05/2011 11:51 PM, Stéphane Glondu wrote:
> It seems that darcs failure was unrelated. I digged a bit more, and
> found some suspicious code in ocamlbuild:
>
> http://caml.inria.fr/mantis/view.php?id=5371
>
> I still don't understand why this corner case is trigge
[CC-ing debian-devel to get more opinions]
On 10/06/2011 04:07 PM, Jonathan Nieder wrote:
>> ocamlbuild's logic is definitively incorrect, but I'm not sure if dash's
>> new behaviour is correct. "bash -c" doesn't skip fork() when a
>> redirection is set up, I guess for a reason. "dash -c" should p
Le 08/10/2011 17:07, Stefano Zacchiroli a écrit :
> given my lazy attempt to get out of various Uploaders fields of 1.5
> years ago has failed, I'm (slowly) going through packages that I haven't
> been maintaining for a while and do that.
>
> I'm writing to you because I've just done so with cam
merge 642706 642835
severity 642706 important
reassign 642706 ocaml-nox
found 642706 3.12.0-7
retitle 642706 ocamlbuild: questionable job control
forwarded 642706 http://caml.inria.fr/mantis/view.php?id=5371
affects 642706 src:bin-prot src:sexplib310
thanks
Le 16/10/2011 13:04, Jonathan Nieder a é
Le 16/10/2011 20:02, Romain Beauxis a écrit :
> I have thus commited a branch "shared" to camlidl which does the following:
> * Patch upstream to build dllcamlidl.so
> * Split binary packages in 3:
> - camlidl: binary
> - libcamlidl-ocaml: runtime files
> - libcamlidl-ocaml-dev: dev files
>
Le 17/10/2011 20:10, Loïc Minier a écrit :
> This is a tracking bug to note that ocamlgsl needs porting on armhf; it
> currently fails to build with: [...]
It doesn't build on armel either...
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with
Le 25/10/2011 16:00, Nicolas Dandrimont a écrit :
> I'm Cc:'ing the OCaml Team which may be interested in your package. I'll
> try to take a look tonight, unless someone beats me to it.
Thank you for bringing this to our attention.
>> I am looking for a sponsor for my package "ocaml-fdinfo".
>>
>
On 26/10/2011 14:17, clayton wrote:
> I have about 2G of files in my home directory, which I generally sync
> multiple times per week. Scattered throughout this 2G, dated
> throughout the life of this installation, are more then 40M of files named
> *.unison.tmp-bad, ie.
>
> ../.miro/.unison.sq
Le 02/11/2011 21:13, Gerd Stolpmann a écrit :
> First, Plasma needs an absolutely recent version of ocamlnet, i.e.
> 3.4.1. I couldn't find a repository with it.
I've just updated it (in Debian unstable).
> Second, there is the question how to get it into Debian. The dpkg is no
> problem for me a
Maintainers
Changed-By: Stéphane Glondu
Description:
coq- proof assistant for higher-order logic (toplevel and compiler)
coq-theories - proof assistant for higher-order logic (theories)
coqide - proof assistant for higher-order logic (gtk interface)
libcoq-ocaml - runtime libraries for Coq
Le 03/11/2011 22:15, Gerd Stolpmann a écrit :
> 1. The part of ocamlnet using cryptokit is missing (i.e. netmech-scram)
> 2. The part of ocamlnet using camlzip is missing (i.e. netzip)
> 3. I wonder why the *.netdb files are in libocamlnet-ocaml-dev and not
>in libocamlnet-ocaml, because there
Package: ftp.debian.org
Severity: normal
Hi,
Please remove the binary packages of ocamlgsl on mips and mipsel. They
are probably broken, and ocamlgsl does no longer build with OCaml
3.12.1 and they block the OCaml transition.
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-ocaml-mai
> will ocamlgsl on mips and mipsel be fixed sometime, so orpie will
> be available on those architectures again?
Actually, ocamlgsl compiles with no error when the #error directive is
commented out. There is a "make test" target, but it uses an unknown
"fort" command... and even so, the test-suite
On 05/24/2011 11:41 AM, Stéphane Glondu wrote:
>> The "strip"ping problem that appeared to motivate the new embedding
>> process had never bothered us, so another suitable workaround from our
>> perspective would be if there was a way to disable the
>> new "
On 11/15/2011 04:04 PM, Jon Ludlam wrote:
> +Package: libxen-ocaml-@version@
> +Architecture: any
> +Section: libs
> +Depends: ocaml-base-nox-${F:OCamlABI}, ${shlibs:Depends}, ${misc:Depends},
> ${ocaml:Depends}
> +Provides: ${ocaml:Provides}
> +Description: OCaml libraries for controlling Xen
>
On 11/15/2011 04:04 PM, Jon Ludlam wrote:
> +/usr/lib/ocaml/stublibs/dll*_stubs.so*
> +/usr/lib/ocaml/xenlight/META
> +/usr/lib/ocaml/xenlight/*.cma
> +/usr/lib/ocaml/xenbus/META
> +/usr/lib/ocaml/xenbus/*.cma
> +/usr/lib/ocaml/xenctrl/META
> +/usr/lib/ocaml/xenctrl/*.cma
> +/usr/lib/ocaml/xenstore
Le 16/11/2011 00:07, Stephen McCamant a écrit :
> So my personal opinion is that the original bug isn't really "fixed",
> but it's close enough that I think it would be within your
> maintainer's discretion to declare it so. Or alternatively this feels
> somewhat like a "help" or "wontfix" situatio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 19 Nov 2011 13:59:35 +0100
Source: ocaml-http
Binary: libhttp-ocaml-dev
Architecture: source amd64
Version: 0.1.5-1
Distribution: unstable
Urgency: low
Maintainer: Debian OCaml Maintainers
Changed-By: Stéphane Glondu
Le 20/11/2011 23:53, Erik de Castro Lopo a écrit :
> Package: libcairo-ocaml-dev
> Version: 1:1.2.0-2+b1
> Severity: normal
>
> There is a new upstream version (3.5) available here:
>
> http://forge.ocamlcore.org/projects/cairo/
It is not the same upstream. They don't even look related.
Whi
On 11/25/2011 05:17 PM, Bastian Blank wrote:
>> +Depends: ocaml-base-nox-${F:OCamlABI}
>
> Why is this not generated?
It should be.
>> +Depends: ocaml-findlib (>= 1.1)
>
> Same.
This is not a library, but a command-line tool, "ocamlfind". It's a kind
of pkg-config for OCaml libraries. It can p
Le 25/11/2011 21:49, Jon Ludlam a écrit :
> +GENCONTROL_ARGS := -VF:OCamlABI="$(OCAML_ABI)"
This should not be needed. It seems that you actually never answered:
does dh_ocaml actually generates the dependency to ocaml-*-$ABI ?
> + dh_install --sourcedir=$(DIR) $(OCAML_DLL_DIR)/*
If there
Le 07/12/2011 15:20, Jonathan Ludlam a écrit :
> Note that this package depends upon libxen-ocaml, which hasn't been
> uploaded yet, although it is committed in the repository.
Which repository? Can you post an URL to a .dsc somewhere, so that we
can build it easily?
--
Stéphane
--
To UNSUBSCR
Le 07/12/2011 21:21, Євгеній Мещеряков a écrit :
> Here is the patch that:
> 1. Add dh_ocamlclean with the same code as dh_ocamlinit -d
> 2. Adds a deprecation warning for dh_ocamlinit -d, in case if someone
> uses it without dh or cdbs
> 3. Uses dh_ocamlclean instead of dh_ocamlinit -d in a
On 12/09/2011 08:42 AM, Goswin von Brederlow wrote:
> There already are ocaml bindings for libuuid1:
> [...]
> Package: libuuidm-ocaml-dev
These are not bindings.
> Not knowing your source does your uuid do something different, something
> more? Could they be merged?
Same question here.
Cheers
Maintainers
Changed-By: Stéphane Glondu
Description:
coq- proof assistant for higher-order logic (toplevel and compiler)
coq-theories - proof assistant for higher-order logic (theories)
coqide - proof assistant for higher-order logic (gtk interface)
libcoq-ocaml - runtime libraries for Coq
Hello,
I've just uploaded Unison 2.40.63 to experimental. I haven't tested it
extensively myself; please do and report success/failure.
It seems that the documentation is broken. I haven't investigated much.
Help would be appreciated.
I've also uploaded a unison2.32.52 package to unstable (it is
Maintainers
Changed-By: Stéphane Glondu
Description:
coq- proof assistant for higher-order logic (toplevel and compiler)
coq-theories - proof assistant for higher-order logic (theories)
coqide - proof assistant for higher-order logic (gtk interface)
libcoq-ocaml - runtime libraries
Maintainers
Changed-By: Stéphane Glondu
Description:
coq- proof assistant for higher-order logic (toplevel and compiler)
coq-theories - proof assistant for higher-order logic (theories)
coqide - proof assistant for higher-order logic (gtk interface)
libcoq-ocaml - runtime libraries
Le 13/01/2012 14:01, Hendrik Tews a écrit :
> 1) leave the situation as is
> People not using Proof General will hopefully not install Proof
> General and therefore don't see the problem.
That would be my choice (least effort :). If people are bothered by PG,
they can uninstall it or override
Maintainers
Changed-By: Stéphane Glondu
Description:
coq- proof assistant for higher-order logic (toplevel and compiler)
coq-theories - proof assistant for higher-order logic (theories)
coqide - proof assistant for higher-order logic (gtk interface)
libcoq-ocaml - runtime libraries
Maintainers
Changed-By: Stéphane Glondu
Description:
coq- proof assistant for higher-order logic (toplevel and compiler)
coq-theories - proof assistant for higher-order logic (theories)
coqide - proof assistant for higher-order logic (gtk interface)
libcoq-ocaml - runtime libraries
Maintainers
Changed-By: Stéphane Glondu
Description:
coq- proof assistant for higher-order logic (toplevel and compiler)
coq-theories - proof assistant for higher-order logic (theories)
coqide - proof assistant for higher-order logic (gtk interface)
libcoq-ocaml - runtime libraries
Maintainers
Changed-By: Stéphane Glondu
Description:
coq- proof assistant for higher-order logic (toplevel and compiler)
coq-theories - proof assistant for higher-order logic (theories)
coqide - proof assistant for higher-order logic (gtk interface)
libcoq-ocaml - runtime libraries
Le 18/01/2012 11:28, Romeyke, Andreas a écrit :
> After upgrading Debian Squeeze to Testing, our ocaml based project does not
> compile anymore,
> because something is wrong now with sexplib.
>
> We got the message "Error: Unbound value string_of_sexp".
>
> With sexplib from Squeeze, all will com
Le 18/01/2012 10:01, Hendrik Tews a écrit :
> better late than never: I would like to announce the first
> release of otags reloaded for OCaml 3.12. It is available at
>
> http://askra.de/software/otags/
>
> Otags reloaded generates tags tables for emacs and vi/vim.
>
> Note that otags (by d
Le 18/01/2012 14:51, Hendrik Tews a écrit :
> This is the old version, which I took over from Monin and
> Alvarado and which was based on old Camlp4 of 3.09. I purposely
> inserted special guards in that version to ensure that it would
> only compile with OCaml 3.09. But some Debian folks removed t
Le 20/01/2012 22:15, Luca Falavigna a écrit :
> some files are licensed GPLv2+, please mention that in copyright file.
If you are talking about polytables.ml* and ocsigen_cache.ml*,
it was an upstream error, see:
http://ocsigen.org/darcsweb/?r=ocsigenserver.dev;a=commitdiff;h=20120123103126-d035
Le 20/01/2012 16:25, Hendrik Tews a écrit :
> a first version of the otags package is at
>
> http://mentors.debian.net/package/otags
>
> I would of course be glad if one of you could have a look at it.
It looks like a hostile takeover, and you cannot do that without the
maintainer's agreement
Le 26/01/2012 11:24, Hendrik Tews a écrit :
>It looks like a hostile takeover, and you cannot do that without the
>maintainer's agreement unless the package is orphaned.
>
> No, no hostility intended. It was only that at first, I didn't
> see your reply from January 19 (because it was deb
Le 26/01/2012 08:36, David MENTRE a écrit :
>> Moreover, I saw that the debian/ repository is also part of the upstream
>> tarball. Keep in mind that it is completely ignored by Debian tools with
>> the 3.0 (quilt) format (only the one from .debian.tar.gz is taken into
>> account), which is a good
Le 28/01/2012 10:17, Hendrik Tews a écrit :
>> a first version of the otags package is at
>>
>> http://mentors.debian.net/package/otags
>
> I have updated the package on mentors. I believe I fixed all the
> issues. [...]
Please do not put the versioned dependencies to camlp4-extra
Le 30/01/2012 23:58, Hendrik Tews a écrit :
> [...] I can even install this package in
> Squeeze alongside ocaml 3.11.2. Then its an easy exercise to
> produce a segmentation fault with otags. The same could happen
> when ocaml 3.13 enters Debian.
OK. Then "camlp4-extra (<< 3.13)" is probably not
Le 31/01/2012 09:36, Hendrik Tews a écrit :
>I know camlp4 depends on Dynlink
>nonetheless, which I currently consider a bug in upstream
>ocaml.
>
> Is there a bug number for this?
I said "currently", because I haven't (yet) taken the time to
investigate and understand it myself... t
Le 31/01/2012 12:44, Hendrik Tews a écrit :
> What is the status dynlink.cmxa on armel?
It doesn't exist. There has been a discussion in [1] about that.
Retrospectively, maybe I would advocate a dummy implementation of
dynlink.cmxa everywhere... something like raising an exception, but
definitely
Le 31/01/2012 16:44, Hendrik Tews a écrit :
> I managed now to build the package from a git repository with
> git-buildpackage. Shall I push my changes back to your otags git
> repository or shall I wait a bit with that?
You can. Actually, it is easier (for me) to review from the git
repository. P
Le 01/02/2012 13:53, Hendrik Tews a écrit :
> I pushed otags-3.12.1.99-2 now to the otags git repository. [...]
Good. I will upload it soon.
> [...] I got
> 3 "Mail delivery failed" emails in response. Is this normal?
It happens sometimes. Nothing to worry about (I think).
>> but where does
Le 06/02/2012 11:42, Hendrik Tews a écrit :
> Hold on! I would just like to know if the packaging is OK from
> your point of view. [...]
It is.
> [...] If it is I will release upstream 3.12.2 and
> prepare a 3.12.2 package. This way I can incorporate necessary
> changes directly in the upstream v
Le 15/02/2012 16:44, Andreas Romeyke a écrit :
>> File "brackets.ml", line 3, characters 0-2:
>> Error: Comment not terminated
>>
>> I believe it's an OCaml feature, that strings inside comments
>> must be terminated (but I cannot find it in the manual).
> That would be a very strange featu
Version: 3.11.2-2
Le 27/02/2012 16:03, Hendrik Tews a écrit :
> I suggest to mark bug #362188 as fixed. The problem is not
> present in stable and testing anymore.
OK. It's done with this mail.
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with
Le 28/02/2012 09:21, Hendrik Tews a écrit :
> I just noticed that camlp5 from Debian cannot compile hol-light,
> because the latter requires a strict camlp5 (with configure -strict).
> Has it ever be considered adding a Debian package for a strict
> camlp5?
See http://bugs.debian.org/cgi-bin/bugr
Le 28/02/2012 23:16, Hendrik Tews a écrit :
> I looked at how camlp5 is compiled and I believe to build
> transitional _and_ strict camlp5 executables and libraries from
> one source package will require quite a bit of work. The reason
> is that the names of executables and libraries are hardcoded
Le 29/02/2012 10:01, Hendrik Tews a écrit :
>What about the library?
>
> You mean camlp5.cma and its variants? They differ between strict
> and transitional modes and their name is hardcoded in the
> Makefile as well. There might be some objects which are
> identical, eg. /usr/lib/ocaml/camlp5
Le 29/02/2012 10:03, Pierre Boutillier a écrit :
> I'm sorry but I do not see an answer to that question in the thread: Why
> do we keep a camlp5 in transitionnal mode ?
This is a good question that I've been thinking about.
> For packages, Coq and ledit support strict mode. The only remaining
>
Le 29/02/2012 11:23, Pierre Boutillier a écrit :
> ssreflect and aactactics are OK
>
> ulex does NOT depend anymore on camlp5 since v1.0:
> CHANGES:
> 1.0
> * Update to the new Camlp4 and to ocamlbuild (release for OCaml 3.10
>only), by Nicolas Pouillard.
Err... we were talking about
Le 29/02/2012 18:04, Pino Toscano a écrit :
> the asmcomp tests fail to link on hurd-i386, because the "call_gen_code"
> symbol is missing.
> The problem is that in testsuite/tests/asmcomp/i386.S the #define's that
> are enabled for hurd are wrong. Using the linux_elf ones (just also it
> is done i
Package: src:approx
Version: 3.5-1
Severity: serious
Tags: patch
Hello,
approx fails to build from source with ocamlnet 3.5.1:
> /usr/bin/ocamlopt -c -warn-error A -I +netstring -o url.cmx url.ml
> + /usr/bin/ocamlopt -c -warn-error A -I +netstring -o url.cmx url.ml
> File "url.ml", line 1, char
Le 01/03/2012 13:51, Hendrik Tews a écrit :
>There are other reverse build-dependencies: matita, ssreflect,
>geneweb... and maybe others (transitively). Someone has to test.
>
> ulex0.8 does not build with a strict camlp5:
>
> ocamlc -a -o pa_ulex.cma -pp 'camlp5o pa_extend.cmo q_MLas
501 - 600 of 2279 matches
Mail list logo
