Bug#1015974: Should gnat-gps be removed?
severity 1015974 normal retitle 1015974 gnat-gps: new version available using python 3 thanks Upstream has finally migrated gnat-gps to python 3 but too late for Debian 11. We will package the new upstream version as part of the next Ada transition (to gnat-12 or gnat-13). In the mean time, this package will remain in unstable. -- Ludovic Brenta.
Bug#951423: gunroar: symbol lookup error: gunroar: undefined symbol: _D4core4stdc5errno5errnoFNbNdNiNeZi
Come to think of it, the problem might also be that the package libphobos76 retained the soname of version 8 but changed the name mangling in version 9. -- Ludovic Brenta.
Bug#951423: gunroar: symbol lookup error: gunroar: undefined symbol: _D4core4stdc5errno5errnoFNbNdNiNeZi
86_64-linux-gnu/libXdmcp.so.6 (0x7f02655b7000) libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x7f02655aa000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x7f02655a5000) libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x7f0265395000) libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x7f026518a000) libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x7f0265183000) libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x7f0264f7d000) libwayland-egl.so.1 => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x7f0264f78000) libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x7f0264f67000) libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x7f0264f5e000) libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x7f0264f1b000) libsndio.so.7.0 => /usr/lib/x86_64-linux-gnu/libsndio.so.7.0 (0x7f0264f07000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f0264e93000) libopus.so.0 => /usr/lib/x86_64-linux-gnu/libopus.so.0 (0x7f0264e38000) libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x7f0264d8d000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f0264d64000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f0264d4) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x7f0264c23000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f0264c09000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f0264bf1000) libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x7f0264bd7000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x7f02649cd000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x7f02647c5000) libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x7f02647b9000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7f0264796000) -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gunroar depends on: ii gunroar-data0.15.dfsg1-9 ii libc6 2.29-10 ii libgcc-s1 [libgcc1] 10-20200211-1 ii libgcc1 1:10-20200211-1 ii libgl1 1.3.0-7 ii libglu1-mesa [libglu1] 9.0.1-1 ii libgphobos76 9.2.1-28 ii libsdl-mixer1.2 1.2.12-16+b1 ii libsdl1.2debian 1.2.15+dfsg2-5 gunroar recommends no packages. gunroar suggests no packages. -- no debconf information -- Ludovic Brenta. The clients repurpose a glocalization.
Bug#927943: libxmlada: FTBFS with unicode-data >= 12.0.0
Yes, I like Nicolas' proposed patch. (Personally I think unicode should have been frozen too, by the way; upgrading it this late in the release cycle seems to be a mistake). -- Ludovic Brenta.
Bug#913371: gnat-gps fails to build on 32-bit kernels, address space exhaustion.
I think this is the best way forward. -- Ludovic Brenta.
Bug#901121: turing: missing dependency on python3-matplotlib
Package: turing Version: 0.10~beta-1 Severity: serious Dear Maintainer, Launching turing on the command line yields: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-lbrenta' NoneType: None Traceback (most recent call last): File "/usr/share/turing/src/main.py", line 86, in from forms import mainwindow File "/usr/share/turing/src/forms/mainwindow.py", line 15, in from matplotlib.axes import Axes ModuleNotFoundError: No module named 'matplotlib' Installing the package python3-matplotlib solves this problem. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages turing depends on: ii python3 3.6.5-3 ii python3-altgraph0.15~repack0-2 ii python3-autopep81.3.5-2 ii python3-cycler 0.10.0-1 ii python3-dateutil2.6.1-1 ii python3-docutils0.14+dfsg-3 ii python3-future 0.15.2-4 ii python3-jedi0.11.1-1 ii python3-kiwisolver 1.0.1-2 ii python3-macholib1.9+repack0-1 ii python3-numpy 1:1.14.3-2 ii python3-parso 0.1.1-1 ii python3-pefile 2017.11.5-2 ii python3-pep81.7.1-1 ii python3-pyflakes1.6.0-1 ii python3-pygments2.2.0+dfsg-1 ii python3-pyparsing 2.2.0+dfsg1-2 ii python3-pyqt5 5.10.1+dfsg-2 ii python3-tz 2018.4-1 turing recommends no packages. turing suggests no packages. -- no debconf information
Bug#769797: marked as done (gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2)
Neil Williams codeh...@debian.org writes: unless you tell me how the b-d gcc-4.9-source ( 4.9.2) is satisfied in unstable, please leave this issue open. That doesn't make sense. gnat-4.9 in unstable has build-dependencies which can be satisfied in unstable. gnat-4.9 in testing has build-dependencies which can be satisfied in testing. Why would the build-dependency gcc-4.9-source ( 4.9.2) in gnat-4.9 in *testing* be relevant when checked in unstable? Correct but I think Matthias' mail alludes to his freeze exception request (#774221) which, if and when granted, will break the build-dependency of gnat-4.9 in testing and require that gnat-4.9 also migrate from unstable to testing; I commented to that effect in the request. So, this bug is technically closed but might resurface in the near future. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769797: gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2
Matthias Klose writes: known. please wait for the gcc-4.9 4.9.2-2 upload before syncing. OK. Are you planning to request a freeze exception so that 4.9.2 goes into jessie? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767845: flightgear: Frequently crashes when using TerraSync
Package: flightgear Version: 3.0.0-3 Severity: grave Justification: makes TerraSync almost unusable This crash is due to #765855 which has just been fixed in libopenscenegraph100. However, even after upgrading libopenscenegraph100 to 3.2.1-5 the crashes still happen quite frequently, ruining many perfectly good flights (4 times in the past 24 hours for me alone and several people reported similar crashes). The frequency of the crashes appears to increase as new TerraSync data becomes available. According to comment #59, it is necessary to recompile flightgear and possibly simgear in order to benefit from the bug fix. Therefore please upload 3.0.0-4 :) -- Ludovic Brenta. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flightgear depends on: ii flightgear-data-all 3.0.0-1 ii freeglut3 2.8.1-2 ii libc6 2.19-12 ii libdbus-1-3 1.8.8-2 ii libgcc1 1:4.9.1-16 ii libgl1-mesa-glx [libgl1] 10.3.1-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libgsm1 1.0.13-4 ii libice6 2:1.0.9-1 ii libjpeg62-turbo 1:1.3.1-8 ii libopenal11:1.15.1-5 ii libopenscenegraph100 3.2.1-5 ii libopenthreads20 3.2.1-5 ii libplib1 1.8.5-7 ii libpng12-01.2.50-2 ii libsimgearcore3.0.0 3.0.0-6 ii libsimgearscene3.0.0 3.0.0-6 ii libsm62:1.2.2-1 ii libspeex1 1.2~rc1.2-1 ii libspeexdsp1 1.2~rc1.2-1 ii libsqlite3-0 3.8.7-1 ii libstdc++64.9.1-16 ii libudev1 215-5+b1 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxi62:1.7.4-1 ii libxmu6 2:1.1.2-1 ii zlib1g1:1.2.8.dfsg-2 flightgear recommends no packages. flightgear suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767845: flightgear: Frequently crashes when using TerraSync
Actually reproducible now with simply: fgfs --enable-terrasync I suggest that flightgear should tighten its build-dependency on libopenscenegraph100 (= 3.2.1-5). -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756385: adasockets: missing license in debian/copyright
Please fix this minor problem before the freeze of testing... -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756383: adacgi: missing license in debian/copyright
Please fix this minor problem before the freeze of Debian... -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759407: gnat-4.9: gnat1 not found on kfreebsd-i386
Emilio Pozuelo Monfort po...@debian.org writes: On 21/09/14 02:31, Ludovic Brenta wrote: Nicolas Boulenguez nico...@debian.org writes: A bootstrap issue will remain: building a new gnat-4.9 package installing these symlinks requires a working compiler. I am now uploading gnat-4.9 4.9.1-2 which solves this problem. I bootstrapped it on a kfreebsd-i386 virtual machine in which I created the symlinks manually, so that gnat-4.9 4.9.1-1 worked again as the bootstrap compiler. Since this is a policy violation (official packages must be built on real hardware, not on virtual machines) I intend to upload -3 to have it rebuilt on kfreebsd-i386 with -2. Which part of policy is that? Heh, I can't find it back. I thought I remembered this rule from years ago. Maybe I am mistaken. Maybe the package I just uploaded is perfectly fine after all. Or, maybe it is a rule imposed by DSA on porter machines. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759407: gnat-4.9: gnat1 not found on kfreebsd-i386
Nicolas Boulenguez nico...@debian.org writes: A bootstrap issue will remain: building a new gnat-4.9 package installing these symlinks requires a working compiler. I am now uploading gnat-4.9 4.9.1-2 which solves this problem. I bootstrapped it on a kfreebsd-i386 virtual machine in which I created the symlinks manually, so that gnat-4.9 4.9.1-1 worked again as the bootstrap compiler. Since this is a policy violation (official packages must be built on real hardware, not on virtual machines) I intend to upload -3 to have it rebuilt on kfreebsd-i386 with -2. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759407: gnat-4.9: gnat1 not found on kfreebsd-i386
reassign 759407 src:gcc-4.9 thanks Hello, Svante is correct on one point: some version of gcc-4.9 broke gnat-4.9 on kfreebsd-i386 at least. Proof: on August 11, gnat-4.9 (=4.9.1-1) worked perfectly well when combined with gcc-4.9 (exact version unspecified): https://buildd.debian.org/status/fetch.php?pkg=libtemplates-parserarch=kfreebsd-i386ver=11.8.2014-3stamp=1407787293 The symptoms appeared later, still with gnat-4.9 (=4.9.1-1) but with a later gcc-4.9; not a snapshot. On August 24: https://buildd.debian.org/status/fetch.php?pkg=gnat-gpsarch=kfreebsd-i386ver=5.3-3stamp=1408919003 Between these two dates (August 11 and August 24), there were no uploads of gnat-4.9 but there were some uploads of gcc-4.9, therefore gcc-4.9 must have broken something, possibly in the target triplet or directory where it looks for gnat1. Possibly, this bug has already been fixed by the last change in this upload: gcc-4.9 (4.9.1-11) unstable; urgency=medium * Update to SVN 20140830 (r214759) from the gcc-4_9-branch. * Update cross installation patches for the branch. * Use the base version (4.9) when accessing files in gcc_lib_dir. -- Matthias Klose d...@debian.org Sat, 30 Aug 2014 22:05:47 +0200 I'll try to check this (on kfreebsd-i386) over the weekend. This particular bug is for kfreebsd-i386 only. hurd-i386 has similar symptoms on different dates (for example, the build of gnat-gps (=5.3-3) succeeded on hurd-i386 when it failed on kfreebsd-i386). I propose to use #761248 (severity important) to track the issue on hurd-i386, if it is different. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749714: liblog4ada: failed to rename -dev package
Package: src:liblog4ada Version: 1.2-4 Severity: serious Justification: policy violation The name of the -dev package must change whenever any of the .ali files in the package changes. Compiling against libgnat-4.9 instead of libgnat-4.6 causes such a change. Similarly the name and soname of the shared library must change. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742590: gnat-4.9: FTBFS on powerpc, Storage_Error in two source files
Package: src:gnat-4.9 Version: 4.9-20140218-1 Severity: serious Symptoms from the buildd log: /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -W -Wall -gnatpg -nostdinc a-direct.adb -o a-direct.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-direct.o] Error 1 make[7]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada/rts-static-zcx' make[6]: *** [rts-static-zcx/libgnat.a] Error 2 make[6]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[5]: *** [gnatlib-static-zcx] Error 2 make[5]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[4]: *** [gnatlib-static-zcx] Error 2 make[4]: *** Waiting for unfinished jobs /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -W -Wall -gnatpg -nostdinc a-direct.adb -o a-direct.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-direct.o] Error 1 make[7]: *** Waiting for unfinished jobs /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -fPIC -W -Wall -gnatpg -nostdinc -fPIC a-direct.adb -o a-direct.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-direct.o] Error 1 make[7]: *** Waiting for unfinished jobs /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -W -Wall -gnatpg -nostdinc -g -O1 -fno-inline \ -fno-toplevel-reorder a-except.adb -o a-except.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-except.o] Error 1 make[7]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada/rts-static-sjlj' make[6]: *** [rts-static-sjlj/libgnat.a] Error 2 make[6]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[5]: *** [gnatlib-static-sjlj] Error 2 make[5]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[4]: *** [gnatlib-static-sjlj] Error 2 /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -fPIC -W -Wall -gnatpg -nostdinc -fPIC -g -O1 -fno-inline \ -fno-toplevel-reorder a-except.adb -o a-except.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-except.o] Error 1 make[7]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada/rts-shared-zcx' make[6]: *** [rts-shared-zcx/libgnat-4.9.so] Error 2 make[6]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[5]: *** [gnatlib-shared-zcx] Error 2 make[5]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[4]: *** [gnatlib-shared-zcx] Error 2 make[4]: Leaving directory `/«PKGBUILDDIR»/build/libada' make[3]: *** [all-libada] Error 2 make[3]: Leaving directory `/«PKGBUILDDIR»/build' make[2]: *** [bootstrap] Error 2 make[2]: Leaving directory `/«PKGBUILDDIR»/build' Note that none of these exceptions are raised when using the bootstrap compiler (gnat-4.6) to compile a-except.adb. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713124: gnat-4.6: FTBFS: unsatisfiable build-dependency: automake ( 1:1.12) but 1:1.13.3-1 is to be installed
Is there any reason to specify Build-Depends: automake ( 1:1.12)? I can build this package without it. Patch attached. Thanks but please modify debian/control.m4 and debian/rules.conf, not debian/control, which is generated. I cannot answer your question myself because these build-dependencies are from the GCC sources. doko, can you shed some light on this? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713297: polyorb: FTBFS: CosEventChannelAdmin.idl:24:31: CosEventComm is undefined
Email forwarded from Pavel Zhukov:
Hi debian ada team! ,
First of all I'm not familar with debian bug tracking system (sorry
about that).
I hit the same issue as described in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713297 while building
polyorb for fedora (with gcc 4.8).
The patch [1] fixed issue for me and it was accepted by Adacore. Feel
free to use one :)
--
Pavel
[1]
--- a/configure 2014-01-27 23:38:14.944966528 +0100
+++ b/configure 2014-01-27 23:38:28.841024943 +0100
@@ -5641,7 +5641,7 @@
case $CXXCPP in
*g++*)
if test ${CXXCPPFLAGS} = ; then
-IDLCPPFLAGS=-x c++ -ansi
+IDLCPPFLAGS=-x c++ -ansi -ffreestanding
# Options to use GNU C++ preprocessor as IDL preprocessor
# -x c++ force C++ preprocessor mode (even though it cannot be
# inferred from filename extension .idl)
--- a/support/idlcpp.m4 2014-01-27 23:37:44.230837412 +0100
+++ b/support/idlcpp.m4 2014-01-27 23:38:04.278921691 +0100
@@ -38,7 +38,7 @@
case $CXXCPP in
*g++*)
if test ${CXXCPPFLAGS} = ; then
-IDLCPPFLAGS=-x c++ -ansi
+IDLCPPFLAGS=-x c++ -ansi -ffreestanding
# Options to use GNU C++ preprocessor as IDL preprocessor
# -x c++ force C++ preprocessor mode (even though it cannot be
# inferred from filename extension .idl)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669513: Removal of gnat-4.4 due to RC bug #669513
Tobias Hansen writes: Am 06.12.2012 20:57, schrieb Tobias Hansen: Am 06.12.2012 20:44, schrieb Ludovic Brenta: Tobias Hansen writes: since we have gnat-4.6 in wheezy and gnat-4.4 does not build anymore (see #669513), can gnat-4.4 be removed? Yes but maybe notify the maintainers of the sole package still depending on it, ghdl. This package is the reason I've refrained from asking for removal of gnat-4.4 sthus far. Thanks for your time and concern Since you are a gnat-4.4 uploader, will you file the removal request? I will file a bug against ghdl. By the way, ghdl is not in wheezy anymore, only in unstable. I filed a bug against ghdl, #695303, and it really needs gnat-4.4 for now. The FTBFS of gnat-4.4 can probably be fixed in unstable by updating it to the most recent version. But to fix #669513 in wheezy, gnat-4.4 should be removed. I'll file a request for that ok? Yes please. I've been stuck in real life recently :) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669513: Removal of gnat-4.4 due to RC bug #669513
Tobias Hansen writes: since we have gnat-4.6 in wheezy and gnat-4.4 does not build anymore (see #669513), can gnat-4.4 be removed? Yes but maybe notify the maintainers of the sole package still depending on it, ghdl. This package is the reason I've refrained from asking for removal of gnat-4.4 sthus far. Thanks for your time and concern -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686781: libgtkada-doc: TestGTK example fails to build, depends on (deleted) Gtk.Extra
severity 686781 normal thanks Severity: serious Justification: fails to build from source That justification applies when building the binary packages from source, not when building example programs contained in the -doc package, therefore this bug is not serious and not release-critical. Downgrading to normal. In version 2.14.2-*, testgtk compiled out of the box, so this is a regression. The patch no_gtkextra.patch has been removed, presumably because it no longer applied in version 2.24. Maybe that this patch is still necessary after all. See also http://www.ada-france.org:8081/revision/info/8a5a9744221c7afed727a67664563d5e72205867 and http://lists.adacore.com/pipermail/gtkada/2009-June/003811.html and followups to that mail. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681385: monotone segfaults at once
affects 681066 monotone reassign 681385 libbotan-1.10-0 1.10.2-1 severity 681385 critical forcemerge 681066 681385 thanks The bug was not in monotone but in libbotan-1.10-0. It has now been fixed in unstable with an urgency=high upload which should migrate to testing within 24 hours from now. No further action is required. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623382: Ping - gnat fatal error - gone away?
reassign 623382 gnat 4.4+1 close 623382 gnat/4.4+1.1 thanks This bug was, in fact, in gnat rather than gnat-4.4. If has been fixed and closed for several months and I wonder why you followed up on this bug. Perhaps it is not properly marked as closed; I'm attempting to fix that. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676847: mlterm: exits with cannot create directory `/usr/bin/.libs': Permission denied
Package: mlterm Version: 3.1.1-1+b1 Severity: grave Justification: renders package unusable $ mlterm mkdir: cannot create directory `/usr/bin/.libs': Permission denied /usr/bin/mlterm: line 101: cd: /build/buildd-mlterm_3.1.1-1+b1-amd64-fXl4rb/mlterm-3.1.1/main-tiny: No such file or directory gcc: error: daemon.o: No such file or directory gcc: error: main_loop.o: No such file or directory gcc: error: main.o: No such file or directory gcc: error: ../xwindow/libxwindow.a: No such file or directory gcc: error: ../mlterm/libmlterm.a: No such file or directory gcc: error: ../mlterm/.libs/libmlterm_core.so: No such file or directory gcc: error: /build/buildd-mlterm_3.1.1-1+b1-amd64-fXl4rb/mlterm-3.1.1/kiklib/src/.libs/libkik.so: No such file or directory gcc: error: ../mkf/lib/.libs/libmkf.so: No such file or directory gcc: error: ../kiklib/src/.libs/libkik.so: No such file or directory The file /usr/bin/mlterm is actually a shell script that starts with these comments: # mlterm - temporary wrapper script for .libs/mlterm # Generated by ltmain.sh - GNU libtool 1.5.26 (1.1220.2.492 2008/01/30 06:40:56) # # The mlterm program cannot be directly executed until all the libtool # libraries that it depends on are installed. # # This wrapper script should never be moved out of the build directory. # If it is, it will not operate correctly. In version 3.0.11-1, which I downgraded to, I can see: $ file $(which mlterm) /usr/bin/mlterm: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x312983f0694a87527584d91c3cd467e635c48494, stripped -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667184: gnat-4.6: intermittent FTBFS, race condition in Makefiles with too many parallel processes
retitle 667184 gnat-4.6: intermittent FTBFS, race condition in gnattools/Makefile severity 667184 important user debian-...@lists.debian.org usertags - ftbfs-gcc-4.7 thanks This bug has nothing to do with gcc-4.7. Analysis of the full log file reveals that the bootstrap used 10 parallel processes, which triggered this race condition. Building the executable program 'gnatfind' requires the object file xref_lib.o, which does not exist yet because another gnatmake is still building it. I think the problem is that make is running several gnatmake processes in parallel in the same directory (one for each tool to build). The various gnatmake processes step on each other's toes. The fix is to run the gnatmake processes sequentially but pass the parallel option to each of them, so they can run parallel compilations as needed. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665448: monotone: FTBFS: testsuite failure
Richard and Francis, Please find the time to investigate and correct this problem. I suspect something to do with libpcre3. I'll sponsor an upload as soon as you can fix the problem. If you need help, scream. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663672: libdbusada0.2-dev: position-independent code in a static library
Package: libdbusada0.2-dev Version: 0.2-1 Severity: serious Violation of Debian Policy 10.2: the static version [of a library] must not be compiled with the -fPIC flag. Please rearrange debian/rules and the .gpr files so that they recompile the object files in two different object directories: -fPIC for the shared library and no -fPIC for the static library. You may want to look at other packages for inspiration on how to do this. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663673: libalog0.4.1-{full,base}-dev: static library contains position-independent code
Package: libalog0.4.1-full-dev Version: 0.4.1-1 Severity: serious Violation of Debian Policy 10.2: the static version [of a library] must not be compiled with the -fPIC flag. Please rearrange debian/rules and the .gpr files so that they recompile the object files in two different object directories: -fPIC for the shared library and no -fPIC for the static library. You may want to look at other packages for inspiration on how to do this. This bug also applies to package libalog0.4.1-base-dev, built from the same package. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650764: gnat-4.4: FTBFS: sinput.adb:776:19: deallocation from empty storage pool
). * sem_intr.adb (Check_Intrinsic_Call): Add check for deallocation from empty storage pool, moved here from Exp_Intr and made into error. (Check_Intrinsic_Call): Remove assumption in generating not-null free warning that the name of the instantiation is Free. * sinput.adb (Tree_Read): Document use of illegal free call allowed in GNAT mode. * types.ads: Remove storage size clauses from big types (since we may need to do deallocations, which are now illegal for empty pools). So I think that backporting the entire commit (affecting exp_intr.adb, sem_intr.adb, sinput.adb and most importantly types.ads) to gnat-4.4 should resolve this bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649307: gnat-4.6: FTBFS on kfreebsd-amd64 (gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998)
retitle 649307 FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998 reassign 649307 src:gcc-4.6 severity 649307 important forcemerge 649307 637236 thanks Julien and everyone else, please stop filing FTBFS bugs automatically against gcc-4.6 or gnat-4.6. We monitor the buildds and are aware of FTBFS, so these bugs are not useful for us and only take away some of our precious time for triaging. Thanks. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649306: gnat-4.6: FTBFS on armel (configure: error: GNAT is required to build ada)
tags 649306 help thanks doko, you said merging gcc-4.6 4.6.2-4 into gnat-4.6 would fix this FTBFS but it hasn't. The buildd log does not indicate the exact version of gcc-4.6 installed on the machine; perhaps I should tighten the build-dependencies og gnat-4.6 to gcc-4.6 (= 4.6.2-4) ? Do you have any other suggestions? Should an ARM porter have a look? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649306: gnat-4.6: FTBFS on armel (configure: error: GNAT is required to build ada)
Julien Cristau jcris...@debian.org writes: On Sat, Nov 19, 2011 at 23:43:03 +0100, Ludovic Brenta wrote: doko, you said merging gcc-4.6 4.6.2-4 into gnat-4.6 would fix this FTBFS but it hasn't. The buildd log does not indicate the exact version of gcc-4.6 installed on the machine; perhaps I should tighten the It does, it was gcc-4.6_4.6.2-4. See the 'Toolchain package versions' line. Thanks but I see all four of: g++-4.4_4.4.6-11 g++-4.6_4.6.2-4 gcc-4.4_4.4.6-11 gcc-4.6_4.6.2-4 in that line. Mmm. I also see: : # configure cd /build/buildd-gnat-4.6_4.6.2-2-armel-bK1oIn/gnat-4.6-4.6.2/build \ PATH=/build/buildd-gnat-4.6_4.6.2-2-armel-bK1oIn/gnat-4.6-4.6.2/bin:/usr/lib/arm-linux-gnueabi/gcc/bin:$PATH \ CC=gcc-4.4 \ further down. This is a result of this in debia/rules2: ifeq ($(REVERSE_CROSS),yes) CC= else CC= $(if $(filter yes,$(with_ada)),gnatgcc,gcc) ifneq ($(PKGSOURCE),gcc-snapshot) # doesn't bootstrap using gcc-4.5 on armel ifneq (,$(filter $(DEB_TARGET_ARCH), armel)) CC = gcc-4.4 endif endif ifeq (,$(findstring gnat,$(PKGSOURCE))) ifneq (,$(filter $(DEB_TARGET_ARCH), kfreebsd-amd64 kfreebsd-i386)) CC = gcc-4.4 endif endif endif I see that Matthias has just removed this bit in svn; this means that merging from gcc-4.6 4.6.2-5 will actually fix this bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642640: libaws: FTBFS: unsatisfiable build-dependencies
Didier Raboud wrote: two months later, what is the status of this transition ? Not started yet, I've been working on other packages. Your mail prompted me to send a full status report to debian-ada@l.d.o, see http://lists.debian.org/debian-ada/2011/11/msg2.html Are the packages going to be migrated to unversionned gnat versions or should NMUers go to versionned gnat-4.6 ? Per Debian Policy for Ada, all Ada source packages must build-depend on both gnat gnat gnat-4.6. The reasons are explained in there: http://people.debian.org/~lbrenta/debian-ada-policy.html If you are interested you can also watch me explain this at FOSDEM 2011: http://www.youtube.com/watch?v=-3HvUH4fJPM Slides available at http://people.cs.kuleuven.be/~dirk.craeynest/ada-belgium/events/11/110205-fosdem.html -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644849: gnat-4.6: does not work with current gcc-4.6
Matthias, this bug is going to cause all future uploads of GNAT to FTBFS, because gnat-4.6 is already the default and the buildds will install the broken gcc-4.6 and try to build gnat-4.6 with it. So, I think the solution has to be in gcc-4.6. In the past, we used to have symlinks like /usr/lib/gcc/x86_64-linux-gnu/4.6.1 - 4.6. Do you have any objection against reintroducing these symlinks? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644105: libplplot-ada: missing Ada source files
Package: libplplot-ada Version: 5.9.8-2 Severity: serious Justification: violation of Debian Policy for Ada. Renders package unusable. Hello, the package libplplot-ada must contain the Ada source files necessary to compile an Ada application using the binding. Per Debian Policy for Ada[1], the Ada source files should be in /usr/share/ada/adainclude/plplotada. The package currently contains only the .ali files. Thanks for providing this binding! [1] http://people.debian.org/~lbrenta/debian-ada-policy.html -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644110: libplplot-ada: aliversion missing from the package name
Package: libplplot-ada Version: 5.9.8-2 Severity: serious Justification: violation of Debian Policy for Ada[1] [1] http://people.debian.org/~lbrenta/debian-ada-policy.html Finally the violation most difficult to explain in a few words. The Debian Policy for Ada mandates that the name of a development package contain a number which we call the aliversion number. This number must change whenever the contents of any of the .ali files in the package changes (which happens, most notably, whenever recompiling the with a new major version of the compiler). The reason for having an aliversion number in the package *name* is to prevent libplplot-ada to cause another package to FTBFS (the dreaded indirect FTBFS scenario explained in [1]). Therefore, please: - rename libplplot-ada to libplplotada1-dev or something similar (the exact name does not matter as long as it contains an aliversion number); - Add Conflict: with and Replaces: libplplot-ada -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644112: libplplot-ada: missing dependency on gnat-4.6
Package: libplplot-ada Version: 5.9.8-2 Severity: serious Justification: violation of Debian Policy for Ada. The package libplplot-ada contains Ada Library Information (.ali) files which contain the checksums and timestamps of other files in the Ada run-time library. These other files are provided by the package gnat-4.6. Therefore the package libplplot-ada must depend on gnat-4.6. [1] http://people.debian.org/~lbrenta/debian-ada-policy.html So please make the package Depend: on ada-compiler, gnat, gnat-4.6 (yes, all three; explanations why in [1] if you're curious) Also, please consider removing the trailing d in the name of the directory /usr/lib/ada/adalib/plplotadad. I think this is a typo. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642074: libxmlezout1 and libxmlezout0: error when trying to install together
OK then, go ahead. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642074: libxmlezout1 and libxmlezout0: error when trying to install together
The man page should not be in the run-time library package. It should be in the -dev package, which Conflicts: with and Replaces: the previous version. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642074: libxmlezout1 and libxmlezout0: error when trying to install together
xavier grave xavier.gr...@ipno.in2p3.fr writes: Le 25/09/2011 10:10, Ludovic Brenta a écrit : The man page should not be in the run-time library package. It should be in the -dev package, which Conflicts: with and Replaces: the previous version. Do you think I should provide a libxmlezout0 new upload version without the manpage or a dpkg-divert in libxmlezout2-dev should be enough ? The idea is to be able to have at the same time libxmlezout0, libxmlezout1 and libxmlezout2-dev libxmlezout2-dev will have to conflict with libxmlezout0 in addition to libxmlezout1-dev, because it will contain the man page which is currently in libxmlezout0. So what you want will not be possible. However it will be possible to install libxmlezout0 and libxmlezout1 at the same time, without any -dev package. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642074: libxmlezout1 and libxmlezout0: error when trying to install together
xavier grave writes: you are against a dpkg-divert solution ? TBH I didn't know about dpkg-divert until now :) I'm not sure how you're planning to call it. For one thing, the preinst script of libxmlezout2-dev may not know about the presence or absence of libxmlezout0. For another, how do you plan to detect when the diversion ceases to be necessary and to remove it from /var/lib/dpkg/diversions? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642640: libaws: FTBFS: unsatisfiable build-dependencies: gnat, libxmlada3.2-dev (= 3.2-3), libasis2008-dev (= 2008-3), libtemplates-parser11.5-dev (= 11.5-2)
This bug will be fixed when libaws transitions to gnat-4.6. The transition of all Ada packages to the new compiler is currently ongoing. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642641: libflorist: FTBFS: build-dependency not installable: gnat
This bug will be fixed when libflorist transitions to gnat-4.6. This transition is currently ongoing. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642618: gnat-gps: FTBFS: unsatisfiable build-dependencies: gnat, libtemplates-parser11.5-dev (= 11.5-2), libgtkada2.14.2-dev
This bug will be fixed when gnat-gps transitions to gnat-4.6. The transition of all Ada packages to the new compiler is currently ongoing. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642644: libgtkada2: FTBFS: build-dependency not installable: gnat
This bug will be fixed when libgtkada2 transitions to gnat-4.6. The transition of all Ada packages to the new compiler is currently ongoing. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640594: monotone-server: installation fails
severity 640594 grave tags 640594 sid merge 640594 635776 thanks This is really a symptom of #635776. This bug does not affect testing. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640314: gnat-4.4: FTBFS: collect2: ld returned 1 exit status
Mònica Ramírez Arceda mon...@probeta.net writes: /build/gnat-4.4-zZBW7n/gnat-4.4-4.4.6/build/gnattools/xref_lib.o: file not recognized: File truncated Filesystem full? Please look earlier in the build log for confirmation. collect2: ld returned 1 exit status The full build log is available from: http://people.debian.org/~lucas/logs/2011-09-02/gnat-4.4_4.4.6-5_lsid64.buildlog The requested URL /~lucas/logs/2011-09-02/gnat-4.4_4.4.6-5_lsid64.buildlog was not found on this server. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637418: gnat-4.6 ftbfs with eglibc-2.13-16
tags 637418 pending thanks On Thu, 11 Aug 2011 10:42:31 +0200, Matthias Klose wrote: clone 637418 -1 reassign -1 linux-libc-dev block 637418 by -1 thanks aurel32 looks like a kernel headers issue aurel32 doko: the difference is that with the i386/x86-64 headers, asm/sigcontext.h was not included aurel32 with the i386 headers it is aurel32 so it looks like a bug in the kernel headers, but triggered by eglibc changes I found that patching src/gcc/ada/gcc-interface/Makefile.in, in the constant INCLUDES, to replace -I- (deprecated) with -iquote allowed gnat-4.6 to build on i386. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637418: gnat-4.6 ftbfs with eglibc-2.13-16
tags 637418 upstream forwarded 637418 http://gcc.gnu.org/PR50048 thanks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636291: gnat on kfreebsd
Thorsten Glaser t...@mirbsd.de wrote: when I looked at this at Debconf 11, I copied two functions from the Linux or FreeBSD (don’t remember, used the one that looked more fitting) file over. The exact diff I sent to Christoph Egger, don’t have it with me any more. Christoph, can you send the patch here for difference? It differs from http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00139.html I've already uploaded (yesterday evening) with my proposed patch but if your patch is better, I'll be happy to upload with yours. Ludovic, I have copyright assignment to the FSF (also for GCC) standing, so this shouldn’t be a problem. OK but in this particular case, I don't think an assignment is necessary since the patch consists in copying FSF-owned material from one FSF-owned file to another. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636692: gnat-4.6: FTBFS on kfreebsd-*: s-taprop.adb:856:10: pthread_attr_setaffinity_np is undefined (more references follow)
Package: src:gnat-4.6 Version: 4.6.1-1 Severity: serious Tags: upstream In the build logs at https://buildd.debian.org/status/fetch.php?pkg=gnat-4.6arch=kfreebsd-amd64ver=4.6.1-2stamp=1311435165 we see: /build/buildd-gnat-4.6_4.6.1-2-kfreebsd-amd64-Jts3n3/gnat-4.6-4.6.1/build/./gcc/xgcc -B/build/buildd-gnat-4.6_4.6.1-2-kfreebsd-amd64-Jts3n3/gnat-4.6-4.6.1/build/./gcc/ -c -g -O2 -W -Wall -gnatpg s-taprop.adb -o s-taprop.o s-taprop.adb:717:32: lwp_self is undefined s-taprop.adb:856:10: pthread_attr_setaffinity_np is undefined (more references follow) This bug is about the second failure. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636692: gnat-4.6: FTBFS on kfreebsd-*: s-taprop.adb:856:10: pthread_attr_setaffinity_np is undefined (more references follow)
forwarded 636692 http://gcc.gnu.org/PR49444 thanks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636692: gnat-4.6: FTBFS on kfreebsd-*: s-taprop.adb:856:10: pthread_attr_setaffinity_np is undefined (more references follow)
notforwarded 636692 http://gcc.gnu.org/PR49444 forwarded 636692 http://gcc.gnu.org/PR49944 thanks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634546: gnat-4.6: FTBFS: make[4]: *** No rule to make target `../gcc/ada/rts-shared-zcx/libgnat-.so', needed by `gnattools-native'. Stop.
tags 634546 unreproducible moreinfo thanks I have rebuilt gnat-4.6 successfully on amd64 on multiple occasions since you filed this bug, including the upload of 4.6.1-2. Please close the bug or provide more details. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636291: gnat-4.6: FTBFS on kfreebsd-* with s-taprop.adb:717:32: lwp_self is undefined
Package: src:gnat-4.6 Version: 4.6.1-1 Severity: serious Tags: upstream /build/buildd-gnat-4.6_4.6.1-2-kfreebsd-amd64-Jts3n3/gnat-4.6-4.6.1/build/./gcc/xgcc -B/build/buildd-gnat-4.6_4.6.1-2-kfreebsd-amd64-Jts3n3/gnat-4.6-4.6.1/build/./gcc/ -c -g -O2 -W -Wall -gnatpg s-taprop.adb -o s-taprop.o s-taprop.adb:717:32: lwp_self is undefined s-taprop.adb:856:10: pthread_attr_setaffinity_np is undefined (more references follow) I have traced this to the following commit: commit a0d9619fa08b438aaeda58cb70100b803942e9fe Author: charlet charlet@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Wed Apr 15 10:06:20 2009 + 2009-04-15 Nicolas Roche ro...@adacore.com * adaint.c: Add function __gnat_lwp_self that retrieves the LWP of the current thread. * s-osinte-linux.ads: Import the __gnat_lwp_self function as lwp_self * s-taprop-linux.adb (Enter_Task): Store the LWP in the TCB git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@146097 138bc75d-0d04-0410-961f-82ee72b054a4 The function __gnat_lwp_self exists in adaint.c only #if defined(linux), so it may not apply to kfreebsd-*. The problem exists because kfreebsd-* uses s-osinte-kfreebsd-gnu.ads, which does not import the function, but also uses s-taprop-linux.adb, which does use the function. I am not sure what to do: either introduce a new file s-taprop-kfreebsd-gnu.adb or provide the function __gnat_lwp_self also on kfreebsd-* and import it in s-osinte-kfreebsd-gnu.ads. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635112: gnat-4.6: probably miscompiled on powerpc
tags 635112 upstream pending forwarded 635112 http://gcc.gnu.org/PR49819 thanks Євгеній Мещеряков eu...@debian.org writes: severity 635112 serious thanks I also noticed that gnat-4.6 on powerpc constans no g-trasym.adb, but it is present on x86_64. Also build log for gnat-4.6 contains this: cp: cannot stat `rts-shared-zcx/g-trasym.adb': No such file or directory cp: cannot stat `rts-static-sjlj/g-trasym.adb': No such file or directory I guess there are wrong depencencies between make targets somewhere. Thanks, this led me to finding the problem, which is in the upstream sources. It is easy to correct; I'll upload a fix today or the day after. I've forwarded the bug as http://gcc.gnu.org/PR49819. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631906: gcc-4.4: cannot find -lgcc_s after upgrade to 4.4.6-6
Thanks for submitting this bug for gcc-4.4; a similar one (#631627) exists for gcc-4.6. My analysis of this bug (with workaround) is here: http://lists.debian.org/debian-gcc/2011/06/msg00209.html -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631817: libgcc1: missing link libgccc_s.so - libgcc_s.so.1
Pedro Larroy wrote: l /lib/x86_64-linux-gnu/libgcc_s.so.1 ls: cannot access /lib/x86_64-linux-gnu/libgcc_s.so.1: No such file or directory l /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/ ls: cannot access /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/: No such file or directory [...] ii gcc-4.6 4.6.0-10 Further research indicates that the version of gcc-4.6 currently in testing is not yet multiarch-aware; the first version with multiarch was 4.6.0-12; the latest version is 4.6.0-14. It should have migrated to testing five days ago but hasn't. The reasons are unclear; the PTS says the package is out of date on powerpc but the build succeeded on 2011-06-18. Could someone please allow 4.6.0-14 to migrate? Pedro, could you please try to reproduce the problem with gcc-4.6 (=4.6.0-14)? (i.e. install it manually with dpkg, or update your system to sid, or create a sid chroot) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614277: oolite: FTBFS on all architectures
Yavor Doganov writes: The fix is simple -- replace #import math.h in OOCocoa.h and #import stdint.h in OOCPUInfo.h with #include. OOCocoa.h probably also needs `#include assert.h' as well. The #import directive should *never* be used for plain C headers, otherwise it may lead to awkward issues like these. Thanks a lot for the tips. I agree, #import is simply not C. Nicolas, if this bug is present in 1.75, could you please report it upstream? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614277: oolite: FTBFS on all architectures
My fault. I built the package on my machine with libgnustep-base-dev (=1.20.1-1) then uploaded, only to discover that 1.20.2-1 had been uploaded in the mean time. This broke source compatibility with oolite. We're working on a fix now. Please be patient. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602052: powernowd: Drop obsolete package
tags 602052 moreinfo thanks After reading this bug report, I removed powernowd from my system. The CPU frequency immediately jumped from 800 MHz to the maximum 2000 MHz and stayed there, even if the machine was idle. I reinstalled powernowd and the CPU frequency went back to 1800, then 1600, then 800 MHz in a matter of seconds. If this package is obsolete and replaced by the kernel, how should I configure my kernel to throttle the CPU back, and why is the kernel not configured to do that out of the box? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602052: powernowd: Drop obsolete package
Andreas Henriksson writes: It's apparently much more efficient to IDLE as much as possible to save power, and to do that you should be running the processor on as high speed as possible to get whatever work you need to get done finished as soon as possible to maximize the time that can be used for idling. OK, this seems very reasonable but could you please tell me how to *practically* achieve that? On my machine with powernowd, it runs at 800 MHz most of the time (when I type etc) and uses the full speed (2000 MHz) only when compiling, or for brief periods of time while rendering web pages and the like. I agree that the intermediate frequencies are not very useful. I'd be all in favor of running my processor at 0 MHz most of the time, the question is how? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601117: adacontrol: FTBFS in squeeze: error: (/usr/lib/ada/adalib/asis/a4g-contt-dp.ali is obsolete and read-only)
clone 601117 -1
reassign -1 libgnatvsn4.4-dev
retitle -1 Debian Ada policy violation: uintp.ali changed between 4.4.4-5 and
4.4.5-2
block 601117 by -1
thanks
Darn. The dreaded Indirect FTBFS problem[1] again. When uploading
gnat-4.4 (=4.4.5-1 and -2) I forgot to check that the .ali files in
libgnat{vsn,prj}4.4-dev were unchanged. It turns out that uintp.ali (in
libgnatvsn4.4-dev) has changed; this is incorrect. I'll revert that
particular change.
[1]
http://people.debian.org/~lbrenta/debian-ada-policy.html#Ada-Library-Information-files
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600052: gnat-4.4: FTBFS on armel
For the record, this late in the release cycle I am personally tempted to resolve this bug by dropping support for armel in all Ada packages. The buildds have caused us a lot of trouble in the past and Matthias seems to be the only person willing and able to build manually on armel. If even he needs help, then I'm pessimistic about armel. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599704: gnat-4.4: FTBFS: Build-Depends on gcc-4.4-source (=4.4.4) which is no longer in testing
reopen 599704 thanks The bug is tagged testing but not fixed in testing yet. Please close this bug only after the package migrates to testing. Also, I intend to use this bug as reference for requesting unblocking of the package. Before 4.4.5-1 can migrate, it must build on all platforms; unfortunately it FTBFS on s390 and armel. I have not yet had time to investigate why. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599704: unblock: gnat-4.4/4.4.5-1
Dear release managers, Because gcc-4.4 (=4.4.5) is now in Squeeze, gnat-4.4 (=4.4.4-5) no longer builds from source. An updated gnat-4.4 package (merging all the packaging changes from gcc-4.4) is available in unstable. Please unblock it so it migrates to testing after its normal 10-day period in unstable. The changes between 4.4.4-5 and 4.4.5-1 are a bit too large for my taste (upstream version change + packaging changes) but all of these changes have been tested and approved as part of gcc-4.4 already. I have also personally verified that the Ada Library Information files are unchanged, thus preserving compatibility with all the existing -dev packages that depend on gnat-4.4. PS. Thanks to Matthias Klose for building on armel and s390, these two buildd failed for reasons external to the package. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599704: unblock: gnat-4.4/4.4.5-1
Luk Claes l...@debian.org writes: On 10/11/2010 02:26 PM, Ludovic Brenta wrote: Dear release managers, Because gcc-4.4 (=4.4.5) is now in Squeeze, gnat-4.4 (=4.4.4-5) no longer builds from source. An updated gnat-4.4 package (merging all the packaging changes from gcc-4.4) is available in unstable. Please unblock it so it migrates to testing after its normal 10-day period in unstable. The changes between 4.4.4-5 and 4.4.5-1 are a bit too large for my taste (upstream version change + packaging changes) but all of these changes have been tested and approved as part of gcc-4.4 already. I have also personally verified that the Ada Library Information files are unchanged, thus preserving compatibility with all the existing -dev packages that depend on gnat-4.4. unblocked Thanks a lot. After I filed this request, Matthias filed Bug#599844: gnat-4.4 build-depends on gcc-snapshot on armel which is severity: serious, too. I am building gnat-4.4 (=4.4.5-2) now and will upload shortly; I hope unblocking it does not require any additional work on your part. FYI, the fix consists in merging additional packaging changes from gcc-4.4 (=4.4.5-3) which has been uploaded to unstable today. This merge also adds updates from the upstream stable gcc-4_4-branch that do not affect Ada. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599704: gnat-4.4: FTBFS: Build-Depends on gcc-4.4-source (=4.4.4) which is no longer in testing
Package: gnat-4.4 Version: 4.4.4-5 Severity: serious Justification: FTBFS Tags: testing patch The package currently in testing, gnat-4.4 (=4.4.4-5), build-depends on gcc-4.4-source (= 4.4.4), gcc-4.4-source ( 4.4.5). This condition is no longer satisfied in testing because of the migration of gcc-4.4-source (=4.4.5-1) into testing. There are three possible ways to solve this problem: 1) Do not change the packaging of GNAT, but remove the build-dependency on gcc-4.4-source; include the entire pristine source of GCC 4.4.4 (57 MiB or so) in the .diff.gz. This is what Matthias Klose has done in gnat-4.4 (=4.4.4-6), already uploaded to unstable. 2) Do not change the packaging of GNAT, update the build-dependency to gcc-4.4-source (= 4.4.5), gcc-4.4-source ( 4.4.6), and add a large patch to the .diff.gz that reverts all the changes between 4.4.4 and 4.4.5. Not attempted yet. 3) Update the packaging of GNAT and the build-dependency on gcc-4.4-source by merging all the changes in gcc-4.4 between 4.4.4-1 and 4.4.5-2. This is what Matthias has done in gnat-4.4 (=4.4.5-0) and uploaded to experimental. I have verified that 4.4.5-0 preserves the .ali files, so I think it is suitable for testing. I have uploaded 4.4.5-1 to unstable with low priority. Please unblock the package so that 4.4.5-1 can migrate to Squeeze after its normal period in unstable. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595830: gnat-4.4: FTBFS in squeeze: xref_lib.o: file not recognized: File truncated
Lucas, any update on this? I'm tempted to close it now. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595830: gnat-4.4: FTBFS in squeeze: xref_lib.o: file not recognized: File truncated
tags 595830 unreproducible moreinfo thanks I just rebuilt successfully on sid. I suspect your disk became full suring compilation? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571191: Possible problems in your Debian packages
I was going to explain the situation with alpha but you beat me to it; thanks for submitting #594106. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559893: Release-critical bugs in monotone: ping?
Is anyone still interested in maintaining monotone in Debian? If not, I will consider switching to another DVCS. This would be a shame. I like monotone very much and I have been using it since 2006. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559893: Bug#574512: Release-critical bugs in monotone: ping?
Francis Russell wrote: Ludovic Brenta wrote: Is anyone still interested in maintaining monotone in Debian? Just thought I'd add that I use monotone from Debian and know others who do as well. I'm willing to help in whatever way I can although I'm not a Debian Maintainer. Is this just a manpower issue? Yes. One of the bugs (#574512) that you filed is reportedly fixed upstream but nobody bothered to backport the patch into 0.47 even though it is a grave functionality bug. As for #559893, Richard has not yet answered the question from Alexander on 2010-04-23. Lastly, #566060 (updated Portuguese translation) requires a few minutes of work but I see nothing done (since January). Your help would be very welcome; you do not have to be a Debian developer; see http://bugs.debian.org/574609 for details. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581330: narval: FTBFS: No patches in series
It just occurred to me that it might be better not to use quilt at all. Currently, you copy .gpr files from the installed Debian packages and patch them locally with quilt from the upstream Makefile but only if the upstream Makefile detects that it is running on Debian. A better approach might be to: - ship the patched .gpr files directly in the debian/ directory - make the upstream makefile distribution-agnostic - make the upstream makefile independent on quilt - remove the build-dependency on quilt from debian/control (this build-dependency can lead people to assume the Debian packaging scripts use quilt when, really, only the upstream Makefile does). Just a thought. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580907: libadasockets-dev: lacks aliversion in package name
Package: libadasockets-dev Version: 1.8.6-3 Severity: serious Justification: Debian Policy for Ada violation, can trigger the infamous Indirect FTBFS bug Please rename libadasockets-dev to libadasockets2-dev. Justification: Debian Policy for Ada, §5.2 Library names and packaging structure. Be sure to add Conflicts: and Replaces: referencing the previous version. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570887: FTBFS: /usr/bin/ld: cannot find -lapq-postgresqlhelp
reopen 570887 thanks The attempt at a fix failed: make[1]: Entering directory `/build/buildd-apq-postgresql_3.0-3-hppa-FQK8gP/apq-postgresql-3.0' [...] building dynamic library for project apq.postgresql /usr/bin/gcc-4.4 -shared -o /build/buildd-apq-postgresql_3.0-3-hppa-FQK8gP/apq-postgresql-3.0/lib/libapq-postgresql.so.3.0 -L/usr/lib/gcc/hppa-linux-gnu/4.4.3/adalib/ -Wl,--export-dynamic -L/home/buildd/lib -lpq -lapq-postgresqlhelp -L/usr/lib -lapq -L/usr/lib/gcc/hppa-linux-gnu/4.4.3/adalib/ -lgnat-4.4 -Wl,-soname,libapq-postgresql.so.3.0 /build/buildd-apq-postgresql_3.0-3-hppa-FQK8gP/apq-postgresql-3.0/obj/apq-postgresql-decimal.o ... /usr/bin/ld: cannot find -lapq-postgresqlhelp Note how debian/rules passes -L/home/buildd/lib instead of -L/build/buildd-apq-postgresql_3.0-3-hppa-FQK8gP/apq-postgresql-3.0/lib. Of course, the directory where the build takes place is dynamic so its path cannot be hardcoded. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570887: FTBFS: /usr/bin/ld: cannot find -lapq-postgresqlhelp
Adrian-Ken, do you need help with this bug? It seems quite trivial to fix by adding the proper -L option. Note that this package is the last Ada package that has not yet transitioned to gnat-4.4 in testing; this bug prevents removal of gnat-4.3. Also, we are getting close to freezing point. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559893: monotone-server: hooks.lua.base is outdated
As of monotone 0.47 I do not see any file named hooks.lua.base either in the upstream sources or in the Debian packaging scripts. Is this an upstream bug? Is it fixed in 0.47-1? If not, 0.47-1 which I am about to upload will not migrate to testing. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571191: music123: please upgrade to gnat-4.4
Package: music123 Version: 15-0.2 Severity: serious Justification: gnat-4.3 will not be in squeeze gnat-4.3 has RC bugs that I will not fix because the default Ada compiler is now gnat-4.4. Please update the package to use gnat-4.4 and recompile. Note that, since music123 is an application rather than a library, it is sufficient to just build-depend on gnat without any version. This will make the package use the default Ada compiler. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568814: polyorb: FTBFS on sparc: 1 test failed
Package: polyorb Version: 2.6.0~20090423-5 Severity: serious Note that the bug may also be present in -4; we do not have a buildd log. I believe it is necessary to run a build by hand on sparc and inspect the detailed server-side logs. == Begin test CORBA/MIOP == Sending CORBA.String: PASSED Sending CORBA.Long..: PASSED Previous tests went OK on the server side...: FAILED Calling function with return value raised an exception..: PASSED Shut down server(s).: PASSED END TESTS...: FAILED - FAILED: 0 out of 1 tests passed, with 0 expected failed tests Scenario CORBA_MIOP.: FAILED -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567668: gnat-gps: FTBFS on kfreebsd-*: common/tty/terminals.c:53:23: error: termio.h: No such file or directory
Package: gnat-gps Version: 4.3-1 Severity: serious Tags: help X-Debbugs-CC: debian-...@lists.debian.org, Xavier Grave xavier.gr...@ipno.in2p3.fr, Nicolas Boulenguez nicolas.bouleng...@free.fr, Olivier Scalbert olivier.scalb...@algosyn.com The buildds on both kfreebsd-* failed with: gcc -c common/tty/terminals.c -o common/tty/terminals.o -g -O2 common/tty/terminals.c:53:23: error: termio.h: No such file or directory common/tty/terminals.c:251:1: warning: TABDLY redefined In file included from /usr/include/termios.h:40, from common/tty/terminals.c:57: /usr/include/bits/termios.h:120:1: warning: this is the location of the previous definition make: *** [common/tty/terminals.o] Error 1 I believe the difference between the terminal interfaces in Linux and FreeBSD is well understood (by FreeBSD porters, that is -- I'm not an expert and I do very little C programming anyway). I no longer have access to a Debian GNU/kFreeBSD host and I lack the time to investigate this issue. Could someone please help? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562342: Bug #562342: polyorb: FTBFS: tests failed
Lucas Nussbaum wrote: What about testing with the network down to find which is the affected test, and disable that test? the network down is much too general. Remember: this is about distributed applications; they obviously require the network. What that means is they must at least be able to open sockets to localhost. Maybe they make some wild assumptions, e.g. that 127.0.0.1 is reachable or that there is some sort of DNS available that will resolve localhost. Maybe they need to be able to listen on some specific UDP or TCP ports. I don't know and that's why I tagged this bug with help. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562342: Bug #562342: polyorb: FTBFS: tests failed
Lucas Nussbaum wrote: On 27/01/10 at 09:42 +0100, Ludovic Brenta wrote: Lucas Nussbaum wrote: What about testing with the network down to find which is the affected test, and disable that test? the network down is much too general. Remember: this is about distributed applications; they obviously require the network. What that means is they must at least be able to open sockets to localhost. Maybe they make some wild assumptions, e.g. that 127.0.0.1 is reachable or that there is some sort of DNS available that will resolve localhost. Maybe they need to be able to listen on some specific UDP or TCP ports. I don't know and that's why I tagged this bug with help. All of this is true on my build nodes. The loopback network is fully functional. You just can't talk to the Internet. That statement is of little help. Posting the logs of a rebuild of 2.6.0~20090423-3 or -4 on those internet-less machines would be much more helpful. Reto has changed the test harness so it sends more details to the build log for analysis. Maybe one of us could then pinpoint the problem. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562342: Bug #562342: polyorb: FTBFS: tests failed
Some of the tests of 2.6.0~20090423-4 just failed on the kfreebsd-amd64 buildd (they all passed in the previous build). Apparently all the test failures were due to: polyorb.utils.sockets: connect to 172.17.12.3 failed: [61] Connection refused The IP address of the host (fano.debian.org) appears to be 206.12.19.110 at the moment (not sure whether it is a static or dynamic address). This suggests that some of the tests indeed rely on network access to machines other than the one doing the build. Xavier, Reto: could you please try to audit the test suite for hardcoded host names or IP addresses? Note that if a host name is hardcoded, this also requires access to a DNS. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562342: Bug #562342: polyorb: FTBFS: tests failed
The kfreebsd-i386 buildd, finzi.debian.org, had similar failures, this time the error message is: polyorb.utils.sockets: connect to 172.17.12.2 failed: [61] Connection refused (as opposed to 172.17.12.3 on fano.debian.org). Is it possible that these IP addresses really are those of the DNS servers themselves? I'd like to see the contents of /etc/resolv.conf on those two hosts. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562342: Bug #562342: polyorb: FTBFS: tests failed
severity 562342 minor thanks This is clearly a problem with the network configuration of the machine doing the tests. I will close the bug when I fully understand what part of the configuration triggers the test failures; in the mean time, lowering the severity to minor. Note that polyorb being a package for *distributed* applications, a network configuration that allows communications between partitions is a requirement. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562342: Bug #562342: polyorb: FTBFS: tests failed
Lucas Nussbaum writes: severity 562342 serious thanks On 26/01/10 at 20:36 +0100, Ludovic Brenta wrote: This is clearly a problem with the network configuration of the machine doing the tests. I will close the bug when I fully understand what part of the configuration triggers the test failures; in the mean time, lowering the severity to minor. Note that polyorb being a package for *distributed* applications, a network configuration that allows communications between partitions is a requirement. I don't see how a network configuration problem could affect the success of the build, since you are not allowed to rely on the network being available for the built to succeed. The build succeeds; only the test suite fails. Are you suggesting we not run the test suite? That would only hinder our ability to find genuine bugs like e.g. #561156. If someone can tell me what part of the network configuration causes the tests to fail, we could try to detect the condition and run the test suite if and only if the configuration permits. I think that would be the best solution. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562342: #562342: polyorb: FTBFS: tests failed
tags 562342 unreproducible help thanks I cannot reproduce the test failures on my amd64 machine. I think the failures are probably due to the network configuration of your machine but I am unable to pinpoint exactly what configuration the tests need and assume. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556809: adasockets: FTBFS: sockets.ads:60:16: (style) in should be omitted
The bug is triggered by the transition from gnat-4.3 to gnat-4.4. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561882: texlive-formats-extra: fmtutil-sys failed during configure
Package: texlive-formats-extra Version: 2009-4 Severity: grave Justification: package installation fails While configuring the package, aptitude says: Setting up texlive-formats-extra (2009-4) ... Running mktexlsr. This may take some time... done. Building format(s) --all --cnffile /etc/texmf/fmt.d/10texlive-formats-extra.cnf. This may take some time... fmtutil-sys failed. Output has been stored in /tmp/fmtutil.hYDO5flj Please include this file if you report a bug. dpkg: error processing texlive-formats-extra (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: texlive-formats-extra E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up texlive-formats-extra (2009-4) ... Running mktexlsr. This may take some time... done. Building format(s) --all --cnffile /etc/texmf/fmt.d/10texlive-formats-extra.cnf. This may take some time... fmtutil-sys failed. Output has been stored in /tmp/fmtutil.ylUuaQy1 Please include this file if you report a bug. dpkg: error processing texlive-formats-extra (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: texlive-formats-extra Press return to continue. Attached is the contents of /tmp/fmtutil.ylUuaQy1. The salient point is: fmtutil: running `pdftex -ini -jobname=eplain -progname=eplain -translate-file=cp227.tcx *eplain.ini' ... This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (INITEX) restricted \write18 enabled. (/usr/share/texmf-texlive/web2c/cp227.tcx) entering extended mode (/usr/share/texmf-texlive/tex/eplain/eplain.ini ! I can't find file `bplain'. l.3 \input bplain (Press Enter to retry, or Control-D to exit) Please type another input file name: ! Emergency stop. -- Ludovic Brenta. fmtutil.ylUuaQy1 Description: application/empty
Bug#561158: polyorb: FTBFS: python: command not found
retitle 561158 polyorb: FTBFS: python: command not found thanks The same error also occurred on hppa and s390 so is not specific to kfreebsd-i386. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561155: polyorb: FTBFS on i386, one test failing in test suite
I rebuilt polyorb in my i386 chroot (on a dual-core amd64 system) and the test suite passed, so I uploaded. I am not closing this bug yet because I want to understand the test failure; if this test depends on certain hardware or kernel versions to succeed, I want to know about it. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558980: access to hppa machine to work on Bug#558980
Carlos O'Donell wrote:
On Sun, Dec 13, 2009 at 10:03 AM, Stephen Leake wrote:
Frans Pop gave me access to his machine. I have some more information
on the bug.
If I compile from full GNADE source (not using the GNADE dynamic or
static libraries), the code works.
What does from full GNADE source mean?
I think that means recompile the application program and the sources of
the library into a single, statically-linked program as opposed to
compile the library sources, create a (static|shared) library and link
into the executable.
[...]
With the static library, I get a stack overflow (caught and reported
by the Ada runtime), during elaboration of a compiler-provided
container library.
Could you please define during elaboration?
It seems only Ada programmers know about elaboration :)
In a nutshell, elaboration is all that happens between the transfer of
control from the dynamic loader to the executable and the start of
execution of the main subprogram (main() in C and C++, anything in Ada).
Elaboration consists in allocating and initialalizing nonstatic global
variables, i.e. those declared outside of any subprogram but whose value is
unknown at compile time. This might involve calling user-defined functions
that return the initial value of a variable. Subprograms and Ada packages,
too, are elaborated; their elaboration consists only in making sure all the
global variables and other subprograms they depend on are already
elaborated. Example:
-*- mode: c -*-
#include stdlib.h
int i = foo ();
int main () { puts (this is called after elaboration\n); return i; }
int foo () { puts (this is called during elaboration\n); return rand ();
}
The example illustrates the importance of controlling elaboration order. In
this case, i must be elaborated before main() is called but after puts()
and rand () are elaborated.
Ada offers precise control of elaboration order and the compiler can report
the elaboration order it has chosen for a given executable program.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557905: [mips only] gnatbind error: s-linux.ali not found, s-linux.ads must be compiled
Package: gnat-4.4 Version: 4.4.2-3 Severity: normal First of all, many thanks to Aurelien for building and uploading gnat-4.4 on mips (see #557905). However I now see three Ada packages FTBFS on mips with the same error error: s-linux.ali not found, s-linux.ads must be compiled during binding. https://buildd.debian.org/fetch.cgi?pkg=adacontrol;ver=1.9r4-4;arch=mips;stamp=1260139936 https://buildd.debian.org/fetch.cgi?pkg=libtemplates-parser;ver=11.5-1;arch=mips;stamp=1260046957 https://buildd.debian.org/fetch.cgi?pkg=adabrowsever=4.0.3-3arch=mipsstamp=1259403924file=log adacontrol and adabrowse use libasis2008-dev but libtemplates-parser does not, so ASIS is not a common denominator. Aurelien, could you please send me the complete build log of gnat-4.4 on mips? There may be something obvious in there. Also note that s-linux is one of these pesky architecture-dependent files (see system-linux-mips.ads). -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561121: FTBFS on sparc: ICE in do_SUBST, at combine.c:677
Package: polyorb Version: 2.6.0~20090423-1 Severity: serious For the very first upload, polyorb FTBFS on sparc (it succeeds on i386, amd64 and powerpc): gcc-4.4 -c -gnatyg -gnatwae -gnat05 -gnatec=/build/buildd-polyorb_2.6.0~20090423-1-sparc-aHRpyU/polyorb-2.6.0~20090423/compilers/config.adc -g -O2 -I/build/buildd-polyorb_2.6.0~20090423-1-sparc-aHRpyU/polyorb-2.6.0~20090423/compilers/gnatdist xe.adb +===GNAT BUG DETECTED==+ | 4.4.2 (sparc-unknown-linux-gnu) in do_SUBST, at combine.c:677 | | Error detected around /usr/lib/gcc/sparc-linux-gnu/4.4.2/adainclude/g-table.adb:299| [...] raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424 gnatmake: xe.adb compilation error make[1]: *** [build-po_gnatdist] Error 4 make[1]: Leaving directory `/build/buildd-polyorb_2.6.0~20090423-1-sparc-aHRpyU/polyorb-2.6.0~20090423' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 Note: I did expect the package to FTBFS on at least a couple of architectures, so I am not surprised :) My dear apprentices, please look at [1] for an example of what to do in such cases. If things come to worse and you cannot solve or work around the problem, the last recourse is to remove sparc from Architectures:. [1] http://lists.debian.org/debian-hppa/2009/12/msg00012.html -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561155: polyorb: FTBFS on i386, one test failing in test suite
Package: polyorb Version: 2.6.0~20090423-1 Severity: serious Justification: FTBFS on i386 Excerpt from the buildd log: Starting scenario CORBA_MIOP Scenario CORBA_MIOP.: FAILED [...] 35 scenarios executed, 85 out of 86 tests passed make[1]: *** [run_tests] Error 1 make: *** [build-stamp] Error 2 dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 make[1]: Leaving directory `/build/buildd-polyorb_2.6.0~20090423-1-i386-wNDAf3/polyorb-2.6.0~20090423' Build finished at 20091214-1750 FAILED [dpkg-buildpackage died] Purging /var/lib/schroot/mount/sid-i386-sbuild-8e0be6bc-c079-4e95-be7e-bfc266ba86f1/build/buildd-polyorb_2.6.0~20090423-1-i386-wNDAf3
Bug#561156: polyorb: FTBFS on kfreebsd-amd64: only 42 out of 86 tests passed
Package: polyorb Version: 2.6.0~20090423-1 Severity: serious Justification: FTBFS on kfreebsd-amd64 Excerpt from the buildd log: Running all 35 scenario files from: /build/buildd-polyorb_2.6.0~20090423-1-kfreebsd-amd64-XNmMrY/polyorb-2.6.0~20090423/testsuite/scenarios Starting scenario CORBA_ALL_EXCEPTIONS Scenario CORBA_ALL_EXCEPTIONS...: FAILED Starting scenario CORBA_BENCHS Scenario CORBA_BENCHS...: FAILED Starting scenario CODE_SETS Scenario CODE_SETS..: FAILED Starting scenario DOMAINMANAGER Scenario DOMAINMANAGER..: FAILED Starting scenario CORBA_HARNESS Scenario CORBA_HARNESS..: FAILED Starting scenario CORBA_INTEROP Scenario CORBA_INTEROP..: PASSED Starting scenario LOCAL Scenario LOCAL..: FAILED Starting scenario LOCATION_FORWARDING Scenario LOCATION_FORWARDING: FAILED Starting scenario OBJECT Scenario OBJECT.: FAILED Starting scenario ORB_INIT Scenario ORB_INIT...: FAILED Starting scenario CORBA_PERFORMANCE Scenario CORBA_PERFORMANCE..: PASSED Starting scenario CORBA_PORTABLEINTERCEPTOR Scenario CORBA_PORTABLEINTERCEPTOR..: FAILED Starting scenario PORTABLESERVER Scenario PORTABLESERVER.: FAILED Starting scenario SHUTDOWN Scenario SHUTDOWN...: FAILED Starting scenario CHAINED_LIST Scenario CHAINED_LIST...: PASSED Starting scenario DYNAMIC_DICT Scenario DYNAMIC_DICT...: PASSED Starting scenario FIXED Scenario FIXED..: PASSED Starting scenario INIT Scenario INIT...: PASSED Starting scenario OA Scenario OA.: PASSED Starting scenario POA Scenario POA: PASSED Starting scenario RANDOM Scenario RANDOM.: PASSED Starting scenario CORE_SYNC_POLICIES Scenario CORE_SYNC_POLICIES.: FAILED Starting scenario TASK Scenario TASK...: PASSED Starting scenario URI_ENCODING Scenario URI_ENCODING...: PASSED Starting scenario IR Scenario IR.: FAILED Starting scenario NAMING Scenario NAMING.: FAILED Starting scenario TIME Scenario TIME...: FAILED Starting scenario ALL_FUNCTIONS Scenario ALL_FUNCTIONS..: FAILED Starting scenario ALL_TYPES Scenario ALL_TYPES..: FAILED Starting scenario ECHO Scenario ECHO...: FAILED Starting scenario CORBA_RANDOM Scenario CORBA_RANDOM...: FAILED Starting scenario CORBA_SECURE_ECHO Scenario CORBA_SECURE_ECHO..: PASSED Starting scenario CORBA_MIOP Scenario CORBA_MIOP.: FAILED Starting scenario MOMA Scenario MOMA...: PASSED Starting scenario POLYORB_CORE Scenario POLYORB_CORE...: PASSED 35 scenarios executed, 42 out of 86 tests passed make[1]: *** [run_tests] Error 1 make[1]: Leaving directory `/build/buildd-polyorb_2.6.0~20090423-1-kfreebsd-amd64-XNmMrY/polyorb-2.6.0~20090423' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561158: polyorb: FTBFS on kfreebsd-i386: python: command not found
Package: polyorb Version: 2.6.0~20090423-1 Severity: serious Justification: FTBFS on kfreebsd-i386 Should polyorb build-depend on Python? If so, why and which version of Python? Excerpt from the buildd log: Running automake configure.ac:19: installing `support/config.guess' configure.ac:19: installing `support/config.sub' docs/Makefile.am:170: `%'-style pattern rules are a GNU make extension docs/Makefile.am:171: `%'-style pattern rules are a GNU make extension docs/Makefile.am:172: `%'-style pattern rules are a GNU make extension docs/Makefile.am:173: `%'-style pattern rules are a GNU make extension docs/Makefile.am:174: `%'-style pattern rules are a GNU make extension docs/Makefile.am:178: `%'-style pattern rules are a GNU make extension docs/Makefile.am:182: `%'-style pattern rules are a GNU make extension docs/Makefile.am:185: `%'-style pattern rules are a GNU make extension docs/Makefile.am:190: `%'-style pattern rules are a GNU make extension docs/Makefile.am:200: `%'-style pattern rules are a GNU make extension docs/Makefile.am:210: `%'-style pattern rules are a GNU make extension docs/Makefile.am:213: `%'-style pattern rules are a GNU make extension docs/Makefile.am:216: `%'-style pattern rules are a GNU make extension docs/Makefile.am:219: `%'-style pattern rules are a GNU make extension docs/Makefile.am:222: `%'-style pattern rules are a GNU make extension docs/Makefile.am:229: `%'-style pattern rules are a GNU make extension docs/Makefile.am:232: `%'-style pattern rules are a GNU make extension docs/Makefile.am:235: `%'-style pattern rules are a GNU make extension docs/Makefile.am:1: installing `support/texinfo.tex' Generating IDL tree accessors support/reconfig: line 72: python: command not found make: *** [configure] Error 127 dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561156: polyorb: FTBFS on kfreebsd-amd64: only 42 out of 86 tests passed
tags 561156 -patch thanks Dann, the patch you just sent appears to be for another bug on package tn5250, not polyorb. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
