Bug#988007: monitoring-plugins-systemd: Please provide backports
Package: monitoring-plugins-systemd Severity: wishlist Hi, I just discovered check_systemd is in Debian, now, but apparently was uploaded just too late to make it into the upcoming bullseye release. Please, could a backport be made? Then it could be deployed (and upgraded) more easily than by copying .deb files around (though that seems to currently work well from 2.3.1-1 in unstable to a buster system), (or by having unstable in the sources.list of a supposed-to-be stable machine and having to trust manual apt pins/preferences against the bulk of unstable). Thanks, canvon
Bug#927108: [ftp.debian.org] Release file for jessie-updates is incomplete
Package: ftp.debian.org Followup-For: Bug #927108 It also contains a broken Version: field which leads to "unusual" ouput from "apt-cache policy", (which confuses my custom nagios/icinga2 check). * http://ftp.debian.org/debian/dists/jessie-updates/InRelease > Origin: Debian > Label: Debian > Suite: oldstable-updates > Version: label=Debian > Codename: jessie-updates > Date: Sat, 25 May 2019 14:30:54 UTC > Architectures: amd64 armel armhf i386 > Components: > Description: Updated packages for Debian 8 The > Version: label=Debian becomes: | release v=label=Debian,o=Debian,a=oldstable-updates,n=jessie-updates,l=Debian,c=main (The v=label=Debian is where my check breaks. But,) I guess the Version: field is simply broken. (?) Regards, Fabian
Bug#892503: tmux: display garbling with nested sessions
Package: tmux Version: 2.3-4 Followup-For: Bug #892503 (Note that I'm reporting the bug as found in the older tmux that is the outer tmux of a tmux-in-tmux situation, though the proposed work-around is to be applied to the newer tmux that is the inner tmux. This is to (hopefully) properly mark the problem as being with the older tmux, as it was reported before that the bug vanishes with tmux >= 2.6 as outer tmux.) Hi, the tmux-in-tmux screen garbling hit me, too. It was also with an outer tmux 2.3 (in my case: 2.3-4) from stable, and a newer inner tmux (in my case: 2.8-3) from testing (buster). On IRC, upstream suggested the work-around to do this in the inner tmux: set -as terminal-overrides ',*:indn@' Then, detach and attach again. This seems to have fixed it, for me. Apparently this cancels the capability "scroll forward #1 lines" for all terminal types. It's not needed in any further inner tmuxes. Regards, Fabian -- Fabian "canvon" Pietsch - https://www.canvon.de/
Bug#926325: raspi3-firmware: console tty0 is not the main console
Package: raspi3-firmware Version: 1.20190215-1 Severity: normal Dear Maintainer, due to the order of the console=... arguments on the kernel command line, given to the firmware in /boot/firmware/cmdline.txt, constructed by your hook script /etc/kernel/postinst.d/z50-raspi3-firmware, the serial console is the main system console. (The last argument wins.) This means that, e.g., systemd boot messages won't appear on the HDMI-connected display. This also means that systemd units with StandardOutput=journal+console won't be able to give live comment on what they are doing / waiting for at boot to the person sitting in front of the monitor. Due to the construction of the Raspberry Pi 3 board and presumed usual use I consider it easier and more likely to connect a monitor (or TV) via an HDMI cable, than to first wire something up to even have a serial port at all in the first place. If still the serial console should be the default main console, and the HDMI-connected display only an additional console, please make this configurable in, e.g., /etc/default/raspi3-firmware. (It could be nice to be able to set additional kernel cmdline arguments or even override the complete cmdline from there, btw.) For the time being, to avoid editing (and later merging on upgrade) a 143 lines script conffile /etc/kernel/postinst.d/z50-raspi3-firmware (see above), I place this little sed script which exchanges the position of two console=... arguments if the first (not the final) is tty0: /etc/kernel/postinst.d/z51-raspi3-fixup and symlinked from /etc/initramfs/post-update.d/z51-raspi3-fixup: #!/bin/bash # (Note: This will not suffice with more than two console=...) exec -- sed -e 's/\(console=tty0 \)\(console=[^ ]* \)/\2\1/' -i /boot/firmware/cmdline.txt This changes /boot/firmware/cmdline.txt from, e.g. (with raised CMA in /etc/default/raspi3-firmware), this: | console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 cma=128M rootwait ..to this: | console=ttyS1,115200 console=tty0 root=/dev/mmcblk0p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 cma=128M rootwait That is, tty0 boots as the main console, receiving, e.g., systemd boot output. The result can be checked by /proc/consoles: | tty0 -WU (EC p )4:7 | ttyS1-W- (E p a)4:65 Look for flag "C = it is preferred console", according to /usr/share/doc/linux-doc/Documentation/filesystems/proc.txt.gz Regards, Fabian -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-4-arm64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages raspi3-firmware depends on: ii dosfstools 4.1-2 raspi3-firmware recommends no packages. raspi3-firmware suggests no packages. -- Configuration Files: /etc/default/raspi3-firmware changed: CMA=128M -- no debconf information
Bug#925334: vc4: CMA fills up and screen not updated anymore on raspi3
Hi, * Fabian Pietsch (Wed, 03 Apr 2019 12:30:01 +0200): > As suggested, I tested more compact cmdline.txt, though: > > | root=/dev/mmcblk0p2 > > | console=tty0 root=/dev/mmcblk0p2 > > | console=tty0 root=/dev/mmcblk0p2 cma=128M > > With the first two, cma defaulted to 64M and already the lightdm login > screen stops updating after a few seconds to minutes. With the 3rd, > the bug initially didn't happen so I used X a bit, then logged out and > let the system fall idle; the bug then seems to have happened > 9868 seconds after boot (according to dmesg --follow). Another round (system mostly idle except for manually renaming enx[...] to eth0 after boot and restarting wicd, which came with lxde meta-package to manage the networking, to get a correct system time via NTP) -> 3960 seconds after boot (in dmesg). That seems to suggest to me that the cmdline.txt built by raspi3-firmware was not the issue, here. Still don't know whether it's possible or sensible to disable the "weird" initial cmdline passed by the firmware, though. In any case, the tile binning error ... | kernel: vc4_v3d 3fc0.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory. ... together with a preceding, e.g., ... | kernel: [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA: | kernel: [drm]V3D: 23468kb BOs (10) | kernel: [drm] V3D shader:144kb BOs (35) | kernel: [drm] dumb: 8148kb BOs (4) ... is usually surrounded (in journal) by nothing but many: | kernel: alloc_contig_range: [36400, 37500) PFNs busy What I'm trying to say is that there seems to be no log-noticeable concurrent activity going on. Watching the CMA use via /proc/meminfo suggests that it's much more than half free, most of the time. The tile binning error seems to be entirely random, at this point. Looking at the source[1], vc4_allocate_bin_bo() seems to use a strategy of successively allocating memory until it randomly finds a block that fits certain requirements. Maybe randomly sometimes there is no such block available, leading to it failing with -ENOMEM. It's not clear to me, though, when and why the function is called, seemingly randomly on an idle system. It reads to me as an initialization, not something that is randomly repeated. (?) [1] https://sources.debian.org/src/linux/4.19.28-2/drivers/gpu/drm/vc4/vc4_v3d.c/#L244 Again, it would be nice if the resulting device error state could somehow be reset / the function retried with more/different CMA free at a later point during the same boot. Perhaps that's already possible (maybe even in a general way?) but I don't know how. (Trying to unbind the driver (vc4_v3d) via sysfs led to a kernel oops (IIRC paging fault?), and an attempt to bind it again was rejected without any noticeable action.) Regards, Fabian -- Fabian "canvon" Pietsch - https://www.canvon.de/
Bug#925334: vc4: CMA fills up and screen not updated anymore on raspi3
Hi, * Romain Perier (Wed, 27 Mar 2019 21:33:19 +0100): > Return-Path: > Message-ID: <20190327203319.ga15...@debby.home> > From: Romain Perier > Subject: Re: Bug#925334: vc4: CMA fills up and screen not updated anymore > on raspi3 > To: Fabian Pietsch , 925...@bugs.debian.org > User-Agent: Mutt/1.10.1 (2018-07-13) > > On Wed, Mar 27, 2019 at 03:29:21PM +0100, Fabian Pietsch wrote: [...] > > the bug is still present in the current version. It took a freshly > > booted, idle system 3304 seconds for the bug to occur, though, > > so this time rather an hour (than 10-30min as stated before). [...] > > So vc4_v3d which reported the error seems to be in status=error > > and counts as suspended. Manual attempts to get it to resume again, > > now that more cma is free again, failed, but there are probably ways > > I don't know about. [...] > Could you test, two stuffs for me ? : > > 1. The VC4 driver seems to use runtime pm operations, could you try to > disable runtime suspend completly (there are kernel parameters for this > if I remember correctly) ? Didn't find anything useful to that regard in linux-doc Documentation/ and by googling. Could you please tell me how? > 2. Your kernel cmdline are... weird, could you try with minimalistic > kernel cmdline ? Only keep console= for logging to uart and/or to your > tty0 and keep your rootfs. The initial part until the two spaces seems to be auto-generated by the firmware at boot, so I guess I can't change or suppress it; if it should be possible, again, please tell me how. My kernel cmdline as passed *to* the firmware is: | fabian@rpi3:~$ cat /boot/firmware/cmdline.txt | console=tty0 console=ttyS1,115200 root=/dev/mmcblk0p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 cma=128M rootwait This is just auto-generated by the raspi3-firmware package to which you (Romain Perier) seem to be contributing. As suggested, I tested more compact cmdline.txt, though: | root=/dev/mmcblk0p2 | console=tty0 root=/dev/mmcblk0p2 | console=tty0 root=/dev/mmcblk0p2 cma=128M With the first two, cma defaulted to 64M and already the lightdm login screen stops updating after a few seconds to minutes. With the 3rd, the bug initially didn't happen so I used X a bit, then logged out and let the system fall idle; the bug then seems to have happened 9868 seconds after boot (according to dmesg --follow). Regards, Fabian -- Fabian "canvon" Pietsch - https://www.canvon.de/
Bug#925334: vc4: CMA fills up and screen not updated anymore on raspi3
Package: src:linux Version: 4.19.28-2 Followup-For: Bug #925334 Dear Maintainer, the bug is still present in the current version. It took a freshly booted, idle system 3304 seconds for the bug to occur, though, so this time rather an hour (than 10-30min as stated before). After the bug has happened, I get the following information from sysfs: | root@rpi3:/sys/bus/platform/drivers/vc4_v3d# for I in enabled status active_time suspended_time; do echo -n "$I=$(cat 3fc0.v3d/power/runtime_$I) "; done; echo | enabled=enabled status=error active_time=16800 suspended_time=55464216 And again: | enabled=enabled status=error active_time=16800 suspended_time=55479160 So vc4_v3d which reported the error seems to be in status=error and counts as suspended. Manual attempts to get it to resume again, now that more cma is free again, failed, but there are probably ways I don't know about. "echo on > .../power/control" changed runtime_enabled=forbidden (and echo auto > control changed it back to runtime_enabled=enabled), but runtime_status remained at "error". Regards, Fabian -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-4-arm64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#925334: vc4: CMA fills up and screen not updated anymore on raspi3
Package: src:linux Version: 4.19.16-1 Severity: important Tags: upstream Dear Maintainer, (please also see the additional information in the footnotes below.) When using the vc4 video driver with Xorg on the Raspberry Pi 3 [raspi3], it seems to sooner or later fill up the CMA, leading to, e.g., this: [ 739.307920] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA: [ 739.314932] [drm]V3D: 23468kb BOs (10) [ 739.321333] [drm] V3D shader:144kb BOs (35) [ 739.327734] [drm] dumb: 8148kb BOs (4) When additionally the following happens, the screen stops updating until reboot [stops_updating]: [ 739.334049] vc4_v3d 3fc0.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory. This happens with cma=64M, cma=128M and cma=256M, though 128M seems to be the recommended size for vc4 use, according to comments in package raspi3-firmware's /etc/default/raspi3-firmware. ii raspi3-firmware 1.20190215-1 arm64Raspberry Pi 2 and 3 GPU firmware and bootloaders With cma=128M, the error happens on a freshly booted, idle system running lightdm, after perhaps 10m-30m, or can be provoked by running a [screensaver]. A work-around is to force Xorg to use driver fbdev, which seems to work even after the tile binning error which otherwise would have required a reboot. I also get a lot of, e.g.: [ 739.135918] alloc_contig_range: [37400, 38400) PFNs busy I don't know if this is related or a different problem. Please somehow make it possible (or even automatic) for the screen update to continue without the need for a reboot. Fixes to CMA handling so that the tile binning error doesn't even happen anymore would be even better! Regards, Fabian (Please also see the footnotes below.) [raspi3] This machine was set up based on a Raspberry Pi 3 Debian buster preview image, from https://wiki.debian.org/RaspberryPi3 ; it says unofficial/unsupported, there, I hope this bug report still is ok as, as far as I understand, the unmodified Debian buster arm64 kernel seems to be used[1]. [1] Pulled in via apt from official mirror in sources.list: https://github.com/Debian/raspi3-image-spec/blob/master/raspi3.yaml#L72 [stops_updating] "Stops updating the screen" here means that the Xorg tty graphical contents don't change anymore, except for the mouse cursor. The mouse cursor can still be moved around, and even changes form on, e.g., window borders, and I can resize the terminal window up one line, and the cursor change on mouseover reflects the change; just nothing changes to the non-mousecursor visual picture. Also, tasking into console works fine, and tasking back into the Xorg tty restores the previous visual picture, and tasking back into the console again is also still possible. So no real "freeze" or hard crash, here, except that, after the tile binning error in dmesg, the Xorg tty graphical contents don't change (except for mouse cursor). [screensaver] The error can be provoked by running the following for some time: /usr/lib/xscreensaver/tessellimage -root -fill-screen This leads to a slightly different pattern of dmesg messages, though. The thing in common is that the screen stops updating, there, too, when the tile binning error quoted above happens. When provoked in this way, "grep ^CmaFree: /proc/meminfo" in a loop said 25564 kB directly before a tile binning error message, 7160 kB directly after, with values between 8000-1 kB after, with recovery to 81740 kB after exiting tessellimage. But the screen update stays stopped. Additional dmesg output: [0.00] Booting Linux on physical CPU 0x00 [0x410fd034] [0.00] Linux version 4.19.0-2-arm64 (debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-14)) #1 SMP Debian 4.19.16-1 (2019-01-17) [0.00] Machine model: Raspberry Pi 3 Model B Rev 1.2 [...] [0.00] cma: Reserved 128 MiB at 0x3340 [...] [0.00] Memory: 780176K/970752K available (8700K kernel code, 1600K rwdata, 2788K rodata, 4864K init, 530K bss, 59504K reserved, 131072K cma-reserved) [...] [0.000193] Console: colour dummy device 80x25 [0.000682] console [tty0] enabled [...] [0.141070] simple-framebuffer 3e887000.framebuffer: framebuffer at 0x3e887000, 0x373800 bytes, mapped to 0x(ptrval) [0.141106] simple-framebuffer 3e887000.framebuffer: format=r5g6b5, mode=1824x984x16, linelength=3648 [0.162242] Console: switching to colour frame buffer device 228x61 [0.182688] simple-framebuffer 3e887000.framebuffer: fb0: simplefb registered! [...] [4.768075] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-02-12 19:42 [...] [ 11.863850] vc4_hdmi 3f902000.hdmi: ASoC: Failed to create component debugfs directory [ 11.921037] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok [ 11.945385] vc4_hdmi
Bug#923962: tigervnc-standalone-server: crashes on ARM after VncAuth
Package: tigervnc-standalone-server Version: 1.9.0+dfsg-3 Severity: important Dear Maintainer, on our Raspberry Pi 3B+ test system, with an arm64 buster preview from https://wiki.debian.org/RaspberryPi3 , Xtigervnc crashes reproducibly after VncAuth, with the following ~/.vnc/rpi3:1.log output excerpt: | [...] | | Xvnc TigerVNC 1.9.0 - built Dec 1 2018 21:51:29 | Copyright (C) 1999-2018 TigerVNC Team and many others (see README.rst) | See http://www.tigervnc.org for information on TigerVNC. | Underlying X server release 12003000, The X.Org Foundation | | | Thu Mar 7 17:19:57 2019 | vncext: VNC extension running! | vncext: Listening for VNC connections on local interface(s), port 5901 | vncext: created VNC server for screen 0 | | Thu Mar 7 17:20:25 2019 | Connections: accepted: [::1]::49280 | SConnection: Client needs protocol version 3.8 | SConnection: Client requests security type VncAuth(2) | terminate called after throwing an instance of 'rdr::Exception' | terminate called recursively | (EE) | (EE) Backtrace: | (EE) 0: /usr/bin/Xtigervnc (OsLookupColor+0x1a8) [0xb38169d0] | (EE) unw_get_proc_info failed: no unwind info found [-10] | (EE) | (EE) | Fatal server error: | (EE) Caught signal 6 (Aborted). Server aborting | (EE) | XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":1" | after 175 requests (175 known processed) with 0 events remaining. | Killing Xtigervnc process ID 1204... which was already dead | Cleaning stale pidfile '/home/vncuser/.vnc/rpi3:1.pid'! (The test Xtigervnc is accessed via an SSH port forwarding, tested with both RealVNC and TightVNC, running on Windows.) Xtigervnc works fine (on the same RPi 3B+) in Raspbian stretch, but crashes in the same way after upgrading the package to Raspbian buster. Xtigervnc also works fine in a Debian buster container on a different system/architecture (amd64). Xtigervnc also works fine with SecurityTypes set to None, skipping the authentication step entirely. Note that Xtigervnc also crashes on our test system (in a different way) with SecurityTypes set to Plain or TLSPlain. This bug report is made against the general use case, though. Please advise on the next steps to track down what is happening. More logs could be provided, the system is not set up for development, yet, though. Here is the /etc/vnc.conf and ~/.vnc/vnc.conf essence: | $ grep -v -E '^(#|$)' /etc/vnc.conf | $fontPath = undef; | $vncStartup = "/etc/X11/Xvnc-session"; | $geometry = "1900x1200"; | 1; | $ | $ grep -v -E '^(#|$)' ~/.vnc/vnc.conf | $SecurityTypes = "VncAuth"; | 1; | $ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-2-arm64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tigervnc-standalone-server depends on: ii libaudit1 1:2.8.4-2 ii libbsd0 0.9.1-1 ii libc6 2.28-7 ii libfile-readbackwards-perl 1.05-2 ii libgcc1 1:8.2.0-21 ii libgcrypt20 1.8.4-5 ii libgl1 1.1.0-1 ii libgnutls30 3.6.6-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libpam0g1.3.1-5 ii libpixman-1-0 0.36.0-1 ii libselinux1 2.8-1+b1 ii libstdc++6 8.2.0-21 ii libsystemd0 240-6 ii libunwind8 1.2.1-8 ii libx11-62:1.6.7-1 ii libxau6 1:1.0.8-1+b2 ii libxdmcp6 1:1.1.2-3 ii libxfont2 1:2.0.3-1 ii libxshmfence1 1.3-1 ii perl5.28.1-4 ii x11-xkb-utils 7.7+4 ii xauth 1:1.0.10-1 ii xkb-data2.26-2 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages tigervnc-standalone-server recommends: ii libgl1-mesa-dri18.3.2-1 ii tigervnc-common1.9.0+dfsg-3 ii x11-xserver-utils 7.7+8 ii xfonts-base1:1.0.4+nmu1 Versions of packages tigervnc-standalone-server suggests: pn xfonts-100dpi | xfonts-75dpi ii xfonts-scalable 1:1.0.3-1.1 -- no debconf information
Bug#835577: python3.5: Syslogs /usr/sbin/foo as /foo instead of as foo
Package: python3.5
Version: 3.5.2-2
Severity: minor
Hi,
when using syslog.syslog() without an explicit call to syslog.openlog()
before, syslog.openlog() gets called automatically with no arguments
and then defaults the logging identifier based on sys.argv[0].
(See [1] for documentation, [2] for the code that does this.)
Specifically: "The optional ident keyword argument is a string which is
prepended to every message, and defaults to sys.argv[0] with leading
path components stripped." [1]
The path component stripping leaves the final slash in, though.
So, e.g., /usr/sbin/foo logs as "/foo" instead of as "foo". When reading
syslog unprepared, it gives the impression that the python script would
be buggy (though it isn't), or a chroot would be involved (which will
often not be the case, too). So I consider this a (minor) bug.
To reproduce, chmod +x and run this script with absolute path:
==>8=
#!/usr/bin/python3 -Es
import syslog
syslog.syslog("Test from python!")
==>8=
(The -Es is there because this is what firewalld uses, which I'm trying
to debug.)
On my machine (Debian stretch/testing), this gives the following syslog
result:
| Aug 27 08:53:27 blackbox /test-syslog.py: Test from python!
The slash is misleading/wrong.
A real-world example is firewalld. Run the following, to provoke an
error that gets syslogged:
# firewall-cmd --permanent --delete-zone=test
Error: INVALID_ZONE: test
Syslog:
| Aug 27 10:21:47 blackbox /firewalld: ERROR: INVALID_ZONE: test
Again, the slash is misleading/wrong.
I was referred on freenode/#python to [2] for how this happens. So this
does not appear to be Debian-specific. It would be nice if this could be
fixed in Debian at least; apart from that, please forward to upstream.
Regards,
Fabian
[1] /usr/share/doc/python3.5/html/library/syslog.html
[2] https://github.com/python/cpython/blob/master/Modules/syslogmodule.c#L98
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python3.5 depends on:
ii libpython3.5-stdlib 3.5.2-2
ii mime-support 3.60
ii python3.5-minimal3.5.2-2
python3.5 recommends no packages.
Versions of packages python3.5 suggests:
ii binutils2.26.1-1
ii python3.5-doc 3.5.2-3
pn python3.5-venv
-- no debconf information
Bug#834453: systemd-resolved: Please add d.f.ip6.arpa to the DNSSEC default negative trust anchors
Package: systemd Version: 230-7 Severity: wishlist Hi, dnssec-trust-anchors.d(5) says: "Negative trust anchors are useful to support private DNS subtrees that are not referenced from the Internet DNS hierarchy, and not signed." "If no negative trust anchor files are configured a built-in set of well-known private DNS zone domains is used as negative trust anchors." The DNSSEC default negative trust anchors for systemd-resolved seem to be defined in [1]. There are reverse DNS domains for the RFC 1918 address space (10.0.0.0/8, 192.168.0.0/16 etc.) listed, but not for IPv6 Unique Local addresses [2], the equivalent for IPv6. That means that, when systemd-resolved's DNSSEC support is enabled, site-locally defined reverse DNS for IPv4 private addresses will resolve with systemd-resolved out-of-the-box, while site-locally defined reverse DNS for IPv6 Unique Local addresses will not. It has to be configured as a DNSSEC negative trust anchor, first, which also makes it necessary to configure the systemd-resolved default negative anchors explicitly, too. (This happens as *.negative files in /etc/dnssec-trust-anchors.d/ ) The current defaults give RFC 6761 as reason for inclusion, but that does not seem to talk about DNSSEC. And the reason given in [1] simply is: "RFC 6761 says that these reverse IP lookup ranges are for private addresses, and hence should not show up in the root zone" The same can be claimed for d.f.ip6.arpa via RFC 4193 [2]: "Reverse (address-to-name) queries for locally assigned IPv6 Local addresses MUST NOT be sent to name servers for the global DNS, [...]." "The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations to act as if they were authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for any such query. [...] if the site administrator has not set up the reverse tree corresponding to the locally assigned IPv6 Local addresses in use, returning RCODE 3 is in fact the correct answer." So if the site administrator has set up the reverse tree for the IPv6 Unique Local addresses in use, there would be no trust path from the root zone, so to use the set up data, a negative trust anchor is necessary. It should qualify as a "private DNS subtree[] that [is] not referenced from the Internet DNS hierarchy, and not signed", as quoted in the beginning of this report. IPv6 Unique Local addresses reverse DNS should also qualify as a "well-known private DNS zone domain[]". So please include d.f.ip6.arpa in the list of default negative trust anchors. Regards, Fabian [1] https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/src/resolve/resolved-dns-trust-anchor.c#n101 [2] RFC 4193 "Unique Local IPv6 Unicast Addresses", e.g., https://tools.ietf.org/html/rfc4193 -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libapparmor12.10.95-4 ii libaudit1 1:2.6.5-1 ii libblkid1 2.28-6 ii libc6 2.23-4 ii libcap2 1:2.25-1 ii libcap2-bin 1:2.25-1 ii libcryptsetup4 2:1.7.0-2 ii libgcrypt20 1.7.2-2 ii libgpg-error0 1.24-1 ii libidn111.33-1 ii libkmod222-1.1 ii liblzma55.1.1alpha+20120614-2.1 ii libmount1 2.28-6 ii libpam0g1.1.8-3.3 ii libseccomp2 2.3.1-2 ii libselinux1 2.5-3 ii libsystemd0 230-7 ii mount 2.28-6 ii util-linux 2.28-6 Versions of packages systemd recommends: ii dbus1.10.8-1 ii libpam-systemd 230-7 Versions of packages systemd suggests: ii policykit-10.105-16 ii systemd-container 230-7 pn systemd-ui Versions of packages systemd is related to: ii udev 230-7 -- Configuration Files: /etc/systemd/system.conf changed [not included] -- no debconf information
Bug#790914: libgdiplus: crashes randomly when loading a transparent-only PNG
Package: libgdiplus
Version: 3.6-1+b2
Severity: normal
Tags: upstream patch
Hi,
there is gdip_load_png_image_from_file_or_stream() in src/pngcodec.c
which calls png_get_PLTE() without initializing the result parameters
before or checking for the 0 (error) return code after. This leads to
png_palette and num_palette being uninitialized when loading certain
images. png_palette is dereferenced, then, in line 378 and following:
set_pixel_bgra(palette-Entries[i],
0,
png_palette[i].blue,
png_palette[i].green,
png_palette[i].red,
#if PNG_LIBPNG_VER 10399
trans_alpha [i]); /*
alpha */
#else
info_ptr-trans[i]);
/* alpha */
#endif
Depending on unknown factors, png_palette is sometimes some valid
pointer then, and png_palette[i].blue, .green, .red read from a random
memory location; or in other cases png_palette is 0, 0x2, 0x2c or other
values that are not accessible when interpreted as an address. This
then leads to the Mono application crashing in native code.
I've included a patch that initializes png_palette and num_palette to
zero. If png_get_PLTE() failed, and therefore those variables stay zero,
this should trigger a check in line 337/338 that sets palette_entries to
zero, which will cause the for loop that contains the set_pixel_bgra()
call to be skipped completely.
Note that this only fixes the crashes. It could be the case that a fully
transparent image (consisting of fully transparent pixels only) would be
loaded as, e.g., a completely black image, with this code change. Other
places where libgdiplus crashes on this type of image might exist, too.
To test the crash - although this might not crash even if it is still
buggy - run this:
$ csharp /r:System.Drawing
Mono C# Shell, type help; for help
Enter statements below.
csharp using System.Drawing;
csharp Bitmap bmpTest = new Bitmap(explosion00.png);
After this it might crash if you're (un)lucky.
Regards, Fabian Pietsch
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages libgdiplus depends on:
ii libc62.19-18
ii libcairo21.14.0-2.1
ii libexif120.6.21-2
ii libfontconfig1 2.11.0-6.3
ii libfreetype6 2.5.2-3
ii libgif4 4.1.6-11
ii libglib2.0-0 2.42.1-1
ii libjpeg62-turbo 1:1.3.1-12
ii libpng12-0 1.2.50-2+b2
ii libtiff5 4.0.3-12.3
ii libx11-6 2:1.6.2-3
ii libxrender1 1:0.9.8-1+b1
libgdiplus recommends no packages.
libgdiplus suggests no packages.
-- no debconf information
--- src/pngcodec.c.orig 2015-07-02 19:31:59.0 +0200
+++ src/pngcodec.c 2015-07-03 00:14:25.0 +0200
@@ -248,10 +248,10 @@
GpStatus status = InvalidParameter;
int bit_depth;
int channels;
BYTE color_type;
- int num_palette;
- png_colorp png_palette;
+ int num_palette = 0;
+ png_colorp png_palette = NULL;
png_ptr = png_create_read_struct (PNG_LIBPNG_VER_STRING, NULL, NULL, NULL);
if (!png_ptr) {
Bug#771696: dibbler-client: resolvconf fix, try 2
Hello,
I've updated the patch to fix resolvconf support.
It fixes a logic error in the patched dns_add(), and chmod()s the right
file(s) in the new domain_add_file(), so /etc/resolv.conf won't
become o-r / others un-readable again.
Also, each new FOO_file() function is above the old FOO() function,
to avoid the FOO_file() function being implicitly declared.
It still does not call resolvconf -d IFACE.inet6 anywhere, and I haven't
patched the other two ports with resolvconf support code yet. But this
seems to run on my machine better than 1.0.0.
Regards, Fabian
diff --git a/Misc/Portable.h b/Misc/Portable.h
index 8c43b80..9b89a0d 100644
--- a/Misc/Portable.h
+++ b/Misc/Portable.h
@@ -151,6 +151,7 @@ struct link_state_notify_t
#define SRVCONF_FILE /etc/dibbler/server.conf
#define RELCONF_FILE /etc/dibbler/relay.conf
#define RESOLVCONF_FILE/etc/resolv.conf
+#define PRIV_RESOLVCONF_FILE /var/lib/dibbler/resolv.conf
#define NTPCONF_FILE /etc/ntp.conf
#define RADVD_FILE /etc/dibbler/radvd.conf
#define CLNTPID_FILE /var/lib/dibbler/client.pid
diff --git a/Misc/Portable.h.in b/Misc/Portable.h.in
index d8bc4a9..a2fe9e6 100644
--- a/Misc/Portable.h.in
+++ b/Misc/Portable.h.in
@@ -151,6 +151,7 @@ struct link_state_notify_t
#define SRVCONF_FILE /etc/dibbler/server.conf
#define RELCONF_FILE /etc/dibbler/relay.conf
#define RESOLVCONF_FILE/etc/resolv.conf
+#define PRIV_RESOLVCONF_FILE /var/lib/dibbler/resolv.conf
#define NTPCONF_FILE /etc/ntp.conf
#define RADVD_FILE /etc/dibbler/radvd.conf
#define CLNTPID_FILE /var/lib/dibbler/client.pid
diff --git a/Port-linux/lowlevel-options-linux.c
b/Port-linux/lowlevel-options-linux.c
index 4000290..eb0c50b 100644
--- a/Port-linux/lowlevel-options-linux.c
+++ b/Port-linux/lowlevel-options-linux.c
@@ -9,6 +9,7 @@
#define _BSD_SOURCE
#define _POSIX_SOURCE
+#define _GNU_SOURCE
#include stdio.h
#include unistd.h
@@ -42,19 +43,24 @@ extern char * Message;
* the pipe needs to be closed by the caller
*
* @param arg1 first command line argument passed to resolvconf
- * @param arg2 second command line argument passed to resolvconf
+ * @param ifname interface name for which to run resolvconf
*
* @return file handler (pipe to resolvconf process) or NULL
*/
-FILE *resolvconf_open(const char *arg1, const char *arg2)
+FILE *resolvconf_open(const char *arg1, const char *ifname)
{
pid_t child;
int pipefd[2];
+char * ifname_;
if (access(RESOLVCONF, X_OK) != 0)
return NULL;
-if (pipe(pipefd) != 0)
+if (!asprintf(ifname_, %s.inet6, ifname))
return NULL;
+if (pipe(pipefd) != 0) {
+free(ifname_);
+return NULL;
+}
switch(child = fork()) {
case 0: /* child */
close(pipefd[1]);
@@ -63,19 +69,35 @@ FILE *resolvconf_open(const char *arg1, const char *arg2)
close(pipefd[0]);
/* double fork so init reaps the child */
if (!fork()) { /* child */
- execl(RESOLVCONF, RESOLVCONF, arg1, arg2, (char *)NULL);
+ execl(RESOLVCONF, RESOLVCONF, arg1, ifname_, (char *)NULL);
} /* All other cases are meaningless here */
exit(EXIT_FAILURE);
break;
case EXIT_FAILURE: /* error */
+ free(ifname_);
return NULL;
break;
}
/* parent */
+free(ifname_);
close(pipefd[0]);
waitpid(child, NULL, 0);
return fdopen(pipefd[1], w);
}
+
+int resolvconf_feed(FILE * pipe, const char * file) {
+FILE * f2 = NULL;
+unsigned int c;
+
+if (!(f2=fopen(file, r)))
+return LOWLEVEL_ERROR_FILE;
+
+while ((c = fgetc(f2)) != EOF) {
+fputc(c, pipe);
+}
+fclose(f2);
+return LOWLEVEL_NO_ERROR;
+}
#endif
/* in iproute.c, borrowed from iproute2 */
@@ -230,18 +252,12 @@ int cfg_file_del(const char *file, const char *keyword,
const char *value) {
-1 - unable to open temp. file
-2 - unable to open resolv.conf file
*/
-int dns_add(const char * ifname, int ifaceid, const char * addrPlain) {
+int dns_add_file(const char * ifname, int ifaceid, const char * addrPlain,
const char * file) {
FILE * f = NULL;
unsigned char c;
-#ifdef MOD_RESOLVCONF
-/* try to use resolvconf */
-f=resolvconf_open(-a, ifname);
-#endif
-
-/* if resolvconf is not available, fallback to normal file append */
-if (!f !(f=fopen(RESOLVCONF_FILE, a+)) ) {
-return LOWLEVEL_ERROR_FILE;
+if (!(f=fopen(file, a+)) ) {
+return LOWLEVEL_ERROR_FILE;
}
fseek(f, -1, SEEK_END);
@@ -257,46 +273,95 @@ int dns_add(const char * ifname, int ifaceid, const char
* addrPlain) {
return LOWLEVEL_NO_ERROR;
}
+
+/*
+ * results 0 - ok
+ -1 - unable to open temp. file
+ -2 - unable to open resolv.conf file
+ */
+int dns_add(const char * ifname, int ifaceid, const char * addrPlain) {
+FILE * f = NULL;
+
Bug#771696: dibbler-client: fails to register DNS server and search list properly with resolvconf
Hello,
I've created a patch against dibbler git which should allow
proper resolvconf operation. A private resolv.conf.IFACE file
is kept in /var/lib/dibbler, modified again and again, and
then fed in whole to resolvconf -a IFACE.inet6.
Before patch:
| root@silencer:~# cat /etc/resolvconf/run/interface/lan
| search nebel.canvon.de
After patch:
| root@silencer:~# cat /etc/resolvconf/run/interface/lan
| cat: /etc/resolvconf/run/interface/lan: No such file or directory
| root@silencer:~# cat /etc/resolvconf/run/interface/lan.inet6
|
| nameserver fd94:97cc:7e28:1::15
| search nebel.canvon.de canvon.de
Missing is resolvconf -d. This would have to happen at a point where
definitely no resolver information for that interface is valid anymore;
e.g., when the interface goes down, or at dibbler-client exit.
Also it does not yet clear the private resolv.conf file(s) at start.
But I now have an IPv6 nameserver in my /etc/resolv.conf again.
Regards,
Fabian Pietsch
* Fabian Pietsch (Thu, 04 Dec 2014 02:52:29 +0100):
Message-ID: 20141204015229.gb7...@silencer.int.canvon.de
From: Fabian Pietsch deb...@canvon.de
Subject: Re: Bug#771696: dibbler-client: fails to register DNS server and
search list properly with resolvconf
To: 771...@bugs.debian.org
User-Agent: Mutt/1.5.20 (2009-06-14)
Hello,
The solution would be to gather the resolver data in dns_add() and
domain_add(), and then call resolvconf -a iface once, with all
information.
I just had a look at dibbler git (which seems to be at the moment almost
dibbler 1.0.0), and the gathering stuff is already there: The
/etc/resolv.conf editing code. Dibbler would just need to keep a
separate resolv.conf (initially empty), perhaps in
/var/lib/dibbler/resolv.conf, and then after each change feed that
to resolvconf -a $IFACE.inet6.
Regards,
Fabian
--
Fabian zzz Pietsch - http://www.canvon.de/
diff --git a/Misc/Portable.h.in b/Misc/Portable.h.in
index d8bc4a9..a2fe9e6 100644
--- a/Misc/Portable.h.in
+++ b/Misc/Portable.h.in
@@ -151,6 +151,7 @@ struct link_state_notify_t
#define SRVCONF_FILE /etc/dibbler/server.conf
#define RELCONF_FILE /etc/dibbler/relay.conf
#define RESOLVCONF_FILE/etc/resolv.conf
+#define PRIV_RESOLVCONF_FILE /var/lib/dibbler/resolv.conf
#define NTPCONF_FILE /etc/ntp.conf
#define RADVD_FILE /etc/dibbler/radvd.conf
#define CLNTPID_FILE /var/lib/dibbler/client.pid
diff --git a/Port-linux/lowlevel-options-linux.c b/Port-linux/lowlevel-options-linux.c
index 4000290..d6045a4 100644
--- a/Port-linux/lowlevel-options-linux.c
+++ b/Port-linux/lowlevel-options-linux.c
@@ -9,6 +9,7 @@
#define _BSD_SOURCE
#define _POSIX_SOURCE
+#define _GNU_SOURCE
#include stdio.h
#include unistd.h
@@ -42,19 +43,24 @@ extern char * Message;
* the pipe needs to be closed by the caller
*
* @param arg1 first command line argument passed to resolvconf
- * @param arg2 second command line argument passed to resolvconf
+ * @param ifname interface name for which to run resolvconf
*
* @return file handler (pipe to resolvconf process) or NULL
*/
-FILE *resolvconf_open(const char *arg1, const char *arg2)
+FILE *resolvconf_open(const char *arg1, const char *ifname)
{
pid_t child;
int pipefd[2];
+char * ifname_;
if (access(RESOLVCONF, X_OK) != 0)
return NULL;
-if (pipe(pipefd) != 0)
+if (!asprintf(ifname_, %s.inet6, ifname))
return NULL;
+if (pipe(pipefd) != 0) {
+free(ifname_);
+return NULL;
+}
switch(child = fork()) {
case 0: /* child */
close(pipefd[1]);
@@ -63,19 +69,35 @@ FILE *resolvconf_open(const char *arg1, const char *arg2)
close(pipefd[0]);
/* double fork so init reaps the child */
if (!fork()) { /* child */
- execl(RESOLVCONF, RESOLVCONF, arg1, arg2, (char *)NULL);
+ execl(RESOLVCONF, RESOLVCONF, arg1, ifname_, (char *)NULL);
} /* All other cases are meaningless here */
exit(EXIT_FAILURE);
break;
case EXIT_FAILURE: /* error */
+ free(ifname_);
return NULL;
break;
}
/* parent */
+free(ifname_);
close(pipefd[0]);
waitpid(child, NULL, 0);
return fdopen(pipefd[1], w);
}
+
+int resolvconf_feed(FILE * pipe, const char * file) {
+FILE * f2 = NULL;
+unsigned int c;
+
+if (!(f2=fopen(file, r)))
+return LOWLEVEL_ERROR_FILE;
+
+while ((c = fgetc(f2)) != EOF) {
+fputc(c, pipe);
+}
+fclose(f2);
+return LOWLEVEL_NO_ERROR;
+}
#endif
/* in iproute.c, borrowed from iproute2 */
@@ -232,16 +254,50 @@ int cfg_file_del(const char *file, const char *keyword, const char *value) {
*/
int dns_add(const char * ifname, int ifaceid, const char * addrPlain) {
FILE * f = NULL;
-unsigned char c;
+char * file;
+int ret;
#ifdef MOD_RESOLVCONF
/* try to use resolvconf */
f=resolvconf_open(-a, ifname);
+if (f) {
+if (!asprintf(file
Bug#771696: dibbler-client: fails to register DNS server and search list properly with resolvconf
Hello, the cause seems to be that resolvconf -a $IFACE is called multiple times, once for each bit of resolver information, so only the last added information survives. The solution would be to gather the resolver data in dns_add() and domain_add(), and then call resolvconf -a iface once, with all information. BTW, it seems that other information providers set $IFACE.inet, so the correct invocation would seem to be resolvconf -a $IFACE.inet6. This way IPv6 nameservers would be ordered after IPv4 nameservers in the final resulting /etc/resolv.conf file, though. Regards, Fabian -- Fabian zzz Pietsch - http://www.canvon.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771696: dibbler-client: fails to register DNS server and search list properly with resolvconf
Hello, The solution would be to gather the resolver data in dns_add() and domain_add(), and then call resolvconf -a iface once, with all information. I just had a look at dibbler git (which seems to be at the moment almost dibbler 1.0.0), and the gathering stuff is already there: The /etc/resolv.conf editing code. Dibbler would just need to keep a separate resolv.conf (initially empty), perhaps in /var/lib/dibbler/resolv.conf, and then after each change feed that to resolvconf -a $IFACE.inet6. Regards, Fabian -- Fabian zzz Pietsch - http://www.canvon.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771696: dibbler-client: fails to register DNS server and search list properly with resolvconf
Package: dibbler-client Version: 0.8.2-1 Severity: normal Tags: ipv6 Dear Maintainer, dibbler-client produces an invalid /run/resolvconf/interface/eth0 file. root@vm-initia:~# cat /run/resolvconf/interface/eth0 search canvon.de This is missing information. In the client log, everything looks fine, though: root@vm-initia:~# tail -3 /var/log/dibbler/dibbler-client.log 2014.12.01 18:29:17 Client NoticeSetting up DNS server fd94:97cc:7e28:2::15 on interface eth0/2. 2014.12.01 18:29:17 Client NoticeSetting up Domain nebel.canvon.de on interface eth0/2. 2014.12.01 18:29:17 Client NoticeSetting up Domain canvon.de on interface eth0/2. Regards, Fabian Pietsch -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dibbler-client depends on: ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-38+deb7u6 ii libgcc11:4.7.2-5 ii libstdc++6 4.7.2-5 ii ucf3.0025+nmu3 Versions of packages dibbler-client recommends: ii dibbler-doc 0.8.2-1 ii resolvconf 1.67 dibbler-client suggests no packages. -- debconf information: * dibbler-client/start: true dibbler-client/title: * dibbler-client/interfaces: eth0 * dibbler-client/options: dns, domain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492270: mktemp: should refuse templates which it currently returns literally
Package: mktemp Version: 1.5-2 Severity: normal mktemp can be given templates which expand to the same name at every use. It seems that it will only enter random characters into the X letters from the template if they are at the end, so this can easily happen by mistake. This leads to an unexpected denial of service vulnerability, triggered if a file with that name already exists. Such a mistake in a script can (and did until recently) go unnoticed if, e.g., an erroneously appended .tmp suffix leads to a valid, although not randomly named temporary file. This was only noticed when such a file was lingering around from a failed run and the new instance's error message suspiciously still contained all the X letters from the template. Consider this example: $ mktemp foo.XX foo.S26762 $ mktemp foo.XX foo.i28529 $ mktemp foo.XX.tmp foo.XX.tmp $ mktemp foo.XX.tmp mktemp: cannot create temp file foo.XX.tmp: File exists The first two mktemp invocation result in two randomly and differently named temporary files, as expected. The third invocation creates a file with a predictable name, and the fourth fails as this file already exists. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages mktemp depends on: ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries mktemp recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489916: dh-make-perl: has POD errors section in man page
Package: dh-make-perl Version: 0.47 Severity: minor Tags: patch From dh-make-perl(1): | POD ERRORS |Hey! The above document had some coding errors, which are explained |below: | |Around line 1403: |'=item' outside of any '=over' This seems to be caused by having a '=back' after the last two items in a list instead of only after the last item, introduced in r21750. Patch that removes the first '=back' attached. This lets the POD ERRORS section disappear. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-4-amd64 (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 dh-make-perl depends on: ii debhelper 7.0.14 helper programs for debian/rules ii dpkg-dev 1.14.20Debian package development tools ii fakeroot 1.9.5 Gives a fake root environment ii libemail-date-format-perl 1.002-1Module to generate RFC-2822-valid ii libmodule-depends-perl0.10-1.1 identify the dependencies of a dis ii libwww-mechanize-perl 1.34-2 Automate interaction with websites ii libyaml-perl 0.66-1 YAML Ain't Markup Language (tm) ii make 3.81-5 The GNU version of the make util ii perl 5.10.0-11 Larry Wall's Practical Extraction ii perl-modules [libpod-parser-p 5.10.0-11 Core Perl modules Versions of packages dh-make-perl recommends: ii apt-file 2.1.3 APT package searching utility -- c ii perl-modules [libmodule-build 5.10.0-11 Core Perl modules -- no debconf information --- dh-make-perl-0.47 2008-06-18 18:39:13.0 + +++ dh-make-perl2008-07-08 08:07:40.0 + @@ -1397,10 +1397,8 @@ This is useful when Bdebian/rules was created using older templates and doesn't contain much customisations. As always, you're strongly encouraged to verify if Bdebian/rules looks sane. -=back - =item B--dh ver Set desired debhelper version. If Cver is 7, generated debian/rules is minimalistic, using the auto-mode of debhelper. Also, any additional
Bug#470236: flam3 in electricsheep
Hi, are you aware of this message in the flam3 RFP? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470236#15 Regards, Fabian -- Fabian zzz Pietsch - http://www.canvon.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484054: libmail-mbox-messageparser-perl: Contains VIM swap file .Perl.pm.swp
Package: libmail-mbox-messageparser-perl Version: 1.4005-2 Severity: minor Hello, the package contains a VIM swap file: a0:/usr/share/perl5/Mail/Mbox/MessageParser# vim -r Swap files found: In current directory: 1..Perl.pm.swp owned by: root dated: Wed Jan 10 03:22:07 2007 file name: ~joey/src/packages/libmail-mbox-messageparser-perl/lib/Mail/Mbox/MessageParser/Perl.pm modified: no user name: joey host name: kodama process ID: 32162 [...] This applies to the package in unstable, too. Regards, Fabian -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages libmail-mbox-messageparser-perl depends on: ii libfilehandle-unget-perl0.1621-2 a FileHandle which supports ungett ii perl5.8.8-7etch3 Larry Wall's Practical Extraction libmail-mbox-messageparser-perl recommends no packages. -- no debconf information -- Fabian zzz Pietsch - http://www.canvon.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430225: sshfs: prevents some ssh_config options from being used
(The BTS doesn't seem to forward the full text of control requests to all affected parties, nor does it normally show in the web interface.) - Forwarded message from José L. Redrejo RodrÃguez [EMAIL PROTECTED] - Return-path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Date: Tue, 22 Apr 2008 09:22:43 +0200 From: José L. Redrejo RodrÃguez [EMAIL PROTECTED] Subject: sshfs: prevents some ssh_config options from being used To: [EMAIL PROTECTED] X-Mailer: Evolution 2.12.3 unarchive 430225 reopen 430225 thanks I've being testing sshfs and checking its code for version 1.9.1. I haven't seen in the code any way to use some of the ssh_config options. In fact, the option ControlPath that the author of the patch (Fabian Pietsch) tries to fix can not be used. Also, none of the provided patches is applied, so I can not understand why you closed this bug. So, please, tell me if this can be done and I've not been able to do it, or the bug just can not be closed. Regards. José L. - End forwarded message - The forwarded message was retrieved here: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=26;mbox=yes;bug=430225 -- Fabian zzz Pietsch - http://zzz.arara.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295156: tspc: init script fails to restart if not runnning
Hi, your package tspc seems to have had no upload since etch, but I just ran into Bug#295156 from early 2005. In particular, tspc gets stopped on ppp down, but the package-provided script snippet to start it again on ppp up fails, as the init script restart fails because of no running tspc. My workaround before finding that bug report was to change /etc/ppp/ip-up.d/0tspc to the following: (appended ~|| start) | #!/bin/sh | invoke-rc.d tspc restart || invoke-rc.d tspc start ..but I guess the solution suggested in 295156 should be better. Are you planning on providing a new tspc upload in the near future? IANADD, so I can't, e.g., NMU it. Apart from this issue, tspc just worked, out-of-the-box, providing myself with anonymous IPv6 tunneling since. It would be nice to have a tspc in lenny that's even better integrated by default. ;) Regards, Fabian -- Fabian zzz Pietsch - http://zzz.arara.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432007: ktorrent: CVE-2007-1799 now really fixed in etch/updates
notfixed 432007 ktorrent/2.0.3+dfsg1-2etch1 fixed 432007 ktorrent/2.0.3+dfsg1-2.2etch1 thanks With DSA 1373-2 [1] and ktorrent-2.0.3+dfsg1-2.2etch1 being released, this seems to be resolved, at last. :) Regards, Fabian (Note: IANADD, just torturing the BTS...) [1] http://lists.debian.org/debian-security-announce/debian-security-announce-2007/msg00168.html Note that in the subject, it's called DSA 1372-2, but 1372 seems to be xorg-server according to [2], and 1373 should be correct[3]. [2] http://www.debian.org/security/2007/dsa-1372 (xorg-server) [3] http://www.debian.org/security/2007/dsa-1373 (ktorrent) ..but this has 1373-1 only. ;) -- Fabian zzz Pietsch - http://zzz.arara.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432007: security upgrade's version lower than in stable, no APT upgrades
Hi, another security upgrade whose version is lower than in stable, so won't be automatically upgraded by APT: ktorrent. * [DSA 1372-1] New ktorrent packages fix directory traversal: | Date: Tue, 11 Sep 2007 19:36:11 +0100 | | Package: ktorrent | Vulnerability : directory traversal | Problem type : remote | Debian-specific: no | CVE Id(s) : CVE-2007-1799 | Debian Bug : 432007 | | It was discovered that ktorrent, a BitTorrent client for KDE, was vulnerable | to a directory traversal bug which potentially allowed remote users to | overwrite arbitrary files. | | For the stable distribution (etch), this problem has been fixed in version | 2.0.3+dfsg1-2etch1. $ apt-cache policy ktorrent ktorrent: Installed: 2.0.3+dfsg1-2.2 Candidate: 2.0.3+dfsg1-2.2 Version table: 2.2.2.dfsg.1-1 0 -1 http://ftp.de.debian.org sid/main Packages *** 2.0.3+dfsg1-2.2 0 500 http://ftp2.de.debian.org etch/main Packages 100 /var/lib/dpkg/status 2.0.3+dfsg1-2etch1 0 500 http://security.debian.org etch/updates/main Packages $ dpkg --compare-versions 2.0.3+dfsg1-2.2 \ 2.0.3+dfsg1-2etch1 echo true $ dpkg --compare-versions 2.0.3+dfsg1-2.2 \ 2.0.3+dfsg1-2etch1 echo true true Like Bug#424411: qt4-x11 security upgrade's version lower than in etch, which seems to have been silently fixed quite a while ago, the security upgrade's version seems to be based on the last normal upload. (2 - 2etch1) This leaves it lower than that of the auto-built bin-NMU (2 - 2+b1) in Bug#424411 and lower than that of the regular NMUs (2 - 2.1 - 2.2) in this case. This seems to be a common problem, and some technical fix (in the Security Team's tools? in usage of dch?) seems appropriate. Immediately use something like 2.etch1? (But might be inappropriately high in other cases.) Perhaps there could also be some tool that regularly checks whether security upgrades are really newer (version-wise) than in stable? At any rate, there should be a new upload with an upgradeable version. Regards, Fabian -- Fabian zzz Pietsch - http://zzz.arara.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414126: firehol: RESERVED_IPS need to be updated
* Alexander Wirt [EMAIL PROTECTED] (Fri, 09 Mar 2007 12:21:54 +0100):
Max Kutny schrieb am Freitag, den 09. März 2007:
Package: firehol
Version: 1.231-7
Severity: normal
RESERVED_IPS variable is out of date. I don't know when the last sync
with upstream happened but at least
http://firehol.cvs.sourceforge.net/firehol/firehol/firehol.sh?r1=1.249r2=1.250
and above were not merged.
The last RESERVED_IPs update was at 10. July 2006. Since there were a few
updates since then I will upload an updated firehol to unstable and volatile
later this day.
There seems to be no newer version in unstable; etch and sid both still
have firehol 1.231-7. In volatile I can only find 1.231-2sarge1volatile2
with a .deb date of 2007-03-12 (3 days after the above mail exchange).
Are there any plans to do something about it, in volatile, a stable
release update or at least unstable (then testing and later backports)?
There are real hosts on the Internet today that are currently blocked by
Debian firehol; at least with a 77.x.x.x IP address, which is part of
the change from the URL above. This can be difficult to figure out if it
hits you unexpectedly... ;)
For the record, a workaround is to replace ${UNROUTABLE_IPS} in
/etc/firehol/firehol.conf with the definition in /lib/firehol/firehol
minus the offending IP address blocks.
Regards, Fabian
--
Fabian zzz Pietsch - http://zzz.arara.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430225: sshfs: prevents some ssh_config options from being used
Package: sshfs Version: 1.6-1 Tags: patch Followup-For: Bug #430225 Despite of debatable usefulness of some ssh_config options with sshfs, this is a general problem. The list of recognized ssh_config options is hardcoded in sshfs.c and, sooner or later, this will prevent legitimate use. I ran into this when trying to disable connection sharing ad hoc, using ControlPath=none, for debugging another problem. There are two possible solutions: 1. Regularly add new ssh_config options to sshfs.c (or at least add one at a time after each reasoned, acceptable request ;). 2. Add a more general syntax to pass ssh_config options to ssh (or even to pass any options to ssh, but this seemed unnecessary to me). I've implemented both. Solution 1 is attached as more_ssh_options.patch (only using options that seemed of possible utility with sshfs; this didn't include ForwardAgent, when I went through ssh_config(5)). Number 2 is all_ssh_options.patch. This adds -o ssh_opt_SSHOPT=VALUE, for any SSHOPT. If the user should choose an invalid one, sshfs will silently exit with code 141; but it will likewise when, e.g., -o Port=jkalsd34jk (or something less obviously erroneous) is fed to the unpatched version. Please review and possible include the patches in your next upload. Regards, Fabian -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages sshfs depends on: ii fuse-utils 2.5.3-4.4Filesystem in USErspace (utilities ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libfuse22.5.3-4.4Filesystem in USErspace library ii libglib2.0-02.12.4-2 The GLib library of C routines sshfs recommends no packages. -- no debconf information more_ssh_options.patch Description: application/not-regular-file all_ssh_options.patch Description: application/not-regular-file
Bug#432633: esmtp: overwrites /etc/mailname on first install
Package: esmtp Version: 0.5.1-4.1 Severity: serious Justification: Policy 10.7.3 On first install of esmtp -- even when not installing esmtp-run, which lets esmtp be the system MTA -- the postinst overwrites /etc/mailname, even when answering the (default) no to Automatically overwrite configuration files?. This is highly unfortunate when mailname was already set and in use by other programs (e.g., the real MTA in case of nullmailer), and violates the spirit, if not the wording, of Policy 10.7.3, local changes [of configuration files] must be preserved during a package upgrade. Policy continues: | The other way to do it is via the maintainer scripts. These scripts | [...] must not overwrite or otherwise mangle the user's configuration | without asking[.] Extract from the postinst: db_get esmtp/overwriteconfig OverwriteConfig=$RET if test -s /etc/esmtprc -a $OverwriteConfig = false then exit 0 fi db_get esmtp/hostname HostName=$RET if test ! -s /etc/mailname -o `cat /etc/mailname` != $HostName then echo $HostName /etc/mailname fi So if automatic overwriting is disabled *and* no non-empty esmtprc existed, the postinst will exit without further configuration file tampering. This would be okay for creating an esmtprc alone, but also overwrites /etc/mailname (if it doesn't match the answer to SMTP server hostname). IMO, even if updating /etc/mailname would have been in order, *at least* a single backup of each automatically overwritten configuration file should be preserved. Furthermore, putting the SMTP server hostname into /etc/mailname seems to be a bad idea at all, cf. a value of smtp.example.org in a setup that would likely need a mailname of example.org. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages esmtp depends on: ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libesmtp5 1.0.3-1+b1 LibESMTP SMTP client library Versions of packages esmtp recommends: pn esmtp-run none (no description available) -- debconf information: * esmtp/username: esmtp/mda: procmail esmtp/hostport: 25 * esmtp/overwriteconfig: false * esmtp/hostname: smtp.int.zzznowman.dyndns.org esmtp/starttls: disabled -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432637: please log start/stop of daemonized nullmailer
Package: nullmailer Version: 1:1.03-4 Severity: wishlist It would be nice (for error tracking and otherwise) if a daemonized syslogging nullmailer would log the fact that it just started / is about to exit. Regards, Fabian -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages nullmailer depends on: ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii lsb-base3.1-23.1 Linux Standard Base 3.1 init scrip Versions of packages nullmailer recommends: ii sysklogd [system-log-daemon] 1.4.1-18 System Logging Daemon -- debconf information: * shared/mailname: silencer.int.zzznowman.dyndns.org * nullmailer/adminaddr: [EMAIL PROTECTED] * nullmailer/relayhost: mail.int.zzznowman.dyndns.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424411: qt4-x11 security upgrade's version lower than in etch
Package: security.debian.org Severity: important Hello, the recent DSA-1292-1 for qt4-x11 says: For the stable distribution (etch), this problem has been fixed in version 4.2.1-2etch1 However, this seems to be lower than the current version in etch: | silencer:~# apt-cache policy libqt4-core | libqt4-core: | Installed: 4.2.1-2+b1 | Candidate: 4.2.1-2+b1 | Version table: | 4.2.3-1+b1 0 | -1 http://ftp.de.debian.org sid/main Packages | *** 4.2.1-2+b1 0 | 500 http://ftp2.de.debian.org etch/main Packages | 100 /var/lib/dpkg/status | 4.2.1-2etch1 0 | 500 http://security.debian.org etch/updates/main Packages | silencer:~# dpkg --compare-versions 4.2.1-2+b1 \ 4.2.1-2etch1 echo true | true As a result, the security upgrade won't be installed automatically using APT. The higher version number seems to originate from an automatic buildd rebuild; from the changelog: | qt4-x11 (4.2.1-2+b1) unstable; urgency=low | | * Binary-only non-maintainer upload for i386; no source changes. | * Rebuild against libmysqlclient15off (= 5.0.27-1) | | -- Debian/i386 Build Daemon buildd_i386-saens Sun, 18 Feb 2007 17:40:30 -0600 | | qt4-x11 (4.2.1-2) unstable; urgency=low | | [...] | | -- Brian Nelson [EMAIL PROTECTED] Tue, 31 Oct 2006 02:42:02 -0500 So this seems to be a systematic problem here that will cause trouble again with further security upgrades or NMUs; the '+' in the appended version strings seems to be rather high, perhaps it should be changed to something lower for the future. Regards, Fabian -- Fabian zzz Pietsch - http://zzz.arara.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418929: RM: ndiswrapper-modules-2.6.8-2-* -- binary modules for ancient kernel version
Package: ftp.debian.org
Severity: minor
ndiswrapper-modules-2.6.8-2-{386,{686,k7}{,-smp}} seem to be still
present in unstable according to packages.debian.org. [1]
They predate even the corresponding packages from sarge, which are:
ndiswrapper-modules-2.6.8-3-{386,{686,k7}{,-smp}}
Regards, Fabian
[1] The source package seems to only build those modules:
http://packages.debian.org/unstable/source/ndiswrapper-modules-i386
So perhaps it should be removed as well, if there aren't any plans
to update it to 2.6.18-4 or something in the near future.
--
Fabian zzz Pietsch - http://zzz.arara.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#69271: PTS Praise Tracking System
Hi, From: Justin Pryzby [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: #69271: PTS Praise Tracking System Date: Sun, 22 Jan 2006 15:46:39 -0500 Hello Joost, In Debian bug log #69271, you request supporting a praise tracking system. I just wanted to point out the functionality provided by bts -k That would be: reportbug -k (or --kudos) Regards, Fabian -- Fabian zzz Pietsch - http://zzz.arara.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417995: initramfs-tools: lets ordinary users read the root filesystem's raw block device
Package: initramfs-tools
Version: 0.85f
Severity: critical
Tags: security patch
Justification: root security hole
A system that was booted from an initramfs created by initramfs-tools has
the following device node in the booted system's /dev:
| brw-r--r-- 1 root root 3, 7 Apr 6 00:38 /dev/root
This allows ordinary users to read the raw root filesystem, i.e.,
its block device. Bypassing the normal filesystem access restrictions
with this becomes easy through, e.g., /sbin/debugfs from e2fsprogs,
a Priority: required package. After reading /etc/shadow, passwords of
other accounts on the system may be cracked. Other authentication data
often is even unencrypted, like the boot loader password from
/etc/lilo.conf, which allows a local attacker to reboot with, e.g.,
init=/bin/bash, and take full control of the system. /blah
The device node is created prior to mounting the root filesystem, by a
script shared between initramfs generator and generated initramfs.
klibc-utils' mknod doesn't seem to support passing permissions on the
command line, so umask or chmod would be needed. For BUSYBOX=y in
/etc/initramfs-tools/initramfs.conf, after applying the following patch,
running update-initramfs -u and rebooting, the device node's permissions
are sane:
| brw--- 1 root root 3, 7 Apr 6 00:50 /dev/root
--- /usr/share/initramfs-tools/scripts/functions.orig
+++ /usr/share/initramfs-tools/scripts/functions
@@ -231,6 +231,7 @@
;;
esac
mknod /dev/root b ${major} ${minor}
+ chmod go-rw /dev/root
ROOT=/dev/root
}
-- Package-specific info:
-- /proc/cmdline
auto BOOT_IMAGE=debian ro root=307 resume=/dev/hda4
-- /proc/filesystems
cramfs
ext3
-- lsmod
Module Size Used by
ipv6 226016 18
button 6672 0
ac 5188 0
battery 9636 0
nfs 202828 2
lockd 54344 2 nfs
nfs_acl 3584 1 nfs
sunrpc138812 4 nfs,lockd,nfs_acl
dm_snapshot15552 0
dm_mirror 19152 0
dm_mod 50232 2 dm_snapshot,dm_mirror
r128 34816 0
drm61332 1 r128
3c509 11828 0
snd_ens137123616 1
tsdev 7520 0
gameport 14632 1 snd_ens1371
snd_ac97_codec 83104 1 snd_ens1371
snd_ac97_bus2400 1 snd_ac97_codec
snd_pcm_oss38368 0
snd_mixer_oss 15200 2 snd_pcm_oss
snd_pcm68676 3 snd_ens1371,snd_ac97_codec,snd_pcm_oss
snd_seq_dummy 3844 0
snd_seq_oss28768 0
snd_seq_midi8192 0
snd_rawmidi22560 2 snd_ens1371,snd_seq_midi
floppy 53156 0
psmouse35016 0
parport_pc 32132 0
parport33256 1 parport_pc
snd_seq_midi_event 7008 2 snd_seq_oss,snd_seq_midi
snd_seq45680 6
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
pcspkr 3072 0
rtc12372 0
serio_raw 6660 0
snd_timer 20996 2 snd_pcm,snd_seq
snd_seq_device 7820 5
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
bttv 159732 0
video_buf 23012 1 bttv
firmware_class 9600 1 bttv
ir_common 27780 1 bttv
compat_ioctl32 1472 1 bttv
i2c_algo_bit8424 1 bttv
btcx_risc 4776 1 bttv
tveeprom 13840 1 bttv
videodev 21120 1 bttv
v4l1_compat12036 1 videodev
v4l2_common20448 2 bttv,videodev
snd47012 10
snd_ens1371,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
soundcore 9248 2 snd
i2c_piix4 8140 0
snd_page_alloc 9640 1 snd_pcm
i2c_core 19680 4 bttv,i2c_algo_bit,tveeprom,i2c_piix4
shpchp 33024 0
intel_agp 21148 1
pci_hotplug28704 1 shpchp
agpgart29896 2 drm,intel_agp
evdev 9088 0
ext3 119240 2
jbd52456 1 ext3
mbcache 8356 1 ext3
ide_generic 1408 0 [permanent]
ide_cd 36064 0
cdrom 32544 1 ide_cd
ide_disk 14848 4
piix9444 0 [permanent]
sis900 21760 0
3c59x 40360 0
mii 5344 2 sis900,3c59x
generic 5476 0 [permanent]
uhci_hcd 21164 0
usbcore 112644 2 uhci_hcd
ide_core 110504 5 ide_generic,ide_cd,ide_disk,piix,generic
thermal13608 0
processor 28840 1 thermal
fan 4804 0
-- kernel-img.conf
# Kernel Image
Bug#330621: apt-listbugs ignores apt-get's --quiet option
* Junichi Uekawa [EMAIL PROTECTED] (Wed, 21 Mar 2007 22:07:40 +0900): it had been pointed out that there would be no way for apt-listbugs to know whether apt-get had been given a -q/--quiet option, to produce loggable output only, i.e., without frequently updated progress indicators. This seems to be mistaken. thanks for the info, patch? Ah, forget about it, I've created the patch anyway. Great! -- Sorry, but I don't speak ruby; I planned to give it a try, but it'll be better if it's done right, by someone who knows the language. Regards, Fabian -- Fabian zzz Pietsch - http://zzz.arara.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415577: nullmailer: fails to send emails on NFS root client that were queued on the NFS server
Package: nullmailer Version: 1:1.03-4 Severity: wishlist This client netboots into an NFS root filesystem. However, APT upgrades are usually performed on the NFS server, while chrooted into the client's root filesystem. Automatically generated mails then get correct 0600 permissions, but root owner in /var/spool/nullmailer/queue/, so nullmailer on the client, running as user mail, can't read or send them. This seems to be caused by the filesystem on the NFS server being mounted nosuid. It would be nice if nullmailer-queue could setuid(mail) (or something?) explicitly, when started as root and filesystem setuid apparently didn't work. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-486 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages nullmailer depends on: ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii lsb-base3.1-23.1 Linux Standard Base 3.1 init scrip Versions of packages nullmailer recommends: ii sysklogd [system-log-daemon] 1.4.1-18 System Logging Daemon -- debconf information: * shared/mailname: cellardoor.int.zzznowman.dyndns.org * nullmailer/adminaddr: [EMAIL PROTECTED] * nullmailer/relayhost: smtp.int.zzznowman.dyndns.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330621: apt-listbugs ignores apt-get's --quiet option (Was: apt-get ignores --quiet option after packages are downloaded)
Hi,
it had been pointed out that there would be no way for apt-listbugs to
know whether apt-get had been given a -q/--quiet option, to produce
loggable output only, i.e., without frequently updated progress
indicators. This seems to be mistaken.
Confer apt-get(8):
| -q, --quiet
|Quiet; produces output suitable for logging, omitting progress
|indicators. [...] Configuration Item: quiet.
And this (the configuration item) seems to be where, e.g.,
apt-listchanges gets this information from.
Code snippet from /usr/bin/apt-listchanges:
| def main():
[...]
|
| if config.apt_mode:
| debs = apt_listchanges.read_apt_pipeline(config)
|
[...]
|
| # If apt is in quiet (loggable) mode, we should make our output
| # loggable too
| if config.quiet == 1:
| config.frontend = 'text'
| elif config.quiet = 2:
| config.frontend = 'mail'
Code snippet from /usr/share/apt-listchanges/apt_listchanges.py:
| def read_apt_pipeline(config):
| version = sys.stdin.readline().rstrip()
| if version != VERSION 2:
| sys.stderr.write(_('''Wrong or missing VERSION from apt pipeline
| (is Dpkg::Tools::Options::/usr/bin/apt-listchanges::Version set to 2?)
| '''))
| sys.exit(1)
|
| while 1:
| line = sys.stdin.readline().rstrip()
| if not line:
| break
|
| if line.startswith('quiet='):
| config.quiet = int(line[len('quiet='):])
Confer apt.conf(5):
| Pre-Install-Pkgs
|This is a list of shell commands to run before invoking dpkg. Like
|options this must be specified in list notation. The commands are
|invoked in order using /bin/sh, should any fail APT will abort. APT
|will pass to the commands on standard input the filenames of all .deb
|files it is going to install, one per line.
|
|Version 2 of this protocol dumps more information, including the
|protocol version, the APT configuration space and the packages, files
|and versions being changed. Version 2 is enabled by setting
|DPkg::Tools::options::cmd::Version to 2. cmd is a command given to
|Pre-Install-Pkgs.
And indeed this is set in /etc/apt/apt.conf.d/20listchanges:
| DPkg::Pre-Install-Pkgs { /usr/bin/apt-listchanges --apt || test $? -ne 10;
};
| DPkg::Tools::Options::/usr/bin/apt-listchanges::Version 2;
So it would seem quite possible now to integrate --quiet awareness into
apt-listbugs, too.
Regards, Fabian
--
Fabian zzz Pietsch - http://zzz.arara.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413945: rxvt-unicode: crashes on U+FFFD; sid version lesser affected
Package: rxvt-unicode
Version: 5.3-1
Severity: normal
Hi,
sarge rxvt-unicode crashes when U+FFFD is to be displayed.
(Apparently this is the substitution character for invalid input;
e.g., for plain latin1 non-ascii chars in UTF-8 mode. Altough urxvt
seems to automatically up-convert at least some of them, other programs
like GNU screen run inside may substitute them before they reach urxvt.)
Before unexpected termination, sarge urxvt prints:
| X Error of failed request: BadName (named color or font does not exist)
| Major opcode of failed request: 75 (X_PolyText16)
| Serial number of failed request: 1197
| Current serial number in output stream: 1218
| Xlib: unexpected async reply (sequence 0x4c2)!
The sid version (7.9-2) doesn't crash, but doesn't render
a character either (xterm does, as a dashed hollow square)
and outputs (essentially the same):
| urxvt: An X Error occured, trying to continue after report.
| urxvt: X Error of failed request: BadName (named color or font does not
exist)
| urxvt: Major opcode of failed request: 75
| urxvt: (which is X_PolyText16)
| urxvt: Serial number of failed request: 3463
The error does _not_ occur when overriding the font list as suggested
in #294582. (Then the character is rendered, as ~(?).) For example:
| $ LANG=de_DE.UTF-8 urxvt -name noresources -fn 10x20
| $ LANG=de_DE.UTF-8 urxvt -name noresources -fn 8x13
| $ LANG=de_DE.UTF-8 urxvt -name noresources -fn terminus-16
| urxvt: An X Error occured, trying to continue after report.
| [...]
My usual fontlist is: terminus-16,xft:Kochi Gothic:antialias=false
As far as I know, urxvt also appends a built-in list of known-to-work
fonts, so apparently the character is missing in all those fonts.
However, it would be nice if urxvt could handle this more gracefully,
i.e., without printing error messages (or more specific ones?) and by
rendering a substitution character, possibly built-in. (?)
The offending character may be produced in the following way:
$ echo '#65533;' | recode html..utf8
Composing the character via urxvt's Ctrl-Shift-{F,F,F,D} also works and
immediately leads to the above results, even before releasing the
modifier keys. (It already tries rendering it in the preview window.)
Regards, Fabian
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.18-4-686
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Versions of packages rxvt-unicode depends on:
ii base-passwd3.5.9 Debian base system master password
ii libc6 2.3.2.ds1-22sarge5GNU C Library: Shared libraries an
ii libfontconfig1 2.3.1-2 generic font configuration library
ii libfreetype6 2.1.7-6 FreeType 2 font engine, shared lib
ii libgcc11:3.4.3-13sarge1 GCC support library
ii libx11-6 4.3.0.dfsg.1-14sarge3 X Window System protocol client li
ii libxft22.1.7-1 FreeType-based font drawing librar
ii libxrender10.8.3-7 X Rendering Extension client libra
ii xlibs 6.9.0.dfsg.1-6~bpo.4 X Window System client libraries m
ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413945: rxvt-unicode: crashes on U+FFFD; sid version lesser affected
* Fabian Pietsch [EMAIL PROTECTED] (Thu, 08 Mar 2007 01:44:05 +0100): As far as I know, urxvt also appends a built-in list of known-to-work fonts, so apparently the character is missing in all those fonts. However, it would be nice if urxvt could handle this more gracefully, i.e., without printing error messages (or more specific ones?) and by rendering a substitution character, possibly built-in. (?) It seems that urxvt (sarge and sid) only uses the first font in the font list when trying to render this character. That means that no easy workaround (of including further fonts at the end of the list) is possible -- only completely substituting the main font helps. (According to the man page, [codeset=...] hints are only used for Xft fonts, so this way also no workaround lies.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405134: acct: cron.monthly broken
Package: acct Version: 6.4~pre1-3 Hi, acct's cron.monthly script seems to be severely broken since -3. What seems to be a good-faith attempt to handle switching between compressed and uncompressed rotated logfiles gracefully, turns out to be affected by the following defects: - Compressed rotated logfile is no longer uncompressed for processing. Instead, a fresh, empty temporary file will be used. - The case of having no uncompressed but a compressed logfile isn't handled anymore. - If no compressed logfile exists, an unconditional 'rm -f ' will be executed, without output redirection(, but simply wrong). - Even in the case of having two rotated logfiles, one compressed and one uncompressed, for what the change seems to have been meant: `ac' is run on both files, but `last' only on the compressed one (if it would have been decompressed into the temporary file). The previous (-1) version's only defect, on the other hand, seems to be that it unconditionally uses a possibly-existing uncompressed rotated logfile in addition to the previously detected existing uncompressed-or-compressed one, and there, too, only for `ac', not for `last'. It could have been fixed simply be dropping the superflous '-f /var/log/wtmp.1'. Apart from the technical details, there seems to be little point in trying to support using two rotated logfiles at the same time, as they are assumed to be rotated monthly / contain records for the previous month, and if really a wtmp.1 and a wtmp.1.gz exist at the same time, one will almost certainly be out-of-date and be stuck there from a configuration change whether to compress rotated wtmp files. Hope this helps in any way and is not (perceived as?) only flames... Regards, Fabian -- Fabian zzz Pietsch - http://zzz.arara.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405134: acct: cron.monthly broken
* Fabian Pietsch [EMAIL PROTECTED] (Sun, 31 Dec 2006 17:48:01 +0100):
Package: acct
Version: 6.4~pre1-3
acct's cron.monthly script seems to be severely broken since -3.
What seems to be a good-faith attempt to handle switching between
compressed and uncompressed rotated logfiles gracefully, turns out to be
affected by the following defects:
[...]
The previous (-1) version's only defect, on the other hand, seems to be
that it unconditionally uses a possibly-existing uncompressed rotated
logfile in addition to the previously detected existing
uncompressed-or-compressed one, and there, too, only for `ac', not for
`last'. It could have been fixed simply be dropping the superflous
'-f /var/log/wtmp.1'.
[...]
Sorry, forgot to attach both scripts for public review.
They live in /etc/cron.monthly/acct after installation
(if that wasn't obvious).
--
Fabian zzz Pietsch - http://zzz.arara.de/
#!/bin/sh
#
# cron script to perform monthly login accounting.
#
# Written by Ian A. Murdock [EMAIL PROTECTED]
# Modified by Dirk Eddelbuettel [EMAIL PROTECTED]
# Modified by Tero Tilus [EMAIL PROTECTED]
# patch adopted by Christian Perrier [EMAIL PROTECTED] for #187538
LOGROTATE=/etc/cron.daily/logrotate
if [ -x /usr/sbin/accton ]
then
echo Login accounting for the month ended `date`:
/var/log/wtmp.report
echo /var/log/wtmp.report
# The logrotate script happens to run before this one, effectively
# swallowing all information out of wtmp before we can use it.
# Hence, we need to use the previous file. Bad hack.
# Too bad we never heard from the logrotate maintainer about this ...
# edd 18 May 2002 make sure wtmp.1 exists
if [ -f ${LOGROTATE} ] [ -x /usr/sbin/logrotate ]
then
if [ -f /var/log/wtmp.1 ]
then
WTMP=/var/log/wtmp.1
elif [ -f /var/log/wtmp.1.gz ]
then
WTMP_WAS_GZIPPED=1
WTMP=`tempfile`
gunzip -c /var/log/wtmp.1.gz ${WTMP}
fi
ac -f ${WTMP} -f /var/log/wtmp.1 -p | sort -nr -k2
/var/log/wtmp.report
echo /var/log/wtmp.report
last -f ${WTMP} /var/log/wtmp.report
if [ -n ${WTMP_WAS_GZIPPED} ]
then
# remove temporary file
rm -f ${WTMP}
fi
else
ac -p | sort -nr -k2 /var/log/wtmp.report
echo /var/log/wtmp.report
last /var/log/wtmp.report
fi
fi
#!/bin/sh
#
# cron script to perform monthly login accounting.
#
# Written by Ian A. Murdock [EMAIL PROTECTED]
# Modified by Dirk Eddelbuettel [EMAIL PROTECTED]
# Modified by Tero Tilus [EMAIL PROTECTED]
# patch adopted by Christian Perrier [EMAIL PROTECTED] for #187538
LOGROTATE=/etc/cron.daily/logrotate
if [ -x /usr/sbin/accton ]
then
echo Login accounting for the month ended `date`:
/var/log/wtmp.report
echo /var/log/wtmp.report
# The logrotate script happens to run before this one, effectively
# swallowing all information out of wtmp before we can use it.
# Hence, we need to use the previous file. Bad hack.
# Too bad we never heard from the logrotate maintainer about this ...
# edd 18 May 2002 make sure wtmp.1 exists
if [ -f ${LOGROTATE} ] [ -x /usr/sbin/logrotate ]
then
if [ -f /var/log/wtmp.1 ]
then
LOGFILE=/var/log/wtmp.1
fi
if [ -f /var/log/wtmp.1.gz ]
then
LOGFILE2=`tempfile`
fi
if [ -n ${LOGFILE} ] [ -n ${LOGFILE2} ]
then
ac -f ${LOGFILE2} -f ${LOGFILE} -p | sort -nr -k2
/var/log/wtmp.report
echo /var/log/wtmp.report
last -f ${LOGFILE2} /var/log/wtmp.report
elif [ -n ${LOGFILE} ] [ -z ${LOGFILE2} ]
then
ac -f ${LOGFILE} -p | sort -nr -k2
/var/log/wtmp.report
echo /var/log/wtmp.report
last -f ${LOGFILE} /var/log/wtmp.report
fi
rm -f ${LOGFILE2}
else
ac -p | sort -nr -k2 /var/log/wtmp.report
echo /var/log/wtmp.report
last /var/log/wtmp.report
fi
fi
Bug#51796: Bug#324910 closed by Daniel Baumann [EMAIL PROTECTED] (Bug#324910: fixed in acct 6.4~pre1-1)
[See below for a comment regarding #51796 (wtmp is rotated before the
report (logrotate?)).]
[Quotes regenerated from original mails to provide context.]
* Fabian Pietsch [EMAIL PROTECTED] (Wed, 24 Aug 2005 21:08:45 +0200):
In /etc/cron.monthly/acct, a monthly report of system and user activity
logged in the wtmp file is generated; part of this is the following:
if [ -f $LOGROTATE ] [ -x /usr/sbin/logrotate ]
then
[...]
ac -f $WTMP /var/log/wtmp.1 -p | sort -nr +1
/var/log/wtmp.report
[...]
else
ac -p | sort -nr +1 /var/log/wtmp.report
[...]
fi
In the second case, the invocation of ac would summarize connect/login
times for all users; in the first, it would do likewise for the user
/var/log/wtmp.1 which doesn't exist, so the only ac output will be:
total0.00
The additional parameter to ac seems to have been left when $WTMP was
introduced, probably in a fix in acct-6.3.5-38.2, and should most
probably be removed to restore functionality.
* Sam Morris [EMAIL PROTECTED] (Tue, 12 Sep 2006 10:20:06 +0100):
I think that the additional processing of wtmp.1 must be left in to take
account of log rotation (see #51796). I found that putting an additional
'-f' parameter before '/var/log/wtmp.1' caused ac to process both files.
[Unfortunately I didn't get the above follow-up to my bug report as I
was only the reporter, not subscribed to the bug nor manually kept in
the loop...]
* Debian Bug Tracking System [EMAIL PROTECTED] (Sat, 04 Nov 2006 05:03:39
-0800):
Subject: Bug#324910 closed by Daniel Baumann [EMAIL PROTECTED]
(Bug#324910: fixed in acct 6.4~pre1-1)
This is an automatic notification regarding your Bug report
#324910: /etc/cron.monthly/acct typo results in no meaningful ac output in
/var/log/wtmp.report if logrotate is installed,
which was filed against the acct package.
It has been closed by Daniel Baumann [EMAIL PROTECTED].
[...]
Changes:
acct (6.4~pre1-1) unstable; urgency=medium
.
[...]
* Updated ac call in cron.monthly to process both $WTMP and /var/log/wtmp.1
(Closes: #324910).
I believe $WTMP already contains /var/log/wtmp.1 if it exists, and the
name of an uncompressed temporary copy of a wtmp.1.gz if that exists
instead. See below for the full quote of what had been shortened above.
Taken from acct-6.4~pre1-1's debian/cron.monthly:
| if [ -f ${LOGROTATE} ] [ -x /usr/sbin/logrotate ]
| then
| if [ -f /var/log/wtmp.1 ]
| then
| WTMP=/var/log/wtmp.1
| elif [ -f /var/log/wtmp.1.gz ]
| then
| WTMP_WAS_GZIPPED=1
| WTMP=`tempfile`
|
| gunzip -c /var/log/wtmp.1.gz ${WTMP}
| fi
|
| ac -f ${WTMP} -f /var/log/wtmp.1 -p | sort -nr -k2
/var/log/wtmp.report
| echo /var/log/wtmp.report
| last -f ${WTMP} /var/log/wtmp.report
|
| if [ -n ${WTMP_WAS_GZIPPED} ]
| then
| # remove temporary file
| rm -f ${WTMP}
| fi
| else
| ac -p | sort -nr -k2 /var/log/wtmp.report
| echo /var/log/wtmp.report
| last /var/log/wtmp.report
| fi
Therefore it seems to me that as of acct-6.4~pre1-1, /var/log/wtmp.1
will be processed twice in some cases. I still suggest the correct fix
for the first occurrence of ac in the above snippet would be:
] ac -f ${WTMP} -p | sort -nr -k2 /var/log/wtmp.report
As for #51796, it might well be possible that the empty report is caused
by the same superflous explicit occurrence of /var/log/wtmp.1 (parsed as
username by ac), as in my original report -- and therefore not caused
by log rotation order, as suggested by #51796's bug title
(wtmp is rotated before the report (logrotate?)).
Or perhaps the whole point of the $WTMP indirection in this script was
to fix #51796, but didn't really fix it because of the leftover explicit
/var/log/wtmp.1 ;)
Regards, Fabian
--
Fabian zzz Pietsch - http://zzz.arara.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309118: capplets: gnome-background-properties crashes repeatedly, not workaroundable by novice users
Package: capplets Version: 1:2.8.2-3 Followup-For: Bug #309118 As stated a bit unspecifically in the original report, gnome-background-properties crashes immediately after being started when there are entries in ~/.gnome2/backgrounds.xml with an empty filename (and name) tag. It seems that such entries are added when the user tries to add an image with special characters in the file name. Crashes here means gets a segfault, obscured by an automatically started GNOME bug reporting tool. It was also reported to me that gnome-background-properties hung indefinitely just after trying to add such an image, but the system was already a bit unresponsive because of high load at that time, so the user might have been too impatient. It seems that the user killed gnome-background-properties after that, probably by force / using GNOME's doesn't respond dialog. The image was displayed correctly as desktop background after setting the value of gconf's /desktop/gnome/background/picture_filename manually. gnome-background-properties stopped crashing after removing the offending empty entry in ~/.gnome2/backgrounds.xml manually. The special characters in question were German umlauts ue and oe, encoded as UTF-8, in an ISO-8859-1 locale. Strangely enough, nautilus and gnome-background-properties (after setting the background manually) display the characters correctly all the same. The net result of this bug is that novice users have no chance to change their desktop background after trying *once* to set an image with special characters in the file name, as the UI for changing desktop backgrounds just keeps crashing. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.16-2-k7 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages capplets depends on: ii capplets-data 1:2.8.2-3 configuration applets for GNOME 2 ii gnome-control-center 1:2.8.2-3 The GNOME Control Center for GNOME ii gnome-desktop-data2.8.3-2Common files for GNOME 2 desktop a ii gnome-icon-theme 2.8.0-4GNOME Desktop icon theme ii gnome-panel 2.8.3-1launcher and docking facility for ii gnome-session 2.8.1-6The GNOME 2 Session Manager ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.8.0-4The ATK accessibility toolkit ii libaudiofile0 0.2.6-6Open-source version of SGI's audio ii libbonobo2-0 2.8.1-2Bonobo CORBA interfaces library ii libbonoboui2-02.8.1-2The Bonobo UI library ii libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an ii libeel2-2 2.8.2-1Eazel Extensions Library (for GNOM ii libesd0 0.2.35-2 Enlightened Sound Daemon - Shared ii libfontconfig12.3.1-2generic font configuration library ii libfreetype6 2.1.7-2.5 FreeType 2 font engine, shared lib ii libgail-common1.8.4-1GNOME Accessibility Implementation ii libgail17 1.8.4-1GNOME Accessibility Implementation ii libgconf2-4 2.8.1-6GNOME configuration database syste ii libgcrypt11 1.2.0-11.1 LGPL Crypto library - runtime libr ii libglade2-0 1:2.4.2-2 library to load .glade files at ru ii libglib2.0-0 2.6.4-1The GLib library of C routines ii libgnome-desktop-22.8.3-2Utility library for loading .deskt ii libgnome-keyring0 0.4.2-1GNOME keyring services library ii libgnome2-0 2.8.1-2The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.8.0-1A powerful object-oriented display ii libgnomeui-0 2.8.1-3The GNOME 2 libraries (User Interf ii libgnomevfs2-02.8.4-4The GNOME virtual file-system libr ii libgnutls11 1.0.16-13.2GNU TLS library - runtime library ii libgpg-error0 1.0-1 library for common error values an ii libgstreamer-plugins0 0.8.8-2Various GStreamer libraries and li ii libgstreamer0.8-0 0.8.9-2Core GStreamer libraries, plugins, ii libgtk2.0-0 2.6.4-3.1 The GTK+ graphical user interface ii libice6 6.9.0.dfsg.1-5bpo2 Inter-Client Exchange library ii libjpeg62 6b-10 The Independent JPEG Group's JPEG ii libmetacity0 1:2.8.8-1 Common library of lightweight GTK2 ii libnautilus2-22.8.2-2libraries for nautilus components ii liborbit2 1:2.12.2-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.8.1-1Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsm6
Bug#354190: siproxd: invalid argument for format string
Package: siproxd
Version: 1:0.5.10+cvs20050423-1
Severity: normal
Tags: patch
In proxy.c, functions proxy_request() and proxy_response(), an argument
of type osip_uri_t* is used for a %s conversion specification. However,
osip_uri_t is a struct; it seems like what really was meant is its member
host of type char*.
This seems to only affect siproxd if debug output is activated,
DBCLASS_PROXY is included in debug_level and a host name read from the
network cannot be resolved. By chance I happened to hit it all the same. ;)
Luckily, on my system, a NUL byte was less than 20 bytes of garbage away.
The code in question is also present in 1:0.5.11-1 (testing, unstable),
as proxy.c is identical to 1:0.5.10+cvs20050423-1 (before applying
debian patches). In current upstream (24Feb2006), the code has been
removed from the two functions in proxy.c, but added to
sip_find_direction() in sip_utils.c, still containing the bug.
Regards, Fabian
diff -du4rN siproxd-0.5.10+cvs20050423/src/proxy.c
siproxd-0.5.10+cvs20050423-format/src/proxy.c
--- siproxd-0.5.10+cvs20050423/src/proxy.c 2005-04-22 00:41:02.0
+0200
+++ siproxd-0.5.10+cvs20050423-format/src/proxy.c 2006-02-24
06:46:53.0 +0100
@@ -143,9 +143,9 @@
if (urlmap[i].active == 0) continue;
if (get_ip_by_host(urlmap[i].true_url-host, tmp_addr) == STS_FAILURE) {
DEBUGC(DBCLASS_PROXY, proxy_request: cannot resolve host [%s],
- urlmap[i].true_url);
+ urlmap[i].true_url-host);
} else {
DEBUGC(DBCLASS_PROXY, proxy_request: reghost:%s ip:%s,
urlmap[i].true_url-host, utils_inet_ntoa(from-sin_addr));
if (memcmp(tmp_addr, from-sin_addr, sizeof(tmp_addr)) == 0) {
@@ -639,9 +639,9 @@
if (urlmap[i].active == 0) continue;
if (get_ip_by_host(urlmap[i].true_url-host, tmp_addr) == STS_FAILURE) {
DEBUGC(DBCLASS_PROXY, proxy_response: cannot resolve host [%s],
- urlmap[i].true_url);
+ urlmap[i].true_url-host);
} else {
DEBUGC(DBCLASS_PROXY, proxy_response: reghost:%s ip:%s,
urlmap[i].true_url-host, utils_inet_ntoa(from-sin_addr));
if (memcmp(tmp_addr, from-sin_addr, sizeof(tmp_addr)) == 0) {
signature.asc
Description: Digital signature
Bug#324910: /etc/cron.monthly/acct typo results in no meaningful ac output in /var/log/wtmp.report if logrotate is installed
Package: acct Version: 6.3.5-39 Severity: minor Tags: patch In /etc/cron.monthly/acct, a monthly report of system and user activity logged in the wtmp file is generated; part of this is the following: if [ -f $LOGROTATE ] [ -x /usr/sbin/logrotate ] then [...] ac -f $WTMP /var/log/wtmp.1 -p | sort -nr +1 /var/log/wtmp.report [...] else ac -p | sort -nr +1 /var/log/wtmp.report [...] fi In the second case, the invocation of ac would summarize connect/login times for all users; in the first, it would do likewise for the user /var/log/wtmp.1 which doesn't exist, so the only ac output will be: total0.00 The additional parameter to ac seems to have been left when $WTMP was introduced, probably in a fix in acct-6.3.5-38.2, and should most probably be removed to restore functionality. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-2-k7 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages acct depends on: ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an -- debconf information excluded --- /etc/cron.monthly/acct +++ /etc/cron.monthly/acct @@ -29,9 +29,9 @@ WTMP=$(tempfile) gunzip -c /var/log/wtmp.1.gz $WTMP fi - ac -f $WTMP /var/log/wtmp.1 -p | sort -nr +1 /var/log/wtmp.report + ac -f $WTMP -p | sort -nr +1 /var/log/wtmp.report echo /var/log/wtmp.report last -f $WTMP /var/log/wtmp.report if [ -n $WTMP_WAS_GZIPPED ] signature.asc Description: Digital signature
Bug#319005: apt-proxy: workaround for apt-proxy-import failure
Hi,
I've been having the same problems, also with the sarge version of
apt-proxy. The problem really seems to arise from compressed Packages
files.
The source[1] suggests that Release and Packages files have to be
registered by apt-proxy for some reason; when running apt-get update
through apt-proxy, it unfortunately only registers the Release file, not
the Packages.gz (as indicated through REGISTERING PACKAGE log
messages, missing for the Packages.gz file).
As a workaround, I've tried to download the uncompressed Packages file
manually through apt-proxy, but first only ended up with exceptions in
the apt-proxy log and an apt-proxy that was unresponsive to that
specific backend until a restart(, i.e., client connections hung).
Further investigation (trial error.. cough) showed that it's the
order that's important; at first, the compressed Packages file has to be
requested, and (immediately?) after that the uncompressed. Surprisingly
enough, according to apt-proxy logs it verifys/uncompresses the
compressed Packages file then instead of downloading the full
uncompressed file (at least with .gz), then correctly registers it.
After apt-proxy had registered the Packages files of my backends,
apt-proxy-import finally worked. (It couldn't import some (few)
packages, though, but most of them were removed from the archive by then
or got imported on a second run (whyever).)
I'd be interested what other consequences (lack of) registering Packages
files has besides apt-proxy-import functionality -- should the
workaround be repeated once in a while for proper long-term apt-proxy
functionality?
Here's a shell script fragment that works around the lack of Packages
files registration for me as described above, using wget:
for URL in \
http://localhost:/debian/dists/sarge/{main,contrib,non-free}/binary-i386/Packages
\
http://localhost:/security/dists/sarge/updates/{main,contrib,non-free}/binary-i386/Packages
do
wget -nv -O /dev/null $URL.gz $URL
done
Regards, Fabian
--
[1] /usr/lib/python2.3/site-packages/apt_proxy/packages.py line 125:
class AptPackages:
[...]
def packages_file(self, uri):
[...]
if basename(uri)==Packages or basename(uri)==Release:
log.msg(REGISTERING PACKAGE:+uri,'apt_pkg')
signature.asc
Description: Digital signature
Bug#193849: procmail adds a blank line at the end of forwarded mail messages
Hi, being a procmail user for quite some time, I just set up spamassassin as a procmail filter and got the same problem of an added newline at the end of (single-line) messages as described in #193849. After applying the patch proposed by Santiago Vila back in 2003 and rebuilding the procmail package locally, the problem disappeared. Personally I'd like this patch to be reconsidered for inclusion at least into the Debian version. Regards, Fabian signature.asc Description: Digital signature
Bug#193849: procmail adds a blank line at the end of forwarded mail messages
Hi, apparently I haven't been using procmail long enough. :) Using flags frw instead of fw for the spamassassin receipt sets procmail to raw mode so it doesn't append newlines. (Also documented in the procmail man page just like this... Just that spamassassin examples don't use r, so I didn't look... :/ ) So could the original reporter perhaps have fixed his forwarding problem as well with this flag? Regards, Fabian signature.asc Description: Digital signature
Bug#319506: groff-base: www.tmac missing
Package: groff-base Version: 1.18.1.1-7 Severity: normal Hi, www.tmac is included in groff, but not in groff-base. If only groff-base is installed, which was the case on my system, this leads to all uses of .URL macros being skipped in the man page output, e.g. groff(1)'s AVAILABILITY section becomes unreadable (if not useless). Regards, Fabian -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-2-k7 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages groff-base depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-13 GCC support library ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280701: Bug #280701 - uptimed: Fails to email when passing top ten record runtimes
Hello, Problem is, the test is backward - the expression should read: (!position || (position = mail_min_position) I just tried this but still not receive any mails... With uptimed-0.3.3-2, this change seems te be incorporated all the same. In a quick test with a modified records file to set an uptime record soon, everything worked just well. So should this bug perhaps be closed now? (Might #274635 be somehow related? It seems the MAIL_MINIMUM_POSITION support was added after woody; the config var is not present on that woody uptimed.conf) Regards, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#283794: cdda2wav: invalid code in cdda2mp3 caused by broken patch
Package: cdda2wav
Version: 4:2.0+a34-2
Followup-For: Bug #283794
Tags: patch
The invalid code in /usr/bin/cdda2mp3 previously reported is caused by a
broken patch in debian/patches/03_script.dpatch:
Compare the part against cdda2mp3..
snip
# specify the sampling program and its options
# do not specify the track option here!
-CDDA2WAV=cdda2wav
-CDDA2WAV_OPTS='-H -P0 -q'
+MP_CODER=${MP_CODER:-oggenc}
+MP_OPTIONS=${MP_OPTIONS:-''}
/snip
..to that against cdda2ogg:
snip
# specify the sampling program and its options
# do not specify the track option here!
-CDDA2WAV=cdda2wav
-CDDA2WAV_OPTS='-H -P0 -q'
+CDDA2WAV=${CDDA2WAV:-cdda2wav}
+CDDA2WAV_OPTS=${CDDA2WAV_OPTS:-'-H -P0 -q'}
/snip
This is most probably due to a copy paste error during patch creation.
As a result, cdda2mp3 won't run cdda2wav, provided the user hasn't
previously set $CDDA2WAV in the environment.
A patch against 03_script.dpatch is attached that also changes the
insertion ordering slightly, so that the resulting cdda2mp3/cdda2ogg
look more similar where they *are* similar. (Try diff-ing them as
they're in the final package now!)
For convenience, the resulting 03_script.dpatch is also attached.
Regards,
Fabian
P.S.: Shouldn't the $NAME part in cdda2ogg better be used in cdda2mp3, too?
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-k7
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Versions of packages cdda2wav depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
-- no debconf information
--- cdrtools-2.01+01a01/debian/patches/03_script.dpatch 2005-02-06
13:11:50.0 +0100
+++ cdrtools-2.01+01a01-modified/debian/patches/03_script.dpatch
2005-02-07 15:27:13.0 +0100
@@ -29,8 +29,8 @@
# do not specify the track option here!
-CDDA2WAV=cdda2wav
-CDDA2WAV_OPTS='-H -P0 -q'
-+MP_CODER=${MP_CODER:-oggenc}
-+MP_OPTIONS=${MP_OPTIONS:-''}
++CDDA2WAV=${CDDA2WAV:-cdda2wav}
++CDDA2WAV_OPTS=${CDDA2WAV_OPTS:-'-H -P0 -q'}
# for normal use, comment out the next line
#DEBUG='-d1'
@@ -42,20 +42,20 @@
+MP_CODER=${MP_CODER:-lame}
+MP_OPTIONS=${MP_OPTIONS:-''}
- FILEPREFIX=${1:-audiotrack}
-
-+if [ $CDDADEVICE = ]
-+then
-+ CDDA_DEVICE=/dev/cdrom
-+ export CDDA_DEVICE
-+fi
-+
+$MP_CODER -h /dev/null 21
+if [ $? != 0 ] ; then
+ echo Encoder not found. Install one first!
+ exit 1
+fi
+
++if [ $CDDADEVICE = ]
++then
++ CDDA_DEVICE=/dev/cdrom
++ export CDDA_DEVICE
++fi
++
+ FILEPREFIX=${1:-audiotrack}
+
+if [ -e /etc/default/cdda2mp3 ]; then
+ . /etc/default/cdda2mp3
+fi
@@ -97,13 +97,13 @@
+ CDDA_DEVICE=/dev/cdrom
+ export CDDA_DEVICE
+fi
++
FILEPREFIX=${1:-audiotrack}
-. /etc/default/cdda2ogg 2/dev/null || true
+if [ -e /etc/default/cdda2ogg ]; then
+ . /etc/default/cdda2ogg
+fi
-+
TRACK=1
while :
#! /bin/sh -e
## 03_script.dpatch by Joerg Jaspert [EMAIL PROTECTED]
## Original made by Eduard Bloch [EMAIL PROTECTED]
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Small patch to the cdda2mp3 script to read a default config.
if [ $# -ne 1 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
fi
case $1 in
-patch) patch -f --no-backup-if-mismatch -p1 $0;;
-unpatch) patch -f --no-backup-if-mismatch -R -p1 $0;;
*)
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1;;
esac
exit 0
@DPATCH@
diff -urNad /home/inet/cvs/cdrtools-2.0+a14/cdda2wav/cdda2mp3
cdrtools-2.0+a14/cdda2wav/cdda2mp3
--- /home/inet/cvs/cdrtools-2.0+a14/cdda2wav/cdda2mp3 2000-06-24
07:47:48.0 +0200
+++ cdrtools-2.0+a14/cdda2wav/cdda2mp3 2003-06-04 00:02:36.0 +0200
@@ -14,19 +14,35 @@
# specify the sampling program and its options
# do not specify the track option here!
-CDDA2WAV=cdda2wav
-CDDA2WAV_OPTS='-H -P0 -q'
+CDDA2WAV=${CDDA2WAV:-cdda2wav}
+CDDA2WAV_OPTS=${CDDA2WAV_OPTS:-'-H -P0 -q'}
# for normal use, comment out the next line
#DEBUG='-d1'
# the post processor is fed through a pipe to avoid space waste
# specify the post processing program and its options
-MP_CODER=lame
-#MP_OPTIONS=''
+MP_CODER=${MP_CODER:-lame}
+MP_OPTIONS=${MP_OPTIONS:-''}
+$MP_CODER -h /dev/null 21
+if [ $? != 0 ] ; then
+ echo Encoder not found. Install one first!
+ exit 1
+fi
+
+if [ $CDDADEVICE = ]
+then
+ CDDA_DEVICE=/dev/cdrom
+ export CDDA_DEVICE
+fi
+
FILEPREFIX=${1:-audiotrack}
+if [ -e /etc/default/cdda2mp3 ]; then
+ . /etc/default/cdda2mp3
+fi
+
TRACK=1
while :
do
diff -urNad /home/inet/cvs/cdrtools-2.0+a14/cdda2wav/cdda2ogg
cdrtools-2.0+a14/cdda2wav/cdda2ogg
--- /home/inet/cvs/cdrtools-2.0+a14/cdda2wav/cdda2ogg 2002-04-09
13:18:15.0 +0200
+++ cdrtools-2.0+a14/cdda2wav/cdda2ogg 2003-06-04 00:02:33.0 +0200
@@ -14,26 +14,34 @@
# specify the sampling program and its options
# do not
