Bug#507536: Missing dependency
severity 507536 important tags 507536 unreproducible thanks On Sun, Feb 08, 2009 at 11:54:35AM +0100, Torsten Werner wrote: Can you reproduce the bug on a clean Debian installation? If not - please downgrade the severity to a sane value. Alright, it is not reproducible in a clean lenny chroot and it works without the missing dependency. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#499036: New release no longer works
tags 499036 patch
thanks
Attached is a NMUdiff to fix a Debian-specific patch which has not
been checked before release by the maintainer.
I will upload a NMU if the maintainer does not react under one day.
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Debian Developer
`- Unix Sys Net Admin
diff -u vtun-3.0.2/debian/changelog vtun-3.0.2/debian/changelog
--- vtun-3.0.2/debian/changelog
+++ vtun-3.0.2/debian/changelog
@@ -1,3 +1,10 @@
+vtun (3.0.2-1.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Fix openpty() wrong usage. (Closes: #499036)
+
+ -- Aurélien GÉRÔME a...@debian.org Tue, 13 Jan 2009 19:32:10 +0100
+
vtun (3.0.2-1) unstable; urgency=low
* New upstream release, fixes incompatibilities with older clients.
diff -u vtun-3.0.2/debian/patches/05-unix98pty.patch
vtun-3.0.2/debian/patches/05-unix98pty.patch
--- vtun-3.0.2/debian/patches/05-unix98pty.patch
+++ vtun-3.0.2/debian/patches/05-unix98pty.patch
@@ -4,10 +4,10 @@
DP: Patch to allow the use of unix 98 pts
-Index: vtun/generic/pty_dev.c
+Index: vtun-3.0.2/generic/pty_dev.c
===
vtun.orig/generic/pty_dev.c
-+++ vtun/generic/pty_dev.c
+--- vtun-3.0.2.orig/generic/pty_dev.c 2009-01-13 19:36:05.0 +0100
vtun-3.0.2/generic/pty_dev.c 2009-01-13 19:36:27.0 +0100
@@ -31,6 +31,8 @@
#include string.h
#include syslog.h
@@ -17,16 +17,18 @@
#include vtun.h
#include lib.h
-@@ -57,31 +59,29 @@ int pty_open(char *sl_name)
+@@ -57,31 +59,29 @@
#else
-char ptyname[] = /dev/ptyXY;
-char ch[] = pqrstuvwxyz;
-char digit[] = 0123456789abcdefghijklmnopqrstuv;
-+char *ptyname;
++char ptyname[1024];
int l, m;
+int master, slave;
++
++/* This algorithm works for UNIX98 PTS */
-/* This algorithm should work for almost all standard Unices */
-for(l=0; ch[l]; l++ ) {
@@ -36,8 +38,6 @@
- /* Open the master */
- if( (mr_fd=open(ptyname, O_RDWR)) 0 )
- continue;
-+/* This algorithm works for UNIX98 PTS */
-+
+/* Open the master */
+mr_fd = openpty(master, slave, ptyname, NULL, NULL);
+if (mr_fd == -1)
@@ -66,10 +66,10 @@
#endif
}
-Index: vtun/Makefile.in
+Index: vtun-3.0.2/Makefile.in
===
vtun.orig/Makefile.in
-+++ vtun/Makefile.in
+--- vtun-3.0.2.orig/Makefile.in2009-01-13 19:36:05.0 +0100
vtun-3.0.2/Makefile.in 2009-01-13 19:36:05.0 +0100
@@ -19,7 +19,7 @@
#
CC = @CC@
signature.asc
Description: Digital signature
Bug#499036: New release no longer works
tags 499036 pending thanks On Tue, Jan 13, 2009 at 07:51:16PM +0100, Aurélien GÉRÔME wrote: I will upload a NMU if the maintainer does not react under one day. Actually, I uploaded it in DELAYED/1-day not to forget later. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#504747: gnu-fdisk: wipes out MBR when used on GPT partitions
On Wed, Dec 03, 2008 at 10:04:13PM +1100, Mark Purcell wrote: Are you in a position to comment on this report, are you able to reproduce, have you been able to discuss with upstream? Upstream is MIA. It is up to the Release Team to decide whether gnu-fdisk is suitable for release or not. I do not have time to argue. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#504099: gnu-fdisk: fails to display GPT partition properly
severity 504099 important thanks Hi, On Fri, Oct 31, 2008 at 09:45:57PM +0900, Osamu Aoki wrote: It may cause data loss due to wrong imprssion this software gives and freitend user may do funny thing. data loss is grave bug You use the verb may, hence you have no valid claim of a security bug. Please show some proof, instead of writing down hypotheses. Based on this observation, I am filing this as RC bug to keep this away from lenny release. I disagree, this is indeed an important bug, but it does no harm as you present it. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#493138: Compiler caught SIGSEGV on provided example code
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5cc2f56000
fstat(3, {st_mode=S_IFREG|0644, st_size=9024, ...}) = 0
lseek(3, 8192, SEEK_SET)= 8192
read(3, pen;\n2.to (cmds.upper) d..., 832) = 832
lseek(3, 0, SEEK_SET) = 0
read(3, ..., 8192) = 8192
read(3, pen;\n2.to (cmds.upper) d..., 4096) = 832
close(3)= 0
munmap(0x7f5cc2f56000, 4096)= 0
open(./object.li, O_RDONLY) = -1 ENOENT (No such file or directory)
open(/usr/share/lisaac/lib/base/object.li, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/usr/share/lisaac/lib/base/low_level/object.li, O_RDONLY) = -1 ENOENT
(No such file or directory)
open(/usr/share/lisaac/lib/collection/object.li, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/share/lisaac/lib/collection/low_level/object.li, O_RDONLY) = -1
ENOENT (No such file or directory)
open(/usr/share/lisaac/lib/file_system/object.li, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/share/lisaac/lib/format/object.li, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/usr/share/lisaac/lib/format/ai/object.li, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/share/lisaac/lib/format/bmp/object.li, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/share/lisaac/lib/graphics/object.li, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/usr/share/lisaac/lib/graphics/low_level/object.li, O_RDONLY) = -1
ENOENT (No such file or directory)
open(/usr/share/lisaac/lib/gui/object.li, O_RDONLY) = -1 ENOENT (No such file
or directory)
open(/usr/share/lisaac/lib/gui/clipping/object.li, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/share/lisaac/lib/gui/event/object.li, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/share/lisaac/lib/gui/input/object.li, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/share/lisaac/lib/gui/low_level/object.li, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/share/lisaac/lib/io/object.li, O_RDONLY) = -1 ENOENT (No such file
or directory)
open(/usr/share/lisaac/lib/kernel/object.li, O_RDONLY) = 3
close(3)= 0
open(/usr/share/lisaac/lib/kernel/object.li, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=5318, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5cc2f56000
fstat(3, {st_mode=S_IFREG|0644, st_size=5318, ...}) = 0
lseek(3, 4096, SEEK_SET)= 4096
read(3, ;\n result := CONVERT[POINTE..., 1222) = 1222
lseek(3, 0, SEEK_SET) = 0
read(3, ..., 4096) = 4096
read(3, ;\n result := CONVERT[POINTE..., 4096) = 1222
close(3)= 0
munmap(0x7f5cc2f56000, 4096)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 5453 detached
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Debian Developer
`- Unix Sys Net Admin
signature.asc
Description: Digital signature
Bug#493138: RM: lisaac [alpha amd64 ia64] -- RoM; ANAIS
Package: ftp.debian.org Hi, The package lisaac has RC Bug#493138 affecting 64-bit architectures. Please remove the Lenny binaries for alpha, amd64, and ia64. Xavier Oswald, one of the upstream maintainers, agrees with it. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#493138: Bug#493141 closed by Debian Archive Maintenance [EMAIL PROTECTED] (Bug#493141: fixed)
severity 493138 important thanks On Thu, Jul 31, 2008 at 06:30:12PM +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the ftp.debian.org package: #493141: RM: lisaac [alpha amd64 ia64] -- RoM; ANAIS It has been closed by Debian Archive Maintenance [EMAIL PROTECTED]. We believe that the bug you reported is now fixed; the following package(s) have been removed from unstable: lisaac | 1:0.13.1-1 | alpha, amd64, ia64 Now downgrading this bug, as it is no longer RC for Lenny. The next upload of the current upstream release should purposely FTBFS on those architectures. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#486829: [pkg-wine-party] Bug#486829: wine: uses dpkg, which is mode 750
severity 486829 important thanks On Thu, Jun 19, 2008 at 09:36:07PM +0200, Pascal A. Dupuis wrote: A searched on 3 machines and found this behaviour only on the one where the installation was performed the longuest time ago, i.e. around 2002. My guess is that this behaviour was introduced by a previous incarnation of harden (woody/sarge), and the old setting persisted upon updates. It should be verified that _ACTUAL_ packages still introduce the behaviour. If there are none, then this bug is void. Thanks, let's see what the maintainer of harden says about it; downgrading the severity in the mean time... Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#474883:
Hi, On Thu, Jun 12, 2008 at 07:09:08PM +0200, PICCA Frédéric-Emmanuel wrote: what is the status of this bug ? It would be cool to have tcc in lenny. do you think that the patch solved this RC bug ? If yes can you upload a new package to help the testing transition. Thomas is currently working on a new upstream release which fixes this bug among others. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#446343: cutter: does not work at all
Hi, On Thu, Dec 06, 2007 at 09:26:43AM +, Chris Davies wrote: On Fri, Oct 12, 2007 at 11:13:44AM +0100, Chris Davies wrote: Cutter does not work as described; it always reports No matching connections found. Here is a repeatable example [...] Aurélien GÉRÔME wrote: I am not able to reproduce it. Does cutter still behave like this if you try it now? I have just reconfirmed that it still does not work for me. (This is running it as root.). I have cutter package 1.03-2 installed from testing, and kernels 2.6.18 (custom build) and 2.6.22-3-686 (debian). I've checked cutter on a transit firewall and also on an end-point. It does not work for me in either situation (No matching connections found). Thanks to this bug, cutter got blindly removed from testing, and I still _cannot_ reproduce it. It would ne nice to get some recipe to reproduce it, if we ever want it to be released with Lenny. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Maintainer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#446343: cutter: does not work at all
On Mon, Feb 11, 2008 at 10:10:18AM +0100, Aurélien GÉRÔME wrote: Thanks to this bug, cutter got blindly removed from testing, and I still _cannot_ reproduce it. It would ne nice to get some recipe to reproduce it, if we ever want it to be released with Lenny. ^ cutter, I meant -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Maintainer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#450446: NMUs
Hi, As part of the NM process, my AM uploaded my NMUs to the archive after the 7-day period. I will subscribe to the PTS for 60 days just in case something goes wrong. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#446343: cutter: does not work at all
Hi, On Fri, Oct 12, 2007 at 11:13:44AM +0100, Chris Davies wrote: Cutter does not work as described; it always reports No matching connections found. Here is a repeatable example: netstat -an | grep 'ESTABLISHED' tcp0 0 192.168.130.5:38101 10.1.30.129:22 ESTABLISHED tcp0 0 192.168.130.5:38819 10.1.30.129:993ESTABLISHED cutter 192.168.130.5 38101 10.1.30.129 22 No matching connections found cutter 192.168.130.5 38101 10.1.30.129 No matching connections found cutter 192.168.130.5 38101 No matching connections found cutter 10.1.30.129 22 192.168.130.5 38101 No matching connections found cutter 10.1.30.129 22 192.168.130.5 No matching connections found cutter 10.1.30.129 22 No matching connections found I am not able to reproduce it. Does cutter still behave like this if you try it now? Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#446343: cutter: does not work at all
On Sun, Dec 02, 2007 at 02:02:44PM +0100, Aurélien GÉRÔME wrote: I am not able to reproduce it. Does cutter still behave like this if you try it now? Also, did you run it as root? Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#451417: NMU diff + patch
tags 451417 patch thanks Hi, Here is a patch to fix this bug, it is under the form of a ready-to-upload NMU. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin diff -ruN etherboot-5.4.2.orig/debian/changelog etherboot-5.4.2/debian/changelog --- etherboot-5.4.2.orig/debian/changelog 2007-12-02 01:12:22.0 +0100 +++ etherboot-5.4.2/debian/changelog 2007-12-02 01:27:59.0 +0100 @@ -1,3 +1,11 @@ +etherboot (5.4.2-1.2) unstable; urgency=low + + * NMU + * Fix FTBFS on amd64: add missing build-dependency on gcc-multilib. +(Closes: #451417) + + -- Aurélien GÉRÔME [EMAIL PROTECTED] Sun, 02 Dec 2007 01:27:10 +0100 + etherboot (5.4.2-1.1) unstable; urgency=low * NMU diff -ruN etherboot-5.4.2.orig/debian/control etherboot-5.4.2/debian/control --- etherboot-5.4.2.orig/debian/control 2007-12-02 01:12:22.0 +0100 +++ etherboot-5.4.2/debian/control 2007-12-02 01:12:53.0 +0100 @@ -2,7 +2,7 @@ Section: admin Priority: optional Maintainer: RISKO Gergely [EMAIL PROTECTED] -Build-Depends: debhelper ( 4.0.0), mkisofs, mtools, syslinux, libc6-dev-i386 [amd64], grub +Build-Depends: debhelper ( 4.0.0), mkisofs, mtools, syslinux, libc6-dev-i386 [amd64], grub, gcc-multilib [amd64] Standards-Version: 3.7.2.0 Package: etherboot signature.asc Description: Digital signature
Bug#450446: NMU diff + patch
tags 450446 patch thanks Hi, Here is a patch to fix this bug, it is under the form of a ready-to-upload NMU. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin diff -ruN extipl-5.04.orig/debian/changelog extipl-5.04/debian/changelog --- extipl-5.04.orig/debian/changelog 2007-12-02 01:57:32.0 +0100 +++ extipl-5.04/debian/changelog 2007-12-02 01:55:44.991797780 +0100 @@ -1,3 +1,11 @@ +extipl (5.04-2.2) unstable; urgency=low + + * NMU + * Fix FTBFS on i386: crc32 is nowadays a nasm keyword, rename it +to crc32_. (Closes: #450446) + + -- Aurélien GÉRÔME [EMAIL PROTECTED] Sun, 02 Dec 2007 01:52:48 +0100 + extipl (5.04-2.1) unstable; urgency=medium * Non-maintainer upload. diff -ruN extipl-5.04.orig/src/castor.asm extipl-5.04/src/castor.asm --- extipl-5.04.orig/src/castor.asm 2002-03-25 14:48:52.0 +0100 +++ extipl-5.04/src/castor.asm 2007-12-02 01:56:29.760221334 +0100 @@ -2233,7 +2233,7 @@ mov cx,16 ;; 8 + 8 pop si pop di - jmp short crc32 + jmp short crc32_ labelbuf_crc: mov bx,label_buff mov cx,label_buffln @@ -2244,7 +2244,7 @@ ;; Enter: cx = length ;; bx = buffer address ;; Return: dx.ax = crc32 -crc32: push si +crc32_: push si mov si,bx mov bx,0x ; res.lo mov dx,bx ; res.hi signature.asc Description: Digital signature
Bug#434150: NMU diff + patch
tags 434150 patch thanks Hi, Here is a patch to fix this bug, it is under the form of a ready-to-upload NMU. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin diff -ruN recoverjpeg-1.1.1.orig/debian/changelog recoverjpeg-1.1.1/debian/changelog --- recoverjpeg-1.1.1.orig/debian/changelog 2007-12-02 02:02:31.0 +0100 +++ recoverjpeg-1.1.1/debian/changelog 2007-12-02 02:05:03.298750418 +0100 @@ -1,3 +1,9 @@ +recoverjpeg (1.1.1-1.1) unstable; urgency=low + + * Fix license issue: recoverjpeg is GPLv2 only. (Closes: #434150) + + -- Aurélien GÉRÔME [EMAIL PROTECTED] Sun, 02 Dec 2007 02:04:02 +0100 + recoverjpeg (1.1.1-1) unstable; urgency=low * New upstream release diff -ruN recoverjpeg-1.1.1.orig/debian/copyright recoverjpeg-1.1.1/debian/copyright --- recoverjpeg-1.1.1.orig/debian/copyright 2007-12-02 02:02:31.0 +0100 +++ recoverjpeg-1.1.1/debian/copyright 2007-12-02 02:03:24.207239888 +0100 @@ -11,8 +11,7 @@ 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 of the License, or (at -your option) any later version. +the Free Software Foundation; version 2 of the License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of signature.asc Description: Digital signature
Bug#452461: Scilab provides architecture specific binaries in all package
Hi, On Fri, Nov 23, 2007 at 01:20:54AM +, Thiemo Seufer wrote: The scilab_4.1.1-2_all.deb provides x86 binaries in /usr/lib/scilab-4.1.2/macros/. The build system in that place suggests the package should provide no binaries at all, as they are supposed to get built at install time or later. Torsten, Martin, how come both of you DDs missed that? Anyway, Torsten, do not hesitate to ping me as your devoted co-maintainer to double-check the package beforehand. :] On a side note, I think that it would be wise to switch from debhelper to cdbs for a package as complex as scilab. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#452461: Scilab provides architecture specific binaries in all package
Hi Torsten, On Sat, Nov 24, 2007 at 05:35:30PM +0100, Torsten Werner wrote: On Nov 24, 2007 5:14 PM, Aurélien GÉRÔME [EMAIL PROTECTED] wrote: Torsten, Martin, how come both of you DDs missed that? the bug is old and already present in lenny and you are mentioned in the changelog for the lenny version, too. Blame yourself. ;-) It is Damn, if this is the case, I am really ashamed. :] *not* a regression introduced by Martin's upload. Sylvestre promised I know for sure that there is a lot of lintian warnings (errors even, as I remember) for scilab. I think it might be worthy to fix them for Lenny. I will proceed to this as soon as I can. to fix it for the next version and the user of the package is not affected by the bug if I have unterstood the problem correctly. But I may be wrong. Can someone enlighten me? Probably, if I understand correctly, these are optional modules which may be loaded at runtime; I have not checked yet... Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#385914: workaround
On Tue, Nov 13, 2007 at 06:26:45PM -0800, Max Alekseyev wrote: A simple workaround is to install Ubuntu pdftk package (which depends on libgcj8-1) from Or rather being constructive, instead of whining and ranting, by finding a DD willing to sponsor my up-to-date package. Thanks, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#438479: version 1.0 released
Hi Marc, On Fri, Aug 17, 2007 at 12:01:58PM +0200, Marc Leeman wrote: The version that is currently in experimental is not usable anymore with newer kernels (too old) and last week version 1.0 was tagged. This might be a better point to start than a git snapshot. Indeed, thanks for the info and agreed on the severity. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#421341: FTBFS: Something wrong with gcjh/classpath/something
unblock 421341 by 421301 tags 421341 patch clone 421341 -1 retitle -1 Linking failure at runtime, ABI mismatch between libgcj7-1 and libstdc++6 tags -1 = sid thanks On Sat, Apr 28, 2007 at 08:21:36PM +0200, Aurélien GÉRÔME wrote: I noticed that gcj-4.1 is currently broken in Sid. Please see Bug#421301 for reference. Sorry, it was a mistake from my part, there is absolutely no relation with Bug#421301 whatsoever; stupid me. Besides, I fixed our current Bug#421341. Previously, pdftk used gcj-4.1 (4.1.1) currently in Lenny, but gcj-4.1 (4.1.2) recently got into Sid. It seems that the behaviour of gcjh changed from 4.1.1 to 4.1.2, so I fixed the makefiles accordingly. The patch which I will use in the next upload is attached. Also, I will surely clean it up a bit, as I have to upload a new upstream release anyway. Unfortunately, even though pdftk now builds fine, it crashes at runtime. $ pdftk libgcj failure: gcj linkage error. Incorrect library ABI version detected. Aborting. The resulting pdftk binary is linked against: * libgcj.so.71 from the binary package libgcj7-1 coming from the source package gcj-4.1 (4.1.2); * libstdc++.so.6 from the binary package libstdc++6 coming from the source package gcc-4.2. It seems that libgcj.so.71 does not agree to be linked with such libstdc++.so.6. It is apparently due to an ABI mismatch between libgcj.so.71 and libstdc++.so.6. Please see [1] for reference. Cheers, [1] http://gcc.gnu.org/ml/java-patches/2007-q1/msg00168.html -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin --- pdftk-1.40.orig/pdftk/Makefile.Debian +++ pdftk-1.40/pdftk/Makefile.Debian @@ -23,7 +23,7 @@ # if you want pdftk to ask before overwriting a file, set # ASK_ABOUT_WARNINGS to true; otherwise: false; override this default # with the dont_ask or do_ask command-line options -CPPFLAGS= -O3 -DPATH_DELIM=0x2f -DASK_ABOUT_WARNINGS=false -fdollars-in-identifiers +CPPFLAGS= -w -O3 -DPATH_DELIM=0x2f -DASK_ABOUT_WARNINGS=false -fdollars-in-identifiers CXXFLAGS= -lgcj # itext compiler flags --- pdftk-1.40.orig/java_libs/gnu/gcj/convert/Makefile +++ pdftk-1.40/java_libs/gnu/gcj/convert/Makefile @@ -25,8 +25,8 @@ # the $* automatic variable, here # %.h : %.class - $(GCJH) --classpath=. $*; - $(RM) $ + $(GCJH) --classpath=/usr/share/java/libgcj-4.1.jar:$(PWD):. $* +# $(RM) $ ## # targets --- pdftk-1.40.orig/java_libs/java_local/security/Makefile +++ pdftk-1.40/java_libs/java_local/security/Makefile @@ -25,8 +25,8 @@ # the $* automatic variable, here # %.h : %.class - $(GCJH) --classpath=. $*; - $(RM) $ + $(GCJH) --classpath=/usr/share/java/libgcj-4.1.jar:$(PWD):. $* +# $(RM) $ ## # targets --- pdftk-1.40.orig/java_libs/gnu_local/java/security/provider/Makefile +++ pdftk-1.40/java_libs/gnu_local/java/security/provider/Makefile @@ -25,8 +25,8 @@ # the $* automatic variable, here # %.h : %.class - $(GCJH) --classpath=. $*; - $(RM) $ + $(GCJH) --classpath=/usr/share/java/libgcj-4.1.jar:$(PWD):. $* +# $(RM) $ ## # targets --- pdftk-1.40.orig/java_libs/gnu_local/java/security/Makefile +++ pdftk-1.40/java_libs/gnu_local/java/security/Makefile @@ -25,8 +25,8 @@ # the $* automatic variable, here # %.h : %.class - $(GCJH) --classpath=. $*; - $(RM) $ + $(GCJH) --classpath=/usr/share/java/libgcj-4.1.jar:$(PWD):. $* +# $(RM) $ ## # targets --- pdftk-1.40.orig/java_libs/com/lowagie/text/xml/xmp/Makefile +++ pdftk-1.40/java_libs/com/lowagie/text/xml/xmp/Makefile @@ -25,8 +25,8 @@ # the $* automatic variable, here # %.h : %.class - $(GCJH) --classpath=. $*; - $(RM) $ + $(GCJH) --classpath=/usr/share/java/libgcj-4.1.jar:$(PWD):. $* +# $(RM) $ ## # targets --- pdftk-1.40.orig/java_libs/com/lowagie/text/pdf/Makefile +++ pdftk-1.40/java_libs/com/lowagie/text/pdf/Makefile @@ -25,8 +25,8 @@ # the $* automatic variable, here # %.h : %.class - $(GCJH) --classpath=. $*; - $(RM) $ + $(GCJH) --classpath=/usr/share/java/libgcj-4.1.jar:$(PWD):. $* +# $(RM) $ ## # targets --- pdftk-1.40.orig/java_libs/com/lowagie/text/pdf/fonts/Makefile +++ pdftk-1.40/java_libs/com/lowagie/text/pdf/fonts/Makefile @@ -34,8 +34,8 @@ # the $* automatic variable, here # %.h : %.class - $(GCJH) --classpath=. $*; - $(RM) $ + $(GCJH) --classpath=/usr/share/java/libgcj-4.1.jar:$(PWD):. $* +# $(RM) $ ## # targets --- pdftk-1.40.orig/java_libs/com/lowagie/text/pdf/codec/postscript/Makefile +++ pdftk-1.40/java_libs/com/lowagie/text/pdf/codec/postscript/Makefile @@ -25,8 +25,8 @@ # the $* automatic variable, here # %.h : %.class - $(GCJH) --classpath=. $*; - $(RM) $ + $(GCJH) --classpath=/usr/share/java/libgcj-4.1.jar:$(PWD):. $* +# $(RM) $ ## # targets --- pdftk-1.40.orig/java_libs/com/lowagie/text/pdf/codec/wmf/Makefile +++ pdftk-1.40/java_libs/com
Bug#421341: FTBFS: Something wrong with gcjh/classpath/something
tags 421341 sid thanks Hi Sami, On Sat, Apr 28, 2007 at 07:39:45AM +0300, Sami Liedes wrote: Package: pdftk Version: 1.40-2 Severity: serious Justification: no longer builds from source I don't know whose bug this is, pdftk's (by possibly setting wrong classpath? I don't know) or gcj's or what, but anyway, for me pdftk doesn't build: OK, I will take a look in some hours... Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#421341: FTBFS: Something wrong with gcjh/classpath/something
tags 421341 confirmed thanks It is fully reproducible on powerpc with the same output. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#421341: FTBFS: Something wrong with gcjh/classpath/something
block 421341 by 421301 thanks On Sat, Apr 28, 2007 at 12:07:00PM +0200, Aurélien GÉRÔME wrote: It is fully reproducible on powerpc with the same output. I noticed that gcj-4.1 is currently broken in Sid. Please see Bug#421301 for reference. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#394404: Unreproducible
Hi, On Tue, Mar 13, 2007 at 11:46:08PM +0100, Marc 'HE' Brockschmidt wrote: I haven't been able to reproduce this problem *anywhere* and upstream hasn't seen a report about a problem like this. I'll probably do another gstreamer-perl upload to get more verbose output from this test, but the test suite helpers in perl are really not helping when it comes to get verbose error messages :-/ The powerpc buildds are running 2.4 kernels and it appears that this is what triggers that ominous bug. If they are upgraded to 2.6 kernels, then the package should build fine. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#412451: Package unusable
On Sat, Mar 17, 2007 at 02:30:46PM +0300, Wartan Hachaturow wrote: On 3/17/07, Aurélien GÉRÔME [EMAIL PROTECTED] wrote: I came upon this while wanting to try qgit and really felt frustrated. To my mind, our users deserve better. I can prepare a NMU if you do not have the time to deal with it, just let me know... Sure they do. I'll upload 1.5.5 today. Thanks Wartan! :) Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#394404: Unreproducible
Hi Steve, On Mon, Mar 12, 2007 at 12:24:49PM -0700, Steve Langasek wrote: On Mon, Mar 12, 2007 at 01:32:24PM +0100, Aurélien GÉRÔME wrote: While building your package in an up-to-date proc-mounted chroot, everything went smoothly. Therefore, I am asking for a requeueing on w-b powerpc... And it failed again on the buildd. Indeed. Which means someone needs to break this down to show what the testsuite failure is and why it fails. As I really cannot reproduce it on several PowerPC subarchitectures which I have access to, is it possible to get more information about the buildd setup? I am not a DD yet, so I cannot access the official buildd machine. However, perhaps if the PowerPC DD porter had access to the buildd, he would be able run tests to search the failure... In the mean time, I propose to let the PowerPC DD porter performs a porter upload of the _powerpc.deb. Is that satisfactory? It seems allowed by the section 5.10.2 of the developers-reference which I worked hard on to pass the PP check of the NM process. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#382658: Unusable on a release architecture is RC
Hi Joachim, On Fri, Jan 19, 2007 at 11:35:19PM +, Joachim Breitner wrote: Am Samstag, den 20.01.2007, 00:07 +0100 schrieb Aurélien GÉRÔME: The powerpc package is unusable, so this bug is RC. To lower the severity to important, you can ask for the removal of the powerpc deb from the archive and restrict the build of xaralx to some architectures where the package is known to work on. Please do not take this is as an offense, this is not meant to be. :) I don’t have a powerpc box around to test this. I could do as you said and have only i386 included, but I actually feel like just having xaralx removed from testing anyways: It was not completely free’ed as promised and xaralx is not important enough to increase the non-free section of etch IMHO. Hopefully xaralx development will pick up again and the core will become free as well. Until then, we maybe should keep it out of testing alltogether, for example with this RC bug :-) Sure. :) Do I need to take action or will xaralx be removed automatically from etch now that is has an RC bug? The package is currently in testing, so you will have to mail debian-release to ask for its removal, or the Release Managers will see this bug and remove the package by themselves. :) Well, you have 2 choices: 1/ You can keep the powerpc deb in unstable with this RC bug. 2/ You can release a package with only i386 and amd64 in the Architecture field and downgrade the severity of this bug. With this, only the known working architectures will enter testing (in non-freeze state). Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#403585: Regression in 2.4.35-1
On Tue, Dec 19, 2006 at 05:57:00PM +1100, Nathan Scott wrote: Hmm, my upload got rejected for some version ... I've sent off some mail to try figure out why. On Tue, 2006-12-19 at 03:02 +, Debian Installer wrote: Rejected: libattr1-dev_2.4.36-1_i386.deb: old version (1:2.4.32-1.1) in unstable = new version (2.4.36-1) targeted at unstable. Rejected: libattr1_2.4.36-1_i386.deb: old version (1:2.4.32-1.1) in unstable = new version (2.4.36-1) targeted at unstable. Rejected: attr_2.4.36-1_i386.deb: old version (1:2.4.32-1.1) in unstable = new version (2.4.36-1) targeted at unstable. Rejected: attr_2.4.36-1.dsc: old version (1:2.4.32-1.1) in unstable = new version (2.4.36-1) targeted at unstable. === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. As reports of broken sid systems rose up, Andreas Barth NMUed your package yesterday in a 0-day NMU policy. He setup an epoch to the package version which IMHO is a bad thing now that we have the possibility of ~ in version strings. He could have used 2.4.35~is.2.4.32-0.1 instead of the ugly 1:2.4.32-1.1, because from now on, you are stuck with an epoch in your package versions. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#403585: Regression in 2.4.35-1
Package: libattr1 Version: 2.4.35-1 Severity: serious Justification: make other packages FTBFS There has been a regression on your package since 2.4.32-1. When building gnu-fdisk yesterday for instance, it went fine. However, today with 2.4.35-1, I got: make[3]: Entering directory `/home/ag/build/fdisk-0.9.1/src' test -z /usr/sbin || mkdir -p -- /home/ag/build/fdisk-0.9.1/debian/fdisk/usr/sbin /usr/bin/install -c 'fdisk' '/home/ag/build/fdisk-0.9.1/debian/fdisk/usr/sbin/gnu-fdisk' /usr/bin/install: relocation error: /lib/libacl.so.1: symbol setxattr, version ATTR_1.0 not defined in file libattr.so.1 with link time reference make[3]: *** [install-sbinPROGRAMS] Error 1 Other people reported the same on #debian-devel for other software. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#403585: Regression in 2.4.35-1
clone 403585 -1 reassign -1 libacl1 found -1 2.2.42-1 retitle -1 Regression in 2.2.42-1 thanks On Mon, Dec 18, 2006 at 10:29:54AM +0100, Aurélien GÉRÔME wrote: Package: libattr1 Version: 2.4.35-1 Severity: serious Justification: make other packages FTBFS There has been a regression on your package since 2.4.32-1. The same goes for acl 2.2.41-1. When building gnu-fdisk yesterday for instance, it went fine. However, today with 2.4.35-1, I got: Tried with acl 2.2.42-1. make[3]: Entering directory `/home/ag/build/fdisk-0.9.1/src' test -z /usr/sbin || mkdir -p -- /home/ag/build/fdisk-0.9.1/debian/fdisk/usr/sbin /usr/bin/install -c 'fdisk' '/home/ag/build/fdisk-0.9.1/debian/fdisk/usr/sbin/gnu-fdisk' /usr/bin/install: relocation error: /lib/libacl.so.1: symbol setxattr, version ATTR_1.0 not defined in file libattr.so.1 with link time reference make[3]: *** [install-sbinPROGRAMS] Error 1 Other people reported the same on #debian-devel for other software. Of course, it is up to you to know which package is the cause of this. :) Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#403585: Raise severities
severity 403585 critical severity 403599 critical thanks I did not see that the system was completely broken after installation. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#402736: FTBFS on alpha on both Etch and Sid
retitle 402736 FTBFS on alpha: memory allocation on 64-bit architectures tags 402736 pending thanks On Tue, Dec 12, 2006 at 09:47:06PM +0100, Aurélien GÉRÔME wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 31355)] 0x000120085700 in cresmatvar_ (id=0x11fec55c0, lw=0x11fec558c, str=0x120fbbe9e, lstr=0x11fec5628, __g77_length_str=4096) at inisci.f:427 427 istk(il ) = 10 (gdb) bt #0 0x000120085700 in cresmatvar_ (id=0x11fec55c0, lw=0x11fec558c, str=0x120fbbe9e, lstr=0x11fec5628, __g77_length_str=4096) at inisci.f:427 #1 0x000120084780 in inisci_ (ini1=0x120aaf3b8, vsizr=0x11fec5690, ierr=0x120ab1c5c) at inisci.f:259 #2 0x0001207812c0 in VTRun () #3 0x000120786794 in main_sci () #4 0x000120787018 in realmain_ () #5 0x00012004d720 in MAIN__ () at mainsci.f:4 I should have looked at the Debian patches earlier, because I found the fix. :) On 64-bit architectures, specific memory allocation functions are used in scilab. It is already the case on ia64 and amd64, so I added alpha to that list. This is probably because of some issue with the mix of Fortran and C, though I have not looked in deeper... Okay, so let's go for a rebuild of all architectures and a hint to get scilab into Etch! ;) Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#402736: FTBFS on alpha on both Etch and Sid
Hi Torsten, On Tue, Dec 12, 2006 at 01:07:50PM +0100, Torsten Werner wrote: On 12/12/06, Aurélien GÉRÔME [EMAIL PROTECTED] wrote: Unfortunately, scilab FTBFS on alpha on both Etch and Sid with differents errors. :( may you try to build it with only the Build-Depends installed by using dchroot or pbuilder? This is what I always do and what I did there. Two chroots (Etch and Sid) with /proc mounted. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#402736: FTBFS on alpha on both Etch and Sid
On Tue, Dec 12, 2006 at 02:46:59PM +0100, Sylvestre Ledru wrote: Le mardi 12 décembre 2006 à 12:29 +0100, Aurélien GÉRÔME a écrit : * A first FTBFS occurs in the file ./routines/Javasci/classes/BadDataArgumentException.java interpreted by javac (gcj-wrapper-4.1). This is easily fixed by replacing the accentuated character in the French comment (s/gérer/gerer/). Thanks for this bug report. I translated the comment into english in the upstream but this change won't be taken in account in the version 4.1 of Scilab (which should be released today or tomorrow). I also made this change in the trunk of Scilab. I commited the change also in the debian svn for scilab but I saw here http://packages.qa.debian.org/s/scilab.html Not touching package, as requested by freeze (contact debian-release if update is needed) What should I do ? Indeed, this is not a necessary change in the Debian packaging, because we do not provide the Java interface anyway. Moreover, it seems that this is a gcj bug. I had gcj in my manual build environment, the configure script detected it, and used it. That is why I said earlier that we might consider disabling it manually, instead of relying on automatic detection by the configure script. * A second FTBFS occurs afterwards in the file ./routines/Javasci/javasci_SciStringArray.c, see the attached build log. Java is not mandatory in Scilab. It is used when you need to use the scilab engine from a Java application (this could become a new debian package btw). Scilab compilation complains about the jni.h file. Maybe if you install libgcj4-dev, this may work but I am not sure about that. Yes, this is probably due to wrong headers, thought I did not search deeper when I read Torsten's feedback on it, i.e. we do not use it. :) * A FTBFS occurs via the oom-killer during the use of the freshly built ./bin/scilab binary to generate HTML documentation, see the attached build log. I saw that bug before : http://www.scilab.org/cgi-bin/bugzilla_bug_II/show_bug.cgi?id=1483 I forwarded this error to the Scilab Mailing list. Sure, this is now the real bug which happens on both Etch and Sid on alpha architecture. However, it happens at an early stage in scilab (when you launch it), so it probably has something to do with either wrong compiled code for alpha (it would be a gcc bug) or an architecture-specific quirk. I am currently investigating the issue with gdb... Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#395252: some needed (and long due) clarifications, Re: Bug#395252
On Tue, Dec 12, 2006 at 04:33:58PM +0100, A Mennucc wrote: It is time to really delve into this. I do not think that this bug is serious. (I have actually the feeling that the severity for this bug is wishlist. ) I have the feeling that you want to close it, but well it is only a feeling, so it does not matter... Here are some reasonings: 1) It is true that the debian-policy asks for dynamic compilation, whenever possible; but the MPlayer team deprecate dynamic linking of ffmpeg: dynamic linking is an experimental feature, it breaks many postprocessing options; so it is not really supported. I never said that you *had* to compile mplayer dynamically with ffmpeg. Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=39. The ideal situation is to have the same ffmpeg code base for every packages which use it, be it dynamically or statically. What you are asking for is not a feature currently sported by MPlayer; as such, your request is severity:wishlist. If you want dynamic linking in MPlayer, you are free to work on it until it works flawlessly, and send me a patch. Sure, but I do not really want a dynamically built mplayer. 2) Never AFAIK was there a release goal of all packages must compile with external ffmpeg No, but it is common sense not to embed and duplicate code in a distro, because it is a nightmare for the security team. I believe that I will not be demised on this... 3) You never opened a serious bug against gst-ffmpeg although gst-ffmpeg is linked with an internal static ffmpeg. Josselin Mouette worked on a patch to solve that. It is another matter and as I do not use gstreamer, I lack of interest for it, unlike mplayer which I often use. And I do not think that you are entitled to claim that severity is serious. Snip ad hominem bashing... Okay, then let's ask an official statement from the security team to resolve the issue. Aurélien GÉRÔME wrote: Sure, I got that. Fine, the shame on me is my punishment for having wanted to get a compromise. :) Compromise? I am the guy that does try to find compromises. I am the guy who spent many years to find a compromise to let MPlayer into Debian - in the end, I even agreed to remove mencoder for fear of patent problems, although most of the encoding stuff is in ffmpeg and that is already in Debian. And I commend you for that. Your (repeated) example of compromise is echo severity serious | mail [EMAIL PROTECTED]. repeated? This is a false accusation. The initial serious severity is from me (the submitter), the following serious severity is from Moritz (on the control bot), and the last one is from me (also on the control bot). That last one is what I call the compromise: the compromise of letting mplayer go to testing, but with an etch-ignore-tagged RC bug. However, I was unaware of the authority to wield the etch-ignore tag, since I saw someone who was not RM wield it. Mea culpa. I see nothing to cheer about So do I. -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#402736: FTBFS on alpha on both Etch and Sid
On Tue, Dec 12, 2006 at 03:10:09PM +0100, Aurélien GÉRÔME wrote: Sure, this is now the real bug which happens on both Etch and Sid on alpha architecture. However, it happens at an early stage in scilab (when you launch it), so it probably has something to do with either wrong compiled code for alpha (it would be a gcc bug) or an architecture-specific quirk. I am currently investigating the issue with gdb... Starting program: /home/ag/build/scilab-4.0/bin/scilex [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 17888)] [New Thread 32769 (LWP 17893)] [New Thread 16386 (LWP 17894)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 17888)] 0x000120078cfc in cresmatvar_ () (gdb) bt #0 0x000120078cfc in cresmatvar_ () #1 0x000120078418 in inisci_ () #2 0x0001205771a8 in VTRun () #3 0x00012057c67c in main_sci () #4 0x00012057cf00 in realmain_ () #5 0x00012004d718 in MAIN__ () The bug is located in the Fortran code of ./routines/system/inisci.f, so it must be related to g77 in some way. I searched a bit, but I do not know much about Fortran. Sylvestre, can you be of any help on this? :) Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#402736: FTBFS on alpha on both Etch and Sid
On Tue, Dec 12, 2006 at 08:10:07PM +0100, Aurélien GÉRÔME wrote: Starting program: /home/ag/build/scilab-4.0/bin/scilex [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 17888)] [New Thread 32769 (LWP 17893)] [New Thread 16386 (LWP 17894)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 17888)] 0x000120078cfc in cresmatvar_ () (gdb) bt #0 0x000120078cfc in cresmatvar_ () #1 0x000120078418 in inisci_ () #2 0x0001205771a8 in VTRun () #3 0x00012057c67c in main_sci () #4 0x00012057cf00 in realmain_ () #5 0x00012004d718 in MAIN__ () The bug is located in the Fortran code of ./routines/system/inisci.f, so it must be related to g77 in some way. I searched a bit, but I do not know much about Fortran. Sylvestre, can you be of any help on this? :) I rebuilt scilab with FC_OPTIONS=-g and here is the gdb session with debugging symbols support. (gdb) r Starting program: /home/ag/build/scilab-4.0/bin/scilex [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 31355)] [New Thread 32769 (LWP 31360)] [New Thread 16386 (LWP 31361)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 31355)] 0x000120085700 in cresmatvar_ (id=0x11fec55c0, lw=0x11fec558c, str=0x120fbbe9e, lstr=0x11fec5628, __g77_length_str=4096) at inisci.f:427 427 istk(il ) = 10 (gdb) bt #0 0x000120085700 in cresmatvar_ (id=0x11fec55c0, lw=0x11fec558c, str=0x120fbbe9e, lstr=0x11fec5628, __g77_length_str=4096) at inisci.f:427 #1 0x000120084780 in inisci_ (ini1=0x120aaf3b8, vsizr=0x11fec5690, ierr=0x120ab1c5c) at inisci.f:259 #2 0x0001207812c0 in VTRun () #3 0x000120786794 in main_sci () #4 0x000120787018 in realmain_ () #5 0x00012004d720 in MAIN__ () at mainsci.f:4 Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#395252: editorial change
Hi Andreas, On Mon, Dec 11, 2006 at 10:22:11PM +0100, Andreas Barth wrote: etch-ignore is only to be set by the release team, or upon special authorisation. Thanks. Sure, I got that. Fine, the shame on me is my punishment for having wanted to get a compromise. :) Sorry Andrea, this is really RC (as I always said), but this is also RC for etch (as I was told on #debian-release). Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#390667: Reopening, not fixed
tags 390667 pending notfound 390667 1:7.2.2-2 found 390667 1:7.2.2.dfsg.1-3 thanks Hi Simon, On Wed, Nov 29, 2006 at 10:35:56PM +0100, Simon Josefsson wrote: Hi! I looked at the version 1:7.2.2.dfsg.1-2 package, and it seems the bug have not been fixed. I still see these files in the source package: ircd-hybrid-7.2.2.dfsg.1/doc/technical/rfc1459.txt ircd-hybrid-7.2.2.dfsg.1/doc/technical/rfc2812.txt ircd-hybrid-7.2.2.dfsg.1/doc/technical/rfc2813.txt The contents of the files is the real IETF RFCs, which are not licensed under a free license. Well, in any case, I have been right to setup a dsfg.1 release... ;) You did not mention those files in your initial bug report, you just mentioned [1]. Of course, I will remove them too, but our dear Release Managers will probably tag this bug as etch-ignore. I did not give them the time to do so on this one when you submitted it in the first place. ;P Cheers, [1] /usr/share/doc/ircd-hybrid/technical/draft-mitchell-irc-capabilities-01.txt.gz -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#392649: rtsigio does not work on alpha
tags 46 pending thanks On Mon, Nov 27, 2006 at 02:52:46PM +0100, Aurélien GÉRÔME wrote: On Mon, Nov 27, 2006 at 02:12:28PM +0100, Andreas Barth wrote: * Aurélien GÉRÔME ([EMAIL PROTECTED]) [061104 15:26]: I found a workaround. I will make ircd-hybrid use poll on Linux/Alpha and on all other kernels besides Linux, because rtsigio is Linux-only. When can we expect an upload of that to happen? Today or tomorrow, sorry for the delay. Please refrain from any NMU or testing removal. I am waiting on my sponsor to upload it now... Thanks. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#392649: rtsigio does not work on alpha
Hi Andreas, On Mon, Nov 27, 2006 at 02:12:28PM +0100, Andreas Barth wrote: * Aurélien GÉRÔME ([EMAIL PROTECTED]) [061104 15:26]: I found a workaround. I will make ircd-hybrid use poll on Linux/Alpha and on all other kernels besides Linux, because rtsigio is Linux-only. When can we expect an upload of that to happen? Today or tomorrow, sorry for the delay. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#399922: toilet: doesn't output readable characters
severity 399922 wishlist retitle 399922 toilet does not work on non-unicode systems thanks On Wed, Nov 22, 2006 at 10:18:15PM +0100, Florian Cramer wrote: Justification: renders package unusable Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Please switch your system to UTF-8 and it will work fine. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#398997: Please provide a s390 binary package
Package: vnstat Version: 1.4-4 Severity: serious The source package vnstat is arch-any and it builds fine on s390. Therefore, I see no reason for not providing a s390 binary package. This is a RC bug, because it downgrades the quality of the release for this package. The post [1] asks the porters to queue the package on a s390 auto-builder. Cheers, [1] http://lists.debian.org/debian-s390/2006/11/msg8.html -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#395252: embedded code copies are not RC
On Sun, Nov 05, 2006 at 11:52:48AM +0100, Diego Biurrun wrote: On Sat, Nov 04, 2006 at 12:31:26AM +0100, Aurélien GÉRÔME wrote: This is a false argument. Come one please, do not attempt to tell me that you can decently play a H.264-encoded video on a non-GHz machine even with SIMD instruction-set, I will not believe you. WTF? No need to get on horses. :) I'm an MPlayer developer and my desktop machine is a K6-III 500MHz. It just happens that I *may* know what I'm talking about here ... It just happens that I have a lot of H.264-encoded videos which will *not* run adequately on the hardware you name above. We *may* not have the same videos... Therefore, I maintain my statement, even if you do not agree. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#395252: embedded code copies are not RC
On Sun, Nov 05, 2006 at 03:23:31PM +0100, Diego Biurrun wrote: Sorry if I was sounding aggressive, this was not my intention. I apologise too if you felt hurt by me sounding like you were lying. Anyway, the confusion seems to have been cleared - good. Sure. :) Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#392649: rtsigio does not work on alpha
tags 392649 - help tags 392649 + pending thanks On Thu, Oct 19, 2006 at 11:10:55AM -0700, Steve Langasek wrote: On Thu, Oct 19, 2006 at 12:11:40PM +0200, Aurélien GÉRÔME wrote: Should I reassign it to linux-2.6 source package, because it does not come from ircd-hybrid itself? Not at grave severity, no. Alpha does not implement rt_sigtimedwait would be a medium-severity bug. The grave bug is ircd-hybrid is built on alpha and depends on a syscall that isn't properly implemented, which is a bug of ircd-hybrid that can be fixed in one of three ways: getting the kernel fixed, using some other kernel interface that works on alpha (which obviously isn't epoll either since that's 2.6-only), or dropping alpha from the architecture list for the package and asking the ftpmasters to remove the binaries. Speaking as an alpha porter, I think any of these three are ok here. I found a workaround. I will make ircd-hybrid use poll on Linux/Alpha and on all other kernels besides Linux, because rtsigio is Linux-only. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#394626: closed by Steve Langasek [EMAIL PROTECTED] (Bug#394626: fixed in qdbm 1.8.70-1.1)
On Fri, Nov 03, 2006 at 12:49:35AM -0800, Debian Bug Tracking System wrote: * Use -O0 in CXXFLAGS in plus/Makefile.in instead of -O1, to avoid an ICE when building on alpha. Closes: #394626. I thought people were credited in changelog entries when they provided a patch which was later applied/adapted. I must have been wrong... Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#395252: embedded code copies are not RC
On Fri, Nov 03, 2006 at 11:34:37PM +0100, Diego Biurrun wrote: That benchmark was done on x86. But let's face it, it's the architecture that counts. Mind that I am writing this from a PPC, which is my main machine.. I disagree, amd64 would be the architecture which counts and amd64 has enough registers to cope with PIC code, but I will not fall in the game of what architecture counts, even if for me, it would rather be powerpc anyway. Then, I can agree with you that static linking has better performance. Therefore, what I can recommand is to build mplayer statically, but with a Debian up-to-date ffmpeg package. I am CCing Samuel Hocevar to get his opinion on the matter... I know that distro people dislike static linking, but multimedia players are speed-critical applications. Not everybody has a multi-GHz machine and even on those high definition content takes them to the limit... This is a false argument. Come one please, do not attempt to tell me that you can decently play a H.264-encoded video on a non-GHz machine even with SIMD instruction-set, I will not believe you. Plus I expect random bugs to creep up. As mentioned above FFmpeg is highly volatile and fast-moving. Backwards-compatibility is not a priority. That will *not* happen with an up-to-date ffmpeg package which other packages might benefit from. What I'm afraid of is that such an updated package might not sit well with xine and the other users of FFmpeg. That is why I would like the opinion of Sam on the matter. He told me on IRC that he needed some time to investigate the matter... Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#394626: closed by Steve Langasek [EMAIL PROTECTED] (Bug#394626: fixed in qdbm 1.8.70-1.1)
On Fri, Nov 03, 2006 at 03:03:36PM -0800, Steve Langasek wrote: Sorry, it didn't occur to me that you would feel strongly about being credited here. This doesn't mean that I don't appreciate your work, it just means (in my case) that I didn't use your patch directly, but re-derived it after testing on alpha. FWIW, the maintainer's upload also doesn't appear to credit you; as I don't intend to re-NMU just to fix the crediting, you might ask the maintainer to make this change in his next version. I bear no grudge against you for this. It is just a trivial workaround anyway, the real bug being in gcc (#394630). Also, my wording may have been too strong. I have been told that I am not qualified to even be accepted in NM (not being visible on the BTS for instance), so I was a bit blood-headed when I looked at the changelog entry. :) Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#395252: embedded code copies are not RC
Hi Diego, On Tue, Oct 31, 2006 at 07:46:01PM +0100, Diego Biurrun wrote: Removing the embedded copies of FFmpeg libraries from MPlayer is a bad idea. For the workload on the security team and the overall quality of Debian (a single source package for whatever produced binary packages), I strongly disagree. The relationship between MPlayer and FFmpeg is very intimate to say the least. MPlayer uses FFmpeg HEAD via a svn:external declaration. In the future we will move both to a common repository. Most FFmpeg developers work on MPlayer as well. Other software also use ffmpeg. AFAIK, ffmpeg do *not* need mplayer to work. FFmpeg is highly volatile and fast-moving. The FFmpeg snapshot in Debian is two months older than the one in MPlayer 1.0rc1. This may not sound much, but it means more than 600 (!) commits to the FFmpeg repository. Using the Debian version of FFmpeg in MPlayer would create a beast entirely different from 1.0rc1. Several codecs have been added which were only available through binaries before, many bugs have been fixed and speed improvements committed. The Debian version can also be updated. I fail to see the issue here. Samuel Hocevar, the Debian ffmpeg maintainer, is really open-minded and cooperative. A H.264 video decoding benchmark done by a fellow developer gives the following numbers: self-built custom binary: 13.9 seconds Debian MPlayer package:14.7 seconds binary with Debian's FFmpeg: 17.7 seconds The Debian FFmpeg binary was built against dynamic FFmpeg, the other two with static FFmpeg. That's a massive 20% performance degradation.. Using a shared dynamic version of FFmpeg would disable several video filters, so there would be even more feature loss. First, on what architecture did you test that? I expect the gap to be reduced on non-x86 architectures. x86 is a register-starved architecture and one of those four general purpose registers is used by PIC code, so dynamic linking can really drop the performance as your benchmark shows. Then, I can agree with you that static linking has better performance. Therefore, what I can recommand is to build mplayer statically, but with a Debian up-to-date ffmpeg package. I am CCing Samuel Hocevar to get his opinion on the matter... Plus I expect random bugs to creep up. As mentioned above FFmpeg is highly volatile and fast-moving. Backwards-compatibility is not a priority. That will *not* happen with an up-to-date ffmpeg package which other packages might benefit from. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#395252: Please depend on ffmpeg binary packages
Package: mplayer Version: 1.0~rc1~svn20199-1 Severity: serious Hi, Your binary package should avoid to use libraries source code provided by your source package. Moreover, you should avoid to compile everything statically and rather use shared libraries. This is hindering the security team and the overall quality of Debian. Instead, you should rather use the Debian packaged version of ffmpeg and of course use shared libraries provided by ffmpeg binary packages. Hence, this explains the release critical status of this bug. If you need any assistance on this, I would be delighted to assist you on the matter. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#394626: FTBFS on alpha: g++ ICE
Package: qdbm Version: 1.8.70-1 Severity: serious When building on alpha, the auto-builder gave the following error. alpha-linux-gnu-g++ -I. -I./.. -I/nonexistant/include -I/usr/local/include -D_XOPEN_SOURCE_EXTENDED=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__=1 -D_HPUX_SOURCE=1 -D_POSIX_MAPPED_FILES=1 -D_POSIX_SYNCHRONIZED_IO=1 -DPIC=1 -D_THREAD_SAFE=1 -D_REENTRANT=1 -Wall -ansi -pedantic -fsigned-char -fPIC -O1 -DNDEBUG -c xdptest.cc xdptest.cc: In function 'int domisc(const char*)': xdptest.cc:455: internal compiler error: in tree_split_edge, at tree-cfg.c:3107 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. Preprocessed source stored into /tmp/ccDWn91Q.out file, please attach this to your bugreport. make[1]: *** [xdptest.o] Error 1 make[1]: Leaving directory `/build/buildd/qdbm-1.8.70/plus' make: *** [build-stamp] Error 2 This is fully reproducible with the last Sid toolchain on my alpha development machine. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#394630: ICE on alpha
Package: g++-4.1 Version: 4.1.1-16 Severity: grave The package qdbm FTBFS on alpha due to an ICE. Here is an extract from the buildd log [1]. alpha-linux-gnu-g++ -I. -I./.. -I/nonexistant/include -I/usr/local/include -D_XOPEN_SOURCE_EXTENDED=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__=1 -D_HPUX_SOURCE=1 -D_POSIX_MAPPED_FILES=1 -D_POSIX_SYNCHRONIZED_IO=1 -DPIC=1 -D_THREAD_SAFE=1 -D_REENTRANT=1 -Wall -ansi -pedantic -fsigned-char -fPIC -O1 -DNDEBUG -c xdptest.cc xdptest.cc: In function 'int domisc(const char*)': xdptest.cc:455: internal compiler error: in tree_split_edge, at tree-cfg.c:3107 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. Preprocessed source stored into /tmp/ccDWn91Q.out file, please attach this to your bugreport. make[1]: *** [xdptest.o] Error 1 make[1]: Leaving directory `/build/buildd/qdbm-1.8.70/plus' make: *** [build-stamp] Error 2 This is fully reproducible with the last Sid toolchain on my alpha development machine. Cheers, [1] http://buildd.debian.org/fetch.cgi?pkg=qdbmver=1.8.70-1arch=alphastamp=1160286309file=log -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#394626: Workaround found for qdbm FTBFS on alpha
tags 394626 patch thanks Compiling the problematic qdbm C++ file with -O0 on alpha avoids the FTBFS. I am attaching a patch for your convenience to adapt to your packaging. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin diff -ruN qdbm-1.8.70.orig/plus/Makefile.in qdbm-1.8.70/plus/Makefile.in --- qdbm-1.8.70.orig/plus/Makefile.in 2006-10-22 12:47:13.0 +0200 +++ qdbm-1.8.70/plus/Makefile.in2006-10-22 12:47:49.0 +0200 @@ -41,7 +41,7 @@ # Building binaries CXX = @CXX@ -RELCXXFLAGS = -O1 -DNDEBUG +RELCXXFLAGS = -O0 -DNDEBUG CPPFLAGS = -I$(srcdir) -I$(srcdir)/.. -I$(HOME)/include -I/usr/local/include \ -D_XOPEN_SOURCE_EXTENDED=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__=1 -D_HPUX_SOURCE=1 \ -D_POSIX_MAPPED_FILES=1 -D_POSIX_SYNCHRONIZED_IO=1 \ signature.asc Description: Digital signature
Bug#391176: Bug is still present when upgrading from 1.9.2-2 - 1.9.2-4
Hi Arnaud, On Mon, Oct 16, 2006 at 09:45:51AM +0200, Arnaud Guiton wrote: I still experience this bug when upgrading from hybserv 1.9.2-2 to 1.9.2-4. As it was a problem in the upgrade scripts and because 1.9.2-2 was affected, maybe it's a normal behavior. The output : -- Setting up hybserv (1.9.2-4) ... Starting Hybserv 2 IRC Services: hybserv. (Here, I had to ^C) dpkg: error processing hybserv (--configure): Subprocess post-installation script killed by signal (Interrupt) (Here, the other packages are upgraded) Errors were encountered while processing: hybserv E: Sub-process /usr/bin/dpkg returned an error code (1) -- After that, an apt-get install hybserv corrects everything. What do you think ? Should the bug be reopened ? Do you need more informations ? Yes, it is a normal behaviour, because 1.9.2-2 is broken. If you try to upgrade from Sarge (1.8.0+1.9.0rc2-1) to Etch (1.9.2-4), it works flawlessly. Anyway, now, hybserv 1.9.2-2 does not exit anymore in the archive. :) Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#391176: Bug is still present when upgrading from 1.9.2-2 - 1.9.2-4
Ouch! I made a confusing typo... On Mon, Oct 16, 2006 at 11:02:39AM +0200, Aurélien GÉRÔME wrote: Yes, it is a normal behaviour, because 1.9.2-2 is broken. If you try to upgrade from Sarge (1.8.0+1.9.0rc2-1) to Etch (1.9.2-4), it works flawlessly. Anyway, now, hybserv 1.9.2-2 does not exit anymore in ^exist the archive. :) Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#392649: rtsigio does not work on alpha
retitle 392649 rtsigio does not work on alpha
severity 392649 important
found 392649
found 392649 1:7.2.2.dfsg.1-2
thanks
The IRCd is running fine, but when an IRC client intends to connect,
nothing happens (the same symptoms are described in #281234, except
for the kernel messages). I attach the IRCd process to strace and
get the following output.
# strace -p 17222
Process 17222 attached - interrupt to quit
gettimeofday({1160692603, 481665}, NULL) =3D 0
rt_sigtimedwait([IO RT_3], 0x120330c50) =3D -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692603, 984385}, NULL) =3D 0
rt_sigtimedwait([IO RT_3], 0x120330c50) =3D -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692604, 486254}, NULL) =3D 0
rt_sigtimedwait([IO RT_3], 0x120330c50) =3D -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692604, 988208}, NULL) =3D 0
rt_sigtimedwait([IO RT_3], 0x120330c50) =3D -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692605, 490120}, NULL) =3D 0
rt_sigtimedwait([IO RT_3], 0x120330c50) =3D -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692605, 992049}, NULL) =3D 0
rt_sigtimedwait([IO RT_3], 0x120330c50) =3D -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692606, 493975}, NULL) =3D 0
rt_sigtimedwait([IO RT_3], unfinished ...
Process 17222 detached
And so on indefinitely...
Here is the output of the IRC client on another host.
00:44 -!- Irssi: Looking up sardaukar
00:44 -!- Irssi: Connecting to sardaukar [10.0.0.9] port 6667
00:44 -!- Irssi: Connection to sardaukar established
And nothing more.
It only appears on alpha and it is probably a kernel bug, because
it works fine on other architectures. Therefore, I am setting the
severity to important.
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Free Software Developer
`- Unix Sys Net Admin
signature.asc
Description: Digital signature
Bug#393196: Please compile ircd-hybrid with rtsigio on any architectures
Package: ircd-hybrid Version: 1:7.2.2.dfsg.1-1 Severity: serious Tags: pending I made a mistake in the debian/rules and now ircd-hybrid is compiled with epoll on any architectures, although I wanted it to be compiled with epoll only on alpha. However, epoll is specific to linux-2.6 and using it on linux-2.4 will fail. The Sarge system the user might come from when dist-upgrading to Etch can be running under linux-2.4. Therefore, to avoid having ircd-hybrid failing under linux-2.4, we must not use epoll. It is a RC bug, because it renders the package unusable after the upgrade path from Sarge to Etch. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#392649: FTBFS on alpha: epoll_* syscall definitions changed since last build
Package: ircd-hybrid
Version: 1:7.2.2.dfsg.1-1
Severity: serious
Tags: help
When building on alpha [1], the auto-builder gave the following error.
gcc -I../include -I/usr/include/pcre -Wall -O2 -g -c s_bsd_epoll.c
s_bsd_epoll.c:87: error: expected declaration specifiers or '...' before
'epoll_create'
s_bsd_epoll.c:87: error: expected declaration specifiers or '...' before
'size'
s_bsd_epoll.c:88: warning: return type defaults to 'int'
s_bsd_epoll.c: In function '_syscall1':
s_bsd_epoll.c:88: error: expected declaration specifiers before
'_syscall4'
s_bsd_epoll.c:123: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
s_bsd_epoll.c:175: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
s_bsd_epoll.c:87: error: parameter name omitted
s_bsd_epoll.c:87: error: parameter name omitted
s_bsd_epoll.c:219: error: expected '{' at end of input
make[2]: *** [s_bsd_epoll.o] Error 1
make[2]: Leaving directory `/build/buildd/ircd-hybrid-7.2.2.dfsg.1/src'
make[1]: *** [build] Error 2
make[1]: Leaving directory `/build/buildd/ircd-hybrid-7.2.2.dfsg.1'
make: *** [build-stamp] Error 2
This is fully reproducible on my alpha development machine into a
up-to-date sid chroot.
I am turning around to fix this bug. :( It is release-critical,
because it prevents the package from going to testing and thus from
fixing 2 other RC bugs.
Cheers,
[1]
http://buildd.debian.org/fetch.php?pkg=ircd-hybridver=1%3A7.2.2.dfsg.1-1arch=alphastamp=1160378662file=logas=raw
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Free Software Developer
`- Unix Sys Net Admin
signature.asc
Description: Digital signature
Bug#392649: ircd-hybrid: FTBFS on alpha: epoll_* syscall definitions changed since last build
Hi alpha porters,
As I wrote in the bug report, I am turning around to find a fix. This
bug did not appear in the previous build from the same release. It
also does not appear on other architectures, because ircd-hybrid only
uses epoll on alpha as rtsigio does not work there.
Any help would be dearly appreciated. Thanks!
On Thu, Oct 12, 2006 at 08:16:53PM +0200, Aurélien GÉRÔME wrote:
Package: ircd-hybrid
Version: 1:7.2.2.dfsg.1-1
Severity: serious
Tags: help
When building on alpha [1], the auto-builder gave the following error.
gcc -I../include -I/usr/include/pcre -Wall -O2 -g -c s_bsd_epoll.c
s_bsd_epoll.c:87: error: expected declaration specifiers or '...' before
'epoll_create'
s_bsd_epoll.c:87: error: expected declaration specifiers or '...' before
'size'
s_bsd_epoll.c:88: warning: return type defaults to 'int'
s_bsd_epoll.c: In function '_syscall1':
s_bsd_epoll.c:88: error: expected declaration specifiers before
'_syscall4'
s_bsd_epoll.c:123: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
s_bsd_epoll.c:175: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
s_bsd_epoll.c:87: error: parameter name omitted
s_bsd_epoll.c:87: error: parameter name omitted
s_bsd_epoll.c:219: error: expected '{' at end of input
make[2]: *** [s_bsd_epoll.o] Error 1
make[2]: Leaving directory `/build/buildd/ircd-hybrid-7.2.2.dfsg.1/src'
make[1]: *** [build] Error 2
make[1]: Leaving directory `/build/buildd/ircd-hybrid-7.2.2.dfsg.1'
make: *** [build-stamp] Error 2
This is fully reproducible on my alpha development machine into a
up-to-date sid chroot.
I am turning around to fix this bug. :( It is release-critical,
because it prevents the package from going to testing and thus from
fixing 2 other RC bugs.
[1]
http://buildd.debian.org/fetch.php?pkg=ircd-hybridver=1%3A7.2.2.dfsg.1-1arch=alphastamp=1160378662file=logas=raw
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Free Software Developer
`- Unix Sys Net Admin
signature.asc
Description: Digital signature
Bug#392649: ircd-hybrid: FTBFS on alpha: epoll_* syscall definitions changed since last build
On Thu, Oct 12, 2006 at 02:55:40PM -0700, Joshua Kwan wrote: From the looks of it, it seems like you should be able to just delete all the preprocessor stuff after the #includes in s_bsd_epoll.c and get away with it. We know that etch will release with a glibc that contains a valid epoll syscall definition. Could you try that on a porting machine? Porters, is this a reasonable idea? Yes, I will give it a try... Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#392649: ircd-hybrid: FTBFS on alpha: epoll_* syscall definitions changed since last build
On Thu, Oct 12, 2006 at 04:09:53PM -0600, Steve Langasek wrote:
On Thu, Oct 12, 2006 at 08:37:59PM +0200, Aurélien GÉRÔME wrote:
As I wrote in the bug report, I am turning around to find a fix.
FWIW, this doesn't translate well into idiomatic English. :) I think you
mean that you're desperate to find a fix?
Sorry, indeed, it is a French idiom that I literally translated. :P
This bug did not appear in the previous build from the same release. It
also does not appear on other architectures, because ircd-hybrid only
uses epoll on alpha as rtsigio does not work there.
You should not be using epoll on alpha either, I'm afraid, because it's a
2.6-only syscall and this means upgrades for stable will break for people
running the 2.4 kernel from sarge.
I would be happy to do that.
You also should not be using syscall1 explicitly, you should be using the
glibc interfaces...
Well, upstream uses them, not me. :)
Do you have a reference to why rtsigio is broken only on alpha?
The upstream package build system gives the choice between rtsigio
and epoll. By default, every architectures use rtsigio. However,
I made alpha use epoll for the following reason.
I did not file a bug report when I found it, but it appears in
the debian/changelog. I was fixing a FTBFS due to a va_list bug in
ircd-hybrid and I decided to really test whether ircd-hybrid ran on
an alpha machine. The IRC daemon was running fine, but when an IRC
client intended to connect, nothing happened (the same symptoms are
described in #281234, except for the kernel messages). I attached
the IRCd process to strace and got the following output.
# strace -p 17222
Process 17222 attached - interrupt to quit
gettimeofday({1160692603, 481665}, NULL) = 0
rt_sigtimedwait([IO RT_3], 0x120330c50) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692603, 984385}, NULL) = 0
rt_sigtimedwait([IO RT_3], 0x120330c50) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692604, 486254}, NULL) = 0
rt_sigtimedwait([IO RT_3], 0x120330c50) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692604, 988208}, NULL) = 0
rt_sigtimedwait([IO RT_3], 0x120330c50) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692605, 490120}, NULL) = 0
rt_sigtimedwait([IO RT_3], 0x120330c50) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692605, 992049}, NULL) = 0
rt_sigtimedwait([IO RT_3], 0x120330c50) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1160692606, 493975}, NULL) = 0
rt_sigtimedwait([IO RT_3], unfinished ...
Process 17222 detached
And so on indefinitely...
Here is the output of the IRC client on another host.
00:44 -!- Irssi: Looking up sardaukar
00:44 -!- Irssi: Connecting to sardaukar [10.0.0.9] port 6667
00:44 -!- Irssi: Connection to sardaukar established
And nothing more.
Hmm... When reproducing the case (after a rebuild with rtsigio) and
looking at the buildd logs for each architecture, I just found that
ircd-hybrid has been built with epoll on any architectures. I did a
stupid thing in the debian/rules... Anyway, I will do another upload
with rtsigio enabled for any architectures by default, but alpha will
not work anymore as stated above, so I will retitle this bug with
Impossible to connect to IRC server on alpha and lower the severity
to important. I think that it is still better than a RC bug. :)
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Free Software Developer
`- Unix Sys Net Admin
signature.asc
Description: Digital signature
Bug#390667: [NONFREE-DOC] Package contains IETF RFC/I-Ds
version 390667 1:7.2.2-2 thanks On Mon, Oct 02, 2006 at 03:35:19PM +0200, Simon Josefsson wrote: It seems your package contains non-free RFC/I-Ds: /usr/share/doc/ircd-hybrid/technical/draft-mitchell-irc-capabilities-01.txt.gz The license on RFC/I-Ds is not DFSG-free, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199810 http://release.debian.org/removing-non-free-documentation I believe the options are: 1) Remove the file from the package (which may include re-packaging the source code). I will remove the file from both source and binary packages. 2) Move the files to a non-free package (which may also include re-packaging the source code). If you disagree with this, because this bug is reported for several packages at once, it seems better to discuss this on debian-legal, in this thread: http://thread.gmane.org/gmane.linux.debian.devel.legal/25993 So far, I only disagree with the version. ;) The severity is serious, because this violates the Debian policy http://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg. Sure. I'm sorry if this report is filed in error, I went over many packages looking for suspicious filenames, and there may be false positives. Expect it to be fixed at the next upload with version 1:7.2.2.dsfg-1. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#390667: [NONFREE-DOC] Package contains IETF RFC/I-Ds
tags 390667 pending thanks On Mon, Oct 02, 2006 at 07:27:54PM +0200, Aurélien GÉRÔME wrote: Expect it to be fixed at the next upload with version 1:7.2.2.dsfg-1. Thanks for the bug report too! Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#390667: [NONFREE-DOC] Package contains IETF RFC/I-Ds
found 390667 1:7.2.2-2 thanks On Mon, Oct 02, 2006 at 07:33:39PM +0200, Aurélien GÉRÔME wrote: On Mon, Oct 02, 2006 at 07:27:54PM +0200, Aurélien GÉRÔME wrote: Expect it to be fixed at the next upload with version 1:7.2.2.dsfg-1. I will modify the source tarball name or version. If you can suggest me your preference on that, it would help me a bit. :) Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#385695: New patch
Setting up a specific ALPHA macro which is passed via CPPFLAGS to the
configure script in debian/rules is not elegant, because gcc has a
built-in __alpha__ macro to take care of it. Hence, here is the new
patch which will come in the 7.2.2-2 revision.
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Free Software Developer
`- Unix Sys Net Admin
#! /bin/sh /usr/share/dpatch/dpatch-run
## 18_va_list_is_not_a_pointer.dpatch by Aurélien GÉRÔME agroxor.cx
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fix va_list usage on Alpha which is not a pointer, but a struct.
@DPATCH@
diff -urNad ircd-hybrid-7.2.2~/src/s_user.c ircd-hybrid-7.2.2/src/s_user.c
--- ircd-hybrid-7.2.2~/src/s_user.c 2006-09-19 17:49:13.0 +0200
+++ ircd-hybrid-7.2.2/src/s_user.c 2006-09-19 17:57:30.648925324 +0200
@@ -427,8 +427,16 @@
{
const char *id = execute_callback(uid_get_cb, source_p);
-while (hash_find_id(id) != NULL)
- id = uid_get(NULL);
+while (hash_find_id(id) != NULL) {
+ va_list vl;
+#ifdef __alpha__
+ vl.__base = NULL;
+ vl.__offset = 0;
+#else
+ vl = NULL;
+#endif
+ id = uid_get(vl);
+}
strlcpy(source_p-id, id, sizeof(source_p-id));
hash_add_id(source_p);
signature.asc
Description: Digital signature
Bug#385695: FTBFS on alpha: remove unused va_list
retitle 385695 FTBFS on alpha: remove unused va_list
thanks
My previous patches were nonsense. This one fixes the issue.
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Free Software Developer
`- Unix Sys Net Admin
#! /bin/sh /usr/share/dpatch/dpatch-run
## 18_remove_unused_va_list.dpatch by Aurélien GÉRÔME agroxor.cx
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Remove unused va_list.
@DPATCH@
diff -urNad ircd-hybrid-7.2.2~/src/s_user.c ircd-hybrid-7.2.2/src/s_user.c
--- ircd-hybrid-7.2.2~/src/s_user.c 2006-09-19 18:37:13.0 +0200
+++ ircd-hybrid-7.2.2/src/s_user.c 2006-09-19 21:13:01.064621246 +0200
@@ -68,7 +68,7 @@
static void report_and_set_user_flags(struct Client *, const struct AccessItem
*);
static int check_xline(struct Client *);
static void introduce_client(struct Client *, struct Client *);
-static void *uid_get(va_list);
+static void *uid_get();
/* Used for building up the isupport string,
* used with init_isupport, add_isupport, delete_isupport
@@ -428,7 +428,7 @@
const char *id = execute_callback(uid_get_cb, source_p);
while (hash_find_id(id) != NULL)
- id = uid_get(NULL);
+ id = uid_get();
strlcpy(source_p-id, id, sizeof(source_p-id));
hash_add_id(source_p);
@@ -1386,12 +1386,12 @@
/*
* uid_get
*
- * inputs - struct Client *
+ * inputs - none
* output - new UID is returned to caller
* side effects - new_uid is incremented by one.
*/
static void *
-uid_get(va_list args)
+uid_get()
{
add_one_to_uid(TOTALSIDUID - 1);/* index from 0 */
return new_uid;
signature.asc
Description: Digital signature
Bug#385946: fmit: crashes at startup
Hi, The sole x86 machines I have are servers. My desktop machine is a PowerPC and fmit runs great on it. Nonetheless, I tried to test fmit on a x86 over an exported X11 display on a PowerPC and it worked fine, but with ALSA disabled of course. However, it seems having ALSA disabled does not reproduce this bug on x86. This might help to narrow down the issue on x86... [EMAIL PROTECTED]:~$ xhost + [EMAIL PROTECTED]:~$ export DISPLAY=chii:0 [EMAIL PROTECTED]:~$ fmit Free Music Instrument Tuner version 0.96.5 built at Sep 2 2006 15:25:55 Install directory '/usr' X Error: BadValue (integer parameter out of range for operation) 2 Major opcode: 155 Minor opcode: 4 Resource id: 0x100 CaptureThread: INFO: Built in transports CaptureThread: INFO:JACK unavailable CaptureThread: INFO:ALSA unavailable (invalid source 'hw:0') CaptureThread: INFO: Auto detecting a working transport ... no transport working ! Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Bug#336993: initramfs done by yaird with XFS
tag 336993 patch
thanks
I think that does not deserve any explainations (clue: unmaintained
code)...
Cheers,
--
((__,--,__)) Aurélien GÉRÔME .---.
`--)~ ~(--` Free Software Developer / \
.-'( )`-. Unix Sys Net Admin [EMAIL PROTECTED]@./
`~~`@) (@`~~` /`\_/`\
| |.''`. // _ \\
| | : :' : | \ )|_
(8___8) `. `'` /`\_` _/ \
`---` `- \__/'---'\__/
BOFH excuse #143: had to use hammer to free stuck disk drive heads.
diff -ruN yaboot-1.3.13-debian.orig/second/fs_xfs.c
yaboot-1.3.13-debian/second/fs_xfs.c
--- yaboot-1.3.13-debian.orig/second/fs_xfs.c 2002-09-15 05:12:21.0
+0200
+++ yaboot-1.3.13-debian/second/fs_xfs.c2006-07-10 22:39:39.236824000
+0200
@@ -658,8 +658,6 @@
startpos = xfs_file-pos;
endpos = xfs_file-pos + len;
- if (endpos xfs_file-len)
- endpos = xfs_file-len;
endofprev = (xfs_fileoff_t)-1;
init_extents ();
while (len 0 (xad = next_extent ())) {
signature.asc
Description: Digital signature
Bug#367024: Licences conflict: Ruby under pure GPL with OpenSSL Licence
On Tue, May 16, 2006 at 04:12:31PM +0900, akira yamada wrote: Aurélien GÉRÔME wrote: Package: libopenssl-ruby1.8 Version: 1.8.2-7sarge2 Severity: serious The binary package libopenssl-ruby1.8 (pure GPL) depends on libssl0.9.7 (OpenSSL Licence). Those 2 licences conflict due to a clause in OpenSSL Licence which has to be added to the GPL. Ruby is distributed with dual-license which is Ruby's License or GPL. URL:http://www.ruby-lang.org/en/LICENSE.txt Absolutely, I am well aware of that. However, for that specific binary package, it is impossible to licence it under an unalterated GPL. Hence, the choice between the GPL or the Ruby Licence is not a choice: it is automatically the Ruby Licence. User of this package can use it as a source package. And they can choise to build without OpenSSL. So I think that debian/copyright has correct information. We may add this point as a note to libopenssl-ruby1.8.README.Debian, but I think that it is not a serious bug. It would be wise to do so. However, it is indeed a serious bug. I did not set the severity to serious, because I found it funny to annoy people, but rather because licences conflict violates the DFSG, and by doing so, the Debian Policy. Cheers. -- ((__,--,__)) Aurélien GÉRÔME .---. `--)~ ~(--` Free Software Developer / \ .-'( )`-. Unix Sys Net Admin [EMAIL PROTECTED]@./ `~~`@) (@`~~` /`\_/`\ | |.''`. // _ \\ | | : :' : | \ )|_ (8___8) `. `'` /`\_` _/ \ `---` `- \__/'---'\__/ BOFH excuse #63: not properly grounded, please bury computer signature.asc Description: Digital signature
Bug#367024: Licences conflict: Ruby under pure GPL with OpenSSL Licence
On Sat, May 13, 2006 at 11:08:19AM +0900, akira yamada wrote: Aurélien GÉRÔME wrote: Package: libopenssl-ruby1.8 Version: 1.8.2-7sarge2 Severity: serious The binary package libopenssl-ruby1.8 (pure GPL) depends on libssl0.9.7 (OpenSSL Licence). Those 2 licences conflict due to a clause in OpenSSL Licence which has to be added to the GPL. Ruby is distributed with dual-license which is Ruby's License or GPL. URL:http://www.ruby-lang.org/en/LICENSE.txt Absolutely, I am well aware of that. However, for that specific binary package, it is impossible to licence it under an unalterated GPL. Hence, the choice between the GPL or the Ruby Licence is not a choice: it is automatically the Ruby Licence. Instead of licencing that particular binary package under 2 licences to choose between, it should be only licenced under the Ruby Licence. Thus, the binary package should contain only the Ruby Licence, except if Yukihiro Matsumoto alters the COPYING file to include the OpenSSL statement like that post shows it: http://lists.debian.org/debian-legal/2004/05/msg00595.html. On a side note, I am unsure about the Ruby Licence case, whether it should include the OpenSSL statement or not... BTW, I am thinking about coding a GnuTLS interface for Ruby, since it does not appear to exist and I need it. :) Cheers. -- ((__,--,__)) Aurélien GÉRÔME .---. `--)~ ~(--` Free Software Developer / \ .-'( )`-. Unix Sys Net Admin [EMAIL PROTECTED]@./ `~~`@) (@`~~` /`\_/`\ | |.''`. // _ \\ | | : :' : | \ )|_ (8___8) `. `'` /`\_` _/ \ `---` `- \__/'---'\__/ BOFH excuse #279: The static electricity routing is acting up... signature.asc Description: Digital signature
Bug#367024: Licences conflict: Ruby under pure GPL with OpenSSL Licence
Package: libopenssl-ruby1.8 Version: 1.8.2-7sarge2 Severity: serious The binary package libopenssl-ruby1.8 (pure GPL) depends on libssl0.9.7 (OpenSSL Licence). Those 2 licences conflict due to a clause in OpenSSL Licence which has to be added to the GPL. Some other packages, lftp and ircd-hybrid for instance, have deactivated SSL support due to that conflict. Though the following may apply to other libopenssl-ruby*, i.e. libopenssl-ruby1.6 and libopenssl-ruby1.9, I open just one bug for now... The binary package libopenssl-ruby1.8 should not be distributed anymore, except if the upstream author alters the GPL by adding what the OpenSSL Licence paragraph 3 and 6 require: This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) Cheers. -- ((__,--,__)) Aurélien GÉRÔME .---. `--)~ ~(--` Free Software Developer / \ .-'( )`-. Unix Sys Net Admin [EMAIL PROTECTED]@./ `~~`@) (@`~~` /`\_/`\ | |.''`. // _ \\ | | : :' : | \ )|_ (8___8) `. `'` /`\_` _/ \ `---` `- \__/'---'\__/ BOFH excuse #108: The air conditioning water supply pipe ruptured over the machine room signature.asc Description: Digital signature
