Bug#519597: check: strdup implicitly converted to pointer
Package: check Version: 0.9.6-1 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `strdup' implicitly converted to pointer at check_print.c:123 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. Note: -ansi conflicts with strdup usage. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions -- dann frazier --- check-0.9.6.orig/src/Makefile.am 2008-12-29 06:48:45.0 -0700 +++ check-0.9.6/src/Makefile.am 2009-03-13 11:57:29.064871705 -0600 @@ -7,7 +7,7 @@ EXTRA_DIST = check.h.in -AM_CFLAGS = @GCOV_CFLAGS@ -ansi -pedantic +AM_CFLAGS = @GCOV_CFLAGS@ -pedantic CFILES =\
Bug#519123: midori: soup_uri_decode implicitly converted to pointer
Package: midori Version: 0.1.4-1 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `soup_uri_decode' implicitly converted to pointer at ../midori/midori-view.c:2551 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions -- dann frazier --- midori-0.1.4/midori/midori-view.c.orig 2009-03-10 09:34:49.720620865 -0600 +++ midori-0.1.4/midori/midori-view.c 2009-03-10 09:33:54.536960858 -0600 @@ -25,6 +25,7 @@ #include stdlib.h #include glib/gi18n.h #include webkit/webkit.h +#include libsoup/soup-uri.h #if GLIB_CHECK_VERSION (2, 18, 0) #define D_(__domain, __message) g_dgettext (__domain, __message)
Bug#518899: add support for the Kyocera / Contax SL300R T* digital camera
Package: linux-2.6 Version: 2.6.26-13 Severity: important Tags: patch Requested by Moritz Muehlenhoff: commit 74511bb340059be5a3fceb032213c7f325344694 Author: Jens Taprogge jens.tapro...@taprogge.org Date: Sun Oct 26 18:16:09 2008 +0100 USB: Unusual dev for the Kyocera / Contax SL300R T* digital camera. The camera reports an incorrect size and fails to handle PREVENT-ALLOW MEDIUM REMOVAL commands. The patch marks the camera as an unusual dev and adds the flags to enable the workarounds for both shortcomings. Signed-off-by: Jens Taprogge jens.tapro...@taprogge.org Cc: Alan Stern st...@rowland.harvard.edu Cc: Phil Dibowitz p...@ipom.com Signed-off-by: Greg Kroah-Hartman gre...@suse.de Adjusted to apply to Debian's 2.6.26 by dann frazier da...@debian.org diff -urpN linux-source-2.6.26.orig/drivers/usb/storage/unusual_devs.h linux-source-2.6.26/drivers/usb/storage/unusual_devs.h --- linux-source-2.6.26.orig/drivers/usb/storage/unusual_devs.h 2009-02-07 16:43:12.0 -0700 +++ linux-source-2.6.26/drivers/usb/storage/unusual_devs.h 2009-03-08 22:10:12.0 -0600 @@ -307,6 +307,13 @@ UNUSUAL_DEV( 0x0482, 0x0103, 0x0100, 0x Finecam S5, US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_INQUIRY), +/* Patch submitted by Jens Taprogge jens.tapro...@taprogge.org */ +UNUSUAL_DEV( 0x0482, 0x0107, 0x0100, 0x0100, + Kyocera, + CONTAX SL300R T*, + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY | US_FL_NOT_LOCKABLE), + /* Reported by Paul Stewart stew...@wetlogic.net * This entry is needed because the device reports Sub=ff */ UNUSUAL_DEV( 0x04a4, 0x0004, 0x0001, 0x0001, -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518900: ALSA: caiaq - Fix Oops with MIDI
Package: linux-2.6
Version: 2.6.26-13
Severity: important
Tags: patch
Requested by Moritz Muehlenhoff:
commit f3f80a9205da74fa56d613f4c14b88b6e4e6caa8
Author: Takashi Iwai ti...@suse.de
Date: Thu Jan 8 15:32:56 2009 +0100
ALSA: caiaq - Fix Oops with MIDI
The snd-usb-caiaq driver causes Oops occasionally when accessing MIDI
devices. This patch fixes the Oops and invalid URB submission errors
as well.
Cc: sta...@kernel.org
Signed-off-by: Takashi Iwai ti...@suse.de
diff --git a/sound/usb/caiaq/caiaq-device.h b/sound/usb/caiaq/caiaq-device.h
index f9fbdba..ab56e73 100644
--- a/sound/usb/caiaq/caiaq-device.h
+++ b/sound/usb/caiaq/caiaq-device.h
@@ -75,6 +75,7 @@ struct snd_usb_caiaqdev {
wait_queue_head_t ep1_wait_queue;
wait_queue_head_t prepare_wait_queue;
int spec_received, audio_parm_answer;
+ int midi_out_active;
char vendor_name[CAIAQ_USB_STR_LEN];
char product_name[CAIAQ_USB_STR_LEN];
diff --git a/sound/usb/caiaq/caiaq-midi.c b/sound/usb/caiaq/caiaq-midi.c
index 30b57f9..f19fd36 100644
--- a/sound/usb/caiaq/caiaq-midi.c
+++ b/sound/usb/caiaq/caiaq-midi.c
@@ -59,6 +59,11 @@ static int snd_usb_caiaq_midi_output_open(struct
snd_rawmidi_substream *substrea
static int snd_usb_caiaq_midi_output_close(struct snd_rawmidi_substream
*substream)
{
+ struct snd_usb_caiaqdev *dev = substream-rmidi-private_data;
+ if (dev-midi_out_active) {
+ usb_kill_urb(dev-midi_out_urb);
+ dev-midi_out_active = 0;
+ }
return 0;
}
@@ -69,7 +74,8 @@ static void snd_usb_caiaq_midi_send(struct snd_usb_caiaqdev
*dev,
dev-midi_out_buf[0] = EP1_CMD_MIDI_WRITE;
dev-midi_out_buf[1] = 0; /* port */
- len = snd_rawmidi_transmit_peek(substream, dev-midi_out_buf+3,
EP1_BUFSIZE-3);
+ len = snd_rawmidi_transmit(substream, dev-midi_out_buf + 3,
+ EP1_BUFSIZE - 3);
if (len = 0)
return;
@@ -79,24 +85,24 @@ static void snd_usb_caiaq_midi_send(struct snd_usb_caiaqdev
*dev,
ret = usb_submit_urb(dev-midi_out_urb, GFP_ATOMIC);
if (ret 0)
- log(snd_usb_caiaq_midi_send(%p): usb_submit_urb() failed,
%d\n,
- substream, ret);
+ log(snd_usb_caiaq_midi_send(%p): usb_submit_urb() failed,
+ ret=%d, len=%d\n,
+ substream, ret, len);
+ else
+ dev-midi_out_active = 1;
}
static void snd_usb_caiaq_midi_output_trigger(struct snd_rawmidi_substream
*substream, int up)
{
struct snd_usb_caiaqdev *dev = substream-rmidi-private_data;
- if (dev-midi_out_substream != NULL)
- return;
-
- if (!up) {
+ if (up) {
+ dev-midi_out_substream = substream;
+ if (!dev-midi_out_active)
+ snd_usb_caiaq_midi_send(dev, substream);
+ } else {
dev-midi_out_substream = NULL;
- return;
}
-
- dev-midi_out_substream = substream;
- snd_usb_caiaq_midi_send(dev, substream);
}
@@ -161,16 +167,14 @@ int snd_usb_caiaq_midi_init(struct snd_usb_caiaqdev
*device)
void snd_usb_caiaq_midi_output_done(struct urb* urb)
{
struct snd_usb_caiaqdev *dev = urb-context;
- char *buf = urb-transfer_buffer;
+ dev-midi_out_active = 0;
if (urb-status != 0)
return;
if (!dev-midi_out_substream)
return;
- snd_rawmidi_transmit_ack(dev-midi_out_substream, buf[2]);
- dev-midi_out_substream = NULL;
snd_usb_caiaq_midi_send(dev, dev-midi_out_substream);
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500876: fix for 500876
On Tue, Mar 03, 2009 at 09:34:26PM +0100, Ola Lundqvist wrote:
Hi Dann
The openvz 686 version is now regression tested. I have also asked the
person that had the problem with this bug to verify the amd64 kernel as well.
Best regards,
Thanks!
// Ola
On Tue, Mar 03, 2009 at 11:36:17AM -0700, dann frazier wrote:
On Tue, Mar 03, 2009 at 05:54:09PM +0100, Ola Lundqvist wrote:
Hi Dann
Looks very similar to the patch I proposed. Here it is.
I was not aware you could add more files so I appended to the
end of the file.
Ah - yeah, in fact we _must_ have separate files. That gives us the
ability to generate older versions of the source tree from the
latest. Of course, that doesn't work so well for the features
patches, since they sometimes have to be regen'd to apply.
When you have different files like this, which order will it take
them?
That is determined by the series file. At application, the build
system parses the series file (using the changelog to determine
order), and applys all of the normal patches (series files that don't
end in -extra), followed by all of the -extra patches.
I guess the only thing remaining is to verify that this patch works
well and risk of regression is low - do you have a system (or systems)
you can use to test the builds here?
http://people.debian.org/~dannf/bugs/500876/
Best regards,
// Ola
On Tue, Mar 03, 2009 at 09:31:36AM -0700, dann frazier wrote:
On Tue, Mar 03, 2009 at 07:49:05AM +0100, Ola Lundqvist wrote:
Hi Dann
Quoting dann frazier da...@dannf.org:
hey Ola,
Attached is a patch I have queued for lenny.
I've posted builds w/ this fix here:
http://people.debian.org/~dannf/bugs/500876/
Oh, thanks a lot.
Would you be able to review the patch/test the build to confirm that
its ok for a stable update? Note that it doesn't change the ABI.
Good to know that it does not change the ABI. I was just about to
send you
a mail with my own work regarding this issue. My machine is currently
building a package with this patch.
Do you have a diff file on what you did? If not I'll send mine later
today.
The patch applied fine and seems to build on 686 arch at least.
Best regards,
// Ola
oops - forgot to attach it
Index: debian/patches/series/14-extra
===
--- debian/patches/series/14-extra (revision 0)
+++ debian/patches/series/14-extra (revision 0)
@@ -0,0 +1 @@
++ features/all/openvz/fix-wrong-size-of-ub0_percpu.patch
featureset=openvz
Index:
debian/patches/features/all/openvz/fix-wrong-size-of-ub0_percpu.patch
===
---
debian/patches/features/all/openvz/fix-wrong-size-of-ub0_percpu.patch
(revision 0)
+++
debian/patches/features/all/openvz/fix-wrong-size-of-ub0_percpu.patch
(revision 0)
@@ -0,0 +1,112 @@
+From: Konstantin Khlebnikov khlebni...@openvz.org
+Date: Tue, 7 Oct 2008 08:57:48 + (+0400)
+Subject: fix wrong size of ub0_percpu.
+X-Git-Tag: sync-2.6.27-15.10.08~5
+X-Git-Url:
http://git.openvz.org/?p=linux-2.6.26-openvz;a=commitdiff_plain;h=777e8164ebf8a03e43511983cdec472f8691a8af
+
+fix wrong size of ub0_percpu.
+
+after commit b3242151 struct percpu_data dynamically allocated
+and have array only for 1 cpu, so static usage of it does not work.
+
+Plus rework macros for static percpu variables declaration and
initialization.
+
+http://bugzilla.openvz.org/show_bug.cgi?id=1039
+
+Signed-off-by: Konstantin Khlebnikov khlebni...@openvz.org
+Signed-off-by: Pavel Emelyanov xe...@openvz.org
+---
+
+diff --git a/include/linux/percpu.h b/include/linux/percpu.h
+index 5ac97e1..e159f4d 100644
+--- a/include/linux/percpu.h
b/include/linux/percpu.h
+@@ -74,11 +74,20 @@ struct percpu_data {
+ (__typeof__(ptr))__p-ptrs[(cpu)]; \
+ })
+
+-#define static_percpu_ptr(sptr, sptrs) ({ \
++struct percpu_data_static {
++ void *ptrs[NR_CPUS];
++};
++
++#define DEFINE_PER_CPU_STATIC(type, name) \
++ static struct percpu_data_static per_cpu_data__##name; \
++ static __typeof__(type) per_cpu__##name[NR_CPUS]
++
++#define percpu_static_init(name) ({ \
+ int i; \
+ for (i = 0; i NR_CPUS; i++) \
+- (sptr)-ptrs[i] = (sptrs)[i]; \
+- (__typeof__(sptrs[0]))__percpu_disguise(sptr);\
++ (per_cpu_data__##name).ptrs[i] =
(per_cpu__##name)[i
Bug#517893: tracker: missing build-dep on libglade2-dev
Package: tracker Version: 0.6.90-2 Severity: serious Tags: patch tracker is failing to build on some archs (ia64 is one) due to a missing build-dep on libglade2-dev. Adding this build-dep fixes the build. Interestingly enough, it looks like libglade2-dev did get installed by some buildds (e.g., mipsel) - perhaps one of the other build-deps used to depend on libglade2-dev, but no longer does? -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517895: psycopg2: psycopg_escape_string implicitly converted to pointer
Package: psycopg2 Version: 2.0.9-1 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `psycopg_escape_string' implicitly converted to pointer at psycopg/cursor_type.c:1225 Function `psycopg_escape_string' implicitly converted to pointer at psycopg/adapter_qstring.c:96 Function `psycopg_escape_string' implicitly converted to pointer at psycopg/cursor_type.c:1225 Function `psycopg_escape_string' implicitly converted to pointer at psycopg/adapter_qstring.c:96 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517470: ffmpeg2theora: FTBFS in sid
Package: ffmpeg2theora Version: 0.21-0.1 Severity: serious Looks like a build-dep changed causing the 0.21-0.1+b1 binNMU to fail to build in current sid: https://buildd.debian.org/build.php?arch=pkg=ffmpeg2theora -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Kernel: Linux 2.6.28-1-mckinley (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516797: vala: test_test_string implicitly converted to pointer
Package: vala Version: 0.5.6-2 Severity: serious Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `test_test_string' implicitly converted to pointer at client.c:338 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516797: patch
tags 516797 + patch thanks client.c includes headers that are not satisfied by the current set of build-deps. --- vala-0.5.7/debian/control 2009-02-23 10:30:19.0 -0700 +++ vala/vala-0.5.7/debian/control 2009-02-23 11:29:49.608619374 -0700 @@ -5,6 +5,8 @@ Uploaders: Marc-Andre Lureau marcandre.lur...@gmail.com, Loic Minier l...@dooz.org, Mathias Hasselmann mathias.hasselm...@gmx.de, Sebastian Dröge sl...@debian.org Build-Depends: debhelper (= 5.0), cdbs (= 0.4), + libdbus-1-dev, + libdbus-glib-1-dev, libglib2.0-dev (= 2.12.0), bison (= 2.3), autotools-dev, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516664: here too
fyi, I'm seeing the same problem here. I've tried --force-shutdown restarting, but I'm still having the issue. I haven't rebooted (not a convenient time to), so I can test things if you like. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516867: lvm2: completion_matches implicitly converted to pointer
Package: lvm2 Version: 2.02.44-1 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `completion_matches' implicitly converted to pointer at lvm.c:135 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions diff -urpN lvm2-2.02.44.orig/tools/lvm.c lvm2-2.02.44/tools/lvm.c --- lvm2-2.02.44.orig/tools/lvm.c 2008-12-17 22:27:18.0 -0700 +++ lvm2-2.02.44/tools/lvm.c 2009-02-23 21:56:28.909244639 -0700 @@ -25,9 +25,6 @@ int main(int argc, char **argv) # include readline/readline.h # include readline/history.h -# ifndef HAVE_RL_COMPLETION_MATCHES -#define rl_completion_matches(a, b) completion_matches((char *)a, b) -# endif static struct cmdline_context *_cmdline;
Bug#516248: skyeye: get_sym implicitly converted to pointer
Package: skyeye Version: 1.2.5-1 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `get_sym' implicitly converted to pointer at utils/main/skyeye.c:200 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions -- dann frazier diff -urpN skyeye-1.2.5.orig/utils/profile/symbol.h skyeye-1.2.5/utils/profile/symbol.h --- skyeye-1.2.5.orig/utils/profile/symbol.h 2008-05-15 08:40:58.0 -0600 +++ skyeye-1.2.5/utils/profile/symbol.h 2009-02-19 18:28:25.636833631 -0700 @@ -73,6 +73,7 @@ void ARMul_TaskSwitch(ARMul_State *state ARMword ARMul_TaskCreate(ARMul_State *state); void ARMul_ReportEnergy(ARMul_State *state, FILE* pf); void ARMul_Consolidate(ARMul_State *state); +char *get_sym(ARMword address); #endif #endif diff -urpN skyeye-1.2.5.orig/utils/main/skyeye.c skyeye-1.2.5/utils/main/skyeye.c --- skyeye-1.2.5.orig/utils/main/skyeye.c 2008-05-02 10:07:09.0 -0600 +++ skyeye-1.2.5/utils/main/skyeye.c 2009-02-19 18:36:45.901755129 -0700 @@ -46,6 +46,7 @@ with this program; if not, write to the #include setjmp.h #include code_cov.h +#include symbol.h /** * A global variable , point to the current archtecture
Bug#515838: xlog: strptime implicitly converted to pointer
Package: xlog Version: 2.0-2 Severity: serious Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `strptime' implicitly converted to pointer at cabrillo.c:347 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508930: add --username, --password, and --no-auth-cache options
On Tue, Dec 16, 2008 at 10:45:21AM -0800, Jack Bates wrote: Package: svn-load Version: 1.1 Severity: wishlist Tags: patch I wish svn-load supported the Subversion --username, --password, and --no-auth-cache options: hey Jack! Thanks for the patch, I'd like to include this support as well. However, I _think_ that we need to do it in a more global way. Your patch sets up the client instance that is used in __main__, but there are several other client instances used throughout the code. This means that these options would only be set for the commit, not for e.g., the source checkout/tagging. One option is to rework NotifiedClient() - make it a class and have it store the configuration for future instances. Another option is to use a single client instance everywhere. I don't really like the aesthetic of passing the client parameter around everywhere but, then again, we're creating a new instance in nearly every function call and that's pretty ugly as well. I suppose we could just make it a global variable. What do you think? -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513228: adding hardware support has important severity
severity 513228 important thanks SRM considers the addition of hardware support to be of 'important' severity (aka, would be nice to fix in a stable release if possible, and of minimal risk to the existing install base). -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515138: kernel-package: mentions of grub on ia64
Package: kernel-package Version: 11.017 Severity: normal da...@krebs:~$ cat /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = yes do_bootfloppy = no do_initrd = yes link_in_boot = no da...@krebs:~$ dpkg -l | grep grub da...@krebs:~$ r...@biglpk:~# dpkg -i linux-image-2.6.28-1-mckinley_2.6.28-1~experimental.1_ia64.deb (Reading database ... 278177 files and directories currently installed.) Preparing to replace linux-image-2.6.28-1-mckinley 2.6.28-1~experimental.1 (using linux-image-2.6.28-1-mckinley_2.6.28-1~experimental.1_ia64.deb) ... The directory /lib/modules/2.6.28-1-mckinley still exists. Continuing as directed. Done. Unpacking replacement linux-image-2.6.28-1-mckinley ... Setting up linux-image-2.6.28-1-mckinley (2.6.28-1~experimental.1) ... Hmm. The package shipped with a symbolic link /lib/modules/2.6.28-1-mckinley/source However, I can not read the target: No such file or directory Therefore, I am deleting /lib/modules/2.6.28-1-mckinley/source Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. Other valid candidates: mkinitramfs-kpkg mkinitrd.yaird W: mdadm: unchecked configuration file: /etc/mdadm/mdadm.conf W: mdadm: please read /usr/share/doc/mdadm/README.upgrading-2.5.3.gz . W: mdadm: no arrays defined in configuration file. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.28-1~experimental.1 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.28-1~experimental.1 was configured last, according to dpkg) You already have a ELILO configuration in /etc/elilo.conf Do we really want to run bootloader elilo? Configuring linux-image-2.6.28-1-mckinley - The default boot loader for this architecture is elilo, which is present. However, you have not explicitly requested the boot loader elilo should be run in the configuration file /etc/kernel-img.conf, and you seem to have grub installed, and have set a postinst hook (which is used to hook in grub after a kernel image installation). At this point, it is perfectly likely that this system is using grub as a bootloader, and not the builtin default of elilo. If that is the case, running elilo instead of grub might make the machine unbootable. I need to know whether to run the default bootloader elilo, or just let the postinst hook script update grub later. The default is to run elilo. Run the default bootloader? Yes Ok, continuing as directed. Running /usr/sbin/elilo ... Installation successful. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Kernel: Linux 2.6.26-1-mckinley (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kernel-package depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii debianutils 2.31 Miscellaneous utilities specific t ii dpkg1.14.25 Debian package management system ii dpkg-dev1.14.25 Debian package development tools ii file4.26-2 Determines file type using magic ii gcc [c-compiler]4:4.3.2-3The GNU C compiler ii gcc-4.1 [c-compiler 4.1.2-25 The GNU C compiler ii gcc-4.3 [c-compiler 4.3.3-3 The GNU C compiler ii gettext 0.17-6 GNU Internationalization utilities ii make3.81-5 The GNU version of the make util ii module-init-tools 3.4-1tools for managing Linux kernel mo ii perl5.10.0-19Larry Wall's Practical Extraction ii po-debconf 1.0.15 manage translated Debconf template ii util-linux 2.13.1.1-1 Miscellaneous system utilities Versions of packages kernel-package recommends: ii bzip2 1.0.5-1high-quality block-sorting file co ii libc6.1-dev [libc6-dev] 2.8+20080809-1 GNU C Library: Development Librari Versions of packages kernel-package suggests: pn docbook-utils none (no description available) ii e2fsprogs 1.41.3-1 ext2/ext3/ext4 file system utiliti ii initramfs-tools [li 0.92otools for generating an initramfs pn libdb3-dev none (no description available) ii libncurses5-dev [li 5.7+20090124-1 developer's libraries and docs for ii linux-source-2.6.18 2.6.18.dfsg.1-24 Linux kernel source for version 2. ii linux-source-2.6.24 2.6.24-6~etchnhalf.8 Linux kernel source for version 2. ii linux-source-2.6.26 2.6.26-13Linux kernel source for version 2. ii xmlto
Bug#515060: linux-headers-2.6.26-1-common: 2.6.26 headers missing uvcvideo.h
On Thu, Feb 12, 2009 at 07:01:27PM -0800, Scott Anderson wrote: Subject: linux-headers-2.6.26-1-common: 2.6.26 headers missing uvcvideo.h Package: linux-headers-2.6.26-1-common Version: 2.6.26-13 Severity: normal *** Please type your report below this line *** I can't find the necessary header files to build the included uvcvideo.ko kernel module. This file isn't under include/ so, by design, its not in the headers package. You can find this file in linux-source-2.6.26. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514833: linux-image-2.6.18-6-686: sundance network driver get timeout on a DFE-580TX when this kernel is installed
On Wed, Feb 11, 2009 at 07:14:23PM +0100, Benoit Mortier wrote: Le Wednesday 11 February 2009 17:59:27 Martin Michlmayr, vous avez ?crit?: * maximilian attems m...@stro.at [2009-02-11 11:47]: When i upgrade this box running a DFE-580TX with the latest etch update of 10 february 2009 Immediately my network card stopped functionning with the message below ... did you try a newer kernel like 2.6.24 etch+half that is shipped there? also lenny is about to be released with 2.6.26. is it reproducible with them? I guess the main point you missed from Benoit's message that apparently a recent stable update broke networking for him; i.e. this is a regression introduced by a stable update. Benoit, is this correct? It worked with the previous 2.6.18 kernel in etch? Yes, this is correct. When applying the latest update for etch for the kernel 2.6.18 this broke the network driver for the DFE-580TX sundance driver For the sundance driver this previous version worked well : 2.6.18.dfsg.1-23etch1 The version from the latest update break the driver : 2.6.18.dfsg.1-24 I put the severity to grave because those cards are mainly used in firewall and router and then have a direct effect on the whole network. There were no code changes between 2.6.18.dfsg.1-23etch1 and 2.6.18.dfsg.1-24 in the code you are using. The only patches that are applied to the -686 flavor were an hppa-specific change and to the cciss driver (just adding ID's). The remaining changes are only applied in the xen flavor. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514147: linux-image-2.6.26-1-686: lenny gets sometimes stuck while booting in system
On Thu, Feb 12, 2009 at 02:09:29AM +0100, Bastian Blank wrote: tags 514147 moreinfo thanks On Wed, Feb 04, 2009 at 07:25:02PM +0100, clue wrote: ** Tainted: P (1) We can't and won't support binary-only crap. Please reproduce without. Assuming you can reproduce without, it'd be helpful to try and capture backtraces of the running processes. Alt+SysRQ+t will do this. If it works, it will produce a lot of output, so I'd suggest hooking up a serial console if you have one. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508151: Bug#514624: linux-image for sparc64 sungem problems
On Mon, Feb 09, 2009 at 07:54:24PM +, Alexander Clouter wrote: Would you and/or Evgeni be able to test a 2.6.26 build to verify this fix if I provide one? Guess I would be then committing myself to move to lenny sooner rather than later for my co-locatin box :) Sure, why not. On Mon, Feb 09, 2009 at 10:01:34PM +0100, Evgeni Golov wrote: On Mon, 9 Feb 2009 11:43:45 -0700 dann frazier wrote: Would you and/or Evgeni be able to test a 2.6.26 build to verify this fix if I provide one? I've just rebuilt 2.6.29-rc3 with the patch from http://marc.info/?l=linux-netdevm=123393014301523w=2 And it brought up the interface fine. There are some comments in http://marc.info/?l=linux-netdevm=123400984909800w=2 that the patch is good but prolly not enough. For me it is. Bringing the interface up and down works fine, traffic is too. So ACK from me to add this to Lenny r1. I'm transferring a build w/ the fix backported to the lenny kernel to here: http://people.debian.org/~dannf/bugs/514624/ If one or both of you could verify that it resolves the issue for you as well, it'd be appreciated. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514567: alsa hda - backport hardware support changes
Package: linux-2.6 Version: 2.6.26-13 Severity: important Tags: patch Moritz Muehlenhoff pointed me to several changesets that increase/fix hardware supported by alsa. This bug is to track the progress of getting these changes included in the lenny kernel. d5337debacc00591b3f81fc3c982b40af7de1ab6 ALSA: hda - Add quirk for HP 2230s 11d518e07d700eeb5bcec36bfd5f501e405230dd ALSA: hda - Add quirk for HP6730B laptop 65b92e5cbc8acd14ea83190b4d016f765dce6075 ALSA: hda - Add another HP model (6730s) for AD1884A 254248313aed7e6ff295ca21a82ca989b1f69c16 ALSA: hda - Make the HP EliteBook 8530p use AD1884A model laptop 5695ff44160e62d9193c0201706853bcfe2a077f ALSA: hda - Add another HP model for AD1884A f3911c5ab93e4295938b2013104d2986ea601454 ALSA: hda: appletv support e8bfc6c1d22395ab706784cb1bcd60f6f9569ed6 ALSA: HDA: patch_analog: Fix SPDIF output on AD1989B a385a52925398e53bedf1a8b30a9a3e002569f27 ALSA: hda - Add ALC887 support b0fc5e043401df4cd243352f1030c4d23e767347 ALSA: hda - Add a quirk for Dell Studio 15 959973b92d3ba235edfa5dcb5df1be1e5d1deba2 ALSA: hda - Add a quirk for MEDION MD96630 f51ff9937bc6732ed5fc08088fdbe89ab8ed27c3 ALSA: HDA: patch_analog: Quirk for Asus P5Q Premium/Pro boards. 8c650087992f1d7a3a7be2e632f4e85a52d20619 ALSA: hda: Add support for ECS/PC Chips boards with Sigmatel codecs 2346d0cde544179a8d235375f1bfbca5c141a31b ALSA: hda - Add model for Toshiba L305 laptop -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506418: Bugfix in 2.6.18.dfsg.1-24etch1 but not available
On Tue, Feb 03, 2009 at 09:45:15AM +0100, Uwe Jans wrote: Hallo, I found this Bug Report and thought that this Soft Error Bug ist fixed in Version 1-24. But if try to get the latest Version from this Package: linux-image-2.6.18-6-xen-amd64 its only the old 1-23 Version. Where ist the fixed new one? Not in stable?! It is in stable-proposed-updates: http://wiki.debian.org/StableProposedUpdates http://packages.qa.debian.org/l/linux-2.6.html -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514048: Missing dependency on zlib1g-dev
severity 514048 normal thanks On Tue, Feb 03, 2009 at 01:30:28PM -0500, zlinux...@wowway.com wrote: Package: linux-source-2.6.26 Version: 2.6.26-13 Severity: serious Package linux-source-2.6.26 has a missing dependency on package zlib1g-dev. If zlib1g-dev is not installed, make fails, as shown below: lguest.c:34:18: error: zlib.h: No such file or directory make[1]: *** [lguest] Error 1 make[1]: Leaving directory `/usr/src/linux-source-2.6.26/Documentation/lguest' make: *** Well, I don't agree that this is release critical since building the source isn't the only reason you might install this package. But, it probably makes sense to recommend zlib1g-dev (like we do gcc) or - if its not needed in most builds - suggest it like we do ncurses-dev. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512787: GRUB
On Wed, Jan 28, 2009 at 01:15:23PM +0100, Robert Millan wrote: On Tue, Jan 27, 2009 at 10:33:08PM -0700, dann frazier wrote: On Mon, Jan 26, 2009 at 12:44:09AM +0100, Robert Millan wrote: Hi, Please could you try the attached patch and see if it fixes the problem? patch /etc/grub.d/10_linux.in 10_linux.diff update-grub hey Robert, It sure does. And I verified that the problem returns if I revert it again. Thanks. That's very annoying, because it makes no sense. It could be that older versions of GRUB couldn't handle this syntax in the parser. Please could you verify that you're running the latest version? With -14 run grub-install and then check if the problem is still there. After running grub-install I see a new (to me) debian-themed splash screen and it boots fine. If it's not that, the only thing that comes to mind is a memory corruption bug that is merely exposed by moving the search command into a menuentry. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512787: upgrade makes system unbootable
On Sun, Jan 25, 2009 at 11:39:44PM +0100, Robert Millan wrote: On Fri, Jan 23, 2009 at 11:05:16AM -0700, dann frazier wrote: My boot entry looks like this: set root=(hd0,1) search --fs-uuid --set e7bf09bb-8d63-4bbb-84d8-4ada743f643f linux /boot/vmlinuz-2.6.26-1-686 root=UUID=e7bf09bb-8d63-4bbb-84d8-4ada743f643f ro initrd /boot/initrd.img-2.6.26-1-686 I found through experimentation that deleting the first two lines allows my system to boot again. Please run grub-emu and check if the following command: search --fs-uuid --set e7bf09bb-8d63-4bbb-84d8-4ada743f643f causes any oddity (e.g. segfault). No segfault, but: BEGIN CUTPASTE Booting a command list error: unknown command `initrd' Press any key to continue... END CUTPASTE Also, try unsetting the root variable, run the search command, and see if it finds the correct value for it. Looks right to me: grub set root= grub echo $root grub search --fs-uuid --set e7bf09bb-8d63-4bbb-84d8-4ada743f643f grub echo $root hd0,1 -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512787: upgrade makes system unbootable
Package: grub-pc
Version: 1.96+20080724-14
Severity: grave
hey,
After a recent upgrade, my laptop became unbootable. I don't have
local access to the machine rigth now, so unfortunately the preboot
information will have to come from memory.
According to dpkg.log, the upgrade was this one:
2009-01-20 22:37:55 upgrade grub-pc 1.96+20080724-12 1.96+20080724-14
At boot time, grub complains that 'initrd' is an invalid option and
refuses to boot.
My boot entry looks like this:
set root=(hd0,1)
search --fs-uuid --set e7bf09bb-8d63-4bbb-84d8-4ada743f643f
linux /boot/vmlinuz-2.6.26-1-686
root=UUID=e7bf09bb-8d63-4bbb-84d8-4ada743f643f ro
initrd /boot/initrd.img-2.6.26-1-686
I found through experimentation that deleting the first two lines
allows my system to boot again. There are obviously more experiments I
could do - see if just removing one of the two lines fixes things, and
try downgrading to see if it makes my system bootable again. I haven't
had time to do these tests (and probably won't until next week), but I
wanted to get a bug filed in the meantime.
I'll attach my grub.cfg for reference.
--
dann frazier
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/update-grub using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
set root=(hd0,1)
search --fs-uuid --set e7bf09bb-8d63-4bbb-84d8-4ada743f643f
if font /usr/share/grub/ascii.pff ; then
set gfxmode=640x480
insmod gfxterm
insmod vbe
terminal gfxterm
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_hurd ###
### END /etc/grub.d/10_hurd ###
### BEGIN /etc/grub.d/10_linux ###
menuentry Debian GNU/Linux, linux 2.6.26-1-686 {
set root=(hd0,1)
search --fs-uuid --set e7bf09bb-8d63-4bbb-84d8-4ada743f643f
linux /boot/vmlinuz-2.6.26-1-686
root=UUID=e7bf09bb-8d63-4bbb-84d8-4ada743f643f ro
initrd /boot/initrd.img-2.6.26-1-686
}
menuentry Debian GNU/Linux, linux 2.6.26-1-686 (single-user mode) {
set root=(hd0,1)
search --fs-uuid --set e7bf09bb-8d63-4bbb-84d8-4ada743f643f
linux /boot/vmlinuz-2.6.26-1-686
root=UUID=e7bf09bb-8d63-4bbb-84d8-4ada743f643f ro single
initrd /boot/initrd.img-2.6.26-1-686
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file is an example on how to add custom entries
### END /etc/grub.d/40_custom ###
Bug#464068: xserver-xorg: [ia64] black screen, backtrace
On Thu, Jan 22, 2009 at 02:22:34AM +0100, Julien Cristau wrote: Hi dann, sorry for letting this sleep for so long :( On Wed, Feb 06, 2008 at 06:00:13PM -0700, dann frazier wrote: #0 _int_malloc (av=0x206a9148, bytes=24) at malloc.c:4139 p = value optimized out nb = 32 idx = 2 bin = (mbinptr) 0x206a91b8 victim = (mchunkptr) 0x60178a70 size = value optimized out victim_index = value optimized out remainder = value optimized out remainder_size = value optimized out block = value optimized out bit = value optimized out map = value optimized out fwd = value optimized out bck = (mchunkptr) 0x0 #1 0x20520df0 in *__GI___libc_malloc (bytes=24) at malloc.c:3553 ar_ptr = (mstate) 0x206a9148 victim = (void *) 0x206a9148 hook = value optimized out #2 0x403588d0 in LogVMessageVerb (type=X_INFO, verb=3, format=0x4036b538 Bus %s I/O range:\n, args=0x6fefb3c8) at ../../os/log.c:362 s = 0x4037adb8 (II) tmpBuf = value optimized out This is weird... Either glibc is broken, or we have corrupted the heap. On x86 I'd suggest to run X under valgrind, but I don't know how to debug this on ia64 :/ hm.. I only vaguely remember this bug, but things are working fine right now on the same box running sid, so perhaps this can just be closed? -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512463: netrek-client-cow: implicit-pointer-conversions
Package: netrek-client-cow Version: 3.2.9-1 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `query_cowid' implicitly converted to pointer at newwin.c:1232 Function `getaddr2' implicitly converted to pointer at senddist.c:125 Function `query_cowid' implicitly converted to pointer at docwin.c:82 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions diff -urpN netrek-client-cow-3.2.9.orig/docwin.c netrek-client-cow-3.2.9/docwin.c --- netrek-client-cow-3.2.9.orig/docwin.c 2009-01-05 01:17:39.0 -0700 +++ netrek-client-cow-3.2.9/docwin.c 2009-01-20 15:39:55.0 -0700 @@ -27,6 +27,7 @@ #include data.h #include packets.h +extern char *query_cowid(void); /* #ifndef * _IBMR2 * char diff -urpN netrek-client-cow-3.2.9.orig/newwin.c netrek-client-cow-3.2.9/newwin.c --- netrek-client-cow-3.2.9.orig/newwin.c 2009-01-05 01:17:43.0 -0700 +++ netrek-client-cow-3.2.9/newwin.c 2009-01-20 15:32:11.0 -0700 @@ -91,6 +91,7 @@ extern void waraction(W_Event * data); /* Other function declarations */ extern int smessage(char ichar); +extern char *query_cowid(void); static int teamRequest(int team, int ship); diff -urpN netrek-client-cow-3.2.9.orig/senddist.c netrek-client-cow-3.2.9/senddist.c --- netrek-client-cow-3.2.9.orig/senddist.c 2009-01-05 01:17:39.0 -0700 +++ netrek-client-cow-3.2.9/senddist.c 2009-01-20 15:38:51.0 -0700 @@ -16,7 +16,7 @@ #include struct.h #include data.h - +char *getaddr2(int flags, int recip); /* this loads all sorts of useful data into a distress struct. */ struct distress *
Bug#355612: NMU uploaded
diff attached.
diff -u im-sdk-12.3.91/debian/changelog im-sdk-12.3.91/debian/changelog
--- im-sdk-12.3.91/debian/changelog
+++ im-sdk-12.3.91/debian/changelog
@@ -1,3 +1,10 @@
+im-sdk (12.3.91-6.3) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix several implicit pointer conversions (Closes: #355612)
+
+ -- dann frazier da...@debian.org Mon, 19 Jan 2009 16:21:05 -0700
+
im-sdk (12.3.91-6.2) unstable; urgency=medium
* Non-maintainer upload.
only in patch2:
unchanged:
--- im-sdk-12.3.91.orig/debian/patches/060_implicit-pointer-conversions.patch
+++ im-sdk-12.3.91/debian/patches/060_implicit-pointer-conversions.patch
@@ -0,0 +1,421 @@
+diff -urpN iiimf-12.3.91-svn2814.orig/iiimxcf/xiiimp.so/iiimp/iiimpSwitcher.h
iiimf-12.3.91-svn2814/iiimxcf/xiiimp.so/iiimp/iiimpSwitcher.h
+--- iiimf-12.3.91-svn2814.orig/iiimxcf/xiiimp.so/iiimp/iiimpSwitcher.h
2005-08-11 22:38:14.0 -0600
iiimf-12.3.91-svn2814/iiimxcf/xiiimp.so/iiimp/iiimpSwitcher.h
2009-01-12 10:26:57.0 -0700
+@@ -45,6 +45,9 @@ Sun Microsystems, Inc. or its licensors
+
+ #include iiimpIM.h
+
++char **my_strsplit (const char *string,
++ const char *single_delimiter);
++
+ Bool im_switcher_active (XimCommon im);
+ Bool im_switcher_new (XimCommon im);
+ void im_switcher_shutdown (XimCommon im);
+diff -urpN iiimf-12.3.91-svn2814.orig/leif/newpy/xaux/gifalloc.c
iiimf-12.3.91-svn2814/leif/newpy/xaux/gifalloc.c
+--- iiimf-12.3.91-svn2814.orig/leif/newpy/xaux/gifalloc.c 2002-10-31
17:15:38.0 -0700
iiimf-12.3.91-svn2814/leif/newpy/xaux/gifalloc.c 2009-01-12
10:27:01.0 -0700
+@@ -10,6 +10,7 @@
+ * 15 Sep 92 - Version 1.0 by Eric Raymond. *
+ */
+ #include stdio.h
++#include stdlib.h
+ #include gif_lib.h
+
+ #define MAX(x, y) (((x) (y)) ? (x) : (y))
+diff -urpN iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/include/imbean.h
iiimf-12.3.91-svn2814/leif/sch_le_sun/include/imbean.h
+--- iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/include/imbean.h
2005-04-28 06:33:45.0 -0600
iiimf-12.3.91-svn2814/leif/sch_le_sun/include/imbean.h 2009-01-12
10:27:01.0 -0700
+@@ -67,4 +67,7 @@ typedef struct _IbmlData {
+ IbmlCategoryPtr *categories;
+ } IbmlData;
+
++IbmlData *imbean_config_new_from_file(char *file_name);
++IbmlData *imbean_config_new_from_memory(char *buffer, int size);
++
+ #endif/* _IBML_H_ */
+diff -urpN
iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.c
iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.c
+---
iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.c
2005-06-27 21:16:37.0 -0600
iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.c
2009-01-12 10:27:02.0 -0700
+@@ -2,6 +2,7 @@
+ #include palette_pixmap.h
+ #include palette_messages.h
+ #include palette_aux.h
++#include palette_menu.h
+
+ enum {
+ BUTTON_STATE_NORMAL = 0,
+diff -urpN
iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.h
iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.h
+---
iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.h
2005-06-27 21:16:37.0 -0600
iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.h
2009-01-12 10:27:02.0 -0700
+@@ -134,4 +134,9 @@ typedef struct _palette_session_t {
+ char *ime_uuid;
+ } palette_session_t;
+
++palette_window_t *palette_window_new();
++palette_button_t *palette_window_get_button_from_pos(palette_window_t
*palette_window, int x, int y);
++vkb_layout_t *palette_window_get_current_ime_vkb_layout(palette_window_t
*palette_window);
++vkb_layout_t **palette_window_get_vkb_layout_list(palette_window_t
*palette_window);
++
+ #endif/* _PALETTE_AUX_H_ */
+diff -urpN
iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_menu.h
iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_menu.h
+---
iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_menu.h
1969-12-31 17:00:00.0 -0700
iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_menu.h
2009-01-12 10:27:02.0 -0700
+@@ -0,0 +1,18 @@
++#ifndef _PALETTE_MENU_H_
++#define _PALETTE_MENU_H_
++
++#include stdio.h
++#include gdk/gdkx.h
++#include gtk/gtk.h
++#include signal.h
++#include wait.h
++
++#include palette_messages.h
++#include palette_aux.h
++#include vkb_aux.h
++
++GtkWidget *palette_window_create_utility_list_menu(palette_window_t
*palette_window);
++GtkWidget *palette_window_update_utility_list_menu(palette_window_t
*palette_window);
++GtkWidget
Bug#511968: shared imap folders to support redundant buildd admins
Package: buildd.debian.org I've been trying to devise a way to allow for multiple maintainers to share the responsibility of signing logs. Switching the recipient address works, but only if absences are known ahead of time - and that also doesn't facilitate load balancing. One idea is a shared imap folder for logs that can be accessed by the team (and luk suggested I bring that up here). Of course, that implies that messages are signed as they are fetched from the server - I can see that increasing the time it takes to do a signing run. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511598: libical: implicit pointer conversions
Package: libical Version: 0.42-1 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `Parse_MIME_FromFileName' implicitly converted to pointer at /build/buildd/libical-0.42/src/test/regression.c:3534 Function `icalvcal_convert' implicitly converted to pointer at /build/buildd/libical-0.42/src/test/regression.c:3538 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions --- libical-0.43/src/test/regression.c.orig 2009-01-08 09:50:19.0 -0700 +++ libical-0.43/src/test/regression.c 2009-01-12 10:09:49.0 -0700 @@ -34,6 +34,8 @@ #include libical/ical.h #include libical/icalss.h #include libicalvcal/vobject.h +#include libicalvcal/icalvcal.h +#include libicalvcal/vcc.h #include regression.h
Bug#507663: ARtem Onair ComCard 11-variation - the story continues...
aes_generic cbc dm_crypt crypto_blkcipher dm_mirror dm_log dm_snapshot dm_mod ide_cd_mod cdrom ide_disk ata_generic libata scsi_mod ide_pci_generic floppy uhci_hcd piix usbcore ide_core dock 3c59x mii thermal processor fan thermal_sys kernel: [ 8142.000398] Pid: 0, comm: swapper Not tainted 2.6.26-1-686 #1 kernel: [ 8142.000416] [c012256f] warn_on_slowpath+0x40/0x66 kernel: [ 8142.000453] [c01190e6] hrtick_start_fair+0xeb/0x12c kernel: [ 8142.000483] [c01188b2] enqueue_task+0x52/0x5d kernel: [ 8142.000497] [c01188d8] activate_task+0x1b/0x26 kernel: [ 8142.000509] [c011b679] try_to_wake_up+0xe8/0xf1 kernel: [ 8142.000530] [c01318e9] autoremove_wake_function+0xd/0x2d kernel: [ 8142.000553] [c011845d] __wake_up_common+0x2e/0x58 kernel: [ 8142.000573] [c011a641] __wake_up+0x29/0x39 kernel: [ 8142.000592] [c012f067] insert_work+0x58/0x5c kernel: [ 8142.000605] [c012f355] __queue_work+0x1c/0x28 kernel: [ 8142.000618] [c012f3b0] queue_work+0x33/0x3c kernel: [ 8142.000630] [c0266af1] dev_watchdog+0x8f/0xdc kernel: [ 8142.000643] [c0129658] run_timer_softirq+0x11a/0x17c kernel: [ 8142.000659] [c0266a62] dev_watchdog+0x0/0xdc kernel: [ 8142.000679] [c0126579] __do_softirq+0x66/0xd3 kernel: [ 8142.000693] [c012662b] do_softirq+0x45/0x53 kernel: [ 8142.000703] [c01268e2] irq_exit+0x35/0x67 kernel: [ 8142.000711] [c0105f3f] do_IRQ+0x52/0x63 kernel: [ 8142.000735] [c01042a7] common_interrupt+0x23/0x28 kernel: [ 8142.000756] [c01300d8] param_set_charp+0x8/0x48 kernel: [ 8142.000769] [c882e097] acpi_idle_enter_bm+0x2a9/0x317 [processor] kernel: [ 8142.000819] [c02498cd] cpuidle_idle_call+0x5b/0x86 kernel: [ 8142.000834] [c0249872] cpuidle_idle_call+0x0/0x86 kernel: [ 8142.000844] [c01025ce] cpu_idle+0xab/0xcb kernel: [ 8142.000862] === kernel: [ 8142.000868] ---[ end trace 6067a6fdd23a928e ]--- kernel: [ 8142.528737] eth1: New link status: Connected (0001) kernel: [ 8189.211424] eth1: New link status: AP Out of Range (0004) kernel: [ 8189.310660] eth1: New link status: AP In Range (0005) -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511603: linux-image-2.6.26-1-amd64: iwl4965 panic
On Mon, Jan 12, 2009 at 12:01:11PM -0600, Michael Ekstrand wrote: Package: linux-image-2.6.26-1-amd64 Version: 2.6.26-12 Severity: important For some time now, I have been experiencing kernel panics (system frozen, caps lock LED blinking) when using my Intel 4965AGN wireless card (in a Thinkpad R61). I have only noticed the problems when connected to my school's WPA-PEAP network. It usually works for some time and then panics; I am running in X11, so I do not have a dump available presently. I have no problems when wireless is disabled. Based on the timing and the varying natures of networks in which I have and have not observed the problem, I suspect that it is being triggered by roaming between access points on the same network. I do not know if the problem persists or not when using a multi-AP unsecured network. I have no problems on my home network, which is secured with WPA-PSK and has a single access point. I am using wpa_supplicant in roaming mode to manage wireless connectivity. I am using firmware from the firmware-iwlwifi package version 0.14. hey Michael, Please capture and include the panic message. Does this go away if you use a snapshot 2.6.28 build? http://wiki.debian.org/DebianKernel -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#355612: intent to NMU
hey,
As this bug has been open with a patch for over a month and without
a rejection from the maintainer, I intend to NMU the associated package
in a week's time (or sooner, if requested by the maintainer).
If you do not wish for this NMU to occur, please send a follow-up in
the bug report stating as such or, better yet, fix it in an MU :)
Attached is an updated version of the patch included in:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355612#36
This patch updates the EIMIL_get_private prototype to not include the
unused second argument, and drops a few of the changes that have been
included since the 12.3.91-svn2814 release.
diff -urpN iiimf-12.3.91-svn2814.orig/iiimxcf/xiiimp.so/iiimp/iiimpSwitcher.h iiimf-12.3.91-svn2814/iiimxcf/xiiimp.so/iiimp/iiimpSwitcher.h
--- iiimf-12.3.91-svn2814.orig/iiimxcf/xiiimp.so/iiimp/iiimpSwitcher.h 2005-08-11 22:38:14.0 -0600
+++ iiimf-12.3.91-svn2814/iiimxcf/xiiimp.so/iiimp/iiimpSwitcher.h 2009-01-12 10:26:57.0 -0700
@@ -45,6 +45,9 @@ Sun Microsystems, Inc. or its licensors
#include iiimpIM.h
+char **my_strsplit (const char *string,
+ const char *single_delimiter);
+
Bool im_switcher_active (XimCommon im);
Bool im_switcher_new (XimCommon im);
void im_switcher_shutdown (XimCommon im);
diff -urpN iiimf-12.3.91-svn2814.orig/leif/newpy/xaux/gifalloc.c iiimf-12.3.91-svn2814/leif/newpy/xaux/gifalloc.c
--- iiimf-12.3.91-svn2814.orig/leif/newpy/xaux/gifalloc.c 2002-10-31 17:15:38.0 -0700
+++ iiimf-12.3.91-svn2814/leif/newpy/xaux/gifalloc.c 2009-01-12 10:27:01.0 -0700
@@ -10,6 +10,7 @@
* 15 Sep 92 - Version 1.0 by Eric Raymond. *
*/
#include stdio.h
+#include stdlib.h
#include gif_lib.h
#define MAX(x, y) (((x) (y)) ? (x) : (y))
diff -urpN iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/include/imbean.h iiimf-12.3.91-svn2814/leif/sch_le_sun/include/imbean.h
--- iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/include/imbean.h 2005-04-28 06:33:45.0 -0600
+++ iiimf-12.3.91-svn2814/leif/sch_le_sun/include/imbean.h 2009-01-12 10:27:01.0 -0700
@@ -67,4 +67,7 @@ typedef struct _IbmlData {
IbmlCategoryPtr *categories;
} IbmlData;
+IbmlData *imbean_config_new_from_file(char *file_name);
+IbmlData *imbean_config_new_from_memory(char *buffer, int size);
+
#endif/* _IBML_H_ */
diff -urpN iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.c iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.c
--- iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.c 2005-06-27 21:16:37.0 -0600
+++ iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.c 2009-01-12 10:27:02.0 -0700
@@ -2,6 +2,7 @@
#include palette_pixmap.h
#include palette_messages.h
#include palette_aux.h
+#include palette_menu.h
enum {
BUTTON_STATE_NORMAL = 0,
diff -urpN iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.h iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.h
--- iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.h 2005-06-27 21:16:37.0 -0600
+++ iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_aux.h 2009-01-12 10:27:02.0 -0700
@@ -134,4 +134,9 @@ typedef struct _palette_session_t {
char *ime_uuid;
} palette_session_t;
+palette_window_t *palette_window_new();
+palette_button_t *palette_window_get_button_from_pos(palette_window_t *palette_window, int x, int y);
+vkb_layout_t *palette_window_get_current_ime_vkb_layout(palette_window_t *palette_window);
+vkb_layout_t **palette_window_get_vkb_layout_list(palette_window_t *palette_window);
+
#endif/* _PALETTE_AUX_H_ */
diff -urpN iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_menu.h iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_menu.h
--- iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_menu.h 1969-12-31 17:00:00.0 -0700
+++ iiimf-12.3.91-svn2814/leif/sch_le_sun/src/auxiliary_windows/gtk2/palette_menu.h 2009-01-12 10:27:02.0 -0700
@@ -0,0 +1,18 @@
+#ifndef _PALETTE_MENU_H_
+#define _PALETTE_MENU_H_
+
+#include stdio.h
+#include gdk/gdkx.h
+#include gtk/gtk.h
+#include signal.h
+#include wait.h
+
+#include palette_messages.h
+#include palette_aux.h
+#include vkb_aux.h
+
+GtkWidget *palette_window_create_utility_list_menu(palette_window_t *palette_window);
+GtkWidget *palette_window_update_utility_list_menu(palette_window_t *palette_window);
+GtkWidget *palette_window_create_vkb_list_menu(palette_window_t *palette_window);
+GtkWidget *palette_window_update_vkb_list_menu(palette_window_t *palette_window);
+#endif
diff -urpN iiimf-12.3.91-svn2814.orig/leif/sch_le_sun/src/auxiliary_windows/gtk2/property_data.h
Bug#401439: parisc: xfs module loading bug
On Tue, Jan 06, 2009 at 10:08:39AM +0100, Helge Deller wrote: Patches which solves the xfs loading bug on parisc has been accepted upstream. Mainstream Kernel 2.6.29 will contain the fix. Description of the problem: http://marc.info/?l=linux-kernelm=123055968113465w=2 Needed patches which were accepted upstream: a) module: fix module loading failure of large kernel modules for parisc http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=088af9a6e05d51e7c3dc85d45d8b7a52c3ee08d7;hp=d1e99d7ae4e6bbd1ebb5e81ecd3af2b8793efee0 b) parisc: fix module loading failure of large kernel modules http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c298be74492bece102f3379d14015638f1fd1fac;hp=088af9a6e05d51e7c3dc85d45d8b7a52c3ee08d7 Maybe it would make sense to backport those fixes in the debian kernel for lenny. Yeah, I was just waiting for these to go upstream. Now that they are, it shouldn't be a problem. Debian bug reports which refer to this issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401439 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350482 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401439 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508489 Appreciated, thanks! -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511021: linux-headers-2.6.24-etchnhalf.1-686: Can not build out-of-tree kernel modules
On Tue, Jan 06, 2009 at 07:47:10PM +0100, Reiner Buehl wrote: Package: linux-headers-2.6.24-etchnhalf.1-686 Version: 2.6.24-6~etchnhalf.7 Severity: grave Justification: renders package unusable When trying to build out-of-tree kernel modules like lirc-modules-source, the build with m-a fails after this message: /usr/bin/make -C /lib/modules/2.6.24-etchnhalf.1-686/build SUBDIRS=/usr/src/modules/lirc/drivers/lirc_dev modules \ KBUILD_VERBOSE=1 make[5]: Entering directory `/usr/src/linux-headers-2.6.24-etchnhalf.1-686' test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( echo; \ echo ERROR: Kernel configuration is invalid.; \ echo include/linux/autoconf.h or include/config/auto.conf are missing.;\ echo Run 'make oldconfig make prepare' on kernel src to fix it.;\ echo; \ /bin/false) After this message the build fails. This isn't a defect with the headers, rather some module packages in etch are only compatible with 2.6.18. See the limitations section here, specifically the last bullet: http://www.debian.org/releases/etch/etchnhalf To verify that the headers themselves are sane, you can try building a package that is known to work, e.g. squashfs-source-etchnhalf. For lirc, in particularly, you might have luck using the lirc packages from testing. It might be compatible with 2.6.24, but there are no guarantees. An etch solution would be to stick with 2.6.18, assuming it supports your system. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504028: FTBFS: /usr/bin/m4:stdin:9: ERROR: end of file in string
On Tue, Jan 06, 2009 at 08:08:08PM +0100, Cyril Brulebois wrote: dann frazier da...@debian.org (30/10/2008): Package: apertium Version: 3.0.7+1-2 Severity: serious As noted in #500171, apertium no longer builds from source. I've reproduced this on both ia64 and i386 (haven't tried others) in latest sid. Downgrading flex from 2.5.35-3 to 2.5.35-2 fixes the problem on i386 but, of course, that would re-introduce #501960 (FTBFS ia64). Hello Dann, I can't reproduce it (with amd64 but oh well), is this bug still valid? The blocking bug #504030 was closed, reopened as #505056, which has been fixed lately (apertium/ia64 given back with a dep-wait). #500171 went away as well. Are there more problems with apertium? If so, can we have logs, please? It is still a problem w/ flex 2.5.35-5. 2.5.35-6/ia64 hasn't uploaded yet, but I'll try a local build. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504028: FTBFS: /usr/bin/m4:stdin:9: ERROR: end of file in string
On Tue, Jan 06, 2009 at 02:51:14PM -0700, dann frazier wrote: On Tue, Jan 06, 2009 at 08:08:08PM +0100, Cyril Brulebois wrote: dann frazier da...@debian.org (30/10/2008): Package: apertium Version: 3.0.7+1-2 Severity: serious As noted in #500171, apertium no longer builds from source. I've reproduced this on both ia64 and i386 (haven't tried others) in latest sid. Downgrading flex from 2.5.35-3 to 2.5.35-2 fixes the problem on i386 but, of course, that would re-introduce #501960 (FTBFS ia64). Hello Dann, I can't reproduce it (with amd64 but oh well), is this bug still valid? The blocking bug #504030 was closed, reopened as #505056, which has been fixed lately (apertium/ia64 given back with a dep-wait). #500171 went away as well. Are there more problems with apertium? If so, can we have logs, please? It is still a problem w/ flex 2.5.35-5. 2.5.35-6/ia64 hasn't uploaded yet, but I'll try a local build. Seems to work fine with flex_.5.35-6. Assuming that version migrates (needs 2 days) this bug should be resolved for lenny. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#401439: parisc: xfs module loading bug
On Tue, Jan 06, 2009 at 09:26:33AM -0700, dann frazier wrote: On Tue, Jan 06, 2009 at 10:08:39AM +0100, Helge Deller wrote: Patches which solves the xfs loading bug on parisc has been accepted upstream. Mainstream Kernel 2.6.29 will contain the fix. Description of the problem: http://marc.info/?l=linux-kernelm=123055968113465w=2 Needed patches which were accepted upstream: a) module: fix module loading failure of large kernel modules for parisc http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=088af9a6e05d51e7c3dc85d45d8b7a52c3ee08d7;hp=d1e99d7ae4e6bbd1ebb5e81ecd3af2b8793efee0 b) parisc: fix module loading failure of large kernel modules http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c298be74492bece102f3379d14015638f1fd1fac;hp=088af9a6e05d51e7c3dc85d45d8b7a52c3ee08d7 Unfortunately, b) is an (hppa-specific) ABI breaker. I'm guessing its the changes to struct mod_arch_specific, but I haven't proven that yet. We could try ignoring the change - but I'm not sure how dangerous that would be. Is this structure known to modules, or is it just used in the core? That is, if you tried to load modules built w/ this patch into a kernel that didn't have this patch, would that be safe? Maybe it would make sense to backport those fixes in the debian kernel for lenny. Yeah, I was just waiting for these to go upstream. Now that they are, it shouldn't be a problem. Debian bug reports which refer to this issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401439 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350482 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401439 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508489 Appreciated, thanks! -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508108: Reopening, bug not fixed in 2.6.26-12
On Mon, Jan 05, 2009 at 07:01:17AM +0100, Christian Perrier wrote: Quoting Jurij Smakov (ju...@wooyd.org): Please enable them for the next upload (which will hopefully make it into lenny). If we want to release lenny some day, maybe not. D-I RC2 was delayed partly because of -12. Now that everything is in place for a release to happen (including the D-I RM back from holidays), I'm not sure that another delay is really welcome. Could we document that issue in the errata? ..and perhaps we can queue it up for r1? Can someone test a snapshot build if I prepare one to make sure our fix is correct? -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508108: Reopening, bug not fixed in 2.6.26-12
On Mon, Jan 05, 2009 at 08:37:28PM +, Jurij Smakov wrote: On Mon, Jan 05, 2009 at 10:41:54AM -0700, dann frazier wrote: On Mon, Jan 05, 2009 at 07:01:17AM +0100, Christian Perrier wrote: Quoting Jurij Smakov (ju...@wooyd.org): Please enable them for the next upload (which will hopefully make it into lenny). If we want to release lenny some day, maybe not. D-I RC2 was delayed partly because of -12. Now that everything is in place for a release to happen (including the D-I RM back from holidays), I'm not sure that another delay is really welcome. Could we document that issue in the errata? ..and perhaps we can queue it up for r1? Can someone test a snapshot build if I prepare one to make sure our fix is correct? Sure, I can test it. Thanks Jurij. Can you try one of these? http://people.debian.org/~dannf/bugs/508108/ -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510914: ruby1.9: should maybe build-dep on procps
Package: ruby1.9 Version: 1.9.0.2-9 Severity: normal I noticed the hppa buildd log has a lot of these messages: /bin/sh: line 2: ps: command not found Should ruby1.9 build-dep on procps? -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Kernel: Linux 2.6.26-1-mckinley (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages ruby1.9 depends on: ii libc6.1 2.7-16 GNU C Library: Shared libraries ii libruby1.91.9.0.2-9 Libraries necessary to run Ruby 1. ruby1.9 recommends no packages. Versions of packages ruby1.9 suggests: pn rdoc1.9 none (no description available) pn ri1.9 none (no description available) pn ruby1.9-examples none (no description available) pn rubygems1.9 none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510363: gxine: get_config_filename implicitly converted to pointer
Package: gxine Version: 0.5.903-3 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `get_config_filename' implicitly converted to pointer at server.c:186 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions --- gxine-0.5.903.orig/src/server.c 2008-12-31 15:04:24.0 -0700 +++ gxine-0.5.903/src/server.c 2008-12-31 15:11:10.0 -0700 @@ -35,6 +35,7 @@ #include globals.h #include engine.h #include server.h +#include utils.h /* #define LOG
Bug#509698: cherokee: ldap_init implicitly converted to pointer
Package: cherokee Version: 0.11.3-2 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `ldap_init' implicitly converted to pointer at validator_ldap.c:161 This is often due to a missing function prototype definition. For more information, see [2]. The libldap API has been updated and many functions used by the ldap plugin are now deprecated. This package should either update to the new API or define LDAP_DEPRECATED to continue using the deprecated interfaces. This patch implements the lazy solution. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. (oh, and hi Gunnar!) [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions -- dann frazier diff -urpN cherokee-0.11.5.orig/cherokee/validator_ldap.h cherokee-0.11.5/cherokee/validator_ldap.h --- cherokee-0.11.5.orig/cherokee/validator_ldap.h 2008-12-18 08:17:53.0 -0700 +++ cherokee-0.11.5/cherokee/validator_ldap.h 2008-12-24 15:44:56.0 -0700 @@ -27,6 +27,7 @@ #include common.h +#define LDAP_DEPRECATED 1 #include ldap.h #include validator.h
Bug#509279: patch
tag 509279 + patch
thanks
diff -urpN bash-3.2.orig/examples/misc/aliasconv.bash
bash-3.2/examples/misc/aliasconv.bash
--- bash-3.2.orig/examples/misc/aliasconv.bash 2005-07-09 07:52:53.0
-0600
+++ bash-3.2/examples/misc/aliasconv.bash 2008-12-23 10:36:42.0
-0700
@@ -7,11 +7,14 @@
# Chet Ramey
# c...@po.cwru.edu
#
-trap 'rm -f /tmp/cb$$.?' 0 1 2 3 6 15
+
+tmpfile=`mktemp`
+
+trap 'rm -f $tmpfile' 0 1 2 3 6 15
T=$'\t'
-cat \EOF /tmp/cb$$.1
+cat \EOF $tmpfile
mkalias ()
{
case $2 in
@@ -28,12 +31,12 @@ mkalias ()
EOF
# the first thing we want to do is to protect single quotes in the alias,
-# since they whole thing is going to be surrounded by single quotes when
+# since the whole thing is going to be surrounded by single quotes when
# passed to mkalias
-sed -e s:':\\'\\\'\\': -e s/^\([a-zA-Z0-9_-]*\)$T\(.*\)$/mkalias \1 '\2'/
/tmp/cb$$.1
+sed -e s:':\\'\\\'\\': -e s/^\([a-zA-Z0-9_-]*\)$T\(.*\)$/mkalias \1 '\2'/
$tmpfile
-$BASH /tmp/cb$$.1 | sed -e 's/\$cwd/\$PWD/g' \
+$BASH $tmpfile | sed -e 's/\$cwd/\$PWD/g' \
-e 's/\$term/\$TERM/g' \
-e 's/\$home/\$HOME/g' \
-e 's/\$user/\$USER/g' \
diff -urpN bash-3.2.orig/examples/misc/aliasconv.sh
bash-3.2/examples/misc/aliasconv.sh
--- bash-3.2.orig/examples/misc/aliasconv.sh2002-11-30 15:20:23.0
-0700
+++ bash-3.2/examples/misc/aliasconv.sh 2008-12-23 10:36:37.0 -0700
@@ -7,11 +7,14 @@
# Chet Ramey
# c...@po.cwru.edu
#
-trap 'rm -f /tmp/cb$$.?' 0 1 2 3 6 15
+
+tmpfile=`mktemp`
+
+trap 'rm -f $tmpfile' 0 1 2 3 6 15
T=''
-cat \EOF /tmp/cb$$.1
+cat \EOF $tmpfile
mkalias ()
{
case $2 in
@@ -28,15 +31,15 @@ mkalias ()
EOF
# the first thing we want to do is to protect single quotes in the alias,
-# since they whole thing is going to be surrounded by single quotes when
+# since the whole thing is going to be surrounded by single quotes when
# passed to mkalias
-sed -e s:':\\'\\\'\\': -e s/^\([a-zA-Z0-9_-]*\)$T\(.*\)$/mkalias \1 '\2'/
/tmp/cb$$.1
+sed -e s:':\\'\\\'\\': -e s/^\([a-zA-Z0-9_-]*\)$T\(.*\)$/mkalias \1 '\2'/
$tmpfile
-sh /tmp/cb$$.1 | sed -e 's/\$cwd/\$PWD/g' \
--e 's/\$term/\$TERM/g' \
--e 's/\$home/\$HOME/g' \
--e 's/\$user/\$USER/g' \
--e 's/\$prompt/\$PS1/g'
+sh $tmpfile | sed -e 's/\$cwd/\$PWD/g' \
+ -e 's/\$term/\$TERM/g' \
+ -e 's/\$home/\$HOME/g' \
+ -e 's/\$user/\$USER/g' \
+ -e 's/\$prompt/\$PS1/g'
exit 0
diff -urpN bash-3.2.orig/examples/misc/cshtobash
bash-3.2/examples/misc/cshtobash
--- bash-3.2.orig/examples/misc/cshtobash 2002-11-30 15:23:41.0
-0700
+++ bash-3.2/examples/misc/cshtobash2008-12-23 10:36:28.0 -0700
@@ -15,25 +15,32 @@
# Chet Ramey
# c...@po.cwru.edu
#
-trap 'rm -f /tmp/cb$$.? cshout cshin' 0 1 2 3 6 15
+tmp=`mktemp`
+aliastmp=`mktemp`
+envtmp=`mktemp`
+vartmp=`mktemp`
+cshout=`mktemp`
+cshin=`mktemp`
+
+trap 'rm -f $tmp $aliastmp $envtmp $vartmp $cshout $cshin' 0 1 2 3 6 15
T=$'\t'
SOURCE=${1:+source $1}
-cat EOF cshin
+cat EOF $cshin
$SOURCE
-alias ! /tmp/cb$$.a
-setenv ! /tmp/cb$$.e
-set ! /tmp/cb$$.v
+alias ! $aliastmp
+setenv ! $envtmp
+set ! $vartmp
EOF
# give csh a minimal environment, similar to what login would provide
-/usr/bin/env - USER=$USER HOME=$HOME PATH=/usr/bin:/bin:/usr/ucb:. TERM=$TERM
SHELL=$SHELL /bin/csh -i ./cshin cshout 21
+/usr/bin/env - USER=$USER HOME=$HOME PATH=/usr/bin:/bin:/usr/ucb:. TERM=$TERM
SHELL=$SHELL /bin/csh -i $cshin $cshout 21
# First convert aliases
-cat \EOF /tmp/cb$$.1
+cat \EOF $tmp
mkalias ()
{
case $2 in
@@ -49,16 +56,16 @@ mkalias ()
}
EOF
-sed s/^\([a-zA-Z0-9_]*\)$T\(.*\)$/mkalias \1 '\2'/ /tmp/cb$$.a
/tmp/cb$$.1
+sed s/^\([a-zA-Z0-9_]*\)$T\(.*\)$/mkalias \1 '\2'/ $aliastmp $tmp
echo '# csh aliases'
echo
-$BASH /tmp/cb$$.1 | sed -e 's/\$cwd/\$PWD/g' \
- -e 's/\$term/\$TERM/g' \
- -e 's/\$home/\$HOME/g' \
- -e 's/\$user/\$USER/g' \
- -e 's/\$prompt/\$PS1/g'
+$BASH $tmp | sed -e 's/\$cwd/\$PWD/g' \
+-e 's/\$term/\$TERM/g' \
+-e 's/\$home/\$HOME/g' \
+-e 's/\$user/\$USER/g' \
+-e 's/\$prompt/\$PS1/g'
# Next, convert environment variables
echo
@@ -70,7 +77,7 @@ sed -e '/^SHLVL/d' \
-e '/^PWD/d' \
-e s/'/'''/g \
-e s/^\([A-Za-z0-9_]*=\)/export \1'/ \
--e s/$/'/ /tmp/cb$$.e
+-e s/$/'/ $envtmp
# Finally, convert local variables
echo
@@ -82,7 +89,7 @@ sed -e 's/'$T'/=/' \
-e '/^[A-Za-z0-9_]*=[^(]/{
s/=/=''/'
s/$/''/'
- }' /tmp/cb$$.v |
+ }' $vartmp |
sed -e '/^argv=/d' -e '/^cwd=/d' -e '/^filec=/d' -e '/^status=/d' \
-e '/^verbose=/d' \
-e '/^term=/d' \
@@ -110,7 +117,7 @@ echo
Bug#508820: linux-image-2.6.26-1-mckinley: MCA and panic after bringing up loopback interface on ia64
On Mon, Dec 15, 2008 at 11:36:37AM -0700, Aaron D. Johnson wrote: Package: linux-image-2.6.26-1-mckinley Version: 2.6.26-11 Severity: grave Justification: renders package unusable Attempting to boot linux-image-2.6.26-1-mckinley (2.6.26-11) as an HP Integrity Virtual Machines guest OS results in a panic during network startup. Console messages leading up to this: [...] [16578579.202741] EXT3 FS on dm-1, internal journal [16578579.204938] EXT3-fs: mounted filesystem with ordered data mode. done. Activating swapfile swap...[16578579.463160] Adding 4194272k swap on /dev/mapper/vg00-swap. Priority:-1 extents:1 across:4194272k done. Setting up networking Configuring network interfaces...[16578581.213754] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [16578582.433694] NET: Registered protocol family 10 [16578582.437702] lo: Disabled Privacy Extensions [16578582.580016] Entered OS MCA handler. PSP=fff2e12c cpu=1 monarch=1 [16578582.580019] All OS MCA slaves have reached rendezvous [16578582.607085] mlogbuf_finish: printing switched to urgent mode, MCA/INIT might be dodgy or fail. [16578582.611888] Delaying for 5 seconds... I've got a theory - can you search the /var/log/kern.log* files on this guest for any Oops messages? Do you recall experiencing a hang during your kernel upgrade? I'm wondering if there was an oops at the time you upgraded your kernel package. Also, can you mount your efi partition and capture the md5sums of the files under /boot/efi/efi/debian? If my theory is correct, you may be able to get back up and running by booting an older kernel (if you have one), running 'elilo', then booting back into the 2.6.26-11 kernel. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508820: linux-image-2.6.26-1-mckinley: MCA and panic after bringing up loopback interface on ia64
On Tue, Dec 16, 2008 at 10:08:59AM -0700, Aaron D. Johnson wrote: dann frazier writes: I've got a theory - can you search the /var/log/kern.log* files on this guest for any Oops messages? No Oopses going back to 3 Dec: ajohn...@spielplatz:~$ sudo zgrep -i oops /var/log/kern.log* ajohn...@spielplatz:~$ sudo gzip -dc /var/log/kern.log.6.gz | head -n 1 Dec 3 06:26:12 spielplatz kernel: [15525239.819366] postgres(22142): floating-point assist fault at ip 403de402, isr 0408 ajohn...@spielplatz:~$ Countless floating-point assist fault messages, though. It seems that PostgreSQL needs some help in this department. Do you recall experiencing a hang during your kernel upgrade? I remember a hang on shutdown for some system during the last week, but nothing during the kernel package upgrade proper. I'm wondering if there was an oops at the time you upgraded your kernel package. Also, can you mount your efi partition and capture the md5sums of the files under /boot/efi/efi/debian? ajohn...@spielplatz:~$ sudo mount -v -t vfat -o ro /dev/sda1 /mnt ajohn...@spielplatz:~$ md5sum /mnt/efi/debian/* 9fa2639fa5dca1521df76c7c254f4e04 /mnt/efi/debian/elilo.conf 5bec2375858e01c4590976f3fb479a3c /mnt/efi/debian/elilo.efi f6d26c846defcbb6a255365b32205e69 /mnt/efi/debian/initrd.img f43e07c02fff08489e5d1f60dc0046ae /mnt/efi/debian/initrd.img.old 35a0f1cd6e79fc7ffd93ca1dddb5df01 /mnt/efi/debian/readme.txt 384b24d661e30ca549569954ab9dc3ae /mnt/efi/debian/vmlinuz 67a9622f681abd91cc4710da8894b743 /mnt/efi/debian/vmlinuz.old ajohn...@spielplatz:~$ If my theory is correct, you may be able to get back up and running by booting an older kernel (if you have one), running 'elilo', then booting back into the 2.6.26-11 kernel. OK, so that worked. What change did re-running elilo make? Based on the MD5sums, there are new initrd and vmlinuz files. Seems like installing kernel-image-2.6.26-1-mckinley should have done that in its postinst script. Here's what I think happened: - Running 2.6.26-8 - Upgraded to 2.6.26-11 - unpacked 2.6.26-11 - generated initramfs - called elilo - elilo loads modules it needs to mount EFI partition, but the modules available are now for 2.6.26-11 and are incompatible with 2.6.26-8. - system tries to mount efi partition and hangs due to incompatible modules - kernel/initrd in the efi partition is now out of date with respect to the files in /boot - system boots 2.6.26-8 again - initramfs loads, works fine (still using 2.6.26-8 initramfs) - system mounts root - system starts loading modules from the root partition (which are now 2.6.26-11 modules), and does bad things. The bug would therefore be that we created a kernel with the same abiname that was actually incompatible with the modules from an earlier release. What happens to the poor user who doesn't know to re-run elilo? (Not that I expect there are too many poor users running ia64 systems.) Unfortunately, I don't know that there's anyway to retroactively solve this problem. The cat is out of the bag, as they say. It would be a nice safety procedure to make sure the modules we need are loaded before we unpack the new modules - i.e., in the preinst. One way to do this would be to call 'elilo' in the preinst. Savy users can configure their systems to do this themselves by adding a preinst hook in /etc/kernel-img.conf. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508875: gnu-fdisk: completion_matches implicitly converted to pointer
Package: gnu-fdisk Version: 1.1-1 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `completion_matches' implicitly converted to pointer at ui.c:189 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions --- gnu-fdisk-1.1.orig/src/ui.c 2008-11-07 05:54:51.0 -0700 +++ gnu-fdisk-1.1/src/ui.c 2008-12-15 23:44:43.0 -0700 @@ -85,10 +85,6 @@ # endif -# ifndef HAVE_RL_COMPLETION_MATCHES -# define rl_completion_matches completion_matches -# endif - # ifndef rl_compentry_func_t # define rl_compentry_func_t void # endif -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508493: closed by Bastian Blank wa...@debian.org (Re: Bug#508493: [linux-2.6] please package 2.6.27)
On Thu, Dec 11, 2008 at 03:55:34PM -0800, Thomas Bushnell BSG wrote: reopen 508493 thanks I'm not sure I understand why you closed the wishlist bug. A freeze, as I understand it, is not about *never* installing a new version, but rather *waiting* until the release is made. It's perfectly normal to have a wishlist bug for a new version--it's not a demand for anything, still less a request for breaking the freeze--just a note, hey, this would be good. Then, when the release is made, kernel version 2.6.27 (or later) can be packaged and the wishlist bug closed. That's the point of wishlist bugs. There is nothing inappropriate about a bug (wishlist or otherwise) being filed which cannot be closed during the freeze; the correct response, as I understand it, is to leave the bug open, perhaps with an email to the bug log explaining the situation. But from the exasperated tone of your message, it seems likely that I have misunderstood what a freeze means. I outline above my understanding. Can you perhaps elaborate on what I have incorrectly understood about what a freeze means? snapshot builds of 2.6.27 are already available - see the wiki page Bastian directed you to. Obviously that's not the same as being in the archive proper, but that's not going to happen till after lenny. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508221: pidgin-sipe: Please package new upstream version
Package: pidgin-sipe Version: 1.2-1 Severity: wishlist Me and several of my coworkers are pretty interested in the 1.3 release because it will let us begin to use our new corporate-standard instant messaging system natively on linux. I know we're still in the lenny freeze, but any chance we can get a new upstream version in experimental? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Kernel: Linux 2.6.26-1-mckinley (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages pidgin-sipe depends on: ii libc6.1 2.7-16 GNU C Library: Shared libraries ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii pidgin2.4.3-4graphical multi-protocol instant m pidgin-sipe recommends no packages. pidgin-sipe suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#508231: ipmitool: misspelling of included
Package: ipmitool Version: 1.8.9-1 Severity: minor Tags: patch diff -urpN ipmitool-1.8.9.orig/README ipmitool-1.8.9/README --- ipmitool-1.8.9.orig/README 2005-01-06 12:13:51.0 -0700 +++ ipmitool-1.8.9/README 2008-12-08 18:12:15.0 -0700 @@ -24,7 +24,7 @@ Background == I originally wrote ipmitool while between projects and employeed at Sun Microsystems. Sun had just embarked on a new line of general-purpose x86 -servers that inclued an OEM Intel board with an IPMIv1.5 BMC on board. +servers that included an OEM Intel board with an IPMIv1.5 BMC on board. It started with an idea that remote chassis power control would be a handy feature for my systems in the lab and from there it grew into a multi- purpose tool that lots of people found useful. I decided to release it diff -urpN ipmitool-1.8.9.orig/doc/ipmitool.1 ipmitool-1.8.9/doc/ipmitool.1 --- ipmitool-1.8.9.orig/doc/ipmitool.1 2007-03-06 15:15:36.0 -0700 +++ ipmitool-1.8.9/doc/ipmitool.1 2008-12-08 18:11:56.0 -0700 @@ -39,7 +39,7 @@ chassis power control. IPMI management of a local system interface requires a compatible IPMI kernel driver to be installed and configured. On Linux this driver is called \fIOpenIPMI\fP and it is included in standard distributions. -On Solaris this driver is called \fIBMC\fP and is inclued in Solaris 10. +On Solaris this driver is called \fIBMC\fP and is included in Solaris 10. Management of a remote station requires the IPMI\-over\-LAN interface to be enabled and configured. Depending on the particular requirements of each system it may be possible to enable the LAN interface using ipmitool over -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Kernel: Linux 2.6.26-1-mckinley (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages ipmitool depends on: ii libc6.1 2.7-16 GNU C Library: Shared libraries ii libncurses5 5.7+20081129-1 shared libraries for terminal hand ii libreadline5 5.2-3 GNU readline and history libraries ii libssl0.9.8 0.9.8g-14 SSL shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ipmitool recommends no packages. Versions of packages ipmitool suggests: ii openipmi 2.0.14-2 Intelligent Platform Management In -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#508092: includes .svn directories
Package: eresi Version: 1:0.8a25-1 The eresi source package includes .svn subdirectories. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#508094: eresi: etrace_geterrfunc implicitly converted to pointer
Package: eresi Version: 1:0.8a25-1 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `etrace_geterrfunc' implicitly converted to pointer at fini.c:49 Function `etrace_geterrfunc' implicitly converted to pointer at fini.c:49 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions --- eresi-0.8a25/librevm/vm/fini.c.orig 2008-12-07 13:36:35.0 -0700 +++ eresi-0.8a25/librevm/vm/fini.c 2008-12-07 13:36:41.0 -0700 @@ -7,6 +7,7 @@ * $Id: fini.c,v 1.1 2008-02-16 12:32:27 thor Exp $ */ #include revm.h +#include ../../libetrace/include/libetrace.h /* Some REVM context cleanup when coming back from script to interactive mode */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505459: issue still exists
reopen 505459 found 505459 0.4.8~dfsg-1 thanks This issue still exists. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507619: MODULES=most fails w/ cciss devices
Package: initramfs-tools
Version: 0.92l
Severity: important
Tags: patch
A coworker reported a lenny install failure today. Turns out he had
asked the installer to run mkinitramfs w/ MODULES=dep, which I'd never
tried before:
dl380g5:/home/dannf# mkinitramfs-kpkg -o /boot/initrd.img-2.6.26-1-686
2.6.26-1-686
mkinitramfs: missing cciss/c0d0p root /dev/cciss/c0d0p1 /sys entry
mkinitramfs: workaround is MODULES=most
mkinitramfs: Error please report the bug
dep_add_modules() expects to find a /sys/block/cciss/c0d0p file, but
it should be trying /sys/block/cciss!c0d0:
dl380g5:/tmp/initramfs# ls /sys/block/
cciss!c0d0 loop0 loop3 loop6 ram0 ram11 ram14 ram3 ram6 ram9
cciss!c0d1 loop1 loop4 loop7 ram1 ram12 ram15 ram4 ram7 sr0
cciss!c0d2 loop2 loop5 md0ram10 ram13 ram2 ram5 ram8
The following patch seems to fix it for me:
--- /usr/share/initramfs-tools/hook-functions.orig 2008-12-02
16:58:05.0 -0700
+++ /usr/share/initramfs-tools/hook-functions 2008-12-02 16:58:53.0
-0700
@@ -269,6 +269,9 @@
root=${root#/dev/}
block=$(awk /^${root}/{print substr(\$5, 1, 3); exit} \
/proc/mdstat)
+ elif [ ${root#/dev/cciss/} != ${root} ]; then
+ block=${root#/dev/cciss/*}
+ block=cciss!${block%p*}
# classical root device
else
block=${root#/dev/}
fyi, I suspect this may also apply to old-style smart array devices,
where device names are similar, but use 'ida' intead of 'cciss' -
e.g. /dev/ida/c0d0p1.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506350: patch
Thanks for the report. Does this patch look sufficient to you?
--- flamethrower-0.1.8.orig/bin/flamethrower
+++ flamethrower-0.1.8/bin/flamethrower
@@ -9,6 +9,7 @@
use strict;
use File::Path;
+use File::Temp;
use Getopt::Long;
use lib /usr/lib/flamethrower;
@@ -23,7 +24,7 @@
my $version_number = INS_VERSION;
my $conf_file = '/etc/flamethrower/flamethrower.conf';
my $transport = udp-receiver;
-my $tmp_dir = /tmp/.flamethrower.$$;
+my $tmp_dir = File::Temp::tempdir(/tmp/flamethrower.XX);
my $version_info = EOF;
@@ -283,13 +284,16 @@
#
my $udp_cmd;
my $tar_cmd;
+my $tar_fh;
+my $tar_file;
+($tar_fh, $tar_file) = File::Temp::tempfile(/tmp/multicast.tar.XX);
if($verbose) {
-$udp_cmd = udp-receiver $udp_receiver_options --file
/tmp/multicast.tar.$$;
-$tar_cmd = tar $tar_opts -C $dir -f /tmp/multicast.tar.$$;
+$udp_cmd = udp-receiver $udp_receiver_options --file $tar_file;
+$tar_cmd = tar $tar_opts -C $dir -f $tar_file;
} else {
-$udp_cmd = udp-receiver $udp_receiver_options --file
/tmp/multicast.tar.$$ 2/dev/null;
-$tar_cmd = tar $tar_opts -C $dir -f /tmp/multicast.tar.$$;
+$udp_cmd = udp-receiver $udp_receiver_options --file $tar_file
2/dev/null;
+$tar_cmd = tar $tar_opts -C $dir -f $tar_file;
}
print $udp_cmd\n if($verbose);
@@ -298,7 +302,8 @@
print $tar_cmd\n if($verbose);
!system($tar_cmd) or die(FAILED: $tar_cmd);
-unlink(/tmp/multicast.tar.$$);
+close $tar_fh;
+unlink($tar_file);
}
--
dann frazier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493768: NMU uploaded to DELAYED/7-day
Patch attached. diff -u jabberd2-2.2.1/debian/changelog jabberd2-2.2.1/debian/changelog --- jabberd2-2.2.1/debian/changelog +++ jabberd2-2.2.1/debian/changelog @@ -1,3 +1,13 @@ +jabberd2 (2.2.1-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Prevent an implicit pointer conversion of the return pointer from +crypt() (Closes: #493768). + * Define LDAP_DEPRECATED to continue to make use of a deprecated API +without implicitly converting returned pointers (Closes: #493765) + + -- dann frazier [EMAIL PROTECTED] Mon, 17 Nov 2008 19:36:16 -0700 + jabberd2 (2.2.1-1) unstable; urgency=low * New upstream release (Closes: #403750). diff -u jabberd2-2.2.1/debian/patches/00list jabberd2-2.2.1/debian/patches/00list --- jabberd2-2.2.1/debian/patches/00list +++ jabberd2-2.2.1/debian/patches/00list @@ -4,0 +5,2 @@ +jabberd2-crypt.patch +jabberd2-ldap.patch only in patch2: unchanged: --- jabberd2-2.2.1.orig/debian/patches/jabberd2-crypt.patch +++ jabberd2-2.2.1/debian/patches/jabberd2-crypt.patch @@ -0,0 +1,18 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## jabberd2-crypt.dpatch by dann frazier [EMAIL PROTECTED] +## DP: add missing prototype for crypt function + [EMAIL PROTECTED]@ +diff -urpN jabberd2-2.2.1.orig/storage/authreg_mysql.c jabberd2-2.2.1/storage/authreg_mysql.c +--- jabberd2-2.2.1.orig/storage/authreg_mysql.c 2008-07-16 03:36:58.0 -0600 jabberd2-2.2.1/storage/authreg_mysql.c 2008-08-04 13:32:21.0 -0600 +@@ -20,6 +20,9 @@ + + /* this module talks to a MySQL server via libmysqlclient */ + ++#define _XOPEN_SOURCE 500 ++#include unistd.h ++ + #include c2s.h + #include mysql.h + only in patch2: unchanged: --- jabberd2-2.2.1.orig/debian/patches/jabberd2-ldap.patch +++ jabberd2-2.2.1/debian/patches/jabberd2-ldap.patch @@ -0,0 +1,38 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## jabberd-ldap.dpatch by dann frazier [EMAIL PROTECTED] +## DP: explicitly use deprecated ldap functions + [EMAIL PROTECTED]@ +diff -urpN jabberd2-2.2.1.orig/storage/authreg_ldap.c jabberd2-2.2.1/storage/authreg_ldap.c +--- jabberd2-2.2.1.orig/storage/authreg_ldap.c 2008-07-16 03:36:58.0 -0600 jabberd2-2.2.1/storage/authreg_ldap.c 2008-08-04 13:27:09.0 -0600 +@@ -30,6 +30,7 @@ + + #include c2s.h + #include lber.h ++#define LDAP_DEPRECATED 1 + #include ldap.h + + #define AR_LDAP_FLAGS_NONE (0x0) +diff -urpN jabberd2-2.2.1.orig/storage/authreg_ldapfull.c jabberd2-2.2.1/storage/authreg_ldapfull.c +--- jabberd2-2.2.1.orig/storage/authreg_ldapfull.c 2008-07-16 03:36:58.0 -0600 jabberd2-2.2.1/storage/authreg_ldapfull.c 2008-08-04 13:27:48.0 -0600 +@@ -34,6 +34,7 @@ + #ifdef STORAGE_LDAP + + #include lber.h ++#define LDAP_DEPRECATED 1 + #include ldap.h + + #define LDAPFULL_PASSBUF_MAX 257 +diff -urpN jabberd2-2.2.1.orig/storage/storage_ldapvcard.c jabberd2-2.2.1/storage/storage_ldapvcard.c +--- jabberd2-2.2.1.orig/storage/storage_ldapvcard.c 2008-07-16 03:36:58.0 -0600 jabberd2-2.2.1/storage/storage_ldapvcard.c 2008-08-04 13:28:49.0 -0600 +@@ -27,6 +27,7 @@ + + #ifdef STORAGE_LDAP + ++#define LDAP_DEPRECATED 1 + #include ldap.h + #include time.h +
Bug#499142: patch
tags 499142 + patch
thanks
To correct an earlier comment, gcj _is_ using threads.
The cause of this bug appears to be a race condition in
send_get_fakem().
When crafting messages, we stuff a serial number and pid into the
message to ensure uniqueness. In the case of threads, our pids will be
the same, so that doesn't really help us - we must rely on the serial
number. Unfortunately, we didn't protect access to the static (and
therefore shared) serial variable with our semaphore, resulting in
this scenario:
THREAD A THREAD B
-
serial++
buf-serial=serial
lock()
serial++
lock()
recvmsg()
serial != buf-serial
Solution is to grab the semaphore before incrementing serial.
Thanks to Troy Heber for helping me work through this one.
diff -urpN fakeroot-1.10.1.orig/communicate.c fakeroot-1.10.1/communicate.c
--- fakeroot-1.10.1.orig/communicate.c 2008-08-03 16:26:49.0 -0600
+++ fakeroot-1.10.1/communicate.c 2008-11-18 15:10:24.0 -0700
@@ -521,9 +521,9 @@ void send_get_fakem(struct fake_msg *buf
if(init_get_msg()!=-1){
pid=getpid();
+semaphore_up();
serial++;
buf-serial=serial;
-semaphore_up();
buf-pid=pid;
send_fakem(buf);
--
dann frazier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506009: maq: gzopen64 implicitly converted to pointer
Package: maq Version: 0.7.1-1 Severity: serious Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `gzopen64' implicitly converted to pointer at fastq2bfq.c:30 Function `gzopen64' implicitly converted to pointer at maqmap_conv.c:57 Function `gzopen64' implicitly converted to pointer at simulate.c:83 Function `gzopen64' implicitly converted to pointer at break_pair.c:16 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505459: sugar-hulahop: hulahop_get_view_for_window implicitly converted to pointer
Package: sugar-hulahop Version: 0.4.7~dfsg-1 Severity: serious Tags: patch Usertags: implicit-pointer-conversion Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `hulahop_get_view_for_window' implicitly converted to pointer at hulahop.c:315 Function `hulahop_get_view_for_window' implicitly converted to pointer at hulahop.c:315 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. The following patch appears to fix the problem for me - there certainly maybe better ways to do it. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions --- sugar-hulahop-0.4.7~dfsg/python/hulahop.override~ 2008-10-08 04:50:05.0 -0600 +++ sugar-hulahop-0.4.7~dfsg/python/hulahop.override2008-11-12 09:02:25.0 -0700 @@ -4,6 +4,7 @@ #include Python.h #include pygtk/pygtk.h +#include hulahop.h #include hulahop-web-view.h %% -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493768: intent to NMU
hey, As these bugs have been open with a patch for over a month and without a rejection from the maintainer, I intend to NMU the associated package in a week's time (or sooner, if requested by the maintainer). If you do not wish for this NMU to occur, please send a follow-up in the bug report stating as such or, better yet, fix it in an MU :) Unless you request otherwise, any NMUs I upload will be to the DELAYED queue, so you will have an additional week to supersede my upload with an MU to prevent it from entering unstable. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499142: Processed: reassign 499142 to fakeroot
On Thu, Nov 06, 2008 at 01:19:40PM +, Clint Adams wrote: On Thu, Nov 06, 2008 at 06:06:03AM +, Debian Bug Tracking System wrote: reassign 499142 fakeroot Bug#499142: hangs while building eclipse Bug reassigned from package `gij-4.3' to `fakeroot'. Are threads involved? I see no evidence that they are - 'ldd /usr/bin/gcj-4.3' shows no libpthread. Does fakeroot-tcp avoid the problem? yep, seems to If neither, has the file being fstat'd been access previously under fakeroot or is this the initial contact? Good question. I took a trace following the instructions in /usr/share/doc/fakeroot/DEBUG, and I'll attach it here since I don't know how to decipher it myself. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503833: reassign, patch link
On Thu, Nov 06, 2008 at 08:33:08PM +0100, Andreas Metzler wrote:
On 2008-11-06 dann frazier [EMAIL PROTECTED] wrote:
reassign 503833 libtasn1-3
severity 503833 important
thanks
Upstream has developed a patch:
http://lists.gnu.org/archive/html/gnutls-devel/2008-11/msg0.html
If I apply this to libtasn1-3 it fixes the problem for me.
However, I had set the nocheck DEB_BUILD_OPTION because it causes
libtasn1-3 to fail at least one build-time test.
It would be nice to get a fix for this into lenny as it will fix a
regression from etch's subversion.
Hello,
I have just uploaded a fixed version to experimental.
Thanks Andreas!
I am reluctant
to go immediately to unstable since it requires a shlibs bump due to
an added function.
I definitely wouldn't call myself a shared lib packaging expert, but
does adding a function really break the ABI? It shouldn't break
backwards compatibility, and anything newly built that may use the new
function should automatically get a versioned runtime dependency.
I am not also not sure about this change:
--
--- a/lib/libtasn1.h
+++ b/lib/libtasn1.h
@@ -105,11 +105,14 @@ extern C
/* that represent an ASN.1 DEFINITION.*/
/**/
+#define SMALL_VALUE_SIZE 16
+
struct node_asn_struct
{
char *name;/* Node name */
unsigned int type; /* Node type */
unsigned char *value; /* Node value */
+unsigned char small_value[SMALL_VALUE_SIZE]; /* if value is less than
that store it here */
int value_len;
struct node_asn_struct *down; /* Pointer to the son node */
struct node_asn_struct *right; /* Pointer to the brother node */
struct node_asn_struct *left; /* Pointer to the next list element
*/
};
typedef struct node_asn_struct node_asn;
typedef node_asn *ASN1_TYPE;
--
Although the docs only talk about using the ASN1_TYPE pointer the
struct definition still is in the public interface. Doesn't this break
the ABI? - I am really not sure, to tired.
My guess would be yes[1].. which sucks because it would make it
significantly harder to get into lenny and fix the subversion
regression :( I wonder if there's an alternate way to handle it?
[1] but again, I'm still not an expert here :)
--
dann frazier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504657: gstm: implicit pointer conversions
Package: gstm Version: 1.2-5 Severity: serious Tags: patch Usertags: implicit-pointer-conversions Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `gstm_name2filename' implicitly converted to pointer at callbacks.c:466 Function `create_pixbuf' implicitly converted to pointer at notarea.c:93 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions diff -urpN gstm-1.2.orig/src/callbacks.c gstm-1.2/src/callbacks.c --- gstm-1.2.orig/src/callbacks.c 2006-08-03 02:39:51.0 -0600 +++ gstm-1.2/src/callbacks.c 2008-11-05 15:47:34.0 -0700 @@ -13,6 +13,7 @@ #include conffile.h extern void gstm_quit(void); +extern char *gstm_name2filename(char *n); extern void docklet_x11_create(void); extern void docklet_x11_position_menu(GtkMenu *menu, int *x, int *y, gboolean *push_in, gpointer user_data); diff -urpN gstm-1.2.orig/src/notarea.c gstm-1.2/src/notarea.c --- gstm-1.2.orig/src/notarea.c 2006-08-02 06:43:50.0 -0600 +++ gstm-1.2/src/notarea.c 2008-11-05 15:50:42.0 -0700 @@ -34,6 +34,8 @@ #include eggtrayicon.h EggTrayIcon *docklet = NULL; static GtkWidget *image = NULL; +extern GdkPixbuf *create_pixbuf(const gchar *filename); + extern void docklet_clicked(int); static void docklet_x11_destroyed_cb(GtkWidget *widget, void *data);
Bug#503833: reassign, patch link
reassign 503833 libtasn1-3 severity 503833 important thanks Upstream has developed a patch: http://lists.gnu.org/archive/html/gnutls-devel/2008-11/msg0.html If I apply this to libtasn1-3 it fixes the problem for me. However, I had set the nocheck DEB_BUILD_OPTION because it causes libtasn1-3 to fail at least one build-time test. It would be nice to get a fix for this into lenny as it will fix a regression from etch's subversion. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499142: backtraces point to gdb
gdb seems to suggest that this is a fakeroot issue - which might help
explain why it happens w/ sbuild pbuilder but not when I build
by hand.
Its unclear why the amd64 buildd, didn't have a problem while
the others archs did - they all seem to use fakeroot.
A backtrace of the faked-sysv process shows:
#0 0xb7e823fa in msgrcv () from /lib/libc.so.6
No symbol table info available.
#1 0x08048f01 in get_msg () at ../faked.c:793
buf = {mtype = 1, id = 3, pid = 7007, serial = 3800, st = {uid =
0,
gid = 0, ino = 1446880, dev = 2049, rdev = 0, mode = 33188, nlink
= 1},
remote = 0}
r = value optimized out
#2 0x0804a115 in main (argc=Cannot access memory at address 0x12
) at ../faked.c:1223
sa = {__sigaction_handler = {sa_handler = 0x8049c60 cleanup,
sa_sigaction = 0x8049c60 cleanup}, sa_mask = {__val = {
0 repeats 32 times}}, sa_flags = 0,
sa_restorer = 0x804c0fc _GLOBAL_OFFSET_TABLE_}
sa_debug = {__sigaction_handler = {sa_handler = 0x8048fe0
debugdata,
sa_sigaction = 0x8048fe0 debugdata}, sa_mask = {__val = {
0 repeats 32 times}}, sa_flags = 0, sa_restorer = 0}
sa_save = {__sigaction_handler = {sa_handler = 0x8049bf0 save,
sa_sigaction = 0x8049bf0 save}, sa_mask = {__val = {
0 repeats 32 times}}, sa_flags = 0, sa_restorer = 0}
i = value optimized out
foreground = 0
load = 0
justcleanup = 0
And a backtrace of the java process has:
#0 0xb5ef65a6 in semop () from /lib/libc.so.6
#1 0xb7f859d0 in semaphore_up () at ../communicate.c:390
#2 0xb7f85a70 in send_get_fakem (buf=0xbfa8bee0) at ../communicate.c:526
#3 0xb7f85b15 in send_get_stat64 (st=0xbfa8bf60) at ../communicate.c:757
#4 0xb7f84574 in __fxstat64 (ver=3, fd=71, st=0xbfa8bf60)
at ../libfakeroot.c:633
#5 0xb6b9072c in gnu::java::nio::channels::FileChannelImpl::size (
this=0x475e70) at /usr/include/sys/stat.h:467
#6 0xb6ffed72 in java.io.RandomAccessFile.length()long (this=0x475e88)
at /tmp/gcj-4.3-4.3.2/src/libjava/java/io/RandomAccessFile.java:245
#7 0xb71416f5 in
java.util.zip.ZipFile$PartialInputStream.ZipFile$PartialInputStream(java.io.RandomAccessFile,
int) (this=0x11985a0, raf=0x475e88,
bufferSize=1024)
at ../../../../../src/libjava/classpath/java/util/zip/ZipFile.java:550
#8 0xb7143187 in
java.util.zip.ZipFile.getInputStream(java.util.zip.ZipEntry)java.io.InputStream
(this=0x475ea0, entry=0x1b4b6f0)
at ../../../../../src/libjava/classpath/java/util/zip/ZipFile.java:426
#9 0xb75e1fe7 in ffi_call_SYSV () at ../../../src/libffi/src/x86/sysv.S:60
#10 0xb75e1d99 in ffi_raw_call (cif=0xf0001,
fn=0xb71430f0
java.util.zip.ZipFile.getInputStream(java.util.zip.ZipEntry)java.io.InputStream,
rvalue=0x1, fake_avalue=0xbfa8c0c0)
at ../../../src/libffi/src/x86/ffi.c:425
[... continues to 424 frames ...]
--
dann frazier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504454: xd: typo in description
Package: xd Version: 3.00.1-1 Severity: minor Tags: patch diff -urpN xd-3.00.1.orig/debian/control xd-3.00.1/debian/control --- xd-3.00.1.orig/debian/control 2008-11-03 16:49:08.0 -0700 +++ xd-3.00.1/debian/control2008-11-03 16:50:08.0 -0700 @@ -22,7 +22,7 @@ Description: smart directory change util working directory. Small changes required thereafter are in practice always performed using the facilities offered by the command shell. . - When multiple expansions are avaiable xd offers a list of alternatives from + When multiple expansions are available xd offers a list of alternatives from which the user may select an option by simply pressing an associated key. Directories that are never selected by the user may be ignored using directives in xd's configuration file. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Kernel: Linux 2.6.26-1-mckinley (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages xd depends on: ii libbobcat11.21.1-1 run-time (shared) Bobcat library ii libc6.1 2.7-15 GNU C Library: Shared libraries ii libgcc1 1:4.3.2-1 GCC support library ii libstdc++64.3.2-1The GNU Standard C++ Library v3 ii libunwind70.98.5-8 A library to determine the call-ch xd recommends no packages. xd suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504030: regression in flex 2.5.35-3
reassign 504030 flex thanks On Fri, Oct 31, 2008 at 10:59:16AM -0500, Manoj Srivastava wrote: Hi, Thinking about it, if the test was done with the same build chain, and two versions of flex, and one fails, and the pther does not, then the bug is really with flex. Please assign back if that is the case. Thanks Manoj. I tested in an i386 lenny chroot. I observed no failure when building w/ flex_2.5.35-2. I then made a single change - upgrading flex to 2.5.35-3, and the failure was reproducible. Reassigning back to flex as requested. On Fri, 31 Oct 2008 08:50:14 -0500, Manoj asked: aaargh. Is this related to the buffer size increase, you think? I can't say - I didn't look into the scope of changes between the two releases. I don't see a difference in redirect vs. pipe, I didn't see a smoking gun when looking at strace output, and its an issue observed equally on x86 and ia64. That leads me to believe its unrelated to the kernel change that uncovered the previous issue. However, it is possible that this is another symptom of whatever the root cause issue is behind #501960. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504028: FTBFS: /usr/bin/m4:stdin:9: ERROR: end of file in string
Package: apertium Version: 3.0.7+1-2 Severity: serious As noted in #500171, apertium no longer builds from source. I've reproduced this on both ia64 and i386 (haven't tried others) in latest sid. Downgrading flex from 2.5.35-3 to 2.5.35-2 fixes the problem on i386 but, of course, that would re-introduce #501960 (FTBFS ia64). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504030: regression in flex 2.5.35-3
Package: flex
Version: 2.5.35-3
Severity: important
2.5.35-3 fails to process input that worked in 2.5.35-2.
This is causing another FTBFS issue in apertium, #504028.
Attached is the input file generated during apertium's build.
With flex_2.5.35-2 this will succeed (even on ia64), but flex_2.5.35-3
will fail on both the archs I tested (i386 and ia64).
$ /usr/bin/flex -Cfer -t apertium_deshtml.cc input2.txt
/usr/bin/m4:stdin:9: ERROR: end of file in string
--
dann frazier
%{
#include cstdlib
#include iostream
#include map
#include vector
#include regex.h
#include string
#include lttoolbox/lt_locale.h
#include lttoolbox/ltstr.h
using namespace std;
wstring buffer;
string symbuf = ;
bool isDot, hasWrite_dot, hasWrite_white;
FILE *formatfile;
string last;
int current;
long int offset;
vectorlong int offsets;
vectorwstring tags;
vectorint orders;
regex_t escape_chars;
regex_t names_regexp;
void bufferAppend(wstring buf, string const str)
{
symbuf.append(str);
for(size_t i = 0, limit = symbuf.size(); i limit;)
{
wchar_t symbol;
int gap = mbtowc(symbol, symbuf.c_str() + i, MB_CUR_MAX);
if(gap == -1)
{
if(i + MB_CUR_MAX limit)
{
buf += L'?';
gap = 1;
}
else
{
symbuf = symbuf.substr(i);
return;
}
}
else
{
buf += symbol;
}
i += gap;
}
symbuf = ;
return;
}
void init_escape()
{
if(regcomp(escape_chars, [EMAIL PROTECTED]/], REG_EXTENDED))
{
cerr ERROR: Illegal regular expression for escape characters endl;
exit(EXIT_FAILURE);
}
}
void init_tagNames()
{
if(regcomp(names_regexp, [a-zA-Z]+, REG_EXTENDED))
{
cerr ERROR: Illegal regular expression for tag-names endl;
exit(EXIT_FAILURE);
}
}
string backslash(string const str)
{
string new_str = ;
for(unsigned int i = 0; i str.size(); i++)
{
if(str[i] == '\\')
{
new_str += str[i];
}
new_str += str[i];
}
return new_str;
}
wstring escape(string const str)
{
regmatch_t pmatch;
char const *mystring = str.c_str();
int base = 0;
wstring result = L;
while(!regexec(escape_chars, mystring + base, 1, pmatch, 0))
{
bufferAppend(result, str.substr(base, pmatch.rm_so));
result += L'\\';
wchar_t micaracter;
int pos = mbtowc(micaracter, str.c_str() + base + pmatch.rm_so,
MB_CUR_MAX);
if(pos == -1)
{
wcerr LUno endl;
wcerr LEncoding error. endl;
exit(EXIT_FAILURE);
}
result += micaracter;
base += pmatch.rm_eo;
}
bufferAppend(result, str.substr(base));
return result;
}
wstring escape(wstring const str)
{
string dest = ;
for(size_t i = 0, limit = str.size(); i limit; i++)
{
char symbol[MB_CUR_MAX+1];
int pos = wctomb(symbol, str[i]);
if(pos == -1)
{
symbol[0]='?';
pos = 1;
}
symbol[pos] = 0;
dest.append(symbol);
}
return escape(dest);
}
string get_tagName(string tag){
regmatch_t pmatch;
char const *mystring = tag.c_str();
string result = ;
if(!regexec(names_regexp, mystring, 1, pmatch, 0))
{
result=tag.substr(pmatch.rm_so, pmatch.rm_eo - pmatch.rm_so);
return result;
}
return ;
}
mapstring, wstring, Ltstr S1_substitution;
void S1_init()
{
S1_substitution[Agrave;] = L??;
S1_substitution[#192;] = L??;
S1_substitution[#xC0;] = L??;
S1_substitution[#xc0;] = L??;
S1_substitution[Aacute;] = L??;
S1_substitution[#193;] = L??;
S1_substitution[#xC1;] = L??;
S1_substitution[#xc1;] = L??;
S1_substitution[Acirc;] = L??;
S1_substitution[#194;] = L??;
S1_substitution[#xC2;] = L??;
S1_substitution[#xc2;] = L??;
S1_substitution[Atilde;] = L??;
S1_substitution[#195;] = L??;
S1_substitution[#xC3;] = L??;
S1_substitution[#xc3;] = L??;
S1_substitution[Auml;] = L??;
S1_substitution[#196;] = L??;
S1_substitution[#xC4;] = L??;
S1_substitution[#xc4;] = L??;
S1_substitution[Aring;] = L??;
S1_substitution[#197;] = L??;
S1_substitution[#xC5;] = L??;
S1_substitution[#xc5;] = L??;
S1_substitution[AElig;] = L??;
S1_substitution[#198;] = L??;
S1_substitution[#xC6;] = L??;
S1_substitution[#xc6;] = L??;
S1_substitution[Ccedil;] = L??;
S1_substitution[#199;] = L??;
S1_substitution[#xC7;] = L??;
S1_substitution[#xc7;] = L??;
S1_substitution[Egrave;] = L??;
S1_substitution[#200;] = L??;
S1_substitution[#xC8;] = L??;
S1_substitution[#xc8;] = L??;
S1_substitution[Eacute;] = L??;
S1_substitution[#201;] = L??;
S1_substitution[#xC9;] = L??;
S1_substitution[#xc9;] = L??;
S1_substitution[Ecirc;] = L??;
S1_substitution[#202;] = L??;
S1_substitution[#xCA;] = L??;
S1_substitution[#xca;] = L??;
S1_substitution[Euml;] = L??;
S1_substitution[#203;] = L??;
S1_substitution[#xCB;] = L??;
S1_substitution[#xcb;] = L??;
S1_substitution[Igrave;] = L??;
S1_substitution[#204;] = L??;
S1_substitution[#xCC;] = L??;
S1_substitution[#xcc;] = L
Bug#503698: thanks + some comments
hey Robert, Thanks for fixing this so quickly! I just realized I failed to attach my patch, but looks like you had no trouble dealing with it. I just wanted to clarify a couple of things, in case you or other readers of this report become a recipient of these bugs in the future. On Mon, 27 Oct 2008 21:53:39 +0100, Robert Millan said: By chance these were, in fact, meant to be pointers so no harm done. I'll wipe out that warning for your convenience. Actually, this is the problem. Without a prototype, gcc will assume that the function will return an int - but in fact it is returning a pointer. This causes the pointer to get truncated on the aformentioned architectures, and attempting to use this pointer will cause a segfault. On amd64 you can sometimes get away with it because the upper 32 bits would've been 0s anyway but, on ia64 at least, this is never the case. In other words, the warning is that the returned pointer is getting converted to something else, not the other way around. severity 503698 minor There are cases where the returned pointer is ignored or that the code in question is guaranteed to never execute. Because of this, I used to always file these bugs as important unless I'd verified that the case will actually occur. However, the ia64 buildds have since been configured to reject any builds that fail this test. Whether or not that is a good idea is arguable but, as things stand, these issues are considered FTBFS defects and therefore warrant an RC severity. Anyway, hope that didn't come off too much like a lecture :) Thanks again for fixing this issue, and for your work towards solving the dsp56k fw problem. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503833: libgnutls26: doesn't handle firefox-exported .p12 certs
Package: libgnutls26 Version: 2.4.2-1 Severity: normal I'm a novice when it comes to dealing with certificates, so don't hestitate to let me know if this bug is missing some important information. There's a long-open bug reported against subversion, #480041. This appears to have surfaced when subversion began using libneon26-gnutls instead of openssl for PKCS12 certs. I took a shot at debugging this, and it looks like the problem first arises when libgnutls calls into libtasn1-3 to decode the ASN.1-encoded PKCS12 file. asn1_der_decoding() eventually bails out, causing an error to be propagated up the stack. troyh and I think we've found a way to simplify the demonstration of this problem outside of subversion by using certtool: 1) Follow the instructions for creating a pkcs12 cert that google found for me on this page: http://hausheer.osola.com/docs/9 2) Run: $ certtool --p12-info --infile /tmp/client.p12 --inraw (To demonstrate that we can process this cert) 3) Imported the cert into iceweasel (aka firefox) 4) Use the backup feature in iceweasel to dump the cert back out to another .p12 file 5) Run: $ certtool --p12-info --infile /tmp/backup.p12 --inraw This time, we see an error: date size is 1822 certtool: p12_import: ASN1 parser: Error in TAG. Obviously, this doesn't prove that this is a bug in gnutls. It could very well be that firefox is exporting a bad cert. However, openssl seems to handle the firefox-exported certs just fine, as seen in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480041#130 That suggests to me that this bug likely lies either in gnutls or libtasn. I'm filing a new bug instead of reassigning the subversion one because subversion could theoretically fix the problem by reverting back to openssl. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Kernel: Linux 2.6.26-1-mckinley (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libgnutls26 depends on: ii libc6.12.7-15GNU C Library: Shared libraries ii libgcrypt111.4.1-1 LGPL Crypto library - runtime libr ii libgpg-error0 1.4-2 library for common error values an ii libtasn1-3 1.5-1 Manage ASN.1 structures (runtime) ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime libgnutls26 recommends no packages. Versions of packages libgnutls26 suggests: ii gnutls-bin2.4.2-1the GNU TLS library - commandline -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480041: gnutls bug
fyi, I've file this bug against gnutls: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503833 As explained there, I opened a new bug instead of reassigning this one because this bug represents a subversion regression which could theoretically be fixed w/o a fix for #503833 (e.g., by going back to not using gnutls). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503698: a56: alloc, fixstring implicitly converted to pointers
Package: a56 Version: 1.3-4 Severity: serious Tags: patch Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `alloc' implicitly converted to pointer at keybld.c:76 Function `fixstring' implicitly converted to pointer at lex.c:83 This is often due to a missing function prototype definition. For more information, see [2]. Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501960: workaround may be incomplete
Thanks for looking into this issue; however, I do think that the selected solution only works around the problem and that this issue is likely to pop up again. A larger page size has made this problem surface, but it is not the root cause (which likely involves stream book keeping). Its possible that other architectures will see this problem. IA-64 isn't the only architecture with a larger default page size - I'm not sure if there are others that are above 16K by default, but there might be others. Such systems would also get bit by this bug when they begin running a recent kernel. Also, the PAGE_SIZE on ia64 is a compile time option - its possible to go up to 64K pages. The default debian kernel doesn't do this, but its a reasonable thing for customers to configure themselves. This workaround could be enhanced to detect the system page size at runtime (via sysconf) and dynamically allocate buffers that match. Or, an easier, possibly slower workaround might be to always force fread to use an 8K buffer (similar to how my instrumentation patch forces 16K buffers to trigger the issue on x86). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480041: similar fedora bug
https://bugzilla.redhat.com/show_bug.cgi?id=445044 -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494308: e100 firmware testing
On Thu, Oct 23, 2008 at 12:47:09AM +0100, Ben Hutchings wrote: On Wed, 2008-10-22 at 17:05 -0600, dann frazier wrote: hey Ben, I got around to testing a build from the source you reference in your blog[1] today - but it appears that the e100 patch in place simply removes the firmware and marks the driver broken. I see in #494308 that there were a couple of different approaches being considered for e100, so perhaps e100 is still a work in progress. My changes to e100 in linux-2.6 are actually divided across 3 files under debian/patches, following what has been done for several other instances of sourceless firmware: 1. debian/dfsg/e100-disable.patch inserts #ifdef REMOVE_DFSG...#endif around the microcode and marks the driver as BROKEN in Kconfig. 2. debian/dfsg/files-1 uses unifdef to remove the microcode. 3. features/all/e100-request_firmware.patch removes the BROKEN mark and adds firmware loading using request_firmware. Each of the 11 other drivers is dealt with similarly, except that for most of them we can use rm instead of unifdef. The orig tarball has steps 1 and 2 already applied and step 3 is part of the normal build process. Ah - I somehow missed the step3 patch. Also, it turns out my controller (8086:1229) isn't one of the devices that gets fw loaded. The driver still works fine though, fwiw. If you decide to move forward w/ a request_firmware() approach, you might want to take note that the e100 driver will be included in the initramfs by default. This means that the firmware should be included in the initramfs as well. You should be able to enable an initramfs hook in the firmware-nonfree source package - see bnx2/defines for an example. I know this works for fw blobs that live in /lib/firmware, but I don't know how well it would deal with files in other subdirectories (e.g. /lib/firmware/e100/). Right, I hadn't got that far yet. Ben. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494936: firmware-bnx2: latest lenny requires manual reload of bnx2 driver
On Wed, Oct 22, 2008 at 02:45:38PM -0700, Brendon B wrote: Package: firmware-bnx2 Version: 0.13 Followup-For: Bug #494936 I ran update-initramfs -u, but the network interfaces don't start on bootup. I still have to remove and re-install the bnx2d drivers. This is a Dell PE 2950. hm.. that's strange - it works for me. Can you unpack the initramfs to make sure the bnx2 files have been included? (see initramfs-tools(8) for a cpio command to do this). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494308: e100 firmware testing
hey Ben, I got around to testing a build from the source you reference in your blog[1] today - but it appears that the e100 patch in place simply removes the firmware and marks the driver broken. I see in #494308 that there were a couple of different approaches being considered for e100, so perhaps e100 is still a work in progress. If you decide to move forward w/ a request_firmware() approach, you might want to take note that the e100 driver will be included in the initramfs by default. This means that the firmware should be included in the initramfs as well. You should be able to enable an initramfs hook in the firmware-nonfree source package - see bnx2/defines for an example. I know this works for fw blobs that live in /lib/firmware, but I don't know how well it would deal with files in other subdirectories (e.g. /lib/firmware/e100/). Thanks! [1] http://people.debian.org/~benh/firmware-removal/ -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501960: patch to simulate problem on !ia64
Attached is a patch intended to make it possible to reproduce/debug
this issue on architectures w/ more common page sizes (e.g. i386).
--
dann frazier
--- flex-2.5.35.orig/scan.c 2008-10-21 14:27:17.0 -0600
+++ flex-2.5.35/scan.c 2008-10-21 12:59:00.0 -0600
@@ -5157,6 +5157,7 @@ int yywrap()
/* set_input_file - open the given file (if NULL, stdin) for scanning */
+char *mybuf;
void set_input_file( file )
char *file;
{
@@ -5171,7 +5172,9 @@ char *file;
else
{
+ mybuf = (char *)malloc(16384);
yyin = stdin;
+ setbuffer(stdin, mybuf, 16384);
infilename = copy_string( stdin );
}
Bug#501960: kernel bug?
reassign 501960 flex thanks It is clear that the aforementioned changeset is the change that caused flex to begin failing. But, I don't see any evidence that the kernel change is faulty. PAGE_SIZE on ia64 kernels is larger than most architectures - 16K is what most distributions (including Debian) use. An effect of the above changeset, as verified by strace, is that the read() and write() system calls issued by flex on a pipe will use this bigger size. fread() appears to be properly hiding the actual read size and is returning 8192 byte buffers to flex upon request. I verified by this by instrumenting YY_INPUT to compare the fread data with the original input file. Its probably useful to note that the corruption happening here is that the last 382 lines of the input file is being prefixed to the output file. The only differences in the remainder of the file are the #line numbers. I've also found that bumping YY_READ_BUF_SIZE up to 16384 seems to workaround the problem - but that may just be putting it back into hiding. My understanding of flex's codebase is nearly non-existant, but filter.c:filter_apply_chain() looks like a reasonable place to suspect an issue. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502538: 2.6.24-6~etchnhalf.5-6: FATAL: modules.dep not found - kernel panic: init not found
On Fri, Oct 17, 2008 at 01:46:18PM +, tom schorpp wrote: Package: linux-image-2.6.24-etchnhalf.1-686 Version: 2.6.24-6~etchnhalf.6 Severity: critical Justification: breaks the whole system Silent upgrade error on modules.dep/ramdisk-creation make kernel ubootable, fails bevor root mount. Maybe depends on newer yaird/initramfs-tools? Please provide the output of the install so we can understand what happened. Are you using yaird or initramfs-tools? If yaird, please try pulling the version from proposed-updates, which will be included in an etch update this weekend. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502553: support new smart array controllers
Package: linux-2.6 Version: 2.6.18.dfsg.1-23 Severity: important According to 24aac480e76c6f5d1391ac05c5e9c0eb9b0cd302, new smart array controllers will become available in late Fall 2008. This bug is to track the progress of adding support for these devices in etch. Patching in new Smart Array PCI IDs isn't strictly necessary, in general. There is a fallback mode in the cciss driver that recognizes Unknown Smart Array Controllers, and has some until recently sane defaults. The problem is that these defaults are no longer sane for newer hardware. The fallback 'max outstanding commands' setting is too high for the next generation controllers running in Zero Memory Raid mode. This means that the current etch kernels will happily detect and operate these newer controllers, but will be setting a queue depth too large for the controller's fifo. To resolve this, an additional patch is suggested that retrieves the queue depth setting from the card's config instead of hard coding each card's value in a table. 2.6.18 can also use 9cff3b383dad193b0762c27278a16237e10b53dc, adding pci ids for the previously released P700M controller, which is already supported in 2.6.24. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502538: stable yaird fails on creating initrd for etch kernel, only one working is yaird unstable
On Fri, Oct 17, 2008 at 07:57:17PM +0200, thomas schorpp wrote: Get:2 http://ftp2.de.debian.org stable/main yaird 0.0.12-18 [185kB] tom3:~# mkinitrd.yaird -o /boot/initrd.img-2.6.18-6-686 2.6.18-6-686 yaird error: unrecognised line in /proc/bus/input/devices: U: Uniq= (fatal) tom3:~# tom3:~# mkinitrd.yaird -o /boot/initrd.img-2.6.24-etchnhalf.1-686 yaird error: unrecognised line in /proc/bus/input/devices: U: Uniq= (fatal) tom3:~# ii yaird 0.0.13-5 Yet Another mkInitRD : tom3:~# mkinitrd.yaird -o /boot/initrd.img-2.6.18-6-686 2.6.18-6-686 tom3:~# tom3:~# mkinitrd.yaird -o /boot/initrd.img-2.6.24-etchnhalf.1-686 2.6.24-etchnhalf.1-686 tom3:~# yaird unstable works, no kernel bug, suggest forward to initramfs-tools package bug tracker. sorry, i do install own kernels the classic way, cannot help much investigating initramfs-tools, if questions, contact me. Right - please try updated yaird in stable-proposed-updates. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502538: 2.6.24-6~etchnhalf.5-6: FATAL: modules.dep not found - kernel panic: init not found
On Fri, Oct 17, 2008 at 08:50:12PM +0200, Thomas Schorpp wrote: dann frazier schrieb: On Fri, Oct 17, 2008 at 01:46:18PM +, tom schorpp wrote: Package: linux-image-2.6.24-etchnhalf.1-686 Version: 2.6.24-6~etchnhalf.6 Severity: critical Justification: breaks the whole system Silent upgrade error on modules.dep/ramdisk-creation make kernel ubootable, fails bevor root mount. Maybe depends on newer yaird/initramfs-tools? Please provide the output of the install so we can understand what happened. Are you using yaird or initramfs-tools? If yaird, please try pulling the version from proposed-updates, which will be included in an etch update this weekend. already done with, see above in the bugs log, or pull proposed updates from where? deb http://your.mirror/debian etch-proposed-updates main -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502434: linux-image-2.6.26-1-686 do not boot
On Thu, Oct 16, 2008 at 10:23:38AM -0300, David Roguin wrote: Package: linux-image-2.6.26-1-686 Version: 2.6.26-8 When i try to boot with the new kernel in lenny, the boot process hangs at a kernel panic. I don't really know where to get the log when the kernel do not boot. If someone could help me, i could send you more info. David, We will have to have more info to be able to diagnose this issue. If you have a second computer, you could try using a serial console to capture the panic. A link to a photo of the screen can also work. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495685: [#495685] firmware-iwlwifi: microcode error
On Thu, Oct 16, 2008 at 12:16:54AM +0200, Stefano Sabatini wrote: In data marted? 2008-10-14 20:49:17 +0200, Stefano Sabatini ha scritto: In data luned? 2008-10-06 19:45:36 +0200, Didier Raboud ha scritto: Le mardi 19 ao?t 2008 19:02:56 Stefano Sabatini, vous avez ?crit?: Package: firmware-iwlwifi Version: 0.12 Severity: grave Justification: renders package unusable I got this when I try to load iwl3945: When I try the command: modprobe iwl3945 it hangs for half a minute, then I get this error: iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection iwl3945: iwlwifi-3945-1.ucode firmware file req failed: Reason -2 iwl3945: Could not read microcode: -2 ACPI: PCI interrupt for device :10:00.0 disabled iwl3945: probe of :10:00.0 failed with error -2 I'm using firmware-iwlwifi 0.12, with a linux-2.6.24 i686 debian custom kernel. Regards. Hi, a new firmware-iwlwifi package is available in unstable. Please try this new package and update your linux-image to get the latest iwlwifi driver and report back if the problem is still alive. N.B. I don't get any error with the firmware... Regards, Updated to iwlwifi-firmware 0.13. [EMAIL PROTECTED] ~ uname -a Linux geppetto 2.6.26-1-686 #1 SMP Thu Oct 9 15:18:09 UTC 2008 i686 GNU/Linux [EMAIL PROTECTED] ~ sudo modprobe -r iwl3945 [EMAIL PROTECTED] ~ sudo modprobe iwl3945 with dmesg I get: [ 332.178973] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks [ 332.178973] iwl3945: Copyright(c) 2003-2008 Intel Corporation [ 332.178973] ACPI: PCI Interrupt :10:00.0[A] - GSI 17 (level, low) - IRQ 17 [ 332.178973] PCI: Setting latency timer of device :10:00.0 to 64 [ 332.178973] iwl3945: Detected Intel Wireless WiFi Link 3945ABG [ 332.218972] iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels [ 332.218972] phy0: Selected rate control algorithm 'iwl-3945-rs' [EMAIL PROTECTED] ~ sudo iwconfig lono wireless extensions. eth1 no wireless extensions. wmaster0 no wireless extensions. wlan0 IEEE 802.11 ESSID: Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 So the module looks correctly loaded. [EMAIL PROTECTED] ~ sudo iwlist wlan0 scanning Here it hangs for 30 seconds more or less, then I get this: wlan0 Interface doesn't support scanning : Network is down From dmesg: [ 372.025418] firmware: requesting iwlwifi-3945-1.ucode [ 432.097666] iwl3945: iwlwifi-3945-1.ucode firmware file req failed: Reason -2 [ 432.097676] iwl3945: Could not read microcode: -2 [EMAIL PROTECTED] ~ locate iwlwifi-3945-1.ucode /lib/firmware/iwlwifi-3945-1.ucode Hints will be highly appreciated. And the problem was... udevd was dead, so it couldn't load the firmware. It took me a good guessing effort for realizing that firmware is loaded by udev, I was indeed experiencing the same loading firmware problem with another module and finally I read something about the firmware being loaded by udev. Please improve the behaviour of the module so that it will check for the presence of udevd and tell explicitely if it isn't present rather than hang forever trying to load the firmware. Anyway, bug report has to be considered closed, now I have to understand why udevd was dying... Thanks for the followup! Thanks, regards. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501960: git bisect
git bisect points to the following commit: 3971e1a917548977cff71418a7c3575ffbc9571f is first bad commit commit 3971e1a917548977cff71418a7c3575ffbc9571f Author: Alex Nixon [EMAIL PROTECTED] Date: Tue Jul 29 22:33:03 2008 -0700 VFS: increase pseudo-filesystem block size to PAGE_SIZE This commit: commit ba52de123d454b57369f291348266d86f4b35070 Author: Theodore Ts'o [EMAIL PROTECTED] Date: Wed Sep 27 01:50:49 2006 -0700 [PATCH] inode-diet: Eliminate i_blksize from the inode structure caused the block size used by pseudo-filesystems to decrease from PAGE_SIZE to 1024 leading to a doubling of the number of context switches during a kernbench run. Signed-off-by: Alex Nixon [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Cc: Jeremy Fitzhardinge [EMAIL PROTECTED] Cc: Peter Zijlstra [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Cc: Ian Campbell [EMAIL PROTECTED] Cc: Theodore Ts'o [EMAIL PROTECTED] Cc: Alexander Viro [EMAIL PROTECTED] Cc: Hugh Dickins [EMAIL PROTECTED] Cc: Jens Axboe [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [2.6.25.x, 2.6.26.x] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 96f34c51d3eb7e47f101f5cbfa15ae2a6f39480f 900bf1fe7100529521a97c56440185686ce7453d M fs -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502132: [ia64] $loader var not replaced in template, bootloader doesn't run
Package: kernel-package Version: 11.002 Severity: grave First off, thanks for whipping kernel-package into shape for the release! Now the issue.. I just upgraded my ia64 workstation to an image from linux-2.6_2.6.26-8, and was presented with a debconf screen that shows some detection problems with the elilo bootloader. The $loader string in the template does not appear to get updated. (I'll provide a link to a screenshot image once a bug number is assigned) The nasty part is that - even though my system is configured to run elilo without prompting - elilo doesn't run and my system is left booting the old kernel. Though a careful user may notice the message warning them that elilo has not run, I expect there's a significant number of users who wouldn't know that they need to take an action (or what that action might be). This puts them at a risk of unknowingly running kernels with open security issues, which is my justification for the RC severity. buildd.debian.org shows that kernel-package_11.002 is what was used to build this package, so that's what I'm using for the version pseudoheader. I don't know if this existed in earlier versions or was fixed since, but I didn't see anything in the changelog that looked to be related. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502132: screenshot
http://people.debian.org/~dannf/bugs/502132/kernel-package-not-running-elilo.png -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502133: python-reportlab: fails to install on system with python2.3
Package: python-reportlab Version: 2.2-1 Severity: important python-reportlab will fail to install on systems that still have python2.3 from sarge installed. [EMAIL PROTECTED]:~$ sudo dpkg --configure -a Setting up python-reportlab (2.2-1) ... INFO: using old version '/usr/bin/python2.3' Compiling /usr/lib/python2.3/site-packages/reportlab/lib/utils.py ... File /usr/lib/python2.3/site-packages/reportlab/lib/utils.py, line 679 @property ^ SyntaxError: invalid syntax pycentral: pycentral pkginstall: error byte-compiling files (126) pycentral pkginstall: error byte-compiling files (126) dpkg: error processing python-reportlab (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of python-reportlab-accel: python-reportlab-accel depends on python-reportlab (= 2.1); however: Package python-reportlab is not configured yet. dpkg: error processing python-reportlab-accel (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: python-reportlab python-reportlab-accel -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Kernel: Linux 2.6.26-1-mckinley (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages python-reportlab depends on: ii python2.5.2-2An interactive high-level object-o ii python-central0.6.8 register and build utility for Pyt Versions of packages python-reportlab recommends: ii python-imaging1.1.6-3Python Imaging Library pn python-renderpm none (no description available) pn python-reportlab-accelnone (no description available) Versions of packages python-reportlab suggests: ii evince [pdf-viewer] 2.22.2-3 Document (postscript, pdf) viewer ii gv [pdf-viewer] 1:3.6.5-2 PostScript and PDF viewer for X pn python-egenix-mxtexttools none (no description available) pn python-reportlab-doc none (no description available) ii xpdf-reader [pdf-viewer] 3.02-1.4 Portable Document Format (PDF) sui ii xpdf-utils [pdf-viewer] 3.02-1.4 Portable Document Format (PDF) sui -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498309: xfs filesystem corruption due to attr2 bug
On Fri, Sep 12, 2008 at 07:25:06PM +0200, Ralf Gross wrote: Thanks, this worked. So far, I couldn't reproduce the bug on the spare server. Neither with the old 2.6.18 nor with your new one. I haven't encountered other problems with the new kernel so far. Ah - I *thought* you'd confirmed this, but didn't see it in the bug report. I see now that it was just that the bug report wasn't cc'd - doing so now. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499142: not ia64 specific
retitle 499142 hangs while building eclipse thanks Turns out this isn't ia64-specific - also seeing it on i386 and powerpc: http://buildd.debian.org/build.php?pkg=eclipsever=3.2.2-6.1arch=i386file=log http://buildd.debian.org/build.php?pkg=eclipsever=3.2.2-6.1arch=powerpcfile=log -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483279: patch
tag 483279 + patch
thanks
Attached is a patch that fixes the issue for me on ia64. Note that
this issue also affects sparc. I plan to do a few more tests tomorrow
and, if successful, proceed with an NMU.
fyi, the attached patch also includes the fix for #480794, which is
needed to build in unstable.
--
dann frazier
diff -u eclipse-3.2.2/debian/rules eclipse-3.2.2/debian/rules
--- eclipse-3.2.2/debian/rules
+++ eclipse-3.2.2/debian/rules
@@ -151,6 +151,7 @@
eclipse-ecj-gcj \
eclipse-add-ppc64-sparc64-s390-s390x \
eclipse-java-home \
+ eclipse-libswt-gtk-symlink-fix \
# eclipse-icon \
# eclipse-efj \
@@ -180,7 +181,7 @@
# eclipse-libswt-mozilla-profiles
- BUILD_DEPS += , libxul-dev
+ BUILD_DEPS += , iceape-dev
MOZILLA_DEP = $${shlibs:Depends}
MOZILLA_HOME = /usr/lib/mozilla
endif
diff -u eclipse-3.2.2/debian/control eclipse-3.2.2/debian/control
--- eclipse-3.2.2/debian/control
+++ eclipse-3.2.2/debian/control
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Debian Java Maintainers [EMAIL PROTECTED]
Uploaders: Jerry Haltom [EMAIL PROTECTED], Michael Koch [EMAIL PROTECTED], Matthias Klose [EMAIL PROTECTED], Stephan Michels [EMAIL PROTECTED]
-Build-Depends: debhelper ( 4.2), dpatch (= 2.0), lsb-release, bzip2, zip, sharutils, default-jdk-builddep, liblucene-java (= 1.4.2), liblucene-java-doc (= 1.4.2), junit (= 3.8), junit4, libjsch-java (= 0.1.36), libgtk2.0-dev (= 2.4), libgnome2-dev (= 2.6), libgnomeui-dev (= 2.6), libxtst-dev, libgl1-mesa-dev, libglu1-mesa-dev, classpath-doc, pkg-config, libcairo2-dev, ant-optional (= 1.6.5-3), libtomcat5.5-java, libxul-dev
+Build-Depends: debhelper ( 4.2), dpatch (= 2.0), lsb-release, bzip2, zip, sharutils, default-jdk-builddep, liblucene-java (= 1.4.2), liblucene-java-doc (= 1.4.2), junit (= 3.8), junit4, libjsch-java (= 0.1.36), libgtk2.0-dev (= 2.4), libgnome2-dev (= 2.6), libgnomeui-dev (= 2.6), libxtst-dev, libgl1-mesa-dev, libglu1-mesa-dev, classpath-doc, pkg-config, libcairo2-dev, ant-optional (= 1.6.5-3), libtomcat5.5-java, iceape-dev
Standards-Version: 3.7.3
Vcs-Svn: svn://svn.debian.org/svn/pkg-java/trunk/eclipse
Vcs-Browser: http://svn.debian.org/wsvn/pkg-java/trunk/eclipse
diff -u eclipse-3.2.2/debian/changelog eclipse-3.2.2/debian/changelog
--- eclipse-3.2.2/debian/changelog
+++ eclipse-3.2.2/debian/changelog
@@ -1,3 +1,12 @@
+eclipse (3.2.2-6.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Update build-dep from libxul-dev to iceape-dev. Closes: #480794
+ * Fix dangling /usr/lib/java/swt3.2-gtk.jar on ia64 and sparc.
+Closes: #483279.
+
+ -- dann frazier [EMAIL PROTECTED] Wed, 08 Oct 2008 00:53:39 -0600
+
eclipse (3.2.2-6) unstable; urgency=low
* Suppress warnings from javac.
diff -u eclipse-3.2.2/debian/patches/eclipse-libswt-xulrunner.dpatch eclipse-3.2.2/debian/patches/eclipse-libswt-xulrunner.dpatch
--- eclipse-3.2.2/debian/patches/eclipse-libswt-xulrunner.dpatch
+++ eclipse-3.2.2/debian/patches/eclipse-libswt-xulrunner.dpatch
@@ -41,9 +41,9 @@
- if [ x`pkg-config --exists mozilla-xpcom echo YES` = xYES ]; then
- GECKO_INCLUDES=`pkg-config --cflags mozilla-xpcom`
- GECKO_LIBS=`pkg-config --libs mozilla-xpcom`
-+ if [ x`pkg-config --exists xulrunner-xpcom echo YES` = xYES ]; then
-+ GECKO_INCLUDES=`pkg-config --cflags xulrunner-xpcom`
-+ GECKO_LIBS=`pkg-config --libs xulrunner-xpcom`
++ if [ x`pkg-config --exists iceape-xpcom echo YES` = xYES ]; then
++ GECKO_INCLUDES=`pkg-config --cflags iceape-xpcom`
++ GECKO_LIBS=`pkg-config --libs iceape-xpcom`
export GECKO_INCLUDES
export GECKO_LIBS
MAKE_MOZILLA=make_mozilla
only in patch2:
unchanged:
--- eclipse-3.2.2.orig/debian/patches/eclipse-libswt-gtk-symlink-fix.dpatch
+++ eclipse-3.2.2/debian/patches/eclipse-libswt-gtk-symlink-fix.dpatch
@@ -0,0 +1,161 @@
+#! /bin/sh -e
+##
+## DP: Debian specific patch, converted from eclipse-swt-x11.patch
+
+[ -f debian/patches/00patch-opts ] . debian/patches/00patch-opts
+patch_opts=${patch_opts:--f --no-backup-if-mismatch}
+
+if [ $# -ne 1 ]; then
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+fi
+case $1 in
+-patch)
+ patch $patch_opts -p0 $0;;
+-unpatch)
+ patch $patch_opts -p0 -R $0;;
+*)
+ echo 2 `basename $0`: script expects -patch|-unpatch as argument
+ exit 1;;
+esac
+exit 0
+
[EMAIL PROTECTED]@
+diff -urpN source-tree.orig/assemble.org.eclipse.sdk.hpux.motif.ia64_32.xml source-tree/assemble.org.eclipse.sdk.hpux.motif.ia64_32.xml
+--- source-tree.orig/assemble.org.eclipse.sdk.hpux.motif.ia64_32.xml 2007-02-12 18:45:20.0 +
source-tree/assemble.org.eclipse.sdk.hpux.motif.ia64_32.xml 2008-10-08 01:48:44.0 +
+@@ -691,7 +691,7 @@
+ /antcall
+ antcall target=jarUp
+ param name=source value=${eclipse.plugins}/
+- param name=elementName value=org.eclipse.swt.motif.hpux.ia64_32_3.2.2.R3_2_maintenance/
++ param name=elementName value=org.eclipse.swt.motif.hpux.ia64_32_3.2.2.v3236/
+ /antcall
+ antcall
Bug#501533: eclipse: [ia64] native compilation ICEs seem to no longer occur
Package: eclipse Version: 3.2.2-6 Severity: normal I noticed this in the changelog entry for version 3.2.2-0ubuntu2: * On ia64, skip some jar files for native compilation to avoid ICEs. This code in debian/rules seems to correspond with that change: if [ $(DEB_HOST_ARCH) = ia64 ]; then \ case $$jar in \ *jsch*) continue;; \ *org.eclipse.osgi*) continue;; \ esac; \ fi; \ While debugging other issues, I tried reverting this patch. The ia64 build succeeded w/o any resulting ICEs. I'm guessing that whatever the issue was has gone away in the 18 months since that release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483279: NMU uploaded
Patch attached - no difference from the proposed one in #483279.
--
dann frazier
diff -u eclipse-3.2.2/debian/rules eclipse-3.2.2/debian/rules
--- eclipse-3.2.2/debian/rules
+++ eclipse-3.2.2/debian/rules
@@ -151,6 +151,7 @@
eclipse-ecj-gcj \
eclipse-add-ppc64-sparc64-s390-s390x \
eclipse-java-home \
+ eclipse-libswt-gtk-symlink-fix \
# eclipse-icon \
# eclipse-efj \
@@ -180,7 +181,7 @@
# eclipse-libswt-mozilla-profiles
- BUILD_DEPS += , libxul-dev
+ BUILD_DEPS += , iceape-dev
MOZILLA_DEP = $${shlibs:Depends}
MOZILLA_HOME = /usr/lib/mozilla
endif
diff -u eclipse-3.2.2/debian/control eclipse-3.2.2/debian/control
--- eclipse-3.2.2/debian/control
+++ eclipse-3.2.2/debian/control
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Debian Java Maintainers [EMAIL PROTECTED]
Uploaders: Jerry Haltom [EMAIL PROTECTED], Michael Koch [EMAIL PROTECTED], Matthias Klose [EMAIL PROTECTED], Stephan Michels [EMAIL PROTECTED]
-Build-Depends: debhelper ( 4.2), dpatch (= 2.0), lsb-release, bzip2, zip, sharutils, default-jdk-builddep, liblucene-java (= 1.4.2), liblucene-java-doc (= 1.4.2), junit (= 3.8), junit4, libjsch-java (= 0.1.36), libgtk2.0-dev (= 2.4), libgnome2-dev (= 2.6), libgnomeui-dev (= 2.6), libxtst-dev, libgl1-mesa-dev, libglu1-mesa-dev, classpath-doc, pkg-config, libcairo2-dev, ant-optional (= 1.6.5-3), libtomcat5.5-java, libxul-dev
+Build-Depends: debhelper ( 4.2), dpatch (= 2.0), lsb-release, bzip2, zip, sharutils, default-jdk-builddep, liblucene-java (= 1.4.2), liblucene-java-doc (= 1.4.2), junit (= 3.8), junit4, libjsch-java (= 0.1.36), libgtk2.0-dev (= 2.4), libgnome2-dev (= 2.6), libgnomeui-dev (= 2.6), libxtst-dev, libgl1-mesa-dev, libglu1-mesa-dev, classpath-doc, pkg-config, libcairo2-dev, ant-optional (= 1.6.5-3), libtomcat5.5-java, iceape-dev
Standards-Version: 3.7.3
Vcs-Svn: svn://svn.debian.org/svn/pkg-java/trunk/eclipse
Vcs-Browser: http://svn.debian.org/wsvn/pkg-java/trunk/eclipse
diff -u eclipse-3.2.2/debian/changelog eclipse-3.2.2/debian/changelog
--- eclipse-3.2.2/debian/changelog
+++ eclipse-3.2.2/debian/changelog
@@ -1,3 +1,12 @@
+eclipse (3.2.2-6.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Update build-dep from libxul-dev to iceape-dev. Closes: #480794
+ * Fix dangling /usr/lib/java/swt3.2-gtk.jar on ia64 and sparc.
+Closes: #483279.
+
+ -- dann frazier [EMAIL PROTECTED] Wed, 08 Oct 2008 00:53:39 -0600
+
eclipse (3.2.2-6) unstable; urgency=low
* Suppress warnings from javac.
diff -u eclipse-3.2.2/debian/patches/eclipse-libswt-xulrunner.dpatch eclipse-3.2.2/debian/patches/eclipse-libswt-xulrunner.dpatch
--- eclipse-3.2.2/debian/patches/eclipse-libswt-xulrunner.dpatch
+++ eclipse-3.2.2/debian/patches/eclipse-libswt-xulrunner.dpatch
@@ -41,9 +41,9 @@
- if [ x`pkg-config --exists mozilla-xpcom echo YES` = xYES ]; then
- GECKO_INCLUDES=`pkg-config --cflags mozilla-xpcom`
- GECKO_LIBS=`pkg-config --libs mozilla-xpcom`
-+ if [ x`pkg-config --exists xulrunner-xpcom echo YES` = xYES ]; then
-+ GECKO_INCLUDES=`pkg-config --cflags xulrunner-xpcom`
-+ GECKO_LIBS=`pkg-config --libs xulrunner-xpcom`
++ if [ x`pkg-config --exists iceape-xpcom echo YES` = xYES ]; then
++ GECKO_INCLUDES=`pkg-config --cflags iceape-xpcom`
++ GECKO_LIBS=`pkg-config --libs iceape-xpcom`
export GECKO_INCLUDES
export GECKO_LIBS
MAKE_MOZILLA=make_mozilla
only in patch2:
unchanged:
--- eclipse-3.2.2.orig/debian/patches/eclipse-libswt-gtk-symlink-fix.dpatch
+++ eclipse-3.2.2/debian/patches/eclipse-libswt-gtk-symlink-fix.dpatch
@@ -0,0 +1,161 @@
+#! /bin/sh -e
+##
+## DP: Debian specific patch, converted from eclipse-swt-x11.patch
+
+[ -f debian/patches/00patch-opts ] . debian/patches/00patch-opts
+patch_opts=${patch_opts:--f --no-backup-if-mismatch}
+
+if [ $# -ne 1 ]; then
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+fi
+case $1 in
+-patch)
+ patch $patch_opts -p0 $0;;
+-unpatch)
+ patch $patch_opts -p0 -R $0;;
+*)
+ echo 2 `basename $0`: script expects -patch|-unpatch as argument
+ exit 1;;
+esac
+exit 0
+
[EMAIL PROTECTED]@
+diff -urpN source-tree.orig/assemble.org.eclipse.sdk.hpux.motif.ia64_32.xml source-tree/assemble.org.eclipse.sdk.hpux.motif.ia64_32.xml
+--- source-tree.orig/assemble.org.eclipse.sdk.hpux.motif.ia64_32.xml 2007-02-12 18:45:20.0 +
source-tree/assemble.org.eclipse.sdk.hpux.motif.ia64_32.xml 2008-10-08 01:48:44.0 +
+@@ -691,7 +691,7 @@
+ /antcall
+ antcall target=jarUp
+ param name=source value=${eclipse.plugins}/
+- param name=elementName value=org.eclipse.swt.motif.hpux.ia64_32_3.2.2.R3_2_maintenance/
++ param name=elementName value=org.eclipse.swt.motif.hpux.ia64_32_3.2.2.v3236/
+ /antcall
+ antcall target=jarUp
+ param name=source value=${eclipse.plugins}/
+@@ -850,7 +850,7 @@
+ arg line=-r -q ${zipargs} '${archiveFullPath}'/
+ arg line=${pluginArchivePrefix}/org.eclipse.ui.workbench.compatibility_3.2.0.I20060605-1400
Bug#500784: probably not a candidate
hey, Holger and I talked about this on IRC, and the current status is that it doesn't appear to meet our guidelines for a stable release update. Stable candidates need to be of = important severity. This bug is wishlist, and that seems to be appropriate considering it is a request for a new feature (as opposed to a regression). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500956: unable to boot on a500 (hppa)
On Fri, Oct 03, 2008 at 07:20:35AM +0200, Martin Michlmayr wrote: * dann frazier [EMAIL PROTECTED] [2008-10-02 17:55]: Are you sure the installer is using 2.6.26-6? This looks a lot like #499458 which should've been fixed in 2.6.26-6 (fixed it for me, at least). Note that he wrote the lenny installer does work, the kernel installed by the installer fails to boot. Which is no surprise since testing still has 2.6.26-5. oh right, that makes sense then. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500956: unable to boot on a500 (hppa)
On Fri, Oct 03, 2008 at 12:39:14AM +0200, Matthias Klose wrote: Package: linux-image-2.6.26-1-parisc64 Version: 2.6.26-6 Severity: serious the lenny installer does work, the kernel installed by the installer fails to boot. The etch kernel does boot. Command line for kernel: 'root=/dev/sda3 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=2/vmlinux' Selected kernel: /vmlinux from partition 2 Selected ramdisk: /initrd.img from partition 2 ELF64 executable Entry 0010 first 0010 n 3 Segment 0 load 0010 size 3866624 mediaptr 0x1000 Segment 1 load 0050c000 size 354080 mediaptr 0x3b1000 Segment 2 load 00564000 size 274566 mediaptr 0x408000 Loading ramdisk 7068216 bytes @ 3f931000... Branching to kernel entry point 0x0010. If this is the last message you see, you may need to switch your console. This is a common symptom -- search the FAQ and mailing list at parisc-linux.org hey Matthias! Are you sure the installer is using 2.6.26-6? This looks a lot like #499458 which should've been fixed in 2.6.26-6 (fixed it for me, at least). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
