Bug#322210: [m68k] ocaml-nox: can not be removed
On Tue, Aug 09, 2005 at 08:26:45PM +0200, Christian T. Steigies wrote: I am trying to clean up my unstable chroot, for some reason a few ocaml packages were still installed. This bug report shows two different problems: 1) ocaml-md5sums may be not available when postrm scripts are invoked 2) /var/lib/ocaml/md5sums is not a directory I fixed (1) and upload is pending. I can't understand (2). /var/lib/ocaml/md5sums/ is a directory and several ocaml related packages install stuff under that directory. I can understand if the directory is no longer there when some postrm scripts are executed (and I fixed the faulty behaviour of ocaml-md5sums in that case), but I can't understand how it comes /var/lib/ocaml/md5sums is something else than a directory. Have you toch-ed it trying to fix the postrm problem (like you did a few lines below in your report)? Thanks for the bug report. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#322210: [m68k] ocaml-nox: can not be removed
On Fri, Aug 12, 2005 at 11:09:10AM +0200, Sven Luther wrote: 1) ocaml-md5sums may be not available when postrm scripts are invoked Sure, you should use it in prerm, since postrm removes it, no ? No, I can't, since when prerm is invoked .md5sums entries are still in /var/lib/ocaml/md5sums/. Still this is not a problem, invoking it on postrm only if ocaml-md5sums is available is fine since as long as it is not available .md5sums entries are useless. As soon as it will get re-installed the registry will be updated again. It is probably not there, but why if it was not there, and some random packages does a : cp stuff /var/lib/ocaml/md5sums It was there since the error reported was not a directory rather than no such file or directory:. But as Christian reported he probably created that file by hand. All should be fixed now, I'm rebuilding the package right now. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322210: [m68k] ocaml-nox: can not be removed
On Thu, Aug 18, 2005 at 07:56:28AM +0200, Christian T. Steigies wrote: I tried to clean my buildd and now its broke worse than ever: Preparing to replace ocaml-nox 3.08.3-6 (using .../ocaml-nox_3.08.3-7_m68k.deb) ... ERROR: emacsen-common being used before being configured. Well, this is not related to ocaml-md5sums any longer, but to emacs. Julien, or someone else with emacs knowledge, could you please look at this issue? -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#322210: Bug#312618: reopen
reopen 322210 merge 312618 322210 thanks On Thu, Aug 18, 2005 at 03:03:37PM +0200, Robert Millan wrote: Preparing to replace ocaml-nox 3.08.3-3 (using .../ocaml-nox_3.08.3-7_i386.deb) ... ERROR: emacsen-common being used before being configured. ERROR: This is likely a bug in the ocaml-nox package, which needs to ERROR: add one of the appropriate dependencies. ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz ERROR: for details. dpkg: warning - old pre-removal script returned error exit status 2 dpkg - trying script from the new package instead ... ERROR: emacsen-common being used before being configured. ERROR: This is likely a bug in the ocaml-nox package, which needs to ERROR: add one of the appropriate dependencies. ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz ERROR: for details. dpkg: error processing /var/cache/apt/archives/ocaml-nox_3.08.3-7_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 2 -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#322210: [m68k] ocaml-nox: can not be removed
On Thu, Aug 18, 2005 at 09:53:00PM +0200, Christian T. Steigies wrote: Well, this is not related to ocaml-md5sums any longer, but to emacs. That is true, but your prerm script uses emacs, so your package has to (pre)depend on emacs or something. I pointed out that the bug is not related to ocaml-md5sums just because the bug was originally related to that. Now, as you've problably seen, I've reopened the bug and merged it with the emacs related bug. That said your bug is proper, serious, and need to be fixed. Still, I know almost nothing about emacs and I thus asked for help on debian-ocaml-maint to people with more emacs policy knowledge. Or are you actually part of the conspiracy trying to demote m68k to second class citizens? ;-) Worst than that: our conspiracy is to have all architectures which do not support ocaml native code compilation demoted to SCC :-))) -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#346892: patch for xlibs-dev splitting
tags 346892 + patch thanks Attached you can find a patch fixing this bug. I'm going to NMU it. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- diff -ur orig/astrolog-5.40/debian/changelog astrolog-5.40/debian/changelog --- orig/astrolog-5.40/debian/changelog 2006-01-22 12:44:21.0 +0100 +++ astrolog-5.40/debian/changelog 2006-01-22 12:44:03.0 +0100 @@ -1,3 +1,13 @@ +astrolog (5.40-2.1) unstable; urgency=low + + * Non-maintainer upload. + * debian/control +- xlibs-dev splitting transition, removed build-dep on xlibs-dev in + favour of libx11-dev + (closes: #346892) + + -- Stefano Zacchiroli [EMAIL PROTECTED] Sun, 22 Jan 2006 12:37:38 +0100 + astrolog (5.40-2) unstable; urgency=low * Updated astrolog.cgi to reflect changes in perl and imagemagick (Closes: #92300, #92304) diff -ur orig/astrolog-5.40/debian/control astrolog-5.40/debian/control --- orig/astrolog-5.40/debian/control 2006-01-22 12:44:21.0 +0100 +++ astrolog-5.40/debian/control2006-01-22 12:43:37.0 +0100 @@ -3,7 +3,7 @@ Priority: extra Maintainer: Tom Lear [EMAIL PROTECTED] Standards-Version: 3.5.6 -Build-depends: debhelper, xlibs-dev +Build-Depends: debhelper, libx11-dev Package: astrolog Architecture: any signature.asc Description: Digital signature
Bug#346874: patch for xlibs-dev splitting
tags 346874 + patch thanks Attached you can find a patch fixing this bug. I'm going to NMU it. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- diff -ur orig/ida-2.01/debian/changelog ida-2.01/debian/changelog --- orig/ida-2.01/debian/changelog 2006-01-22 16:19:50.0 +0100 +++ ida-2.01/debian/changelog 2006-01-22 16:27:34.0 +0100 @@ -1,3 +1,17 @@ +ida (2.01-1.3) unstable; urgency=low + + * Non-maintainer upload. + * debian/control +- xlibs-dev splitting transition, removed build-dep on xlibs-dev in + favour of: libx11-dev, libxp-dev, libxext-dev, libxpm-dev, + libxt-dev, x-dev + (closes: #346874) +- bumped build-dep on libmotif-dev to (= 2.2.3-1.3), it is the + first version of the package not depending on xlibs-dev and thus + installable + + -- Stefano Zacchiroli [EMAIL PROTECTED] Sun, 22 Jan 2006 12:16:51 +0100 + ida (2.01-1.2) unstable; urgency=low * Non-maintainer upload. diff -ur orig/ida-2.01/debian/control ida-2.01/debian/control --- orig/ida-2.01/debian/control2006-01-22 16:19:50.0 +0100 +++ ida-2.01/debian/control 2006-01-22 16:27:16.0 +0100 @@ -1,7 +1,7 @@ Source: ida Section: contrib/graphics Priority: extra -Build-Depends: debhelper (= 4.0), perl, libmotif-dev (= 2.2.2), libjpeg-dev, libtiff4-dev | libtiff-dev, libpng3-dev | libpng-dev, libungif4-dev, xbase-clients, xlibs-dev, xutils, bsdmainutils, libpcd-dev, libcurl3-dev | libcurl-dev, libexif-dev, libfontconfig1-dev, libfreetype6-dev +Build-Depends: debhelper (= 4.0), perl, libmotif-dev (= 2.2.3-1.3), libjpeg-dev, libtiff4-dev | libtiff-dev, libpng3-dev | libpng-dev, libungif4-dev, xbase-clients, libx11-dev, libxp-dev, libxext-dev, libxpm-dev, libxt-dev, x-dev, xutils, bsdmainutils, libpcd-dev, libcurl3-dev | libcurl-dev, libexif-dev, libfontconfig1-dev, libfreetype6-dev Maintainer: Gerd Knorr [EMAIL PROTECTED] Standards-Version: 3.6.1 signature.asc Description: Digital signature
Bug#338098: libextlib-ocaml-dev: is not installable in unstable
On Tue, Nov 08, 2005 at 12:10:17PM +0800, Paul Wise wrote: ocaml has been updated to a new upstream version. as a result, libextlib-ocaml-dev needs to be updated. I see a lot of your other packages are in the same situation. In order to ease migration into testing of the whole bunch of ocaml packages during transitions between upstream releases, packages are uploaded in a staged manner. First those who directly build depends on ocaml only, then those which depends to it at distance 2 and so on. Extlib is at distance 2, before it can be uploaded we need to rebuild those at distance one among which there is, for example, findlib on which I'm working on. Feel free to submit a patch for extlib (implementing the change we discussed on debian-ocaml-maint to ease future transitions) or switch to testing. Thanks for the report. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#319433: FTBFS: Unable to find libmlgdome2-xslt
tags 319433 + wontfix thanks On Thu, Jul 21, 2005 at 09:55:53AM -0700, Matt Kraai wrote: Package: editex Version: 0.0.5-6 Severity: serious editex fails to build because it cannot find libmlgdome2-xslt: editex is going to be removed from the debian archive, I requested its removal two weeks ago (see #317298), thus I wont fix this bug ever. Cheers. -- Stefano Zacchiroli -- Master in Computer Science @ Uni. Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} - http://www.bononia.it/zack/ I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! -- G.Romney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320624: pcre-ocaml: FTBFS: Not using -fPIC to make a shared library.
On Sat, Jul 30, 2005 at 07:57:36PM +0200, Kurt Roeckx wrote: Your package is failing to build with the following error: On which architecture the package FTBFS? On buildd.debian.org all attempted built have been completed successfully ... Before forwarding the patch upstream I would like to have more info to give him. Thanks for the report and for the patch. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#320624: pcre-ocaml: FTBFS: Not using -fPIC to make a shared library.
On Sun, Jul 31, 2005 at 12:25:14PM +0200, Kurt Roeckx wrote: On which architecture the package FTBFS? On buildd.debian.org all attempted built have been completed successfully ... The log was from amd64, but it failed on hppa too. Yes, I discovered it this morning, since yesterday evening the build log wasn't available yet. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320624: pcre-ocaml: FTBFS: Not using -fPIC to make a shared library.
On Sun, Jul 31, 2005 at 12:25:14PM +0200, Kurt Roeckx wrote: The log was from amd64, but it failed on hppa too. Could you please try the attached patch to see if it fixes the problem? TIA, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- diff -u -r pcre-ocaml-5.10.0.bak/OCamlMakefile pcre-ocaml-5.10.0/OCamlMakefile --- pcre-ocaml-5.10.0.bak/OCamlMakefile 2005-07-31 12:30:25.0 +0200 +++ pcre-ocaml-5.10.0/OCamlMakefile 2005-07-31 12:30:59.0 +0200 @@ -886,6 +886,7 @@ else $(DLLSONAME): $(OBJ_LINK) $(OCAMLMKLIB) $(INCFLAGS) $(CLIBFLAGS) \ + -ccopt $(PIC_CFLAGS) \ -o $(CLIB_BASE) $(OBJ_LINK) $(CLIBS:%=-l%) \ $(OCAMLMKLIB_FLAGS) endif
Bug#320624: pcre-ocaml: FTBFS: Not using -fPIC to make a shared library.
On Sun, Jul 31, 2005 at 12:48:41PM +0200, Kurt Roeckx wrote: No it doesn't. You're now using -fPIC at link time while you should do it at compile time. Thanks, I will then wait for some feedback from OCamlMakefile upstream author since -fPIC should be handled properly by it without adding -fPIC to CPPFLAGS has you suggested. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320624: pcre-ocaml: FTBFS: Not using -fPIC to make a shared library.
On Sun, Jul 31, 2005 at 12:29:11PM +0200, Stefano Zacchiroli wrote: AFAICT the bug is in OCamlMakefile which fails to pass PIC_CFLAGS when inovking ocamlmklib. I thus suppose that adding -ccopt -fPIC in the $(DLLSONAME) rule would be enough. Still, since I don't know OCamlMakefile in detail I ask your advice on this. Dear Markus, since I will be away in the next days and I don't want the pcre-ocaml debian package to be unbuildable for long I applied a quick and dirty patch to OCamlMakefile, which simply passes -fPIC to the building of all .o thru ocamlc. There should be a better way ... Kurt, could you please try it on your amd64 box? Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- #! /bin/sh /usr/share/dpatch/dpatch-run ## 31_fpic.dpatch by Stefano Zacchiroli [EMAIL PROTECTED] ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: No description. @DPATCH@ diff -urNad --exclude=CVS --exclude=.svn ./OCamlMakefile /tmp/dpep-work.483SSF/trunk/OCamlMakefile --- ./OCamlMakefile 2005-06-09 01:42:12.0 +0200 +++ /tmp/dpep-work.483SSF/trunk/OCamlMakefile 2005-07-31 22:00:28.0 +0200 @@ -1011,6 +1011,7 @@ .c.$(EXT_OBJ): $(OCAMLC) -c -cc $(CC) -ccopt $(CFLAGS) \ + -fPIC \ $(CPPFLAGS) $(CPPFLAGS_WIN32) \ $(CFLAGS_WIN32) $(CINCFLAGS) $(CFLAG_O)$@ $ signature.asc Description: Digital signature
Bug#332283: ocamlnet_1.1-4 (unstable): fails to build
tags 332283 + moreinfo thanks On Wed, Oct 05, 2005 at 06:55:57PM +0200, Bastian Blank wrote: Package: ocamlnet Version: 1.1-4 Severity: serious There was an error while trying to autobuild your package: Automatic build of ocamlnet_1.1-4 on debian-31 by sbuild/s390 69 [...] Build-Depends: debhelper ( 4.0.0), ocaml-nox-3.08.3, libpcre-ocaml-dev (= 5.10), libequeue-ocaml-dev, ocaml-findlib, dpatch [...] Checking correctness of source dependencies... Toolchain package versions: libc6-dev_2.3.5-6 linux-kernel-headers_2.6.13+0rc3-1.1 gcc-4.0_4.0.2-1 g++-4.0_4.0.2-1 binutils_2.16.1cvs20050902-1 libstdc++6-4.0-dev_4.0.2-1 libstdc++6_4.0.2-1 [...] make[1]: Entering directory `/build/buildd/ocamlnet-1.1/src' for pkg in netstring cgi pop smtp nethttpd; do /usr/bin/make -C $pkg install || exit; done make[2]: Entering directory `/build/buildd/ocamlnet-1.1/src/netstring' test ! -d mappings || tools/unimap_to_ocaml/unimap_to_ocaml \ -o netmappings_iso.pmap -pmap mappings/iso*.unimap test ! -d mappings || tools/unimap_to_ocaml/unimap_to_ocaml \ -o netmappings_jp.pmap -pmap mappings/jis*.*map test ! -d mappings || tools/unimap_to_ocaml/unimap_to_ocaml \ -o netmappings_other.pmap -pmap mappings/cp*.unimap mappings/adobe*.unimap mappings/koi*.unimap mappings/mac*.unimap mappings/windows*.unimap ocamlfind ocamldep -package camlp4 -syntax camlp4o *.ml *.mli depend Error while loading pa_o.cmo: file not found in path. Preprocessing error make[2]: *** [depend] Error 2 make[2]: Leaving directory `/build/buildd/ocamlnet-1.1/src/netstring' make[1]: *** [install] Error 2 make[1]: Leaving directory `/build/buildd/ocamlnet-1.1/src' make: *** [install] Error 2 pa_o.cmo is part of the ocaml-nox binary package, and on my (i386) box is properly installed: $ locate pa_o.cmo /usr/lib/ocaml/3.08.3/camlp4/pa_o.cmo $ dpkg -S /usr/lib/ocaml/3.08.3/camlp4/pa_o.cmo ocaml-nox: /usr/lib/ocaml/3.08.3/camlp4/pa_o.cmo Is it the same on the s390 box who tried the build? Anyhow the bug seems to be on the ocaml-nox package and not in ocamlnet which indeed builds properly on a fresh sid (i386) pbuilder environment. Many thanks for your report. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#332283: ocamlnet_1.1-4 (unstable): fails to build
On Sat, Oct 08, 2005 at 09:59:03PM +0200, Bastian Blank wrote: Anyhow the bug seems to be on the ocaml-nox package and not in ocamlnet which indeed builds properly on a fresh sid (i386) pbuilder environment. s390 don't support native compiled code, maybe this is a problem. This is likely to be the reason, since looking at the build logs the build failed on all architectures which do not support native code compilation. I did a strace and got the following: | execve(/usr/bin/camlp4, [camlp4, -nolib, -I, /home/waldi/debian/tmp/ocamlnet/ocamlnet-1.1/camlp4, pa_o.cmo, pa_op.cmo, pr_dump.cmo, cgi.ml], [/* 33 vars */]) = 0 | stat64(/home/waldi/debian/tmp/ocamlnet/ocamlnet-1.1/camlp4/pa_o.cmo, 0x7fb29570) = -1 ENOENT (No such file or directory) | write(2, Error while loading \pa_o.cmo\: file not found in path.\n, 56) = 56 No trace of using the files in /usr/lib/ocaml/3.08.3/camlp4/. snip The build-environment is broken. Each second build it fails with | ocamlfind ocamlc -package unix pcre equeue -package camlp4 -syntax camlp4o -c nethttp.ml | File nethttp.ml, line 1, characters 0-1: | Could not find the .cmi file for interface nethttp.mli. This is strange indeed, I suspect a problem with ocaml-findlib on the affected architecture. It is that package responsible for invoking the compiler and preprocessor with the right parameters. How can I get an environment in which reproduce the problem? I tried logging on the s390 debian machine as well as the m68k one, but even if there are dchroots for sid there are no (or I failed to find them) pbuilders and of course I don't have the privileges to install the needed build dependencies ... Could you give me access to such an environment on s390? Thanks for your feedback. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#300848: doesn't work anymore: fatal error
On Tue, Mar 22, 2005 at 10:34:58AM +0100, Enrico Zini wrote: $ polygen Fatal error: cannot load shared library dllunix Reason: dllunix.so: cannot open shared object file: No such file or directory I didn't do anything! I swear! I trust you :) It looks like a side effect of some change in some Ocaml runtime. Zack, can you give me any clue? Actually we are in these days in the process of migrating from ocaml 3.08.2 to ocaml 3.08.3, and the first uploaded version of ocaml 3.08.3 is broken wrt dynamic loading of shared objects (like dllunix.so). _If_ polygen depends only on the ocaml runtime then you could solve the problem either getting ocaml 3.08.3-2 (actually in incoming and rebuilding) or by patching /usr/lib/ocaml/3.08.3/ld.conf so that it contains the following: /usr/local/lib/ocaml/3.08.3/stublibs /usr/lib/ocaml/3.08.3/stublibs instead of /usr/local/lib/ocaml/3.08/stublibs /usr/lib/ocaml/3.08/stublibs For references have a look at the thread starting here: http://lists.debian.org/debian-ocaml-maint/2005/03/msg00095.html In the meantime, you should reinstall the graphic SCSI mouse to connect a periferic. But pay attention: you either cannot boot an attachment, or never have to cancel the connector to overclock a pointer over a jumper over a pointer. I also suggest reinstalling the USB tea cup heater. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301141: liblablgtk2-ocaml: Fails to install because of wrong dependency on ocaml-base-3.08
On Thu, Mar 24, 2005 at 09:10:57AM +0100, Ralf Treinen wrote: Well, it still is a bug in unstable, even if we (the ocaml maintainers) know that it is only transitory. I have already tagged the bug report as pending and the RM has tagged it as sid , but I don't think it should be closed until a new liblablgtk2-ocaml is uploaded which is installable with ocaml-* from unstable. Well, according to the upload log lablgtk2 has already been uploaded and is installable. So it is appropriate to close this bug report. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#338932: postgresql-ocaml - FTBFS: Fatal error: the file install is not a bytecode executable file
On Sun, Nov 13, 2005 at 11:25:18PM +0100, Bastian Blank wrote: Automatic build of postgresql-ocaml_1.4.6-3 on debian-31 by sbuild/s390 69 [...] Installing library with ocamlfind ocamlfind install -ldconf /dev/null -destdir /build/buildd/postgresql-ocaml-1.4.6/debian/libpostgresql-ocaml-dev/usr/lib/ocaml/3.09.0 postgresql META libpostgresql_stubs.a postgresql.cma postgresql.cmi postgresql.mli dllpostgresql_stubs.so Fatal error: the file install is not a bytecode executable file Looking at the build log I can't figure out what's going on. Could you please install postgresql-ocaml build dependencies on the sid chroot of a debian development s390 machine? Since I suspect a problem with ocaml-findlib, installing also its build dependencies may save future work ... Thanks for the report, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#338935: Processed: Re: Bug#338935: ocaml-ssl - FTBFS: Fatal error: the file install is not a bytecode executable file
On Mon, Nov 14, 2005 at 07:03:42AM -0800, Debian Bug Tracking System wrote: Bug#338935: ocaml-ssl - FTBFS: Fatal error: the file install is not a bytecode executable file I'm aware of the problem, I'm waiting for an s390 admin to install findlib build dependencies to examine the problem ... -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#338935: ocaml-ssl - FTBFS: Fatal error: the file install is not a bytecode executable file
On Mon, Nov 14, 2005 at 04:23:56PM +0100, Julien Cristau wrote: this problem was introduced when findlib switched to using cdbs, and the if [ -x /usr/bin/ocamlopt ]; then dh_strip; else true; fi line was removed. I think the following patch should fix this issue: Gotcha!, many thanks for your hint. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#338932: postgresql-ocaml - FTBFS: Fatal error: the file install is not a bytecode executable file
reassign 338932 ocaml-findlib thanks The bug is related to ocaml-findlib and will be fixed with its forthcoming upload. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#339167: library package needs to be renamed (libstdc++ allocator change)
tags 339167 + confirmed pending thanks [ This bug has been reported against gdome2-xslt ] gdome2-xslt includes the ocaml bindings for the C library shipped. For this reason it must soon be transitioned from ocaml 3.08.3 to ocaml 3.09.0. I will rename the C++ part of the package contextually to the ocaml transition. Please avoid NMU for the C++ part in the meantime. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#340458: lablgtkmathview - FTBFS: ocamlfind: Package `gdome2' not found
On Wed, Nov 23, 2005 at 04:16:58PM +0100, Bastian Blank wrote: Automatic build of lablgtkmathview_0.7.2-3 on debian01 by sbuild/s390 79 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper ( 4.0.0), ocaml-nox (= 3.09.0), ocaml-findlib (= 1.1), liblablgtk2-ocaml-dev (= 2.6.0), libgdome2-ocaml-dev (= 0.2.3-3), libgtkmathview-dev (= 0.7.5), pkg-config [...] checking for ocamlc... yes checking for ocamlfind... yes checking for gdome2... ocamlfind: Package `gdome2' not found The problem is in version 0.2.3-3 of libgdome2-ocaml-dev which ships a fubar content in /usr/lib/ocaml/3.09.0/gdome2/ (almost nothing). Version 0.2.3-4 (already rebuilt for s390) is ok. If it is ok for you I propose to just rebuild lablgtkmathview against that version on s390 and avoid reuploading lablgtkmathview with a more tight build depends on libgdome2-ocaml-dev. After all 0.2.3-3 will disappear due to the c++ allocator change. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#340879: extlib: FTBFS: new, more restrictive coreutils mv
On Sat, Nov 26, 2005 at 06:00:01PM +0100, Roland Stigge wrote: building the package extlib in a clean sid build environment (with pbuilder) on i386 results in: Thanks for the patch. Upload which fixes this problem is coming soon. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#341002: uninstallable in unstable: please port to ocaml 3.09.0
Package: libgetopt-ocaml-dev Severity: grave As per subject: libgetopt-ocaml-dev is currently not installable on debian/unstable due to the transition to ocaml 3.09. Please port it. TIA, Cheers. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341290: uninstallable in unstable: please port to ocaml 3.09
Package: libdbi-ocaml-dev Severity: grave ocamldbi is currently uninstallable in unstable, porting the package to ocaml 3.09 is needed. Cheers. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338483: keeping vim outside of testing
This bug is keeping vim 6.4 out of testing. Could you please do one of the following: 1) port the package so that it works with vim 6.4 (if possible) 2) ask for help on the pkg-vim-maintainers mailing list, we can consider maintainaing vimacs collaboratively if you're interested (and if the package still work with vim 6.4, of course) 3) ask for its removal from the unstable archive Many thanks, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#300848: This is still present in sarge
On Tue, Apr 05, 2005 at 04:43:54PM +0200, Enrico Zini wrote: This bug is currently present in sarge. No, it is not. Versions of polygen in sarge works correctly with the ocaml version in sarge (just tried on an up-to-date testing machine). More exactly, there are at least two cases where this bug can cause breakage: Thus, if I understand correctly, you're saying that this _can_ be a bug if one of the two happens, am I wrong? If not, this bug should not be open in the BTS. 1. If someone using testing upgrades to the unstable ocaml If she do it via apt-pinning this is not an issue for the BTS: you get packages from unstable, you call for trouble. If not, how should she get the unstable ocaml? 2. if the ocaml transition makes it into testing and for any reason polygen will not enter testing at the same time, polygen in testing will be broken Here there is an issue indeed. The polygen version currently in testing doesn't adhere to the debian ocaml policy which require dependency on ocaml-base-nox-version, but rather depends only on ocaml-base-nox. Last polygen version uploaded by Enrico to unstable has the correct dependency. Thus, theorically, it is possible that the ocaml transition makes it into testing and polygen not. If that happens, then polygen will break. Still, that case is rather unlikely since all ocaml packages should enter testing at once and some of them are still being uploaded these days. Unstable's polygen can't enter testing before of them (due to the ocaml-base-nox-3.08.3 dependency), but since it has already been uploaded it will enter testing in the same run of the testing scripts as all the other ocaml packages. That said, I still see no reason to have this bug open in the BTS: at the moment we have no problem with polygen in sarge. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#304161: planets uninstallable in sid
Package: planets Version: 0.1.12-3 Severity: grave Planets is currently not installable in sid: # apt-get install planets Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: planets: Depends: ocaml-base-3.08 but it is not installable E: Broken packages Package dependencies (both Depends and Build-Depends) need to be ported to ocaml 3.08.3. Cheers. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.11-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages planets depends on: pn ocaml-base-3.08 Not found. ii tk8.4 8.4.9-1Tk toolkit for Tcl and X11, v8.4 - -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#304885: FTBFS on ia64
Package: ocamlcreal Severity: grave ocamlcreal failed to build from sources on ia64: http://buildd.debian.org/fetch.php?pkg=ocamlcrealver=0.4-6arch=ia64stamp=1113341294file=logas=raw at a first look it did not run configure before building the package and thus did not discover that ocamlc.opt was not available. I have no idea on why this happened only on ia64, maybe there is some issues with the toolchain. Still, the problem has to be faced since ocamlcreal is blocking the 3.08.3 transition. Could you please have a look at it? If the solution requires a new upload please upload with urgency (at least) medium. TIA, Cheers. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.11-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#352582: [Pkg-zope-developers] Bug#352582: enabling external editor render plone-instance unusable
On Sun, Feb 12, 2006 at 09:51:08PM +0100, Fabio Tranchitella wrote: Ciao Stefano, which version of plone are you using? $ dpkg -l plone* | grep ^ii ii plone 2.1.2-1content management system based on zope and cmf ii plone-site 2.1.2-1preconfigured zope instance containing a plone -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#352582: [Pkg-zope-developers] Bug#352582: enabling external editor render plone-instance unusable
On Sun, Feb 12, 2006 at 10:12:22PM +0100, Fabio Tranchitella wrote: Did you add the ExternalEditor package to the plone-site instance? Something like: # dzhandle -z 2.8 add-product plone-site ExternalEditor You're right, that was indeed the problem. I'm sorry, I'm quite a zope newbie. Still, may I suggests to document the required steps in README.Debian? Just mention to do dzhandle add-product / restart-pending-instances. The actual content of the README.Debian is quite useless while the proposed one could avoid future bug reports from newbies like me. (For this reason I'm not yet closing the report with this mail) Many thanks for your help, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#352582: [Pkg-zope-developers] Bug#352582: enabling external editor render plone-instance unusable
On Sun, Feb 12, 2006 at 11:09:21PM +0100, Fabio Tranchitella wrote: I'm not using my usual workstation and I can't check, but I suppose that README.Debian from zope-common package already explains the way Zope packages works in Debian. I looked at it and it's fine, but what I was suggesting is to document in the README.Debian of zope-externaleditor the steps needed to install it. It should be fine even to refer users to the README.Debian of zope-common. Anyhow, just a suggestion, feel free to close this bug report (which IMHO, is not relevant to zope-common). Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#356101: FTBFS: probably due to new make
Hi Martin, On Thu, Mar 09, 2006 at 06:09:57PM +, Martin Michlmayr wrote: Your package fails to build from source in unstable, probably because of the new make. gtkmathview relies only on cdbs and on its dpatch support: probably the problem resides in one of the two. I will look into it. Thanks for the report, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#356101: FTBFS: probably due to new make
On Thu, Mar 09, 2006 at 06:59:10PM +, Martin Michlmayr wrote: Oh, it's possible that it's a cdbs problem. Unfortunately, cdbs isn't really maintained much anymore. What? Are you kidding? A lot of packages depend on it, is it really not maintained? This will be a real problem for many of us ... I don't know cdbs at all. Do you think you can investigate? Well, I know it only as an user, not as a cdbs developer. I will try to do my best ..., but I wont have time to work on it until the next week for sure. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356101: RC bug patches
On Fri, Mar 10, 2006 at 04:11:02AM -0800, Matt Kraai wrote: It appears to be a bug in gtkmathview. cdbs provides the following single-colon rule: unpatch: deapply-dpatches snip gtkmathview contains the following double-colon rule in its debian/rules: unpatch:: deapply-dpatches That line was a temporary patch (read: huge hack) related to #284231. Now that the bug is fixed in cdbs (thanks Peter!) that line can be removed. Thanks for the patch, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#384019: Open Publication License DFSG-freeness
On Fri, Sep 01, 2006 at 04:34:04PM +0100, James Troup wrote: Is Vim's manual distributable in main or do we need to move it to non-free? The OPL without options is fine for main. Thanks for the info. Still, I can't help asking you something more: - are we talking about the same OPL (in this bug report we are talking about the one at http://opencontent.org/openpub/)? - which motivation do you have to sustain this thesis? I mean, I can close this bug report as I feel your opinion on this is more trustworthy than mine, but what if tomorrow another guy from debian-legal ask for this bug to be reopened? Thanks for taking time for this issue. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#385356: lablgtksourceview: FTBFS: relocation R_X86_64_32 against `ml_table_source_search_flag' can not be used when making a shared object
tags 385356 + pending thanks On Sat, Sep 02, 2006 at 06:11:10AM +0200, Julien Cristau wrote: Actually -fPIC is used inconsistently. It is part of the compile flags, but not used at link time, which (I think) causes this FTBFS. The attached patch should fix this. Tnx for the patch. Actually, the one I applied to the package came from Maxence Guesdon, and consists in letting ocamlc compile all .c files, so that -fPIC is (consistently) used depending on the architecture where the package is being built. By the way, lablgtksourceview is currently a native package; is this intended? Yes. I used to follow the scheme x.y.z-k even for native debian packages. Incrementing only the k component when changes where applied only to the debian packaging, not inducing a new upstream release. Nowadays it seems that the debian packaging tools are more and more discouraging this practice (see the quite new lintian warning); I will eventually quit this practice ..., even I don't think there's anything wrong with that. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#387319: ocamldap needs to be rebuilt against the new pcre-ocaml
Package: libldap-ocaml-dev Version: 2.1.8-1 Severity: serious After my upload of libpcre-ocaml-dev 5.11.1-1 ocamldap needs to be rebuilt against it: [EMAIL PROTECTED]:~$ ledit ocaml Objective Caml version 3.09.2 Findlib has been successfully loaded. Additional directives: #require package;; to load a package #list;; to list the available packages #camlp4o;;to load camlp4 (standard syntax) #camlp4r;;to load camlp4 (revised syntax) #predicates p,q,...;; to set these predicates Topfind.reset();; to force that packages will be reloaded #thread;; to enable threads # #require ocamldap;; /usr/lib/ocaml/3.09.2/pcre: added to search path /usr/lib/ocaml/3.09.2/pcre/pcre.cma: loaded /usr/lib/ocaml/3.09.2/unix.cma: loaded /usr/lib/ocaml/3.09.2/netstring: added to search path /usr/lib/ocaml/3.09.2/netstring/netstring.cma: loaded /usr/lib/ocaml/3.09.2/netstring/netstring_top.cmo: loaded /usr/lib/ocaml/3.09.2/netstring/netaccel.cma: loaded /usr/lib/ocaml/3.09.2/netstring/netaccel_link.cmo: loaded /usr/lib/ocaml/3.09.2/netstring/compatcgi.cma: loaded /usr/lib/ocaml/3.09.2/str.cma: loaded /usr/lib/ocaml/3.09.2/ssl: added to search path /usr/lib/ocaml/3.09.2/ssl/ssl.cma: loaded /usr/lib/ocaml/3.09.2/ocamldap: added to search path /usr/lib/ocaml/3.09.2/ocamldap/ocamldap.cma: loaded The files /usr/lib/ocaml/3.09.2/ocamldap/ocamldap.cma and /usr/lib/ocaml/3.09.2/pcre/pcre.cma disagree over interface Pcre Let me know if you want an NMU for that. Cheers. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Versions of packages libldap-ocaml-dev depends on: ii libocamlnet-ocaml-dev 1.1-12 OCaml application-level Internet p ii libssl-ocaml-dev 0.3.1-5OCaml bindings for OpenSSL ii ocaml-nox [ocaml-nox-3.09.2] 3.09.2-6 ML language implementation with a libldap-ocaml-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378721: vim-lesstif: gvim always crashes during startup
On Wed, Jul 19, 2006 at 02:48:25PM +0400, Andrey Kiselev wrote: Lesstif variant of gvim does not work on my system and crashes during startup. There is backtrace log from the gdb: In addition I have built vim package using libmotif from unstable (2.2.3-1.4) and it works just fine. So it is most likely a problem with lesstif, but it renders vim-lesstif completely unusable. Could you please compare the versions of lesstif against which yours (fixed) binary works and ours (broken) binary does not? It would be a lot helpful ... Many thanks in advance, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#381406: gdome2-xslt: FTBFS: ld: cannot find -lz
reassign 381406 libgdome2-cpp-smart-dev thanks On Fri, Aug 04, 2006 at 08:45:02AM +0200, Julien Danjou wrote: package: gdome2-xslt version: 0.0.7-4 severity: serious hello, There was a problem while autobuilding your package: snip g++ -g -Wall -O2 -o .libs/test main.o -lz -lm /usr/lib/libgmetadom_gdome_cpp_smart.so /usr/lib/libgdome.so /usr/lib/libglib-2.0.so /usr/lib/libxslt.so /usr/lib/libxml2.so ../../C++/gdome_xslt/.libs/libgdome_xslt_cpp_smart.so /usr/bin/ld: cannot find -lz Thanks for the bug report, I was not aware of this issue. Still, the problem apparently come from gmetadom, as gdome2-xslt does not use zlib at all and correctly does not declare any kind of dependency toward it. gmetadom OTOH has a -lz flag in its pkg-config file, but does not declare a proper dependency on zlib. Now, wearing my gmetadom maintainer's hat :-), I'm investigating upstream weather that dependency is spurious and than should be removed from the pkg-config file or if it is actually useful and then should be listed as a dependency against zlib. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#382205: vim-latexsuite: Plugin doesn't seems to load
tags 382205 + moreinfo unreproducible thanks On Wed, Aug 09, 2006 at 05:13:24PM +0100, Joao Paulo Pinto Trindade wrote: Package: vim-latexsuite Version: 20060325-1 Severity: grave Justification: renders package unusable It seems that vim doesn't load the plugin. I can't reproduce it here. Note that the plugin is loaded only when a file recognized as a filetype 'tex' is loaded. Note also that if you open an empty .tex file that file will be recognized as a filetype 'plaintex', not 'tex', and this will not trigger the loading of the vim-latexsuite. Please try checking if the file you are working on is recognized as filetype 'tex' (you can check this by simply executing :set ft). If this is not the case you can manually trigger the loading of the latexsuite by setting :set ft=tex, which you probably want to do anyhow if you are writing LaTeX instead of plain TeX. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#384019: vim-runtime: [NONFREE-DOC:OPL] vim's user manual and reference manual are not DFSG free
On Mon, Aug 21, 2006 at 11:55:17PM +1200, Carlos Z.F. Liu wrote: Package: vim-runtime Version: 1:7.0-035+1 Severity: serious Justification: DFSG Hi, Currently, part of vim's documents (user manaul and reference manual) are using OPL license, which is considered as DFSG-incompatible[1]. You can verify this info by typing :help manual-copyright in vim editor. Actually :help manual-copyright is incoherent about what license applies to the manual. It states: This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later. The latest version is presently available at: http://www.opencontent.org/opl.shtml (same license name for the book, no URL there) The license pointed to by the URL however it is not the Open Publication License v1.0 (which is indeed non-free according to debian-legal), but rather the OpenContent License v1.0, for which I've found no discussion on debian-legal (nor it is mentioned in [1]). So, this is an issue: discover which license applies to the book and to the manual. Other sources make me think that the Open Publication License is indeed the license that applies to it, but it should be verified: - http://www.moolenaar.net/vim_errata.html - http://www.gnu.org/doc/other-free-books.html We will get in touch with upstream to discover which is the case. Thanks for the bug report. Cheers. [1] http://wiki.debian.org/DFSGLicenses -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#384019: manual-copyright clarification
On Tue, Aug 22, 2006 at 09:52:14PM +0200, Bram Moolenaar wrote: The name Open Publication License is right, the URL was wrong. Could you please correct the URL then? I guess the following is the correct one: http://opencontent.org/openpub/ The book by Steve Oualline uses this license, I used it for the Vim documentation to avoid any trouble. Otherwise I don't care much what license is used exactly. So we have quite a problem in Debian now, regarding the Vim Manual :-( The Open Publication License is not a free license according to the Debian Free Software Guidelines [1]. This has been discussed on the debian-legal mailing list, the conclusion and the discussions are available in the Debian wiki [2]. The bug report Cc-ed is a bug raising this issue [3]. As the things are now, we will be forced to remove the vim manual from the free section of the Debian archive and move it to non-free. Users will then be able to install vim with the default debian configuration, but wont be able to do it without adding the non-free archives to their repository configuration. I fear that this would also mean that vim wont be the standard vi-like editor in the debian distribution :-(( Do you think it is possible to relicense the manual under a different license? (The best possible is usually the same that applies to the source code of the program itself). How many parts are taken from Oualline's book? Is it possible to rewrite them? We are of course willing to help in that, but maybe we are luckily enough that no more parts took from the book are still in the help ... Many thanks in advance, Cheers. [1] http://www.debian.org/social_contract#guidelines [2] http://wiki.debian.org/DFSGLicenses#head-add2e754f3a906f07e4ff1c050a2548f04ef4cbe [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384019 -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#384019: manual-copyright clarification
On Wed, Aug 23, 2006 at 11:24:31PM +0200, Bram Moolenaar wrote: The name Open Publication License is right, the URL was wrong. Could you please correct the URL then? I guess the following is the correct one: I have changed it. The ftp server will soon have the updated files. Thanks. Do you think it is possible to relicense the manual under a different license? (The best possible is usually the same that applies to the source code of the program itself). How many parts are taken from Oualline's book? Is it possible to rewrite them? We are of course willing to help in that, but maybe we are luckily enough that no more parts took from the book are still in the help ... It sounds like you are splitting hairs. As far as I know the OPL is a free license, since it allows distribution and modification. What part of the OPL makes it non-free? The OPL (meaning in this mail Open Publication License, since the same acronym is used for the Open Content License) is at the very minimum a license whose freeness is debatable. A few fact to argument this. * The Free Software Foundation itself consider the license as a free documentation license ONLY IF none of the License Options are exercised. I don't know what is the case of the Vim documentation. See http://www.fsf.org/licensing/licenses/ * The license is not OSI approved (it is not listed on http://www.opensource.org/licenses/) * The debian-legal as determined it as non DFSG-free (see http://wiki.debian.org/DFSGLicenses#head-add2e754f3a906f07e4ff1c050a2548f04ef4cbe) This latter point is motivated by two, IMO minor, points (the first and the third of http://lists.debian.org/debian-legal/2004/03/msg00226.html), and by an additional major point, namely the license fails to pass the dissident test (see http://people.debian.org/~bap/dfsg-faq.html). The reason is that every modification to a document published under this license must be owned by an identified author. This is the verbatim text of the test: # The Dissident test. Consider a dissident in a totalitarian state who wishes to share a modified bit of software with fellow dissidents, but does not wish to reveal the identity of the modifier, or directly reveal the modifications themselves, or even possession of the program, to the government. Any requirement for sending source modifications to anyone other than the recipient of the modified binary---in fact any forced distribution at all, beyond giving source to those who receive a copy of the binary---would put the dissident in danger. For Debian to consider software free it must not require any such excess distribution. While I think (but this is a personal opinion) that the minor points could be ignored for inclusion of the vim documentation in the debian distribution, I don't think the latter aspect could be. We would probably be forced to remove the vim documentation from the debian distribution, moving it to non-free :-((( Since I don't want that ... while on the Debian side I'm trying to get comments from the people responsible of accepting stuff into the archive ... on the Bram side I would like to know how hard it would be to relicense the manual under a different license. Could you please comment on that? Many thanks in advance, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#384019: manual-copyright clarification
On Mon, Aug 28, 2006 at 11:25:00PM +0200, Bram Moolenaar wrote: None of the options is used. Thus according to FSF this is a free license. Good to know. additional major point, namely the license fails to pass the dissident test (see http://people.debian.org/~bap/dfsg-faq.html). The reason is that every modification to a document published under this license must be owned by an identified author. This is the verbatim text of the test: This is a bogus point in my opinion. Since copyright is automatically given by creating something, every text should have the author mentioned and/or is automatically associated to it. Thus this is actually implied in every created work, no matter if it is mentioned in the license or not, since law goes above a license. The solution is to use a fantasy name for the author. There is nothing to stop someone from doing that, as far as I know. And the license used is irrelevant. It it not a bogus point, according to my interpretation of the license. The text of the license states: All modified versions of documents covered by this license, including translations, anthologies, compilations and partial documents, must meet the following requirements: 3. The person making the modifications must be identified and the modifications dated. That identified to me sounds like forbidding the use of a fantasy name; the dissident of the test will be breaking the license using a fantasy name. Note that IANAL, nor one of the guy who decided the license is not DFSG-free, still I can understand the point. We would probably be forced to remove the vim documentation from the debian distribution, moving it to non-free :-((( I think that's your problem. Requiring authors to use exactly the license you approve of is actually close to dictatorial behavior. It is our problem, but is also a problem for our users, and I believe it would be a pity for the vim community as well. Note that we are not requiring to use exactly a particular license, we have guidelines for what we believe is free, and several licenses are free according to our guidelines. OPL simply does not happen to be one of them. Please consider losing the rules a bit, so that you can actually claim to have a free operating system. ... it is free precisely as long as we have the rules :-) YMMV. Note also that we, as package maintainer of vim, have no particular power in deciding whether the license is ok or not, it is a matter up to the whole body of Debian developers. Could you please comment on that? In my opinion the docs go under a free license, I don't see a reason to change it. And I actually can't change it, since I used text from Steve Oualline's book in the user manual, and that text uses this license. Well, there is the way of contacting both the author and the publisher to see if they agree to license the text also under the terms of some other license. Note that I'm not asking you to do so, we can do that. But that would be pointless if you're not interested in relicensing under another license the part of the manual that you have written by yourself. Are you interested in that? Many thanks for this discussion, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#396707: fails to start: double free or corruption (or segfault ...)
Package: gtkpod Version: 0.99.4-1 Severity: grave Since some weeks gtkpod fails to start. Without libc6-i686 installed the error message is quite informative: [EMAIL PROTECTED]:~$ gtkpod *** glibc detected *** double free or corruption (out): 0x08410f30 *** Aborted [EMAIL PROTECTED]:~$ Seems to be a double free. With libc6-i686 installed it simply segfaults on start up. I guess the difference is due to some more careful checking of the plain libc, but the issue stands: gtkpod is not usable at the moment. I attach a stack backtrace and a (gzipped) strace, in case it helps. Cheers. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Versions of packages gtkpod depends on: ii libatk1.0-01.12.3-1 The ATK accessibility toolkit ii libc6 2.3.6.ds1-7 GNU C Library: Shared libraries ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.1-2 generic font configuration library ii libglade2-01:2.6.0-2 library to load .glade files at ru ii libglib2.0-0 2.12.4-1 The GLib library of C routines ii libgpod0 0.4.0-0.3 a library to read and write songs ii libgtk2.0-02.8.20-3 The GTK+ graphical user interface ii libid3tag0 0.15.1b-8 ID3 tag reading library from the M ii libpango1.0-0 1.14.7-1 Layout and rendering of internatio ii libx11-6 2:1.0.3-2 X11 client-side library ii libxcursor11.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxi6 1:1.0.1-3 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxml22.6.27.dfsg-1 GNOME XML library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender11:0.9.1-3 X Rendering Extension client libra ii zlib1g 1:1.2.3-13compression library - runtime gtkpod recommends no packages. -- no debconf information gtkpod.strace.gz Description: Binary data [New Thread -1221096528 (LWP 20745)] *** glibc detected *** double free or corruption (out): 0x08410f30 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1219615040 (LWP 20742)] 0xb75fb947 in raise () from /lib/tls/libc.so.6 (gdb) bt #0 0xb75fb947 in raise () from /lib/tls/libc.so.6 #1 0xb75fd0c9 in abort () from /lib/tls/libc.so.6 #2 0xb7630fda in __fsetlocking () from /lib/tls/libc.so.6 #3 0xb763889f in mallopt () from /lib/tls/libc.so.6 #4 0xb7638942 in free () from /lib/tls/libc.so.6 #5 0xb775ab31 in g_free () from /usr/lib/libglib-2.0.so.0 #6 0xb7746ff1 in g_hash_table_unref () from /usr/lib/libglib-2.0.so.0 #7 0xb774706b in g_hash_table_destroy () from /usr/lib/libglib-2.0.so.0 #8 0xb77d3338 in itdb_device_free () from /usr/lib/libgpod.so.0 #9 0xb77d33c7 in itdb_device_read_sysinfo () from /usr/lib/libgpod.so.0 #10 0xb77d35b4 in itdb_device_set_mountpoint () from /usr/lib/libgpod.so.0 #11 0xb77c030a in itdb_set_mountpoint () from /usr/lib/libgpod.so.0 #12 0x08072ef1 in init_data () #13 0x08088fb2 in main ()
Bug#396707: closed by Frank Lichtenheld [EMAIL PROTECTED] (Re: Bug#396707: Confirmed)
On gio, 2006-11-02 at 14:48 -0800, Debian Bug Tracking System wrote: Don not use libgpod 0.4.0 from Marillat. It is neither API nor ABI compatible to previous versions. Which is why I didn't upload it yet. Upstream needs to change the SONAME first... Ah, right, that was it. I didn't notice that the newer version of libgpod were coming from debian-multimedia. Thanks for the tip. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema? /\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344150: vim: FTBFS on hppa
tags 344150 + pending thanks On Tue, Dec 20, 2005 at 01:29:26PM +0100, Matthijs Mohlmann wrote: Package: vim Version: 1:6.4-001+2 Severity: serious Hi, vim fails to build from source on an hppa: Mea culpa, but already fixed in the SVN version of vim. The current related debian/changelog line is: vim (1:6.4-004+2) UNRELEASED; urgency=low [ Stefano Zacchiroli ] * debian/rules: finally found the karma of target-specific variables, hopefully the file is clearer now ... I will detail it more, explaining that it fixes the FTBFS on hppa. I couldn't find out why it stops right there. I'll take look on it later. It stops on dh_testdir which don't know some option... but it builds fine on the other architectures, I'm not yet sure what causes this. I think it's related to some difference in debhelper and/or make, but there was indeed some messed up interaction among debian/rules variable and environment variable due to a misuse of 'export' in debian/rules. Now it should be fixed (i.e. it used to be broken on my laptop as well, with the same error as hppa, but now is fixed). Have a look at the SVN diff on debian/rules for moreinfo. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#344368: conflicts with vim-common
On Wed, Dec 21, 2005 at 09:13:01PM -0800, Joshua Kwan wrote: Package: vim-runtime Version: 1:6.4-004+1 Severity: grave Unpacking replacement vim-runtime ... dpkg: error processing /var/cache/apt/archives/vim-runtime_1%3a6.4-004+2_all.deb (--unpack): trying to overwrite `/usr/bin/vimtutor', which is also in package vim-common dpkg-deb: subprocess paste killed by signal (Broken pipe) vim-runtime should Replace vim-common. It does: Package: vim-runtime Replaces: vim-common ( 6.4-004+2), ... are you sure you're upgrading against the latest versions? Which frontend are you using to upgrade (apt/dselect/aptitude/...)? I don't understend how you can have the reported behaviour ... Thanks for the report. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#344368: non-epoched versioned dependencies in debian/control
retitle 344368 non-epoched versioned dependencies in debian/control thanks On Thu, Dec 22, 2005 at 08:43:15AM +0100, Stefano Zacchiroli wrote: dpkg: error processing /var/cache/apt/archives/vim-runtime_1%3a6.4-004+2_all.deb (--unpack): It does: Package: vim-runtime Replaces: vim-common ( 6.4-004+2), ... I'm noticing only now a big bug in vim's debian/control. All Replaces/Recommends/... versioned dependencies are against the non-epoched versions (i.e. in the example above it should be 1:6.4-004+2, instead of 6.4-004+2)!!! This is the cause of the missed Replaces. We should fix it and upload soon. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#344658: vim - FTBFS: cp: cannot stat `./debian/tmp/usr/bin/rview': No such file or directory
On Sat, Dec 24, 2005 at 02:04:16PM +0100, Bastian Blank wrote: Package: vim Version: 1:6.4-006+1 Severity: serious There was an error while trying to autobuild your package: Automatic build of vim_1:6.4-006+1 on debian-31 by sbuild/s390 79 [...] dh_install -X.svn cp: cannot stat `./debian/tmp/usr/bin/rview': No such file or directory dh_install: command returned error code 256 make: *** [install-stamp-vim-tiny] Error 1 Which version of make is installed in the autobuilder environment? If it is the same that is installed in the sid chroot on raptor.debian.org (3.80), then the responsible is probably make. In particular, vim's debian/rules uses 'export' target specific variables, for example: install-stamp-%: export DH_OPTIONS=-p$* Apparently they were not supported in earlier version of make. (And no, I was not aware of this non-backward compatibility, otherwise I would have set an appropriate build-depends). You can check if they are supported or not looking at 'info make' and searching for 'Target-specific Variable'. If they are supported you should see in the first screen something like: or like this: TARGET ... : export VARIABLE-ASSIGNMENT If they're not supported, could you please try to upgrade the version of make to the latest in unstable and try again the build? Alternatively, it would be enough to install it on raptor's sid chroot. I will try it. (I believe you're that chroot's maintainer ...) Thanks for the report. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#344658: vim - FTBFS: cp: cannot stat `./debian/tmp/usr/bin/rview': No such file or directory
On Mon, Dec 26, 2005 at 11:01:05AM +0100, Stefano Zacchiroli wrote: raptor.debian.org (3.80), then the responsible is probably make. In particular, vim's debian/rules uses 'export' target specific variables, for example: I changed debian/rules so that this feature is no longer used. The patched version of vim I have builds properly on a sarge chroot and in the sid chroot available on raptor.debian.org. Does this imply that it will build properly even on the s390 auto-builder? If you want to test it, the patched source package is available on raptor.debian.org in /home/zack. Or, alternatively, on the web at http://people.debian.org/~zack/stalla/ Please let me know if you can test it in advance or if you like us to upload this version and wait the auto-builder do its work. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#501423: build-dep of gossip now fixed, need to be hinted
block 501423 by 494940 thanks Hi Nobse, On Tue, Oct 07, 2008 at 08:25:12PM +0200, Norbert Tretkowski wrote: Are you saying that gossip should be removed from testing and therefore removed from the release? No. But we now really need a fix for the loudmouth RC bug. AFAICT, the bug you were referring to from #501423 was #494940, which now is fixed. Is that correct? Hence, gossip just need a hint to enter testing, it was needing just 2 days, 4 are elapsed, but of course it is blocked by the freeze. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501423: please unblock loudmouth 1.4.2-2 / reschedule gossip 1:0.31-1
Hi, loudmouth 1.4.2-2 is needed in testing to let gossip (which is in testing already) have all its needed build-deps. See #501423. There was an additional bug blocking loudmouth, #494940, which has been fixed by Löic 5 days ago. Since then loudmouth has been rebuilt everywhere and is apparently read to transition. Can you please unblock loudmouth 1.4.2-2, so that build-deps of gossip get satisfied in lenny, and then reschedule building in testing of gossip/1:0.31-1? FWIW, I do have tried building gossip in lenny against loudmouth 1.4.2-2 and it worked fine. TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501423: please unblock loudmouth 1.4.2-2
On Sun, Oct 26, 2008 at 12:18:22AM +0200, Stefano Zacchiroli wrote: Can you please unblock loudmouth 1.4.2-2, so that build-deps of gossip get satisfied in lenny, and then reschedule building in testing of gossip/1:0.31-1? Checking twice, only the unblock of loudmouth/1.4.2-2 is needed, as gossip/1:0.31-1 has already been rebuilt against the same version of loudmouth I'm requesting to unblock. Hence, I restrict my request to just: please unblock loudmouth/1.4.2-2. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434647: NMU is coming
I'm going to NMU to unstable a fixed version of kaffe as soon the build is complete. Attached you can find the current debdiff. AFAICT Patrick's patch was missing the fix for kaffe's pre*inst*. The attached patch fixes that as well. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach diff -u kaffe-1.1.8/debian/kaffe.prerm kaffe-1.1.8/debian/kaffe.prerm --- kaffe-1.1.8/debian/kaffe.prerm +++ kaffe-1.1.8/debian/kaffe.prerm @@ -6,7 +6,6 @@ if [ $1 != upgrade ] ; then for file in appletviewer jar java javac javadoc javah javakey javap jdb native2ascii rmic rmiregistry serialver ; do update-alternatives --remove $file /etc/alternatives/kaffe-system/bin/$file || true - update-alternatives --auto $file || true done fi diff -u kaffe-1.1.8/debian/kaffe.preinst kaffe-1.1.8/debian/kaffe.preinst --- kaffe-1.1.8/debian/kaffe.preinst +++ kaffe-1.1.8/debian/kaffe.preinst @@ -5,7 +5,6 @@ if [ $1 = upgrade ] ; then for file in appletviewer jar java javac javadoc javah javakey javap jdb native2ascii rmic rmiregistry serialver ; do update-alternatives --remove $file /usr/lib/kaffe/bin/$file || true - update-alternatives --auto $file || true done fi diff -u kaffe-1.1.8/debian/changelog kaffe-1.1.8/debian/changelog --- kaffe-1.1.8/debian/changelog +++ kaffe-1.1.8/debian/changelog @@ -1,3 +1,12 @@ +kaffe (2:1.1.8-5.2) unstable; urgency=high + + * Non-maintainer upload. + * Avoid making kaffe the default java compiler upon configuration, +overriding local choices. Thanks to Patrick Schoenfeld for the patch. +Closes: #434647 + + -- Stefano Zacchiroli [EMAIL PROTECTED] Sun, 26 Oct 2008 19:25:03 +0100 + kaffe (2:1.1.8-5.1) unstable; urgency=low * Non-maintainer upload. diff -u kaffe-1.1.8/debian/jikes-kaffe.prerm kaffe-1.1.8/debian/jikes-kaffe.prerm --- kaffe-1.1.8/debian/jikes-kaffe.prerm +++ kaffe-1.1.8/debian/jikes-kaffe.prerm @@ -3,7 +3,6 @@ case $1 in upgrade | remove) update-alternatives --remove javac /usr/bin/jikes-kaffe || true -update-alternatives --auto javac || true ;; esac
Bug#503616: libapache2-mod-ocamlnet: mod_netcgi_apache.so will not load
On Mon, Oct 27, 2008 at 01:44:01PM +0100, Stéphane Glondu wrote: 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: Replacing the last line of /etc/apache2/mods-enabled/netcgi_apache.load (the one mentioning netcgi_apache.cma) to: NetcgiLoad netcgi_apache/netcgi_apache.cma First of all thanks for the bugreport, the risk of overlooking this serious issue for Lenny was quite high :) Then, we have two issues here: 1) The wrong path in netcgi_apache.load, pointed out (together with a fix) by Stéphane. That's easily fixable, I can upload a fixed version of ocamlnet RSN. 2) The fact that camlrun_shared.so is not in a path known by ld.so. Which is a hell of a more tricky issue. On one hand one might argue that that library should belong to /usr/lib/ (or to some other dir known by ld.so). I frankly don't think so, because it is a high unstable library, introduced only recently upstream, ... and I don't want (yet) to take over the burden of version it with SONAMEs/VERSIONs/... *If* we decide it should belong /usr/lib/, then the most straightforwards solutions are: a) symlink /usr/lib/libcamlrun_shared.so - `ocamlc -where`/... b) entry for `ocamlc -where` in /etc/ld.so.conf.d/ Both will require an upload of OCaml, which will make two uploads in total because ocamlnet needs to be fixed anyhow. 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. Comments? Cheers. [1] http://wiki.debian.org/RpathIssue [2] http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Bug#503616: libapache2-mod-ocamlnet: mod_netcgi_apache.so will not load
tags 503616 + pending thanks On Tue, Oct 28, 2008 at 11:43:52PM +0100, Stéphane Glondu wrote: 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: OK, thanks for the feedback. FWIW, I do have the fix now, but it still need some more polishing. Tomorrow I finalize it, and ask on -release what is for them the preferred way to receive the fix for Lenny (either upload via testing-proposed-updates or upload via unstable + unblock request). Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Bug#503616: RFC: how to push the fix for #503616 (and on the fix itself)
tags 503616 + patch thanks Dear -release-rs, how should I push the fix for #503616? Via t-p-u or unstable + unblock request? Long story: only recently it has been brought to my attention #503616 which affects an Apache module currently in testing. I do have a fix already, but it involves using an -rpath. Still, I do believe it is possible one of the few proper usages of -rpath, my reasoning is in the bug log, and is agreed upon by other Debian OCaml members. Also, this solution permits to fix only ocamlnet in Lenny, while the other (rpath-free) solution I envisaged would require fixing both ocamlnet and ocaml in the Lenny timeframe. (... and we do not think it is the right solution.) Now, my question is how should I push the fix: via t-p-u or via unstable + unblock request? The diff to the latest ocamlnet version in Lenny is attached for review. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach diff --git a/debian/changelog b/debian/changelog index 0cbcf4d..d969761 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,14 @@ +ocamlnet (2.2.9-3+lenny1) testing-proposed-updates; urgency=low + + * add rpath pointing at `ocamlc -where` to the Apache module shipped by +libapache2-mod-ocamlnet, so that libcamlrun_shared.so can be found +(Closes: #503616) + * fix wrong path in /etc/apache2/mods-available/netcgi_apache.load, which +inhibited proper loading of netcgi .cma library +(also needed to fix #503616) + + -- Stefano Zacchiroli [EMAIL PROTECTED] Wed, 29 Oct 2008 00:09:07 +0100 + ocamlnet (2.2.9-3) unstable; urgency=medium [ Stephane Glondu ] diff --git a/debian/etc/netcgi_apache.load b/debian/etc/netcgi_apache.load index a4b51fb..a105813 100644 --- a/debian/etc/netcgi_apache.load +++ b/debian/etc/netcgi_apache.load @@ -4,4 +4,4 @@ NetcgiLoad netsys/netsys.cma NetcgiLoad netstring/netstring.cma NetcgiLoad str.cma NetcgiLoad netcgi2/netcgi.cma -NetcgiLoad netcgi2-apache/netcgi_apache.cma +NetcgiLoad netcgi_apache/netcgi_apache.cma diff --git a/debian/patches/00list b/debian/patches/00list index b899fa0..09ac5b0 100644 --- a/debian/patches/00list +++ b/debian/patches/00list @@ -1,5 +1,6 @@ camlp5_5_alias_pat.dpatch camlrun_shared.dpatch +rpath-apache.dpatch dont_install_gpl.dpatch mkdir_destdir.dpatch missing_shebangs.dpatch diff --git a/debian/patches/rpath-apache.dpatch b/debian/patches/rpath-apache.dpatch new file mode 100755 index 000..ebe6a0a --- /dev/null +++ b/debian/patches/rpath-apache.dpatch @@ -0,0 +1,20 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## rpath-apache.dpatch by Stefano Zacchiroli [EMAIL PROTECTED] +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: add rpath to Apache module, pointing to `ocamlc -where` +## DP: rationale: ensure libcamlrun_shared.so can be found + [EMAIL PROTECTED]@ +diff -urNad ocamlnet~/src/netcgi2-apache/Makefile.def ocamlnet/src/netcgi2-apache/Makefile.def +--- ocamlnet~/src/netcgi2-apache/Makefile.def 2008-10-29 00:19:10.175784001 +0100 ocamlnet/src/netcgi2-apache/Makefile.def 2008-10-29 00:19:56.095780612 +0100 +@@ -46,7 +46,7 @@ + ### Embed Caml code into the C code. + ### Requires `caml_startup' instead of `caml_main' in handler.c + mod_netcgi_apache.so: $(MOD_OBJECTS) +- $(APXS) -c -o $@ $^ -L$(APACHE_OCAMLLIBDIR) $(patsubst -lcamlrun,-lcamlrun_shared,$(APACHE_OCAMLLIBS)) ++ $(APXS) -c -o $@ $^ -L$(APACHE_OCAMLLIBDIR) -Wl,--rpath,$(APACHE_OCAMLLIBDIR) $(patsubst -lcamlrun,-lcamlrun_shared,$(APACHE_OCAMLLIBS)) + test -f .libs/$@ cp .libs/$@ . + + netcgi_apache_mod.lo: netcgi_apache_mod.o
Bug#503616: libapache2-mod-ocamlnet: mod_netcgi_apache.so will not load
On Wed, Oct 29, 2008 at 01:06:06PM +, Richard Jones wrote: We'll probably do an rpath for this in Fedora, since it seems to be the simplest and least intrusive solution. I've did the same in fact, the patch is at: http://git.debian.org/?p=pkg-ocaml-maint/packages/ocamlnet.git;a=blob;f=debian/patches/rpath-apache.dpatch;h=ebe6a0a3c745c20905f9bea4710e49fe587c2f6f;hb=fb8004e8cb22e2b5c134cd2a2c541564314276fd. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Bug#503616: closed by Stefano Zacchiroli [EMAIL PROTECTED] (Bug#503616: fixed in ocamlnet 2.2.9-3+lenny1)
On Thu, Oct 30, 2008 at 07:57:29AM -0700, Dave Benjamin wrote: Thanks for looking into this issue. I will try the module again as soon as I can find the updated packages in unstable. Were you able to get it to load successfully? Yes, sure, I was able to. The package is already available also in unstable: ocamlnet/2.2.9-4. I am concerned that there might be a third problem, since I added the ocaml lib directory to my ld.so.conf (as described in the bug report) and I was still getting an error message about the sqrt symbol not being found. I don't understand what sqrt it is talking about (glibc? Pervasives?), or what might cause that to happen... The problem was double (as discussed in the bug log): inability to find the .so and inability to find the .cma. The first part has been addressed adding an -rpath, the second part by fixing the wrong path in the *.load Apache snippet. The second part fixes also the sqrt problem, given that .cma files contain (once found) all the references needed to load additional libraries. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Bug#505490: ocaml-batteries_0.20081112+gitBB342A7-1(hppa/experimental): FTBFS: Failure: Cannot find ocamlbuildlib.cmxa
tags 505490 + pending thanks On Thu, Nov 13, 2008 at 12:30:24AM +0100, Frank Lichtenheld wrote: Package: ocaml-batteries Version: 0.20081112+gitBB342A7-1 Severity: serious Thanks, the bug it's already fixed in the git repo (as usual, I discovered it 5 minutes after the upload, because it is not trivially reproducible on my dev machine). Nevertheless, I won't bother re-upload to experimental before the next upstream release, as we are still talking about a pre-beta upstream release. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature
Bug#502146: (no subject)
On Fri, Oct 17, 2008 at 11:52:11AM -0400, Jan Engelhardt wrote: I believe this was fixed in 0.45. It was, see #497813; closing this bug report. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502146: (no subject)
reopen 502146 fixed 502146 0.48-1 thanks On Sat, Nov 15, 2008 at 12:23:37PM +0100, Stefano Zacchiroli wrote: It was, see #497813; closing this bug report. I obviously got an off by 1 in version number on this. I thought 0.45 was already in testing while it is not, reopening and setting fixed as needed (as this bug is fixed in unstable). Thanks to Carsten for spotting this. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495246: version syntax error in Build-Conflicts (unexpanded substvar ${Source-Version})
Package: xosd
Version: 2.2.14-1.5
Severity: serious
Hi, the source stanza of xosd reads:
Package: xosd
Binary: libxosd-dev, xosd-bin, libxosd2
Version: 2.2.14-1.5
Priority: optional
Section: x11
Maintainer: Philipp Matthias Hahn [EMAIL PROTECTED]
Build-Depends: cdbs, debhelper (= 4.1.0), libgdk-pixbuf-dev, libgtk1.2-dev,
libtool, libx11-dev, libxext-dev, libxinerama-dev, x11proto-core-dev,
x11proto-xext-dev, x11proto-xinerama-dev
Build-Conflicts: libxosd-dev ( ${Source-Version})
Architecture: any
Standards-Version: 3.6.1.1
snip
The Build-Conflicts lines violates the syntax allowed by policy (see
5.6.12) for version numbers. In particular curly braces and $ characters
are not allowed.
Beside that, Source-Version is a deprecated substvar, it's recommended
counterpart is source:Version, see deb-substvars(5).
Cheers.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467422: tries to overwrite file owned by liblua5.1-posix-dev
Package: liblua5.1-posix1 Version: 5.1.2-2 Severity: serious During today's upgrade of unstable: dpkg: dependency problems prevent configuration of liblua5.1-posix-dev: liblua5.1-posix-dev depends on liblua5.1-posix1 (= 5.1.2-2); however: Package liblua5.1-posix1 is not installed. dpkg: error processing liblua5.1-posix-dev (--configure): dependency problems - leaving unconfigured Cheers ignorable PS for the maintainer and the Italian cabal: e non so nemmeno perché ho installato 'sto cavolo di pacchetto :-) Che bagaglio /ignorable -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages liblua5.1-posix1 depends on: ii libc6 2.7-8 GNU C Library: Shared libraries liblua5.1-posix1 recommends no packages.
Bug#469285: ocsigen-doc: not installable in unstable
On Tue, Mar 04, 2008 at 03:21:24PM +0100, Stephane Glondu wrote: Concerning the dependency on ocaml-nox-3.10.0: indeed it is not really needed. It has actually been fixed for a while, but not uploaded since we are in a middle of a migration... Summarizing a discussion on #debian-ocaml of this afternoon. ocsigen-doc is blocking the transition (together with its buildd friends) since until the package with the bogus dependency is in testing, the new OCaml can't enter as it will break ocsigen-doc. Being arch:all the scheduled binNMU of ocsigen-doc won't do any better. So I'm going to do a sourceful upload of ocsigen in a few hours. To avoid having ocsigen FTBFS on the archs which are still missing ocamlnet, Julien is going to ask for a dep-wait on those archs to the release team. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#479318: does not work with perl 5.10.x
Package: lintian Version: 1.23.47 Severity: grave Here is what I get today, after an upgrade to perl 5.10.x, running lintian on a *.changes file: $ lintian ocaml-res_2.2.5-1_i386.changes Can't use string (1) as an ARRAY ref while strict refs in use at /usr/share/lintian/checks/menus line 418, IN line 4. internal error: cannot run menus check on package libres-ocaml-dev N: Skipping check of binary package libres-ocaml-dev Yesterday it was working properly. The changes file involved is attached, though I doubt it is related at all to the problem. An educated guess: either something in lintian needs to be ported to the new perl, or lintian dependencies are wrong and need to be fixed to avoid co-installability with latest perl. ... nevertheless, thanks for lintian! :) Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-4 The GNU assembler, linker and bina ii diffstat1.45-2 produces graph of changes introduc ii dpkg-dev1.14.18 package building tools for Debian ii file4.24-2 Determines file type using magic ii gettext 0.17-2 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output ii liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin ii man-db 2.5.1-4 on-line manual pager ii perl [libdigest-sha 5.10.0-9 Larry Wall's Practical Extraction lintian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479318: does not work with perl 5.10.x
On Sun, May 04, 2008 at 11:41:20AM +0100, Adam D. Barratt wrote: I had a quick look and can't see any other uses of the syntax. Indeed the patch works fine here, with it I'm able to perform complete lintian runs. Thanks! Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479327: tulip misses dependencies and crashes
On Sun, May 04, 2008 at 03:10:24PM +0200, Yann Dirson wrote: On Sun, May 04, 2008 at 12:44:00PM +0200, Sam Hocevar wrote: Hi! I have been unable to get the Debian tulip packages to work: dependencies are missing, and the program crashes. Same here. Hm, that looks like an annoying consequence of the split of qt4 into more binary packages. A rebuild is likely enough to fix it. Currently it does not, because the current source package in unstable and testing FTBFS (just tried). I'll also have to package the final 3.0.0 one day - but since I have had problems with B7, I'm not sure it will go that smoothly, so better make B6 suitable for release first :) In the meantime 3.0.1 got release, any status update on packaging it for Debian? /me really eager to play with tulip ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483940: setting package to libgalax-ocaml-dev galax-extra galax-doc galaxd galax, tagging 483940
# Automatically generated email from bts, devscripts version 2.10.29 # # galax (1.1-3) unstable; urgency=low # # * debian/rules: remove .depend files created during clean, as they cause #FTBFSs (permission denied) on buildds using -rsudo (Closes: #483940) # package libgalax-ocaml-dev galax-extra galax-doc galaxd galax tags 483940 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501117: timer-applet: old preset files from stable cause crashes
On Sat, Oct 04, 2008 at 11:38:31AM +0200, Philipp Kern wrote: [0] looks like a bug that could be found when updating from etch to Hi Philipp, [0] looks like a dangling reference, can you please expand it? TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452104: Pleare rebuild against liblablgtk2-ocaml 2.10.0-2
On Tue, Nov 20, 2007 at 02:12:36PM +0100, Enrico Tassi wrote: This is a mostly a reminder: please, rebuild the package against the new version of gtk2 bindings. The lablgtk2 is already aware of this, he told me that he is going to ask for the needed binNMUs as soon as lablgtk2 has been rebuild on all archs. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#452104: fixed in unstable
Version: 0.7.8-3 Just uploaded a new version with the fixed dependencies. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#456310: network manager returns no network device has been found after last hal-info upgrade
Package: hal-info Version: 20071212-1 Severity: grave After the last upgrade of hal-info, network manager fails to find any network device only reporting the error message mentioned in the subject (no network device has been found) when clicking on the ex nm-applet icon. (Note that this happens even with the network device not being mentioned in /etc/network/interfaces as required by network-manager.) Downgrading hal-info to the testing version (20071030-1) fixes the problem. I presume (though I haven't checked) that for finding the network interfaces which are not listed in /etc/network/interfaces to be managed, network manager does some lookup via hal, which fails due to some hal-info breakage. Hence, I think that the other way of using network-manager via /etc/network/interfaces suggested in /usr/share/doc/network-manager/README.Debian (namely, to list the desired interfaces as auto and with dhcp) works, but I haven't tried that. My (wireless) network card is an Intel as described below by lspci: 06:05.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05) Subsystem: Intel Corporation Unknown device 2702 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (750ns min, 6000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 20 Region 0: Memory at b0204000 (32-bit, non-prefetchable) [size=4K] Capabilities: access denied and works properly (without network-manager / hal) with the ipw2200 kernel module. Severity grave since I bet other people with the same Intel card will have a network shortage upon installing the current package version. Thanks in advance, Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457014: ocaml-nox: Bad permissions on ocamldoc-api-ref-config
tags 457014 + confirmed thanks On Tue, Dec 18, 2007 at 11:52:11PM -0500, Daniel Schepler wrote: /bin/sh: line 2: /usr/share/cdbs/1/class/ocamldoc-api-ref-config: Permission denied make: *** [build/libcryptgps-ocaml-dev] Error 126 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 I can also reproduce this on amd64 using ocaml packages compiled from source. I can reproduce it here too, ocamldoc-api-ref-config is not installed as an executable script. Probably dh_fixperms is removing the +x bit. I'm rebuilding the package telling dh_fixperms to ignore such a script as a quick fix for this. A more proper long term fix would be to move ocamldoc-api-ref-config elsewhere, but I failed to find a proper place. Any suggestion? Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#457014: ocaml-nox: Bad permissions on ocamldoc-api-ref-config
On Wed, Dec 19, 2007 at 08:59:50AM +0100, Stefano Zacchiroli wrote: I just tried on my home box (amd64/sid), and cannot reproduce the error you describe on recompiling cryptgps. mmmh, this is strange, I really don't see how can it built find for you: the cdbs class now invokes /usr/share/cdbs/1/class/ocamldoc-api-ref-config and that file is not executable here: $ ls -l /usr/share/cdbs/1/class/ocamldoc-api-ref-config -rw-r--r-- 1 root root 2238 2007-12-17 13:41 /usr/share/cdbs/1/class/ocamldoc-api-ref-config Can you please check whether the above file is executable for you or not? I've committed on the svn repo what I think is a fix for this (see my previous post to this bugreport). Before uploading however, I'll wait for some info from Ralf, since given his test in which the FTBFS does not manifest itself I fear there is something more to be understood ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#457014: ocaml-nox: Bad permissions on ocamldoc-api-ref-config
On Wed, Dec 19, 2007 at 08:44:32AM +0100, Ralf Treinen wrote: I just tried on my home box (amd64/sid), and cannot reproduce the error you describe on recompiling cryptgps. mmmh, this is strange, I really don't see how can it built find for you: the cdbs class now invokes /usr/share/cdbs/1/class/ocamldoc-api-ref-config and that file is not executable here: $ ls -l /usr/share/cdbs/1/class/ocamldoc-api-ref-config -rw-r--r-- 1 root root 2238 2007-12-17 13:41 /usr/share/cdbs/1/class/ocamldoc-api-ref-config Can you please check whether the above file is executable for you or not? TIA Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#429736: world readable passwords in /var/cache/debconf/config.dat
Package: zope-debhelper Version: 0.3.9 Severity: grave Tags: security The maintainer scripts generated by zope-debhelper leave passwords in /var/cache/debconf/config.dat. Passwords are therefor world readable by any user of the system. Tagging this bug a security since this is a local privilege escalation: users can access instances as the administrator user. As an example this is what I can read in the above mentioned file right now: Name: zenoss/admin-automatic-password Template: zope-common/admin-automatic-password Value: Owners: zenoss Flags: seen Variables: instance = zenoss password = ec298e16 user = admin zver = 2.9 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages zope-debhelper depends on: ii debhelper 5.0.50 helper programs for debian/rules ii perl 5.8.8-7Larry Wall's Practical Extraction zope-debhelper recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419892: cduce_0.4.1-1+b1(ia64/unstable): FTBFS: SEGV runing ./cduce
On Fri, Jul 27, 2007 at 07:21:29PM +0200, Julien Cristau wrote: Severity: serious There was an error while trying to autobuild your package: snip make[2]: Leaving directory `/build/buildd/cduce-0.4.1' ./cduce -I web/ --compile web/xhtml.cd make[1]: *** [web/xhtml.cdo] Segmentation fault make[1]: Leaving directory `/build/buildd/cduce-0.4.1' make: *** [build-stamp] Error 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=ia64pkg=cducever=0.4.1-1+b1 Has anyone tried to find out what's going on here (or workaround it)? It looks like cduce is being built with ocamlopt, which has a code generation bug on ia64, so hopefully building cduce with ocamlc would fix it. Thomas, are you still around? It seems the cduce package need some care ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#441198: binNMU request for gtkmathview on amd64 [Was: Re: Bug#441198: Crash on amd64]
Hi -releasers, can you please schedule a binNMU for the source package gtkmathview on amd64? Unfortunately I'm not entirely sure that it is the proper solution, since I did not (also after talking with upstream et al) about what was the cause of the crash, but we are quite convinced it was some toolchain breakage. Nevertheless, ATM rebuilding the package on amd64 fixes the problem, that's why I'm asking for the binNMU. Hints on what to do on other archs (i.e. binNMU also there?) are appreciated. On i386 the package works just fine, but I don't know what to expect elsewhere ... TIA, Cheers. On Fri, Sep 07, 2007 at 02:25:10PM +0100, Enrico Tassi wrote: Package: libgtkmathview-bin Version: 0.7.8-2 Severity: normal --- Please enter the report below this line. --- It crashes in a deterministic way, gdb bt and valgrind log follow. I also attach the document I used to generate the crash. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#446079: do nothing useful: interface mismatch on Grammar
Package: otags Version: 3.09.3-2 Severity: serious --- Please enter the report below this line. --- I'm using ocaml 3.10 with otags. Apparently otags is not capable of doing anything useful: $ otags *ml *mli Error while loading /usr/lib/ocaml/3.10.0/otags//tags.cma: interface mismatch on Grammar. Error while loading /usr/lib/ocaml/3.10.0/otags//tags.cma: interface mismatch on Grammar. Error while loading /usr/lib/ocaml/3.10.0/otags//tags.cma: interface mismatch on Grammar. Error while loading /usr/lib/ocaml/3.10.0/otags//tags.cma: interface mismatch on Grammar. Error while loading /usr/lib/ocaml/3.10.0/otags//tags.cma: interface mismatch on Grammar. Error while loading /usr/lib/ocaml/3.10.0/otags//tags.cma: interface mismatch on Grammar. Error while loading /usr/lib/ocaml/3.10.0/otags//tags.cma: interface mismatch on Grammar. The error message is reported once for each input file. I guess the problem is due to some camlp4 interface incompatibility, but passing -camlp4 camlp5 did not help. Cheers. --- System information. --- Architecture: i386 Kernel: Linux 2.6.22-2-686 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstablepeople.debian.org 500 unstableftp.it.debian.org 500 testing security.debian.org 1 experimentalftp.it.debian.org --- Package information. --- Depends(Version) | Installed -+-=== ocaml-base-nox-3.10.0| camlp5 | 5.00-1 -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#446462: /usr/bin/vim is left broken when alternative is manual and points to vim-full
On Sat, Oct 13, 2007 at 12:43:52PM -0400, James Vega wrote: *sigh* I don't know what made piuparts succeed before but it is definitely exhibiting the reported behavior now. Looks like it's time for another update-alternatives hack. Ok, also because I had indeed other out of bounds reports of the bug from other friends of mine. Actually, it was a typo on my part in the preinst file. I'm preparing a package now and will get it uploaded today. Many thanks for this! Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#446864: missing dep on libxpm-dev (or spurious -lXpm in .la file)
Package: libt1-dev Version: 5.1.1-1 Severity: serious File: /usr/lib/libt1x.la Compiling against libt1-dev fails if libxpm-dev is not installed. Either it should be declared as a dependency of libt1-dev, or the reference to -lXpm in /usr/lib/libt1x.la file should be removed. Severity serious since this bug induces FTBFSs in other packages, which used to build just fine. As an example see the gtkmathview (source) package and #441198 (note that the bug per se is not due to libt1-dev, but in the bug log an example of the FTBFS induced by libt1-dev is reported). TIA, Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libt1-dev depends on: ii libice-dev 2:1.0.4-1X11 Inter-Client Exchange library ii libsm-dev 2:1.0.3-1+b1 X11 Inter-Client Exchange library ii libt1-5 5.1.1-1 Type 1 font rasterizer library - r ii libx11-dev 2:1.0.3-7X11 client-side library (developme ii libxext-dev 1:1.0.3-2X11 miscellaneous extensions libra Versions of packages libt1-dev recommends: ii libt1-doc 5.1.1-1Type 1 font rasterizer library - d -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441198: binNMU request for gtkmathview on amd64 [Was: Re: Bug#441198: Crash on amd64]
On Mon, Oct 15, 2007 at 02:48:16AM -0700, Steve Langasek wrote: ... also, after manually installing libxpm-dev for the build and installing the resulting packages, I still get a segfault on amd64. So binNMUs don't seem to be the answer here. Thanks for this investigation, I've just reported #446864 for the t1lib issue. Since upstream has just released 0.8.0 I'll wait for the above bug to be solved and then give again a try to the latest upstream. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#446864: missing dep on libxaw7-dev
retitle 446864 missing dependency on libxaw7-dev thanks Package: libt1-dev Version: 5.1.1-1 --- Please enter the report below this line. --- In the end it seems that this bug boils down to a missing dependency from libt1-dev to libxaw7-dev. Indeed the latter package is listed as a *build* dependency but not as a dependency for the -dev package, potentially introducing unresolvable link flags. Please add the missing dep. I plan to do a delayed NMU since I really need this to be fixed and I'm (now) convinced it would introduce no harm. I hope you don't mind. Cheers. --- System information. --- Architecture: i386 Kernel: Linux 2.6.22-2-686 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstablepeople.debian.org 500 unstableftp.it.debian.org 500 testing security.debian.org 1 experimentalftp.it.debian.org --- Package information. --- Depends (Version) | Installed ===-+- libt1-5 (= 5.1.1-1) | 5.1.1-1 libice-dev | 2:1.0.4-1 libsm-dev | 2:1.0.3-1+b1 libx11-dev | 2:1.0.3-7 libxext-dev | 1:1.0.3-2 -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#446864: here is a patch
tags 446864 + patch
thanks
Hi, please find attached the debdiff for the fixed package I'm going to
upload (delayed by 7 days).
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48) Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15) Bac: no, la demo scema\/right keys at the right time
diff -u t1lib-5.1.1/debian/control t1lib-5.1.1/debian/control
--- t1lib-5.1.1/debian/control
+++ t1lib-5.1.1/debian/control
@@ -23,7 +23,7 @@
Package: libt1-dev
Section: libdevel
Architecture: any
-Depends: libt1-5 (= ${binary:Version}), libice-dev, libsm-dev, libx11-dev, libxext-dev
+Depends: libt1-5 (= ${binary:Version}), libice-dev, libsm-dev, libx11-dev, libxext-dev, libxaw7-dev
Recommends: libt1-doc
Conflicts: t1lib-dev, t1lib1-dev
Description: Type 1 font rasterizer library - development
diff -u t1lib-5.1.1/debian/changelog t1lib-5.1.1/debian/changelog
--- t1lib-5.1.1/debian/changelog
+++ t1lib-5.1.1/debian/changelog
@@ -1,3 +1,10 @@
+t1lib (5.1.1-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add dependency from libt1-dev to libxaw7-dev (Closes: #446864)
+
+ -- Stefano Zacchiroli [EMAIL PROTECTED] Wed, 17 Oct 2007 16:49:42 +0200
+
t1lib (5.1.1-1) unstable; urgency=low
* new upstream version (Closes: #418664)
signature.asc
Description: Digital signature
Bug#446864: Bug#447368: gtkmathview: FTBFS: /usr/bin/ld: cannot find -lXpm
forcemerge 447368 446864 thanks On Sat, Oct 20, 2007 at 03:46:58PM +0200, Lucas Nussbaum wrote: Package: gtkmathview version: 0.7.8-2 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20071019 qa-ftbfs Justification: FTBFS on i386 /usr/bin/ld: cannot find -lXpm collect2: ld returned 1 exit status This is not a bug in gtkmathview, but rather in t1lib. See #446864 for details. I've already NMUed t1lib, but I've uploaded it to the delayed 6 days queue some days ago (don't know how the upload should be visible ATM ...). Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#447303: ocaml-syck: FTBFS without ocamlopt
On Fri, Oct 19, 2007 at 11:21:55PM +0200, Julien Cristau wrote: See http://buildd.debian.org/fetch.cgi?pkg=ocaml-syckarch=hppaver=0.1.1-1stamp=1192820955file=logas=raw *.a files aren't built on architectures lacking a native compiler, so shouldn't be installed. Yep, thanks for the report. More precisely (and as a reminder to self), the *.a files generated by ocamlopt from ocaml sources aren't built on non native architectures. On the contrary *.a files generated by ocamlmklib to statically link glue C/OCaml code are built also on non native architectures. This glitch was actually what fooled me here. Working on this, expect a pending tag soon. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#450903: libocamlnet-ssl-ocaml: segfault on custom ssl bindings
On Mon, Nov 12, 2007 at 02:56:34AM +0100, Romain Beauxis wrote: 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 please provide the example, so that we can test the fix? After some introspection, helped by Sam, we found out that the package ships its custom ssl extra-bindings. These are out-of-date and caused the segfault. Out-of-date respect what? Thanks for the patch, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450903: libocamlnet-ssl-ocaml: segfault on custom ssl bindings
On Thu, Jan 10, 2008 at 09:47:04AM +0100, Samuel Mimram wrote: AFAIR some code from the C headers of ocaml-ssl was copied into ocamlnet-ssl but unfortunately I changed these definitions later in ocaml-ssl and the disparity between the two libs was leading to a SEGV in ocamlnet-ssl. Ah, so you did it in the beginning, do you mind getting in touch yourself with Gerd then to rectify the status quo? I can of course do it, but removing an intermediary would be faster. Please Cc the bug report if you do so; let me know otherwise. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441494: not installable: needs to be rebuilt against ocaml 3.10
Package: libgv-ocaml Version: 2.12-4 Severity: serious libgv-ocaml currently can't be installed on unstable due to the transition from ocaml 3.09 to ocaml 3.10. Simply rebuilding (binNMU should be ok as well) against the current ocaml-nox version in unstable should fix the problem, can you please ask for the rebuild and/or due a sourceful upload? If you need any help on this (including NMU) feel free to ask on [EMAIL PROTECTED] TIA, Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441507: Bug#441502: coq - FTBFS: /bin/sh: camlp4o: command not found
On Mon, Sep 10, 2007 at 09:48:54AM +0200, Michael Ablassmeier wrote: Package: coq Version: 8.1.pl1+dfsg-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20070905 On Mon, Sep 10, 2007 at 09:49:05AM +0200, Michael Ablassmeier wrote: Package: ocaml-sqlite3 Version: 0.21.0-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20070905 On Mon, Sep 10, 2007 at 09:49:09AM +0200, Michael Ablassmeier wrote: Package: planets Version: 0.1.13-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20070905 All these bugs are due to the fact that the /usr/bin/camlp4o executable is no longer shipped by ocaml-nox, but rather by camlp4. Hence you now need to build depend on the camlp4 package. Please note that if you use some more advanced camlp4 bundle executable (like, for example, /usr/bin/camlp4orf) then you will also need to build-depend on camlp4-extra which ships it. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#442026: FTBFS on archs without the native-compilers
On Wed, Sep 12, 2007 at 05:51:26PM +0100, Enrico Tassi wrote: --- Please enter the report below this line. --- The .install.in file reports: debian/tmp/lablgtksourceview/*.cma usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ debian/tmp/lablgtksourceview/*.cmi usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ debian/tmp/lablgtksourceview/*.cmxa usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ That is wrong on archs without the native compiler. I suggest a single Agreed, but probably something changed in the semantics of debhelper (or maybe from compatibility level 4 to 5 which I've bumped), something which AFAICT is not documented in the manpage. The lines above were not changed since the first upload in Debian and the package was built properly in the past on all architectures ... debian/tmp/lablgtksourceview/*.cm* usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ I'm fine with this fix, but probably won't be able to commit/reupload it before this week-end. Feel free to fix it and reupload the package (adding yourself as an Uploader) .. or wait until this week-end. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#442997: please rebuild with ocaml 3.10 (currently uninstallable in sid)
Package: facile Version: 1.1-5 Severity: serious Hi, facile is currently uninstallable in sid due to the transition to ocaml 3.10; actually the package is also blocking the transition (among a few others). Please rebuild it against ocaml 3.10 and upload. I intend to NMU the package anytime soon, probably uploading to the 1-day delayed queue. Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
merge 444360 443150 tags 444360 + help tags 443150 + help thanks On Fri, Sep 28, 2007 at 02:10:06AM +0200, Frank Lichtenheld wrote: your package failed to build from source. Yep, thanks, was already reported. I'll look into this but I would appreciate help from some of the Apache guys, since apparently apxs is not invoking the compilers to build PIC code ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 09:48:50AM +0200, Julien Cristau wrote: The problem seems to be that you're trying to build the mod_netcgi_apache.so shared object while linking with -lcamlrun, but libcamlrun only exists as a static (non-PIC) library. Aaaarggh, right! IIRC that's an upstream issue for which exists a patch (by Richard Jones maybe ...), isn't it? What about applying it in the OCaml Debian package? Thanks for the pointer, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 02:10:45PM +0100, Richard Jones wrote: In particular I could do it if INRIA said that they would support the change in some future release (see the exception Patches Heading Upstream). But otherwise this is quite a large ABI change -- if Fedora users started to build lots of 64 bit shared libraries linked with -lcamlrun I could end up maintaining it separately forever. I think you misunderstood my proposal. I don't want to apply your initial fix which changes libcamlrun.a into libcamlrun.so. I want to add a libcamlrun_shared.so, so there would be no ABI change, just the added possibility to link against it. Or maybe you're concerned about having to drop in the future support for libcamlrun_shared.so, but I think the user impact of that new library would be quite low. In fact I don't think anything else that mod_caml-like projects will need it ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
