Bug#974668: libsigrokdecode: Please upgrade libsigrokdecode to 0.5.3 release
Source: libsigrokdecode Severity: wishlist libsigrokdecode 0.5.3 was released in December 2019 and contains several new decoders. Please consider packaging this version for Debian. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#544030: new upstream version 1.6.7 is available
Package: avr-libc Version: 1:1.6.2.cvs20080610-2 Severity: wishlist Please consider packaging the new upstream version 1.6.7, see: http://mirrors.zerg.biz/nongnu/avr-libc/avr-libc-1.6.7.tar.bz2 Thanks Phil -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531838: evolution: unusably slow since upgrading to 2.26
Package: evolution Version: 2.26.2-2 Severity: important Since upgrading evolution from 2.22 to 2.26, mail operations in general (and switching between folders in particular) have become many times slower than they used to be. Specifically, I have two commonly-used IMAP folders which each contain a fairly large number of emails: about 200,000 in one and about 100,000 in the other. With the old evolution, I could switch between these folders almost instantly (so long as the message headers were already cached locally, of course). In the new version, changing between these two folders takes about a minute. This is sufficiently bad as to make evolution almost unusable since the upgrade. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#394418: [Pkg-mono-group] Bug#394418: mono_1.1.18-3 (arm/unstable): FTBFS: SIGSEGV
On Wed, 2006-11-15 at 15:33 +0100, Mirco Bauer wrote: Also the failing happens not always at the same build position, but its always the first few files that get compiled. Ah, this is new information. If the behaviour is non-deterministic then this also suggests that the problem is caused by some kind of timing issue or other external factor. The build runs 8 to 10 hours on a arm box, a race condition that always happened in the first hour on netwinder, but not at all on cats, means it's not a runtime issue that seem to ever happen on cats. My experience (see my mail on Oct 30) was that the build failed on my CATS too when I tried it there. I don't think we have enough evidence to say with any certainty that the bug is really specific to netwinder. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394418: mono_1.1.18-3 (arm/unstable): FTBFS: SIGSEGV
On Wed, 2006-11-15 at 04:40 -0800, Steve Langasek wrote: But does anyone understand yet *why* this bug affects the netwinders and not the cats boxes? Not really. My best guess is that it's a subtle timing issue of some kind and shows up on the netwinders because they're slightly faster. Or, alternatively, it might be due to some small difference in kernel version between the two platforms. I'm also concerned that, even on the CATS machines, it might be that the build is only succeeding by chance and any real-world workload would cause the same bug to resurface. So, overall, with our current state of knowledge I kind of feel we'd be better off not shipping mono at all on arm. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382711: status=0x37 with a Maxtor drive
Hi Martin
Thanks for your mail. It does sound like your problem is very similar
to mine. Just to give you a bit more background, I originally started
out with two Maxtor drives on the nVidia controller but this
configuration was desperately unstable: under any kind of load, one or
other drive would seize up and start giving command timeout kind of
messages. Initially, this was so bad that I couldn't even finish
installing Debian: it would typically lock up during the initial RAID
mirroring operation when the second drive was added to the array.
I tried swapping the nVidia controller for an ALi one on a PCI card, and
swapping the motherboard for a different one (also with an ALi chipset).
None of these things really seemed to help. If I connected one drive to
the ALi controller and one drive to the nVidia controller then things
were better but still pretty bad.
After that I replaced the two Maxtor drives with a pair of Seagates.
This seemed to improve the situation somewhat but it was still pretty
flaky: after anything between a few hours and a few days, one drive
would start giving timeouts and get kicked from the array. Generally,
this would be followed fairly rapidly by a complete system failure:
either the other drive would fall over in the same way, or the machine
would crash with an Oops like the one I reported.
Since about the end of August I've been running with the RAID in
degraded mode using just a single drive and haven't had any repeat of
these problems. It's frustrating not having any redundancy, but this
seems to be the only configuration that's safe right now. I was
thinking that I might try upgrading to 2.6.17 in case that fixed the
dual-drive situation, but it sounds from your experience like this
probably won't help me much.
Interestingly, though, I do have another amd64 machine which has been
running a RAID5 array of three drives (split across two controllers, one
sata_promise and one sata_via) since January with no trouble. This
machine also has Seagate drives and is using kernel 2.6.14-2-amd64-k8.
Cheers
Phil
On Mon, 2006-11-13 at 13:57 +0100, Martin Schuster wrote:
Hi Jon, Hi Phil, Hello Debian BTS :)
[Jon: Mailing this to you too, I found http://lkml.org/lkml/2006/4/23/63
and thought you might be interested]
Just wanted to report that I have a problem with quite
the same symptoms:
Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)
2 Maxtor 6V250F0 in RAID1
Linux 2.6.17-cks1 with some minor changes
Sometimes (no idea how to trigger this, happens ca. once
per month) I get:
ata1: translated ATA stat/err 0x37/00 to SCSI SK/ASC/ASCQ 0x4/00/00
ata1: status=0x37 { DeviceFault SeekComplete CorrectedError Index Error }
sd 1:0:0:0: SCSI error: return code = 0x802
sdc: Current: sense key=0x4
ASC=0x0 ASCQ=0x0
Info fld=0xd80321c
end_request: I/O error, dev sdc, sector 230225719
ata1: command 0xc8 timeout, stat 0xb7 host_stat 0x21
Until now, this usually only resulted in the faulty
drive being taken offline from the array; today I got
an OOPS too:
raid1: Disk failure on sdc1, disabling device.
^IOperation continuing on 1 devices
[...]
BUG: unable to handle kernel NULL pointer dereference at virtual address
0088
printing eip:
b026b3cf
*pde =
Oops: 0002 [#1]
SMP
Modules linked in: sg sr_mod cdrom ide_generic floppy 8250_pnp 8250
serial_core pcspkr usbhid ohci_hcd skge crc32 sk98lin piix ide_core hw_random
ehci_hcd uhci_hcd usbcore intel_agp agpgart w83627ehf hwmon i2c_isa i2c_core
genrtc
CPU:0
EIP:0060:[b026b3cf]Not tainted VLI
EFLAGS: 00010286 (2.6.17-cks1-cp2 #1)
EIP is at raid1d+0xb79/0xcfa
eax: cfdf2e48 ebx: ecx: 0008 edx: cf878d40
esi: edi: 0001 ebp: ceb96240 esp: cfc4bec0
ds: 007b es: 007b ss: 0068
Process md0_raid1 (pid: 810, threadinfo=cfc4a000 task=cfe43a70)
Stack: b13fcbc0 0001 cfc4a000 cf878d58
cf878d90 b1409f00 cf878d74 cebef040 cfcefa00 1000 cf878d40 cf878d5c
0001 0db8f6f8 0020 0008 b01228a2 9c534d80 00a131f1 b140d408
Call Trace:
b01228a2 run_timer_softirq+0x3a/0x18e b0114b89
default_wake_function+0x0/0xc
b02d35fb schedule_timeout+0x6e/0xac b0278162 md_thread+0x40/0x12a
b012b0ca autoremove_wake_function+0x0/0x37 b0278122 md_thread+0x0/0x12a
b012af18 kthread+0x9f/0xc4 b012ae79 kthread+0x0/0xc4
b0100d25 kernel_thread_helper+0x5/0xb
Code: 1c 39 f7 0f 84 8e 00 00 00 85 ff 75 07 8b 4c 24 38 8b 79 08 83 ef 01 8d
04 fd 00 00 00 00 8b 54 24 38 03 42 04 8b 30 8b 4c 24 4c f0 01 8e 88 00 00
00 85 f6 74 c8 8b 46 70 a8 04 74 c1 8b 4a 60
EIP: [b026b3cf] raid1d+0xb79/0xcfa SS:ESP 0068:cfc4bec0
3ata1: command 0xb0 timeout, stat 0xb7 host_stat 0x0
SMART doesn't report any suspicious values.
I guess my next steps will be to replace the Motherboard (Asus P5P800)
and the drive in question; I'll report back then.
hth,
--
To UNSUBSCRIBE, email to
Bug#394418: [Pkg-mono-group] Bug#394418: v3 v4 question
On Mon, 2006-10-30 at 00:39 +0100, Mirco Bauer wrote:
So we are back to, it never failed to build on cats, but always did on
netwinder.
Mm, strange. I tried to build it by hand on smackdown and it failed
again there:
Creating ../../build/deps/net_2_0_corlib.dll.makefrag ...
make[8]: Leaving directory `/var/tmp/mono-1.1.18/mcs/class/corlib'
make[8]: Entering directory `/var/tmp/mono-1.1.18/mcs/class/corlib'
/usr/bin/make all-local
make[9]: Entering directory `/var/tmp/mono-1.1.18/mcs/class/corlib'
MONO_PATH=../../class/lib/net_2_0_bootstrap:
$MONO_PATH /var/tmp/mono-1.1.18/runtime/mono-wrapper ../../gmcs/gmcs.exe
/codepage:65001 -nowarn:169,612,618,649 -d:INSIDE_CORLIB -nowarn:414
-d:NET_1_1 -d:NET_2_0 -debug /noconfig -unsafe -nostdlib
-resource:resources/collation.core.bin
-resource:resources/collation.tailoring.bin
-resource:resources/collation.cjkCHS.bin
-resource:resources/collation.cjkCHT.bin
-resource:resources/collation.cjkJA.bin -resource:resources/collation.cjkKO.bin
-resource:resources/collation.cjkKOlv2.bin -target:library -out:mscorlib.dll
@corlib.dll.sources
=
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=
mono: unhandled page fault at pc=0x0012e448, lr=0x000dc204 (bad
address=0x0084, code 0)
pc : [0012e448]lr : [000dc204]Not tainted
sp : bf5ff69c ip : bf5ff670 fp : bf5ff6cc
r10: 4011c000 r9 : bf5ff778 r8 : bf5ff6f8
r7 : 0024 r6 : r5 : bf5ff6d0 r4 : bf5ffbe0
r3 : r2 : 4011cca0 r1 : r0 :
Flags: nZCv IRQs on FIQs on Mode USER_32 Segment user
Control: 3CBD17F Table: 03CBD17F DAC: 0015
0012e414 sigusr1_signal_handler:
12e414: e1a0c00dmov ip, sp
12e418: e92dd810stmdb sp!, {r4, fp, ip, lr, pc}
12e41c: e24cb004sub fp, ip, #4 ; 0x4
12e420: e24dd020sub sp, sp, #32 ; 0x20
12e424: e50b0028str r0, [fp, #-40]
12e428: e50b102cstr r1, [fp, #-44]
12e42c: e50b2030str r2, [fp, #-48]
12e430: ebfd81aabl 8eae0 mono_thread_current
12e434: e1a03000mov r3, r0
12e438: e50b301cstr r3, [fp, #-28]
12e43c: e51b3030ldr r3, [fp, #-48]
12e440: e50b3014str r3, [fp, #-20]
12e444: e51b301cldr r3, [fp, #-28]
12e448: e5d33084ldrbr3, [r3, #132]
12e44c: e353cmp r3, #0 ; 0x0
At a first glance this looks more like a TLS emulation kind of problem
than an instruction set discrepancy. But it'd take a bit more detective
work to figure out what's really going wrong, and I guess there is no
guarantee that this is the same problem the netwinders are seeing in any
case.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394418: v3 v4 question
On Sun, 2006-10-29 at 09:09 -0800, Steve Langasek wrote: Ok, is there some other difference at the instruction set level between the netwinder and cats systems? No, the instruction sets are the same. FWIW, though, smackdown is actually a cats, not a netwinder, and the build seems to be failing there in any case. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382711: linux-image-2.6.16-2-xen-amd64-k8: sata assertion failure and kernel oops
Package: linux-image-2.6.16-2-xen-amd64-k8
Version: 2.6.16-17
Severity: normal
A few minutes ago, one of our amd64 machines fell over with the errors
below. It has two Maxtor disks attached to an nVidia controller,
running as a raid1 pair: the boot-time messages look like this:
libata version 1.20 loaded.
sata_nv :00:0e.0: version 0.8
PCI: Setting latency timer of device :00:0e.0 to 64
ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE482 bmdma 0xE000 irq 11
ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE082 bmdma 0xE008 irq 11
ata1: SATA link up 3.0 Gbps (SStatus 123)
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4773 85:7c69 86:3e01 87:4763
88:407f
ata1: dev 0 ATA-7, max UDMA/133, 160086528 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : sata_nv
ata2: SATA link down (SStatus 0)
scsi1 : sata_nv
Vendor: ATA Model: Maxtor 6V080E0Rev: VA11
Type: Direct-Access ANSI SCSI revision: 05
PCI: Setting latency timer of device :00:0f.0 to 64
ata3: SATA max UDMA/133 cmd 0xDC00 ctl 0xD882 bmdma 0xD400 irq 10
ata4: SATA max UDMA/133 cmd 0xD800 ctl 0xD482 bmdma 0xD408 irq 10
ata3: SATA link up 3.0 Gbps (SStatus 123)
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7f69 84:4773 85:7c69 86:3e01 87:4763
88:407f
ata3: dev 0 ATA-7, max UDMA/133, 160086528 sectors: LBA48
ata3: dev 0 configured for UDMA/133
scsi2 : sata_nv
ata4: SATA link down (SStatus 0)
scsi3 : sata_nv
Vendor: ATA Model: Maxtor 6V080E0Rev: VA11
Type: Direct-Access ANSI SCSI revision: 05
Here's the log of the crash:
--
Aug 12 20:14:03 uebercounty kernel: ata1: translated ATA stat/err
0x37/00 to SCSI SK/ASC/ASCQ 0x4/00/00
Aug 12 20:17:03 uebercounty kernel: ata1: status=0x37 { DeviceFault
SeekComplete CorrectedError Index Error }
Aug 12 20:17:03 uebercounty kernel: ata1: command 0x35 timeout, stat
0xb7 host_stat 0x21
Aug 12 20:17:03 uebercounty kernel: ata1: translated ATA stat/err
0xb7/00 to SCSI SK/ASC/ASCQ 0xb/47/00
Aug 12 20:17:03 uebercounty kernel: ata1: status=0xb7 { Busy }
Aug 12 20:17:03 uebercounty kernel: sd 0:0:0:0: SCSI error: return code
= 0x802
Aug 12 20:17:03 uebercounty kernel: sda: Current: sense key: Aborted
Command
Aug 12 20:17:03 uebercounty kernel: Additional sense: Scsi parity
error
Aug 12 20:17:03 uebercounty kernel: end_request: I/O error, dev sda,
sector 4096967
Aug 12 20:17:03 uebercounty kernel: raid1: Disk failure on sda3,
disabling device.
Aug 12 20:17:03 uebercounty kernel: ^IOperation continuing on 1 devices
Aug 12 20:17:03 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:03 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty kernel: ata1: command 0x35 timeout, stat
0xb7 host_stat 0x21
Aug 12 20:17:33 uebercounty kernel: ata1: translated ATA stat/err
0xb7/00 to SCSI SK/ASC/ASCQ 0xb/47/00
Aug 12 20:17:33 uebercounty kernel: ata1: status=0xb7 { Busy }
Aug 12 20:17:33 uebercounty kernel: sd 0:0:0:0: SCSI error: return code
= 0x802
Aug 12 20:17:33 uebercounty kernel: sda: Current: sense key: Aborted
Command
Aug 12 20:17:33 uebercounty kernel: Additional sense: Scsi parity
error
Aug 12 20:17:33 uebercounty kernel: end_request: I/O error, dev sda,
sector 5243841
Aug 12 20:17:33 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty /USR/SBIN/CRON[12579]: (root) CMD (
run-parts --report /etc/cron.hourly)
Aug 12 20:17:33 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty kernel: ata1: command 0x35 timeout, stat
0xb7 host_stat 0x21
Aug 12 20:17:33 uebercounty kernel: ata1: translated ATA stat/err
0xb7/00 to SCSI SK/ASC/ASCQ 0xb/47/00
Aug 12 20:17:33 uebercounty kernel: ata1: status=0xb7 { Busy }
Aug 12 20:17:33 uebercounty kernel: sd 0:0:0:0: SCSI error: return code
= 0x802
Aug 12 20:17:33 uebercounty kernel: sda: Current: sense key: Aborted
Command
Aug 12 20:17:33 uebercounty kernel: Additional sense: Scsi parity
error
Aug 12 20:17:33 uebercounty kernel: end_request: I/O error, dev sda,
sector 5257775
Aug 12 20:17:33 uebercounty kernel: ATA: abnormal status 0xB7 on port
0xE807
Aug 12 20:17:33 uebercounty last message repeated 2 times
[...]
Aug 12 20:31:05 uebercounty kernel: ata1: command 0xa1 timeout, stat
0xb7 host_stat 0x0
Aug 12 20:31:05 uebercounty kernel: ata1: translated ATA stat/err
0xb7/00 to SCSI SK/ASC/ASCQ 0xb/47/00
Aug 12 20:31:05 uebercounty kernel: ata1: status=0xb7 { Busy }
Aug 12 20:31:05 uebercounty kernel: Assertion failed! qc !=
NULL,drivers/scsi/libata-core.c,ata_pio_poll,line=2897
Aug 12 20:31:20 uebercounty last message repeated 911 times
Aug 12 20:31:20 uebercounty kernel: Assertion failed! qc !=
NULL,drivers/scsi/libata-core.c,ata_pio_poll,line=2897
Aug 12 20:31:23 uebercounty last message repeated 182 times
Aug 12 20:31:23
Bug#348194: please include app_pickup.c from bristuff
Package: asterisk Version: 1.2.1.dfsg-1 Severity: wishlist Asterisk's app_directed_pickup doesn't seem to be able to pick up calls that are ringing on a SIP device if the call originated from a Zap channel, though it works fine when both ends of the call are on SIP. Bristuff's app_pickup can pick up calls in this situation, and seems to work fine without the rest of the bristuff patch. Please consider including this module in the Debian package: it's self-contained and shouldn't hurt anybody who isn't using it. The only complication is that app_pickup's Pickup() needs to be renamed to PickupCallGroup() or something, so that it doesn't clash with the one from app_directed_pickup. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348090: please add build-depend on libpopt-dev for smsq
Package: asterisk Severity: wishlist Version: 1.2.1.dfsg-1 Asterisk only builds the smsq utility if it detects popt.h at build time. Please add a build dependency on libpopt-dev to make sure this happens. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342968: Package explicitely build-depends on g++-3.4
reopen 342968 severity 342968 important thanks I don't think that just removing g++-3.4 from the Build-Depends line is an appropriate fix for this bug. The package still does actually require gcc-3.4 to build on ARM; as a result, it's now unbuildable on that architecture: http://buildd.debian.org/fetch.php?pkg=gmsharch=armver=1.61.3-2stamp=1136060975file=log Please either put the Build-Depends back how it was, or remove the requirement for gcc-3.4 from debian/rules. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337263: gij-4.0: segfaults on arm
These patches seem to fix this problem. I haven't tested the resulting gij very extensively, but it can at least execute hello world type stuff now. p. arm-gij.dpatch Description: application/shellscript arm-libffi.dpatch Description: application/shellscript
Bug#345168: Sarge version of nscd is completely broken (Fails to cache any entry)
On Thu, 2005-12-29 at 15:08 +0100, Laurent Caron wrote: I'm using nscd (sarge version) with LDAP, and it is not working. Attaching to it with strace -p $PID shows no activity while doing a simple ls -al /home with a few directories in /home, making constant LDAP lookups. Upgrading nscd to the one in sid solves the problem.. It is hard to believe that the version of nscd in sarge could have remained completely broken for this length of time without someone noticing. So I'm guessing that there must be some local problem on your system that is preventing it from working. Could you please send us the complete strace output from nscd (i.e. from program startup onwards), and also the complete output from strace ls -l /home or something similiar? p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298913: locales: option to locale-gen to avoid regenerating existing locales?
tags 298913 + pending thanks On Thu, 2005-03-10 at 17:16 +, Colin Watson wrote: Attached is a patch that implements a --keep-existing flag, with documentation. It relies on perl-base to figure out whether the locale exists, but perl-base is Essential so that should be OK. Run 'make' in debian/local/manpages/ after applying it. Looks good to me. I've checked this in. Thanks. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326791: install of libc6 wants to remove all kernels
On Mon, 2005-09-05 at 21:10 +0200, Wolfgang Leister wrote: As you can see from the example the install tries to uninstall initrd-tools and all installed kernels. This makes that I cannot upgrade some other packages that depend on a newer version of libc6. This is caused by libc6's Conflict with older versions of initrd-tools. If you upgrade initrd-tools before libc6 then the problem should go away. I'm not sure if there is anything we can do in libc6 to make this situation work better (for example, by encouraging apt to upgrade initrd-tools rather than removing it). Any suggestions would be welcome. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#264887: GLOB_APPEND ignored by glob() in at least one place
On Tue, 2004-08-10 at 14:41 -0500, Jeff Licquia wrote: When the GLOB_APPEND flag is passed to glob(), the call is supposed to tack new results on to the ones already represented in the glob_t passed in. If there is an error, partial results may be added, but the original glob_t should definitely be left alone. This is not respected in at least one part of glibc's glob implementation. In this particular place, globfree() is called on the glob_t regardless of the flags passed. Since glob() is implemented recursively with GLOB_APPEND added to the flags, this can affect the results returned even from a call where GLOB_APPEND is not set. The following patch fixes the one instance of this behavior I found. Thanks for the patch. Do you have a testcase that demonstrates the effect of the bug? p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#214898: Bug#133578: gdm: default locale setting
On Fri, Apr 16, 2004 at 09:13:42PM -0700, Ryan Murray wrote: Just to make it clear to everyone involved -- #133578 is waiting for #214898 to be fixed in glibc. I'm not going to parse/use a tool to read the PAM configuration file /etc/environment. That config file is for setting up the _login_ environment, not the system boot environment. I see that #133578 has been closed now. Does this mean that the requirement for #214898 has gone away, and this bug can also be closed? p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344954: validlocale needs a new home
tags 344954 + pending thanks On Tue, 2005-12-27 at 17:39 -0500, Joey Hess wrote: The validlocale program is currently part of base-config, but base-config is going away. validlocale needs a new home ASAP and locales seems like the best place. Seems reasonable to me. I've checked this into SVN; it'll be in the next upload. Thanks p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329126: please add conflict with sarge gawk to post-sarge libc6
On Mon, 2005-09-19 at 23:07 +0400, Nikita V. Youshchenko wrote:
[EMAIL PROTECTED]:~ echo -n | fakeroot awk '{print}'
awk: relocation error: awk: symbol _dl_catch_error, version GLIBC_PRIVATE not
defined in file ld-linux.so.2 with link time reference
This is fixed in post-sarge gawk 3.1.4-2.0.1.
This may affect large number of people, who upgrade to post-sarge libc6 to
be able to install other post-sarge packages. So it seems reasonable to
add a conflict with sarge version of gawk to current libc6 packages.
I have a feeling that adding this conflict is likely to result in gawk
just being uninstalled, and potentially taking a lot of other packages
with it, during upgrades. If that's the case, it seems that the cure
would be rather worse than the original disease. That said, I agree
with you that just leaving gawk in a broken state is not exactly
satisfactory either.
I've copied this note to debian-release in case the fine folks on that
list can provide any guidance.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314616: doesn't re-read resolv.conf
reassign 314616 no-ip thanks Glibc's standard behaviour is to cache the contents of /etc/resolv.conf across multiple calls to gethostbyname(). I doubt this will change any time soon. The solution to this bug is probably for no-ip to call res_init() prior to attempting resolution, if it suspects that the nameservers are likely to have changed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319524: please allow DHCP server to specify default archive mirror
On Sat, 2005-07-23 at 15:15 -0400, Joey Hess wrote:
Phil Blundell wrote:
You're right that a preseed file would also allow me to set the mirror
location during install, but that would be slightly more cumbersome from
my point of view. I don't really want to get into building customised
CD images, so in order to make it just work without manual
intervention there would need to be a way for clients to automatically
locate the preseed file on the server, which I think would again come
down to a DHCP option.
I've wanted for a while a way to let dhcp servers broadcast a preseed
file (either content or url). If you can point me at a way to make a
dhcp server do that and show me what it looks like to a dhcp client,
then the rest of the peices should be very easy to put together.
Sorry about taking so long to reply to this.
I guess there are a couple of ways to make this work. One possibility
would just be to have the installer try to retrieve the preseed file
from a fixed location on the next-server specified in the DHCP lease,
using tftp and/or http. So, if you wrote next-server 192.168.106.1 in
your dhcpd.conf, the installer might try
http://192.168.106.1/d-i/preseed.txt; or something. That'd be easy to
set up, and probably powerful enough for most folks.
It'd probably help if the clients had 'send vendor-class-identifier
Debian;' or something similar in their dhclient.conf files, in case
the server needed to provide different next-server values to d-i and
other clients.
A slightly more complex approach would be to put this in the dhcp config
file:
option space debian;
option debian.preseed-file code 1 = text;
class debian {
match if option vendor-class-identifier = Debian;
vendor-option-space debian;
option debian.preseed-file http://server/preseed.txt;;
}
That way, you could specify a complete arbitrary URL for the installer
to retrieve, at the cost of rather more configuration at the server end.
I think the URL ought to show up as $new_preseed_file in the
dhclient-script's environment; you'd probably want the script to write
this out to some other file from where the installer proper could pick
it up.
I guess the two mechanisms aren't exclusive: you could have the clients
use the debian.preseed-file option if the server sends it, and
otherwise try the next-server thing.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324795: libc6 in stable broken on arm4vl
The llseek problem is caused by a kernel bug. I thought that the 2.2.19 netwinder kernels in Debian had been patched to fix this, but I guess I was mistaken about that. Anyway, there isn't a great deal that we can do in glibc to fix the underlying problem. I guess we could add a check to glibc's preinst to catch this case and prevent the new library being installed under a kernel where it won't work. The easiest thing would just be to disallow anything older than 2.4.0. Writing a directed test to detect the presence of the actual bug would also be possible, but that'd be a bit harder. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343154: arm build broken by -msoft-float flag
Package: asterisk Version: 1:1.2.0.dfsg-1 Severity: serious Somewhere around 1.2.0, asterisk seems to have started trying to use -msoft-float when compiling some of its constituent parts on ARM. This isn't going to work: soft float is a whole new ABI, and you can't mix and match between soft and hard FP in a single executable. See: http://buildd.debian.org/fetch.php?pkg=asteriskver=1% 3A1.2.0.dfsg-1arch=armstamp=1132256374file=logas=raw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343155: ftbfs: build-depends on nonexistent automake1.6
Package: vegastrike Version: 0.4.3-3 Severity: serious This package has a build dependency on automake1.6, which doesn't exist any more in unstable. See: http://buildd.debian.org/fetch.php?pkg=vegastrikearch=armver=0.4.3-3stamp=1134028424file=log -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343061: patch needed for build on arm
Package: dmalloc
Version: 5.4.2-2
This package fails to build with recent compilers due to some bad inline
assembly:
http://buildd.debian.org/~jeroen/status/package.php?p=dmalloca=arm#fail-arm
The patch below seems to fix this problem.
--- clean/dmalloc-5.4.2/return.h2004-10-19 14:51:21.0 +
+++ dmalloc-5.4.2/return.h 2005-12-12 08:48:53.0 +
@@ -301,7 +301,7 @@
* For ARM based machines with gcc/gas 3.3.3 -- Silvester Erdeg.
*/
#ifdef __arm__
-#define GET_RET_ADDR(file) asm(str lr, %0 : =g (file) : /* no
inputs */ )
+#define GET_RET_ADDR(file) do { register int lr asm(lr); file =
(char *)lr; } while (0)
#endif
/*/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327849: arm: Cannot handle identifiers with '$' character
On Mon, 2005-09-12 at 22:24 +0200, Matthias Klose wrote: On arm only, gcc cannot handle C identifiers like: static void L1__GET_$ENVIRONMENT__defmacro() please could you (or somebody having access to an arm machine) check, if the problem exists in gcc-3.4 and/or gcc-snapshot as well? if these fail as well, is it possible to build the package using gcc-3.3 on arm? From what Camm told me before, it sounds like this problem only exists in gcc-4.0. I haven't investigated this issue at all, but at a first guess I would say this is caused by the patches to support the new ARM EABI (in which all identifiers containing $ are reserved). We should probably back out that change in Debian, at least for the time being. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319770: continual rekeying causes inordinate CPU usage
Package: racoon Version: 1:0.6-1 Severity: normal After racoon has been running for a while, it seems to get itself into a state where it is continuously setting up and tearing down SAs as quickly as it can: Jul 24 18:44:51 mebius racoon: INFO: IPsec-SA established: ESP/Tunnel x.x.x.x[4500]-192.168.2.101[4500] spi=242473511(0xe73da27) Jul 24 18:44:51 mebius racoon: INFO: IPsec-SA established: ESP/Tunnel 192.168.2.101[4500]-x.x.x.x[4500] spi=258690464(0xf6b4da0) Jul 24 18:44:52 mebius racoon: INFO: IPsec-SA expired: ESP/Tunnel x.x.x.x[0]-192.168.2.101[0] spi=242473511(0xe73da27) Jul 24 18:44:52 mebius racoon: INFO: initiate new phase 2 negotiation: 192.168.2.101[4500]=x.x.x.x[4500] Jul 24 18:44:52 mebius racoon: INFO: NAT detected - UDP encapsulation (ENC_MODE 1-3). Jul 24 18:44:52 mebius racoon: INFO: Adjusting my encmode UDP-Tunnel-Tunnel Jul 24 18:44:52 mebius racoon: INFO: Adjusting peer's encmode UDP-Tunnel(3)-Tunnel(1) Jul 24 18:44:52 mebius racoon: INFO: IPsec-SA established: ESP/Tunnel x.x.x.x[4500]-192.168.2.101[4500] spi=242473511(0xe73da27) Jul 24 18:44:52 mebius racoon: INFO: IPsec-SA established: ESP/Tunnel 192.168.2.101[4500]-x.x.x.x[4500] spi=217834153(0xcfbe2a9) Jul 24 18:44:53 mebius racoon: INFO: IPsec-SA expired: ESP/Tunnel x.x.x.x[0]-192.168.2.101[0] spi=242473511(0xe73da27) Jul 24 18:44:53 mebius racoon: INFO: initiate new phase 2 negotiation: 192.168.2.101[4500]=x.x.x.x[4500] Jul 24 18:44:53 mebius racoon: INFO: NAT detected - UDP encapsulation (ENC_MODE 1-3). Jul 24 18:44:53 mebius racoon: INFO: Adjusting my encmode UDP-Tunnel-Tunnel Jul 24 18:44:53 mebius racoon: INFO: Adjusting peer's encmode UDP-Tunnel(3)-Tunnel(1) Jul 24 18:44:53 mebius racoon: INFO: IPsec-SA established: ESP/Tunnel x.x.x.x[4500]-192.168.2.101[4500] spi=242473511(0xe73da27) Jul 24 18:44:53 mebius racoon: INFO: IPsec-SA established: ESP/Tunnel 192.168.2.101[4500]-x.x.x.x[4500] spi=83407585(0x4f8b2e1) Jul 24 18:44:54 mebius racoon: INFO: IPsec-SA expired: ESP/Tunnel x.x.x.x[0]-192.168.2.101[0] spi=242473511(0xe73da27) Jul 24 18:44:54 mebius racoon: INFO: initiate new phase 2 negotiation: 192.168.2.101[4500]=x.x.x.x[4500] As well as making it difficult to actually use the encrypted link, this is annoying because it causes racoon to chew up a large amount of CPU time. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319524: please allow DHCP server to specify default archive mirror
On Sat, 2005-07-23 at 10:54 +0200, Christian Perrier wrote: I may be wrong but I think that passing information about the Debian mirror is not DHCP job. This information can be preseeded using the normal preseed mechanism, I think this is pretty enough for any kind of automation. In my view, the mirror location is part of the network environment. DHCP already has mechanisms to report NTP servers, name servers, print servers and even IRC servers; I don't think the Debian mirror server is conceptually any different to these. Ultimately, in fact, I'd like a way for a running Debian system to update its /etc/apt/sources.list based on DHCP information, so that I don't have to edit sources.list on every machine if the mirror location changes. You're right that a preseed file would also allow me to set the mirror location during install, but that would be slightly more cumbersome from my point of view. I don't really want to get into building customised CD images, so in order to make it just work without manual intervention there would need to be a way for clients to automatically locate the preseed file on the server, which I think would again come down to a DHCP option. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319466: automatically use STARTTLS for IMAP connections
On Sat, 2005-07-23 at 11:36 +, Alexander Sack wrote: Y Giridhar Appaji Nag wrote: Alex, I hope you are OK with marking this as forwarded to upstream :-). I thought this would be a good opportunity to play around more with the [EMAIL PROTECTED] mailserver. Sure, thank you! Feel free to do so in future :). Maybe try to verify if the latest thunderbird HEAD build (1.1a?) fixes this bug - the bug is already closed upstream. If it really fixes this, tag it fixed-upstream, so I remember to close it with the first 1.1 upload. Although it is marked as fixed upstream, I tend to agree with the view expressed in this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=60377#c59 -- namely, that the utility of STARTTLS is greatly reduced if it isn't enabled by default. I'd prefer to see this bug kept open until TLS negotiation is enabled out of the box (ideally for all servers, but I could live with it happening just for those that are LOGINDISABLED). thanks p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319524: please allow DHCP server to specify default archive mirror
Package: debian-installer Version: sarge Severity: wishlist We have a local mirror of the Debian archive on our office network. It'd be great if there was some option I could set in my DHCP configuration to tell the installer about this mirror, rather than having to enter information manually and fill in the details every time I install. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#285628: dillo: FTBFS (amd64/gcc-4.0): invalid storage class for function 'Html_write_raw'
On Wed, 2005-07-20 at 22:00 +0100, Roger Leigh wrote: Unless you plan to upload a new version that fixes this bug in the next few days, or you object to the changes in the following patch, I intend to NMU dillo shortly to fix this RC bug. Please go ahead. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308150: racoon: chokes on ISAKMP_NPTYPE_NATOA_DRAFT payload
Package: racoon Version: 1:0.5.1-1 I use racoon in a mixed environment with both Linux and Windows XP/2000 clients. It seems that, when the Windows clients are using NAT-T, they send a NAT Original Address payload, which racoon doesn't understand. It prints ignore the packet, received unexpecting [sic] payload type 131. messages and, true to its word, ignores the packets, which obviously means that negotiation fails. This trivial patch causes racoon to silently ignore the NATOA_DRAFT payloads, which is sufficient to make things work for me. Thanks p. --- clean/ipsec-tools-0.5.1/src/racoon/isakmp_quick.c 2005-03-02 20:00:43.0 + +++ ipsec-tools-0.5.1/src/racoon/isakmp_quick.c 2005-05-08 10:58:21.0 +0100 @@ -980,6 +980,9 @@ isakmp_check_notify(pa-ptr, iph2-ph1); break; + case ISAKMP_NPTYPE_NATOA_DRAFT: + break; + default: plog(LLV_ERROR, LOCATION, iph2-ph1-remote, ignore the packet,
Bug#257343: Should I report another bug (was: Please don't remove dillo from GNOME/KDE menus)
On Wed, 2005-02-02 at 21:24 +0200, AKL. Mantas Kriauciunas wrote: It seems Dan Korostelev [EMAIL PROTECTED] doesn't care about this bugreport (more than 2 months without answer) :( Should I report another bug about missing icon and freedesktop menu and desktop entry standarts or simply change subject of this bugreport ? If nobody will answer me I change subject after one month ;) Please go ahead and retitle this bug report. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
