Bug#1011127: [Pkg-openssl-devel] Bug#1011127: libssl3 breaks systems vith VIA Nehemiah cpu
Am 2022-05-17 15:34, schrieb Sebastian Andrzej Siewior: On 2022-05-17 12:53:07 [+0200], Wolfgang Walter wrote: Systems with VIA Nehemiah cpu break after upgrading unstable. All commands using libssl3 fail with … lscpu shows: Architecture:i686 CPU op-mode(s): 32-bit … Flags: fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse cpuid rng rng_en ace ace_en My guess is that your CPU lacks sse2, which in turn doesn't support multi-byte nops, which in turn does not support the endbr opcode / CET. I built i386 packages without endbr and uploaded everything to https://people.debian.org/~bigeasy/openssl-3-noendbr/ Could you please give a try report if this is correct? Sebastian Yes, with libssl3_3.0.3-4.noendbr_i386.deb this is fixed. Thanks -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#1011127: libssl3 breaks systems vith VIA Nehemiah cpu
Package: libssl3 Version: 3.0.3-4 Severity: grave Systems with VIA Nehemiah cpu break after upgrading unstable. All commands using libssl3 fail with traps: modprobe[2002] trap invalid opcode ip:b7c14700 sp:bfed3238 error:0 in libcrypto.so.3[b7ac+24f000] traps: sshd[1969] trap invalid opcode ip:b7b9c700 sp:bfedeaf8 error:0 in libcrypto.so.3[b7a48000+24f000] lscpu shows: Architecture:i686 CPU op-mode(s): 32-bit Address sizes: 32 bits physical, 32 bits virtual Byte Order: Little Endian CPU(s): 1 On-line CPU(s) list: 0 Vendor ID: CentaurHauls BIOS Vendor ID: VIA Model name: VIA Nehemiah BIOS Model name: Eden ESP CPU @ 1.0GHz BIOS CPU family: 13 CPU family: 6 Model: 9 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 Stepping:8 BogoMIPS:1995.89 Flags: fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse cpuid rng rng_en ace ace_en Vulnerability Itlb multihit: Processor vulnerable Vulnerability L1tf: Vulnerable Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled Vulnerability Meltdown: Vulnerable Vulnerability Spec store bypass: Vulnerable Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2:Mitigation; Retpolines, STIBP disabled, RSB filling Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Systems with a VIA Eden Processor do not show this problem (flags are fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx cpuid pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#1003574: segfault in libc-2.33.so during i386 boot ofde QEMU VM
Am 2022-01-15 11:26, schrieb Aurelien Jarno: control: reopen -1 control: merge 1003610 -1 control: severity -1 serious control: found -1 glibc/2.33-1 control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=28784 On 2022-01-12 14:08, Christian Kastner wrote: Hi Aurelien, thank you for the quick reply. On 2022-01-12 11:45, Aurelien Jarno wrote: >> # Boot image. -enable-kvm assumes that this is being tested on amd64 >> # Optionally use -nographic for terminal output instead of GUI >> $ qemu-system-i386 \ >>-machine q35 \ >>-enable-kvm \ > > You might also want to try without -enable-kvm Indeed, this fixed the issue. So sorry for the noise. I was 120% sure that I had tried that. My turn to be sorry, it appears to be a genuine issue on the GNU libc side, and changing the CPU definition in QEMU, either with -cpu or by disabling kvm) just hide the bug. I was not able to reproduce the issue as you need a non-Intel CPU to get the issue with the command line your provided. This bug also affects via C7 CPUs. I have reported the issue upstream and provided a patch, currently waiting for review. Regards, Aurelien I built the libc6 deb-package for i386 with your patch applied. It fixes the problem for VIA C7 and VIA Eden. Thanks a lot for your help. I hope upstream will include this fix soon. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#941018: ibus 1.5.21-1 does not work with qt5 applications
Package: ibus Version: 1.5.21-1 Severity: serious After upgrading from 1.5.19-4 to 1.5.21-1 all may qt5 ibus stop working with ibus (for example anki, kate, konsole, ...). If one switches to say chinese, nothing happens , the default keyboard remains to input method. Switching input method in chromium, for example, works. Downgrading back to the version in testing (which is 1.5.19-4+b1) fixes the issue. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#850430: fixed in postfix 3.1.4-2
On Fri, 06 Jan 2017 16:49:17 + LaMont Jones <lam...@debian.org> wrote: > Source: postfix > Source-Version: 3.1.4-2 > > We believe that the bug you reported is fixed in the latest version of > postfix, which is due to be installed in the Debian FTP archive. This does not fix the problem here. What fixes the problem is making a symlink to smtp called lmtp and changing master.cf to call lmtp instead of smtp. I don't think you can call smtp as smtp if you want it to act in lmtp mode. Here code from smtp.c: (from https://git.launchpad.net/postfix/tree/src/smtp/smtp.c?h=stable/v3.1) /* * XXX At this point, var_procname etc. are not initialized. * * The process name, "smtp" or "lmtp", determines the protocol, the DSN * server reply type, SASL service information lookup, and more. Prepare * for the possibility there may be another personality. */ sane_procname = sane_basename((VSTRING *) 0, argv[0]); if (strcmp(sane_procname, "smtp") == 0) smtp_mode = 1; else if (strcmp(sane_procname, "lmtp") == 0) smtp_mode = 0; So I think there must be a link lmtp => smtp and in master.cf it sould be lmtp unix - - - - - lmtp Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#841420: --enable-default-pie breaks kernel builds
On Friday, 21 October 2016 14:45:25 CEST Ritesh Raj Sarraf wrote: > The Debian kernel packages still have a dependency on gcc-5, which may mean > that the kernels are currently only built/supported with gcc-5. vanilla kernels (Linus' tree and the stable ones) could be compiled just fine with gcc 6.2.0-6 and that now fails. I still think this is a major regression and regard gcc 6.2.0-7 simply as broken. > > On Thu, 2016-10-20 at 11:22 -0500, S R Wright wrote: > > Concurring with Wolfgang; pulling the source straight from kernel.org > > and using identical .config files will work with 6.2.0-6 but fail with > > 6.2.0-7. I was able to build and install 4.8.3 with no issues after > > back-revving gcc et. al. to 6.2.0-6 > > > > -- sRw > > > > On 10/20/16 11:09, Wolfgang Walter wrote: > > > Hello, > > > > > > with this version of gcc-6 I can't build vanilla kernels any more. It > > > fails > > > with even with CC_STACKPROTECTOR_STRONG disabled: > > > > > > scripts/kconfig/mconf Kconfig > > > configuration written to .config > > > > > > *** End of the configuration. > > > *** Execute 'make' to start the build or try 'make help'. > > > > > > ksrc@ei:~/build/kernels/linux-4.8.3$ make > > > scripts/kconfig/conf --silentoldconfig Kconfig > > >CHK include/config/kernel.release > > >CHK include/generated/uapi/linux/version.h > > >CHK include/generated/utsrelease.h > > >UPD include/generated/utsrelease.h > > >CC kernel/bounds.s > > > kernel/bounds.c:1:0: error: code model kernel does not support PIC mode > > > /* > > > > > > Kbuild:45: recipe for target 'kernel/bounds.s' failed > > > make[1]: *** [kernel/bounds.s] Error 1 > > > Makefile:1015: recipe for target 'prepare0' failed > > > make: *** [prepare0] Error 2 > > > > > > > > > I think this is a major regression if you can't build vanilla and stable > > > kernels any more. > > > > > > Regards, Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#841420: --enable-default-pie breaks kernel builds
Hello, with this version of gcc-6 I can't build vanilla kernels any more. It fails with even with CC_STACKPROTECTOR_STRONG disabled: scripts/kconfig/mconf Kconfig configuration written to .config *** End of the configuration. *** Execute 'make' to start the build or try 'make help'. ksrc@ei:~/build/kernels/linux-4.8.3$ make scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC kernel/bounds.s kernel/bounds.c:1:0: error: code model kernel does not support PIC mode /* Kbuild:45: recipe for target 'kernel/bounds.s' failed make[1]: *** [kernel/bounds.s] Error 1 Makefile:1015: recipe for target 'prepare0' failed make: *** [prepare0] Error 2 I think this is a major regression if you can't build vanilla and stable kernels any more. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#837759: network configuration stops working reliably
Hello Martin, On Monday, 19 September 2016 11:02:08 CEST Martin Pitt wrote: > Hello Wolfgang, > > Wolfgang Walter [2016-09-14 23:34 +0200]: > > > > I tested this with a script: > FTR, I tried this as welll, and I cannot reproduce the bug either. > > Wolfgang Walter [2016-09-14 17:56 +0200]: > > Yes, systemd-networkd ist active. But on most machines I only have *.link > > > entries, usually one to name the device: > *.link entries are handled by udev, not networkd. So if you can > reproduce this on a machine with only has files like > > > == > > [Match] > > MACAddress=11:22:33:44:55:66 > > > > [Link] > > Name=net > > WakeOnLan=off > > == > > then can you please "systemctl disable --now systemd-networkd" and > check if the problem still happens? I suppose not, but if so, this > tells us that this is being done through udev. When I disable systemd-networkd the problem disappears. The reason I think it is a race is because it depends on how many interfaces you set up, if you use systemd-networkd to setup some interfaces and the number of ip-addresses and things you do in /etc/network/interfaces. For example on that simple machines where I only have *.link and don't use systemd-networkd: sometimes (maybe 2 out of 10) it works, but most of the time I loose some or all ip-adresses. Here is the log (without) debugging: in this case the interface only kept the IPv6 addresses and lost its ipv4 address, all set up in /etc/network/interfaces. Sep 19 11:33:25 maiskolben systemd[1]: Starting Raise network interfaces... Sep 19 11:33:25 maiskolben systemd[1]: Starting Network Service... Sep 19 11:33:26 maiskolben systemd-networkd[480]: Enumeration completed Sep 19 11:33:26 maiskolben systemd-networkd[480]: net: Lost carrier Sep 19 11:33:26 maiskolben systemd-networkd[480]: net: Gained carrier Sep 19 11:33:26 maiskolben systemd[1]: Started Network Service. Sep 19 11:33:27 maiskolben systemd-networkd[480]: net: Gained IPv6LL Sep 19 11:33:27 maiskolben ifup[352]: Waiting for DAD... Done Sep 19 11:33:27 maiskolben systemd[1]: Started Raise network interfaces. But there is nothing special about ipv4-addresses. With more interfaces one may loose some or all of the ipv6 adresses, too. I think the crucial point is that systemd-networkd may declares the interface "net" unamanaged AFTER "net: Lost carrier" so that all addresses confgured until that point are ripped off. This " Lost carrier" is always there on startup, don't know if this is caused by udev when it detects the interface on startup. Here is the log with systemd-networkd disabled: Sep 19 11:37:20 maiskolben systemd[1]: Starting Raise network interfaces... Sep 19 11:37:22 maiskolben ifup[400]: Waiting for DAD... Done Sep 19 11:37:23 maiskolben systemd[1]: Started Raise network interfaces. > > If networkd itself is really the culprit, can you please try the > following: > > * Keep it disabled, run your test.sh to set up the dummy interface, >and run > > SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd > > (as root). Does this now cause the addresses to be removed? This > will run much later than test.sh, so this will tell us if this is a > principal logic error or a race condition, i. e. only happens if > networkd starts at the right time after test.sh. No, I don't loose any addresses then. But as you see there is no such "net: Lost carrier" or "TEST: Lost carrier" and so on. SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd Found container virtualization none Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Got message type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch cookie=2 reply_cookie=0 error=n/a Got message type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a interface=n/a member=n/a cookie=3 reply_cookie=2 error=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName cookie=3 reply_cookie=0 error=n/a Got message type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a interface=n/a member=n/a cookie=5 reply_cookie=3 error=n/a Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory timestamp of '/etc/systemd/network' changed timestamp of '/lib/systemd/network' changed TEST: Flags change: +UP +LOWER_UP +RUNNING
Bug#837759: network configuration stops working reliably
On Wednesday, 14 September 2016 10:00:28 CEST Felipe Sateler wrote: > Control: tags -1 moreinfo > > On 14 September 2016 at 06:59, Wolfgang Walter <wolfgang.wal...@stwm.de> > wrote: > > Package: systemd > > Version: 231-6 > > Severity: grave > > > > Starting with version 231-6 the configuration of network interfaces stops > > working reliably when rebooting a system. Downgrading to 231-5 fixes the > > problem. > > > > Symptoms: If a network interface is configured using > > /etc/network/interfaces it seems that systemd now sometimes removes the > > configured ip4 and/or ipv6 addresses in the boot process. It also seems > > to remove routes of network interfaces configured manually or with > > /etc/network/interfaces if the link state changes. > > > > This seems not only be the case with interfaces configured via > > /etc/network/ interfaces but with any interface one creates and assigns > > ip addresses manually. > > > > I tested this with a script: > > > > #!/bin/sh > > if [ "$1" = start ]; then > > ip link del TEST >/dev/null 2>&1 || true > > ip link add name TEST type dummy > > ip -b - <<"EOF" > > link set TEST up > > addr add 10.10.10.10/32 dev TEST nodad > > addr add 2a01:1:1:1::1/128 dev TEST nodad > > addr add 2a01:1:1:1::2/128 dev TEST nodad > > addr add 2a01:1:1:1::3/128 dev TEST nodad > > addr add 2a01:1:1:1::4/128 dev TEST nodad > > addr add 2a01:1:1:1::5/128 dev TEST nodad > > EOF > > ip addr ls TEST > > sleep 2 > > elif [ "$1" = stop ]; then > > ip addr flush dev TEST > > ip link del TEST > > fi > > > > which I start with as a systemd oneshot service with > > > > Before=systemd-networkd.service > > > > I can see in the journal that TEST has all adresses assigned but with > > 231-6 it looses them again (probably when systemd-networkd.service > > starts). With 231-5 or earlier this in not the case. > > It appears you are using systemd-networkd. Could you please attach > your networkd configuration? > > Version 231-6 is built with iptables support, so that may be causing > an interaction that was not visible before. I think this is the problem: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=debian/231-6=79e10aaee1cdd412bd42f13f26e558ba1cd2196b I suppose is that the check for LINK_STATE_UNMANAGED may be racy. The interface may go down and up before LINK_STATE_UNMANAGED is set. Maybe the state is LINK_STATE_PENDING ? Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#837759: network configuration stops working reliably
Am Mittwoch, 14. September 2016, 10:00:28 schrieben Sie: > Control: tags -1 moreinfo > > On 14 September 2016 at 06:59, Wolfgang Walter <wolfgang.wal...@stwm.de> wrote: > > Package: systemd > > Version: 231-6 > > Severity: grave > > > > Starting with version 231-6 the configuration of network interfaces stops > > working reliably when rebooting a system. Downgrading to 231-5 fixes the > > problem. > > > > Symptoms: If a network interface is configured using > > /etc/network/interfaces it seems that systemd now sometimes removes the > > configured ip4 and/or ipv6 addresses in the boot process. It also seems > > to remove routes of network interfaces configured manually or with > > /etc/network/interfaces if the link state changes. > > > > This seems not only be the case with interfaces configured via > > /etc/network/ interfaces but with any interface one creates and assigns > > ip addresses manually. > > > > I tested this with a script: > > > > #!/bin/sh > > if [ "$1" = start ]; then > > ip link del TEST >/dev/null 2>&1 || true > > ip link add name TEST type dummy > > ip -b - <<"EOF" > > link set TEST up > > addr add 10.10.10.10/32 dev TEST nodad > > addr add 2a01:1:1:1::1/128 dev TEST nodad > > addr add 2a01:1:1:1::2/128 dev TEST nodad > > addr add 2a01:1:1:1::3/128 dev TEST nodad > > addr add 2a01:1:1:1::4/128 dev TEST nodad > > addr add 2a01:1:1:1::5/128 dev TEST nodad > > EOF > > ip addr ls TEST > > sleep 2 > > elif [ "$1" = stop ]; then > > ip addr flush dev TEST > > ip link del TEST > > fi > > > > which I start with as a systemd oneshot service with > > > > Before=systemd-networkd.service > > > > I can see in the journal that TEST has all adresses assigned but with > > 231-6 it looses them again (probably when systemd-networkd.service > > starts). With 231-5 or earlier this in not the case. > > It appears you are using systemd-networkd. Could you please attach > your networkd configuration? Yes, systemd-networkd ist active. But on most machines I only have *.link entries, usually one to name the device: == [Match] MACAddress=11:22:33:44:55:66 [Link] Name=net WakeOnLan=off == Most of them are virtual machines. On those machine where I also habe *.netdev and *.network entries this also happens. The one with the simpliest has only one *.network: == [Match] Name=net [Network] LinkLocalAddressing=ipv6 IPv6AcceptRouterAdvertisements=no DHCP=no Address=10.11.12.13/24 Gateway=10.11.12.1 Address=2001:1234:1::abc1 Address=2001:1234:1::abc2 Address=2001:1234:1::abc3 Address=2001:1234:1::abc4 NTP=2001:1234:1::123 [Route] Gateway=fe80::1 PreferredSource=2001:1234:1::abc1 == This interface works fine. But other interfaces configured by /etc/network/interfaces or the manually created interface TEST loose there ipv4 and ipv6 addresses. Please note, that I did not create a *.link entry for TEST on any of the machines. If I later restart these interfaces (with ifdown + ifup for /etc/network/interfaces, systemctl restart test-network-device.service for TEST) they keep their addresses. > > Version 231-6 is built with iptables support, so that may be causing > an interaction that was not visible before. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#837759: network configuration stops working reliably
Package: systemd Version: 231-6 Severity: grave Starting with version 231-6 the configuration of network interfaces stops working reliably when rebooting a system. Downgrading to 231-5 fixes the problem. Symptoms: If a network interface is configured using /etc/network/interfaces it seems that systemd now sometimes removes the configured ip4 and/or ipv6 addresses in the boot process. It also seems to remove routes of network interfaces configured manually or with /etc/network/interfaces if the link state changes. This seems not only be the case with interfaces configured via /etc/network/ interfaces but with any interface one creates and assigns ip addresses manually. I tested this with a script: #!/bin/sh if [ "$1" = start ]; then ip link del TEST >/dev/null 2>&1 || true ip link add name TEST type dummy ip -b - <<"EOF" link set TEST up addr add 10.10.10.10/32 dev TEST nodad addr add 2a01:1:1:1::1/128 dev TEST nodad addr add 2a01:1:1:1::2/128 dev TEST nodad addr add 2a01:1:1:1::3/128 dev TEST nodad addr add 2a01:1:1:1::4/128 dev TEST nodad addr add 2a01:1:1:1::5/128 dev TEST nodad EOF ip addr ls TEST sleep 2 elif [ "$1" = stop ]; then ip addr flush dev TEST ip link del TEST fi which I start with as a systemd oneshot service with Before=systemd-networkd.service I can see in the journal that TEST has all adresses assigned but with 231-6 it looses them again (probably when systemd-networkd.service starts). With 231-5 or earlier this in not the case. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#815173: kernel-image-4.4.0-1-amd64 does not boot on my Thinkpad X240
Package: linux-image-4.4.0-1-amd64 Version: 4.4.2-1 Severity: serious Hello, This kernel does not boot on my Thinkpad X240. grub loads the kernel and the initrd. Then die computer hangs. There is no additional output. I must switch the computer with the powerbutton. linux-image-4.4.0-trunk-amd64 works fine. Regards -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#728823: Fails to start: Running without the SUID sandbox!
same problem here. A workaround is to make a symlink ln -s chromium-sandbox /usr/lib/chromium/chrome-sandbox -- Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722604: Info received (Bug#722604: Info received (udev: system won't mount partitions at boot, nor create network interface
Hello,
CONFIG_DEVTMPFS_MOUNT=y
does not fix our problems here, we need the changes to /etc/init.d/udev I
mailed earlier.
The reason is that we start a complete debian system as initramfs. In this
case CONFIG_DEVTMPFS_MOUNT=y does nothing. As there is no devtmpfs mounted the
bugs in /etc/init.d/udev are triggered: it tries to mount a tmpfs (instead of
devtmpfs) and even this fails because it calls mount erroneously.
Probably debian systems running custom kernels built without
CONFIG_DEVTMPFS_MOUNT=y will start, too, if /etc/init.d/udev is fixed.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--- udev.orig 2013-09-16 13:41:20.750160567 +0200
+++ udev 2013-09-15 02:48:03.699703206 +0200
@@ -22,11 +22,11 @@
# mount a tmpfs over /dev, if somebody did not already do it
mount_tmpfs() {
if grep -E -q ^[^[:space:]]+ /dev (dev)?tmpfs /proc/mounts; then
-mount -n -o remount,${dev_mount_options} -t tmpfs tmpfs /dev
+mount -n -o remount,${dev_mount_options} -t devtmpfs devtmpfs /dev
return
fi
- if ! mount -n -o $dev_mount_options -t tmpfs tmpfs /dev; then
+ if ! mount -n -o $dev_mount_options -t devtmpfs devtmpfs /dev; then
log_failure_msg udev requires tmpfs support, not started
log_end_msg 1
fi
@@ -144,6 +144,11 @@
# new /dev has been mounted and udevadm trigger has been run there will be
# no /dev/null. This also means that you cannot use the shell command.
+dev_mount_options='mode=0755'
+if [ $tmpfs_size ]; then
+ dev_mount_options=size=${tmpfs_size},${dev_mount_options}
+fi
+
case $1 in
start)
if init_is_upstart 2/dev/null; then
Bug#722604: udev: system won't mount partitions at boot, nor create network interfaces
/etc/init.d/udev has a bug which breaks it here:
$dev_mount_options is empty (not set at all) which makes
mount -n -o $dev_mount_options -t tmpfs tmpfs /dev
fail in mount_tmpfs().
I think
dev_mount_options='mode=0755'
if [ $tmpfs_size ]; then
dev_mount_options=size=${tmpfs_size},${dev_mount_options}
fi
is missing.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722604: Info received (udev: system won't mount partitions at boot, nor create network interfaces)
I had to make another change to /etc/init.d/udev:
in mount_tmpfs() I had to change tmpfs to devtmpfs:
mount_tmpfs() {
if grep -E -q ^[^[:space:]]+ /dev (dev)?tmpfs /proc/mounts; then
mount -n -o remount,${dev_mount_options} -t devtmpfs devtmpfs /dev
return
fi
if ! mount -n -o $dev_mount_options -t devtmpfs devtmpfs /dev; then
log_failure_msg udev requires tmpfs support, not started
log_end_msg 1
fi
return 0
}
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704174: CVE-2013-2266
Package: src:bind9 Version: 1:9.8.4.dfsg.P1-6 Severity: grave http://cxsecurity.com/issue/WLB-2013030255 https://kb.isc.org/article/AA-00879 This bug also affects all programs which use libdns. Regards, -- Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682218: charon: leftfirewall=yes broken
Package: strongswan-ikev2 Version: 4.6.4-5 Severity: serious In 4.6.4-5 charon runs as a non-privileged user instead of root. This breaks * leftfirewall=yes Breaking (silently) leftfirewall is a security problem. The problem is that iptables does not work as non-root even if it is called with the necessary capabilities. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625877: xserver-xorg-core 1.10.2: resizing konsole hangs xserver
On Friday 06 May 2011, Cyril Brulebois wrote: reassign 625877 nvidia-glx thanks Hi, Wolfgang Walter wolfgang.wal...@stwm.de (06/05/2011): Package: xserver-xorg-core Version: 2:1.10.1-2 Severity: grave After upgrading from xserver-xorg-core 2:1.9.5-1 to version 2:1.10.1-2 the xserver hangs when I resize konsole (kde sid). Downgrading to 2:1.9.5-1 fixes the problem. I found similar reports for other distros (Ubuntu, Fedora, ArchLinux), i.e. https://bbs.archlinux.org/viewtopic.php?id=116544p=3 Most people report that they are using binary drivers from nvidia (as I do) but some report the those problems for other drivers. reassigning there for now. Your “report” is very incomplete. Please use reportbug next time. And follow up with details: http://pkg-xorg.alioth.debian.org/howto/report-bugs.html Disabling composite fixes the problem for me, too. Regards, -- Wolfgang Walter Mraw, KiBi. Here are some missing infos: -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38.5-ei+6.3 (SMP w/6 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xorg depends on: ii konsole [x-terminal-emulator] 4:4.4.5-3 X terminal emulator ii libgl1-mesa-dri 7.10.2-2 free implementation of the OpenGL ii libgl1-mesa-glx [libgl1] 7.10.2-2 free implementation of the OpenGL ii libglu1-mesa 7.10.2-2 The OpenGL utility library (GLU) ii x11-apps 7.6+4 X applications ii x11-session-utils 7.6+1 X session utilities ii x11-utils 7.6+2 X11 utilities ii x11-xfs-utils 7.6+1 X font server utilities ii x11-xkb-utils 7.6+2 X11 XKB utilities ii x11-xserver-utils 7.6+2 X server utilities ii xauth 1:1.0.5-1 X authentication utility ii xfonts-100dpi 1:1.0.3100 dpi fonts for X ii xfonts-75dpi 1:1.0.375 dpi fonts for X ii xfonts-base 1:1.0.3standard fonts for X ii xfonts-scalable 1:1.0.3-1 scalable fonts for X ii xfonts-utils 1:7.6~1X Window System font utility progr ii xinit 1.3.0-1X server initialisation tool ii xkb-data 2.1-2 X Keyboard Extension (XKB) configu pn xorg-docs-corenone (no description available) ii xserver-xorg 1:7.6+6the X.Org X server ii xterm [x-terminal-emulator] 269-1 X terminal emulator xorg recommends no packages. Versions of packages xorg suggests: pn xorg-docs none (no description available) Versions of packages xserver-xorg depends on: ii libc62.13-2 Embedded GNU C Library: Shared lib ii nvidia-glx [xorg-driver-vide 270.41.06-1 NVIDIA binary Xorg driver ii x11-xkb-utils7.6+2 X11 XKB utilities ii xkb-data 2.1-2 X Keyboard Extension (XKB) configu ii xserver-xorg-core2:1.9.5-1 Xorg X server - core server ii xserver-xorg-input-evdev [xo 1:2.6.0-2 X.Org X server -- evdev input driv ii xserver-xorg-video-dummy [xo 1:0.3.4-2 X.Org X server -- dummy display dr Versions of packages xserver-xorg recommends: ii libgl1-mesa-dri 7.10.2-2 free implementation of the OpenGL The server does not freeze immediately. When resizing a konsole window it shortly shows strange content, then the whole screens gets redrawn and the kernel logs May 4 01:09:26 ei kernel: [61049.249134] NVRM: Xid (:01:00): 13, 0001 5097 15e0 0100 You may resize 2 or 3 times and then the xserver freezes and I can't switch to a VT. But the xserver does not crash. If one moves the mouse it will react after several seconds and then starts moving very slowly in the direction the mouse was moved. Disabling composite probably helps because as a side effect one disables any opengl effects of kwin. I can't say if it is a problem of the nvidia driver or of the xserver. Regards, -- Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625877: xserver-xorg-core 1.10.2: resizing konsole hangs xserver
Package: xserver-xorg-core Version: 2:1.10.1-2 Severity: grave After upgrading from xserver-xorg-core 2:1.9.5-1 to version 2:1.10.1-2 the xserver hangs when I resize konsole (kde sid). Downgrading to 2:1.9.5-1 fixes the problem. I found similar reports for other distros (Ubuntu, Fedora, ArchLinux), i.e. https://bbs.archlinux.org/viewtopic.php?id=116544p=3 Most people report that they are using binary drivers from nvidia (as I do) but some report the those problems for other drivers. Disabling composite fixes the problem for me, too. Regards, -- Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587583: closed by Rene Mayrhofer rm...@debian.org (Bug#587583: fixed in strongswan 4.4.1-1)
Hello! Am Dienstag, 17. August 2010 schrieb Debian Bug Tracking System: This is an automatic notification regarding your Bug report which was filed against the strongswan package: #587583: strongswan 4.4.0-2 does not work here: charon seems not to ignore all incoming requests/answers It has been closed by Rene Mayrhofer rm...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Rene Mayrhofer rm...@debian.org by replying to this email. This does not help here. The issue remains. What helps is to change /etc/strongswan.conf. Explicitly forcing charon tu use socket-raw (instead of socket-default) fixes the problem here. I therefor added the line: load = curl ldap aes des sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem openssl fips-prf xcbc hmac agent gmp attr kernel-netlink socket-raw farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 dhcp resolve This fixes the issue for 4.4.0-2, too. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587583: 4.4.0-2 does not work here: charon seems not to ignore all incoming
Maybe this is the solution: https://lists.strongswan.org/pipermail/users/2010-August/005192.html https://lists.strongswan.org/pipermail/users/2010-August/005197.html Probably socket-default should be disabled at compile-time as debian enables pluto. Regards -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587583: strongswan 4.4.0-2 does not work here: charon seems not to ignore all incoming requests/answers
Package: strongswan Version: 4.4.0-2 Severity: grave charon seems no ignore all incoming ikev2-request. I downgraded both machines to strongswan 4.3.2-1.3 and all worked again. I further left one with 4.3.2-1.3 and upgraded the other to 4.4.0-2. Whereas 4.3.2-1.3 logs and answer packets sent by 4.4.0-2, the latter neither logs request nor anwers from 4.3.2-1.0. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587282: plugins missing
Package: strongswan Version: 4.4.0-1 Severity: grave strongswan floods syslog with the following message charon: 08[NET] no socket implementation registered, receiving failed According to the strongswan mailing list: strongswan-4.4.0 requires a charon socket plugin, either socket-default if charon-only is running or socket-raw if both charon an pluto are running. These plugins are missing. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569462: xserver-xorg-input-elographics: FTBFS: ../../src/xf86Elo.c:800: error: too few arguments to function 'InitButtonClassDeviceStruct'
This is due to the new xserver version. Upstream already fixed this: http://cgit.freedesktop.org/xorg/driver/xf86-input-elographics/commit/?id=a18af14b1df5271fbe3100df3fcb3a8811981ddf Please upgrade the debian-package to the newest upstream version, which fixes other problems, too: http://cgit.freedesktop.org/xorg/driver/xf86-input-elographics/commit/?id=ac5366d6e1f26e6ceef3d062ab7df301d623cf54 Rergards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569931: oxygen-ait theme crashes in libjpeg62
Package: kdebase-workspace-kgreet-plugins Version: 4:4.3.4-4 Severity: grave Since I upgraded unstable (today, 15.2.2010) kdms greeter crashes when using the theme /usr/share/kde4/apps/kdm/themes/oxygen-air with a segmentation fault (in libjpeg62 when decompressing). Theme /usr/share/kde4/apps/kdm/themes/oxygen works. I think this has something todo with the upgrade of kdelibs5 and libplasma3 (or liblzma1 to liblzma2)? Here is the dpkg.log: 2010-02-15 01:01:32 startup archives unpack 2010-02-15 01:01:47 upgrade kdelibs-bin 4:4.3.4-1 4:4.3.4-1+b1 2010-02-15 01:01:47 status half-configured kdelibs-bin 4:4.3.4-1 2010-02-15 01:01:47 status unpacked kdelibs-bin 4:4.3.4-1 2010-02-15 01:01:47 status half-installed kdelibs-bin 4:4.3.4-1 2010-02-15 01:01:47 status half-installed kdelibs-bin 4:4.3.4-1 2010-02-15 01:01:47 status unpacked kdelibs-bin 4:4.3.4-1+b1 2010-02-15 01:01:47 status unpacked kdelibs-bin 4:4.3.4-1+b1 2010-02-15 01:01:47 upgrade libpng12-dev 1.2.42-1 1.2.42-2 2010-02-15 01:01:47 status half-configured libpng12-dev 1.2.42-1 2010-02-15 01:01:47 status unpacked libpng12-dev 1.2.42-1 2010-02-15 01:01:47 status half-installed libpng12-dev 1.2.42-1 2010-02-15 01:01:47 status triggers-pending man-db 2.5.6-5 2010-02-15 01:01:47 status half-installed libpng12-dev 1.2.42-1 2010-02-15 01:01:47 status half-installed libpng12-dev 1.2.42-1 2010-02-15 01:01:47 status unpacked libpng12-dev 1.2.42-2 2010-02-15 01:01:47 status unpacked libpng12-dev 1.2.42-2 2010-02-15 01:01:48 upgrade libpng12-0 1.2.42-1 1.2.42-2 2010-02-15 01:01:48 status half-configured libpng12-0 1.2.42-1 2010-02-15 01:01:48 status unpacked libpng12-0 1.2.42-1 2010-02-15 01:01:48 status half-installed libpng12-0 1.2.42-1 2010-02-15 01:01:48 status triggers-pending doc-base 0.9.5 2010-02-15 01:01:48 status half-installed libpng12-0 1.2.42-1 2010-02-15 01:01:48 status half-installed libpng12-0 1.2.42-1 2010-02-15 01:01:48 status unpacked libpng12-0 1.2.42-2 2010-02-15 01:01:48 status unpacked libpng12-0 1.2.42-2 2010-02-15 01:01:48 upgrade kdelibs5 4:4.3.4-1 4:4.3.4-1+b1 2010-02-15 01:01:48 status half-configured kdelibs5 4:4.3.4-1 2010-02-15 01:01:48 status unpacked kdelibs5 4:4.3.4-1 2010-02-15 01:01:48 status half-installed kdelibs5 4:4.3.4-1 2010-02-15 01:01:49 status half-installed kdelibs5 4:4.3.4-1 2010-02-15 01:01:49 status unpacked kdelibs5 4:4.3.4-1+b1 2010-02-15 01:01:49 status unpacked kdelibs5 4:4.3.4-1+b1 2010-02-15 01:01:49 trigproc man-db 2.5.6-5 2.5.6-5 2010-02-15 01:01:49 status half-configured man-db 2.5.6-5 2010-02-15 01:01:50 status installed man-db 2.5.6-5 2010-02-15 01:01:50 trigproc doc-base 0.9.5 0.9.5 2010-02-15 01:01:50
Bug#569931: closed by Andreas Barth a...@not.so.argh.org (Bug#569931: fixed in libjpeg6b 6b-16.1)
Hello, I installed these vesions of libjpeg62 and libjpeg8 and this does NOT fix the issue. It still crashes in jpeg_start_decompress () from /usr/lib/libjpeg.so.62 Not only kdm greeter crashes, konqueror and gwenview crash, too. It must have something to do with the upgrade from kdelibs-bin, kdelibs5 and libplasma3. If I downgraded them to 4:4.3.4-1 and reinstall liblzma1 the issue disappears. Regards, Wolfgang Walter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002151845.55756.wolfgang.wal...@stusta.mhn.de
Bug#537389: binutils 2.19.51.20090714-1 produces non-bootable kernel
Am Mittwoch, 22. Juli 2009 schrieb Matthias Klose: On 21.07.2009 07:23, Wolfgang Walter wrote: Package: binutils Version: 2.19.51.20090714-1 There were no error messages or anything from the kernel; just the spontaneous reboot or hang. No configuration kernel configuration changes either; the only difference in a working test case and a non-working test case was building with different versions of binutils. There's nothing special about the PC that had the problem booting the kernel. It's an old machine that has never had problems with Linux. I can confirm that. I had to downgrade binutils to build a working 2.6.30.2 (or 2.6.30.1). In LKML other people also tracked down non-booting 2.6.30.x to be caused by the actual binutils package in sid. I can't see this kind of report for current Fedora and Ubuntu, which are both based to a subset of the hjl's binutils patches (the Debian package is pure upstream without these patches applied). As a quick check, please could you recheck with the package found here: http://packages.ubuntu.com/karmic/amd64/binutils/download http://packages.ubuntu.com/karmic/i386/binutils/download I'll try tonight. Maybe this mail from Bastian Blank to 537...@bugs.debian.org has an hint: = On Mon, Jul 20, 2009 at 03:02:36PM -0700, Linus Torvalds wrote: On Mon, 20 Jul 2009, Kiko Piris wrote: Yes, as Marcel Beister pointed, it resulted some binutils bug. Downgrading the package produced a perfectly bootable 2.6.30.2. Ok, so it's been narrowed down to binutils. Good. Okay, I did some work and now got one working and one not working kernel. The setup code it, except the payload size and the version string, identical. Now to vmlinux. First difference (1-vmlinux is the broken, 2-vmlinux is the working version): | 2-vmlinux: file format elf32-i386 | 2-vmlinux | architecture: i386, flags 0x0113: | HAS_RELOC, EXEC_P, HAS_SYMS, D_PAGED vs. | 1-vmlinux: file format elf32-i386 | 1-vmlinux | architecture: i386, flags 0x0013: | HAS_RELOC, EXEC_P, HAS_SYMS The file lost its D_PAGED flag. Next: | 16 .init.rodata 0394 c05057e0 005057e0 004067e0 2**4 | CONTENTS, ALLOC, LOAD, RELOC, DATA | 17 .data.page_aligned 0800 c0506000 00506000 00407000 2**5 | CONTENTS, ALLOC, LOAD, DATA vs. | 16 .init.rodata 0394 c0506000 00506000 00407000 2**4 | CONTENTS, ALLOC, LOAD, RELOC, DATA | 17 .data_nosave 0c6c c0506394 00506394 00407394 2**0 | ALLOC | 18 .data.page_aligned 0800 c0507000 00506394 00407394 2**5 | CONTENTS, ALLOC, LOAD, DATA So suddenly there apears a .data_nosave with some content, but it is marked the same then a bss section and not even properly aligned according to the linker script. The same sections of another working kernel, built with the new binutils: | 18 .init.rodata 03bd c040f4c0 0040f4c0 003104c0 2**2 | CONTENTS, ALLOC, LOAD, RELOC, DATA | 19 .data_nosave 1000 c041 0041 00311000 2**2 | CONTENTS, ALLOC, LOAD, DATA | 20 .data.page_aligned 0800 c0411000 00411000 00312000 2**2 | CONTENTS, ALLOC, LOAD, DATA The .data_nosave section is a real one here. I would say, such holes won't survive the objcopy to create a binary and all code is at the wrong location. Bastian = Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537389: binutils 2.19.51.20090714-1 produces non-bootable kernel
On Wednesday 22 July 2009, Matthias Klose wrote: On 21.07.2009 07:23, Wolfgang Walter wrote: Package: binutils Version: 2.19.51.20090714-1 There were no error messages or anything from the kernel; just the spontaneous reboot or hang. No configuration kernel configuration changes either; the only difference in a working test case and a non-working test case was building with different versions of binutils. There's nothing special about the PC that had the problem booting the kernel. It's an old machine that has never had problems with Linux. I can confirm that. I had to downgrade binutils to build a working 2.6.30.2 (or 2.6.30.1). In LKML other people also tracked down non-booting 2.6.30.x to be caused by the actual binutils package in sid. I can't see this kind of report for current Fedora and Ubuntu, which are both based to a subset of the hjl's binutils patches (the Debian package is pure upstream without these patches applied). As a quick check, please could you recheck with the package found here: http://packages.ubuntu.com/karmic/amd64/binutils/download http://packages.ubuntu.com/karmic/i386/binutils/download No difference: neither 2.6.30.2 nor 2.6.30.1 work. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537389: binutils 2.19.51.20090714-1 produces non-bootable kernel
Package: binutils Version: 2.19.51.20090714-1 There were no error messages or anything from the kernel; just the spontaneous reboot or hang. No configuration kernel configuration changes either; the only difference in a working test case and a non-working test case was building with different versions of binutils. There's nothing special about the PC that had the problem booting the kernel. It's an old machine that has never had problems with Linux. I can confirm that. I had to downgrade binutils to build a working 2.6.30.2 (or 2.6.30.1). In LKML other people also tracked down non-booting 2.6.30.x to be caused by the actual binutils package in sid. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524845: libslang2 depends on libpng12-0
Package: libslang2 Version: 2.1.4-2 Severity: serious libslang2 depends on libpng12-0. Either libpng12-0 is really needed, in this case libpng12-0 probably needs to go into /lib. Or, as it seems, libpng12-0 is not needed, just suggested. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#475098: charon needs dbus but strongswan does not depend on dbus
Package: strongswan Version: 4.1.11-1 Severity: serious starting with version 4.1.11-1 charon depends on dbus (it fails to start without dbus being installed) but strongswan package does not depend on package dbus. Regards -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#475099: charon does not work any more
Package: strongswan Version: 4.1.11-1 Severity: grave after updating to version 4.1.11-1 charon does not start any more. It fails with error message: Apr 9 01:46:59 eumel charon: 01[CFG] unable to set DBUS name: Connection :1.15 is not allowed to own the service org.freedesktop.NetworkManager.strongswan due to security policies in the configuration file Apr 9 01:46:59 eumel charon: 01[DMN] killing daemon: unable to set DBUS name Regards -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
Bug#393573: Fixed upstream: 1.0-8776 for Linux x86 released
Nvidia just released a bug-fixed version: http://nvidia.custhelp.com/cgi-bin/nvidia.cfg/php/enduser/std_adp.php?p_faqid=1971 There is a detailed response Rapid7 Advisory R7-0025 http://nvidia.custhelp.com/cgi-bin/nvidia.cfg/php/enduser/std_adp.php?p_faqid=1971 -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München Tel: +49 89 38196-276 Fax: +49 89 38196-144 [EMAIL PROTECTED] http://www.studentenwerk.mhn.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373839: kdelibs4c2a: Unable to print to CUPS server
Hello,
this bug is not fixed.
I think it is bug STR #1717 (upstream):
http://www.cups.org/str.php?L1717
and was solved upstream 18.7.2006 (SVN: v5748)
The fix posted there was:
Index: http.c
===
--- http.c (revision 5743)
+++ http.c (working copy)
@@ -1809,6 +1809,16 @@
return (1);
/*
+ * Flush pending data, if any...
+ */
+
+ if (http-wused)
+ {
+if (httpFlushWrite(http) 0)
+ return (0);
+ }
+
+ /*
* If not, check the SSL/TLS buffers and do a select() on the connection...
*/
===
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Leiter EDV
Leopoldstraße 15
80802 München
http://www.studentenwerk.mhn.de/
