Bug#303494: support for /dev/lirc0 (udev-style name)
Package: lirc
Version: 0.7.1pre2-2
Severity: normal
On my buddy's mythtv box, udev creates /dev/lirc0 when the module loads.
Currently, lirc won't work with this config out of the box. I suggest
the following:
- Add autodetect support to the initscript - see the patch below.
This patch also corrects what I think was a logic error that would cause a
user specified DEVICE name to be overridden.
- Make autodetection the default behavior. debconf currently
asks you to create static devices. With this change, debconf should instead
give the user the choices of:
1) Autodetect
2) /dev/lirc
3) User specified device
If they choose to autodetect, the DEVICE= line in hardware.conf should be
left commented out. If they choose /dev/lirc, then fall into the 'Create
/dev/lirc if necessary' prompt. If they choose user-specified, just take
whatever they enter, and warn if its non-existant.
Actually, since autodetect should work 99% of the time, it might be
more user friendly to just eliminate the other options, and let the user
edit hardware.conf, if necessary.
--- lirc.orig 2005-04-06 18:55:34.628760167 -0600
+++ lirc2005-04-06 19:09:34.025271671 -0600
@@ -28,11 +28,20 @@
build_args ()
{
local ARGS=$*
+
+ ## Try to find an lirc device.
+ ## udev uses /dev/lirc0
+ ## static dev uses /dev/lirc
+ ## devfs uses /dev/lirc/0
+ if [ -z $DEVICE ]; then
+ for dev in /dev/lirc0 /dev/lirc /dev/lirc/0; do
+ if [ -c $dev ]; then
+ DEVICE=$dev
+ break
+ fi
+ done
+ fi
if [ -n $DEVICE ] [ $DEVICE != none ]; then
- if [ -d /dev/lirc ] [ $DEVICE = /dev/lirc ];then
- #new device names
- DEVICE=/dev/lirc/0
- fi
ARGS=--device=$DEVICE $ARGS
fi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303495: openafs-modules-source: Oops on startup (2.6.12-rc2-mm1)
Package: openafs-modules-source Version: 1.3.81-2 Severity: important Kernel 2.6.12-rc2-mm1, PREEMPT OpenAFS 1.3.81 Upon load of afs: /usr/sbin/afsd -stat 300 -dcache 100 -daemons 2 -volumes 50 -dynroot -fakestat -afsdb -nosettime I immediately get this, and a hung /afs mountpoint Unable to handle kernel NULL pointer dereference at virtual address printing eip: c02d2b2a *pde = Oops: 0002 [#1] PREEMPT Modules linked in: openafs ... CPU:0 EIP:0060:[__down+90/320] Tainted: P VLI EFLAGS: 00010002 (2.6.12-rc2-mm1) EIP is at __down+0x5a/0x140 eax: ebx: e036c000 ecx: d27cc924 edx: e036cf48 esi: d27cc91c edi: 0246 ebp: e036cf68 esp: e036cf34 ds: 007b es: 007b ss: 0068 Process ls (pid: 28602, threadinfo=e036c000 task=c43ffa90) Stack: d27cc924 c43ffa90 0001 c43ffa90 c01160d0 d27cc924 c015a66d e036cf58 f35a1994 f35a1994 0003 db5eed40 e036cf78 c02d2d8e d27cc800 e036cfa0 c01837b3 ffe8 e036cfa0 0020 d27cc800 Call Trace: [show_stack+122/144] show_stack+0x7a/0x90 [show_registers+329/432] show_registers+0x149/0x1b0 [die+221/368] die+0xdd/0x170 [do_page_fault+794/1642] do_page_fault+0x31a/0x66a [error_code+79/84] error_code+0x4f/0x54 [__down_failed+10/16] __down_failed+0xa/0x10 [.text.lock.inotify+11/520] .text.lock.inotify+0xb/0x208 [sys_open+94/160] sys_open+0x5e/0xa0 [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 Code: 55 d8 c7 02 02 00 00 00 9c 5f fa b8 01 00 00 00 e8 3c 35 e4 ff 83 4d d4 01 8d 4e 08 8d 55 e0 89 4d cc 8b 41 04 89 4d e0 89 51 04 89 10 ff 46 04 89 45 e4 8d b4 26 00 00 00 00 8d bc 27 00 00 00 6note: ls[28602] exited with preempt_count 1 -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.12-rc2-mm1 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages openafs-modules-source depends on: ii bison 1:1.875d-1 A parser generator that is compati ii debhelper 4.2.32 helper programs for debian/rules ii e2fslibs-dev 1.37-1 ext2 filesystem libraries - header ii flex 2.5.31-31 A fast lexical analyzer generator. ii kernel-package8.130 A utility for building Linux kerne ii libncurses5-dev 5.4-4 Developer's libraries and docs for ii libpam0g-dev 0.76-22Development files for PAM -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300888: logcheck-database: database skip postgrey ignore pattern
tags 300888 pending
thanks
On Tue, 2005-03-22 at 17:37 +0100, Sythos wrote:
On Tue, Mar 22, 2005 at 04:01:45PM +, Jamie L. Penman-Smithson wrote:
logcheck-database contain postgrey ignore file, but postgrey first
attempt is listed in logcheck report
Can you provide the log messages that are not caught please?
Mar 22 16:43:10 vortex postfix/smtpd[19674]: NOQUEUE: reject: RCPT from
snip
I see in logcheck rules NOQUEUE should be ignored...
I've added the following rule to CVS which I've tested against the log
messages you gave me:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ postfix/smtpd\[[0-9]+\]:
[[:upper:]0-9]+: reject: RCPT from [^[:space:]]+: [45][0-9][0-9]
[^[:space:]]+: Client host rejected: Greylisted for 300 seconds \(see
http://isg.ee.ethz.ch/tools/postgrey/help/sythos.net.html\);
from=[^[:space:]]* to=[^[:space:]]+ proto=(ESMTP|SMTP)
helo=[^[:space:]]+$
If in a future version of postgrey the message changes, this rule will
need to be updated. However, this means it can be tailored more - always
good for precious system resources.
Thanks for your bug report,
--
-jamie [EMAIL PROTECTED] | spamtrap: [EMAIL PROTECTED]
w: http://www.silverdream.org | p: [EMAIL PROTECTED]
pgp key @ http://silverdream.org/~jps/pub.key
21:30:02 up 17 min, 2 users, load average: 2.65, 2.52, 1.58
signature.asc
Description: This is a digitally signed message part
Bug#303496: clamsmtp: [INTL:pt_BR] Please consider adding the attached debconf template translation
Package: clamsmtp Severity: wishlist Please consider using the attached clamsmtp Brazilian Portuguese (pt_BR) debconf template translation. It was properly checked against errors using the msgfmt utility from gettext package as can be see bellow : [EMAIL PROTECTED]:~/debian-traducoes/clamsmtp$ msgfmt -c -v -o /dev/null pt_BR.po 8 mensagens traduzidas. [EMAIL PROTECTED]:~/debian-traducoes/clamsmtp$ Also, it's bziped for size optimization. Regards, -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) pt_BR.po.bz2 Description: BZip2 compressed data
Bug#303495: [grand.central.org #18187]: OpenAFS 1.3.81: Oops on startup (2.6.12-rc2-mm1)
Cross-referencing the Debian bug and OpenAFS ticket number: Debian bug: #303495 OpenAFS Ticket: #18187 -- Rick Nelson Win 95 is simplified for the user: User: What does this configuration thing do? You: It allows you to modify you settings, for networking, hardware, protocols, ... User: Whoa! Layman's terms, please! You: It changes stuff. User: That's what I'm looking for! What can it change? You: This part change IP forwarding. It allows ... User: Simplify, simplify! What can it do for ME? You: Nothing, until you understand it. User: Well it makes me uncomfortable. It looks so technical; Get rid of it, I want a system *I* can understand. You: But... User: Hey, who's system is this anyway? You: (... rm this, rm that, rm /etc/* ...) All done. -- Kevin M. Bealer [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302948: copyright file
reopen 302948 thanks Could you also add: Upstream Author: Wilmer van der Gaast Copyright 2001 by Wilmer van der Gaast or some similar indicator that you are the upstream author as well as the Debian maintainer. Thanks, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303497: nhfsstone needs a better description
Package: nhfsstone Version: 1:1.0.7-1 Severity: minor The package description for nhfsstone is rather lacking. I suggest replacing it with something along the lines of the first paragraph under DESCRIPTION in the man page: nhfsstone (pronounced n-f-s-stone, the h is silent) is used on a NFS client to generate an artificial load with a particular mix of NFS operations. It reports the average response time of the server in mil- liseconds per call and the load in calls per second. The program adjusts its calling patterns based on the client's kernel NFS statis- tics and the elapsed time. Load can be generated over a given time or number of NFS calls. noah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281596: ppracer packages in sid
Hi! I've tried the ppracer package on AMD64 and they work great. As tuxracer is totally dead upstream and ppracer is in my eyes the proper successor, I'd like to proceed to get the current tuxracer packages removed from sarge and provide current users a transition path to ppracer. I need to recheck, but AFAIK the procedure for ppracer to superceed tuxracer is 1. Upload a ppracer package with Replace/Conflict: tuxracer 2. Afterwards, upload an empty tuxracer package with Depends: ppracer How do you feel about proceeding in this direction ? I know the time is tight to make it into sarge, but it would IMHO definetly benefit our users to have an upgrade path to an actively maintained game instead of the famous but totally outdated original tuxracer. -- Oliver M. Bolzer [EMAIL PROTECTED] GPG (PGP) Fingerprint = 621B 52F6 2AC1 36DB 8761 018F 8786 87AD EF50 D1FF signature.asc Description: Digital signature
Bug#302684: zeroconf configuration method / option?
On Wed, Apr 06, 2005 at 10:35:36AM +0100, Mark Brown wrote: On Wed, Apr 06, 2005 at 07:08:18PM +1000, Anand Kumria wrote: Yes - totally agreed, it is a bug that zeroconf currently wil attempt to assign an IPv4 link-local address to an interface with an address family of 'inet6'. That's not buggy: Yes it is, if this only existed in /etc/network/interfaces iface eth0 inet6 static [...] That is it a bug if an an IPv4 link local address appears on the eth0 interface. If there were also a line like: iface eth0 inet static *then* an IPv4 link local address should be assigned. interfaces it can (IPv6 address assignment is rather different to IPv4 so this is can sensibly be done by the kernel - there's no policy in having an ethernet link local address, for example). Actually the defense mechanism isn't so different -- just the allocation method. I've been thinking about factoring the link-local defense state machine out of the IPv6 layer in the kernel and then using it for any addresses marked as IPv4 link-local. Cheers, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
Bug#300209: tomcat4: tomcat dies with Parse error in default web.xml after upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Martin wrote: [...] This is totally independent of the contents of the web.xml file. I even exchanged the files with the contents of /usr/share/tomcat4/.debian/web.xml but to no avail. Something seams to have changed between 4.1.30 and 4.1.31 totally. This makes the package unusable for most installations. [...] Christoph, It could be that a version number needs to be added to a particular dependency. Given that numerous others including myself have upgraded to this package without the issue you describe here, filing a bug with a grave severity is a bit, well, severe on your part. Could you tell us which version of libcommons-collections-java you have installed on this machine? On my powerpc sid install, I currently have: $ dpkg -l libcommons-collections-java Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libcommons-col 2.1.1-3A set of abstract data type interfaces and i This parse error seems to be only for the web.xml inside your application that has the context /hisqis/qisserver. Swapping it out with the sample web.xml is /usr/share/tomcat4/.debian is not necessarily an effective test. Are any of the other web applications the only one running on the tomcat instance in question? If not, how does the web.xml of working applications differ from this one? Also, if it is the only one, could you include its contents here, provided that nothing sensitive is contained within the file? We really need more information to pursue the remedy of this bug. Also, if anything has changed regarding the status of this bug and the problem you were experiencing, please update it on the bug report. This report seems to have knocked tomcat4 out of testing and therefore has jeopardized whether or not a Tomcat 4 server will be included in the imminent Sarge release. Regards, - -- Barry Hawkins All Things Computed site: www.alltc.com weblog: www.yepthatsme.com Registered Linux User #368650 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCVKEQHuKcDICy0QoRAuBLAJ9jSfKUyxl57GFnilO3+K2TsFsSNgCfZ5Gk ljAjE5FfLd+ctO0zo7JCMIg= =hxTr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303499: subversion won't start with xinetd
Package: subversion Version: 1.1.3-3 The latest subversion will not start using xinetd. I get the following message in /var/log/daemon.log: Apr 6 22:47:24 k2 xinetd[26132]: Port not specified and can't find service: svnserve with getservbyname The previous version was working without issues. This very well could be a xinetd problem, I'm not sure. Jiann-Ming Su Yeah, Lois, that'll be about as much fun as a lecture on ontological empiricism. --Peter Griffin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303498: CAN-2005-0749: Elf Binary Loading Local DoS
Package: kernel-source-2.6.8 Version: 2.6.8-15 Severity: important SecurityFocus http://www.securityfocus.com/bid/12935/discussion/ has the following: It is reported that issue exists in the 'load_elf_library' function. Linux Kernel 2.6.11.5 and prior versions are affected by this issue. Ubuntu mentions this issue as part of USN-103-1, and it's fixed in 2.6.11.6 The patch from 2.6.11.5 to 2.6.11.6 for the load_elf_library is here: http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Fincr%2Fpatch-2.6.11.5-6.bz2;z=2 The changelog for that change says in relation: From: Herbert Xu [EMAIL PROTECTED] Yichen Xie [EMAIL PROTECTED] points out that load_elf_library can modify `elf_phdata' before freeing it. I'm not enough of a programmer to prepare a diff for the 2.6.8 source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303360: bittornado: please enable psyco support in the package
tag 303360 +pending thanks I'll add a patch that enables psyco support if it exists, and change the package to Suggest: python-psyco. I wont Depend on it because psyco is i386 only, and until there are architecture specific Depends support in dpkg, I would rather bittornado be available for all architectures, rather than just i386. On Wed, 06 Apr 2005, Pierre Habouzit wrote: maybe /usr/lib/python2.3/site-packages/BitTornado/PSYCO.py could e.g. be : try import psyco psyco = 1 except: psyco = 0 This is probably what I'll do, except that the try requires a colon after it. or sth more subtle like : from BittornadoConf import enable_psycho psyco = enable_psycho with BittornadoConf beeing a module in /etc/bittornado (see how mailman does this with mm_cfg.py) If you submit a patch that does this, I'll consider it. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303501: CAN-2005-0750: Bluetooth root exploit due to boundary checking
Package: kernel-source-2.6.8 Version: 2.6.8-15 Severity: critical Justification: root security hole USN-103-1 says this: Ilja van Sprundel discovered that the bluez_sock_create() function did not check its protocol argument for negative values. A local attacker could exploit this to execute arbitrary code with root privileges by creating a Bluetooth socket with a specially crafted protocol number. (CAN-2005-0750) It's fixed in 2.6.11.6, and the relevant diff can be seen: http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Fincr%2Fpatch-2.6.11.5-6.bz2;z=6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303499: Acknowledgement (subversion won't start with xinetd)
Nevermind, the service name has to be subversion. In the previous version of subversion or xinetd, this was not the case. I was able to get away with svnserve as the service name. Jiann-Ming Su Yeah, Lois, that'll be about as much fun as a lecture on ontological empiricism. --Peter Griffin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300209: tomcat4: tomcat dies with Parse error in default web.xml after upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Hawkins wrote: [...] Could you tell us which version of libcommons-collections-java you have installed on this machine? On my powerpc sid install, I currently have: $ dpkg -l libcommons-collections-java Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libcommons-col 2.1.1-3A set of abstract data type interfaces and i [...] One other thought regarding libraries; what libraries are in this particular web application's /WEB-INF/lib folder? Thanks, - -- Barry Hawkins All Things Computed site: www.alltc.com weblog: www.yepthatsme.com Registered Linux User #368650 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCVKaxHuKcDICy0QoRAoiNAKDS+mUuBWEsB8w2JRcRSTaJKAyQbwCdEsZH 6V9aSAWBXTmVDKWAEyAnXns= =amNk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303502: leafpad: in replace dialog, esc key works as 'yes'
Package: leafpad Version: 0.7.9-4 Severity: normal In the replace dialog, the esc key behaves counter-intuitively by replacing the next occurence, as if 'yes' had been pressed. Esc should probably translate into 'cancel' or at least 'no'. In line 128 of search.c, the value from the dialog is compared against GTK_RESPONSE_CANCEL and GTK_RESPONSE_NO, anything else taken as 'yes'. Simply handling GTK_RESPONSE_DELETE_EVENT (what pressing esc returns) as 'cancel' fixes the problem. A quick search suggests there are flags to tell the dialog to return 'cancel' for the esc key, which might be a more proper way to do it. Or maybe only replacing on a specific GTK_RESPONSE_YES. Thanks. Philippe -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10bp0 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages leafpad depends on: hi libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libglib2.0-02.6.3-1 The GLib library of C routines ii libgtk2.0-0 2.6.2-4 The GTK+ graphical user interface ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303503: snes9x: error while loading shared libraries: libXxf86dga.so.1: cannot open shared object file: No such file or directory
Package: snes9x-x Version: 1.42-2 Severity: important No matter how I try to invoke it, I always get: snes9x: error while loading shared libraries: libXxf86dga.so.1: cannot open shared object file: No such file or directory However, auto-apt can't find libXxf86dga.so.1 and the packages snes9x-x depends on don't contain it either. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (700, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11-rc2 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages snes9x-x depends on: hi libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-12 GCC support library ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-12.0.1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous exte ii snes9x-common1.42-2 Common files for snes9x ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302988: IBM Thinkpad T43 hardware detection incomplete
On Wed, Apr 06, 2005 at 11:40:57AM +0200, Gaudenz Steinlin wrote:
On Wed, Apr 06, 2005 at 07:16:09AM +0200, Christian Perrier wrote:
Actually, I think that it is ata_piix. I am attaching my working
2.6.11.5 kernel config and the output of lsmod. I am not using an
initrd image. However, if I modprobe ata_piix and sd_mod, the
installer still does not find the hard drive. I don't find any
entries in /dev/scsi either. It does not help to modprobe all of the
other sata_* modules either.
So, loading ata_piix should be the Right Way for discover when finding
your SATA chipset but what you say it that this is not enough with the
D-I kernel, right??
So, this problem is dual:
-discover needs to load the correct module?: easy to fix in pci.lst
I've added the missing information to pci.lst.
-the kernel module must properly handle your hardware?: not easy to
fix if this fails with the current 2.6.8-2 kernel we have in D-I
For everyone reading this?: is this the correct conclusion?
I think this conculsion is correct. Horm: Is there any need to reassign
this bug to the kernel (if yes which package?)?
The only problem reported in this bug not yet solved is the second
network card:
:04:02.0 0280: 8086:4224 (rev 05)
:04:02.0 Network controller: Intel Corp.: Unknown device 4224 (rev 05)
If you want to reassign this bug to the kernel, I'd assign it
to kernel-source-2.6.8. Actually, I think there is already
a bug there relating to this, and I would be interested in someone
testing the attached patches (applogies if you have seen these before,
a problem a lot like this is being discussed in a couple of places)
though I don't think they have much chance of making it into Sarge.
--
Horms
# origin: bzolnier (BitKeeper)
# cset: 1.1938.134.1 (2.6) key=416b214bV7CwIRgRqoomLi6qTfcGmw
# URL: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]
# inclusion: upstream
# descrition: [PATCH] libata: PCI IDE legacy mode fix
# revision date: Wed, 06 Apr 2005 17:25:20 +0900
#
# S rset: ChangeSet|1.1938.132.2..1.1938.134.1
# I rset: drivers/scsi/libata-core.c|1.100..1.101
# I rset: include/linux/libata.h|1.55..1.56
# I rset: drivers/scsi/ata_piix.c|1.31..1.32
#
# Key:
# S: Skipped ChangeSet file only
# O: Original Followed by Updated
# U: Updated Included with updated range of versions
# I: Included Included verbatim
# E: Excluded Excluded on request from user
# D: Deleted Manually deleted by subsequent user edit
# R: Revised Manually revised by subsequent user edit
#
#
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/10/11 20:11:55-04:00 [EMAIL PROTECTED]
# [PATCH] libata: PCI IDE legacy mode fix
#
# In PCI IDE legacy mode ap-port_no is incorrectly set to zero for
# the second port. Fix it by adding -hard_port_no to struct ata_probe_ent
# and struct ata_port (per Jeff's suggestion) and teaching ata_piix.c
# to use it instead of -port_no.
#
# Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
#
# include/linux/libata.h
# 2004/10/11 15:52:22-04:00 [EMAIL PROTECTED] +2 -0
# PCI IDE legacy mode fix
#
# drivers/scsi/libata-core.c
# 2004/10/11 15:52:22-04:00 [EMAIL PROTECTED] +8 -0
# PCI IDE legacy mode fix
#
# drivers/scsi/ata_piix.c
# 2004/10/11 15:52:22-04:00 [EMAIL PROTECTED] +10 -10
# PCI IDE legacy mode fix
#
#
= drivers/scsi/libata-core.c 1.100 vs 1.101 =
--- 1.100/drivers/scsi/libata-core.c2004-09-16 15:45:15 +09:00
+++ 1.101/drivers/scsi/libata-core.c2004-10-12 04:52:22 +09:00
@@ -3032,6 +3032,8 @@ static void ata_host_init(struct ata_por
ap-ctl = ATA_DEVCTL_OBS;
ap-host_set = host_set;
ap-port_no = port_no;
+ ap-hard_port_no =
+ ent-legacy_mode ? ent-hard_port_no : port_no;
ap-pio_mask = ent-pio_mask;
ap-mwdma_mask = ent-mwdma_mask;
ap-udma_mask = ent-udma_mask;
@@ -3338,8 +3340,14 @@ ata_pci_init_legacy_mode(struct pci_dev
probe_ent[0].n_ports = 1;
probe_ent[0].irq = 14;
+ probe_ent[0].hard_port_no = 0;
+ probe_ent[0].legacy_mode = 1;
+
probe_ent[1].n_ports = 1;
probe_ent[1].irq = 15;
+
+ probe_ent[1].hard_port_no = 1;
+ probe_ent[1].legacy_mode = 1;
probe_ent[0].port[0].cmd_addr = 0x1f0;
probe_ent[0].port[0].altstatus_addr =
= include/linux/libata.h 1.55 vs 1.56 =
--- 1.55/include/linux/libata.h 2004-09-16 15:45:15 +09:00
+++ 1.56/include/linux/libata.h 2004-10-12 04:52:22 +09:00
@@ -189,6 +189,7 @@ struct ata_probe_ent {
Scsi_Host_Template *sht;
struct ata_ioports port[ATA_MAX_PORTS];
unsigned intn_ports;
+ unsigned inthard_port_no;
unsigned intpio_mask;
unsigned intmwdma_mask;
unsigned intudma_mask;
@@ -273,6 +274,7 @@ struct ata_port {
unsigned long flags; /*
Bug#303504: libbow install-info call typo
Package: libbow Version: 20020213-7 On upgrading libbow I get the following: Setting up libbow (20020213-7) ... install-info: unknown option `---quiet' usage: install-info [--version] [--help] [--debug] [--maxwidth=nnn] [--section regexp title] [--infodir=xxx] [--align=nnn] [--calign=nnn] [--quiet] [--menuentry=xxx] [--info-dir=xxx] [--keep-old] [--description=xxx] [--test] [--remove | --remove-exactly ] [--dir-file] [--] filename It's a simple typo of the --quiet option. Cheers, -- Matt pgphGSdysiRb5.pgp Description: PGP signature
Bug#303505: openldap2.2: [INTL:ja] update Japanese debconf translation
Package: openldap2.2 Severity: wishlist Hi, I updated Japanese translation of debconf messages (ja.po). Please apply this. Thanks, -- Kenshi Muto [EMAIL PROTECTED] ja.po.gz Description: Binary data
Bug#295422: e2fsprogs for Sarge
Hi Ted, I hope that all is well. I am writing to you about an old problem with the e2fsprogs that has unfortunately resurfaced in testing and I am looking for some advice on the best way forward. In a nutshell the problem is bug 295422. You fixed this in e2fsprogs 0.35-7, a versioned dependancy was added to kernel-image-amd64 2.6.8-12 and the bug was closed. So far, so good. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295422 Unfortunately the version of kernel-image-amd64 in testing is 2.6.8-11, so the versioned dependancy is not there. We also have e2fsprogs 0.35-6 in testing, which means that bug 295422 manifests in testing. Normally this would just be a matter of waiting for the new versions to filter down to testing, but as part of the attempts to get sarge released, testing was fozen a little while ago, so changes aren't propogating, while unstable marches on (bit of a process problem is an understatement, but lets save that discussion for another day). The real problem for Debian is that we need a to update e2fsprogs in testing, but we are unsure of the best version to use. I notice that the version in testing is quite a lot newer, e2fsprogs 1.37-1. This presents two issues, firstly I've been advised by Steve Langasek that small incremental changes are quite desirable at this point. And secondly, there is a pending issue with e2fsprogs 1.37-1 wherby mke2fs fails on ia64, bug 302200. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302200 In short, we are looking for your advice on which version of e2fsprogs to include in sarge. My understanding is that appart from this issue, 0.35-6 seems to be quite fine. Here are some ideas that I have. I am not sure of the versining gymnastics that need to occur to make this happen, perhaps none, Steve Langasek can advise. * Inculde 0.35-7 verbatim in sarge * Include 0.35-8 verbatim in sarge * Include 0.35-6 + just the fix for 302200 in sarge * Include 1.37-2 (as yet unreleased) in sarge this would require some considerable review and is thus likely the slowest option. You probably have other ideas, which is why we are here. Best wishes -- Horms Appendix For reference, so everything is in one place, Testing has kernel-image-2.6.8-amd64 2.6.8-11 which is built against kernel-tree-2.6.8-13 which is also in testing. Unstable has kernel-image-2.6.8-amd64 2.6.8-12 which is built against kernel-tree-2.6.8-14 which is not available in testing. And before you ask, ues this packaging is going to be unified, but much to some people's chagirn, probably not until after sarge (we are frozen, right?). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301123: gaim-extendedprefs: Shrink below normal size does not work
On 24 Mar 2005, Arjan Oosting [EMAIL PROTECTED] wrote: I have looked at the source code of gaim-extendedprefs and it only set the GTK property allow_shrink, thus it is an interaction bug of libgtk2.0-0 and sawfish. Furthermore resizing horizontal/vertical below the normal size is still possible if you first re-size vertical/horizontal respectively. So I will reassign this bug to libgtk2.0-0. Thanks for your work on this. I just did some further testing to find out why the workaround you suggested does not work for me. When I start my X session with xfce4 and then replace xfwm4 by sawfish, your trick works, but if I start my session with sawfish from the very beginning, even this does not work. I assume that xfce probably does some gtk magic at startup that sawfish fails to do, but unfortunately I don't know enough about these things to look at this in further detail. Thanks, Philipp -- Philipp Weis[EMAIL PROTECTED]http://pweis.com/ signature.asc Description: Digital signature
Bug#302684: zeroconf configuration method / option?
On Wed, Apr 06, 2005 at 11:04:25AM +0100, Mark Brown wrote: On Wed, Apr 06, 2005 at 07:06:21PM +1000, Anand Kumria wrote: On Sun, Apr 03, 2005 at 03:28:24PM +0100, Mark Brown wrote: It would be helpful if the program were to monitor the configuration of the interface and only bring up a zeroconf address in the absence of any other configuration (though if it were to do this it ought to look out It is explicitly okay to have an interface with both a IPv4 routable address and an IPv4 link-local It is possible but this behaviour is discouraged: the main reason for doing it is when failing over from a zeroconf address to an allocated one (for example, when a DHCP server becomes avaliable). I do believe the RFC recommends this behaviour and it's mostly how the Apple and Microsoft implementations appear to behave (see the appendix in the RFC). Actually I read it entirely the other way -- the RFC recommends *against* doing it the way that has been done on these platforms. Because of this I do feel allocating an address when another is present ought to be at most optional behaviour. Hmm, I'll have a think about how to make that something that can be tweaked. Allocating a route without an address is more useful since it allows communication with zeroconfed devices even when the system is explicitly configured (for example, statically) so I can see that usefully being done separately. Perhaps as another option, perhaps non-optionally. I'll certainly keep that in mind. If you know of any way I can programatically determine whether a specific interface will use ARP to do hardware - IP address resoultion, I'm certainly interested. You can determine the link type of the interface from the kernel (it is displayed as link/ether or whatever by 'ip link') and select specific interface types you know do ARP. That's not 100% ideal but it does appear from a brief glance to be what the kernel is doing internally so if it's good enough for the kernel I'd say it's good enough for zeroconf too :) . That was pretty much what I had concluded as well. Thanks for the info. Cheers, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
Bug#303506: whizzytex: Please include upstream changelog.
Package: whizzytex Version: 1.2.2-1 Severity: wishlist Hi Junichi, including the upstream changelog in /usr/share/doc/whizzytex would be quite helpful. This seems to be standard for all packages I looked at so far. The upstream changelog is at http://pauillac.inria.fr/whizzytex/CHANGES -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (600, 'unstable'), (570, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages whizzytex depends on: ii advi 1.6.0-4a DVI previewer and presenter writ ii emacs21 [emacsen] 21.4a-1The GNU Emacs editor ii gv1:3.6.1-10 PostScript and PDF viewer for X ii tetex-bin [xdvi] 2.0.2-28 The teTeX binary files -- no debconf information -- Philipp Weis[EMAIL PROTECTED]http://pweis.com/ signature.asc Description: Digital signature
Bug#303507: qemu-make-debian-root usage error
Package: qemu Version: 0.6.1-1 Severity: minor Tags: patch Running qemu-make-debian-root with the incorrect number of arguments outputs a usage statement: Usage: %s [-k] size-in-MB distrib deburl image [files_to_copy_in_/root] eg %s 150 sid http://proxy:1/debian qemu This probably shouldn't read %s, but instead the command called, the attached patch fixes this. Micah -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages qemu depends on: ii bochsbios 2.1.1+20041109-3 BIOS for the Bochs emulator ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-4.1 Simple DirectMedia Layer ii sharutils 1:4.2.1-13 shar, unshar, uuencode, uudecode ii vgabios 0.4c+20041014-1VGA BIOS software for the Bochs an ii zlib1g1:1.2.2-4 compression library - runtime -- no debconf information --- /tmp/qemu-make-debian-root 2005-04-06 23:10:35.332746032 -0500 +++ /usr/sbin/qemu-make-debian-root 2005-04-06 23:09:48.839814032 -0500 @@ -9,7 +9,7 @@ fi if [ $# -lt 4 ]; then -echo Usage: %s [-k] size-in-MB distrib deburl image [files_to_copy_in_/root] 2 +echo Usage: $0 [-k] size-in-MB distrib deburl image [files_to_copy_in_/root] 2 echo eg %s 150 sid http://proxy:1/debian qemu 2 exit 1 fi
Bug#185685: netatalk: Write access required to .AppleDB even for read-only connections
Package: netatalk Version: 2.0.2-3 Followup-For: Bug #185685 Additional Information: Technically, world write access to .AppleDB was not needed. All users who will be using the share need write access to .AppleDB and the files it contains. It is sufficient to create a 'share' group containing all users you wish to give access, and set group read+write+sticky on .AppleDB and give group read+write to all files beneath it. For a bit on concealment, .AppleDB can be moved from the root of the share by setting dbpath in AppleVolumes.default explicitly to a hidden directory. # mkdir /var/hidden # chmod 700 /var/hidden dbpath:/var/local/hidden/.AppleDB/ Additional information can be had from the FAQ on http://netatalk.sourceforge.net/ http://netatalk.sourceforge.net/wiki/index.php/SpecialFilesFolders?PHPSESSID=3f04cf483b415d82f4de062091baf087 * * * * * Actually, with some minor tweaking to the package it looks like this bug could be closed now. If the rc netatalk script is modified to start the cnid_metad process and if the AppleVolumes.default share uses the dbd back end like this: /home/test test cnidscheme:dbd Then the .AppleDB directory will be created root.root 755, or what every you have your umask set to. * * * * * P.S. I'm trying to become a developer, so any suggestion or council are gladly received. -Sam George -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages netatalk depends on: ii cracklib2 2.7-15 A pro-active password checker libr ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libcupsys2-gnutls10 1.1.23-7 Common UNIX Printing System(tm) - ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [ ii libgssapi1-heimdal 0.6.3-8 Libraries for Heimdal Kerberos ii libpam-modules 0.76-22 Pluggable Authentication Modules f ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g0.76-22 Pluggable Authentication Modules l ii libslp1 1.0.11a-2OpenSLP libraries ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra ii netbase 4.20 Basic TCP/IP networking system ii perl5.8.4-6 Larry Wall's Practical Extraction -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301758: gnunet-check segfaults
Hi Arnaud, On 04 Apr 2005, Arnaud Kyheng [EMAIL PROTECTED] wrote: Are you using the init script to start the gnunet daemon ? (/etc/init.d/gnunet start) Could you check the /var/log/gnunet and /var/lib/GNUnet access right ? It should have read write access for the gnunet user. Thanks, this was the problem that prevented GNUnet from starting up correctly. All files in /srv/GNUnet/data/afs/content were owned by root instead of gnunet. Nevertheless, gnunet-check still segfaults as described in my original message. -- Philipp Weis[EMAIL PROTECTED]http://pweis.com/ signature.asc Description: Digital signature
Bug#301758: gnunet-check segfaults
On 07 Apr 2005, Philipp Weis [EMAIL PROTECTED] wrote: On 04 Apr 2005, Arnaud Kyheng [EMAIL PROTECTED] wrote: Are you using the init script to start the gnunet daemon ? (/etc/init.d/gnunet start) Could you check the /var/log/gnunet and /var/lib/GNUnet access right ? It should have read write access for the gnunet user. Thanks, this was the problem that prevented GNUnet from starting up correctly. All files in /srv/GNUnet/data/afs/content were owned by root instead of gnunet. Hm, it seems as if this was not the problem at all. There was some GNUnet traffic on the network after startup, but within a few minutes the daemon disappeared again. Nothing got written to the logfile, although the permissions are set correctly. Strange. I attached my config file, maybe this could help to nail down the problem. -- Philipp Weis[EMAIL PROTECTED]http://pweis.com/ # This is the configuration for the GNUnet daemon, gnunetd. # Copy this file to /etc/gnunet.conf if you are root. # For any other location, you must explicitly tell gnunetd # where this file is (option -c FILENAME). # # After any change in this file, you may want to manually restart # gnunetd since some changes are only recognized after a re-start. # Sending a SIGHUP to gnunetd will trigger re-reading the following # options: # NETWORK: HELOEXCHANGE # GNUNETD: LOGLEVEL # LOAD: INTERFACES # LOAD: BASICLIMITING # LOAD: MAXNETDOWNBPSTOTAL # LOAD: MAXNETUPBPSTOTAL # LOAD: MAXCPULOAD # # # This file is structured as follows. # 1) GNUNETD_HOME - base directory for all GNUnet files # 2) gnunetd options (which transport and application services, logging) # 3) network configuration # 4) load management (resource limitations) # 5) UDP, TCP and SMTP transport configuration # 6) configuration for anonymous file sharing (AFS) # # # # This line gives the root-directory of the GNUnet installation. Make # sure there is some space left in that directory. :-) Users inserting # or indexing files will be able to store data in this directory # up to the (global) quota specified below. Having a few gigabytes # of free space is recommended. # GNUNETD_HOME = /srv/GNUnet # # Options for the GNUnet server, gnunetd # [GNUNETD] # How many minutes is the current IP valid? (GNUnet will sign HELO # messages with this expiration timeline. If you are on dialup, 60 # (for 1 hour) is suggested. If you are having a static IP address, # you may want to set this to a large value (say 14400). The default # is 1440 (1 day). If your IP changes periodically, you will want to # choose the expiration to be smaller than the frequency with which # your IP changes. # The largest legal value is 14400 (10 days). # Default: HELOEXPIRES = 1440 HELOEXPIRES = 1440 # Loglevel, how much should be logged? You can use NOTHING, FATAL, # ERROR, FAILURE, WARNING, MESSAGE, INFO, DEBUG, CRON or EVERYTHING # (which log more and more messages in this order). Default is # WARNING. LOGLEVEL= WARNING # In which file should gnunetd write the logs? If you specify # nothing, logs are written to stderr (and note that if gnunetd runs # in the background, stderr is closed and all logs are discarded). # Default: LOGFILE = /var/log/gnunetd/gnunetd.log # Do not change this unless you know exactly what you're doing. # Changing this value alone, will break the package. LOGFILE = /var/log/gnunetd/gnunetd.log # In which file should gnunetd write the process-id of the server? If # you run gnunetd as root, you may want to choose # /var/run/gnunetd.pid. It's not the default since gnunetd may not # have write rights at that location. # Default: PIDFILE = /var/run/gnunetd/gnunetd.pid # Do not change this unless you know exactly what you're doing. # Changing this value alone, will break the package. PIDFILE = /var/run/gnunetd/gnunetd.pid # This directory should be made available periodically --- it contains # information how to join GNUnet that is in no way private to the # local node. This directory can be shared between nodes AND should # be put on a public web-server (if possible). You should find a list # of known hosts under http://www.ovmj.org/GNUnet/hosts/, you can copy # those files into this directory. # # If you specify a HOSTLISTURL, the directory will be automatically # populated by gnunetd with an initial set of nodes. # Default: HOSTS= $GNUNETD_HOME/data/hosts/ HOSTS = $GNUNETD_HOME/data/hosts/ # GNUnet can automatically update the hostlist from the web. While # GNUnet internally communicates which hosts are online, it is # typically a good idea to get a fresh hostlist whenever gnunetd # starts from the WEB. By setting this option, you can specify from # which server gnunetd should try to download the hostlist. The # default should be fine for now. # # The general format is a list of
Bug#303508: pinentry-qt: Hangs when pressing Menu key then Esc
Package: pinentry-qt Version: 0.7.2-1 Severity: normal Good morning, To reproduce this bug, you must have a keyboard with a Menu key (or some other key, I suppose) that is mapped to open a context menu. I believe this is the default mapping for this key, if you have it. (On my keyboard, the Menu key is between the right Logo key and the right Ctrl key.) 1. from a terminal, run pinentry-qt 2. type getpinEnter (a pin entry dialog box should appear) 3. in the dialog box, press the Menu key (a context menu should appear) 4. press Esc At this point, the dialog box will dissappear, but no response will be returned to the terminal. (If you omit step 3, you will get the response ERR 111 canceled, which is what we want.) This bug manifested itself to me as kmail hanging after I accidentally mistyped my passphrase (by hitting the Menu key instead of Shift, which is right above it) and then hitting Esc to get a fresh start. At this point the context menu was showing, and it hung as described, and kmail hung too because it was still waiting for a response. (Note that if you get the context menu for the line edit using the right mouse button instead of the Menu key, this bug does not appear.) Also, other apps that use a line edit do not behave this way; for example, to see the expected behaviour, do this: 1. run kdialog --inputbox test 2. follow steps 3-4 above Cheers, nate -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages pinentry-qt depends on: ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-12 GCC support library ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libqt3c102-mt3:3.3.3-8 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management ii libstdc++5 1:3.3.5-12 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-12.0.1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous exte ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286698: Debian bug 286698 : Please open a different bug
Ossama, please open a different bug report instead of adding to this different one, after making sure that you have nvidia-glx installed (and maybe up-to-date). Thanks, Filipus Klutiero -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303509: /usr/sbin/filefrag: filefrag does not work on other filesystems
Package: e2fsprogs Version: 1.35-6 Severity: minor File: /usr/sbin/filefrag despite the manpage claiming so, filefrag does not work on other filesystems unless they implement a ext3(?)-specific ioctl: $ filefrag /fs/dosc/temp/* EXT3_IOC_GETFLAGS: Inappropriate ioctl for device EXT3_IOC_GETFLAGS: Inappropriate ioctl for device ... /fs/dosc is a vfat filesystem that supports FIGETBSZ and FIBMAP. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (700, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11-rc2 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages e2fsprogs depends on: ii e2fslibs1.35-6 The EXT2 filesystem libraries ii libblkid1 1.35-6 Block device id library hi libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libcomerr2 1.35-6 The Common Error Description libra ii libss2 1.35-6 Command-line interface parsing lib ii libuuid11.35-6 Universally unique id library -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303510: d-i install report
Package: installation-reports INSTALL REPORT Debian-installer-version: 20050406 from http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/i386/rc3/sarge-i386-netinst.iso uname -a: Linux matthew 2.6.8-2-386 #1 Mon Jan 24 03:01:58 EST 2005 i686 GNU/Linux Date: 20050406 @ 16:00 GMT Method: I installed from a local partial mirror located on an external USB hard rive. I booted directly from the install CD. Machine: Gateway GP7-450 Processor: Pentium III (Katmai) Memory: 128 MB SDRAM Root Device: IDE - /dev/hda - Maxtor 9102404-(PM) Root Size/partition table: # fdisk -l Disk /dev/hda: 10.2 GB, 10239860736 bytes 255 heads, 63 sectors/track, 1244 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 1 31 248976 82 Linux swap /dev/hda2 * 32 47 128520 83 Linux /dev/hda3 48 109 498015 83 Linux /dev/hda4 1101244 9116887+ 8e Linux LVM hda2 is /boot and hda3 is / # vgdisplay -v Finding all volume groups Finding volume group vg00 --- Volume group --- VG Name vg00 System ID Formatlvm2 Metadata Areas1 Metadata Sequence No 8 VG Access read/write VG Status resizable MAX LV0 Cur LV5 Open LV 5 Max PV0 Cur PV1 Act PV1 VG Size 8.69 GB PE Size 4.00 MB Total PE 2225 Alloc PE / Size 2048 / 8.00 GB Free PE / Size 177 / 708.00 MB VG UUID JMwLfq-s6Yp-jTSA-8BG9-nd4F-fjYu-kiA1kv --- Logical volume --- LV Name/dev/vg00/usr VG Namevg00 LV UUIDx26xFI-wo6x-pQQk-q1UR-WRSm-KZRZ-qScAlf LV Write Accessread/write LV Status available # open 1 LV Size3.00 GB Current LE 768 Segments 1 Allocation inherit Read ahead sectors 0 Block device 254:0 --- Logical volume --- LV Name/dev/vg00/opt VG Namevg00 LV UUIDseZ8kh-e4gJ-IzVl-JepF-OBrR-DrVs-Ge3ZV4 LV Write Accessread/write LV Status available # open 1 LV Size1.00 GB Current LE 256 Segments 1 Allocation inherit Read ahead sectors 0 Block device 254:1 --- Logical volume --- LV Name/dev/vg00/var VG Namevg00 LV UUID3OqRWb-W6K0-kZrI-sqyf-EPDV-ITn4-E7Dlqj LV Write Accessread/write LV Status available # open 1 LV Size2.00 GB Current LE 512 Segments 1 Allocation inherit Read ahead sectors 0 Block device 254:2 --- Logical volume --- LV Name/dev/vg00/local VG Namevg00 LV UUIDh7jQkq-hyRq-lKR5-EdVK-1BLe-PWAL-Od8kgA LV Write Accessread/write LV Status available # open 1 LV Size1.00 GB Current LE 256 Segments 1 Allocation inherit Read ahead sectors 0 Block device 254:3 --- Logical volume --- LV Name/dev/vg00/home VG Namevg00 LV UUIDWiOHQA-cn1I-M8xf-w5Kk-2KRq-iLtl-SD6BGd LV Write Accessread/write LV Status available # open 1 LV Size1.00 GB Current LE 256 Segments 1 Allocation inherit Read ahead sectors 0 Block device 254:4 --- Physical volumes --- PV Name /dev/hda4 PV UUID ecZpSi-Up5E-1FiH-YTgV-l03q-7p7S-J5rZ2Y PV Status allocatable Total PE / Free PE2225 / 177 Output of lspci and lspci -n: # lspci :00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) :00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) :00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) :00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) :00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) :00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) :00:0e.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) :00:10.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) :01:00.0 VGA compatible controller: nVidia Corporation NV4 [RIVA TNT] (rev 04) # lspci -n :00:00.0 0600: 8086:7190 (rev 03) :00:01.0 0604: 8086:7191 (rev 03) :00:07.0 0601: 8086:7110 (rev 02
Bug#303507: Previous patch incomplete
Please use the attached patch as a reference instead. Micah --- /tmp/qemu-make-debian-root 2005-04-06 23:10:35.332746032 -0500 +++ /usr/sbin/qemu-make-debian-root 2005-04-06 23:15:01.022355072 -0500 @@ -9,8 +9,8 @@ fi if [ $# -lt 4 ]; then -echo Usage: %s [-k] size-in-MB distrib deburl image [files_to_copy_in_/root] 2 -echo eg %s 150 sid http://proxy:1/debian qemu 2 +echo Usage: $0 [-k] size-in-MB distrib deburl image [files_to_copy_in_/root] 2 +echo eg $0 150 sid http://proxy:1/debian qemu 2 exit 1 fi
Bug#303178: faqomatic: Maintenance job fails for multiple foms
Hello,
root wrote:
The current maintenance job design fails completely when the fom data is
not in the default directory, which is unavoidable when you have more
than one fom running.
I am sorry for the frustrating troubles you have been experiencing. I
test all changes but I cannot emulate all possible configurations.
Multi FOM's is outside the scope of what I test, though I will now add
it to the battery. I would like to point out that you are running
testing/unstable and with that choice, you do expose yourself to the
first round of changes made to a package; which is very much
appreciated.
Furthermore, as far as I can tell, there was NO WARNING WHATSOEVER that
you were about to break our setup. There certainly is no NEWS file.
The change was made in 2.721-1, on Dec. 15, 2004 and is clearly
mentioned in the changelog:
* Reworked installer to write configuration parameters for cron
maintenance job to a file instead of writing the actual job to
www-data's crontab. The maintenance job is now installed by dpkg
into /etc/cron.d/faqomatic (closes: #271776).
It is also detailed in README.Debian:
The cron maintenance job seems different that the normal FOM setup,
what's the deal?
It is slightly different. Rather than having the FOM configuration
mechanism install a job directly into www-data's crontab, it now
writes parameters to /var/lib/fom/meta/maintenance_job_conf. This
file inturn is used by the maintenance job in /etc/cron.d/faqomatic.
I do it this way so that the cron job can be treated as a conf file.
...though upon further consideration, I agree that this change would
warrant an entry in the NEWS.Debian file. I will create one and
include it in the 2.721-5 release.
You did not even remove the old cron job.
This is incorrect. The initial job is removed from www-data's
crontab. Actually, the removal is a spot heavy handed and pulls out
anything that even looks like a FOM maintenance job, I am surprised
that you have ANY FOM jobs left in www-data's crontab.
At least that's how it works on my system. If you find that your
experience is different, please let me know as I would like to correct
any over-sites in the packages upgrade path. As I said, I never
tested it with multiple FOM's, so I can't claim familiarity with the
details of that configuration.
Please immediately restore the previous behaviour. At least that worked.
Now we get to the heart of the matter. My changes do indeed break the
maintenance process when users hack their setup to run multiple FOM's,
which is a very reasonable change to make and should be accomodated.
To that end, I have changed the setup a bit and you can now create
multiple jobs for whichever FOM's you would like. Simply create
additional maintenance job conf files or have the installer do it.
Then add additional crontab entries wherever you like, passing the
different conf files you just created, in the cron job's invocation of
the maintenance routine. I will document all this in the new package
but it's pretty straight forward.
It takes a little while for my sponsor to check over packages and
upload them, so since you are in a rush and I would very much like to
remedy the troubles you are experiencing, you can retrieve the new
package from here sometime tomorrow:
http://zoion.net/~jereme/debian/faqomatic/faqomatic_2.721-5_all.deb
However, the change is small, you can just apply the attached patch.
Then make sure you have created the config files for each FOM's
maintenance job and add cron entries akin to /etc/cron.d/faqomatic but
suppling a conf file parameter:
28 * * * * www-data test -f /var/lib/fom/meta/maintenance_job_conf \
test -f /usr/share/perl5/FAQ/OMatic/Debian.pm perl \
-wMFAQ::OMatic::Debian -e 'maintenance_job(/my/other/fom/maint_job_conf)'
I propose that you have a look at it and see if it meets your needs.
If not, I will gladly adjust it until it works for your environment.
I appreciate this consideration. I understand the problem you are
having but would like any additional details you can furnish about
your setup and what got hosed.
Again, I apologize for the troubles your are experiencing.
kind regards,
jereme
--
Jereme Corrado [EMAIL PROTECTED]
--- FAQ/OMatic/Debian.pm.orig 2005-04-07 00:31:37.430916912 -0400
+++ FAQ/OMatic/Debian.pm2005-04-07 00:32:41.281210192 -0400
@@ -9,11 +9,9 @@
our @ISA = qw(Exporter);
our @EXPORT = qw(maintenance_job);
-# The config file written by FOM installer for our maintenance cron job.
-# TODO: determine this dynamically
-my $maint_conf_file = /var/lib/fom/meta/maintenance_job_conf;
-
sub maintenance_job {
+my $maint_conf_file = shift || '/var/lib/fom/meta/maintenance_job_conf';
+
my %vars;
open(F, $maint_conf_file) || die cannot open $maint_conf_file: $!\n;
Bug#298632: #298632: gtk-gnutella: Progress bar in downloads/active downloads is at 0% constantly
Package: gtk-gnutella Version: 0.95-3 Followup-For: Bug #298632 To help confirm this: I have the same bug on my system. It's pesky, because you can't tell who's getting how much of what. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages gtk-gnutella depends on: ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libglib2.0-02.6.3-1 The GLib library of C routines ii libgtk2.0-0 2.6.4-1 The GTK+ graphical user interface ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio ii libxml2 2.6.16-6 GNOME XML library ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300209: tomcat4: tomcat dies with Parse error in default web.xml after upgrade
Hi Sarge release team, The java packing team just got blindsided by bug #300209, which appears to have knocked tomcat4 out of Sarge. Heads up that you may hear some begging for re-inclusion in the near future. Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
