Bug#352368: gnat-gps: AMD64 port?
Chris Metzler <[EMAIL PROTECTED]> writes: > Just a wishlist request for an AMD64 port of this IDE. I presume > it'll be possible to run it in the 32-bit chroot jail, and that's > what I'm going to try next; but it'd be nice to not have to. I used > it a lot on my previous machine and would like to again. I plan to transition all Ada packages to gcc-4.1. In theory, this will make it possible to support amd64. In practice, I don't have access to such a machine, so I will rely on users to provide testing and any necessary patches. The transition should take place in time for Etch, but will probably take several months to complete. Your help will be appreciated. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346317: file conflicts
Matthias Klose <[EMAIL PROTECTED]> writes: > trying to overwrite `/usr/lib/libgnat.so', which is also in package gnat-4.0 > libgnat.so doesn't belong into the library package. Right. This was from a user request on comp.lang.ada, he wanted C programmers to be able to link against libgnat without having to guess the exact path (/usr/lib/gcc-lib/.../adalib). And C programmers don't need gnat, just gcc. I'll just place the symlink in gnat in -19. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297985: gnat-gps causes the X server to crash when compiling
Here is interesting info that was sent to the gnat-gps bug, #297980: --- Begin Message --- Package: gnat-gps Version: 2.1.0-3 The problem does not occur with udev enabled (at least for udev 0.053-1, kernel 2.6.8-2-386): F4 and "Build" works properly. However, the problem (X11 crash at F4) comes back if udev is disabeled again (using, for example, "UDEV_DISABLED=yes" as boot parameter). -- Peter Keller. --- End Message ---
Bug#297985: Bug#297980: gnat-gps: causes the X server to crash when compiling
I ran gnat-gdb under strace and I can find nothing obvious. It
appears to me that the X server shuts down _after_ the compilation
completes.
For a while I suspected something to do with pseudo-ttys, because of a
thread[1] on the gps-users mailing list.
[1] http://lists.adacore.com/pipermail/gps-users/2004-December/000318.html
I rebuilt gnat-gps with --without-ptys but the results are the same.
On Debian, GPS has no problem using a pseudo-tty to communicate with
the underlying compiler:
stat64("/dev/ptypf", {st_mode=S_IFCHR|0666, st_rdev=makedev(2, 15), ...}) = 0
open("/dev/ptypf", O_RDWR|O_NONBLOCK) = 5
access("/dev/ttypf", R_OK|W_OK) = 0
fcntl64(5, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
fcntl64(5, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0
stat64("/home/lbrenta/bin/gnatmake", 0xbfffca34) = -1 ENOENT (No such file or
directory)
stat64("/usr/local/bin/gnatmake", 0xbfffca34) = -1 ENOENT (No such file or
directory)
stat64("/usr/bin/gnatmake", {st_mode=S_IFREG|0755, st_size=1067896, ...}) = 0
fork() = 7762
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
...
read(5, "gnatgcc -c -g -o /home/lbrenta/s"..., 4096) = 165
...
--- SIGCHLD (Child exited) @ 0 (0) ---
...
read(5, "sdc.adb:28:06: (style) bad inden"..., 4096) = 418
...
read(5, 0xbfffc824, 4096) = -1 EIO (Input/output error)
...
close(5)= 0
close(5)= -1 EBADF (Bad file descriptor)
ioctl(5, TIOCGPGRP, [1]) = -1 EBADF (Bad file descriptor)
kill(-1, SIGINT
The file ends here.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308174: libgnat-4.0: depends on unavailable version of libgcc1
Package: libgnat-4.0 Version: 4.0.0-2 Severity: grave Tags: experimental Justification: renders package uninstallable libgnat-4.0 depends on libgcc1 (>= 1:4.0-0pre6ubuntu4), when the available version is 1:4.0.0-2 (from same source package). -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306628: gnat-gps: Error on startup on PowerPC
Niklaus Giger writes: > gnat-gps > gnat-gps: error while loading shared libraries: > /usr/lib/libgtkada-2.4.so.0: R_PPC_REL24 relocation at 0x0178d778 for > symbol `abort' out of range The function 'abort' is part of the GNU C library in /lib/libc.so.6. The message seems to indicate that libc.so.6 was compiled without the mandatory -fPIC option, which instructs the compiler to emit position-independent code. To ascertain that this is indeed the problem, could you try this: $ readelf -a /lib/libc.so.6 | grep abort Please send the output. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306628: gnat-gps: Error on startup on PowerPC
Niklaus Giger writes: > Am Mittwoch, 27. April 2005 21.48 schrieben Sie: >> readelf -a /lib/libc.so.6 | grep abort > Here it is: >782: 0fea3f30 512 FUNCGLOBAL DEFAULT 10 Best regards I may be wrong but I think this is the problem; there should be a second line with R_PPC_REL24 in it. Could you try reinstalling libc6? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306834: gnat: Wrong code generated for legal program, RM 6.4.1(13), 9.5.1(3), 9.5.3(8)
Package: gnat
Version: 3.15p-12
Severity: normal
-- fails in 3.15p, 3.4, and 4.0
-- RM 6.4.1(13)
-- RM 9.5.1(3)
-- RM 9.5.3(8)
with text_io; use text_io;
procedure Test_144 is
type intp is access all integer;
i: aliased integer := 3;
x1: intp;
procedure p1(x: out intp) is
begin
null;
end;
protected type T1 is
entry e1 (x: out intp);
procedure p2(x: out intp);
end T1;
protected body T1 is
entry e1 (x: out intp) when true is
begin
null;
end e1;
procedure p2(x: out intp) is
begin
null;
end;
end T1;
task type T2 is
entry e1 (x: out intp);
end T2;
task body T2 is
begin
for i in 1..2 loop
accept e1 (x: out intp) do
begin
null;
end;
end e1;
end loop;
end T2;
pt: T1;
tt: T2;
procedure doit(x2: intp) is
procedure check is
begin
if x1 = x2
then put_line("PASSED");
else put_line("FAILED");
end if;
x1 := x2;
end;
begin
x1 := x2;
p1(x1);
check;
pt.p2(x1);
check;
pt.e1(x1);
check;
tt.e1(x1);
check;
end;
begin
doit(null);
doit(i'access);
end Test_144;
The program prints "FAILED" not "PASSED".
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Versions of packages gnat depends on:
ii binutils2.15-5 The GNU assembler, linker and bina
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libc6-dev 2.3.2.ds1-20 GNU C Library: Development Librari
ii libgnat-3.15p-1 3.15p-12 The GNU Ada 95 compiler runtime li
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306833: gnat: Wrong code generated with -O -fPIC
Package: gnat
Version: 3.15p-12
Severity: normal
-- fails when compiled -O -fPIC on gnat 3.15p and gcc 4.0.0 20041212
with text_io; use text_io;
procedure Test_139 is
type T1 is range -128..127;
generic
package pak1 is
x1: T1 := 0;
end pak1;
package new_pak1 is new pak1; use new_pak1;
type T2 is record
x2: integer;
x3: integer;
x4: T1;
end record;
x5: T2 := (0,0,0);
x6: T1;
procedure proc1(x7 : out T1; x8 : T2) is
begin
x7 := x1;
end proc1;
begin
proc1(x6, x5);
x1 := 80;
x5.x4 := 100;
put_line(T1'image(x5.x4));
put_line(T1'image(x1));
case x5.x4 - (110 - x1) is
when 80..81 | 83 | 102 => null;
when 70 => put_line("PASSED");
when others => put_line("FAILED");
end case;
end Test_139;
The actual output is:
100
80
FAILED
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Versions of packages gnat depends on:
ii binutils2.15-5 The GNU assembler, linker and bina
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libc6-dev 2.3.2.ds1-20 GNU C Library: Development Librari
ii libgnat-3.15p-1 3.15p-12 The GNU Ada 95 compiler runtime li
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306832: gnat: Bug box, Assert_Failure at sinfo.adb:2365 on legal program
Package: gnat Version: 3.15p-12 Severity: normal -- gnat bug on legal program; from gcc bug 19002 package Test_138 is type T1 is record i: integer; end record; package pak1 is type T2 is tagged private; private type T2 is tagged null record; end pak1; generic package pak2 is function f(x: pak1.T2) return integer; function f(x: T1) return integer; j: integer := f((i => 2)); end pak2; package new_pak2 is new pak2; end Test_138; +===GNAT BUG DETECTED==+ | 3.15p (20020523) (i686-pc-linux-gnu) Storage_Error stack overflow (or erroneous memory access)| | Error detected at Test_138.ada:19:24 [Test_138.ada:22:4] | +===GNAT BUG DETECTED==+ | 4.0.0 20041212 (experimental) (i686-pc-linux-gnu) Assert_Failure sinfo.adb:2474| | Error detected at Test_138.ada:19:24 [Test_138.ada:22:4] | +===GNAT BUG DETECTED==+ | 3.15p (Debian 3.15p-13) (i486-pc-linux-gnu) Assert_Failure sinfo.adb:2365| | Error detected at test_138.ads:17:24 [test_138.ads:22:4] | -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages gnat depends on: ii binutils2.15-5 The GNU assembler, linker and bina ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libc6-dev 2.3.2.ds1-20 GNU C Library: Development Librari ii libgnat-3.15p-1 3.15p-12 The GNU Ada 95 compiler runtime li -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306835: gnat: Illegal program not detected, RM 3.6(11)
Package: gnat Version: 3.15p-12 Severity: normal procedure Test_146 is generic type T1 is private; package pak1 is type T2 is array(1..10) of aliased T1; end pak1; type T3 (b: Boolean := False) is null record; package new_pak1 is new pak1 (T1 => T3); --ERROR: T3 unconstrained begin null; end Test_146; Some output similar to the following is expected, but GNAT says nothing. test_146.adb:5:41: Type "T1" of aliased component must be constrained (RM 3.6(11)) test_146.adb:9:39: Actual type "T3" is unconstrained (RM 3.6(11)) gnatmake: "test_146.adb" compilation error -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages gnat depends on: ii binutils2.15-5 The GNU assembler, linker and bina ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libc6-dev 2.3.2.ds1-20 GNU C Library: Development Librari ii libgnat-3.15p-1 3.15p-12 The GNU Ada 95 compiler runtime li -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311394: wine: ignores font settings in ~/.wine/conf
Package: wine Version: 0.0.20050310-1.1 Severity: normal Wine reads various font files on the system, and always selects the first one as the default font (e.g. for menus). This can be seen on my system by starting "winemine". With WINEDEBUG=font, I get: ... trace:font:ReadFontDir Loading fonts from "/home/lbrenta/.wine/dosdevices/c:/windows/fonts" trace:font:load_fontconfig_fonts fontconfig: /usr/X11R6/lib/X11/fonts/Type1/n021023l.pfb trace:font:load_fontconfig_fonts fontconfig: /usr/share/fonts/truetype/dustin/dustismo_bold_italic.ttf trace:font:AddFontFileToList Loading font file "/usr/share/fonts/truetype/dustin/dustismo_bold_italic.ttf" index 0 trace:font:AddFontFileToList fsCsb = 2193 0400/a0af 104a trace:font:AddFontFileToList Added font L"Dustismo" L" Bold Italic" ... trace:font:AddFontFileToList Added font L"MgOpen Canonica" L"Bold Italic" trace:font:DumpFontList Family: L"Dustismo" trace:font:DumpFontList L" Bold Italic" trace:font:DumpFontList L"Regular" trace:font:DumpFontList L" Bold" trace:font:DumpFontList L" Italic" trace:font:DumpFontList Family: L"Bitstream Vera Serif" trace:font:DumpFontList L"Bold" trace:font:DumpFontList L"Roman" ... trace:font:WineEngCreateFontInstance L"System", h=16, it=0, weight=400, PandF=22, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance not in cache trace:font:WineEngCreateFontInstance Chosen: L"Dustismo" L"Regular" ... This illustrates that, on my system, the first TrueType font family happens to be "Dustismo". The problem is that, no matter what I put in ~/.wine/conf, this font is always selected. I have tried, for example: [fonts] "Default" = "-bitstream-vera-serif-" "Alias0" = "System,-bitstream-vera-sans-,subst" and the values in /usr/share/doc/wine/config. The settings are simply ignored. If I put a .ttf file in ~/.wine/drive_c/windows/fonts, that font is used instead, no matter what ~/.wine/conf says. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages wine depends on: ii debconf 1.4.30.13Debian configuration management sy ii libwine 0.0.20050310-1.1 Windows Emulator (Library) ii xbase-clients [xcontrib 4.3.0.dfsg.1-13 miscellaneous X clients -- debconf information: wine/del_wine_conf: true wine/install_type: Autodetect -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315416: gnat: Incorrect upper/lower case handling in Ada.Text_IO.Enumeration_IO
Jacob Sparre Andersen writes: > It appears that "Ada.Text_IO.Enumeration_IO" doesn't convert its > output correctly to lower case, when the enumeration contains > non-ISO-646 characters. Thank you for this report. Unfortunately, the non ISO-646 characters in your email got mangled along the way. Could you please send them as attachments, encoded in UTF-8? Additionally, it would be better to also describe the characters in question, as done in #312621. In your report, you mention GCC 3.2.2, which is not in Debian anymore. Does the bug really happen with gnat 3.15p? Have you also tested it with other versions? -- Ludovic Brenta. Registered Linux user #6891http://counter.li.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328614: lintian should not complain about read-only ada files
> Package: lintian
> Version: 1.23.12
>
> bad-permissions-for-ali-file
>
> AFAIK, these have to be read-only. CCing Ludovic.
Yes, they have to be read-only; see #226879 and #227162.
What is the problem? Why was this bug opened?
BTW, linda only checks in /usr/lib/adalib, I think it should check
in all directories, especially /usr/{gcc-,}lib/*/*/adalib.
--
Ludovic Brenta <[EMAIL PROTECTED]>
PS. Please disregard the stupid ad below, I can't remove it.
--
Scarlet Mobile - nous couvrons 98% de la population
Plus d'info sur http://www.scarlet.be/fr/consumer/mobile/
Bug#289566: Gnat...
"Alex Papadopoulos" writes: > Yes I do, is it related to that ? Yes. The directory /usr/lib/gcc-lib/i486-linux/2.8.1 is part of `gnat'. However, the compiler driver provided by the `gnat' package is gnatgcc, not gcc. gcc is provided by the package `gcc'. On my system I get this: $ gnatgcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/2.8.1/specs gcc version 2.8.1 $ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-5) There is something wrong with either one of these packages on your system. Or perhaps you have a symlink making gcc point to gnatgcc? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289566: Gnat...
Alex, I have no clue what is happening on your system. Nobody else than your friends appear to have that problem. One thing I'm sure of is that the package `gnat' is not at fault. If the problem is still there, could you please try this: $ which gcc $ `which gcc` -v $ /usr/bin/gcc-3.3 -v $ which gnatgcc $ `which gnatgcc` -v $ /usr/bin/gnatgcc -v $ alias The Makefiles used during compilation of linux appear to use some `gcc' command which is not /usr/bin/gcc-3.3 as it should. I'm trying to understand what exactly is happening. Also, you could try to compile linux with CC=/usr/bin/gcc-3.3. BTW, the symlink /usr/bin/gcc is provided by the package `gcc', which is a dependency package providing the default GCC compiler, currently gcc-3.3. You should not have to modify this symlink, or any other symlink under /usr/bin or /usr/lib. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#234551: ITP: libbooch_components -- The Ada 95 Booch Components
retitle 234551 RFP: libbooch_components -- The Ada 95 Booch Components thanks As I have already made 18 packages for Debian, I cannot commit time to the maintenance of more packages. Moreover, the package `libcharles' already provides a container library for Ada 95. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293652: gnat-gps: Missing library dependancy
Yes, gnat-gps_2.1.0 is not in sid yet. It's on the way, though. Matthias, the binary packages are at the usual place. -- Ludovic Brenta. deb http://www.ada-france.org/debian ada main deb-src http://www.ada-france.org/debian ada main -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294388: gnat-gps: GPS is not installable, because of broken dependencies :
reassign 294388 libgtkada2-0 tags 294388 sid merge 293652 294388 thanks Nicolas Bouillon writes: > The following packages have unmet dependencies: > gnat-gps: Depends: libgtkada-2.4 (>= 2.4.0) but it is not installable > E: Broken packages libgtkada-2.4 is in the queue of new packages; it should go into sid in the next few days. The reason for the delay is that the sonames of the shared libraries changed, and consequently the binary package names must also change. > Please let me know if there is a workaround. > The package libgtkada2-0 version 2.4.0-1 is installed. There are two workarounds: * use testing * temporarily add the following to your /etc/apt/sources.list: deb http://www.ada-france.org/debian ada main deb-src http://www.ada-france.org/debian ada main and use pinning to prefer packages from "ada" over "sid". The above is the staging area where I upload new packages before they are accepted into sid. Thank you for reporting this bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297980: gnat-gps: causes the X server to crash when compiling
Package: gnat-gps Version: 2.1.0-3 Severity: critical Tags: help Any attempt to compile a program using F4 or Build causes the X server to crash. I thought I solved this problem last month, but it just popped up again :( The problem was caused by one of the GNAT.Expect.Expect procedures, used when launching the underlying compiler. The package GNAT.Expect is part of GNAT, not GPS, but GPS contains a modified copy of it. The original (GNAT 3.15p) caused the crash, and the copy from GPS didn't. Now, the crash occurs even with the copy that came with GPS (I verified that it is indeed compiled into the gnat-gps executable). I need to investigate further. gnat-gps 2.1.0-2 did not have the problem. The only difference between it and -3 is a recompile (see the changelog). I am confused. Note also that, by my book, any crash of the X server is a bug in the X server. I will file another bug report against xserver-xfree86. I appreciate any help in investigating this problem. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages gnat-gps depends on: ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libglib2.0-02.6.1-3 The GLib library of C routines ii libgnat-3.15p-1 3.15p-12 The GNU Ada 95 compiler runtime li ii libgtk2.0-0 2.4.14-2 The GTK+ graphical user interface ii libgtkada-2.4 2.4.0-3 Ada binding for the GTK library ii libpango1.0-0 1.6.0-3 Layout and rendering of internatio ii python2.3 2.3.4-19 An interactive high-level object-o -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297985: xserver-xfree86: X server crashes when compiling a program from gnat-gps
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-10 Severity: critical Tags: help Any attempt to compile a program from within gnat-gps (an IDE) using F4 or the Build menu causes the X server to crash. By my book, any crash of the X server is a bug in the X server; this bug captures this. Another bug filed against gnat-gps captures the fact that gnat-gps should not trigger this problem. I thought I solved this problem in gnat-gps last month, but it just popped up again :( The problem was caused by one of the GNAT.Expect.Expect procedures, used when launching the underlying compiler. The package GNAT.Expect is part of GNAT, not GPS, but GPS contains a modified copy of it. The original (GNAT 3.15p) caused the crash, and the copy from GPS didn't. Now, the crash occurs even with the copy that came with GPS (I verified that it is indeed compiled into the gnat-gps executable). I need to investigate further. gnat-gps 2.1.0-2 did not have the problem. The only difference between it and -3 is a recompile (see the changelog). I am confused. I would appreciate any possible help in solving this problem. To reproduce it: $ apt-get install gnat-gps gnat-gps-doc $ cp -R /usr/share/doc/gnat-gps-doc/examples/tutorial $HOME Now launch GPS from the Debian menu | Programs | Apps | Programming | GNAT Programming System. After the splash screen, the "Welcome to GPS 2.1.0 (20041129)" dialog box opens. Tick "Open existing project"; navigate to $HOME/tutorial/sdc.gpr. Click OK. The IDE pops up. Press F4, or click the Build | Make | sdc.gpr menu item. The X server crashes. -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 20 2004-03-12 01:50 /etc/X11/X -> /usr/bin/X11/XFree86 -rwxr-xr-x 1 root root 1745740 2004-12-15 20:19 /usr/bin/X11/XFree86 Contents of /var/lib/xfree86/XF86Config-4.roster: xserver-xfree86 VGA-compatible devices on PCI bus: :01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 13) /etc/X11/XF86Config-4 does not match checksum in /var/lib/xfree86/XF86Config-4.md5sum. XFree86 X server configuration file status: -rw-r--r-- 1 root root 3006 2004-07-02 20:29 /etc/X11/XF86Config-4 Contents of /etc/X11/XF86Config-4: # XF86Config-4 (XFree86 X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 > /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section "Files" FontPath"unix/:7101"# local font server FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/CID" FontPath"/usr/lib/X11/fonts/Speedo" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"speedo" Load"type1" Load"vbe" Load"xtt" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "be" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/psaux" Option "Protocol" "PS/2" EndSection Section "InputDevice" Identifier "Generic Mouse" Driver "mouse" Option "SendCoreEvents""true" Option "Device""/dev/input/mice" Option
Bug#297985: Acknowledgement (xserver-xfree86: X server crashes when compiling a program from gnat-gps)
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297980 for the bug filed against gnat-gps. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297980: gnat-gps: causes the X server to crash when compiling
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297985 filed against xserver-xfree86. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297985: xserver-xfree86: X server crashes when compiling a program from gnat-gps
(CC'ing Helge Lenz the original reporter) I have been able to create a core file with the debugging version of the X server by using kill -SEGV, as Branden Robinson described. Then I tried to reproduce the problem with gnat-gps, and no core file is created. The X server exits as though gnat-gps were sending a Ctrl+Alt+Backspace to it. This then sends a SIGPIPE to gnat-gps, which crashes. Is it possible for a client program to cause the X server to shut down? If so, what kind of X request should I look for in gnat-gps? Here is additional information on how to debug gnat-gps. Switch to a text console (e.g. VT1), login as yourself, and do: $ apt-get install gnat-gdb $ apt-get source gnat-gps $ cd gnat-gps-2.1.0 $ dpkg-buildpackage -rfakeroot (takes ~1h on my Pentium III 900 MHz) $ cd glide/obj $ gnatgdb gnat-gps (gdb) set env DISPLAY=:0 (gdb) break commands-builder.adb:207 (gdb) run Swith to the X console (VT7 by default). After loading sdc.gpr, press F4. Switch back to VT1 where GDB is running, and take it from there. At one point, the X server exits but gnat-gps keeps on running in GDB. In my previous experience, this happens while gnat-gps is in one of the GNAT.Expect.Expect procedures. Later on, gnat-gps receives SIGPIPE because the X server is down. Also, it is possible to attach GDB to the X server itself. In a text console, login as root and: # ps -u root | grep XFree86-debug (look at the PID of the X server) # gdb /usr/bin/XFree86-debug (gdb) attach I have not yet had time to go further than this. I would need to install the sources to the X server, possibly rebuild it, and try to find the exit point, i.e. what was XFree86 thinking when it shut down? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355154: libgnat-3.4: insatisfiable depends in unstable
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: > On Fri, Mar 03, 2006 at 06:57:38PM +0100, Ludovic Brenta wrote: >> GNAT is no longer being built from gcc-3.4. No package depends on >> libgnat-3.4. > > Sorry, that's wrong: > > Reverse Depends: > music123,libgnat-3.4 3.4.4 I believe this can be fixed quite easily. Open a bug against music123 to ask the maintainer to use the default Ada compiler. This package violates the Debian Policy for Ada :) > gnat-3.4,libgnat-3.4 3.4.5-2 > gnat-3.4,libgnat-3.4 3.4.1-3 These don't count. > ghdl,libgnat-3.4 3.4.1-3 ghdl is a VHDL front-end to GCC, and so depends on a particular version of the GCC back-end. Since it is written in Ada, it requires the Ada run-time. Strangely, upstream's latest version, 0.21, uses GCC 4.0.2 as its back-end, and 0.21 is in unstable. How come it still requires libgnat-3.4 in Debian? Sounds like a case for another bug. Matthias, what do you suggest? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355154: libgnat-3.4: insatisfiable depends in unstable
Matthias Klose <[EMAIL PROTECTED]> writes: > Ludovic Brenta writes: >> ghdl is a VHDL front-end to GCC, and so depends on a particular >> version of the GCC back-end. Since it is written in Ada, it requires >> the Ada run-time. Strangely, upstream's latest version, 0.21, uses >> GCC 4.0.2 as its back-end, and 0.21 is in unstable. How come it still >> requires libgnat-3.4 in Debian? Sounds like a case for another bug. >> >> Matthias, what do you suggest? > > yes, and maybe point out, that you'll go for gnat-4.1 as the gnat > compiler in etch. I just had time to check that the version currently in unstable build-depends on gnat-4.0, not gnat-3.4, which is fine for the time being. Steinar, are you sure your installed ghdl is the latest version? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375242: dpkg: install-info unable to determine description for `dir' entries
Nicolas François <[EMAIL PROTECTED]> writes: > It is not a typo. Yes it is, because after I changed $' to $2 (applying the patch I provided), install-info worked just fine. > Can you provide the info file that generated the original error? It is quite long, so I'll include only the first node. -- Ludovic Brenta. This is adacontrol_pm.info, produced by makeinfo version 4.7 from adacontrol_pm.texi. INFO-DIR-SECTION GNU Ada tools START-INFO-DIR-ENTRY * AdaControl Programmer Manual: (adacontrol_pm). END-INFO-DIR-ENTRY This manual documents version 1.4 of AdaControl. File: adacontrol_pm.info, Node: Top, Next: General, Prev: (dir), Up: (dir) AdaControl Programmer Manual Last edited: 4 October 2005 This is the AdaControl Programmer Manual. It is intended for those who want to add new rules to AdaControl. Reading this manual is not necessary to use AdaControl. On the other hand, it is assumed that the reader knows how to use AdaControl before thinking of adding new rules. * Menu: * General:: * The framework and utilities packages:: * Writing a new rule:: * Plugging-in a new rule into the framework:: * Testing and debugging a rule:: Commercial support is available for AdaControl. If you plan to use AdaControl for industrial projects, or if you want it to be customized or extended to match your own needs, please contact Adalog at [EMAIL PROTECTED] AdaControl is Copyright (C) 2005 Eurocontrol/Adalog. AdaControl is free software; you can redistribute it and/or modify it under terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This unit is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License distributed with this program; see file COPYING. If not, write to the Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. As a special exception, if other files instantiate generics from this program, or if you link units from this program with other files to produce an executable, this does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License. This document is Copyright (C) 2005 Eurocontrol/Adalog. This document may be copied, in whole or in part, in any form or by any means, as is or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy.
Bug#375242: dpkg: install-info unable to determine description for `dir' entries
Nicolas François <[EMAIL PROTECTED]> writes: > install-info (at least dpkg's install-info) expects a description after > * AdaControl Programmer Manual: (adacontrol_pm). > > Something like: > * AdaControl Programmer Manual: (adacontrol_pm). Programmer Manual for > AdaControl > > > You can either modify the .info file, or specify the description with > --description="Programmer Manual for AdaControl" when you call install-info. > > Do you agree on closing this bug? OK, I didn't know the description was mandatory. I'll add one to the info file; it is okay to close the bug, but I think it would be nice to make the error message more explicit. Thanks for your attention. -- Ludovic Brenta.
Bug#200003: Any progress?
Matthias Klose <[EMAIL PROTECTED]> writes: > The second thing is to remove the gfdl'd texi files from the sources, > so that the package still builds. The idea is to replace these files > with dummy content, such that the build still succeds and the Makefile > don't have to be patched. Unless I am mistaken, there was a Debian General Resolution lately that allows GFDL'd documents in main, provided they have no front-cover text, no back-cover text and no invariants. I am concerned that wholesale deletion of all documentation from the GCC package is a disservice to users. Should we not rather assess each document individually and remove only those that fail the General Resolution criteria? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401385: This might not be as easy as I thought...
Hi Kevin, Thanks for taking all that trouble. The debugging information should not go into the package libgnat-4.1, because that's a run-time-only package not intended for developers. Instead, the debugging information should go either to a new package (libgnat-4.1-dbg), either into package gnat-4.1, which already contains the static library with debugging information as well as the compiler. Creating a new package is a better long-term solution, because sooner or later we'll want to switch to multilib. In a multilib system, we do not want to have both libraries and programs in the same package. Are you comfortable editing debian/control.m4 and debian/rules.d/binary-ada.mk to add the new package? Then send me a patch? If you do that then I'll review and apply your patch into the next upload. PS. Make sure libgnat-4.1-dbg depends on libgnat-4.1, and recommends gnat-gdb (>= 6.4). Also, gnat-4.1 should recommend libgnat-4.1-dbg but not depend on it. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401385: This might not be as easy as I thought...
Kevin Brown writes: > That may be true, but developers aren't the only ones who might make > use of these files. Anyone who gets a crash in an Ada application > could get a much better traceback (for filing a bug report) with > these files in place than without. > > Independent of the potential issues described below, we should give > some serious thought to including the debugging files with the runtime > package. > > It does bloat the package a bit, though. The overriding reason is multilib. We will make a separate -dbg package, and we will probably even move the static library to another package, too. Better do it right the first time. [...] > But given that the control file is generated from an m4 master, > changing binary-ada.mk in the required way may be a problem. The > argument to dh_strip will be --dbg-package, and it takes the name of > the target package as its argument. That's a problem because the > package names are generated from the m4 master. [...] The only part of the package name that will change across versions is the version number, and there is a macro in the Makefiles for that: $(GNAT_VERSION). All package names in binary-ada.mk are derived from that macro, and we pass its value to m4 so it generates control from control.m4. So, no problem. See the top 15 lines of binary-ada.mk of you're not convinced. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
Sven Luther writes: > Euh, it seems to me more that the hardware has a bug which causes > normal operation to damage it. > > As thus, i think that any damage done would be under the > responsability of the manufacturer to repare or fix. This seems to > be both the position of Bastian and Maximilian, and it seems > reasonable. > > So, users of such hardware, please bother your vendor to either > exchange it for a not broken one, or at least provide a bios upgrade > which fixes the brokeness. No, the problem is not in the BIOS, it is in the kernel and it is described at length in the upstream bug report. If I understand this description correctly, the kernel is not compliant with the ACPI specification in that it handles all ACPI events in a single thread, whereas the ACPI spec only says that the *interpreter* must be single-threaded. Also, there is a deadlock situation in the kernel which is clearly a kernel, not BIOS, bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
forward 400488 http://bugzilla.kernel.org/show_bug.cgi?id=7122 forward 404143 http://bugzilla.kernel.org/show_bug.cgi?id=5534 thanks When I said there's a memory leak, that's not technically true. What happens is that ACPI events get piled up in a queue and never processed, due to a deadlock in Linux' ACPI subsystem. Thus the memory is not exactly "lost" but the net effect is the same as for a genuine memory leak. Now here is some additional information; my hourly cron job has monitored the slab allocation for some more time and the bug appears even more severe than I first thought. Notice how the slab allocation jumped from 64M to 1G between 6:17 and 7:17? The only thing happening at that time in the system was the execution of the daily crontabs at 6:47. These are the stock (unmodified) Debian crontabs for apt, aptitude, apt-show-versions, bsdmainutils, dlocate, find, logrotate, man-db, modutils, prelink, standard, sysklogd, tetex-bin, zz-backup2l. 2006-06-21T20:06:10: Slab:30296 kB 2006-17-21T20:17:01: Slab:37756 kB 2006-17-21T21:17:01: Slab:48116 kB 2006-17-21T22:17:01: Slab:55764 kB 2006-17-21T23:17:01: Slab:69904 kB -- Reboot with acpi=noirq: only one CPU found -- 2006-24-21T23:24:10: Slab:10444 kB -- Reboot with pci=noacpi: only one CPU found -- 2006-30-21T23:30:26: Slab: 9676 kB 2006-30-21T23:30:26: Acpi-State 0 0 80 481 : tunables 120 608 : slabdata 0 0 0 -- Reboot with no options: OK, both CPUs found -- 2006-34-21T23:34:23: Slab:10584 kB 2006-34-21T23:34:23: Acpi-State 0 0 80 481 : tunables 120 608 : slabdata 0 0 0 2006-17-22T00:17:01: Slab:15424 kB 2006-17-22T00:17:01: Acpi-State 23088 23088 80 481 : tunables 120 608 : slabdata481481 0 2006-17-22T01:17:01: Slab:29956 kB 2006-17-22T01:17:01: Acpi-State 59136 59136 80 481 : tunables 120 608 : slabdata 1232 1232 0 2006-17-22T02:17:01: Slab:37764 kB 2006-17-22T02:17:01: Acpi-State 95088 95088 80 481 : tunables 120 608 : slabdata 1981 1981 0 2006-17-22T03:17:01: Slab:45544 kB 2006-17-22T03:17:01: Acpi-State130992 130992 80 481 : tunables 120 608 : slabdata 2729 2729 0 2006-17-22T04:17:01: Slab:53328 kB 2006-17-22T04:17:01: Acpi-State166944 166944 80 481 : tunables 120 608 : slabdata 3478 3478 0 2006-17-22T05:17:01: Slab:61120 kB 2006-17-22T05:17:01: Acpi-State202896 202896 80 481 : tunables 120 608 : slabdata 4227 4227 0 2006-17-22T06:17:01: Slab:68904 kB 2006-17-22T06:17:01: Acpi-State238800 238800 80 481 : tunables 120 608 : slabdata 4975 4975 0 2006-17-22T07:17:01: Slab: 1152624 kB 2006-17-22T07:17:01: Acpi-State274656 274656 80 481 : tunables 120 608 : slabdata 5722 5722 0 2006-17-22T08:17:01: Slab: 1160376 kB 2006-17-22T08:17:01: Acpi-State310608 310608 80 481 : tunables 120 608 : slabdata 6471 6471 0 2006-17-22T09:17:01: Slab: 1168168 kB 2006-17-22T09:17:01: Acpi-State346464 346464 80 481 : tunables 120 608 : slabdata 7218 7218 0 2006-17-22T10:17:01: Slab: 1175892 kB 2006-17-22T10:17:01: Acpi-State382176 382176 80 481 : tunables 120 608 : slabdata 7962 7962 0 2006-17-22T11:17:01: Slab: 1183660 kB 2006-17-22T11:17:01: Acpi-State417984 417984 80 481 : tunables 120 608 : slabdata 8708 8708 0 2006-17-22T12:17:01: Slab: 1191400 kB 2006-17-22T12:17:01: Acpi-State453744 453744 80 481 : tunables 120 608 : slabdata 9453 9453 0 2006-17-22T13:17:01: Slab: 1202924 kB 2006-17-22T13:17:01: Acpi-State489696 489696 80 481 : tunables 120 608 : slabdata 10202 10202 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
Some more information. 1) On my machine, reading the temperature using, say, yacpi, causes one processor to process all the pending ACPI events. On a uniprocessor machine, the machine would appear to hang for several seconds; not so on my dual-core machine :) 2) The lare slab usage (1.1 Gb) was in part due to the XFS cache data; all three of my machine's filesystems are XFS. So the Acpi-State line in /proc/slabinfo is the really meaningful one. Here is my complete log so far, with annotations. 2006-06-21T20:06:10: Slab:30296 kB 2006-17-21T20:17:01: Slab:37756 kB 2006-17-21T21:17:01: Slab:48116 kB 2006-17-21T22:17:01: Slab:55764 kB 2006-17-21T23:17:01: Slab:69904 kB -- Reboot with acpi=noirq: only one CPU found -- 2006-24-21T23:24:10: Slab:10444 kB -- Reboot with pci=noacpi: only one CPU found -- 2006-30-21T23:30:26: Slab: 9676 kB 2006-30-21T23:30:26: Acpi-State 0 0 80 481 : tunables 120 608 : slabdata 0 0 0 -- Reboot with no options: OK, both CPUs found -- 2006-34-21T23:34:23: Slab:10584 kB 2006-34-21T23:34:23: Acpi-State 0 0 80 481 : tunables 120 608 : slabdata 0 0 0 2006-17-22T00:17:01: Slab:15424 kB 2006-17-22T00:17:01: Acpi-State 23088 23088 80 481 : tunables 120 608 : slabdata481481 0 2006-17-22T01:17:01: Slab:29956 kB 2006-17-22T01:17:01: Acpi-State 59136 59136 80 481 : tunables 120 608 : slabdata 1232 1232 0 2006-17-22T02:17:01: Slab:37764 kB 2006-17-22T02:17:01: Acpi-State 95088 95088 80 481 : tunables 120 608 : slabdata 1981 1981 0 2006-17-22T03:17:01: Slab:45544 kB 2006-17-22T03:17:01: Acpi-State130992 130992 80 481 : tunables 120 608 : slabdata 2729 2729 0 2006-17-22T04:17:01: Slab:53328 kB 2006-17-22T04:17:01: Acpi-State166944 166944 80 481 : tunables 120 608 : slabdata 3478 3478 0 2006-17-22T05:17:01: Slab:61120 kB 2006-17-22T05:17:01: Acpi-State202896 202896 80 481 : tunables 120 608 : slabdata 4227 4227 0 2006-17-22T06:17:01: Slab:68904 kB 2006-17-22T06:17:01: Acpi-State238800 238800 80 481 : tunables 120 608 : slabdata 4975 4975 0 2006-17-22T07:17:01: Slab: 1152624 kB 2006-17-22T07:17:01: Acpi-State274656 274656 80 481 : tunables 120 608 : slabdata 5722 5722 0 2006-17-22T08:17:01: Slab: 1160376 kB 2006-17-22T08:17:01: Acpi-State310608 310608 80 481 : tunables 120 608 : slabdata 6471 6471 0 2006-17-22T09:17:01: Slab: 1168168 kB 2006-17-22T09:17:01: Acpi-State346464 346464 80 481 : tunables 120 608 : slabdata 7218 7218 0 2006-17-22T10:17:01: Slab: 1175892 kB 2006-17-22T10:17:01: Acpi-State382176 382176 80 481 : tunables 120 608 : slabdata 7962 7962 0 2006-17-22T11:17:01: Slab: 1183660 kB 2006-17-22T11:17:01: Acpi-State417984 417984 80 481 : tunables 120 608 : slabdata 8708 8708 0 2006-17-22T12:17:01: Slab: 1191400 kB 2006-17-22T12:17:01: Acpi-State453744 453744 80 481 : tunables 120 608 : slabdata 9453 9453 0 2006-17-22T13:17:01: Slab: 1202924 kB 2006-17-22T13:17:01: Acpi-State489696 489696 80 481 : tunables 120 608 : slabdata 10202 10202 0 -- Start yacpi, monitoring the temperature every second. -- Note how the slab allocation drops by ~100M and then stays constant. 2006-17-22T14:17:01: Slab: 1097584 kB 2006-17-22T14:17:01: Acpi-State 109144 80 481 : tunables 120 608 : slabdata 3 3 0 2006-17-22T15:17:01: Slab: 1097532 kB 2006-17-22T15:17:01: Acpi-State45 96 80 481 : tunables 120 608 : slabdata 2 2 0 2006-17-22T16:17:01: Slab: 1097536 kB 2006-17-22T16:17:01: Acpi-State75144 80 481 : tunables 120 608 : slabdata 3 3 0 2006-17-22T17:17:01: Slab: 1097668 kB 2006-17-22T17:17:01: Acpi-State 141144 80 481 : tunables 120 608 : slabdata 3 3 0 -- Stop the yacpi monitoring. 2006-17-22T18:17:01: Slab: 1098904 kB 2006-17-22T18:17:01: Acpi-State 5808 5808 80 481 : tunables 120 608 : slabdata121121 0 -- At this point the Acpi-State has started increasing again, but is still -- small. Most of the slab allocations are in the XFS caches (all three -- filesystems on this computer are XFS). -- T
Bug#405874: gnat-glade-doc's version doesn't match gnat-glade
severity 405874 wishlist thanks Steve Langasek writes: > The question is whether the documentation is sufficiently > out-of-sync that it's better to let the user consult on-line docs > from upstream than to present them with inaccurate docs in Debian. > I don't know of any reason why this is the case here, but I don't > use gnat at all; Matthias is listed as an uploader, so presumably he > has a better idea than I do, so I'll defer to his judgement on > whether this is RC. I'm the maintainer and have assessed the changes in the documentation; there are minor editorial changes and a few additions, but nothing ground-breaking and certainly no risk of loss of life or data, or breach of confidentiality. Downgrading to wishlist. PS. The new version, not yet packaged, has > with the Invariant Sections being ``GNU Free Documentation License'', with the > Front-Cover Texts being > ``GLADE User's Guide / GNAT Library for Ada Distributed Environment'', > and with no Back-Cover Texts. Does that really qualify as non-free? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407417: Confusing versioning of libstdc++6[-...]
Package: gcc-3.4
Version: 3.4.6-5
Severity: important
Stephan Krempel writes:
> Dear Debian GCC Maintainers,
>
> first I want to wish you a happy new year and thank you for your work.
>
> This time I am a bit confused about some of the package names and
> versions.
>
> libstdc++6 is from source gcc-4.1, but libstdc++6-dbg, -dev, -doc,
> -pic are still from gcc-3.4. As a simple user I would expect that
> installing libstdc++6[-...] give me everything in matching versions.
>
> Is there any reason why libstdc++6[-...] are not only dependency
> packages depending on the respective package with the default
> compiler ABI, at the moment libstdc++6-4.1[-...]?
>
> As long as we are in unstable this wouldn't be of high interest, but
> in the upcomming stable release some users could become very
> confused.
>
> I hope this is not an already discussed issue, couldn't find an old
> thread about it.
Indeed, this is confusing.
The gcc-3.4 source package builds libstdc++6-{dbg,dev,pic} which
depend on libstdc++6 (>= 3.4.6-5).
The gcc-4.1 source package builds libstdc++6-4.1-{dbg,dev,pic} which
depend on libstdc++6 (>= 4.1.1-19).
The current version of libstdc++6 satisfies both dependencies, and
this is proably wrong.
Stephan, the workaround for now is to install
libstdc++6-4.1-{dbg,dev,pic}, and remove libstdc++6-{dbg,dev,pic}.
Proposed solution 1:
1) Do not build libstdc++6-{dbg,dev,pic} from gcc-3.4 anymore.
2) In gcc-4.1, change libstdc++6-4.1-{dbg,dev,pic} to
libstdc++6-{dbg,dev,pic}, with Conflicts and Replaces.
Proposed solution 2:
1) In gcc-4.1, change libstdc++6-4.1-{dbg,dev,pic} to Conflict with
and Replace libstdc++6-{dbg,dev,pic}.
Proposed solution 3:
1) Do not build libstdc++6-{dbg,dev,pic} from gcc-3.4 anymore.
2) In gcc-defaults, build libstdc++6-{dbg,dev,pic} that, in etch,
depend on libstdc++6-4.1-{dbg,dev,pic}.
I personally vote against solution 2, since we don't build g++-3.4
anymore and so the libstdc++6-{dbg,dev,pic} from gcc-3.4 are useless
anyway. I think solution 3 is the best if we want to support multiple
versions of g++.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407417: Confusing versioning of libstdc++6[-...]
Actually, the only package that has file conflicts is libstdc++6-dbg; it conflicts with both libstdc++5-3.3-dbg and libstdc++6-4.1-dbg; in addition it will conflict in the future with libstdc++6-4.2-dbg. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407417: Confusing versioning of libstdc++6[-...]
severity 407417 serious
justification: file clashes without Conflicts between packages
thanks
Matthias Klose writes:
> Ludovic Brenta writes:
>> Proposed solution 3:
>> 1) Do not build libstdc++6-{dbg,dev,pic} from gcc-3.4 anymore.
>
> why?
Because we do not build libstdc++6 from gcc-3.4 anymore.
>> 2) In gcc-defaults, build libstdc++6-{dbg,dev,pic} that, in etch,
>>depend on libstdc++6-4.1-{dbg,dev,pic}.
>
> maybe, but not anymore for etch. For a cosmetic change it's not worth
> touching three source packages.
Actually, just two (gcc-3.4 and gcc-defaults), but I'm nit-picking.
More importantly, I disagree that it is a "cosmetic change":
- the libstdc++6-{dbg,dev,pic} packages in the archive are unusable
because there is no matching libstdc++6; normally this would qualify
as a "grave functionality" bug.
- the libstdc++6-{dbg,dev,pic} contain files clashing with
libstdc++6-4.1-{dbg,dev,pic} but do not Conflict with them; see [1].
I believe that that alone qualifies as a "serious policy violation"
bug.
- The same file clashes apply to libstdc++5-3.3-{dbg,dev,pic}, too.
[1]
http://packages.debian.org/cgi-bin/search_contents.pl?version=testing&arch=amd64&case=insensitive&word=libstdc%2B%2B6-dbg&searchmode=filelist
>> I personally vote against solution 2, since we don't build g++-3.4
>> anymore and so the libstdc++6-{dbg,dev,pic} from gcc-3.4 are useless
>> anyway.
>
> huh, we don't build g++-3.4 anymore? thats news.
Sorry, that was a thinko; I meant libstdc++6.
> g++-3.4 will go away in lenny. I don't see the need to introduce
> defaults packages in gcc-defaults.
OK, that's an option too; I suggest we just drop
libstdc++6-{dbg,dev,pic} from gcc-3.4, and modify gcc-4.1 so that its
packages Conflict with the ones from gcc-3.3. I'm willing to do that
myself, in the etch branch.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366744: GNAT is not mentioned in its copyright file
Please replace the previous patch with this patch against 4.1.0-4. More explanation may be needed for Pascal. [Ludovic Brenta] * debian/copyright: Mention Ada packages (Closes: #366744). Reorganise the explanation on the various packages. Explain biarch. List all binary packages built from the sources. Remove duplicate licensing terms for libmudflap. --- copyright b7226bc76a8c19f917b7bb22600488058df7dfae +++ copyright 2e4dcbdb7ff6953764b53f01c051c0ab1dfd55a8 @@ -1,48 +1,105 @@ -This is the Debian GNU/Linux prepackaged version of the GCC compiler -collection, containing C, C++, Objective-C, Objective-C++, Fortran-95, -Java, and Pascal compilers, and the libstdc++ support library. +-*- mode: Text; fill-column: 75 -*- -The compilers are split into several binary packages: gcc (which has -support for C), g++ (which supports C++), gobjc (which supports -Objective C), gobjc++ (which support Obj-C++), gfortran (which supports -Fortran95), gij, gcj (supports Java), and gpc (supports Pascal). -A version of libstdc++-v3 is also provided. +This is the Debian GNU/Linux prepackaged version of the GNU compiler +collection, containing Ada, C, C++, Fortran 95, Java, Objective-C, +Objective-C++, and Treelang compilers, documentation, and support +libraries. In addition, Debian provides the GNU Pascal compiler in the +same source package. Packaging is done by the Debian GCC Maintainers +, with sources obtained from: -Documentation is provided in the packages cpp-4.1-doc, gcc-4.1-doc, -gcj-4.1-doc, gfortran-4.1-doc and gpc-2.1-4.1-doc. + ftp://gcc.gnu.org/pub/gcc/releases/ (for full releases) + svn://gcc.gnu.org/svn/gcc/ (for prereleases) + http://gnu-pascal.de/alpha/ (for GNU Pascal) -This package was put together by the Debian GCC Maintainers -, with sources obtained from: +Changes: See changelog.Debian.gz - [NOTE: the current prereleases obtained from the CVS archive] - ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.1.0.tar.bz2 +Debian splits the GNU Compiler Collection into packages for each language, +library, and documentation as follows: - http://gnu-pascal.de/alpha/ +Language Compiler package Library packageDocumentation +--- +Adagnat-4.1 libgnat-4.1gnat-4.1-doc +C gcc-4.1 gcc-4.1-doc +C++g++-4.1 libstdc++6 libstdc++6-4.1-doc +Fortran 95 gfortran-4.1 libgfortran1 gfortran-4.1-doc +Java gcj-4.1 libgcj7libgcj-doc +Objective Cgobjc-4.1 libobjc1 +Objective C++ gobjc++-4.1 +Pascal gpc-4.1 +Treelang treelang-4.1 -Changes: See changelog.Debian.gz +For some language run-time libraries, Debian provides source files, +development files, debugging symbols and libraries containing position- +independent code in separate packages: -GCC is Copyright (C) 1986, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1994, -1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 -Free Software Foundation, Inc. +Language Sources Development Debugging Position-Independent +--- +C++libstdc++6-4.1-dbg libstdc++6-4.1-pic +Java libgcj7-src libgcj7-dev libgcj7-dbg -This program is free software; you can redistribute it and/or modify it -under the terms of the GNU General Public License as published by the -Free Software Foundation; either version 2, or (at your option) any -later version. +Additional packages include: -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. +All languages: +libgcc1, libgcc2, libgcc4 GCC intrinsics (platform-dependent) +libffi4-dev, libffi4Foreign Function Interface library +gcc-4.1-baseBase files common to all compilers +gcc-4.1-soft-float Software floating point (ARM only) +gcc-4.1-source The sources with patches -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. +Ada: +libgnatvsn-dev, libgnatvsn4.1 GNAT version library +libgnatprj-dev, libgnatprj4.1 GNAT Project Manager library -On Debian GNU/Linux systems, the complete text of the GNU General -Public License can be found in `/usr/share/common-licenses/GPL'. +C: +cpp-4.1, cpp-4.1-docGNU C Preprocessor +libmudflap0-dev, libmudflap0Library for instrumenting pointers +libssp0-dev, libssp0GCC stack smashing protection library +fixinc
Bug#405467: linux-image-2.6.18-3-amd64: uses 100% CPU time handling hardware interrupts from parallel port
> you'd anyway newer kernels for this box and even not applied > upstream ones, so i'd appreciate if you understand that 2.6.18 is > not a good cut off for HP NX. I understand all that, but I also understand that bug reports in a public database are good, because they document issues and help other people find the workaround. In fact, I always encourage users of my own packages to file bug reports, whether or not I can or will fix them. So, please do not assume that I'm bitching and moaning about your package; I am merely documenting an issue and its workaround. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405467: linux-image-2.6.18-3-amd64: uses 100% CPU time handling hardware interrupts from parallel port
maximilian attems <[EMAIL PROTECTED]> writes: > this is pretty useless in this case, > if you want to do something usefull grab 2.6.20-rc3 from upstream > and file bugzilla.kernel.org bugs for the open ones. > afaik acpi is still not settled, may be othere ones too. I am not a Linux kernel developer; I am a Debian developer. The purpose of this bug report is to document an issue (and its workaround) in Debian Etch. Even if the bug is fixed upstream, it is still present in Debian Etch at this time, and will affect other people for as long as the buggy kernel is in Debian Etch. > linux-2.6 meta packet has way to many bogus or valid reports that a > user would look at it, so i highly question this documentation. As can be seen from the subject line, I did not file this bug report against linux-2.6; I filed it against linux-image-2.6.18-3-amd64. There are, currently, 6 bugs on that package, none of which seem bogus to me. > modprobe blacklisting is not like black magic and not worth to > "document". Yes, it is worth documenting because not everyone is a kernel developer - or a developer at all. The most valuable item in this bug report is that it establishes a link between *symptoms* (subject line), *cause*, and *workaround*. None of these are black magic, but linking them together is valuable. You are a volunteer just like me. You strive to make Debian Etch as perfect as possible, just like I do. Nobody forces you to read bug reports; but if you do, please refrain from off-topic (i.e. non-technical) discussions in bug reports. I will comment no more on this issue. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401385: libgnat-4.1: libgnat needs a shared debugging version, to be placed in /usr/lib/debug
Kevin Brown writes: > OK, I've finished working on this and the end result appears to work > properly. It creates -dbg packages for libgnat, libgnatprj, and > libgnatvsn. See the attached patch. Hi Kevin, Thank you so much for the patch. I have reviewed it after returning from vacation and it seems fine, at least at first glance. I will apply the patch when I get around to working on GCC again. I'll do that after Etch is released; now everything is frozen anyway. > By the way, my initial attempt at this didn't work because it turns > out that we're using debhelper compatibility level 4, which changes > the semantics of the --dbg-package option rather significantly. So > if we move to compatibility level 5 or greater, we'll need to > slightly modify the --dbg-package argument to each dh_strip command > that makes use of it. Right; I was aware that we used level 4, but not of the changes that implied. Thanks for investigating and warning us ahead of the transition to level 5. > Is there anything else I need to do for this bug? No; just wait until I've applied the patch and Matthias decides to upload (gnat uploads are coordinated with gcc and gcj). BTW, would you consider joining Debian as a maintainer? I'm looking for co-maintainers for Ada packages. Be warned that the process of becoming a full Debian developer is a multi-year one :/ but you can contribute without being a DD, as you just proved. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405467: linux-image-2.6.18-3-amd64: uses 100% CPU time handling hardware interrupts from parallel port
I like the idea, and in addition I think the page should have a link in http://www.linux-laptop.net/ -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402505: libgtkada2-bin: gtkada2-config gives wrong -aO option
tags 402505 confirmed patch severity 402505 minor thanks Workaround: use the project files. The presence of the workaround makes this bug minor instead of important. PS. As Etch has been frozen today, I will fix this bug only after the release. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402587: Please remove libadabindx from unstable
Package: ftp.debian.org Severity: wishlist libadabindx has been orphaned for 2 months and nobody has stepped up to adopt it. As #392083 explains, this package is unused, unmaintained and abandoned upstream. Please remove it from the archive, thus closing #392083. Thanks. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414615: gnat-gps: Crashes when activating any of the 'Browsers' submenu entries from the editor context menu
tags 414615 confirmed thanks Wow, that's a nice one. But I get: raised PROGRAM_ERROR : s-intman.adb:158 explicit raise instead. I do not believe this is an ABI incompatibilty, because I build all Ada packages with the same compiler, namely gnat-4.1. But it could conceivably be a compiler bug, just like #400876/#400883. Alain, since you're so helpfully working on this, I would be interested in testing your patches. Kevin Brown (CC'd) is also interested. Please see http://www.ada-france.org/article131.html and maybe we can all join forces with help from monotone. The monotone database contains some debugging code that Kevin and I added to gnat-gps but never uploaded to Debian. It is in a special branch called org.debian.gnat-gps.debug. You can also get packages from there before they hit the archive (for example, libgtkada2 waited ~20 days in the NEW queue before being approved by the FTP masters). PS. As an emacs addict, I don't use gnat-gps myself and I am quite busy with Real Life but I will try to support your efforts. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414614: gnat-gdb: doesn't support 'break exception' (from gnat-gps)
retitle 414614 gnat-gps: calls gdb instead of gnatgdb with default project properties severity 414614 minor reassign 414614 gnat-gps thanks Alain Kalker writes: > Package: gnat-gdb > Version: 6.4+2006-2 > Severity: important > > When enabling the preference 'Debugger->Break on exceptions' in gnat-gps > and subsequently initializing a debugging session, the debugger reports: > > (gdb) break exception > Function "exception" not defined. It seems that this is not the correct gdb. Try "show version" in the debugger console. The correct output should be: GNU gdb 6.4 for GNAT Pro 2006 (20060522) Copyright 2005 Free Software Foundation, Inc. Ada Core Technologies version of GDB for GNAT Professional GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". which I get from an xterm after calling gnatgdb. But in gnat-gps, after initializing the debugger and doing "show version", I get: GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". which is the wrong gdb, without Ada support. This seems like a bug in gps, because the project properties, "Languages" tab, shows gnatgdb as the debugger. To correct the problem, I wrote /usr/bin/gnatgdb explicitly in the combo box for the debugger. Lowering the severity to minor because of this simple workaround, but definitely something worth fixing. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
I've just received a new laptop to replace my old IBM ThinkPad T22. The build time for gnat-gps went down from 220 minutes to 17 minutes. It's an HP Compaq nx6325 with dual-core AMD Turion 64x2 TL-60 @2GHz, and 2 GB of RAM. Got it with FreeDOS preloaded instead of Redmond's stuff, too, so I paid no "tax" on it :). As a result, I've been able to update patches/elaboration.patch to the point where gnat-gps 4.0.0 survives gnatbind's pessimistic elaboration order. Now it crashes with a Constraint_Error (access check failed) when clicking on a tab in the project properties notebook. Since this situation is no worse than that in 3.1.3, I'm going to upload 4.0.0-1. This build was made with -01, dynamic elaboration checks (-gnatE), stack checking (which requires an additional patch), and pessimistic elaboration order. If I ever fix this bug, I'll revert to more classical -O2, static elaboration checks and optimised elaboration order. The build scripts etc. are, of course, in the Monotone database for those interested (see http://www.ada-france.org/article130.html for French instructions, and the archives of comp.lang.ada for an English translation). PS. I'll upload amd64 instead of i386 binaries; wait for the buildds to produce 32-bit binaries. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Kevin Brown <[EMAIL PROTECTED]> writes: > Sounds like I'll wanna grab the current source, but it also sounds > like the changes you made and the changes I made are quite similar. Yes, and I just uploaded 4.0.1 which, according to its change log, fixes a few bugs, but not the ones we're interested in. The patches from 4.0.0 applied cleanly, but I also had to add a small patch for GtkAda 2.8.1. With both 4.0.0 and 4.0.1, I get slightly different symptoms from you: (1) GPS hangs, but does not crash, when trying to open a file selector. I too suspect something wrong in GtkAda. Unfortunately there is no unit test for the file selector. Maybe it would be worthwhile to write one. (unless I missed something in testgtk? Look in /usr/share/doc/libgtkada2-doc/examples/testgtk.tar.gz) (2) GPS crashes when clicking on the Naming tab in the project properties. Before it crashes, it opens a message box saying: "Unexpected fatal error, GPS is in an inconsistent state Please report with contents of /home/lbrenta/.gps/log.18230 You will be asked to save modified files before GPS exits" (the number in the log file name is the PID; it will change at each run). The last 4 lines in the log file read: [UNEXPECTED_EXCEPTION] 1/55 Unexpected exception Exception name: CONSTRAINT_ERROR _UNEXPECTED_EXCEPTION_ Message: project_properties.adb:3635 access check failed (2006-11-28 01:15:22.526) [UNEXPECTED_EXCEPTION] 2/56 Unhandled exception: Exception name: CONSTRAINT_ERROR _UNEXPECTED_EXCEPTION_ Message: project_properties.adb:3635 access check failed (2006-11-28 01:15:24.102) which is the same bug as I had in 3.1.3. That's why I said that 4.0.0 or 4.0.1 are no worse than 3.1.3. > ==22897== Invalid read of size 8 > ==22897==at 0x601684E: > system__finalization_implementation__attach_to_final_list (in > /usr/lib/libgnat-4.1.so.1) Mmm. I don't know what to make of that. I'd like to see a stack trace at that point, is that possible? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Kevin Brown <[EMAIL PROTECTED]> writes: > Hmm...it still crashes on me, consistently. I get the following > message: > > *** glibc detected *** corrupted double-linked list: 0x01b39820 *** > Aborted [...] > By the way, why'd you close this bug? On amd64 the bug is just as > valid now as it was before... I have not seen this crash. In my experience, gnat-gps is now mostly usable and I think it should be allowed into testing. The crashes I reported in #393636 are gone, and so are those you reported that were due to elaboration problems. That's why I closed this bug. I suggest you file a new bug with the doubly-linked list problem, with steps to reproduce and severity Important. Also I think it is time to replace the all-catching, vague bug report with more precise ones which I can then forward upstream with some hope to see them fixed. BTW, I'm running Etch not sid; if the problem happens consistently on Sid and not on Etch, then this is evidence that the problem is in some other library. And yes I now run amd64, too :) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400876: gnat-gps: Crash after clicking on "Browse" in the welcome screen
Running gnat-gps under valgrind revealed many, many errors. One seemed related to #400876 and #400883, which I was investigating at the time; it looked like a double deallocation problem: ==25342== Address 0x9F3D820 is 48 bytes inside a block of size 840 free'd ==25342==at 0x4A1B46D: free (vg_replace_malloc.c:233) ==25342==by 0x435A39: __gnat_free (s-memory.adb:82) ==25342==by 0x70929A: vfs__unchecked_free (vfs.adb:458) ==25342==by 0x6F4A7C: directory_tree__read_directory (directory_tree.adb:1161) ==25342==by 0x6F3A13: directory_tree__read_directory (directory_tree.adb:1115) ==25342==by 0x6F7869: directory_tree__file_append_directory (directory_tree.adb:1309) ==25342==by 0x6FD1F2: directory_tree__refresh (directory_tree.adb:1713) ==25342==by 0x6F8F61: directory_tree__initialize (directory_tree.adb:1434) ==25342==by 0x6F81AF: directory_tree__gtk_new (directory_tree.adb:1368) Removing just the call to VFS.Unchecked_Free which triggers the error solves only part of the problem, as GPS hangs when I click on OK or Close in the file selector. Turning VFS.Unchecked_Free into a no-op introduces memory leaks, but makes the problems described in both bugs disappear. That's what the patch below does. Kevin, could you please try it and report back? I don't think this patch solves the problem, it just prevents it from being triggered. -- Ludovic Brenta. Index: common/src/vfs.adb === --- common/src/vfs.adb.orig 2006-11-29 15:42:12.723222000 +0100 +++ common/src/vfs.adb 2006-11-29 15:42:54.917859250 +0100 @@ -452,10 +452,8 @@ procedure Unchecked_Free (Arr : in out File_Array_Access) is - procedure Internal is new Ada.Unchecked_Deallocation -(File_Array, File_Array_Access); begin - Internal (Arr); + null; end Unchecked_Free; - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400876: dmalloc
Duncan Sands <[EMAIL PROTECTED]> writes: > I tried running gnat-gps with dmalloc preloaded: Thanks for taking the time to try and help me out! [...] > debug-malloc library: dumping program, fatal error >Error: cannot locate pointer in heap (err 22) > Aborted (core dumped) [...] > I hope this inspires you :) It inspires me to study the Tao of Programming some more... I'll upload 4.0.1-3 with the patch I mentioned tonight; then I'll try to reproduce what you said and see what I can glean from the core file. However, memory corruption bugs have a nasty tendency to cause crashes in random, unrelated places :) > PS: In your instructions for reproducing, you say "then click on > Browse". I see no "Browse" - what do you mean exactly? Options (1) and (3) on the welcome screen have Browse buttons next to them. Only the one next to the selected option is active. When you click on it, GPS is supposed to open a file selector dialogue box. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390636: Undefined subroutine &main::WIFEXITED called at /usr/lib/dpkg/controllib.pl line 433
The bug just struck on a buildd on powerpc: see http://buildd.debian.org/fetch.cgi?pkg=gnat-gps;ver=4.0.1-3;arch=powerpc;stamp=1164850518 Two days earlier, on the same machine (malo), the same package built successfully: http://buildd.debian.org/fetch.cgi?&pkg=gnat-gps&ver=4.0.1-1&arch=powerpc&stamp=1164674176&file=log debian-admin, could you please investigate and see if dpkg-dev was "upgraded" in the mean time? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400876: gnat-gps: Crash after clicking on "Browse" in the welcome screen
Kevin Brown writes: > Why are we using any unchecked deallocations at all? That seems > counter to one of the biggest reasons to use Ada: correctness > checking. > > I'd rather take the potential heap usage hit and guarantee > correctness here. Is there any way we can turn this uncheck > deallocation to a checked deallocation? "we" is actually the upstream author, AdaCore. The only "checked" deallocation that takes place in Ada is the one for objects on the stack. For heap-allocated objects, there are only two choices: - either you use an instance of Ada.Unchecked_Deallocation (which is still safer than C's free() because it guards against double deallocation and calls any finalization routines necessary) - or you declare an access type in a nested scope and specify a Storage_Size. When the access type goes out of scope, the storage is reclaimed. In the case of GPS, not many access types can be practically defined in a nested scope. Ada allows a garbage collector, but GNAT doesn't provide one out of the box (nor does any other Ada compiler). All allocations and deallocations are therefore explicit. > If it happens that the memory is never freed then it means that > something is referring to it when it shouldn't, and that would > obviously warrant investigation in its own right. In the absence of a garbage collector, the only reason why memory isn't freed is because my patch disabled the deallocation. However I'm quite convinced that there is a dangling pointer somewhere. Since I compile with full run-time checks, no overflow could have gone unnoticed. Valgrind flagged directory_tree.adb:1161 as deallocating memory that was already freed. Removing that one line didn't solve the problem, though; I had to change _all_ calls to VFS.Unchecked_Free into no-ops before the symptoms (crashes) disappeared. So, yes, we do need to investigate. BTW, two logs from valgrind are in gnat-gps_4.0.1-3.diff.gz; one taken before the memory_corruption.patch, and the other with the patch applied. In both cases, I started gnat-gps, selected the third option from the welcome box, and clicked Browse next to it. > I would hope that GNAT would provide the means to determine why the > allocator believes the memory chunk in question is still in use... GNAT does provide a facility called "debug storage pools", but using that facility would be a major undertaking. We'd have to create one pool for each (non-derived) access type, and associate the access type with it. That would allow us to detect memory leaks (but so does valgrind). Unfortunately, it would most probably cause the memory corruption to not take place anymore, so we wouldn't be able to track it down. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400876: gnat-gps: Crash after clicking on "Browse" in the welcome screen
Kevin Brown <[EMAIL PROTECTED]> writes: > I modified the Contents_Access finalization code to configure the > debug pool to not raise exceptions and instead to print out the > various information it can when encountering this error. The end > result looks like this: Be careful: Virtual_File is particularly nasty; it is an Ada controlled object, but GPS also stores its address (not access) in a "boxed" GObject. As a result there are two copies of Finalize and two copies of Adjust; one is called from Ada and the other from glib, as a callback. It is important to modify both versions of Adjust and Finalize. See vfs.adb:1167: procedure Finalize (File : in out Virtual_File) is vfs.adb:1176: procedure Adjust (File : in out Virtual_File) is vfs.adb:1309: function Virtual_File_Boxed_Copy vfs.adb:1325: procedure Virtual_File_Boxed_Free (Boxed : System.Address) is The latter two are passed as callbacks to glib in VFS.Get_Virtual_File_Type. > So I'm tempted to file another bug, this one against libgnat-4.1, > stating that we need to compile a debug version (that would land in > /usr/lib/debug) so that it's possible to set breakpoints within > library functions. We should do so for the various libgtkada-2.8 > libraries as well, but libgnat is by far the most important in this > regard. Try to link statically against /usr/lib/gcc/x86_64-linux-gnu/4.1.2/adalib/libgnat.a, it already contains debugging symbols. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400876: gnat-gps: Crash after clicking on "Browse" in the welcome screen
Kevin Brown writes: > All I wanted to do was to call GNAT.Debug_Pool.Configure(). > Ideally, I'd want to call it only once at program initialization > time, but I don't know how to do that from within vfs.adb, so I > settled on calling it from the finalization code. You can add elaboration code like this: package body VFS is ... begin GNAT.Debug_Pool.Configure (Pool => My_Pool); end VFS; -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400876: gnat-gps: Crash after clicking on "Browse" in the welcome screen
Kevin Brown <[EMAIL PROTECTED]> writes: > I can't just specify -static because it requires *all* libraries to > be static. All Ada libraries only, i.e. not glibc or GTK+. The Ada libraries involved are: /usr/lib/gcc/x86_64-linux-gnu/4.1.2/adalib/libgnat.a /usr/lib/libgnatprj.a /usr/lib/libgnatvsn.a /usr/lib/libtemplates_parser.a /usr/lib/libgtkada2.a -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400876: gnat-gps: Crash after clicking on "Browse" in the welcome screen
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/adalib/libgnarl.a and I really don't think you need libpython2.4.a or anything else. The reason why you need static Ada libraries and nothing else is because all Ada libraries are linked dynamically against libgnat-4.1.so; if you replace it with a static version then you also need to replace the dependent libraries with static versions. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400876: gnat-gps: Crash after clicking on "Browse" in the welcome screen
Kevin Brown writes:
[Trouble linking statically]
> For what it's worth, here's one iteration of the linker package
> definition that I've tried to use:
>
>package Linker is
> for Default_Switches ("Ada") use
> ("-g",
> "-static",
> "/usr/lib/libgnatprj.a",
> "/usr/lib/libgnatvsn.a",
> "/usr/lib/libtemplates_parser.a",
> "/usr/lib/libgtkada2.a",
> "/usr/lib/gcc/x86_64-linux-gnu/4.1.2/adalib/libgnarl.a",
> "/usr/lib/gcc/x86_64-linux-gnu/4.1.2/adalib/libgnat.a",
> GtkAda2.Linker_Switches,
> Gnatprj.Linker_Switches,
> Gnatvsn.Linker_Switches,
> Templates_Parser.Linker_Switches,
> -- Some C libraries which we build from debian/rules:
> "obj/libgps.a", "obj/libdb.a",
> -- The python shared library from python-dev comes
> -- last, because libgps.a needs it.
> "-L/usr/lib/python2.4/config",
> "-lpython2.4");
>end Linker;
The problems are:
- You must pass -static to the *binder*, not the *linker*. As per the
GAT documentation, you do not need to pass libgnata or libgnarl.a
explicitly; the binder's job is to figure out these things for you.
- Like I said, you should be linking statically with all Ada
libraries. Consequently, you should have removed the
*.Linker_Switches, since they're the ones bringing in the shared
libraries.
- libgps.a is not an Ada library, and it does not require any shared
library, so it is not the cause for your problem. Same with
libdb.a.
Here is a correct project file snippet:
package Binder is
for Default_Switches ("Ada") use ("-static");
end Binder;
package Linker is
for Default_Switches ("Ada") use
("/usr/lib/libgnatprj.a",
"/usr/lib/libgnatvsn.a",
"/usr/lib/libtemplates_parser.a",
"/usr/lib/libgtkada2.a",
"-lgtk-x11-2.0",
-- Some C libraries which we build from debian/rules:
"obj/libgps.a", "obj/libdb.a",
-- The python shared library from python-dev comes
-- last, because libgps.a needs it.
"-lpython2.4");
end Linker;
And the output of ldd for the resulting gnat-gps:
$ ldd gnat-gps
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x2ae6438ae000)
libpython2.4.so.1.0 => /usr/lib/libpython2.4.so.1.0 (0x2ae643cd7000)
libpthread.so.0 => /lib/libpthread.so.0 (0x2ae643f16000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ae64402b000)
libc.so.6 => /lib/libc.so.6 (0x2ae644138000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0
(0x2ae644376000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x2ae64448e000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x2ae644622000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x2ae644764000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x2ae64496d000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x2ae644aae000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x2ae644bb2000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0
(0x2ae644d4f000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x2ae644e58000)
libdl.so.2 => /lib/libdl.so.2 (0x2ae644f79000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x2ae64507c000)
libm.so.6 => /lib/libm.so.6 (0x2ae6451e5000)
libutil.so.1 => /lib/libutil.so.1 (0x2ae645368000)
/lib64/ld-linux-x86-64.so.2 (0x2ae643796000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x2ae64546b000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x2ae64559e000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x2ae6456b)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x2ae6457b9000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x2ae6458bb000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x2ae6459c4000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x2ae645ac7000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x2ae645bd1000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x2ae645cd7000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x2ae645dd9000)
librt.so.1 => /lib/librt.so.1 (0x2ae645ede000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0
(0x2ae645fe8000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x2ae646116000)
libz.so.1 => /usr/lib/libz.so.1 (0x2ae64628e000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x2ae6463a5000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x2ae6464c8000)
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398492: gnade-dev: gnat 4.1 support
tags 398492 pending thanks Brian May wrote: > Unless I missed something, gnat-4.1 support would allow me to compile > the one application against both gnade and xmlada available in Debian. The thing you missed is that gnade 1.6.1 is in the NEW queue and will hit sid shortly :) Indeed it will allow you to combine glade with all other libraries compiled with gnat-4.1. Tagging as pending until gnade reaches unstable. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358301: gnat is now gnat-4.1
Agreed. I have to upload a new version of gnade anyway due to the new ABI, so I'll fix this bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370634: gch: FTBFS: transition to GNAT 4.1 (waiting for asis)
I have asked the maintainer to remove the package, because I have just uploaded adacontrol, a nice replacement which is maintained upstream (unlike gch). adacontrol builds with the new asis 2005 version, which I also uploaded this evening. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384281: gnat-gps: Build-depends on libxmlada1-dev which is uninstallable
Yes, I'm in the middle of a transition of all packages to GCC 4.1
instead of gnat 3.15p.
In Sarge:
gnat-gps 2.1.0 depends on libgtkada2 2.4.0, libxmlada1 1.0.0, gnat 3.15p
In Etch:
gnat-gps 4.0.0 depends on libgtkada2 2.8.1, libxmlada2 2.2, gnat 4.1
Current status:
- gnat 3.15p and libxmlada1 have been removed (the removal of gnat on
kfreebsd-i386 is just lagging behind but will take place eventually).
- gnat 4.1, libxmlada2 are in Etch.
- I've almost completed the work on libgtkada2 2.8.1 but will not be
able to upload before at least september 11 (ADSL link down at home
due to move).
- gnat-gps 4.0.0 will follow shortly thereafter. It may or may not
have the bug you experienced.
If you are being held up by this bug, I suggest you create a Sarge
(stable) chroot and rebuild gnat-gps 2.1.0-8 in there; the build scripts
will create an executable with debugging symbols by default. The
executable will be called "gps" in the top-level source directory.
(warning: takes an hour to build on my Pentium III @900 MHz, but the
build script takes advantage of multiple CPUs if present).
> -- System Information:
> Debian Release: 3.1
> Architecture: i386 (i686)
> Kernel: Linux 2.6.8met2
> Locale: LANG=C, LC_CTYPE=fi_FI (charmap=ISO-8859-1)
>
> Versions of packages gnat-gps depends on:
> ii libatk1.0-0 1.8.0-4The ATK accessibility toolkit
> ii libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries
> an
> ii libglib2.0-0 2.6.4-1The GLib library of C routines
> ii libgnat-3.15p-1 3.15p-12 The GNU Ada 95 compiler runtime
> li
OK, seems like a Sarge chroot. If you want to rebuild gnat-gps 2.1.0-8
as opposed to the Sarge version (2.1.0-4), then you'll need gnat
3.15p-19, not -12. You can get most of the required packages in source and
binary form from my staging area:
http://www.ada-france.org/debian/pool/
(sorry, the Packages.gz file is out of date, don't use apt-get).
> ii libgtk2.0-0 2.6.4-3.1 The GTK+ graphical user
> interface
> pn libgtkada-2.4Not found.
It seems your chroot is out of date and perhaps contains the source package
libgtkada2 (<= 2.4.0-2). Please try to "apt-get update" it so you get
libgtkada2 (>= 2.4.0-4) which provides the missing binary package.
> ii libpango1.0-0 1.8.1-1Layout and rendering of
> internatio
> ii python2.3 2.3.5-3sarge1 An interactive high-level
> object-o
Summary:
1. apt-get update/upgrade the Sarge chroot, will install libgtkada-2.4
2. wget http://www.ada-france.org/debian/pool/*3.15p-19*.deb
3. dpkg --install gnat_3.15p-19_i386.deb libgnat3.15p_3.15p-19_i386.deb
4. wget http://www.ada-france.org/debian/pool/libgtkada*_2.4.0-8*.deb
5. dpkg --install libgtkada{2-dev,-2.4}_2.4.0-8_i386.deb
6. apt-get build-dep gnat-gps (will install tcl8.4-dev, libcairo2-dev)
7. cd gnat-gps-2.1.0; debian/rules build (will give debugging symbols)
(the above is off the top of my heat, caveat emptor)
HTH
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384281: gnat-gps: Build-depends on libxmlada1-dev which is uninstallable
> Ok. Does it look like gnat-gps could be included in etch? Yes, I'm confident that gnat-gps 4.0.0 will be in Etch. > Unfortunately gdb hits infinite loop if I produce my ada binaries > with gcc-3.3 so I am using gcc 4.1 in unstable chroot instead, gnat-3.3 is known to be buggy, I recommend against using it. Does the problem also happen when you build with with gnat 3.15p on Sarge? You may also want to pass -gstabs+ or -gstabs- to gcc and see if it makes a difference. > Thanks for all the suggestions. Fortunately I can probably live with > ada-mode in emacs for now. Yes, but gdb will still go into an infinite loop won't it? What is the bug you are experiencing in gnat-gps? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299033: Debian bug #299033: gnat compiler crash
retitle 299033 gnat: Gigi abort, code=999 thanks Is the bug still present in gnat 4.1, which is now in testing? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384123: cpp has broken dependancies
It seems you are running a mix of different versions of Debian? In Sarge: cpp4:3.3.5-3 depends on cpp-3.3 (>= 1:3.3.5-1) cpp-3.31:3.3.5-13 depends on gcc-3.3-base (>= 1:3.3.5-13, << 1:3.3.6) gcc-3.3-base 1:3.3.5-13 satisifies the dependency. So the question boils down to: why do you have gcc-3.3-base (=3.3.6-5) installed? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352368: gnat-gps: AMD64 port?
Hi J??rome, The good news is that I'm almost finished with the packaging of libgtkada2 2.8.1; gnat-gps is next in my priority list. The bad news is that I'm out of ADSL until Sept 11 at least, possibly a few days after that. I'll upload in september. -- Ludovic Brenta.
Bug#383440: adacgi: Ada spec and library information files in
Phil Brooke wrote: > On Thu, 17 Aug 2006, Ludovic Brenta wrote: > >> Since AdaCGI is a library, it must consist of two binary packages: >> libadacgi-dev and libadacgi1. > > No, I disagree. I see no benefit to users in making such Debian-specific > changes. See end of email. [...] > I'm happy to be convinced otherwise about (not) converting the package > to multiple binaries. However, I don't see any significant benefit at > this time. If I understand your proposal correctly, you want to provide the .gpr file and the source and .ali files in their proper places, but you would still provide the object files in /usr/lib/ada/adalib/adacgi/*.o, right? The pro of this proposal is reduced complexity, both for you and for users (one package instead of two). The con is a lack of consistency with other library packages; both in the naming scheme for packages, and in that it would be impossible for users to pass "-ladacgi" to the linker. Maybe you could mitigate that with linker options in the project file. Also the lack of a shared library means users have no option but to link statically. I think that it would still be a good idea to at least compile adacgi with -g, per general Debian policy. I don't feel very strongly one way or another, because the small size of adacgi excuses it for not being a honest-to-God shared library :) > Do any other distributions do this to adacgi? No, but then again, AFAIK no other distribution carries adacgi; not even Gentoo and not even FreeBSD :) so, Debian leads the way once again :) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382466: adacontrol: FTBFS: dpkg-genchanges: failure: cannot read files list file: No such file or directory
tags 382466 pending thanks Roland Stigge writes: > this should be fixed by moving the commands from the "binary" to the > "binary-arch" target. Yep. I've already made the changes, but my ADSL hasn't been transferred to my new home yet, so I can't upload just now. ETA is mid-September. Thanks -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#380587: Please go ahead
The package is ready on my hard disk, but the upload has been delayed by the telephone company's inability to transfer my ADSL connection to my new home in a timely manner :( They're supposed to do the transfer today; then I have to make sure ADSL works, and I'll upload as soon as I can. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#380587: Please go ahead
George Danchev wrote: > Ah, I see, bad day ;-). In that case you might consider mailing your > debian/ directory to a fellow DD (if it is not already kept in a public > VCS), to upload instead of you (I don't think an NMU is needed in that case). > Assuming there is get-orig-source target or exact instructions of how to > get the upstream tarball. Just an idea. I'm actually planning to place my Monotone database on Ada-France's server, http://www.ada-france.org. But I need my ADSL for that :) The guys came yesterday and dug a hole in the pavement in front of my house, and pulled the wires to the house. They're supposed to come back today to actually connect the thing to the network. My package for GtkAda 2.8.1 is ready for upload. Hold your breath now :) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#387250: [NONFREE-DOC] Package contains IETF RFC/I-D
Simon, Thanks for bringing this issue to my attention. I will remove the RFC documents from the package, as I'm sure they're in doc-rfc anyway. However, before I do that, I'll ask upstream when a new release is planned, and whether they'd be willing to delete the documents from their tarballs. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#387826: libgnatprj4.1: does not support library project files; affects gnat tools
Package: libgnatprj4.1 Version: 4.1.0-2 Severity: normal The package libgnatprj4.1 mistakenly contains an object file compiled from mlib-tgt.adb instead of mlib-tgt-linux.adb. As a consequence, none of the GNAT tools will support project files. This bug is specific to Debian, and was introduced with the package libgnatprj4.1. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#387899: As I undestand ssl-thin.ads must be added as "alternative".
Olleg Samoylov <[EMAIL PROTECTED]> writes:
> I can't compile aws application.
>
> rateme.adb:4:06: file "ssl-thin.ads" not found
> rateme.adb:4:06: "Rateme (body)" depends on "Aws.Client (spec)"
> rateme.adb:4:06: "Aws.Client (spec)" depends on "Aws.Net.Ssl (spec)"
> rateme.adb:4:06: "Aws.Net.Ssl (spec)" depends on "Ssl.Thin (spec)"
>
> But exists files ssl-thin__dummy.ads, ssl-thin__gnutls.ads,
> ssl-thin__openssl.ads. As I undestand they are alternatives for
> ssl-thin.ads and must be added debian "alternative" for this.
No, because this is a compile-time "alternative"; the Debian
alternatives system only deals with run-time "alternatives".
Moreover, you don't really have a choice; due to licensing
requirements, I have linked libaws2.2 against libgnutls13 and so AWS
will always use GNU TLS instead of OpenSSL.
The proper thing to do is to add a package Naming in a project file.
In fact, it should be /usr/share/ada/adainclude/aws.gpr; I'll correct
that problem.
In the mean time, you can try to add this to your project file:
with "aws.gpr";
project Rateme is
[...]
package Naming is
-- Configuration for GNU/Linux using GNU TLS for strong crypto
for Body ("AWS.Net.SSL") use "aws-net-ssl__gnutls.adb";
for Body ("AWS.Net.SSL.Certificate")
use "aws-net-ssl-certificate__gnutls.adb";
for Body ("AWS.Net.Std") use "aws-net-std__gnat.adb";
for Body ("AWS.OS_Lib") use "aws-os_lib__gnat.adb";
for Body ("AWS.Translator.Conversion")
use "aws-translator-conversion__f.adb";
for Spec ("SSL.Thin") use "ssl-thin__gnutls.ads";
for Spec ("Templates_Parser.Configuration")
use "templates_parser-configuration__aws.ads";
end Naming;
...
end Rateme;
This fix will become unnecessary when I upload the patched AWS.
Thanks for pointing the problem to me.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388560: [Fixed in 4.2] ICE in build_binary_op, at ada/utils2.c:848
Package: gnat-4.1 Version: 4.1.0-2 Severity: normal Tags: upstream, fixed-upstream Forwarded: http://gcc.gnu.org/PR15305 (This bug was reported to me a long time ago, but was not in Debian at the time. Now recording it for reference.) with unchecked_conversion; procedure Test_100 is package pak1 is type T2 is private; function "=" (left, right : T2) return Boolean; private type T3 is access integer; type T2 is new T3; function convert is new unchecked_conversion (integer, T3); end pak1; package body pak1 is function "=" (left, right : T2) return Boolean is begin return false; end "="; end pak1; generic type T1 is private; x1: in T1; x2: in out T1; package pak2 is b: boolean := x1 = x2; end pak2; y1: pak1.T2; y2: pak1.T2; package new_pak2 is new pak2 (pak1.T2, y1, y2); begin null; end Test_100; $ $ gnatmake test_100.adb gcc-4.1 -c test_100.adb +===GNAT BUG DETECTED==+ | 4.1.2 20060729 (prerelease) (Debian 4.1.1-10) (i486-pc-linux-gnu) GCC error:| | in build_binary_op, at ada/utils2.c:848 | | Error detected at test_100.adb:30:26 [test_100.adb:35:4] | -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378437: asis: FTBFS: bashisms
tags 378437 pending thanks Now that Packages-arch-specific has been updated, I can upload a new asis that fixes this bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378715: libopentoken: Uninstallable due to unmet dep on gnat (< 3.16)
Felipe, Thanks for the contribution, but this is insufficient. You see, the new Ada compiler (GCC 4.1) changes the ABI, so it is necessary to change the soname of the shared library. I am currently in the process of migrating all Ada packages to the new compiler, but I am struggling. Would you have time to submit an updated patch that also changes the soname? Look in debian/rules and in debian/control, there is nothing else to change IIRC. After the soname change, the package must build-depend on gnat (>= 4.1) and the -dev package must depend on gnat-4.1. This is because gnat-4.2 will probably change the ABI again. Thanks -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370560: Merge #370560 and #379921
merge 370560 379921 thanks I am still waiting for the change to Packages-arch-specific to take effect on the buildds. I will probably not be able to upload the new libaws (2.2) before August 10, as I'll be on vacation starting tomorrow evening. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378715: libopentoken: Uninstallable due to unmet dep on gnat (< 3.16)
Felipe Augusto van de Wiel writes:
> Looking in debian/rules I found out that the major from the version
> field is used as soname, as I'm a little bit new with library RC
> bugfix, I just want to know if I did it right, before submit the
> patch.
>
> I did not touch debian/rules. I added the following entry to
> debian/changelog:
>
>
> libopentoken (4.0-1) unstable; urgency=medium
>
> * Non-maintainer upload. (Closes: #378715).
> - Bump SONAME to 4, due to gnat transition.
> - Dependency changes in debian/control
> + libopentoken build-depends on gnat (>= 4.1)
> + libopentoken-dev depends on gnat-4.1
>
> -- Felipe Augusto van de Wiel (faw) <[EMAIL PROTECTED]> Thu,
> 27 Jul 2006 18:36:30 -0300
It is against debian policy to invent a new version number on behalf
of upstream; it should really be 3.0b-3.1 for an NMU, or 3.0b-4 if you
submit the patch to me and I upload the package.
It is okay if the soname does not match the major version number;
there are other examples of this, like libgnutls13 (1.4.1-1).
So therefore, debian/rules must change one way or another.
The soname libopentoken.so.4 is fine, but you may also want to
consider libopentoken.so.3.0b, which requires smaller changes to
debian/rules. It's up to you.
> And here is the debian/control:
>
> Source: libopentoken
> Priority: optional
> Maintainer: Ludovic Brenta <[EMAIL PROTECTED]>
Please change my email address while you're at it: [EMAIL PROTECTED]
> Uploaders: Matthias Klose <[EMAIL PROTECTED]>
No longer necessary, as I don't need a sponsor anymore :) but, if you
want to adopt the package, you can add your sponsor's address here. I
can be your sponsor for this package if you want.
> Build-Depends: debhelper (>= 4.1.0), gnat (>= 4.1)
> Standards-Version: 3.6.2
Please update to 3.7.2 with no changes required, and say so in the
changelog.
> Package: libopentoken-dev
> Section: libdevel
> Architecture: i386 kfreebsd-i386 powerpc sparc
Sorry I forgot to tell you that earlier but gnat-4.1 supports more
architectures than gnat 3.15p did; so please change that to:
Architecture: amd64 hppa i386 ia64 kfreebsd-i386 powerpc sparc
> Depends: libopentoken3 (= ${Source-Version}), gnat-4.1
Should depend on the proper library package, with a name matching the
soname: so either libopentoken4, or libopentoken3.0b depending on your
choice.
> Description: OpenToken lexical analysis library for Ada
>
>
> Tha package built sucessfully, I installed it and here is the
> libopentoken listing:
>
> $ l /usr/lib/libopentoken.*
> - -rw-r--r-- 1 root root 746130 Jul 27 18:44 /usr/lib/libopentoken.a
> lrwxrwxrwx 1 root root 19 Jul 27 18:47 /usr/lib/libopentoken.so ->
> libopentoken.so.4.0
Good. These are the files from the -dev package, but you seem to be
missing the actual library.
Also, if you choose libopentoken.so.3.0b for the soname you'll need to
reflect the changes there; you should see either:
/usr/bin/libopentoken.a
/usr/bin/libopentoken.so -> libopentoken.so.4.0
/usr/bin/libopentoken.so.4 -> libopentoken.so.4.0 *
/usr/bin/libopentoken.so.4.0
or
/usr/bin/libopentoken.a
/usr/bin/libopentoken.so -> libopentoken.so.3.0b
/usr/bin/libopentoken.so.3.0b *
(before the upload, it is:
/usr/bin/libopentoken.a
/usr/bin/libopentoken.so -> libopentoken.so.3.0b
/usr/bin/libopentoken.so.3 -> libopentoken.so.3.0b *
/usr/bin/libopentoken.so.3.0b
The important thing is that programs linked against the library must
find a file with the same name as the soname, I have marked them with
* above)
> it is ok, I will be happy to send the patch to debian/control and
> debian/changelog to the BTS, probably my AM (Applicant Manager) will
> also take a look to the NMU packages, and if you or him want to
> upload the prepared packages, I will be happy to see that
> happening. ;)
OK, it's up to you. You can either:
- submit the patch to me and I'll upload in August, after returning
from vacation (must be version 3.0b-4)
- ask your sponsor to upload an NMU (add his email address to the
Uploaders: field) (must be version 3.0b-3.1)
- adopt the package (change the maintainer's address to your
address, and add your sponsor's address to Uploaders; I can be your
sponsor for this package, too) (must be version 3.0b-4).
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#380615: libtemplates-parser: FTBFS: problem generating dvi files
tags 380615 moreinfo thanks Julien Danjou wrote: > Building templates_parser.pdf > /usr/bin/texi2dvi -p --expand --clean --quiet templates_parser.texi > /usr/bin/texi2dvi: pdfetex exited with bad status, quitting. > /usr/bin/texi2dvi: see templates_parser.log for errors. I'm back now. Could you please attach the file, templates_parser.log, to the bug report? Thanks. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373247: marked as done (adabrowse: FTBFS: transition to GNAT 4.1 (waiting for asis))
reopen 373247 tags 373247 pending reopen 330814 Matej Vela wrote: > BTW, Ludovic, you seem to have closed #330814 by mistake. Should it > be reopened? Or does disabling project management make it moot? Correct. Thanks for pointing this out. The bug is still a wish of mine, but I haven't had a response from upstream. It should remain open. I'm also reopening #373247 because the buildds have not yet build asis on all supported architectures. I've asked the buildd maintainers to take the new architectures into account and trigger a build on the new ones. I'll reupload adabrowse when that's done; tagging "pending". -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370560: libaws: FTBFS: transition to GNAT 4.1
>> # libxmlada2 now in unstable. >> retitle 370560 libaws: FTBFS: transition to GNAT 4.1 Thanks Matej for this. Your work on bug triaging is very useful to me. I am also waiting for the DAK people to update Packages-arch-specific to take into account the new architectures supported by GCC 4.1. I am not yet ready to upload libaws, but I've started work already. The update to Packages-arch-specific affects all Ada packages, so I'm being held at the moment. I asked for this update on 2006-07-15 or thereabouts, but received no reply so far. -- Ludovic Brenta. == Please ignore this: == -- Club Scarlet : Tout le monde gagne! Si vous devenez aujourd'hui Scarlet One grace a un client existant de Scarlet, vous recevez tous les deux un cadeau d'une valeur de 50 euros! Surfez vite sur http://www.clubscarlet.be
Bug#378160: adacontrol: FTBFS: missing build-dep on debhelper
tags 378160 pending thanks I'm waiting for a change to packages-arch-specific to allow building asis on all architectures supported by GCC 4.1. I will upload the fixed adacontrol aftwerwards. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379795: RM: libflorist-3.15p-1 -- RoM, superseded by libflorist, RC-buggy
Package: ftp.debian.org Severity: normal Please remove the package libflorist-3.15p-1 from unstable and testing. It currently FTBFS due to the transition to a newer Ada compiler (see #377841). I am planning to upload a replacement package named libflorist, with a newer version number (= 2006-1), soname (libflorist.so.2006) and corresponding package names. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384565: monotone - FTBFS: Build killed with signal 15
The bug still happens with 0.30. I was browsing the monotone-devel archives and something went *tick* in my head: Shaun Jackman wrote: > The monotone-0.30.tar.gz tarball shipped with package_revision.txt set > to `unknown'. Should this be fixed? Thomas Moschny wrote: > [it is likely to affect 0.30 users] only in such a way that > 'mtn --full-version' says something like "base revision: unknown", > and only if they use a binary built from the official tarfile. Other > than that purely cosmetic issue it should not cause any problems. > > However, if you used to do something like 'cat _MTN/revision' in *your > own* project, you should change that to 'mtn automate get_revision_id'. Nathaniel Smith wrote: > 'mtn automate get_base_revision_id' The build failure occurs when you try to call 'mtn automate get_revision'. Could you try to change that to get_base_revision_id, and see if it improves things? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384565: monotone - FTBFS: Build killed with signal 15
Much to my bafflement, I notice that 0.29 built successfully on sparc, but 0.30 FTBFS. Also, the machine that built 0.29 may not be the same as the one that built 0.30; for sparc, these were phleebhut and auric, respectively. I suspect that there may be a hardware problem on some of the buildd machines. The current situation is: 0.280.290.30 alpha ok ok ok amd64 ok ok ok arm ok FTBFS FTBFS hppa ok FTBFS FTBFS ia64 ok ok ok m68k ok FTBFS ? mips ok FTBFS FTBFS mipselok FTBFS FTBFS powerpc ok ok ok s390 ok FTBFS ? sparc ok ok FTBFS m68k is lagging behind as usual, and s390 is uncharacteristically lagging behind :) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390101: gnat-4.1: Bug box in expand_expr_addr_expr_1, at expr.c:6393
Package: gnat-4.1 Version: 4.1.1-14 Severity: normal While builing libtexttools on alpha: gcc-4.1 -c -I./ -g -O2 -gnatafno -gnatVa -I.. -I- /build/buildd/libtexttools-2.0.3/windows.adb windows.adb:273:14: warning: "x" may be referenced before it has a value windows.adb:273:17: warning: "y" may be referenced before it has a value windows.adb:1879:16: warning: "OldX" may be referenced before it has a value windows.adb:1879:22: warning: "OldY" may be referenced before it has a value windows.adb:2555:19: warning: "Relative" may be referenced before it has a value windows.adb:2574:19: warning: "Tempint" may be referenced before it has a value windows.adb:2666:03: warning: "OK" is never assigned a value windows.adb:2667:03: warning: "text" is never assigned a value +===GNAT BUG DETECTED==+ | 4.1.2 20060920 (prerelease) (Debian 4.1.1-14) (alpha-unknown-linux-gnu) GCC error:| | in expand_expr_addr_expr_1, at expr.c:6393 | | Error detected at windows.adb:3529:1 | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392083: O: libadabindx -- Ada binding to the X Window System and *tif
Package: wnpp Severity: normal I'm orphaning libadabindx. This package is unmaintained upstream and has zero votes in the Popularity Contest. It does have one known user however. I've contacted him privately to know if he would adopt the package. The package requires minimal work for a transition to GCC 4.1. This involves: - update the Build-Depends to gnat (>= 4.1) - update Depends of libadabindx-dev to gnat-4.1 - add alpha, amd64, hppa, ia64, s390 to Architectures - change the soname of the shared library, because of the new ABI - change the name of the library package. There may be other things I haven't thought about. Whoever adopts the package: if you're not a Debian Developer, contact me and I'll sponsor the package for you. If the package is not adopted by the time Etch freezes, I'll ask for removal. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382779: Bug #382779: libaws: FTBFS: probably bashims in pdf generation
severity 382779 wishlist
thanks
This problem also appears in libtemplates-parser (see #380615) and only
occurs if /bin/sh is dash. The shell script that builds the
documentation has nothing obvious that should succeed with bash and fail
with dash. There is a simple workaround: use bash.
Downgrading severity to wishlist ("add support for dash").
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429934: gnat-4.1: Incorrect type debugging information for variables in other compilation units
Package: gnat-4.1 Version: 4.1.1-22 Severity: normal Tags: confirmed, upstream In the test case below, GCC emits correct type information for Debugging.A but the type information for Extenal.B is incorrect. package External is type External_Type is array (1 .. 4) of Float; B : External_Type; end External; with External; procedure Debugging is A : External.External_Type; begin A := (1.0, 2.0, 3.0, 4.0); External.B := A; end Debugging; How to reproduce: $ gnatmake -g debugging.adb gcc-4.1 -c -g debugging.adb gnatbind -x debugging.ali gnatlink debugging.ali -g $ gnatgdb debugging Current directory is /home/lbrenta/src/tmp/ GNU gdb 6.4 for GNAT Pro 2006 (20060522) Copyright 2005 Free Software Foundation, Inc. Ada Core Technologies version of GDB for GNAT Professional [...] (gdb) break debugging Breakpoint 1 at 0x400d30: file debugging.adb, line 5. (gdb) run [...] Breakpoint 1, debugging () at debugging.adb:5 (gdb) ptype a type = array (1 .. 4) of <4-byte float>(correct) (gdb) ptype external.b type = <4-byte integer>(wrong) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnat-4.1 depends on: ii gcc-4.1 4.1.1-21 The GNU C compiler ii gnat-4.1-base 4.1.1-22 The GNU Compiler Collection (gnat ii libc6 2.5-9GNU C Library: Shared libraries ii libc6-dev 2.5-9GNU C Library: Development Librari ii libgcc1 1:4.2-20070528-1 GCC support library ii libgnat-4.1 4.1.1-22 Runtime library for GNU Ada applic ii libgnatprj4.1 4.1.1-22 GNU Ada Project Manager ii libgnatvsn4.1 4.1.1-22 GNU Ada compiler version library gnat-4.1 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430005: svk: svk depotmap --relocate does not move the contents of the repository
Package: svk Version: 2.0.1-1 Severity: normal As illustrated below, svk fails to move the contents of a repository even when explicitly asked to do so, using depotmap --relocate: [~] rm -rf .svk [~] svk depotmap --init '' /var/lib/svk Repository /home/lbrenta/.svk/local does not exist, create? (y/n)y Depot '' already exists; use 'svk depotmap --detach' to remove it first. [~] svk depotmap --relocate '' /var/lib/svk Depot '' relocated to '/var/lib/svk'. [~] rm -rf .svk /var/lib/svk/* [~] svk depotmap --init '' /var/lib/svk Repository /home/lbrenta/.svk/local does not exist, create? (y/n)y Depot '' already exists; use 'svk depotmap --detach' to remove it first. [~] svk depotmap --relocate '' /var/lib/svk Depot '' relocated to '/var/lib/svk'. [~] ll /var/lib/svk total 0 [~] ll .svk/local total 12 drwxr-xr-x 2 lbrenta lbrenta 51 2007-06-21 18:43 conf/ drwxr-xr-x 2 lbrenta lbrenta6 2007-06-21 18:43 dav/ drwxr-sr-x 5 lbrenta lbrenta 120 2007-06-21 18:43 db/ -r--r--r-- 1 lbrenta lbrenta2 2007-06-21 18:43 format drwxr-xr-x 2 lbrenta lbrenta 4096 2007-06-21 18:43 hooks/ drwxr-xr-x 2 lbrenta lbrenta 39 2007-06-21 18:43 locks/ -rw-r--r-- 1 lbrenta lbrenta 229 2007-06-21 18:43 README.txt -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages svk depends on: ii libalgorithm-annotate-perl 0.10-1 represent a series of changes in a ii libalgorithm-diff-perl 1.19.01-2a perl library for finding Longest ii libapp-cli-perl 0.07-2 Dispatcher module for command line ii libclass-accessor-perl 0.30-1 Automated accessor generator ii libclass-autouse-perl 1.23-1 Defer loading ( 'use'ing ) of a cl ii libclass-data-inheritable-p 0.06-1 Inheritable, overridable class dat ii libcompress-zlib-perl 1.42-2 Perl module for creation and manip ii libdata-hierarchy-perl 0.34-1 Handle data in a hierarchical stru ii libfile-spec-perl 3.24-2 provides functions for generating ii libfile-temp-perl 0.18-1 provides functions for generating ii libfreezethaw-perl 0.43-3 converting Perl structures to stri ii libio-digest-perl 0.10-1 Calculate digests while reading or ii liblist-moreutils-perl 0.21-1 Addition list functions not found ii liblocale-maketext-lexicon- 0.62-2 Lexicon-handling backends for "Loc ii liblocale-maketext-simple-p 0.16-1 Simple interface to Locale::Makete ii libpath-class-perl 0.16-0.1 Cross-platform path specification ii libperlio-eol-perl 0.13-1 PerlIO layer for normalizing line ii libperlio-via-dynamic-perl 0.11-1 dynamic PerlIO layers ii libperlio-via-symlink-perl 0.05-1 PerlIO layers for create symlinks ii libpod-escapes-perl 1.04-1 CPAN's Pod::Escapes -- for resolvi ii libpod-simple-perl 3.04-1 Perl framework for parsing files i ii libsvn-mirror-perl 0.73-1 A subversion repository mirroring ii libsvn-simple-perl 0.27-2 A simple interface for writing a d ii libterm-readkey-perl2.30-3 A perl module for simple terminal ii libuniversal-require-perl 0.10-1 Load modules from a variable ii liburi-perl 1.35-2 Manipulates and accesses URI strin ii libversion-perl 1:0.7203-1 Perl extension for Version Objects ii libyaml-syck-perl 0.71-1 Fast, lightweight YAML loader and ii perl5.8.8-7 Larry Wall's Practical Extraction ii perl-modules [libfile-temp- 5.8.8-7 Core Perl modules ii subversion 1.4.2dfsg1-2 Advanced version control system svk recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430003: svk: Refuses to create a new repository in arbitrary directory
Package: svk Version: 2.0.1-1 Severity: normal $ rm -rf $HOME/.svk $ svk depotmap --init '' /var/lib/svk Repository /home/lbrenta/.svk/local does not exist, create? (y/n) svk insists that the repo should be in this hardcoded default path, and ignores my explicit instruction not to use it. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages svk depends on: ii libalgorithm-annotate-perl 0.10-1 represent a series of changes in a ii libalgorithm-diff-perl 1.19.01-2a perl library for finding Longest ii libapp-cli-perl 0.07-2 Dispatcher module for command line ii libclass-accessor-perl 0.30-1 Automated accessor generator ii libclass-autouse-perl 1.23-1 Defer loading ( 'use'ing ) of a cl ii libclass-data-inheritable-p 0.06-1 Inheritable, overridable class dat ii libcompress-zlib-perl 1.42-2 Perl module for creation and manip ii libdata-hierarchy-perl 0.34-1 Handle data in a hierarchical stru ii libfile-spec-perl 3.24-2 provides functions for generating ii libfile-temp-perl 0.18-1 provides functions for generating ii libfreezethaw-perl 0.43-3 converting Perl structures to stri ii libio-digest-perl 0.10-1 Calculate digests while reading or ii liblist-moreutils-perl 0.21-1 Addition list functions not found ii liblocale-maketext-lexicon- 0.62-2 Lexicon-handling backends for "Loc ii liblocale-maketext-simple-p 0.16-1 Simple interface to Locale::Makete ii libpath-class-perl 0.16-0.1 Cross-platform path specification ii libperlio-eol-perl 0.13-1 PerlIO layer for normalizing line ii libperlio-via-dynamic-perl 0.11-1 dynamic PerlIO layers ii libperlio-via-symlink-perl 0.05-1 PerlIO layers for create symlinks ii libpod-escapes-perl 1.04-1 CPAN's Pod::Escapes -- for resolvi ii libpod-simple-perl 3.04-1 Perl framework for parsing files i ii libsvn-mirror-perl 0.73-1 A subversion repository mirroring ii libsvn-simple-perl 0.27-2 A simple interface for writing a d ii libterm-readkey-perl2.30-3 A perl module for simple terminal ii libuniversal-require-perl 0.10-1 Load modules from a variable ii liburi-perl 1.35-2 Manipulates and accesses URI strin ii libversion-perl 1:0.7203-1 Perl extension for Version Objects ii libyaml-syck-perl 0.71-1 Fast, lightweight YAML loader and ii perl5.8.8-7 Larry Wall's Practical Extraction ii perl-modules [libfile-temp- 5.8.8-7 Core Perl modules ii subversion 1.4.2dfsg1-2 Advanced version control system svk recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425626: gnatcheck not available in the package 'asis-programs'
Santiago, Thank you for the problem report. After investigation, I see that gnatcheck appeared in ASIS 2006, which I initially packaged for Debian. Unfortunately, it turned out not to work with GCC 4.1 (exceptions at run time). I then reverted to ASIS 2005, which does not include gnatcheck, and I forgot to update the package description. It is my intention to package GCC 4.2 along with either ASIS 2006 or ASIS 2007. These newer versions will include gnatcheck. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430005: svk: svk depotmap --relocate does not move the contents of the repository
reopen 430005 thanks >> As illustrated below, svk fails to move the contents of a repository >> even when explicitly asked to do so, using depotmap --relocate: > > It is not documented that relocate implies move. Why should it? Because in English, "relocate" is a synonym for "move". Because it makes no sense to change ~/.svk/config (which "svk depotmap --relocate" does) without also moving the repository. Because the current behaviour creates a dangling link from ~/.svk/config to an empty, or nonexistent, directory. svk fails the Law of Least Astonishment: this is a bug. If that's intentional, that should be documented: this would be a documentation bug. I find your attitude of ignoring the problem, or refusing to admit there is a problem, insulting. Since you appear to have time available for bug triaging, why don't you just forward this bug upstream? Thank you. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430003: closed by Bastian Blank <[EMAIL PROTECTED]> (Re: Bug#430003: svk: Refuses to create a new repository in arbitrary directory)
reopen 430003 thanks > On Thu, Jun 21, 2007 at 06:41:03PM +0200, Ludovic Brenta wrote: >> $ rm -rf $HOME/.svk >> $ svk depotmap --init '' /var/lib/svk >> Repository /home/lbrenta/.svk/local does not exist, create? (y/n) > > It is not documented that --init takes two arguments and works this way. Then there is still a bug: svk should not do anything but issue an error message stating that there are extra arguments on the command line. Currently, it accepts the extra arguments but does something unexpected, thereby failing the Law of Least Astonishment. Furthermore, there appears to be no way to create a depot in a user-specified directory. Would you like me to file a new (wishlist) bug for this? BTW, this missing functionality also fails the Law of Least Astonishment, since, if there is no way to create a depot anywhere but ~/.svk/local, why does the command accept a /path/to/repository at all? I find your attitude of ignoring the problem, or refusing to admit there is a problem, insulting. Since you appear to have time available for bug triaging, why don't you just forward this bug upstream? Thank you. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421140: NMU prep
Kees Cook <[EMAIL PROTECTED]> writes: > Tags: patch > > Hi! Attached is the NMU I'd like to upload shortly. Approved. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427107: gnat-4.1: Bug box, Assert_Failure at einfo.adb:846, renaming predefined "=" and "/="
Package: gnat-4.1 Version: 4.1.1-22 Severity: normal package Pak1 is type T1 is tagged null record; function Eq(X, Y : T1) return Boolean renames "="; function Neq(X, Y : T1) return Boolean renames "/="; -- line 4 end Pak1; gnatmake pak1 yields gnatmake pak1 gcc-4.1 -c pak1.ads +===GNAT BUG DETECTED==+ | 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) (x86_64-pc-linux-gnu) | | Assert_Failure einfo.adb:846 | | Error detected at pak1.ads:4:43 | The token that triggers the bug box is the "renames" in line 4. Here is a second test case that triggers the same bug box: package Pak1 is type T1 is tagged null record; function Eq (X, Y : T1) return Boolean renames "="; type T2 is new T1 with null record; function Eq (X, Y : T2) return Boolean renames "="; -- line 6 end Pak1; gnatmake pak1 gcc-4.1 -c pak1.ads +===GNAT BUG DETECTED==+ | 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) (x86_64-pc-linux-gnu) | | Assert_Failure einfo.adb:846 | | Error detected at pak1.ads:6:43 | The token that triggers this bug box is, again, the "renames" in line 6. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnat-4.1 depends on: ii gcc-4.1 4.1.1-21 The GNU C compiler ii gnat-4.1-base 4.1.1-22 The GNU Compiler Collection (gnat ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libc6-dev 2.3.6.ds1-13 GNU C Library: Development Librari ii libgcc1 1:4.1.1-21 GCC support library ii libgnat-4.1 4.1.1-22 Runtime library for GNU Ada applic ii libgnatprj4.1 4.1.1-22 GNU Ada Project Manager ii libgnatvsn4.1 4.1.1-22 GNU Ada compiler version library gnat-4.1 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427108: gnat-4.1: Legal program executes incorrectly, RM 3.4(27)
Package: gnat-4.1
Version: 4.1.1-22
Severity: normal
The following program prints FAILED; it should print PASSED
as per RM 3.4(27), which states:
-- "For the execution of a call on an inherited subprogram,
-- a call on the corresponding primitive subprogram of the
-- parent or progenitor type is performed; the normal conversion
-- of each actual parameter to the subtype of the corresponding
-- formal parameter (see 6.4.1) performs any necessary type
-- conversion as well."
with Text_IO; use Text_IO;
procedure Test1 is
package Pak1 is
type T1 is tagged null record;
function Eq(X, Y: T1) return Boolean renames "=";
end Pak1;
package Pak2 is
type T2 is new Pak1.T1 with record
F1: Integer;
end record;
end Pak2;
Z1: Pak2.T2 := (F1 => 1);
Z2: Pak2.T2 := (F1 => 2);
begin
if Pak2.Eq(Z1, Z2) = Pak1.Eq(Pak1.T1(Z1), Pak1.T1(Z2))
then Put_Line("PASSED");
else Put_Line("FAILED");
end if;
end Test1;
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.18-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages gnat-4.1 depends on:
ii gcc-4.1 4.1.1-21 The GNU C compiler
ii gnat-4.1-base 4.1.1-22 The GNU Compiler Collection
(gnat
ii libc6 2.3.6.ds1-13 GNU C Library: Shared
libraries
ii libc6-dev 2.3.6.ds1-13 GNU C Library: Development
Librari
ii libgcc1 1:4.1.1-21 GCC support library
ii libgnat-4.1 4.1.1-22 Runtime library for GNU Ada
applic
ii libgnatprj4.1 4.1.1-22 GNU Ada Project Manager
ii libgnatvsn4.1 4.1.1-22 GNU Ada compiler version
library
gnat-4.1 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#380587: libgtkada2: FTBFS: missing case value: "None"
tags 380587 pending thanks Now that the buildds have picked up Packages-arch-specific, I am almost ready to upload libgtkada2 2.8.1, which fixes this bug. I'll do asis, libxmlada2 and libaws first, though. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382049: RM: libxmlada1 -- RoM, superseded by libxmlada2, RC-buggy
Package: ftp.debian.org Severity: normal Please remove libxmlada1 from the archive; I don't have the manpower to maintain it in parallel with libxmlada2, and there is insufficient demand to warrant the effort anyway. libxmlada1 FTBFS due to gnat 3.15p being removed from the archive (#378728), and has bashisms in debian/rules (#372771). Superseded by libxmlada2, which switches the license to the pure GPL (libxmlada1 had an exception allowing proprietary software to be linked with it). libxmlada2 is already in testing. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
