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
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..
Can you
occurs with the attached cfagent.conf file.
I have narrowed it a lot. I should have done this earlier!
--
Stéphane Glondu
groups:
ferme = ( IPRange(10.231.136.200-210) )
Peter De Schrijver a écrit :
There was an error while trying to autobuild your package:
[...]
I don't understand this error, and as I said in [1], I'm waiting for an
explanation myself.
[1] http://lists.debian.org/debian-wb-team/2010/01/msg00010.html
mlpost built fine on all other
tags 564779 + unreproducible
severity 564779 normal
thanks
Peter De Schrijver a écrit :
Package: mlpost
Version: 0.7.4-1
[...]
There was an error while trying to autobuild your package:
[...]
+ mkdir -p img/ cd img/ ../customdoc/img_doc.byte /dev/null cd ..
fatal: exec failed: No such
Lucas Nussbaum a écrit :
Source: cameleon
Version: 1.9.18.svn20090908+703-1
[...]
During a rebuild of all packages in sid, your package failed to build on
amd64.
FYI, I'm planning to fix this with the upload of cameleon 1.9.19 to
unstable (during lablgtk2 2.14 transition). Note: it might be
severity 582981 normal
thanks
Le 25/05/2010 14:44, Mehdi Dogguy a écrit :
It's unfortunate that tuareg-mode doesn't compile with emacs22 but:
emacs22 is not meant to be released with squeeze [1] [...]
and is not in testing.
Right. Therefore, I'm lowering this bug's priority.
Cheers,
--
Jan Wagner a écrit :
Thats totally fine and I don't belive anybody is making a backport of ocaml
just for fun. In my case it was a build-dep, needed by another package.
Backporting ocaml isn't an easy task, since you'll have to have all
OCaml libraries recompiled. Besides, the workflow used in
tags 569260 + patch
thanks
Cyril Brulebois a écrit :
your package FTBFS on all archs for +b1 (Recompile with OCaml 3.11.2)
this way:
| ocamlc.opt -I ptests -dtypes -vmthread -g -o bin/ptests.byte \
| unix.cma threads.cma str.cma dynlink.cma
ptests/ptests_config.ml
reassign 569267 libexpat-ocaml-dev
affects 569267 cduce
retitle libexpat-ocaml-dev: missing dependency on ocaml-nox-$ABI
thanks
Cyril Brulebois a écrit :
your package FTBFS for the +b2 binNMU round:
| Build cduce
| File _none_, line 1, characters 0-1:
| Error: Files
reassign 569391 libgdome2-ocaml-dev
retitle 569391 libgdome2-ocaml-dev: misses dependency on ocaml-nox-$ABI
affects 569391 src:matita
thanks
Lucas Nussbaum a écrit :
Relevant part: [...]
I think the relevant part is rather:
OCAMLC nCic2OCic.mli
OCAMLOPT nCic2OCic.ml
OCAMLC
Stefano Zacchiroli a écrit :
In fact, it's already fixed in Git [1], I just didn't have time to
upload yet. If it can be uploaded right away, I'll do that tomorrow.
Please do.
--
Stéphane
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe.
Package: minlog
Version: 4.0.99.20080304-4.1
Severity: grave
Hello,
I get the following error when running minlog:
/usr/share/minlog/init.scm:37:2: if: bad syntax (must have an else
expression) in: (if COMMENT-FLAG (begin (display COMMENT-STRING) (for-each
display x) (newline)))
Running
tags 578216 + moreinfo
thanks
Paul Pelzl a écrit :
The ocsigen server does not respond to my HTTP requests. I launched the
server via /etc/init.d/ocsigen force-start, and used the configuration
file included with the distribution.
Have you tried to connect in IPv6? What is the output of
severity 578216 important
retitle 578216 Should listen on IPv4 by default
thanks
Paul Pelzl a écrit :
Have you tried to connect in IPv6? What is the output of netstat -lptn?
Ah, thanks. I can indeed connect via ip6-localhost.
Is this the expected behavior when the port is configured as
reassign 567060 src:ocamlgsl
affects 567060 src:orpie
retitle 567060 missing libmlgsl.a on bytecode architectures
thanks
Nobuhiro Iwamatsu a écrit :
orpie FTBFS on armel, ia64, mips* and s390.
[...]
/usr/bin/ld: cannot find -lmlgsl
It appears that libmlgsl.a, which should be installed by
severity 580322 serious
thanks
Joost Yervante Damad a écrit :
lwt thread canceling is broken in lwt 2.1.0.
After discussion with upstream they came up with a set of fixes, which are
available in DARCS: [...]
We are currently investigating another issue with the lwt 2.1.0 /
ocsigen 1.3.2
Lucas Nussbaum a écrit :
During a rebuild of all packages in sid, your package failed to build on
amd64.
[...]
mkdir -p img/ cd img/ ../customdoc/img_doc.byte /dev/null cd ..
+ mkdir -p img/ cd img/ ../customdoc/img_doc.byte /dev/null cd ..
Command exited with code 1.
make[1]: ***
Stéphane Glondu a écrit :
Lucas Nussbaum a écrit :
During a rebuild of all packages in sid, your package failed to build on
amd64.
[...]
mkdir -p img/ cd img/ ../customdoc/img_doc.byte /dev/null cd ..
+ mkdir -p img/ cd img/ ../customdoc/img_doc.byte /dev/null cd
..
Command exited
Norbert Preining a écrit :
Do texlive-metapost maintainers have a clue?
Do *not* set
tracing_choices := 1;
that is the reason 1 is returned. I will ask Taco if that is intended,
but an easy fix for you is simply do NOT include the above line.
This is generated code. Is it always safe
Taco Hoekwater a écrit :
Any issued diagnostic messages set the return code to 1. Issued errors
are 2, issued fatal errors give 3.
Thank you for the explanation. I will comment out the tracingmacros
instruction in the generated code.
Cheers,
--
Stéphane
PS: Merry Christmas!
--
To
Lennart Sorensen a écrit :
Compilation with module-assistant with a 2.6.29 kernel fails... Or
let's say doesn't do anything:
Pretty sure it worked here.
On amd64? I know at least one other person who has the same problem (and
I know nobody who hasn't :-).
BTW, I observe the same behaviour
Lennart Sorensen a écrit :
rm -rf /usr/src/modules/nvidia* (or m-a clean nvidia-kernel-legacy-173xx
should do that)
m-a a-i -t nvidia-kernel-legacy-173xx -l 2.6.29-1-amd64,2.6.29-2-amd64
It built and installed. I did have to remove my non legacy modules
packages first though since they
reassign 527816 libcryptokit-ocaml-dev
thanks
Christoph Martin a écrit :
The problem is, that the new version of libcryptokit-ocaml-dev does not
anymore contain cryptokit.a: [...]
This is a (big) mistake, and my fault. Shame on me :-(
It will be fixed soon.
--
Stéphane
--
To UNSUBSCRIBE,
Stefano Zacchiroli a écrit :
I've prepared an NMU for monotone-viz (versioned as 1.0.1-1.1) and
uploaded it to DELAYED/2, according to devref §5.11.1. The patch renames
some stub methods to avoid name clashes at (C) link-time with recent
versions of lablgtk2.
The current patch looks too much
Package: lvm2
Version: 2.02.53-2
Severity: critical
Justification: breaks the whole system
Hello,
My computer failed to boot this morning because lvm2 failed to create
/dev/vgname/* symlinks on (read-only) /. It seems that starting
checkroot before lvm2 fixed the problem.
Best regards,
--
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
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
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
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
Lucas Nussbaum a écrit :
ocamlfind ocamlopt -a -o gettextBase.cmxa gettextConfig.cmx
gettextCategory.cmx gettextTypes.cmx gettextUtils.cmx gettextModules.cmx
gettextCompat.cmx gettext.cmx gettextFormat_parser.cmx
gettextFormat_lexer.cmx gettextFormat.cmx gettextMo_int32.cmx
Stéphane Glondu a écrit :
Here is the aptitude log for the last upgrade of the chroot:
[...]
[UPGRADE] cdbs 0.4.56 - 0.4.57
[...]
The bug must have been introduced by one of these packages.
The guilty appears to be cdbs... Actually, there is little doubt:
1. login into a clean
Lucas Nussbaum a écrit :
make[2]: Entering directory
`/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir'
/bin/sh
/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/mkinstalldirs
Lucas Nussbaum a écrit :
make[3]: Entering directory
`/build/user-libpuzzle_0.9-2-amd64-Aok0cp/libpuzzle-0.9'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory
Julian Andres Klode a écrit :
/debian/tmp/... is installed, instead of the files inside it
e.g. /debian/tmp/usr/lib/dbus-1.0/dbus-daemon-launch-helper
instead of /usr/lib/dbus-1.0/dbus-daemon-launch-helper.
I attached a patch I used to locally build a working package. It
simply removes the
Stéphane Glondu a écrit :
- downgrade bash to lenny's version (3.2-4)
It seems that . doesn't look in the current directory whereas it used
to before.
This is fixed in pkg-ocaml-maint git, and I've notified upstream.
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ
Lucas Nussbaum a écrit :
During a rebuild of all packages in sid, your package failed to build on
amd64.
[...]
The full build log is available from:
http://people.debian.org/~lucas/logs/2009/09/07/cameleon_1.9.18.svn20090302+691-1_lsid64.buildlog
Steps not to reproduce:
- login to
Florent Fourcot a écrit :
Fatal - While loading /usr/lib/ocsigen/extensions/ocsipersist-sqlite.cma:
Dynlink.Error: interface mismatch on Sqlite3
Indeed. This is because of a new version of ocaml-sqlite3 that breaks
binary compatibility. This problem will be solved at the next upload of
Ocsigen
Hello,
nmu ocsigen_1.1.0-2 . ALL . -m 'Recompile with ocaml-sqlite3 1.4.0'
This would close #527224.
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Romain Beauxis a écrit :
[...dh_install failure because of missing *.a files...]
Was there any kind of change in the behaviour of dh_install ?
AFAICT, dh_install has always failed with wildcards which doesn't expand
to anything.
What happens often, however, is that you have C bindings in your
tag 519627 + patch
thanks
Stephane Glondu a écrit :
A binary NMU[1] has been recently requested for the OCaml 3.11.0
transition, and your package fails to build[2], most likely because of
some change in OCaml 3.11.0. [..]
A fix is attached.
Cheers,
--
Stéphane
commit
Hello,
This bug has been fixed in the git repository[1] (owned by
pkg-ocaml-maint) for a while, but I thought it would have been uploaded
quickly so I didn't file a bugreport.
Besides from being moved to dh-ocaml, ocamldoc-api-ref-config has also
been moved to /usr/share/ocaml (but compatibility
Siegfried Gevatter (RainCT) a écrit :
Thanks for taking the time to report this bug and helping improve
Debian. Could you please tell me what output you get if you run
«screenruler» from a terminal?
I get:
Loading libraries...
ruby: symbol lookup error:
Christian Perrier a écrit :
Trying to recompile the geneweb package in sid gives:
camlp5r pa_extend.cmo q_MLast.cmo pa_macro.cmo -DUNIX -o def.syn.ppo
def.syn.ml
ocamlc.opt -warn-error A -I ../wserver -I ../dag2html -I +camlp5 -c -impl
def.syn.ppo
File def.syn.ppo, line 1, characters 0-1:
tags 521674 + upstream patch
thanks
Stéphane Glondu a écrit :
You can workaround this failure by adding -w x to the failing command
line. It will disable the warning (which is an error because of
-warn-error). You can also remove -warn-error (your call).
I can see in the changelog entry
tags 522008 + confirmed upstream fixed-upstream
thanks
Daniel Schepler a écrit :
[...]
../exec/exec.a(omake_exec.o): In function `camlOmake_exec__28':
(.data+0x390): undefined reference to `caml_sync'
[...]
This is quite strange, since I cannot find any other reference of
caml_sync neither
Samuel Thibault a écrit :
Package: lablgtk2
Version: 2.12.0-2
Severity: serious
Justification: FTBFS
With libpanel-applet2-dev = 2.26, panel-applet.h doesn't include
libgnomeui/gnome-ui-init.h any more, so that ml_panel'c use of
LIBGNOMEUI_MODULE defined there doesn't work any more.
This
tags 535267 + patch
thanks
sks is going to block the OCaml 3.11.1 transition.
Attached is a patch that fixes the FTBFS. I am not able to reproduce
#535469, so I don't know whether it is fixed by a mere recompilation.
I suggest to proceed with the NMU anyway if there is no news from sks
Stephen Dranger wrote:
Reporting success installing and running this package after applying
the patch/workaround submitted to this bug.
Same here.
--
Stéphane
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Package: src:aptitude
Version: 0.6.3-3
Severity: serious
Tags: patch
Hello,
debian/rules clean doesn't clean build directories:
/tmp/build/aptitude-0.6.3# debian/rules clean
dh_testdir
dh_testroot
if [ -f build-stamp-gtk ]; then rm build-stamp-gtk; fi
if [ -f build-stamp-curses ]; then rm
Le -10/01/-28163 20:59, Wesley W. Terpstra a écrit :
While I can understand that downloading files from the Internet at
large might be bad for other reasons, this package only downloads from
the debian archive itself. I could have packed all the
cross-compilation files into a 'source tarball'
Package: matita
Version: 0.5.8-2+b1
Severity: serious
Tags: upstream
Hello,
Matita currently fails to build from source with camlp5 6.02.1 [1]. It
seems to be the only blocker to a transition to camlp5
6.02.1. Upstream is currently working on a new release but cannot give
a timeframe on when it
Package: ghostscript
Version: 9.01~dfsg-1
Severity: serious
Tags: sid
Hello,
ocaml-melt currently FTBFS on sparc [1] because of a bus error
provoked by ps2pdf. The bus error is easily reproduced by running
ps2pdf on the file available at [2]. This bug is not present with the
previous version,
tags 602170 + confirmed
severity 602170 important
thanks
Le 02/11/2010 09:28, Joost Yervante Damad a écrit :
whenever there's something wrong, the binding looks up the exception to be
thrown, and throws it.
[...]
more details, including a patch with a possible solution can be found at:
affects 589359 + apron
thanks
Le 17/07/2010 00:35, Mehdi Dogguy a écrit :
mpfr4 (3.0.0-2) ships libmpfr-dev which is also shipped by mpfr
(version 2.4.2). mpfr and mpfr4 are incompatible in several ways.
Packages using libmpfr-dev in their build-depends are going to start
FTBFS'ing soon.
tags 589359 - pending
thanks
Le 17/07/2010 12:32, Laurent Fousse a écrit :
After removing the reference to `mpfr_random' in
mlgmpidl/gmp_random.idl then make clean make rebuild apron fails
on GMP_RND_MAX. [...]
Indeed.
I'll try to provide a patch monday for apron.
I'm looking forward to
Le 19/07/2010 11:24, Laurent Fousse a écrit :
Please pull from http://komite.net/laurent/scratch/apron.git and tell
me if it works (it builds fine here).
Looks reasonable. I will upload and forward it upstream.
Thanks,
--
Stéphane
--
To UNSUBSCRIBE, email to
Mark Baker wrote:
[...] When I built approx 3.3.0
from source, it worked (or at least didn't crash on startup, I didn't
try to install it).
When I build approx 3.3.0 from source in stable, and then use sid's
libpcre3, I get a segfault as well. Actually, the segfault can be
reproduced very
Le 29/07/2010 04:50, Tommi Vainikainen a écrit :
In libpcre3 8.02 pcre_config option MATCH_LIMIT and
MATCH_LIMIT_RECURSION take a long integer pointer as where parameter,
but instead in older pcre those take a integer pointer. (see pcreapi.3
function pcre_config and parameter MATCH_LIMIT, and
Le 29/07/2010 11:43, Stéphane Glondu a écrit :
So it looks like pcre-ocaml (and most likely its reverse-depends) was
the only package affected by that.
Affected rdeps include cmigrep, ocsigen, cduce, galax and liquidsoap.
--
Stéphane
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ
tags 581202 + pending patch
thanks
Le 29/07/2010 11:56, Stéphane Glondu a écrit :
So it looks like pcre-ocaml (and most likely its reverse-depends) was
the only package affected by that.
Affected rdeps include cmigrep, ocsigen, cduce, galax and liquidsoap.
I've uploaded the attached NMU
Le 31/07/2010 18:48, Stéphane Glondu a écrit :
I've uploaded the attached NMU to DELAYED/5.
Sorry...
--
Stéphane
pcre3.diff
Description: application/pgp-keys
clone 591174 -1
retitle -1 RM: mlton-cross
reassing -1 debian-release
user release.debian@packages.debian.org
usertags -1 + rm
thanks
Le 31/07/2010 21:45, Lucas Nussbaum a écrit :
Relevant part:
make[1]: Entering directory
Le 22/02/2011 07:47, Lucas Nussbaum a écrit :
Source: cmigrep
Version: 1.5-7
Severity: serious
Tags: wheezy sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20110221 qa-ftbfs
Justification: FTBFS on amd64
A fix of that is scheduled to be uploaded during the OCaml 3.12.0
transition.
Le 26/02/2011 01:38, Julien Cristau a écrit :
Package: libsoundtouch-dev
Version: 1.5.0-3
Severity: serious
Justification: i said so
Apparently you decided to start a SONAME transition with no coordination
with the release team. This will clash with the ongoing transition to
ffmpeg 0.6,
Subject: ocamlopt broken by binutils 2.21
Package: ocaml
Severity: grave
Version: 3.11.2-2
Tags: wheezy sid
Le 08/03/2011 14:00, Eric Cooper a écrit :
I was able to fix this problem; a patch is attached to the issue report in
http://caml.inria.fr/mantis/view.php?id=5237
I only did a full
Package: src:graphviz
Version: 2.26.3-5
Severity: serious
Hello,
Your package FTBFS with the following message:
mv: cannot stat
`/build/buildd-graphviz_2.26.3-5+b2-amd64-fEbTwo/graphviz-2.26.3/debian/libgv-python/usr/lib/graphviz/python27/*.so':
No such file or directory
make: ***
Package: otags
Version: 3.09.3.3-1~11
Severity: serious
Tags: wheezy sid
Hello,
I've just noticed that otags FTBFSes since the recent upgrade of camlp5:
Configuration summary:
binaries will be copied to /usr/bin
libraries will be copied to /usr/lib/ocaml/otags/
native-code
Package: calibre
Version: 0.7.50+dfsg-1
Severity: grave
Hello,
Since I upgraded calibre this morning (along with python-qt4 and
python-sip, that I was keeping at an old version because of #616372),
calibre stopped working altogether. I get an immediate
segfault. According to strace, it happens
severity 620031 important
tags 620031 + confirmed
thanks
Le 29/03/2011 13:06, Torsten Crass a écrit :
Justification: renders package unusable
Severity: grave
unison-gtk still works when no terminal interaction is involved (e.g.
when you use an agent).
After a recent upgrade, unison-gtk
Le 26/03/2011 11:50, Stéphane Glondu a écrit :
Since I upgraded calibre this morning (along with python-qt4 and
python-sip, that I was keeping at an old version because of #616372),
calibre stopped working altogether. I get an immediate
segfault. According to strace, it happens after
/usr/lib
Hello,
I was hit by this bug too, and using rpcbind instead of portmap also
works for me.
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Le 10/04/2011 17:13, Kurt Roeckx a écrit :
SSLv2 support got removed, but it seems you still try to use the
functions. I suspect this is yet an other case of a wrapper of the
openssl library. [...]
Indeed. Are SSLv23_* functions still OK to use?
[...] You can check that those functions
severity 604933 important
thanks
Le -10/01/-28163 20:59, ygrek a écrit :
Justification: renders package unusable
This is overly exaggerated. The findlib package and shared stublibs are
not upstream features, and the package can still be used as a regular
library with third-party programs. This
Package: calibre
Version: 0.8.21+dfsg-1
Severity: grave
Dear maintainer,
It is impossible to run calibre today:
$ calibre
Traceback (most recent call last):
File /usr/bin/calibre, line 19, in module
sys.exit(main())
File /usr/lib/calibre/calibre/gui2/main.py, line 338, in main
app,
Package: src:graphviz
Version: 2.26.3-7
Severity: serious
Dear Maintainer,
graphviz fails to build from source on all architectures. On amd64, it fails
with:
CC gvconfig.lo
CC gvtextlayout.lo
CC gvusershape.lo
CC gvc.lo
CCLD libgvc.la
block 633304 with 639288
thanks
On 11/02/2011 08:27 AM, Stéphane Glondu wrote:
CC gvconfig.lo
CC gvtextlayout.lo
CC gvusershape.lo
CC gvc.lo
CCLD libgvc.la
x86_64-linux-gnu-gcc: error: /usr/lib/x86_64-linux-gnu/libexpat.so: No such
file or directory
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,
Le 06/03/2012 08:18, Andreas Beckmann a écrit :
during a test with piuparts I noticed your package fails to upgrade from
'squeeze'.
It installed fine in 'squeeze', then the upgrade to 'wheezy' fails.
[...]
Precision: it fails when using apt, but it works using aptitude.
Could you please
Package: dnsmasq
Version: 2.60-1
Severity: grave
Hello,
I cannot start a (squeeze) netboot install (on an eee pc 701) using
dnsmasq on the server. In the past, I have already installed
(successfuly) computers this way. Today, dnsmasq keeps segfaulting
after downloading the kernel image. It also
Hello,
I've just tried version 2.12.3-7 with aforementioned patch, and it
compiles successfully (and does not without the patch). After more than
6 months of pending, maybe it's time to upload it? Or remove the tag...
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to
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
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-amd64.cow
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
$ pdebuild --pbuilder cowbuilder -- --basepath
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.
[1] http://thread.gmane.org
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: Files
Hello,
I was trying to check whether this bug was caused by #642922, and I got
a different error:
ghc --make Setup
[1 of 2] Compiling Distribution.ShellHarness ( Distribution/ShellHarness.hs,
Distribution/ShellHarness.o )
[2 of 2] Compiling Main ( Setup.lhs, Setup.o )
Le 26/09/2011 23:46, Iain Lane a écrit :
That's fixed in darcs (darcs' darcs repo? hah) and is #642710. You can
just hack the .cabal file to accept 0.95.1 which is in sid and it should
work for you.
I tried after applying patch:
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
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
already exported by libocamlnet
Package: src:bin-prot
Version: 1.3.1-1
Severity: serious
Hello,
The latest version of bin-prot fails to build from source on almost
all architectures. Besides, there is a known issue with OCaml 3.12.1
[1]. I've notified upstream; they are investigating...
[1]
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.
More
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 triggered with this
patched dash
[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 probably
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
1 - 100 of 389 matches
Mail list logo
