Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On Tue, Jun 20, 2006 at 06:40:56PM +0200, Jonas Meurer wrote: On 19/06/2006 Andrew Pimlott wrote: 1. Create a marking for partitions to be encrypted with a random key, allowing for the positive identification above. Perhaps this should be part of LUKS. i see this more as a feature than as a bug. agree there may exist situations where you don't want your device to be marked as 'contains encrypted data'. Right, however most users would be happy to put such a mark if it increased safety. So it would be a nice option. 2. If I use LUKS for all encrypted filesystems, I believe it is possible to perform the negative identification above. That is, if I don't see the LUKS header, and the partition does not have an unencrypted volume, then it is safe to destroy. So let me promise that I have no non-LUKS encrypted filesystems. i'm not sure that i understand. you mean that all encrypted non-swap devices should be LUKS devices? we should never expect that. I mean _if I explicitly promise so_, we should expect that. So give me some configuration directive like LuksOnly that I can set. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On Tue, Jun 20, 2006 at 10:10:24PM +0200, Jonas Meurer wrote: On 20/06/2006 Andrew Pimlott wrote: I mean _if I explicitly promise so_, we should expect that. So give me some configuration directive like LuksOnly that I can set. looks like overkill for me. users who use only luks don't need to specify that. 'cryptsetup isLuks' is run against every source device anyway, before invoking 'cryptsetup luksOpen'. so there should be no need for a LuksOnly option. But as I understand, a randomly keyed partition can't be done with Luks (or can it?). So even for a user who uses Luks for all his permanent partitions, there will still be the swap partition (or mabye a /tmp partition) that cannot be identified. If we had LuksOnly, we could be confident that those partitions are disposible. However it may still be overkill. I would be happy enough if there were a check for randomly keyed swap partitions that verifies that the source device is 1) not a formatted, unencrypted volume and 2) not Luks. That's still a good measure of safety. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: encrypted swap with variable key fails
As a non-expect in cryptsetup who just wants his swap space back, let me see if I understand the problem. Automatically formatting a swap partition is a destructive operation, so all reasonable checks should be made before doing it. It is currently not possible to positively identify a swap partition encrypted with a random key; nor is it possible to negatively identify a partition as not encrypted (with some unknown key). This gives me two ideas: 1. Create a marking for partitions to be encrypted with a random key, allowing for the positive identification above. Perhaps this should be part of LUKS. 2. If I use LUKS for all encrypted filesystems, I believe it is possible to perform the negative identification above. That is, if I don't see the LUKS header, and the partition does not have an unencrypted volume, then it is safe to destroy. So let me promise that I have no non-LUKS encrypted filesystems. It would be a shame to require extra configuration for encrypted swap with a random key, as this is a commonly recommended setup. Furthermore, it not fundamentally dangerous; the only reason it is dangerous today is that we don't mark partitions clearly enough, and that could change. So we should be able to find a solution. On the other hand, I'm glad you guys are so concerned with the safety of my data! Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369123: libmusclecard1: looks for non-existent /usr/pcsc/services
Package: libmusclecard1
Version: 1.3.3-1
Severity: normal
Tags: patch
/usr/lib/libmusclecard.so.1 hard-codes the directory /usr/pcsc/services,
when it should be /usr/lib/pcsc/services.
--- debian/rules.orig 2006-05-27 10:48:09.0 -0700
+++ debian/rules2006-05-27 10:42:18.0 -0700
@@ -39,6 +39,7 @@
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
+ --enable-muscledropdir=\$${prefix}/lib/pcsc/services \
LDFLAGS=-lpthread
Also, it seems like the program bundleTool used to be provided by
pcsc-lite but is no longer. It is however present in the libmusclecard
source, so perhaps it should create a new package containing bundleTool.
But I don't know how all this is supposed to work, so I could very well
be wrong.
Andrew
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (800, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages libmusclecard1 depends on:
ii libc6 2.3.6-9GNU C Library: Shared libraries
ii libpcsclite1 1.3.1-2Middleware to access a smart card
libmusclecard1 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369123: libmusclecard1: looks for non-existent /usr/pcsc/services
tested working version:
--- debian/rules.orig 2006-05-27 10:48:09.0 -0700
+++ debian/rules2006-05-27 10:42:18.0 -0700
@@ -39,6 +39,7 @@
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
+ --enable-muscledropdir=/usr/lib/pcsc/services \
LDFLAGS=-lpthread
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366178: dpkg: Don't report unable to delete old directory when upgrade contains a file in that directory
Package: dpkg Version: 1.13.16 Severity: minor This issue commonly occurs with many packages, but I'll take xbase-cliens as an example, upgrading 6.9.0.dfsg.1-4 - 1:7.0.0-5: Unpacking xbase-clients (from .../xbase-clients_1%3a7.0.0-5_i386.deb) ... dpkg: warning - unable to delete old directory `/etc/X11/xsm': Directory not empty It appears that the old version included /etc/X11/xsm and /etc/X11/xsm/system.xsm as conffiles; but the new version includes only /etc/X11/xsm/system.xsm. I suppose this is considered a bug fix, as xbase-clients should not exclusively own the directory. Anyhow, dpkg gives the warning since the directory indeed cannot be removed. However, since the new version of the package itself contains a file in this directory, this could be taken to suppress the warning. The current behavior is responsible for a significant fraction of warnings during upgrades, and it's a waste of time to verify that in fact the package is not leaving behind garbage. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages dpkg depends on: ii coreutils [textutils] 5.94-1 The GNU core utilities ii libc6 2.3.6-7GNU C Library: Shared libraries dpkg recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366180: xkb-data: many files in /etc/X11/xkb (from xlibs) orphaned in X11R7 transition
Package: xkb-data Version: 0.8-5 Severity: normal When upgrading through the transition to X11R7, I purged the xlibs package and installed xkb-data. I got many warnings: dpkg - warning: while removing xlibs, directory `/etc/X11/xkb/symbols/pc' not empty so not removed. dpkg - warning: while removing xlibs, directory `/etc/X11/xkb/symbols' not empty so not removed. dpkg - warning: while removing xlibs, directory `/etc/X11/xkb/rules' not empty so not removed. dpkg - warning: while removing xlibs, directory `/etc/X11/xkb/geometry' not empty so not removed. dpkg - warning: while removing xlibs, directory `/etc/X11/xkb/compat' not empty so not removed. dpkg - warning: while removing xlibs, directory `/etc/X11/xkb' not empty so not removed. And in the end, many files were left under /etc/X11/xkb. (A full list is at the end.) No package claims ownership of these files (and dlocate confirms that the purged version of xlibs did not own them). I don't know how this happened, but this scenario was repeated exactly on two separate systems. On neither did I ever change any xkb conffiles. It's possible that this condition has existed for a long time, and that the bug is in an older version of xlibs. I'm filing this against xkb-data because 1) it now owns the xkb files and 2) people upgrading may remove xlibs, so there is no chance to fix the problem there. Here is the list of orphaned files under /etc/X11/xkb: geometry/omnibook compat/group_led compat/leds rules/xfree86-it.lst symbols/ru_yawerty symbols/pc/ar symbols/pc/ben symbols/pc/cz_qwerty symbols/pc/dev symbols/pc/dvorak symbols/pc/el symbols/pc/en_US symbols/pc/fr-latin9 symbols/pc/ge_la symbols/pc/ge_ru symbols/pc/guj symbols/pc/gur symbols/pc/il_phonetic symbols/pc/iu symbols/pc/kan symbols/pc/lo symbols/pc/mk symbols/pc/ml symbols/pc/mt_us symbols/pc/ogham symbols/pc/ori symbols/pc/pl2 symbols/pc/sapmi symbols/pc/sk_qwerty symbols/pc/sr symbols/pc/syr symbols/pc/syr_phonetic symbols/pc/tel symbols/pc/th_pat symbols/pc/th_tis symbols/pc/tml symbols/pc/yu symbols/pc/us_intl symbols/pc/se_FI symbols/pc/se_NO symbols/pc/se_SE symbols/pc/dz Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366184: libghc6-c2hs-dev: should pre-depend on ghc6
Package: libghc6-c2hs-dev Version: 0.13.6-4 Severity: important I just did a big upgrade, and libghc6-c2hs-dev failed: Preparing to replace libghc6-c2hs-dev 0.13.6-4 (using .../libghc6-c2hs-dev_0.13.6-4.1_i386.deb) ... /var/lib/dpkg/info/libghc6-c2hs-dev.prerm: line 22: ghc-pkg: command not found dpkg: warning - old pre-removal script returned error exit status 127 dpkg - trying script from the new package instead ... /var/lib/dpkg/tmp.ci/prerm: line 25: ghc-pkg: command not found dpkg: error processing /var/cache/apt/archives/libghc6-c2hs-dev_0.13.6-4.1_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 127 /var/lib/dpkg/info/libghc6-c2hs-dev.postinst: line 26: ghc-pkg: command not found dpkg: error while cleaning up: subprocess post-installation script returned error exit status 127 ghc-pkg is not available until ghc6 is finished configuring. Thus, I think that libghc6-c2hs-dev should pre-depend on ghc6. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages libghc6-c2hs-dev depends on: ii ghc6 6.4.1-2.1 GHC - the Glasgow Haskell Compilat libghc6-c2hs-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366186: upgrade leaves behind i386-rpm-linux, etc
Package: rpm Version: 4.4.1-8 Severity: minor When upgrading: Preparing to replace rpm 4.0.4-31.1 (using .../archives/rpm_4.4.1-8_i386.deb) ... Unpacking replacement rpm ... dpkg: warning - unable to delete old directory `/usr/lib/rpm/athlon-rpm-linux': Directory not empty dpkg: warning - unable to delete old directory `/usr/lib/rpm/i686-rpm-linux': Directory not empty dpkg: warning - unable to delete old directory `/usr/lib/rpm/i586-rpm-linux': Directory not empty dpkg: warning - unable to delete old directory `/usr/lib/rpm/i486-rpm-linux': Directory not empty dpkg: warning - old file `//usr/lib/rpm/i386-rpm-linux/macros' is the same as several new files! (both `/usr/lib/rpm/i386-linux/macros' and `/usr/lib/rpm/noarch-linux/macros')dpkg: warning - unable to delete old directory `/usr/lib/rpm/i386-rpm-linux': Directory not empty Here's an example of what it looks like now: % ls -l /usr/lib/rpm/i386-* lrwxrwxrwx 1 root root 14 2006-04-21 23:14 /usr/lib/rpm/i386-linux - i386-rpm-linux /usr/lib/rpm/i386-rpm-linux: total 4 -rw-r--r-- 1 root root 1838 2006-03-05 02:08 macros This doesn't seem to be intentional, since as far as I can see the *-rpm-* directories won't get removed by purge. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages rpm depends on: ii libbeecrypt6 4.1.2-4open source C library of cryptogra ii libbz2-1.01.0.3-2high-quality block-sorting file co ii libc6 2.3.6-7GNU C Library: Shared libraries ii libpopt0 1.7-5 lib for parsing cmdline parameters ii librpm4 4.4.1-8RPM shared library ii libselinux1 1.30-1 SELinux shared libraries ii libssl0.9.8 0.9.8a-8 SSL shared libraries ii perl 5.8.8-4Larry Wall's Practical Extraction ii zlib1g1:1.2.3-11 compression library - runtime rpm recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365984: xfonts-base: old font dirs in /usr/X11R6/lib/X11/fonts not removed
Package: xfonts-base Version: 1:1.0.0-3 Severity: minor I'm not sure if this is the right place to report this, and it's probably a known issue, but I couldn't find any mention of it. With the X transition, font directories under /usr/X11R6/lib/X11/fonts are not being removed because they still have fonts.dir, etc in them. Is there a plan for removing those files and thus the containing directories when there are no fonts left? Would it be sufficient to have update-fonts-dir, etc, delete the generated files in the postrm? Or will there be a special clean-up script when the transition is complete? Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xfonts-base depends on: ii x11-common1:7.0.16 X Window System (X.Org) infrastruc ii xfonts-utils 1:1.0.0-3 X Window System font utility progr xfonts-base recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365814: gnupg: gpg does not round-trip clearsigned messages
On Wed, May 03, 2006 at 11:18:04AM -0400, David Shaw wrote: This is not a bug. Clearsigned messages are not reversible to restore the original message including line endings and trailing whitespace. If perfect reversibility is desired, you must use regular signatures. Ok, but this seems like a strange and unexpected design for a signature. There should probably be some strong warnings in the documentation. For example, the handbook misleadingly says The option --clearsign causes the document to be wrapped in an ASCII-armored signature but otherwise does not modify the document. Maybe the docs should say Clearsigning modifies the message in minor ways that should not affect reading. However, for this reason it should not be used on data that must be preserved exactly. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365814: gnupg: gpg does not round-trip clearsigned messages
PS. I was off-line when I filed this, but now I notice that this has been discussed. One message [1] suggests that this is a spec violation by gnupg. Andrew [1] http://www.imc.org/ietf-openpgp/mail-archive/msg12809.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365811: vim: setting eol does not mark the buffer modified
Package: vim Version: 1:6.4-007+1 Severity: minor Setting the eol option does not mark the buffer modified, even when it would cause a change in the contents of the file: % echo -n hello out % ls -l out -rw-rw-r-- 1 andrew andrew 5 2006-04-06 15:46 out % vim out Note the [noeol]. :set eol Note no [+]. :set modified? nomodfiied :wq % ls -l out -rw-rw-r-- 1 andrew andrew 6 2006-04-06 15:48 out Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages vim-perl depends on: ii libatk1.0-0 1.11.3-1 The ATK accessibility toolkit ii libc6 2.3.6-4GNU C Library: Shared libraries an ii libcairo2 1.0.2-3The Cairo 2D vector graphics libra ii libfontconfig12.3.2-5generic font configuration library ii libglib2.0-0 2.10.1-2 The GLib library of C routines ii libgpmg1 1.19.6-22 General Purpose Mouse - shared lib ii libgtk2.0-0 2.8.16-1 The GTK+ graphical user interface ii libice6 6.9.0.dfsg.1-5 Inter-Client Exchange library ii libncurses5 5.5-1 Shared libraries for terminal hand ii libpango1.0-0 1.12.0-2 Layout and rendering of internatio ii libperl5.85.8.8-3Shared Perl library ii libsm66.9.0.dfsg.1-5 X Window System Session Management ii libx11-6 6.9.0.dfsg.1-5 X Window System protocol client li ii libxcursor1 1.1.3-1X cursor management library ii libxext6 6.9.0.dfsg.1-5 X Window System miscellaneous exte ii libxi66.9.0.dfsg.1-5 X Window System Input extension li ii libxinerama1 6.9.0.dfsg.1-5 X Window System multi-head display ii libxrandr26.9.0.dfsg.1-5 X Window System Resize, Rotate and ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra ii libxt66.9.0.dfsg.1-5 X Toolkit Intrinsics ii vim-gui-common1:6.4-007+1Vi IMproved - Common GUI files ii vim-runtime 1:6.4-007+1Vi IMproved - Runtime files vim-perl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365814: gnupg: gpg does not round-trip clearsigned messages
Package: gnupg Version: 1.4.2.2-1 Severity: normal Messages clearsigned and then decrypted may not return the original message. In particular, a newline may be added. % echo -n hello out % ls -l out -rw-rw-r-- 1 andrew andrew 5 2006-04-06 15:51 out % gpg --clearsign out % gpg --decrypt --output out2 out.asc gpg: Signature made Thu 06 Apr 2006 03:51:09 PM PDT using DSA key ID 43ABB76D gpg: Good signature from Andrew Pimlott [EMAIL PROTECTED] % ls -l out2 -rw-rw-r-- 1 andrew andrew 6 2006-04-06 15:51 out2 If you clearsign both hello and hello\n, you will see that they result in the same SIGNED MESSAGE. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages gnupg depends on: ii libbz2-1.01.0.3-2high-quality block-sorting file co ii libc6 2.3.6-4GNU C Library: Shared libraries an ii libldap2 2.1.30-13 OpenLDAP libraries ii libreadline5 5.1-7 GNU readline and history libraries ii libusb-0.1-4 2:0.1.11-7 userspace USB programming library ii makedev 2.3.1-80 creates device files in /dev ii zlib1g1:1.2.3-11 compression library - runtime gnupg recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359277: cryptsetup: luksOpen fails with exit code 0
Package: cryptsetup Version: 2:1.0.2+1.0.3-rc3-1 Severity: important If you run cryptsetup luksOpen /dev/luks_partition whatever and mistype the passphrase, the program exits with 0 instead of indicating an error. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages cryptsetup depends on: ii dmsetup 2:1.02.03-1The Linux Kernel Device Mapper use ii libc6 2.3.6-4GNU C Library: Shared libraries an ii libdevmapper1 2:1.02.03-1The Linux Kernel Device Mapper use ii libgcrypt11 1.2.2-1LGPL Crypto library - runtime libr ii libgpg-error0 1.2-1 library for common error values an ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libuuid1 1.38+1.39-WIP-2005.12.31-1 universally unique id library cryptsetup recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359182: debhelper: dh_installdirs man page says it only created dirs for one package
On Mon, Mar 27, 2006 at 01:19:59PM -0500, Joey Hess wrote: Andrew Pimlott wrote: The dh_installdirs man page says (or at least implies) that it creates directories for only one package per invocation. However, when I run it with no options, it creates directories for all packages (based on their .dirs files). debhelper(7) describes common semantics for all debhelper programs, including: If your source package generates more than one binary package, deb‐ helper programs will default to acting on all binary packages when run. It also describes how to control which packages a command acts on. I see nothing in dh_installdirs(1) that contradicts this. I see now, but I think a new user of debhelper would find it confusing. The special behavior regarding the first package is described (in paragraph Any directory ...) before the common behavior for all packages (A file ...). By the time I read the former, I assumed that dh_installdirs always acted on the first package. Perhaps swapping the order and changing a few words would clarify it: dh_installdirs is a debhelper program that is responsible for creating subdirectories in package build directories. For each package dh_installdirs is told to act on, the file debian/package.dirs lists the directories to be created in the package build directory. Separate the directory names with whitespace. In addition, any directory names specified as parameters will be created in the package build directory of the first package acted on (based upon their order in debian/control). Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359182: debhelper: dh_installdirs man page says it only created dirs for one package
Package: debhelper Version: 5.0.26 Severity: minor The dh_installdirs man page says (or at least implies) that it creates directories for only one package per invocation. However, when I run it with no options, it creates directories for all packages (based on their .dirs files). Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages debhelper depends on: ii binutils 2.16.1cvs20060117-1 The GNU assembler, linker and bina ii coreutils [fileutils 5.94-1 The GNU core utilities ii dpkg-dev 1.13.17 package building tools for Debian ii file 4.17-1 Determines file type using magic ii html2text1.3.2a-3An advanced HTML to text converter ii perl 5.8.8-3 Larry Wall's Practical Extraction ii po-debconf 1.0 manage translated Debconf template debhelper recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359006: xterm: unicode glyph rendering glitch
Package: xterm Version: 210-2 Severity: minor Unicode characters generally render properly in my xterm, using LANG=en_US.UTF-8, however I just noticed a glitch. When U+2218 is rendered in some colors, it turns into the dashed box that usually denotes a bad character. To reproduce: - start vim in an xterm, with LANG=en_US.UTF - enter insert mode and type the sequence ctrl-V u2218 You should see a nice function composition symbol, U+2218: ∘ - Now colorise it by typing :set ft=mail and then entering before the symbol. When it changes color, it turns into a dashed box. If I cut and past it into another application, it shows up correctly as a function composition symbol, so xterm clearly still knows what it should be; it just doesn't render it properly. Also, I don't see the same problem with most other unicode characters, but it does seem to afflict others in the same range. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xterm depends on: ii libc6 2.3.6-4GNU C Library: Shared libraries an ii libfontconfig12.3.2-5generic font configuration library ii libice6 6.9.0.dfsg.1-5 Inter-Client Exchange library ii libncurses5 5.5-1 Shared libraries for terminal hand ii libsm66.9.0.dfsg.1-5 X Window System Session Management ii libx11-6 6.9.0.dfsg.1-5 X Window System protocol client li ii libxaw7 6.9.0.dfsg.1-5 X Athena widget set library ii libxext6 6.9.0.dfsg.1-5 X Window System miscellaneous exte ii libxft2 2.1.8.2-5.1FreeType-based font drawing librar ii libxmu6 6.9.0.dfsg.1-5 X Window System miscellaneous util ii libxt66.9.0.dfsg.1-5 X Toolkit Intrinsics ii xlibs-data6.9.0.dfsg.1-5 X Window System client data Versions of packages xterm recommends: ii xutils6.9.0.dfsg.1-5 X Window System utility programs -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346098: patch in 6.9.0.dfsg.1-4
On Fri, Mar 10, 2006 at 06:08:18PM +0100, Niko Ehrenfeuchter wrote: afaics, the above mentioned patch is included in 6.9.0.dfsg.1-4 (at least from what i've seen in the deb-sources), but unfortunately EmulateWheel still doesn't work for me with this version (up-to-date testing). I even tried to rebuild the package locally to make sure the patch is applied, but it didn't have any impact on the result... Sorry for the late reply. A better patch was checked in upstream. See https://bugs.freedesktop.org/show_bug.cgi?id=5071 I've lost track of when this might get into Debian. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291391: pod2man turns VERTICAL BAR (pipe) into BOX DRAWINGS LIGHT VERTICAL
On Wed, Mar 08, 2006 at 08:18:46PM -0800, Russ Allbery wrote: I'm a little suspicious of the \*(W fiddling as well, but I'm not sure I understand exactly why that's being done. The comment says that it's turning \*(-- into an unbreakable dash, but I don't understand why that's being done by outputting a Greek capital omega followed by a dash and then using .tr to change the omega back to a dash. If anyone understands what the motivation might be here, please explain it to me? To clarify, I only meant to remove the special treatment of the vertical bar. I had no idea that line was also doing something else, so any other effect it had was unintentional. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291391: pod2man turns VERTICAL BAR (pipe) into BOX DRAWINGS LIGHT VERTICAL
This old bug just tripped me. It appears trivial to fix with this
patch. I don't know roff, but this seems to have the right effect, and
you notice the tip-off bv (bar vertical, box vertical?). Someone
who knows roff could tell if this is the right fix (is tchrist still
active?), but this change seems harmless.
Andrew
--- /usr/share/perl/5.8.8/Pod/Man.pm2006-03-07 00:01:39.0 -0800
+++ - 2006-03-07 00:02:16.902649000 -0800
@@ -74,11 +74,10 @@
..
.\ Set up some character translations and predefined strings. \*(-- will
.\ give an unbreakable dash, \*(PI will give pi, \*(L will give a left
-.\ double quote, and \*(R will give a right double quote. | will give a
-.\ real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
+.\ double quote, and \*(R will give a right double quote.
+.\ \*(C+ will give a nicer C++. Capital omega is used to
.\ do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\ expand to `' in nroff, nothing in troff, for use with C.
-.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.ds -- \(*W-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354506: xpdf-utils: pdftops creates postscript with leading '%' that confuses poster
Package: xpdf-utils Version: 3.01-6 Severity: normal I created an EPS file from a PDF file[1] (large download) using pdftops -eps FortOrdFairMap.pdf, and then tried to run it through poster. However, the generated EPS uses some clever tricks to include the bitmap portions of the document, which allow '%' to appear at the beginning of a line. poster assumes that these lines are comments and omits them from its output, resulting in a broken file. I am not a PostScript expert, so I can't comment on the propriety of this EPS file, but perhaps the bitmap inclusion technique could be modified not to use % at the beginning of a line. Meanwhile, I'll look at fixing poster to pass through comments. Andrew [1] http://fortordcleanup.com/images/FortOrdFairMap.pdf -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xpdf-utils depends on: ii libc6 2.3.6-1GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-9 GCC support library ii libpaper1 1.1.14-5 Library for handling paper charact ii libstdc++64.0.2-9The GNU Standard C++ Library v3 ii xpdf-common 3.01-6 Portable Document Format (PDF) sui xpdf-utils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354506: xpdf-utils: pdftops creates postscript with leading '%' that confuses poster
On Sun, Feb 26, 2006 at 02:51:43PM -0800, Andrew Pimlott wrote: Meanwhile, I'll look at fixing poster to pass through comments. Hmm, poster claims that it is necessary to remove the DSC comments from the original document: those (DSC) lines sometimes disturb proper previewing of the result with ghostview. However, the output of pdftops can just as well have two leading '%'s as one in bitmaps (in fact, my file does). Is there some way to distinguish those from DSC comments? Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354506: xpdf-utils: pdftops creates postscript with leading '%' that confuses poster
Hmm, despite the discouraging comment in poster, when I modified it to pass through all comments, the result worked perfectly in gv. However, I would rather not propose that as a solution except as a last resort. At least I have a nice 100MB file to send to the printer Monday! Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354506: pdftops creates postscript with non-comment comments
Derek, I reported this in the Debian bug tracking system[1], but I thought I should mention this to you because I believe it's a bug that would affect all users of pdftops. The problem, fully described in the Debian bug report, is that when pdftops puts a bitmap into the generated PostScript, it may create lines starting with % and even %%, which are not comments. This confuses the poster[2] post-processor. I don't know enough about PostScript to lay the blame, but it seems it would be better to avoid creating these lines if possible. Thanks a lot for xpdf! Andrew [1] http://bugs.debian.org/354506 [2] ftp://ftp.ics.ele.tue.nl/pub/users/jos/poster/poster.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335962: scp -r follows symlinks
To follow up on this bug report, following symlinks in a recursive copy is non-standard compared to other unix tools, and was highly surprising to me. In fact, I just lost an hour because of this: I edited the copy I thought the symlink was pointing to, but there was no more symlink. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348384: xterm: please restore default charClass
I want to strongly second the opinion of Kirk Hilliard [EMAIL PROTECTED]. I find that in fact the new behavior makes it harder to select URLs! When I read mail in mutt, the URL often wraps to a new line and in preceded by a '+' character. Double-clicking the URL selects the '+', so I must carefully select the start and end of the URL by character. With the old settings, I could double-click anywhere in HTTP and drag to the end by word (which is also useful to grab only part of the URL, by the way). The issue repeats itself in many other situations. For example, I used to be able to get a bug number out of a Debian changelog by double-clicking; now, I get #345477, instead. When I want a word from a document, I end up getting the surrounding punctuation as well. And so on. Moreover, xterm has had its default selection behavior forever, and with such a venerable program, the Debian package should be conservative in changing defaults. I was quite shocked by the new behavior. I even took care to keep my old xterm windows open so that I could enjoy the historical behavior until I had time to figure out what was going on! Last, if you are going to keep the change, you should not only mention it in README.Debian, but update the man page, which gives the default. In my view, the burden of maintaining the updated man page is reason enough not to make this change. ;-) Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342948: patch for stable includes no documentation
I want to amplify the comment of Nicholas Lee [EMAIL PROTECTED]. This patch did not include an update to the manual, only a terse mention in the changelog.Debian. Even reading the bug log, I cannot tell what behaviour is implemented for stable. This leaves the hapless administrator to use guesswork to repair the damage, a precarious situation for a security-critical function. Further, there appears to be no way to get the old behavior back in situations where that is safe. I would suggest documenting the applied patch in the man page and README.Debian. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348917: hald-addon-storage uses too much CPU
Package: hal Version: 0.5.5.1-5 Severity: normal I recently ran top, and noticed among the usual cpu hogs a new contender, an obscure program called hald-addon-storage, sucking down 1-2%. This is on an ordinary, modern x86 computer, and I have not touched the configuration of hal, hotplug, udev, or anything like that. I did not investigate further, so I do not know whether this is just a measurement fluke, but if it is accurate, it is clearly unreasonably high. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages hal depends on: ii adduser 3.80 Add and remove users and groups ii dbus 0.60-5 simple interprocess messaging syst ii libc6 2.3.5-12 GNU C Library: Shared libraries an ii libdbus-1-2 0.60-5 simple interprocess messaging syst ii libdbus-glib-1-2 0.60-5 simple interprocess messaging syst ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libglib2.0-0 2.8.5-1The GLib library of C routines ii libhal1 0.5.5.1-5 Hardware Abstraction Layer - share ii libusb-0.1-4 2:0.1.10a-22 userspace USB programming library ii lsb-base 3.0-14 Linux Standard Base 3.0 init scrip ii pciutils 1:2.1.11-15.3 Linux PCI Utilities ii udev 0.080-1/dev/ and hotplug management daemo ii usbutils 0.71+cvs20051029-4 USB console utilities hal recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348917: hald-addon-storage uses too much CPU
On Fri, Jan 20, 2006 at 12:23:25AM +0100, Sjoerd Simons wrote:
Cou you run ``strace -t -p pid of hald-addon-storage using cpu'' for
about 30 seconds and mail the output of that ?
Good idea. I'm sending the whole thing, but you can see that the cycle
is every 2 seconds.
Andrew
15:41:31.384514 setup() = 0
15:41:33.113655 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = -1
EBUSY (Device or resource busy)
15:41:33.126573 open(/etc/mtab, O_RDONLY) = 4
15:41:33.126689 fstat64(4, {st_mode=S_IFREG|0644, st_size=368, ...}) = 0
15:41:33.126808 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f6c000
15:41:33.126890 read(4, /dev/hda3 / ext3 rw,errors=remou..., 4096) = 368
15:41:33.127027 close(4)= 0
15:41:33.127096 munmap(0xb7f6c000, 4096) = 0
15:41:33.127166 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 4
15:41:33.140189 ioctl(4, CDROM_DRIVE_STATUS, 0x7fff) = 1
15:41:33.140818 close(4)= 0
15:41:33.140895 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
15:41:33.140998 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
15:41:33.141069 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
15:41:33.141130 nanosleep({2, 0}, {2, 0}) = 0
15:41:35.142382 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = -1
EBUSY (Device or resource busy)
15:41:35.155217 open(/etc/mtab, O_RDONLY) = 4
15:41:35.155338 fstat64(4, {st_mode=S_IFREG|0644, st_size=368, ...}) = 0
15:41:35.155434 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f6c000
15:41:35.155509 read(4, /dev/hda3 / ext3 rw,errors=remou..., 4096) = 368
15:41:35.155638 close(4)= 0
15:41:35.155706 munmap(0xb7f6c000, 4096) = 0
15:41:35.155776 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 4
15:41:35.168554 ioctl(4, CDROM_DRIVE_STATUS, 0x7fff) = 1
15:41:35.169139 close(4)= 0
15:41:35.169214 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
15:41:35.169340 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
15:41:35.169412 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
15:41:35.169477 nanosleep({2, 0}, {2, 0}) = 0
15:41:37.171116 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = -1
EBUSY (Device or resource busy)
15:41:37.183994 open(/etc/mtab, O_RDONLY) = 4
15:41:37.184113 fstat64(4, {st_mode=S_IFREG|0644, st_size=368, ...}) = 0
15:41:37.184212 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f6c000
15:41:37.184285 read(4, /dev/hda3 / ext3 rw,errors=remou..., 4096) = 368
15:41:37.184414 close(4)= 0
15:41:37.184482 munmap(0xb7f6c000, 4096) = 0
15:41:37.184552 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 4
15:41:37.197891 ioctl(4, CDROM_DRIVE_STATUS, 0x7fff) = 1
15:41:37.198476 close(4)= 0
15:41:37.198545 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
15:41:37.198628 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
15:41:37.198692 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
15:41:37.198795 nanosleep({2, 0}, {2, 0}) = 0
15:41:39.199901 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = -1
EBUSY (Device or resource busy)
15:41:39.212701 open(/etc/mtab, O_RDONLY) = 4
15:41:39.212822 fstat64(4, {st_mode=S_IFREG|0644, st_size=368, ...}) = 0
15:41:39.212919 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f6c000
15:41:39.212990 read(4, /dev/hda3 / ext3 rw,errors=remou..., 4096) = 368
15:41:39.213123 close(4)= 0
15:41:39.213194 munmap(0xb7f6c000, 4096) = 0
15:41:39.213264 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 4
15:41:39.226080 ioctl(4, CDROM_DRIVE_STATUS, 0x7fff) = 1
15:41:39.226691 close(4)= 0
15:41:39.226777 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
15:41:39.226864 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
15:41:39.226930 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
15:41:39.226992 nanosleep({2, 0}, {2, 0}) = 0
15:41:41.228593 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = -1
EBUSY (Device or resource busy)
15:41:41.241430 open(/etc/mtab, O_RDONLY) = 4
15:41:41.241552 fstat64(4, {st_mode=S_IFREG|0644, st_size=368, ...}) = 0
15:41:41.241648 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f6c000
15:41:41.241720 read(4, /dev/hda3 / ext3 rw,errors=remou..., 4096) = 368
15:41:41.241848 close(4)= 0
15:41:41.241953 munmap(0xb7f6c000, 4096) = 0
15:41:41.242030 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 4
15:41:41.254829 ioctl(4, CDROM_DRIVE_STATUS, 0x7fff) = 1
15:41:41.255420 close(4)= 0
15:41:41.255506 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
15:41:41.255594 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
15:41:41.255660 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
15:41:41.255722 nanosleep({2, 0}, {2, 0}) = 0
15:41:43.257330 open(/dev/hdc, O_RDONLY|O_NONBLOCK|O_EXCL|O_LARGEFILE) = -1
EBUSY (Device or resource busy)
15:41:43.270143 open(/etc/mtab, O_RDONLY) = 4
15:41:43.270388 fstat64(4,
Bug#320136: [patch] EmulateWheel button press broken
As reported in two Debian bug reports [1] [2], the ability for the
EmulateWheelButton to generate button events was broken shortly before
the 6.9 release. It is still broken in current Debian unstable package
6.9.0.dfsg.1-3, and I believe it is still broken in x.org CVS.
It was broken by version 1.15 of
xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c. The problem is the
removal of the truebuttons variable. The wheel emulation code in
MouseDoPostEvent modifies buttons to mask out EmulateWheelButton,
therefore the if condition
if (buttons != pMse-lastMappedButtons) {
(line 2256) was failing when the EmulateWheelButton was pressed,
therefore
pMse-lastMappedButtons = buttons;
(line 2359) was not being run, therefore when the EmulateWheelButton was
released,
change = buttons ^ pMse-lastMappedButtons;
(line 2162) thought there was no change, therefore the button press was
not generated.
The appended patch fixes this by restoring truebuttons (which I called
origbuttons to be slightly clearer). The logic is very similar to
before 1.15, and it does not appear to interfere with the mapping
changes in 1.15, so I don't think it will introduce any problems that
weren't already there. I tested that I can now generate a button press
with EmulateWheelButton.
The patch was generated against the latest Debian unstable sources, but
applies cleanly to the latest CVS.
Andrew
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320136
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346098
[3]
http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c?r1=1.14r2=1.15
--- mouse.c.orig2006-01-12 13:46:21.0 -0800
+++ mouse.c 2006-01-12 14:10:46.0 -0800
@@ -2076,7 +2076,7 @@
MouseDoPostEvent(InputInfoPtr pInfo, int buttons, int dx, int dy)
{
MouseDevPtr pMse;
-int emulateButtons;
+int origbuttons, emulateButtons;
int id, change;
int emuWheelDelta, emuWheelButton, emuWheelButtonMask;
int wheelButtonMask;
@@ -2084,6 +2084,8 @@
pMse = pInfo-private;
+origbuttons = buttons;
+
/* Do single button double click */
if (pMse-doubleClickSourceButtonMask) {
if (buttons pMse-doubleClickSourceButtonMask) {
@@ -2211,7 +2213,7 @@
if (dx || dy)
xf86PostMotionEvent(pInfo-dev, 0, 0, 2, dx, dy);
-if (buttons != pMse-lastMappedButtons) {
+if (origbuttons != pMse-lastMappedButtons) {
change = buttons ^ pMse-lastMappedButtons;
@@ -2314,7 +2316,7 @@
(buttons (1 (id - 1))), 0, 0);
}
-pMse-lastMappedButtons = buttons;
+pMse-lastMappedButtons = origbuttons;
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319113: acknowledged by developer (Re: Bug#319113: your bug -- manpages-dev: getservent(3) is confusing about the size of s_port)
On Tue, Dec 20, 2005 at 11:11:37PM -0500, Justin Pryzby wrote: Oh, I didn't see that. Then you have to call ntohs() on it before doing any arithmetic operations on it, or interpretting it as an integer, as in your test. Yes, that's what bit me. I didn't realize that ntohs rather than ntols (since I thought I was operating on a 32 bit int) was appropriate. In retrospect, it makes sense, but it wasn't obvious to me at the time. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316809: finding .config in current linux packages
The information in README.Debian of current linux-source packages (the Config Files section) does seem to be accurate, however it isn't very helpful to someone who's looking for the .config files in a small download. This doesn't seem to be available in the current packages; IIUC the smallest download is a linux-headers-* package. I would suggest that the README.Debian be changed to point to the linux-headers-* packages. It would still be nice, however, to make the .config files more conveniently available. One idea would be to put each in its own package, generated along with the linux-image-* and linux-headers-* packages, but this is probably ridiculous. Would it be possible to put them in the linux-source-* package, by having the linux-source-* build process generate the .config file for each variant? Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#244658: info coreutils prog always gives man page
I am following up to this bug because I think what I am seeing is related, and maybe it will revive interest in this unresolved issue. Currently, on an unstable system, with coreutils (5.93-5), glibc-doc (2.3.5-8.1), and info (4.8-2) installed, info prog for any program in coreutils gives a man page (which tells you to run info prog) instead of an info page. info coreutils prog brings up the coreutils page, except for the cases such as pr and who brought up earlier in this bug log. I am not sure exactly what the behavior was when the bug was opened, but the situation now seems to be worse: info prog always returns wrong information, yet is recommended in the man pages. At this point, changing the man pages seems appropriate. As for really fixing the issue, I don't understand Karl Berry's objection. Perhaps eventually dir files should be enhanced, but in the meantime how would preferring exact matches be worse than the current behavior? Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335819: openoffice.org-common: non-existing programs oowriter2, etc used in mailcap entries
Package: openoffice.org-common Version: 2.0.0-1 Severity: normal Many of the openoffice packages have files in /usr/lib/mime/packages that run programs ending in 2, eg oowriter2, which do not exist (because the program is called oowriter, etc). Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages openoffice.org-common depends on: ii dictionaries-common [openoffi 0.60.1 Common utilities for spelling dict ii openoffice.org-core 2.0.0-1OpenOffice.org office suite archit ii openoffice.org-l10n-en-us 2.0.0-1English_american language package ii python2.3.5-3An interactive high-level object-o openoffice.org-common recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334474: libapache-mod-ssl: private keys created world writeable by mod-ssl-makecert
Package: libapache-mod-ssl Version: 2.8.24-2 Severity: normal I ran dpkg-reconfigure libapache-mod-ssl as recommended in README.Debian, and the generated /etc/apache/ssl.key/server.key was created with permissions -rw-r--r--1 root root 891 2005-10-18 00:00 /etc/apache/ssl.key/server.key This should be readable only by root. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages libapache-mod-ssl depends on: ii apache-common 1.3.33-8 support files for all Apache webse ii libc6 2.3.5-7GNU C Library: Shared libraries an ii libdb4.2 4.2.52-20 Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libssl0.9.8 0.9.8a-1 SSL shared libraries ii openssl 0.9.8a-1 Secure Socket Layer (SSL) binary a libapache-mod-ssl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330253: xemacs21-support: info pages are not in the info path
Package: xemacs21-support Version: 21.4.17-2 Severity: normal Because the info docs are in /usr/share/info/xemacs21 instead of /usr/share/info, the stand-alone info reader (ie, in the package info) cannot find the documentation. Also, the info main page does not include xemacs entries. I see that install-info is commented out in the postinst, but I don't understand why. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xemacs21-support depends on: ii emacsen-common1.4.16 Common facilities for all emacsen ii xemacs21 21.4.17-2 highly customizable text editor ii xemacs21-mule [xemacs21] 21.4.17-2 highly customizable text editor -- xemacs21-support recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329875: smlnj: /root/SML/ infects installed version
Package: smlnj Version: 110.52-1 Severity: normal Warning: I don't know if this is really a bug, as I am not a real SML/NJ user. However, I installed smlnj and tried to use it with Isabelle. Isabelle has a script build which runs smlnj. Unfontunately, I got the errors: Standard ML of New Jersey v110.52 [built: Fri Jan 21 16:42:10 2005] !* unable to process `' (unknown extension `none') - [autoloading] unexpected exception (bug?) in SML/NJ: Io [Io: openIn failed on /root/SML/smlnj-110.52/sml.boot.x86-unix/basis.cm/.cm/x86-unix/basis.cm, No such file or directory] raised at: Basis/Implementation/IO/bin-io-fn.sml:618.25-618.71 ../cm/util/safeio.sml:30.11 ../compiler/TopLevel/interact/evalloop.sml:44.55 Since I can see with grep that /root/SML is in many smlnj files, including binaries, I have a suspicion that this is the problem. I installed smlnj by myself in /usr/local, and now Isabelle's build command works. It seems that Isabelle is piping fun exit 0 = (OS.Process.exit OS.Process.success): unit | exit _ = OS.Process.exit OS.Process.failure; fun commit () = not (SMLofNJ.exportML/usr/local/Isabelle/heaps/smlnj-110_x86-linux/Pure); val ml_system = smlnj-110; (useML-Systems/smlnj.ML; useROOT.ML) handle _ = exit 1; Session.finish(); to /usr/lib/smlnj/bin/sml @SMLdebug=/dev/null Not sure if this helpz without knowing the contents of /usr/local/Isabelle/heaps/smlnj-110_x86-linux/Pure. If you want to download Isabelle and try it yourself, I followed thi install instructions and then edited etc/settings to uncomment the smlnj-110 section and set ML_HOME=/usr/lib/smlnj/bin. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages smlnj depends on: ii smlnj-runtime 110.52-1 Standard ML of New Jersey runtime smlnj recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327571: unison compatibility situation
Package: unison Version: 2.13.16-2 Severity: wishlist This is mostly a reminder of bug 308126, please mention in NEWS.Debian when archive format changes. Casual users of unison might not be aware that unison breaks protocol compatibilty with every version, so it would be nice to remind them. (Speaking of which, NEWS.Debian seems to have slipped out of the package in the latest upload.) It might also be nice to say something about this in the package description. Eg, Note: The remote version of unison must have the same first two version components, eg 2.13. And for unison2.9.1 you could add, This package is compatible with with unison package in Debian sarge. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages unison depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an Versions of packages unison recommends: ii openssh-client [ssh-client] 1:4.1p1-7 Secure shell client, an rlogin/rsh -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326395: unison-gtk: profile does not exist (directory has version appended)
Package: unison-gtk Version: 2.13.16-1 Severity: important I just upgraded unison and unison-gtk and ran my usual command, unison-gtk home. I got the error dialog: Fatal error Profile /home/andrew/.unison-2.13.16-gtk/home.prf does not exist I hope this is not intentional. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages unison-gtk depends on: ii libatk1.0-0 1.10.1-2 The ATK accessibility toolkit ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libglib2.0-0 2.8.0-1The GLib library of C routines ii libgtk2.0-0 2.6.9-1The GTK+ graphical user interface ii libpango1.0-0 1.8.2-1Layout and rendering of internatio ii unison2.13.16-1 A file-synchronization tool for Un Versions of packages unison-gtk recommends: ii ssh-askpass 1:1.2.4.1-3 under X, asks user for a passphras -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323867: ProductName: ESP Ghostscript message causes popup in gv
Package: gs-esp Version: 8+8.15rc4.dfsg.1-2 Severity: normal When I run gv, I get an annoying popup saying %%[ ProductName: ESP Ghostscript ]%% So probably gs-esp should not print this message. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages gs-esp depends on: ii gs-common 0.3.9 Common files for different Ghostsc ii libc6 2.3.5-3GNU C Library: Shared libraries an ii libcupsimage2 1.1.23-12 Common UNIX Printing System(tm) - ii libcupsys2 [libcupsys2-gn 1.1.23-12 Common UNIX Printing System(tm) - ii libcupsys2-gnutls10 1.1.23-12 Common UNIX Printing System(tm) - ii libice6 6.8.2.dfsg.1-5 Inter-Client Exchange library ii libjpeg62 6b-10 The Independent JPEG Group's JPEG ii libpaper1 1.1.14-3 Library for handling paper charact ii libpng12-01.2.8rel-1 PNG library - runtime ii libsm66.8.2.dfsg.1-5 X Window System Session Management ii libstdc++64.0.1-5The GNU Standard C++ Library v3 ii libtiff4 3.7.3-1Tag Image File Format (TIFF) libra ii libx11-6 6.8.2.dfsg.1-5 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-5 X Window System miscellaneous exte ii libxt66.8.2.dfsg.1-5 X Toolkit Intrinsics ii xlibs 6.8.2.dfsg.1-5 X Window System client libraries m ii zlib1g1:1.2.3-3 compression library - runtime Versions of packages gs-esp recommends: ii gsfonts 8.14+v8.11+urw-0.2 Fonts for the Ghostscript interpre ii psfontmgr 0.11.8-0.1 PostScript font manager -- part of -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#246983: gs-*: alternatives priority confusion
Kenshi Muto wrote: At Tue, 11 May 2004 02:38:54 +0200, Adrian Bunk wrote: the current setup is pretty braindead if CUPS is installed: - by default, gs-gpl and gs-afpl are never used when gs is called - if you manually change the default gs, you break CUPS What about the following: - CUPS calls gs-esp instead of gs - gs-esp priority becomes lower than 20 - gs-esp with low priority conflicts with older CUPS packages Because CUPS itself uses gs-esp statically (so CUPS always needs 'Depends: gs-esp'), your reassign should be closed. But, I won't agree to make gs-esp lower. Some other filter packages are still using 'gs'. Since alternatives are intended to be changed by an administrator, it is a bug if some filters call gs when they need gs-esp. So if these filters are fixed, as they should be anyway, then we can change the priorities and everyone will be happy. :-) Adrian Bunk wrote: Installing CUPS effectively makes gs-gpl and gs-afpl useless. This is really a serious problem. I was quite surprised to discover that I was using gs-esp when calling gv (cf bug 323867), since I had never intentionally installed it. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323239: aptitude: search backwards
Package: aptitude Version: 0.2.15.9-6 Severity: wishlist Searching backwards would be nice. Suggest binding ReSearchBackwards to 'N'. I don't know what key to bind SearchBackwards to; for me, it's hardly necessary. I mostly want ReSearchBackwards for when I've hit 'n' too many times. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-6-3.1 0.6.40.1 Advanced front-end for dpkg ii libc6 2.3.5-3GNU C Library: Shared libraries an ii libgcc1 1:4.0.1-3 GCC support library ii libncurses5 5.4-9 Shared libraries for terminal hand ii libsigc++-1.2-5c2 1.2.5-5type-safe Signal Framework for C++ ii libstdc++64.0.1-3The GNU Standard C++ Library v3 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-do none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322867: laptop-mode-tools: reduce logging noise
Package: laptop-mode-tools Version: 1.08-1 Severity: minor laptop_mode spits a verbose, badly formatted noise to daemon.log: Aug 12 22:24:33 localhost apmd: + Stopping automatic power miser daemon: apmiser. Laptop Mode Tools 1.08 Setting action to stop because we are running on AC power. Stopping laptop_modeAdjusting 2.6 kernel parameters to disable laptop mode. Remounting filesystems. /dev/hda3 not found in Aug 12 22:24:33 localhost apmd: + PARTITIONS. / not found in PARTITIONS. Checking /dev/hda3 against HD because PARTITIONS contains auto. /dev/hda3 contains /dev/hda, which is in HD, so we will remount it. Original options: rw,errors=remount-ro,commit=0 Executing: blockdev --setra 256 /d ... and so on for many more lines. Ideally this would be pared down to only useful information. :-) Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages laptop-mode-tools depends on: ii powermgmt-base1.22 Common utils and configs for power Versions of packages laptop-mode-tools recommends: ii acpid 1.0.4-2Utilities for using ACPI power man ii apmd 3.2.2-3Utilities for Advanced Power Manag ii hdparm6.1-2 tune hard disk parameters for high -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322867: laptop-mode-tools: reduce logging noise
On Sat, Aug 13, 2005 at 10:10:35AM +0200, Bart Samwel wrote: It seems like you have VERBOSE_OUTPUT=1 in laptop-mode.conf. If you set it to 0 then the output will hopefully be nice and simple. Ok. However, VERBOSE_OUTPUT=1 appears to be the default, since I did not change it. Perhaps turning it off would be a better default. And formatting the output better in case it goes to syslog couldn't hurt. :-) Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323019: NOLM_AC_HD_POWERMGMT=1 is a poor default
Package: laptop-mode-tools Version: 1.08-1 Severity: normal I just upgraded my laptop-mode-tools in unstable, and noticed my hard disk was spinning down even on AC power. It never did this with older laptop-mode-tools. (I made only one modification to the shipped config, changing LM_BATT_HD_IDLE_TIMEOUT to 12.) I notice in the config NOLM_AC_HD_POWERMGMT=1, which sets hdparm -B 1 when leaving laptop mode. I think this must be a mistake--shouldn't it be 255, like LM_AC_HD_POWERMGMT? Note I can't reproduce the spin-down on AC problem at the moment (even though I'm positive it was happening before), so I can't test for sure that changing LM_AC_HD_POWERMGMT will stop it. I'm going to continue monitoring to see if I can get some hard data. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages laptop-mode-tools depends on: ii powermgmt-base1.22 Common utils and configs for power Versions of packages laptop-mode-tools recommends: ii acpid 1.0.4-2Utilities for using ACPI power man ii apmd 3.2.2-3Utilities for Advanced Power Manag ii hdparm6.1-2 tune hard disk parameters for high -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322842: udev: devices deleted/disabled on rmmod, not reinstated on modprobe
Package: udev Version: 0.065-1 Severity: normal I have had udev installed (because hal depends on it) for several months, and just encountered a problem which has me perplexed. I don't know much about udev, so I'm not sure whether my system is in an invalid state or how it might have gotten that way, so I'll just explain what I observe. I am running Debian kernel 2.6.11-1-686. I have udevd running, however my /dev directory is a normal disk filesystem and appears to be a traditional /dev (with hundreds of device files). There is no tmpfs mount for devfs. I recently had a problem with my sound driver (snd_intel8x0) which I tried to fix by removing it with rmmod and reinstalling with modprobe. After I did this, I found that alsaplayer would play sounds but firefox would not. It seems to be because firefox was looking for pre-alsa, OSS devices. I checked my /dev directory and found: % ls -l dsp* c- 1 root root 14, 3 2005-06-14 19:47 dsp0 crw-rw 1 root audio 14, 19 2005-06-14 19:47 dsp1 crw-rw 1 root audio 14, 35 2005-06-14 19:47 dsp2 crw-rw 1 root audio 14, 51 2005-06-14 19:47 dsp3 This didn't look right, so I changed the mode and owner of dsp0 to match the others, and added a dsp - dsp0 symlink (and did similar for mixer, audio, and adsp). Now firefox worked. I still wanted to understand what had caused the breakage, so I removed snd_intel8x0, and things went back to the above. I reinstalled snd_intel8x0 once again, and sure enough, the devices hadn't changed. So the situation seems to be that udevd is deleting devices when the module is unloaded, and not creating them when it is loaded. But I suspect the real problem may be that udevd is running, but I don't have a udev-created /dev. Since I've rebooted since installing udev, and haven't fiddled with udev configuration, I don't know how I've gotten into this situation. Let me know if I can give you more information. Andrew -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 0 lrwxrwxrwx 1 root root 20 2005-04-12 19:01 020_permissions.rules - ../permissions.rules lrwxrwxrwx 1 root root 12 2005-08-04 17:35 050_hal-plugdev.rules - ../hal.rules lrwxrwxrwx 1 root root 19 2005-04-12 19:01 cd-aliases.rules - ../cd-aliases.rules lrwxrwxrwx 1 root root 13 2005-04-12 19:01 udev.rules - ../udev.rules lrwxrwxrwx 1 root root 12 2005-07-04 14:33 z50_run.rules - ../run.rules lrwxrwxrwx 1 root root 19 2005-08-03 11:05 z60_alsa-utils.rules - ../alsa-utils.rules lrwxrwxrwx 1 root root 17 2005-07-04 14:33 z70_hotplugd.rules - ../hotplugd.rules -- /sys/: /sys/block/fd0/dev /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hda/hda3/dev /sys/block/hda/hda4/dev /sys/block/hda/hda5/dev /sys/block/hdc/dev /sys/block/loop0/dev /sys/block/loop1/dev /sys/block/loop2/dev /sys/block/loop3/dev /sys/block/loop4/dev /sys/block/loop5/dev /sys/block/loop6/dev /sys/block/loop7/dev /sys/block/ram0/dev /sys/block/ram1/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/class/coda/cfs0/dev /sys/class/coda/cfs1/dev /sys/class/coda/cfs2/dev /sys/class/coda/cfs3/dev /sys/class/coda/cfs4/dev /sys/class/input/event0/dev /sys/class/input/event1/dev /sys/class/input/event2/dev /sys/class/input/event3/dev /sys/class/input/mice/dev /sys/class/input/mouse0/dev /sys/class/input/mouse1/dev /sys/class/input/ts0/dev /sys/class/input/ts1/dev /sys/class/misc/agpgart/dev /sys/class/misc/hpet/dev /sys/class/misc/hw_random/dev /sys/class/misc/psaux/dev /sys/class/misc/rtc/dev /sys/class/misc/vmmon/dev /sys/class/printer/lp0/dev /sys/class/sound/timer/dev -- Kernel configuration: isapnp_init not present. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (800, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages udev depends on: ii hotplug 0.0.20040329-25 Linux Hotplug Scripts ii initscripts 2.86.ds1-1 Standard scripts needed for bootin ii libc62.3.5-3 GNU C Library: Shared libraries an ii libselinux1 1.24-2 SELinux shared libraries ii lsb-base 3.0-1 Linux Standard Base 2.0 init scrip ii makedev 2.3.1-78creates device files in /dev ii sed 4.1.4-2 The GNU sed stream editor udev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316810: loop-aes-source: clarify requirement for kernel-source
Apologies for not getting to this sooner. On Sun, Jul 31, 2005 at 09:07:18PM +0200, Max Vozeler wrote: Could you have a look at http://svn.hinterhof.net/viewcvs/loop-aes-source/trunk/debian/README.Debian?view=markup and ideally give me feedback whether it addresses your points, and/or which parts could be further improved? I think it is quite clear, thanks. Just one comment: On Sun, Jul 03, 2005 at 12:35:24AM -0700, Andrew Pimlott wrote: Second, I was surprised that I had to install the kernel-source package, but I didn't have to actually rebuild the kernel. Perhaps you could clarify that in the package description and/or README.Debian: Although you must have a full kernel source tree to build the loop-aes driver, it does not patch the kernel, so you don't need to rebuild. The newly build module will load into your old kernel. Using an unconfigured/uncompiled source tree will work most of the time, but is not actually safe or recommended. The loop-AES Makefile looks at a number of files in the source tree to determine build settings, and among them are Makefile and include/linux/autoconf.h which do not exist or do not contain correct settings in unconfigured trees. It is in fact strongly recommended to build the kernel one intends to use before using it to build loop-AES. I hope this requirement is now clearer in the new version of README.Debian. If not perhaps you see a possible better wording? I believe you are talking about a custom kernel here, yes? Because with the Debian kernel, and using module-assistant as recommended, it is not necessary to build the kernel. And even with a custom kernel, it is not necessary to rebuild after installing loop-aes-source. So I would still add something like this in the first paragraph: . . . are not sufficient. (However, you will not have to rebuild your kernel to use the loop-aes module.) Perhaps that seems obvious in light of the instructions, but personally, when I see that kernel source is required, I jump to the conclusion that I will need to rebuild. Third, the instructions for using make-kpkg to build loop-aes are a bit incomplete. If you follow the instructions, when you run make-kpkg, you will get hit with a zillion questions from make oldconfig (or at least I did). Perhaps best would be to get the .config that Debian uses, which can be copied from /boot. This step (copying /boot/config-$KVERS) and the observation from your other mail that --append-to-version is required would be useful to add. But - I decided to drop this entire section about building for official kernels using make-kpkg in favour of describing how one can use module-assistant to the same effect. I haven't tried it, from what I can read, that sounds like a good way to go. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#203269: Still present?
On Fri, Aug 05, 2005 at 05:33:15PM -0700, Daniel Burrows wrote: I haven't had any other reports of this bug, I've never seen it myself, and it refers to a rather old version of aptitude. Would you mind if I closed it to clear out the bug list a little? Please do--I haven't seen anything like it since. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#258399: xlibs: dvorak keyboard layout is missing right alt key
On Tue, Aug 02, 2005 at 10:44:39PM +0200, Denis Barbier wrote: On Sun, Jul 24, 2005 at 09:11:39PM -0700, Andrew Pimlott wrote: Shouldn't the line include level3(ralt_switch_multikey) (line 64) simply be removed from pc/dvorak? You are fully right. As there have been various problems with other changes in XKB stuff, I for one was reluctant to push this change in before sarge release. I plan working on XKB very soon, and will then commit this change. Cool, thanks! Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#258399: xlibs: dvorak keyboard layout is missing right alt key
I'm another dvorak user who is annoyed by this behavior, and from reading this bug log, I can't figure out what the difficulty is. Shouldn't the line include level3(ralt_switch_multikey) (line 64) simply be removed from pc/dvorak? This is part of the basic definition, and does not seem to belong there. In pc/us, the basic definition does not include such a line, only the intl and alt-intl definitions. Do some people need an intl version of pc/dvorak (besides those already present, eg fr and pl_basic)? If so, let them provide it; or if I must, I'll provide it, and they can fix it if it's broken. Meanwhile, let's fix the definition for 90% of users who just want both alt keys to work. If this is not the solution, can someone explain the problem in small words, and I promise I'll work on it. Andrew PS. Thanks a lot Adam for putting that song in your sig that is now stuck in my head. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319113: manpages-dev: getservent(3) is confusing about the size of s port
On Wed, Jul 20, 2005 at 09:28:47AM +0200, Michael Kerrisk wrote: The detail you point out is IP-specific. On the other hand, the 'services' file is protocol independent (yes, it mostly only contains IP-related entries nowadays), and valid port number range could be different in some protocols. So, it's not really appropriate (IMO) to change this man page. (See by the way ip(7), where the 'u_int16_t' data type makes clear the 16-bit nature of the port number for IP). ok, thanks for the explanation. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319109: cupsys-driver-gutenprint: syntax error on local ppd file
On Wed, Jul 20, 2005 at 08:49:14PM +0100, Roger Leigh wrote: I'll add the patch back in. Would you be willing to test the packages? thanks and sure -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319099: /etc/init.d/xfree86-common exists during rc.d purge
Package: xfree86-common Version: 6.8.2.dfsg.1-2 Severity: minor Trying to purge xfree86-common: Removing xfree86-common ... Purging configuration files for xfree86-common ... update-rc.d: /etc/init.d/xfree86-common exists during rc.d purge (use -f to force) I have not touched /etc/init.d/xfree86-common, so I don't know why it didn't get removed. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xfree86-common depends on: ii x11-common6.8.2.dfsg.1-3 X Window System (X.Org) infrastruc xfree86-common recommends no packages. -- debconf information: xfree86-common/experimental_packages: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319109: cupsys-driver-gutenprint: syntax error on local ppd file
Package: cupsys-driver-gutenprint
Version: 4.3.99+cvs20050715-1
Severity: normal
I just upgraded to cupsys-driver-gutenprint, purging
cupsys-driver-gimpprint and cupsys-driver-gimpprint-data. In the
output, I got a whole bunch of lines Writing ..., and then:
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `egrep -i -l Gutenprint|Gimp-Print
/etc/cups/ppd/Color-LaserJet-4600-v3010.107-Postscript-(recommended).ppd'
No Gutenprint PPD files to update.
/etc/cups/ppd/Color-LaserJet-4600-v3010.107-Postscript-(recommended).ppd
was a file I found via linuxprinting.org and installed with
gnome-cups-add.
The error comes from /usr/sbin/cups-genppdupdate.5.0, and it looks like
someone was sloppy around line 93. If you can assume a newer perl, I
believe you should be able to use something like
open PPDFILES, '-|', qw( egrep -i -l ), Gutenprint|Gimp-Print, @ppdglob
to avoid shell quoting problems. Actually, it seems like
open PPDFILES, egrep -i -l \Gutenprint|Gimp-Print\ *.{ppd,PPD}|
might do just as well.
Andrew
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages cupsys-driver-gutenprint depends on:
ii cupsys 1.1.23-11Common UNIX Printing System(tm) -
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libcupsimage2 1.1.23-11Common UNIX Printing System(tm) -
ii libcupsys2-gnutls10 1.1.23-11Common UNIX Printing System(tm) -
ii libgutenprint2 4.3.99+cvs20050715-1 runtime for the Gutenprint printer
ii libjpeg62 6b-10The Independent JPEG Group's JPEG
ii libperlmenu-perl4.0-2Menu and Template (curses-based) U
ii libpng12-0 1.2.8rel-1 PNG library - runtime
ii libtiff43.7.3-1 Tag Image File Format (TIFF) libra
ii perl5.8.7-4 Larry Wall's Practical Extraction
ii zlib1g 1:1.2.2-9compression library - runtime
Versions of packages cupsys-driver-gutenprint recommends:
ii gs-esp [postscript-viewer]7.07.1-9 The Ghostscript PostScript interpr
ii gs-gpl [postscript-viewer]8.15-1 The GPL Ghostscript PostScript int
ii gv [postscript-viewer]1:3.6.1-12 PostScript and PDF viewer for X
ii kghostview [postscript-viewer 4:3.3.2-2 PostScript viewer for KDE
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319113: manpages-dev: getservent(3) is confusing about the size of s_port
Package: manpages-dev Version: 2.02-2 Severity: minor I am not a C programmer, so I may be misunderstanding some convention, but the documentation in getservent(3) for s_port confused me. In the man page, its type is given as int, however it is actually a 16 bit value. It seems this ought to be mentioned to avoid confusion. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages manpages-dev depends on: ii manpages 2.02-2 Manual pages about using a GNU/Lin manpages-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#288928: remove all traces of Speedo
I upgraded xfonts-scalable in unstable, and it seems that this request (to remove Speedo fonts) was granted. However, /etc/X11/fonts/Speedo is still in xfonts-scalable.list, and: Unpacking replacement xfonts-scalable ... dpkg: warning - unable to delete old file `/usr/X11R6/lib/X11/fonts/Speedo': Directory not empty % ls /usr/X11R6/lib/X11/fonts/Speedo encodings.dir fonts.cache-1 fonts.dir fonts.scale % ls /etc/X11/fonts/Speedo xfonts-scalable.scale Personally, I lament this change, because while I never knew what those fonts were good for, I always thought it was cool to have a directory called Speedo. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317171: ipw2100-source: include patch for wpasupplicant
Package: ipw2100-source Version: 1.1.0-1 Severity: important The ipw2100 module built from this package does not work with the wpasupplicant version in unstable. See http://ipw2100.sourceforge.net/#patches http://ipw2100.sourceforge.net/patches/ipw2100-1.1.0-wpa_supplicant-0.4.x.patch Without this patch, I got bizarre and frustrating error messages from wpasupplicant. After applying it, wpasupplicant authenticates successfully. Yeah! Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages ipw2100-source depends on: ii debconf [debconf-2.0] 1.4.51 Debian configuration management sy ii debhelper 4.9.3 helper programs for debian/rules ii module-assistant 0.9.3 tool to make module package creati ipw2100-source recommends no packages. -- debconf information: * ipw2100/firmware_note: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317180: wpasupplicant: log somewhere
Package: wpasupplicant Version: 0.4.2-1 Severity: wishlist wpa_supplicant doesn't seem to log anywhere. I would expect it to log to daemon.log, like dhclient. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages wpasupplicant depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libssl0.9.7 0.9.7g-1 SSL shared libraries wpasupplicant recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316809: kernel-source-2.6.11: tell where to find the Debian .config
Package: kernel-source-2.6.11 Version: 2.6.11-7 Severity: wishlist I wanted to rebuild a kernel-image package starting with the same .config in the official Debian packages. One way to do this is to install the kernel-image package, which contains it in /boot/config-XXX, but it's annoying to install a huge kernel-image package you're just going to replace. It took me a good while to notice that the .config file is also in the kernel-headers package (obvious in retrospect), in /usr/src/kernel-headers-XXX/.config. That's also a big download for just that file, though I already happened to have it installed. Finally, I discovered that the kernel-image _source_ package is (contrary to intuition) a tiny little thing containing little other than the .configs. I would suggest either copying the .configs into the kernel-source package, or putting clear documentation into the kernel-source package, say in README.Debian: If you want to start with the same kernel .config used in the official Debian kernel-image package, get it from the _source_ package for the relevant kernel-image (don't worry, it's a small download). BTW, the kernel-headers-2.6.11-1 package contains /usr/share/doc/kernel-headers-2.6.11-1/config-2.6.11-1.gz matching /usr/src/kernel-headers-2.6.11-1/.config; however the kernel-headers-2.6.11-1-686 contains no such file in /usr/share/doc. Is that intentional? Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kernel-source-2.6.11 depends on: ii binutils 2.15-7 The GNU assembler, linker and bina ii bzip2 1.0.2-7high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities Versions of packages kernel-source-2.6.11 recommends: ii gcc 4:3.3.6-1The GNU C compiler ii libc6-dev [libc-dev]2.3.2.ds1-22 GNU C Library: Development Librari ii make3.80-9 The GNU version of the make util -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316810: loop-aes-source: clarify requirement for kernel-source
Package: loop-aes-source Version: 3.0d-1 Severity: wishlist I found a few things confusing when I decided to build the loop-aes driver. First, the package description didn't mention that I would need a kernel-source package, not just kernel-headers, so I had to go back and install that. You could probably also add a Recommends: kernel-source (or maybe Suggests:). Second, I was surprised that I had to install the kernel-source package, but I didn't have to actually rebuild the kernel. Perhaps you could clarify that in the package description and/or README.Debian: Although you must have a full kernel source tree to build the loop-aes driver, it does not patch the kernel, so you don't need to rebuild. The newly build module will load into your old kernel. Third, the instructions for using make-kpkg to build loop-aes are a bit incomplete. If you follow the instructions, when you run make-kpkg, you will get hit with a zillion questions from make oldconfig (or at least I did). Perhaps best would be to get the .config that Debian uses, which can be copied from /boot. Andrew -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages loop-aes-source depends on: ii build-essential 10.1 informational list of build-essent ii bzip2 1.0.2-7high-quality block-sorting file co ii debhelper 4.9.3 helper programs for debian/rules ii module-assistant 0.9.3 tool to make module package creati Versions of packages loop-aes-source recommends: ii kernel-package9.001 A utility for building Linux kerne -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316812: exim4-config: support simple virtual domain configuration
Package: exim4-config Version: 4.51-2 Severity: wishlist I'm sure this must come up often, but since I don't see a bug for it, I want to record it. I have simple virtual domain requirements, and I found that the configuration at http://www.debian-administration.org/articles/140 met my needs splendidly. Could something like this be added to exim4-config? Andrew -- Package-specific info: Exim version 4.51 #1 built 28-Jun-2005 18:05:34 Copyright (c) University of Cambridge 2005 Berkeley DB: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) Support for: iconv() IPv6 GnuTLS Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Configuration file is /var/lib/exim4/config.autogenerated -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages exim4-config depends on: ii adduser 3.64 Add and remove users and groups ii debconf [debconf-2.0] 1.4.51 Debian configuration management sy ii passwd1:4.0.3-35 change and administer password and exim4-config recommends no packages. -- debconf information: exim4/dc_noalias_regenerate: false exim4/dc_smarthost: * exim4/dc_relay_domains: * exim4/dc_relay_nets: * exim4/mailname: pimlott.net * exim4/dc_local_interfaces: 127.0.0.1 * exim4/dc_minimaldns: false exim4/exim3_upgrade: true * exim4/dc_other_hostnames: * exim4/dc_eximconfig_configtype: internet site; mail is sent and received directly using SMTP exim4/no_config: true exim4/hide_mailname: * exim4/dc_postmaster: andrew exim4/dc_readhost: * exim4/use_split_config: false exim4/internal/exim4-config.reconfigure: false exim4/exim4-config-title: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316810: loop-aes-source: clarify requirement for kernel-source
When I rebooted, I found another problem: The make-kpkg line needs to be something like make-kpkg --append-to-version -1-686 modules_image to match the suffix of the kernel-image-XXX package you're using. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316812: exim4-config: support simple virtual domain configuration
On Mon, Jul 04, 2005 at 07:25:27AM +0200, Marc Haber wrote: On Sun, Jul 03, 2005 at 06:34:24PM -0700, Andrew Pimlott wrote: I'm sure this must come up often, but since I don't see a bug for it, I want to record it. It comes up often, but the virtual domain requirements of different people are so different that I really don't want to have the work of supporting the gazillions of different wishes. Fair enough. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314327: exim4-config: passwd.client requires cannonical hostname
Package: exim4-config Version: 4.50-8 Severity: wishlist I just upgraded from exim to exim4 in the process of upgrading from Woody to Sarge. My ISP requires authentication, and in exim (3), I uncommented and modified the login: directive. In exim4, I found passwd.client and tried to use that instead. Unfortunatly, when I used my ISP's smarthost (smtp.sbcglobal.yahoo.com, as it is entered in Debconf) as the host part, it didn't work. I discovered the reason is that smtp.sbcglobal.yahoo.com is an alias for smtp-sbc-v1.mail.vip.sc5.yahoo.com, and when I put that in passwd.client, it works. Since I don't trust that to remain stable, I put * in passwd.client, which also works. However, obviously this is not a solution for everyone. If it would be feasible to allow using the non-cannonical hostname in passwd.client, I think it would save users some grief. If this is too difficult, at least it could be documented in README.SMTP-AUTH, and perhaps also in the passwd.client comments. Something like: Note: The hostname of the mail server must be the cannonical hostname. The hostname your ISP gives you (eg, mail.isp.com) may be an alias for the cannonical hostname, which you can find by running host mail.isp.com. However, if you always connect to the same smarthost, you might choose to enter the wildcard * to sidestep the issue. Andrew -- Package-specific info: Exim version 4.50 #1 built 27-May-2005 08:08:19 Copyright (c) University of Cambridge 2004 Berkeley DB: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) Support for: iconv() IPv6 GnuTLS Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to replace # the DEBCONFsomethingDEBCONF strings in the configuration template files. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='smarthost' dc_other_hostnames='*.pimlott.net:rassiga.com:pimlott.net' dc_local_interfaces='' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='smtp.sbcglobal.yahoo.com' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='false' dc_mailname_in_oh='true' mailname:pimlott.net -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (600, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.9-1-686-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages exim4-config depends on: ii adduser 3.63 Add and remove users and groups ii debconf [debconf-2.0] 1.4.51 Debian configuration management sy ii passwd 1:4.0.3-31sarge5 change and administer password and -- debconf information: exim4/dc_noalias_regenerate: false * exim4/dc_smarthost: smtp.sbcglobal.yahoo.com exim4/dc_relay_domains: * exim4/dc_relay_nets: * exim4/mailname: pimlott.net * exim4/dc_local_interfaces: * exim4/dc_minimaldns: false exim4/exim3_upgrade: true * exim4/dc_other_hostnames: *.pimlott.net:rassiga.com:pimlott.net * exim4/dc_eximconfig_configtype: mail sent by smarthost; received via SMTP or fetchmail exim4/no_config: true * exim4/hide_mailname: false exim4/dc_postmaster: exim4/dc_readhost: * exim4/use_split_config: false exim4/internal/exim4-config.reconfigure: false exim4/exim4-config-title: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310757: davfs2: doesn't enforce permissions
Package: davfs2 Version: 0.2.3-2 Severity: grave Tags: security Justification: user security hole It appears that davfs2 does not enforce unix permissions. I just mounted a DAV share as root. When I list permissions in the root of the mount, I see % ls -ld . drwxr-xr-x 1 root root 512 2005-05-25 11:43 . % ls -l total 950 -rwxr-xr-x 0 root root 6 2005-05-25 11:43 file drwxr-xr-x 1 root root512 2005-05-10 05:18 dir However, as a regular user, I can create and modify files with no restrictions. For example touch foo and echo hello file both work fine. I also tried mounting with mode=0700, and nothing changed, not even the permissions displayed. So it appears that there is no way to restrict access to the mounted DAV share. Also, on a possibly related note, I see that if I create a file with touch foo, foo has the permissions -rw-rw-r-- 0 root root 0 2005-05-25 11:48 foo However, if I unmount and remount, then the permissions revent to -rwxr-xr-x 0 root root 0 2005-05-25 11:48 foo Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages davfs2 depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libneon24 0.24.7.dfsg-2 An HTTP and WebDAV client library ii libssl0.9.70.9.7g-1 SSL shared libraries ii libxml22.6.16-7 GNOME XML library ii zlib1g 1:1.2.2-4 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304838: exim4-config: mail sent by smarthost; no local mail causes weird behavior wrt local delivery
[I was left out of the loop on replies to this bug that I filed.] Marc Haber [EMAIL PROTECTED] wrote: On Fri, Apr 15, 2005 at 09:14:35PM -0700, Andrew Pimlott wrote: I have just installed a Debian unstable machine and configured exim4 for mail sent by smarthost; no local mail. This has two weird effects (which I don't think are the same as bug 297841): (Throughout this message, I have replaced my domain with example.com.) 1. Mail to real-andrew is not delivered locally; instead, exim tries to deliver to [EMAIL PROTECTED] This is unreproducible here, it delivers fine to the smarthost: Maybe you misunderstood my example. I ran mail real-andrew, with no @domain, and it tried to deliver to [EMAIL PROTECTED] But the whole puprose (I thought) of real- addresses is that they will always be delivered locally, not sent to a smarthost or anywhere else. This is what the debconf question exim4/dc_postmaster says: Note that postmaster's mail should be read on the system to which it is directed, rather than being forwarded elsewhere, so (at least one of) the users you choose should not redirect their mail off this machine. Use a real- prefix to force local delivery. No. no local mail does really mean, no local mail, and the templates cannot be changed before sarge release. First, this puts the user in a difficult spot, because the debconf templates contain contradictory statements. I realize that changing templates has a high cost, but I would consider it worthwhile because the current wording is so confusing. Second, please consider supporting real- addresses in all configurations. Since people have to ask for local delivery explicitly, it seems unlikely that it would cause problems. Moreover, I think many users would like a no local mail except for system messages option, and this change would provide it. If you will not make this change, I would at least clarify in Debconf that no local mail means even system messages. And what will you recommend that users enter for dc_postmaster? Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#273296: mozilla-browser: don't go to mozilla.org the first time the browserer is started after an upgrade
ROBERTOJIMENOCA [EMAIL PROTECTED] wrote: What page is that? Do you know if this bug is filled upstream? Mozilla and Debian have different priorities, so I don't expect this suggestion would receive a warm reception at Mozilla, and I don't have the patience to argue with them. In Debian, upgrades of the entire system are forgettably routine, whereas Mozilla thinks that a new browser version is a major life event. Besides, I've been using Firefox for a while, which doesn't have this problem. I don't know whether Mozilla still does. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309530: mozilla-firefox: emacs key shortcuts not recognized
Ok, I've figured out that killing gnome-settings-daemon restores my settings in ~/.gtkrc-2.0. All I can say is, holy crap is this bad design! My configuration varies depending on whether some daemon happens to be running?! The daemon asserts its defaults ahead of the settings I've explicitly typed into my ~/.gtkrc-2.0?! gnome-settings-daemon seems to have been started by some other program I ran. Is there some way of ensuring that it never gets started, or of asking it to defer to my ~/.gtkrc-2.0? BTW, README.Debian should be updated, because now even gnome-keybinding-properties doesn't permit setting Emacs bindings. Not to mention that as soon as I run it, it undoes the key mappings I have set with xmodmap. Message to GNOME people: Please give some consideration in your designs to leaving things alone when you have not been asked to get involved. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309530: mozilla-firefox: emacs key shortcuts not recognized
On Fri, May 20, 2005 at 09:34:36PM +0200, Loïc Minier wrote: When you reassigned this bug to Gtk, I thought I had seen a web page explaining all of this, but I couldn't get my hand on it again. Guess what? I've found it: http://kb.mozillazine.org/Emacs_Keybindings_(Firefox) Thanks, I think I saw that at one point too. This ain't Firefox specific, and it will tell that there are two layers: the Gtk configuration, and the GNOME configuration of Gtk, the second being edited via gconf. This isn't very useful if one is used some of the time, and the other is used other times, and the difference is something that is invisible to the user (whether gnome-session-daemon is running). Really, this is a terrible user experience. Besides, the gtkrc-2.0 settings have been documented for some time, and since they are explicitly entered, they should override any default gnome-sesson-daemon settings. Could you please follow the suggestion on the page I pointed you to and report whether that helped? I make a quick test, and changing the setting with gconf-editor (as described on that page) it does fix the keybindings. However, gnome-settings-daemon still breaks my keyboard configuration when it starts, because it (seemingly) reasserts my XKB settings, overwriting the changes I added with xmodmap. I can see no way to turn this off. So the real solution for me is preventing gnome-settings-daemon from running. If it did, I would be glad to complement the README.Debian of libgtk2.0-0 and eventually will suggest Gtk 2 apps getting report of the problem to link to this file. Yes, that would be good. Message to GNOME people: Please give some consideration in your designs to leaving things alone when you have not been asked to get involved. PS: Your rant doesn't reach GNOME people and is useless in this form. I must add that Gtk and GNOME people are quite close-working, so your reproach isn't well-targetted. Well, since this bug is now on Gtk, I thought it might be a good channel. But maybe I'll paste some of this text into a GNOME bug report (where it can get ignored because it doesn't affect GNOME-centric users). Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309530: mozilla-firefox: emacs key shortcuts not recognized
http://bugzilla.gnome.org/304911 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309530: mozilla-firefox: emacs key shortcuts not recognized
On Fri, May 20, 2005 at 11:28:19PM +0200, Loïc Minier wrote: On Fri, May 20, 2005, Andrew Pimlott wrote: This isn't very useful if one is used some of the time, and the other is used other times, and the difference is something that is invisible to the user (whether gnome-session-daemon is running). Really, this is a terrible user experience. Besides, the gtkrc-2.0 settings have been documented for some time, and since they are explicitly entered, they should override any default gnome-sesson-daemon settings. This is a point of view, I can't talk for the intentions of upstream, but you might consider the fact that a GConf override might be easier to implement in a large workstations parc. I wouldn't mind an override if I had asked for it. But anyway, it seems that GTK is designed so that only one of GConf and .gtkrc is used at a time, and that doesn't seem likely to change. I think you refer to a different bug here, related to your XKB configuration under GNOME, is this correct? Right, I realize I'm mixing issues, and this doesn't have to do with GTK. Sorry. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309530: mozilla-firefox: emacs key shortcuts not recognized
Package: mozilla-firefox Version: 1.0.4-1 Severity: important All emacs shortcuts in text inputs are gone in the latest firefox upgrade. For example, start firefox and click in the location bar. If I press ctrl-a, it selects the whole URL instead of moving to the beginning. If I press ctrl-w, it closes the window instead of deleting a word. I don't believe I've changed any settings. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages mozilla-firefox depends on: ii debianutils 2.13.2 Miscellaneous utilities specific t ii fontconfig 2.3.2-1 generic font configuration library ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libc62.3.2.ds1-22GNU C Library: Shared libraries an ii libfontconfig1 2.3.2-1 generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcc1 1:3.4.3-13 GCC support library ii libglib2.0-0 2.6.4-1 The GLib library of C routines ii libgtk2.0-0 2.6.4-3 The GTK+ graphical user interface ii libidl0 0.8.5-1 library for parsing CORBA IDL file ii libjpeg626b-10 The Independent JPEG Group's JPEG ii libkrb53 1.3.6-3 MIT Kerberos runtime libraries ii libpango1.0-01.8.1-1 Layout and rendering of internatio ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libstdc++5 1:3.3.6-5 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-13 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-13 X Window System miscellaneous exte ii libxft2 2.1.7-1 FreeType-based font drawing librar ii libxp6 4.3.0.dfsg.1-13 X Window System printing extension ii libxt6 4.3.0.dfsg.1-13 X Toolkit Intrinsics ii psmisc 21.6-1 Utilities that use the proc filesy ii xlibs4.3.0.dfsg.1-13 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309530: mozilla-firefox: emacs key shortcuts not recognized
On Tue, May 17, 2005 at 02:32:24PM -0700, Andrew Pimlott wrote: FWIW, I upgraded my gtk packages from 2.6.4-1 to 2.6.4-3 at the same time I upgraded firefox, so it could be gtk's fault. Hmm I see similar behavior in GAIM, so it smells like a GTK problem. I'll try reopening and reassigning the bug. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309530: mozilla-firefox: emacs key shortcuts not recognized
On Tue, May 17, 2005 at 05:11:58PM -0400, Eric Dorland wrote: Look in the README.Debian. Argh, I only checked the changelog.Debian. Actually, the README.Debian says that the behavior changed for firefox 1.0, and for me Emacs keys were working in 1.0.3. In fact, I have had a .gtkrc-2.0 with gtk-key-theme-name = Emacs all along. So the real problem is that firefox has evidently stopped honoring that setting. FWIW, I upgraded my gtk packages from 2.6.4-1 to 2.6.4-3 at the same time I upgraded firefox, so it could be gtk's fault. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308126: unison: please mention in NEWS.Debian when archive format changes
Package: unison Version: 2.10.2-1 Severity: wishlist It's a pretty significant event for unison users when the archive format changes. If I have any unsynchronized changes when I upgrade to a new archive format, I have to merge them all by hand. I think a warning in NEWS.Debian would be appropriate in this situation. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages unison depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307743: pcsc-lite: does not build with debugging by default
Package: pcsc-lite Severity: minor The pcsc-lite source package builds without debugging (-g) by default, in violation of policy 10.1[1]. I believe you copied a faulty example out of an older version of policy; the current example should work correctly. Thanks, Andrew [1] http://www.debian.org/doc/debian-policy/ch-files.html -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307446: xfonts-terminus: files left behind on upgrade
Package: xfonts-terminus Version: 4.12-2 Severity: minor During upgrade: Preparing to replace xfonts-terminus 4.12-1 (using .../xfonts-terminus_4.12-2_all.deb) ... Unpacking replacement xfonts-terminus ... dpkg: warning - unable to delete old file `/usr/share/fonts/bitmap/terminus': Directory not empty dpkg: warning - unable to delete old file `/usr/share/fonts/bitmap': Directory not empty And: % find /usr/share/fonts/bitmap /usr/share/fonts/bitmap /usr/share/fonts/bitmap/fonts.cache-1 /usr/share/fonts/bitmap/terminus /usr/share/fonts/bitmap/terminus/fonts.cache-1 Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xfonts-terminus depends on: ii xutils 4.3.0.dfsg.1-12.0.1 X Window System utility programs -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306975: sharutils: uudecode -m does not decode base64, as documented
Package: sharutils Version: 1:4.2.1-13 Severity: minor uudecode(1): If the option -m is given on the command line base64 encoding is used instead. % uudecode -m uudecode: invalid option -- m Try `uudecode --help' for more information. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages sharutils depends on: ii debianutils 2.13.2 Miscellaneous utilities specific t ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306975: sharutils: uudecode -m does not decode base64, as documented
On Fri, Apr 29, 2005 at 09:54:37PM +0200, Santiago Vila wrote: On Fri, 29 Apr 2005, Andrew Pimlott wrote: % uudecode -m uudecode: invalid option -- m Try `uudecode --help' for more information. SYNOPSIS --- uuencode [-m] [ file ] name doh. That's really lame, but not a bug I guess. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303582: offlineimap: 'EOF occurred in violation of protocol' with uw-imapd
On Mon, Apr 11, 2005 at 08:41:37AM -0500, John Goerzen wrote: UW-IMAPd is known to do weird things like this, unfortunately. I'd say about 2/3 of the problems people have with OfflineIMAP are with UW-IMAPd servers. Ok, I've canned UW-IMAPd and installed dovecot. (Actually, I think I made a dumb mistake configuring OfflineIMAP when I was using UW-IMAPd, but that's irrelevant now.) Another problem with uw-imapd is that whenever I access a mailbox via IMAP, even if I do not save any changes, it saves the mbox changing message statuses from N to O. I would like to imapd to leave messages in the N status unless my mail client changes it. This may or may not be possible, depending on your specific IMAP server. I asked about this on the dovecot mailing list, and got an answer that is attached. offlineimap certainly takes every effort to avoid changing flags on messages during a download, but some IMAP servers will treat any download as a read. In any case, once a message is read on a local client, that does change a flag that OfflineIMAP will propogate back, and it should result in the N and O being removed. Alternatively, if you use IMAP or OfflineIMAP clients for all your mailbox accesses, you should have no trouble (IMAP does not differentiate between N and O). The issue is that the N versus O state is very meaningful to me. It's pretty important to the way I read mail that all messages I've never seen have the N state. If I were to sync with OfflineIMAP, but then actually read my mail on the server, and all the Ns were gone, it would bug me. Andrew ---BeginMessage--- There are two relevant flags associated with a message in IMAP, SEEN and RECENT. New messages might be considered unread ones (don't have the SEEN flag set) or recent ones. The client gets to modify SEEN, which it typically does when it reads the message. The server is the only thing that can modify RECENT, which it does when it has notified a client that has SELECT-ed (i.e. opened) the folder about new messages. I assume offlineimap is behaving just like a normal client and SELECT-ing the folder in order to download messages. If it doesn't want to change the RECENT status, then it should use EXAMINE (opens mailbox readonly) instead of SELECT. Likewise, it shouldn't set the SEEN flag unless it wants to signal that the message has been read. In other words, Dovecot is behaving correctly as far as I can tell, and offlineimap is probably to blame. See RFC 3501 (e.g. http://rfc.net/rfc3501.html#s2.3.2.;) for details! Best Wishes, Chris On Tue, 19 Apr 2005 17:03:49 -0700 Andrew Pimlott [EMAIL PROTECTED] wrote: Hi. I'm new to IMAP, but just tried uw-imapd and then dovecot in conjuction with offlineimap. I'm using Debian package version 0.99.14-1 and have my mail in mbox format. One of the first things that annoys me about both programs is that as soon as you read a mailbox over imap, the imapd changes all new messages to old. It seems to have the assumption that the IMAP client is reading the messages, but particularly in the case of offlineimap, this assumption is not justified: I might not read the message on the client on which I've just synced, I might read it on the server or another client. So I would like dovecot to leave the mailbox alone, and leave it up to the client to write any changes to message status. Is there any option to dovecot that would accomplish this? --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-- Christopher Wakelin,[EMAIL PROTECTED] IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094 ---End Message---
Bug#303582: offlineimap: 'EOF occurred in violation of protocol' with uw-imapd
On Thu, Apr 21, 2005 at 01:31:04PM -0500, John Goerzen wrote: OK, they do have a point about EXAMINE. OfflineIMAP currently' doesn't do that for performance reasons (it would have to re-SELECT the same folder if it were to have to modify it later). But it could. The mechanics of handling \Recent are also not trivial but doable. I'll go ahead and leave this open but I don't think I'll have time to work on it soonish. No problem. I haven't even settled on using OfflineIMAP; I'm just testing the waters. One other thing might be to suggest treating the absence of any flag as I've seen it and (N or O) as I've not seen it. Well, three states is kind of nice. But I'm thinking about revising my mail habits, so anything's up for consideration Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305069: mutt: extra redraw, scroll when resuming
Package: mutt Version: 1.5.9-1 Severity: normal Starting with the upgrade to 1.5.8, mutt has displayed a weird behavior when resuming from a suspend while displaying the message index. What appears to happen is, it initially redraws the screen as it was before, as expected; but then it immediately draws the screen again, this time scrolling so that the selected message is at the bottom of the screen. (Or, with nomenu_scroll, so that the index is at a natural page.) Even if was already in this position, so that no scrolling is done, the redraw is visible as an annoying flash. To reproduce, open a mailbox (with menu_scroll set) with more than one screen-full of messages, go to the end, then go up one message, so that you are on the second to last line of the index. Suspend with ctrl-Z and resume. You should see that the index is scrolled so that the message you are on is now the last line of the index. Andrew -- System Information: Debian Release: 3.0 APT prefers unstable APT policy: (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-686-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages mutt depends on: ii exim [mail-transport-agent] 3.35-1woody4 An MTA (Mail Transport Agent) ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libdb4.34.3.27-2 Berkeley v4.3 Database Libraries [ ii libgnutls11 1.0.16-13GNU TLS library - runtime library ii libidn110.5.13-1.0 GNU libidn library, implementation ii libncursesw55.4-4Shared libraries for terminal hand ii libsasl22.1.19-1.5 Authentication abstraction library -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304838: exim4-config: mail sent by smarthost; no local mail causes weird behavior wrt local delivery
Package: exim4-config Version: 4.50-5 Severity: normal I have just installed a Debian unstable machine and configured exim4 for mail sent by smarthost; no local mail. This has two weird effects (which I don't think are the same as bug 297841): (Throughout this message, I have replaced my domain with example.com.) 1. Mail to real-andrew is not delivered locally; instead, exim tries to deliver to [EMAIL PROTECTED] Since root is aliased to real-andrew, this means that system messages are not delivered. The debconf questions imply that real- mail should be delivered locally even with mail sent by smarthost; no local mail. 2. Mail to [EMAIL PROTECTED] fails with 451 Temporary local problem. The log message looks bizarre: 2005-04-15 13:12:40 H=localhost [127.0.0.1]:33800 I=[127.0.0.1]:25 U=andrew F=[EMAIL PROTECTED] temporarily rejected RCPT [EMAIL PROTECTED]: error in redirect data: domain missing or malformed in andrew@ I don't know where andrew@ came from. I think that @localhost mail should be delivered locally even with mail sent by smarthost; no local mail, especially since that's what fetchmail uses. However, even if you want to reject such mail, the error status and log message should probably made more clear. Andrew -- Package-specific info: Exim version 4.50 #1 built 03-Apr-2005 07:22:57 Copyright (c) University of Cambridge 2004 Berkeley DB: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) Support for: iconv() IPv6 GnuTLS Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # This is a Debian specific file dc_eximconfig_configtype='satellite' dc_other_hostnames='' dc_local_interfaces='127.0.0.1' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='mail.example.com' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='false' dc_mailname_in_oh='true' mailname:example.com -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages exim4-config depends on: ii adduser 3.63 Add and remove users and groups ii debconf [debconf-2.0] 1.4.48 Debian configuration management sy ii passwd 1:4.0.3-31sarge2 change and administer password and -- debconf information: exim4/dc_noalias_regenerate: false * exim4/dc_smarthost: mail.example.com exim4/dc_relay_domains: exim4/dc_relay_nets: * exim4/mailname: example.com * exim4/dc_local_interfaces: 127.0.0.1 * exim4/dc_minimaldns: false exim4/exim3_upgrade: true * exim4/dc_other_hostnames: * exim4/dc_eximconfig_configtype: mail sent by smarthost; no local mail exim4/no_config: true * exim4/hide_mailname: false * exim4/dc_postmaster: real-andrew * exim4/dc_readhost: * exim4/use_split_config: false exim4/exim4-config-title: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304845: tasksel: desktop task has incomplete printing support
On Fri, Apr 15, 2005 at 06:53:37PM -0400, Joey Hess wrote: There's a print server task on the same screen that will install printer support. Sure, but a user who just wants to print probably won't select print server. If cups is the standard way to print from GNOME, it seems it should be installed with desktop. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304701: fetchmail: uidl is on by default
Package: fetchmail Version: 6.2.5-12 Severity: minor I set up fetchmail with a POP3 server without using the uidl option, and was confused to see it using a .fetchids file anyway. I discovered that fetchmail tries to use UIDL even if not configured to, if the LAST command is not supported by the server (pop3.c starting at line 828 in the Debian source). This should probably be documented. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages fetchmail depends on: ii adduser 3.63 Add and remove users and groups ii base-files 3.1.2Debian base system miscellaneous f ii debconf 1.4.48 Debian configuration management sy ii debianutils 2.13.2 Miscellaneous utilities specific t ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libssl0.9.7 0.9.7e-3 SSL shared libraries -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303582: offlineimap: 'EOF occurred in violation of protocol' with uw-imapd
Package: offlineimap
Version: 4.0.9
Severity: normal
I installed uw-imapd-ssl 4:2001adebian-6 from woody on my mail server,
and tried to access it with offlineimap from unstable. I got the
following error:
% offlineimap -u TTY.TTYUI
OfflineIMAP 4.0.8 (Rev 592)
Copyright (C) 2002 - 2004 John Goerzen [EMAIL PROTECTED]
This software comes with ABSOLUTELY NO WARRANTY; see the file
COPYING for details. This is free software, and you are welcome
to distribute it under the conditions laid out in COPYING.
Account sync madstop:
* Processing account madstop
Account sync madstop:
Copying folder structure from IMAP to MappedIMAP
Account sync madstop:
Establishing connection to madstop.pimlott.net:993.
madstop: Enter password:
Account sync madstop:
Establishing connection to madstop.pimlott.net:993.
madstop: Enter password:
Folder sync madstop[mail/test]:
Syncing mail/test: IMAP - MappedIMAP
Copy message 1 from mail/test:
Copy message 1 IMAP[mail/test] - MappedIMAP[mail/test],
LocalStatus[mail.test]
Thread 'Copy message 1 from mail/test' terminated with exception:
Traceback (most recent call last):
File /usr/lib/python2.3/site-packages/offlineimap/threadutil.py, line 153,
in run
Thread.run(self)
File /usr/lib/python2.3/threading.py, line 422, in run
self.__target(*self.__args, **self.__kwargs)
File /usr/lib/python2.3/site-packages/offlineimap/folder/Base.py, line 276,
in copymessageto
newuid = object.savemessage(uid, message, flags)
File /usr/lib/python2.3/site-packages/offlineimap/folder/UIDMaps.py, line
156, in savemessage
newluid = self._mb.savemessage(self, -1, content, flags)
File /usr/lib/python2.3/site-packages/offlineimap/folder/IMAP.py, line 224,
in savemessage
date, content)[0] == 'OK')
File /usr/lib/python2.3/site-packages/offlineimap/imaplib.py, line 319, in
append
return self._simple_command(name, mailbox, flags, date_time)
File /usr/lib/python2.3/site-packages/offlineimap/imaplib.py, line 976, in
_simple_command
return self._command_complete(name, apply(self._command, (name,) + args))
File /usr/lib/python2.3/site-packages/offlineimap/imaplib.py, line 778, in
_command
while self._get_response():
File /usr/lib/python2.3/site-packages/offlineimap/imaplib.py, line 824, in
_get_response
resp = self._get_line()
File /usr/lib/python2.3/site-packages/offlineimap/imaplib.py, line 917, in
_get_line
line = self.readline()
File /usr/lib/python2.3/site-packages/offlineimap/imaplib.py, line 1149, in
readline
return self.sslobj.readline()
File /usr/lib/python2.3/site-packages/offlineimap/imaplib.py, line 1091, in
readline
linebuf = self.read(1024)
File /usr/lib/python2.3/site-packages/offlineimap/imaplib.py, line 1082, in
read
retval = self._read(n)
File /usr/lib/python2.3/site-packages/offlineimap/imaplib.py, line 1070, in
_read
return self.sslsock.read(n)
sslerror: (8, 'EOF occurred in violation of protocol')
Last 12 debug messages logged for Copy message 1 from mail/test prior to
exception:
imap: Returned object from fetching 1: ('OK', [('1 (UID 1 BODY[] {693}',
'Return-path: [EMAIL PROTECTED]\r\nEnvelope-to: [EMAIL PROTECTED]: Thu, 07
Apr 2005 07:43:23 -0700\r\nReceived: from andrew by madstop.pimlott.net with
local (Exim 3.35 #1 (Debian))\r\n\tid 1DJYE7-0002J3-00\r\n\tfor [EMAIL
PROTECTED]; Thu, 07 Apr 2005 07:43:23 -0700\r\nDate: Thu, 7 Apr 2005 07:43:23
-0700\r\nFrom: Andrew Pimlott [EMAIL PROTECTED]\r\nTo: Andrew Pimlott [EMAIL
PROTECTED]\r\nSubject: test\r\nMessage-ID: [EMAIL
PROTECTED]\r\nMime-Version: 1.0\r\nContent-Type: text/plain;
charset=us-ascii\r\nContent-Disposition: inline\r\nUser-Agent:
Mutt/1.5.6+20040907i\r\nX-Bogosity: Ham, tests=bogofilter, spamicity=0.42,
version=0.94.1\r\nContent-Length: 0\r\nLines: 0\r\n\r\n'), ')'])
imap: savemessage: called
imap: savemessage: using date 7-Apr-2005 07:43:23 -0800
imap: savemessage: initial content is: 'Return-path: [EMAIL
PROTECTED]\r\nEnvelope-to: [EMAIL PROTECTED]: Thu, 07 Apr 2005 07:43:23
-0700\r\nReceived: from andrew by madstop.pimlott.net with local (Exim 3.35 #1
(Debian))\r\n\tid 1DJYE7-0002J3-00\r\n\tfor [EMAIL PROTECTED]; Thu, 07 Apr
2005 07:43:23 -0700\r\nDate: Thu, 7 Apr 2005 07:43:23 -0700\r\nFrom: Andrew
Pimlott [EMAIL PROTECTED]\r\nTo: Andrew Pimlott [EMAIL
PROTECTED]\r\nSubject: test\r\nMessage-ID: [EMAIL
PROTECTED]\r\nMime-Version: 1.0\r\nContent-Type: text/plain;
charset=us-ascii\r\nContent-Disposition: inline\r\nUser-Agent:
Mutt/1.5.6+20040907i\r\nX-Bogosity: Ham, tests=bogofilter, spamicity=0.42,
version=0.94.1\r\nContent-Length: 0\r\nLines: 0\r\n\r\n'
imap: savemessage: new headers are:
X-OfflineIMAP-1507185133-6d616473746f70-6d61696c2f74657374:
1112887115-0251739269695-v4.0.8
imap: savemessage_addheader: called to add
X-OfflineIMAP-1507185133-6d616473746f70-6d61696c2f74657374:
1112887115-0251739269695-v4.0.8
imap: savemessage_addheader: insertionpoint = 33
imap
Bug#303612: uw-imapd: on upgrade from woody, no ports are activated in inetd.conf
Package: uw-imapd Version: 7:2002edebian1-9 Severity: normal I just upgraded from uw-imapd-ssl in woody to uw-imapd from unstable. I took the default answers to the new debconf questions, in particular, listen on imap2 and imaps, and do not enforce port selection. My previous uw-imapd-ssl configuration listened on the same two ports in inetd.conf; however, after upgrading, there were no imap entries in inetd.conf. I'm guessing that the new package chose not to enforce the port selections, because I was upgrading. However, since this is the first time I saw the debconf questions, I expected my choices to be honored this time. When I changed my answer to the enforce question to yes, the lines were added to inetd.conf as expected. It seems that this could trip people upgrading from woody, so it would be good to create a better transition. When upgrading from a pre-debconf version, the selected ports should probably be enforced unconditionally. Andrew -- System Information: Debian Release: 3.0 APT prefers unstable APT policy: (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-686-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages uw-imapd depends on: ii debconf 1.4.46 Debian configuration management sy ii libc-client2002edebian 7:2002edebian1-9 UW c-client library for mail proto ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libcomerr2 1.36release-1common error description library ii libkrb531.3.6-1 MIT Kerberos runtime libraries ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g0.76-22 Pluggable Authentication Modules l ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii openssl 0.9.6c-2.woody.7 Secure Socket Layer (SSL) binary a -- debconf information: * uw-imapd/force_debconf_choice: false * uw-imapd/protocol: imap2, imaps -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300667: translation dictionaries on dict.org
On Mon, Mar 21, 2005 at 10:07:00PM -0500, Rik Faith wrote: I've added an english and a trans virtual dictionary to the dict.org and test.dict.org servers. The default is still to show everything -- it demonstrates the fine freedict.org work that I've been remiss in not showing off sooner. It seems that right now, both using the dict client and www.dict.org, I get only english dictionaries by default. Which is very comfortable for me, but it doesn't sound like what you intended. I understand your wish to showcase all the free dictionaries by default--it's very impressive. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300667: translation dictionaries on dict.org
On Mon, Mar 21, 2005 at 10:10:23AM -0500, Rik Faith wrote: I could add a virtual dictionary of non-translating dictionaries that is not normally searched. Then you could search in, e.g., the non-translating database -- then you could depend on me to keep it up to date when I change the databases served. I'll explore this option this week or next and let you know. Thanks, that seems like a good solution. You could also make a virtual dictionary of just the translating dictionaries, for when people want that. I filed a Debian bug[1] to track this issue. If you reply-all to this message, your response will be added to the bug log. Sure, but I don't see how this is a Debian bug? It's not, but 1) the Debian maintainer usually knows how to route the issue to right person, 2) sometimes (eg if upstream is unresponsive, not in this case) Debian will make its own fix, and 3) the Debian BTS gives an issue visibility and a communications channel it might not otherwise have. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300667: dict.org returns useless foreign translations
Package: dict Version: 1.9.15-1 Severity: wishlist dict has recently started returning translations into various languages. While this is cool, it's not what I've come to expect from dict and is generally useless to me when I want to know what a word means. (It helps that these entries are at the end, so I can stop reading when I see them, but they are still distracting.) The cause is the addition of translation dictionaries to dict.org, and there doesn't appear to be a straight-forward way to leave this class of dictionaries out of searches. I will email [EMAIL PROTECTED] about this, but I wanted to file a Debian bug for tracking and because perhaps the Debian package can work around the problem. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages dict depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii netbase 4.20 Basic TCP/IP networking system ii recode 3.6-10 Character set conversion utility 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#300667: translation dictionaries on dict.org
Hi. I use the dict client all the time, and noticed that dict.org recently added translation dictionaries to the default list. This is a cool idea, but it's kind of annoying to run dict looking for a definition and get a long list of translations at the end. There doesn't seem to be any easy way to omit these dictionaries on my end (other than enumerating all the dictionaries I want, which list is ever-changing), so I'm wondering if you have a solution. Perhaps the translation dictionaries should be moved to a different dict server, or a feature should be added to select a class of dictionaries. (I don't know anything about the dict protocol, so I don't know whether this is feasible.) I filed a Debian bug[1] to track this issue. If you reply-all to this message, your response will be added to the bug log. Thanks, Andrew [1] http://bugs.debian.org/300667 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299892: make: stripping leading ./ causes flaky results
Package: make Version: 3.80-9 Severity: minor [This bug was sent to bug-make@gnu.org, but since I haven't received a reply, I'm posting it here so there is a record.] make is doing something funny in the area of stripping the leading ./ from filenames. I can demonstrate with the following Makefile, which is also attached so you get a copy without whitespace damage. files := $(shell find . -type f -print) objects: $(addprefix ./, $(files)) install: $(addprefix /home/andrew/, $(files)) $(addprefix /home/andrew/, $(files)): /home/andrew/%: ./% true $ Put this in an empty directory, then create some files, eg for i in $(seq 1 10); do touch foo$i; done and run make install Output: true foo1 true foo2 true foo3 true foo4 true ./foo5 true foo6 true foo7 true foo8 true ./foo9 true foo10 true Makefile Funny, huh? I gave a little attempt to tracking it down. I thought maybe parse_file_seq was at fault, but it seems to give correct results. Then, I looked at the output of make -r -p install (attached). Looking at the Not a target entries, I see foo5, ./foo5, and foo4, but no ./foo4. So it seems that for some reason foo5 has an entry under both names and they are aliased in some way. I can't imagine why this only afflicts some files. Also, I noticed that if I comment out the second line of the Makefiles (which defines the unused objects target), the output is: true ./foo1 true ./foo2 true ./foo3 true ./foo4 true ./foo5 true ./foo6 true ./foo7 true ./foo8 true ./foo9 true ./foo10 true ./Makefile This seems to be a mostly cosmetic bug, but the aliasing is somewhat worrying. My make is 3.80 in Debian GNU/Linux unstable. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages make depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information files := $(shell find . -type f -print) objects: $(addprefix ./, $(files)) install: $(addprefix /home/andrew/, $(files)) $(addprefix /home/andrew/, $(files)): /home/andrew/%: ./% true $ # GNU Make 3.80 # Copyright (C) 2002 Free Software Foundation, Inc. # This is free software; see the source for copying conditions. # There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. true foo1 true foo2 true foo3 true foo4 true ./foo5 true foo6 true foo7 true foo8 true ./foo9 true foo10 true make_data_base true Makefile # Make data base, printed on Mon Feb 28 16:23:46 2005 # Variables # automatic D = $(patsubst %/,%,$(dir $)) # automatic ?F = $(notdir $?) # environment RLPR_PRINTHOST = 10.16.16.20 # default CWEAVE = cweave # automatic ?D = $(patsubst %/,%,$(dir $?)) # automatic @D = $(patsubst %/,%,$(dir $@)) # environment XAUTHORITY = /home/andrew/.Xauthority # automatic @F = $(notdir $@) # default CURDIR := /home/andrew/proj/web/apn/test # makefile SHELL = /bin/sh # default RM = rm -f # default CO = co # environment HZ = 100 # environment _ = /usr/bin/make # default PREPROCESS.F = $(FC) $(FFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -F # default LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH) # default OUTPUT_OPTION = -o $@ # environment HUSHLOGIN = FALSE # default COMPILE.cpp = $(COMPILE.cc) # makefile (from `Makefile', line 1) MAKEFILE_LIST := Makefile # default LINK.p = $(PC) $(PFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) # default CC = cc # default COMPILE.f = $(FC) $(FFLAGS) $(TARGET_ARCH) -c # default CHECKOUT,v = +$(if $(wildcard $@),,$(CO) $(COFLAGS) $ $@) # default CPP = $(CC) -E # default LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) # environment PATH = /home/andrew/bin:/usr/sbin:/sbin:/home/andrew/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games # default LD = ld # default TEXI2DVI = texi2dvi # environment FVWM_USERDIR = /home/andrew/.fvwm # default YACC = yacc # makefile (from `Makefile', line 1) files := ./foo1 ./foo2 ./foo3 ./foo4 ./foo5 ./foo6 ./foo7 ./foo8 ./foo9 ./foo10 ./make_data_base ./Makefile # default COMPILE.mod = $(M2C) $(M2FLAGS) $(MODFLAGS) $(TARGET_ARCH) # default ARFLAGS = rv # default LINK.r = $(FC) $(FFLAGS) $(RFLAGS) $(LDFLAGS) $(TARGET_ARCH) # environment WINDOWID = 33554448 # environment FVWM_MODULEDIR = /usr/lib/fvwm/2.5.12 # default LINT.c = $(LINT) $(LINTFLAGS) $(CPPFLAGS) $(TARGET_ARCH) # default LINT = lint # default YACC.y = $(YACC) $(YFLAGS) # default AR = ar # default TANGLE = tangle # environment LS_COLORS =
Bug#297340: make: tilde expansion does not work as in the shell
Package: make Version: 3.80-9 Severity: minor In the shell (tested with bash and zsh), ~/foo expands to /home/andrew/foo whether or not this file exists. In make, it expands only when the file exists; otherwise, it expands to the empty string. Here is an example: % echo ~/foo /home/andrew/foo % ls ~/foo ls: /home/andrew/foo: No such file or directory % cat Makefile all: true $(wildcard ~/foo) % make true % touch foo % make true /home/andrew/foo This consistency seems gratuitous and unintuitive, so I believe it should be fixed to behave like the shell. If it is not fixed, it should be documented. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages make depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297374: make: builds without debugging by default (policy 10.1)
Package: make Version: 3.80-9 Severity: minor -g should be used by default accourding to policy 10.1. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages make depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297340: make: tilde expansion does not work as in the shell
On Mon, Feb 28, 2005 at 01:10:25PM -0600, Manoj Srivastava wrote: The problem lies in your use of the function wildcard. Ick, thank you for pointing this out. $(wildcard PATTERN...) This string, used anywhere in a makefile, is replaced by a space-separated list of names of existing files that match one of the given file name patterns. If no existing file name matches a pattern, then that pattern is omitted from the output of the `wildcard' function. Note that this is different from how unmatched wildcards behave in rules, where they are used verbatim rather than ignored (*note Wildcard Pitfall::). This last sentence is slightly inaccurate (or perhaps ambiguous, depending on the meaning of unmatched). If ~/foo (where foo does not exist) is used in a rule, it _is_ expanded to /home/andrew/foo (rather than used verbatim). Consider the static pattern rule: ~/foo/bar: ~/foo/%: % This gives the error target `/home/andrew/foo' doesn't match the target pattern, because ~/foo was expanded in the target, but not in the target pattern. I thought I could fix this by pre-expanding ~foo: dest := $(wildcard ~/foo) $(dest)/foo: $(dest)/%: % but this runs afoul of the rule you point out. (In the real code, ~/foo is a parameter that might be set by the user, so I wanted to support ~ expansion.) I would suggest that ~ expansion be excepted from the no existing file name rule, since that rule seems to have been written with * and ? wildcards in mind. However, I have not looked at whether this is feasible. I think what this really indicates is that ~ and * expansion are different. As a second alternative, I would suggest reading the last sentence cited strictly, and not expanding ~/foo in rules when that file doesn't exist. This would make my first example work. However, I consider this inferior to the first suggestion, because it is inconsistent with the shell and less intuitive. For now, I'll probably just go with dest := $(shell echo ~/foo) Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297452: reportbug: automatic bcc is AWOL
Package: reportbug Version: 3.8 Severity: normal I noticed when filing a recent bug that I didn't get a mailed copy of the bug report, as I am used to. The documentation of the --no-cc option suggests that by default I should get a bcc, and my (untouched) /etc/reportbug.conf contains a line cc. So the lack of a bcc seems to be a bug. Note I am using the --mutt option. Andrew -- Package-specific info: ** Environment settings: EDITOR=vi VISUAL=vi EMAIL=[EMAIL PROTECTED] ** /home/andrew/.reportbugrc: mutt no-query-bts mode standard -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages reportbug depends on: ii python2.3 2.3.5-1An interactive high-level object-o -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293272: cron: @include common-session in PAM config logs to auth.log
Package: cron Version: 3.0pl1-86 Severity: wishlist My disk doesn't stay spun-down very long, even with laptop-mode. I discovered the problem was syslog doing syncs to auth.log whenever a cron job runs. (I have a package, lockout, that runs a cron job every minute.) cron logs to auth.log because it has @include common-session in its PAM config, and common-session uses pam_unix. The log lines look like Feb 1 20:07:01 localhost CRON[25041]: (pam_unix) session opened for user root by (uid=0) Feb 1 20:07:01 localhost CRON[25041]: (pam_unix) session closed for user root I would suggest leaving common-session out of the PAM config, because a cron job is not really a session in the normal sense. It really doesn't make sense for every cron job to be logged in auth.log. (If you want to log them, daemon.log would probably be better.) Another way to solve my problem would be to change syslog.conf so that auth.log is not synced. However, this seems sub-optimal because real authorization events are pretty important. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages cron depends on: ii adduser 3.59 Add and remove users and groups ii debianutils 2.11.2 Miscellaneous utilities specific t ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libpam0g0.76-22 Pluggable Authentication Modules l -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291787: xterm: selection is cleared by scrolling
Package: xterm Version: 4.1.0-16woody5 Severity: normal First, I want to say I couldn't be more pleased by the recent effort (bug 277832) to improve selection handling. The new behavior is generally quite pleasant. However, there appears to be a significant regression. Any time the terminal scrolls (by which I mean, a newline is received when the cursor is at the bottom, not scrolling of the view with shift-pgup), the selection is cleared. To reproduce: 1. Open an xterm. 2. Press enter enough times to get the cursor to the bottom of the screen. 3. Select something. 4. Press return to scroll one line. The selection is cleared. I'm not sure exactly which version introduced this behavior, but I'm guessing it was a side-effect of fixing bug 277832. I've verified that in 4.1.0-16woody5, the selection remains in step 4. Andrew -- System Information: Debian Release: 3.0 APT prefers unstable APT policy: (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-686-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xterm depends on: ii debconf 1.4.42 Debian configuration management sy ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libfreetype6 2.1.7-2.3 FreeType 2 font engine, shared lib ii libncurses5 5.4-4 Shared libraries for terminal hand ii libxaw7 4.1.0-16woody5 X Athena widget set library ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu -- debconf information: xterm/xterm_needs_devpts: xterm/clobber_xresource_file: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
