Bug#340679: pyqt-tools: pyuic should NOT attempt to connect to session/x servers
Package: pyqt-tools Version: 3.15-4 Severity: normal While building hplip in a pbuider chroot (and later verified in all autobuilders using their logs): pyuic -x -o ui/loadpaperform_base.py ui/loadpaperform_base.ui Session management error: Could not open network socket It should not have tried to connect to anything in the first place. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages pyqt-tools depends on: ii libc62.3.5-8 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-4 GCC support library ii libqt3-mt3:3.3.5-1 Qt GUI Library (Threaded runtime v ii libstdc++6 4.0.2-4 The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-10 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-10 X Window System miscellaneous exte ii xlibs6.8.2.dfsg.1-10 X Window System client libraries m pyqt-tools recommends no packages. -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341000: hplip-base: fails to install due to libsnmp5 (= 5.1) not being installable
reassign 341000 ftp.bugs.debian.org severity 341000 important merge 341000 340467 thanks There is nothing I can do. Thanks for assigning 341000 to me :-) But unfortunately this is a major testing fuckup and not something wrong with the HPLIP packages. On Sun, 27 Nov 2005, Aldo Maggi wrote: Package: hplip-base Version: 0.9.3-3 Severity: grave Justification: renders package unusable fails to install due to libsnmp5 (= 5.1) not being installable, this package is not listed among dependancies in http://packages.debian.org/testing/utils/hplip-base Yes it is. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341060: initscript: completely broken
Package: sysfsutils Version: 1.3.0-3 Severity: grave Justification: renders package unusable if [ $f1 ] ;... is NOT valid shell syntax. Nor is [ ... -a $f2 ]. You're missing a -n in front of all bare string tests inside [ ]. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages sysfsutils depends on: ii libc6 2.3.5-8.1 GNU C Library: Shared libraries an ii libsysfs1 1.3.0-3interface library to sysfs sysfsutils recommends no packages. -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341060: initscript: completely broken
severity 341060 grave thanks (I am setting it back to grave so that apt-listbugs warns people off until an upload fixing the bug hits the archive. See the rest of the email). On Mon, 28 Nov 2005, Martin Pitt wrote: The script runs fine with bash and dash, and [ $foo ] is common Well, here it broke with bash from sid depending on the values of $foo, which is probably why you could not reproduce it. practice and described in test(1: -n STRING the length of STRING is nonzero STRING equivalent to -n STRING Braindamaged common practice, that one is. If with -something test recognizes the string is, stupid things test will do. Never use naked strings with test, it is courting an error mode. I *think* it is smart enough not to croak if you [ $string ], but it will on [ $string -a something -a $string2 ]... In this case it barfs when some of the strings are -1, see attached error dump. Try this: a=1 ; b=-1 ; [ -n $a -a $b ] echo ok Interestingly enough, a=1 ; b=-1 ; [ $a -a $b ] echo ok won't croak. This is bash trying to be smart, as a=1 ; b=-1 ; /usr/bin/[ $a -a $b ] echo ok WILL croak. Please give me the output of sh -nx /etc/init.d/sysfsutils if it really breaks for you. if it really breaks? I'd have worded that request very differently, the way you did is not nice at all. I hope you did so because of the @d.o address, and would not write something like that to a regular user. Output attached, and sysfs.conf attached too. BTW, -nx gives no output, I ran it with -x only. also, just for completeness: khazad-dum:/etc# ls -lad /bin/sh lrwxrwxrwx 1 root root 4 Oct 14 19:47 /bin/sh - bash and khazad-dum:/etc# head -n 1 /etc/init.d/sysfsutils #! /bin/sh -e -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh # # /etc/sysfs.conf - Configuration file for setting sysfs attributes. # # The sysfs mount directory is automatically prepended to the attribute paths. # # Examples: # # Always use the powersave CPU frequency governor # devices/system/cpu/cpu0/cpufreq/scaling_governor=powersave # # Use userspace CPU frequency governor and set initial speed # devices/system/cpu/cpu0/cpufreq/scaling_governor = userspace # devices/system/cpu/cpu0/cpufreq/scaling_setspeed = 60 ## ## ADM-1027 temperature monitor / fan controller ## # Device setup (maybe overriden later by /etc/sensors.conf) # Generated using sensors.conf, look there. class/i2c-adapter/i2c-0/device/0-002e/vrm = 91 class/i2c-adapter/i2c-0/device/0-002e/in0_max = 1576 class/i2c-adapter/i2c-0/device/0-002e/in0_min = 1419 class/i2c-adapter/i2c-0/device/0-002e/in1_max = 1523 class/i2c-adapter/i2c-0/device/0-002e/in1_min = 1301 class/i2c-adapter/i2c-0/device/0-002e/in2_max = 3472 class/i2c-adapter/i2c-0/device/0-002e/in2_min = 3128 class/i2c-adapter/i2c-0/device/0-002e/in3_max = 5260 class/i2c-adapter/i2c-0/device/0-002e/in3_min = 4740 class/i2c-adapter/i2c-0/device/0-002e/in4_max = 12625 class/i2c-adapter/i2c-0/device/0-002e/in4_min = 11375 ## Temperature control ## # temp1: CPU Temperature class/i2c-adapter/i2c-0/device/0-002e/temp1_min = 05000 class/i2c-adapter/i2c-0/device/0-002e/temp1_max = 8 class/i2c-adapter/i2c-0/device/0-002e/temp1_auto_temp_off = 26000 class/i2c-adapter/i2c-0/device/0-002e/temp1_auto_temp_min = 45000 class/i2c-adapter/i2c-0/device/0-002e/temp1_auto_temp_max = 55000 class/i2c-adapter/i2c-0/device/0-002e/temp1_auto_temp_crit = 65000 # temp2: ADM1027 Temperature class/i2c-adapter/i2c-0/device/0-002e/temp2_min = 0 class/i2c-adapter/i2c-0/device/0-002e/temp2_max = 6 class/i2c-adapter/i2c-0/device/0-002e/temp2_auto_temp_off = 35000 class/i2c-adapter/i2c-0/device/0-002e/temp2_auto_temp_min = 35500 class/i2c-adapter/i2c-0/device/0-002e/temp2_auto_temp_max = 5 class/i2c-adapter/i2c-0/device/0-002e/temp2_auto_temp_crit = 5 # temp3: Motherboard (environment) Temperature class/i2c-adapter/i2c-0/device/0-002e/temp3_min = 0 class/i2c-adapter/i2c-0/device/0-002e/temp3_max = 55000 class/i2c-adapter/i2c-0/device/0-002e/temp3_auto_temp_off = 35000 class/i2c-adapter/i2c-0/device/0-002e/temp3_auto_temp_min = 35500 class/i2c-adapter/i2c-0/device/0-002e/temp3_auto_temp_max = 5 class/i2c-adapter/i2c-0/device/0-002e/temp3_auto_temp_crit = 6 ## Fan and PWM control ## class/i2c-adapter/i2c-0/device/0-002e/auto_acoustics_enhancement = 2 # fan1: CPU fan class/i2c-adapter/i2c-0/device/0-002e/fan1_min = 2000 class/i2c-adapter/i2c-0/device/0-002e/pwm1_auto_channels = -1 # fan2: VR fan #class/i2c-adapter/i2c-0/device/0-002e/fan2_min = 1800 #class/i2c-adapter/i2c-0/device/0-002e/pwm2_auto_channels = -1 class/i2c-adapter/i2c-0/device/0-002e/fan2_min = 0 class/i2c-adapter/i2c-0/device/0-002e/pwm2_auto_channels = 0 # fan3: Front fan and fan4: Rear fan
Bug#193364: [Amavisd-new-debian-devel] Re: Bug reports
forwarding message from amavisd-new upstream to relevant bug reports.
From: Mark Martinec [EMAIL PROTECTED]
Subject: [Amavisd-new-debian-devel] Re: Bug reports
Date: Wed, 3 Aug 2005 17:25:11 +0200
Brian,
Sorry for delay, your mail just arrived when I left for vacation,
and now it took me a while to catch up with my mail.
I am going through old bug reports for amavisd-new in Debian,
I suspect many are obsolete and can be closed.
Anyone know if any of these can be closed?
Any help closing bug reports would be appreciated.
URL:http://bugs.debian.org/193364
Can be closed, the default current log entry (2.3.2) looks like:
Blocked SPAM, [10.11.12.13] [10.1.2.3] ... - ...,
Message-ID: ..., mail_id: DLIEolNRsDou, Hits: 22.545+1.8, 11958 ms
The corresponding macro is %c:
%c spam level/hits (mnemonic: sCore) as provided by SpamAssassin,
including a per-recipient boost when used in $log_recip_templ
and a min of per-recipient boosts in other templates
URL:http://bugs.debian.org/211740
Solved in amavisd-new-2.3.0 when feeding MTA-amavisd over LMTP.
The problem does not have a better solution when using SMTP protocol.
From the release notes:
- at last: when mail is received through LMTP protocol, gracefully handle
a temporary failure 4xx reply from MTA to a RCPT TO command and pass it
back to a LMTP client for tempfailed recipients only, instead of returning
450 for _all_ recipients (needed the sending routine to be aware of the
receiving side capabilities, which was previously not available);
URL:http://bugs.debian.org/228766
In 2.3.2 (and earlier) there are the following commented-out lines
in file amavisd. Uncommenting them achieves what was requested.
# $hdr_edits-append_header('X-Spam-Checker-Version',
# sprintf(SpamAssassin %s (%s) on %s, Mail::SpamAssassin::Version(),
# $Mail::SpamAssassin::SUB_VERSION, $myhostname));
URL:http://bugs.debian.org/236482
In case of exceeded decoding quota or file number limit the
current version (2.3.2) or amavisd-new no longer 'preserves evidence',
it just tempfails the message.
URL:http://bugs.debian.org/281752
The request is still valid, but has a low significance, because
REJECT is only useful in pre-queue mail filtering setup, and
amavisd-new is targeted at post-queue filtering, in which case
the additional information would only be seen in one's own MTA log,
which is not of much use. The REJECT destiny setting is pretty much
useless in post-queue setup, the preferred settings are BOUNCE or DISCARD
Regards
Mark
- End forwarded message -
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#228766: marking this bug as wontfix
tag 228766 + wontfix thanks This bug cannot be fixed without help from spamassassin upstream. Upstream amavisd-new removed the commented-out code, and Debian won't add futher breakage points to amavisd-new for a wishlist. Please feel free to remove the wontfix tag AND notify us *if* spamassassin upstream ever publishes an official, public API to get the version strings from perl. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342068: azureus: Missing options in options dialog in the new version
Package: azureus Version: 2.3.0.6-1 Severity: normal Some options are missing in the new version's option dialog, *even in advanced mode*. Namely, the Priorize most completed files option is missing. However, that option STILL exists, and it STILL works... but now I cannot disable it anymore! (it was enabled while using an older version of Azureus). Since the file storing Azureu's config is NOT editable without specialized tools or knowledge, I cannot even fix that by hand easily. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.3-debian4+bluesmoke+atapassthru+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages azureus depends on: ii libcommons-cli-java 1.0-7 API for working with the command l ii liblog4j1.2-java 1.2.12-1 Logging library for java ii libseda-java 3.0-3 the Staged Event-Driven Architectu ii libswt-gtk-3.1-java 3.1-3 Standard Widget Toolkit for GTK Ja pn sun-j2re1.5 | java-virtual-ma none (no description available) pn sun-j2re1.5 | java2-runtime none (no description available) Versions of packages azureus recommends: ii java-package 0.27 utility for building Java(TM) 2 re -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342314: cyrus22-imapd: long line bug in Cyrus
On Tue, 06 Dec 2005, Mark Nipper wrote: Please include the patch below as seen on the DSPAM users list recently (and supposedly already reported to the Cyrus folks, but no new releases have been made upstream since then). We should try to find this patch (and all other important ones) in Cyrus upstream CVS, and use their version instead (just in case the fix upstream was slightly different). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308248: incompatible with (recent) makedev
On Mon, 09 May 2005, Frank Lichtenheld wrote: Setting up rng-tools (2-unofficial-mt.8-5) ... ./MAKEDEV: don't know how to make device hwrandom ./MAKEDEV: don't know how to make device intel_rng Urk. Forgot to fix that in the stable branch. I am considering whether to promote the experimental Debian branch to stable, so as to provide sarge with extremely faster VIA RNG support. Whatever happens, the next upload will fix this bug, by deprecating the other device names completely and depending on an udev and a makedev that provide hwrng. BTW, if you like rng-tools please consider playing with the one in http://arch.debian.org/arch/private/hmh/rng-tools-2005/ It is a *much* improved version, and I welcome comments. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308274: automake1.9: Please add linux-kernel-2.6-like output mode for make
Package: automake1.9
Version: 1.9.5-1
Severity: wishlist
Tags: upstream
Please add support for pretty-running make as it is done for the Linux
kernel 2.6. It helps a lot to reduce cruft and call attention to warnings,
especially for builts like the ones done by automake when dependency
tracking is enabled.
The tags used for pretty-printing should be somehow configurable, with good
defaults for the supported languages and compilers/preprocessors.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.8-debian0.2+libata6dev1+bluesmoke
Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1)
Versions of packages automake1.9 depends on:
ii autoconf 2.59a-3automatic configure script builder
ii autotools-dev 20050422.1 Update infrastructure for config.{
-- no debconf information
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308275: libtool: Please make language support (C/C++/F77) configurable
Package: libtool
Version: 1.5.6-6
Severity: wishlist
Tags: upstream
Libtool *really* should let one configure what kind of language support
needs to be used in the AC_PROG_LIBTOOL macro.
That way, a lot of useless, distracting, major resource waste of tests could
be dropped (e.g. C++/F77 tests in the outrageously big number of pure C
packages out there, multiplied by the number of users compiling them...)
This would also address bugs such as Debian bug #221873, as well.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.8-debian0.2+libata6dev1+bluesmoke
Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1)
Versions of packages libtool depends on:
ii autotools-dev 20050422.1Update infrastructure for config.{
ii cpp4:3.3.5-3 The GNU C preprocessor (cpp)
ii file 4.12-1Determines file type using magic
ii gcc [c-compiler] 4:3.3.5-3 The GNU C compiler
ii gcc-2.95 [c-compiler] 1:2.95.4-22 The GNU C compiler
ii gcc-3.3 [c-compiler] 1:3.3.6-3.0.1 The GNU C compiler
ii gcc-3.4 [c-compiler] 3.4.3-13 The GNU C compiler
ii gcc272 [c-compiler]2.7.2.3-18The GNU C compiler.
ii libc6-dev [libc-dev] 2.3.2.ds1-21 GNU C Library: Development Librari
-- no debconf information
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308275: Acknowledgement (libtool: Please make language support (C/C++/F77) configurable)
package libtool severity 308275 wishlist tags 308275 wontfix tags 308275 fixed-upstream merge 308275 221873 thanks Oops... I should have read the #221873 bug report beforehand, as that report basically states that #308275 is fixed in 1.6 just in the way I would like it to have been fixed). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309114: postfix: bsmtp entry in master.cf causes data corruption
Package: postfix Version: 2.2.3-2 Severity: important The current line in the bsmtp mailer in master.cf tells pipe to do dot-stuffing and then calls bsmtp with the -d switch, which also does dot-stuffing. Please remove that -d option from the bsmtp command invocation -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.9-debian0.2+libata6dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages postfix depends on: ii adduser 3.63 Add and remove users and groups ii debconf [debconf-2.0] 1.4.49 Debian configuration management sy ii dpkg1.10.27 Package maintenance system for Deb ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [ ii libsasl22.1.19-1.5 Authentication abstraction library ii libssl0.9.7 0.9.7g-1 SSL shared libraries ii netbase 4.21 Basic TCP/IP networking system -- debconf information excluded -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343645: Processed: Re: [Pkg-sysvinit-devel] Processed: Re: Bug#343645: e2fsprogs: Superblock last mount time is in the future, fix it ? (Y)
tag 343645 wontfix thanks Please, no screwing with this glibc and util-linux issue. It should be fixed by util-linux (patch 50% done by yours thruly), and glibc. It is wontfix for initscripts. It is almost-pending for util-linux. I have no idea if, after util-linux is fixed, glibc will do the right thing and make sure /etc/localtime is always valid (bugs will need to be reassigned to glibc, I don't think they have been notified yet. /etc/localtime IS glibc's domain, as timezones and locales are their domain. It should be kept up-to-date by tzconfig. It should be a copy of the zonefile instead of a symlink. d-i probably has to be fixed to severely discourage UTC=no and to also do copies, but that's something else. I am against futher breakage on this issue by trying to work around it in initscripts. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316468: [Pkg-sysvinit-devel] Bug#316468: Implement, but assist backporters?
On Thu, 05 Jan 2006, Thomas Hood wrote: Petter Reinholdtsen replied: I would prefer it if the current sysvinit package did not have any dependenices missing in debian/stable, to make it easier to backport the package to sarge. Please wait with this change until etch is released. That won't happen, sorry. Etch will need some stuff that simply doesn't exists in sarge. Is -delete is no slower than the current -print0 | xargs rm code? I'll assume so. It might be a bit slower (extra fork, pipe setup), but it won't make much of a difference, either way. I doubt it is in the easily measurable land. How about we make this change but encapsulate the find call in a function in order to assist the sarge backporters? The sysvinit packages already require modification for use in sarge. IMHO It makes no sense to do such a change and place it in a function call, the function call is probably slower than the original code to begin with :) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343645: Processed: Re: [Pkg-sysvinit-devel] Processed: Re: Bug#343645: e2fsprogs: Superblock last mount time is in the future, fix it ? (Y)
Hi LaMont! On Thu, 05 Jan 2006, LaMont Jones wrote: On Thu, Jan 05, 2006 at 08:55:26AM -0200, Henrique de Moraes Holschuh wrote: It should be fixed by util-linux (patch 50% done by yours thruly), and glibc. It is wontfix for initscripts. It is almost-pending for util-linux. I have no idea if, after util-linux is fixed, glibc will do the right thing and make sure /etc/localtime is always valid (bugs will need to be reassigned to glibc, I don't think they have been notified yet. What's the status of the patch, and can I get a copy of it? I was trying to write one that did all in util-linux, but during that time it become apparent that the fix needs to involve glibc and initscripts too to be effective during DST. I will send you a simple patch ASAP that just fixes things but requires the user to manually edit the hwclockfirst.sh file and add TZ= something there, and fix that manually for DST. The full solution will (if approved by initscripts and glibc) have a working /etc/localtime by the time hwclockfirst is run, so that TZ= will be unneeded, and it will all work even during DST. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342887: [PATCH] move hwclock to S05 and S46. Fix initscript problems
tag 342887 + patch
thanks
See attached patch. It was not completely tested yet, but it seems sane,
and it survived some light testing.
Note that hwclock.sh runs much later than I'd like it to, but we need to
make sure /usr is mounted, and that means it must run after NFS has had its
change of mounting /usr.
USER'S GUIDE:
1. Install util-linux with the patch applied
2. Edit hwclockfirst.sh and set TZ to your timezone
3. Change that TZ according to daylight savings time, manually.
The TZ hack will be uncessary eventually, and util-linux will be fixed
accordingly to not mention TZ anymore in the initscript (dpkg will warn you
that the initscript conffile has changed). When that happens, please update
the initscript.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
diff -ruN util-linux-2.12r/debian/hwclock.sh
util-linux-2.12r-fix2/debian/hwclock.sh
--- util-linux-2.12r/debian/hwclock.sh 2006-01-05 09:17:51.677942513 -0200
+++ util-linux-2.12r-fix2/debian/hwclock.sh 2006-01-05 20:41:58.799569064
-0200
@@ -11,6 +11,12 @@
# during startup/shutdown.
# - Added comments to alert users of hwclock issues
# and discourage tampering without proper doc reading.
+# 2006-01-05 Henrique M. Holschuh [EMAIL PROTECTED]
+# - Improve message handling
+# - Fix FIRST=yes/no invocations of hwclock --hctosys,
+# and other minor things
+# - Make very sure /etc/adjtime is not used on FIRST=yes
+# - Follow symlinks in /etc/adjtime (no reason not to)
# WARNING: Please read /usr/share/doc/util-linux/README.Debian.hwclock
# before changing this file. You risk serious clock
@@ -22,8 +28,15 @@
# as machine hardware clock type for Alphas.
HWCLOCKPARS=
+# Set this to your timezone if your clock is not in UTC, this hack will go
+# away soon. Make sure to use the simplest form for TZ, see tzset(3) for
+# details
+# e.g. TZ=ABC+03:00 for GMT-3:00, TZ=AAA-05:30 for UTC+05:30
+#
+#TZ=
+
[ ! -x /sbin/hwclock ] exit 0
-. /etc/default/rcS
+[ -r /etc/default/rcS ] . /etc/default/rcS
. /lib/lsb/init-functions
verbose_log_action_msg() { [ $VERBOSE = no ] || log_action_msg $@; }
@@ -34,7 +47,9 @@
UTC=
if [ X$FIRST = Xyes ] [ ! -r /etc/localtime ]; then
if [ -z $TZ ]; then
- log_action_msg System clock was not updated at this
time
+ log_warning_msg Hardware clock misconfiguration
detected!
+ log_warning_msg Hardware clock not in UTC, TZ unset
and /etc/localtime unreadable
+ log_failure_msg System clock was not updated at this
time
exit 1
fi
fi
@@ -42,55 +57,65 @@
yes)GMT=--utc
UTC=--utc
;;
- *) log_action_msg Unknown UTC setting: \$UTC\; exit 1 ;;
+ *) log_warning_msg Hardware clock misconfiguration detected!
+ log_failure_msg Unknown UTC setting: \$UTC\; exit 1 ;;
esac
case $BADYEAR in
no|) BADYEAR= ;;
yes)BADYEAR=--badyear ;;
- *) log_action_msg unknown BADYEAR setting: \$BADYEAR\; exit 1
;;
+ *) log_warning_msg Hardware clock misconfiguration detected!
+ log_failure_msg unknown BADYEAR setting: \$BADYEAR\; exit 1
;;
esac
case $1 in
start)
- if [ ! -f /etc/adjtime ] [ ! -e /etc/adjtime ]; then
+ if [ $FIRST != yes ] [ ! -e /etc/adjtime ]; then
+ # (will follow symlinks)
echo 0.0 0 0.0 /etc/adjtime
fi
- if [ $FIRST != yes ]; then
- # Uncomment the hwclock --adjust line below if you want
- # hwclock to try to correct systematic drift errors in the
- # Hardware Clock.
- #
- # WARNING: If you uncomment this option, you must either
make
- # sure *nothing* changes the Hardware Clock other than
- # hwclock --systohc, or you must delete /etc/adjtime
- # every time someone else modifies the Hardware Clock.
- #
- # Common vilains are: ntp, MS Windows, the BIOS Setup
- # program.
- #
- # WARNING: You must remember to invalidate (delete)
- # /etc/adjtime if you ever need to set the system clock
- # to a very different value and hwclock --adjust is being
- # used.
- #
- # Please read
/usr/share/doc/util-linux/README.Debian.hwclock
- #
Bug#346148: [Pkg-sysvinit-devel] Bug#346148: checkroot.sh: does not properly handle fsck exit states
On Fri, 06 Jan 2006, Wouter Verhelst wrote: I just noticed that my laptop, at bootup, started an fsck for the root filesystem, claiming that it was a filesystem with errors. When it was about 20% done, it exited, and told me to rerun it manually. I expected a prompt for my root password and to be put in single-user mode, but this did not happen; instead, my system did a normal boot. This means fsck returned error codes 2 or 3. If fsck needs to be re-run manually, it should have something else (bit 1 should not be set, bit 2 should be set, and I am not sure about bit 3. Other bits should be unset). What is your root filesystem? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343645: Processed: Re: [Pkg-sysvinit-devel] Processed: Re: Bug#343645: e2fsprogs: Superblock last mount time is in the future, fix it ? (Y)
On Fri, 06 Jan 2006, Thomas Dickey wrote: On Thu, Jan 05, 2006 at 04:50:24PM +0100, Henrique de Moraes Holschuh wrote: I was trying to write one that did all in util-linux, but during that time it become apparent that the fix needs to involve glibc and initscripts too to be effective during DST. The patch was too simplistic to be of use anyway. Granted that it was tested lightly... Simplistic as in? What did it fail to do? The whole fix involves a lot of crap that won't be done by util-linux, but rather initscripts. The patch just fixes util-linux back to what it should be doing. I don't see any discussion on this thread that points out that modifying the hardware clock from another system can make the Debian system unbootable (until one waits for the future to arrive ;-). And you won't :-P We don't protect people from hanging themselves on purpose. If you want to discuss that the test is completely stupid, or that fsck is not repairing it correctly or in the desired way, you have to talk to the e2fsck maintainer. OTOH, a misshandled clock (as in we say we support it in local time but really don't) is a bug no matter how we look at it, so even if e2fsck stops caring about the system clock, we would still need to do something about this issue at early boot anyway. Or drop the non-UTC support for the RTC. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346218: pget: must close connections that already transmitted their share
Package: lftp Version: 3.4.0-1 Severity: important At least in ftp mode, pget is not closing the connections that have already transmitted their share. This leads to absurd waste of bandwitdh when dealing with really huge files (like CD or DVD iso images) if every partition does not transfer at the same rate. It really needs to partition the file correctly, and when a partition is done transfering, close it. If a connection dealing with a partition times out, restart THAT connection (I think it already does this), etc. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.5-debian6+bluesmoke+atapassthru+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages lftp depends on: ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libgcc1 1:4.0.2-5 GCC support library ii libgcrypt11 1.2.2-1LGPL Crypto library - runtime libr ii libgnutls11 1.0.16-14 GNU TLS library - runtime library ii libgpg-error0 1.1-4 library for common error values an ii libncurses5 5.5-1 Shared libraries for terminal hand ii libreadline5 5.1-5 GNU readline and history libraries ii libtasn1-20.2.17-1 Manage ASN.1 structures (runtime) ii netbase 4.24 Basic TCP/IP networking system ii zlib1g1:1.2.3-9 compression library - runtime lftp recommends no packages. -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346321: aptitude: offers upgrade to exp version (pri -10) instead of unst version (990)
Package: aptitude Version: 0.4.1-1 Severity: important I am tagging this as important because any bug that makes people install experimental packages unawares is quite problematic :) $ apt-cache policy libarts1c2a libarts1c2a: Installed: 1.4.3-3 Candidate: 1.5.0-3 Version table: 1.5.0-3 0 990 http://mirrors.kernel.org unstable/main Packages 990 http://ftp.fi.debian.org unstable/main Packages 1.5.0-2 0 -10 http://mirrors.kernel.org experimental/main Packages -10 http://ftp.fi.debian.org experimental/main Packages *** 1.4.3-3 0 100 /var/lib/dpkg/status However, aptitude does this: libarts1c2a recommends libarts1-akode --\ The following actions will resolve this dependency: - Upgrade libarts1c2a [1.4.3-3 (now) - 1.5.0-2 (experimental, experimental)] - Keep libarts1c2a at version 1.4.3-3 (now) - Remove libarts1c2a [1.4.3-3 (now)] - Install libarts1-akode [4:3.5.0-2 (experimental, experimental)] - Leave the dependency libarts1c2a recommends libarts1-akode unresolved. i.e it prefers to install the experimental version, even if it is priority -10. The correct solution is to install libarts1c2a 1.5.0-3, and leave the dependency unresolved. OR to hold everything. But installing anything that has a negative priority is a no-no. For reference, my /etc/apt/preferences is: Package: * Pin: release a=experimental Pin-Priority: -10 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.5-debian6+bluesmoke+atapassthru+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-6-3.1 0.6.43 Advanced front-end for dpkg ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-5 GCC support library ii libncursesw5 5.5-1 Shared libraries for terminal hand ii libsigc++-2.0-0c2a2.0.16-2 type-safe Signal Framework for C++ ii libstdc++64.0.2-5The GNU Standard C++ Library v3 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.4.1-1English manual for aptitude, a ter -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346329: [Pkg-sysvinit-devel] Bug#346329: swap on LVM
On Fri, 06 Jan 2006, Joel Johnson wrote: However, I have my swap located on an LVM volume, and the dm_mod isn't So do I. loaded until later (libdevmapper1.02) so attempting to activate the swap is futile. The script should check if the fstab entry is /dev/mapper/* and The swap could be, e.g, in /dev/vg name/whatever name the lv has. Then we have the miriad of ways device mapper could be activated: lvm, evms, etc... and also dmbased RAID. Argh. I really don't know how useful trying to make those checks even more comprehensive will be. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Bug#346598: init script stop example should use --oknodo
On Sun, 08 Jan 2006, Matt Kraai wrote: According to the LSB Core Specification 3.1, init scripts should consider running stop on a service already stopped or not running successful, but the example in policy does not behave this way because it does not pass --oknodo to start-stop-daemon in the stop case. The attached patch makes it do so. It must also use retry or some other way to make sure the daemon indeed stopped, and we should add a comment that you cannot use --exec if: 1. the daemon isn't an ELF executable (i.e. no #! stuff can use --exec) 2. the daemon could be running when its executable was replaced by a package upgrade. Or remove that error-inducing example completely and tell people to read /etc/init.d/skeleton (which is easier to fix than policy :-) ). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347264: Incorrect *Manufacturer string
On Mon, 09 Jan 2006, Pascal De Vuyst wrote: hplip-ppds package incorrectly uses *Manufacturer: HP (HPLIP) inside PPDs. Yes, this is done on purpose because of the myriad of other sources of possibly non-compatible PPDs for HP printers managed by hpijs (i.e. HPLIP). Are we going to remove all HP PPDs from all other PPD-installing packages in Debian, including the crap that comes with cupsys by default, and the ones in foomatic* ? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347264: Incorrect *Manufacturer string
On Tue, 10 Jan 2006, Roger Leigh wrote: An alternate approach, used by Foomatic and Gutenprint, is to put the driver name after the model: zgrep '^\*NickName:' /usr/share/cups/model/gutenprint/5.0/en/stp-escp2-c60.5.0.ppd.gz *NickName: EPSON Stylus C60 - CUPS+Gutenprint v5.0.0-rc2 I will do so, then. However, the other parts of the PPD spec for Debian will not be followed by hplip until all other issues are fixed, i.e. I will still ship the PPDs in a hplip/ subdir off the toplevel PPD directory for now, and that contains hpijs PPDs mixed with pure postscript PPDs. Is it desireable to forecefully case-normalize the PPD filenames? HP uses basically the toss a coin way of selecting which case they use on these things, and linuxprinting.org did not fix it upon acceptance of the PPDs. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347527: [Pkg-Cyrus-imapd-Debian-devel] Bug#347527: please expand 45-kolab2-annotations patch
On Wed, 11 Jan 2006, Steffen Joeris wrote: I want to send you all patches from Kolab which are provided, some of them are really necessary for a cyrus to run with kolab (hope you agree). Please include a description with each patch of the functionality provided by that patch *and* all possible incompatibilities with upstream it could generate. Patch dependency information is also quite useful :P Depending on what comes of that, we can take the patches as is, or we'll ask you to make them runtime-controlled for each compartimentalized functionality (which would be a good way to get them accepted upstream too, I suppose). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347264: Incorrect *Manufacturer string
On Wed, 11 Jan 2006, Pascal De Vuyst wrote: For the above reasons hplip-ppd should provide HPLIP PPDs and foomatic-filters-ppds should not. HPLIP provides *HP* PPDs. This includes all hpijs ones, and all postscript ones. I am not about to deal with the mess of shipping a different set of PPDs than upstream (I can deal with shipping all, or shipping none). The reason for this is user confusion, which I am wary of increasing. We should not remove all HP PPDs from packages providing PPDs since there are other binary gs drivers (e.g. pcl3) for use with HP printers where PPDs are provided by foomatic-filter-ppds. You'll have to verify if HPLIP is not providing those... If they are supported by HP, it probably does. Roger Leigh has a good point here. HPLIP PPDs already use the above Foomatic approach so that's no problem. Only in CVS, I didn't upload the packages not screwing up with the Manufacturer's field yet. So if PPDs are named e.g. HP-DeskJet_520-hpijs.ppd.gz and are located in As I said, there are ppds for other drivers than hpijs, including pure postscript. I think Debian should lead the way here by providing unified naming for PPDs which opens possibilities for GUI tools that are currently not possible. Perhaps a bug should be filed against foomatic-db to get this changed upstream. It *will* have to be changed upstream if you want to change names. But only the case is weird in HP's case, and that I can deal with. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347657: please add imapd.patch from kolab upstream
On Wed, 11 Jan 2006, Steffen Joeris wrote:
-#if defined(HAVE_STDARG_H) || defined(_WINDOWS)
+#if defined(HAVE_STDARG_H) || defined(__STDC__) || defined(_WINDOWS)
+#ifdef __FreeBSD__
+/* #define fdatasync(fd) fsync(fd) */
+#define O_DSYNC 0
+#endif
+
Assorted fixes we can ignore in Debian.
+#include sys/time.h
That one we want anyway.
#-#ifdef HAVE_CONFIG_H
#-#include config.h
#-#endif
#+#include ../../../config.h
We must fix this properly. Just config.h should have been enough, and
config.h is *always* wrong :)
+#ifdef ATVDOM /* allow '@' being a regular character in mboxname even when
using virtual domains */
+ else if ((cp = strrchr(name, '@'))) {
+#else
if ((cp = strrchr(name, '@'))) {
+#endif /* ATVDOM */
Not acceptable for regular cyrus.
-static void db_err(const char *db_prfx, char *buffer)
+static void db_err(const DB_ENV *dbenv, const char *db_prfx, const char
*buffer)
{
syslog(LOG_WARNING, DBERROR %s: %s, db_prfx, buffer);
}
We should verify this one.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347658: please include patch from kolab for Shell.pm
On Wed, 11 Jan 2006, Steffen Joeris wrote: Enclosed there is a small patch for the Shell.pm file. We also found it in the kolab-upstream. There I can only see some additional thinks. I think these are interesting for the mailboxes. The mailboxes with kolab have an other look. It is acutally a proper fix for shell.pm, we should apply it anyway. It documents valid cyrus 2.2 (without kolab changes). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347659: please discuss patch for ldap authentification (Kolab)
On Wed, 11 Jan 2006, Steffen Joeris wrote:
This is the ldap authentification patch for cyrus.
As far as I know it enables the ldap authentification.
Kolab uses ldap for all user information.
[...]
-{ virtdomains, off, ENUM(off, userid, on) }
+{ virtdomains, off, ENUM(off, userid, ldap, on) }
THAT I didn't like at all. If it is an authz module, it should have been
plugged to the ptloader. Looks more like a hack to the vir. domain system.
If kolab touched that, the chances of we taking the patches have decreased
to close to zero. I do NOT want people doing such things that 2.3 will
NEVER support.
We might need a cyrus-kolab package that has the patches applied, and to
keep the rest of cyrus pure...
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347660: please look at the wildcard-deactivating patches (Kolab)
On Wed, 11 Jan 2006, Steffen Joeris wrote:
This is necessary because Kolab uses the whole email adress for the
mailbox and there are for example '%' 's :)
I will not take this patch. It would be asking for misterious breakages.
Also, I am not sure it is legal IMAP either, and if it is not legal IMAP per
the RFCs, I'd push for its removal even if it were accepted...
We know that it will be very difficult or maybe impossible to integrate it
into the official cyrus package, but i think we will discuss it
Indeed. Why not fix Kolab so that it stops doing such weird things? It
should be doable.
+ #ifdef notdef
/* verify that the mailbox doesn't have a wildcard in it */
for (p = oldmailboxname; !r *p; p++) {
if (*p == '*' || *p == '%') r = IMAP_MAILBOX_BADNAME;
}
+ #endif
We *really* don't want to mess with this.
+ * original definition
#define GOODCHARS +,-.0123456789:[EMAIL PROTECTED]
+ */
+
+#define GOODCHARS #$%'()*+,-.0123456789:;=[EMAIL PROTECTED]|}~
+
Some of those might be needed for other stuff... as a rule, cyrus avoids
chars that could cause hell on scripts or the imap protocol, and reserves
some itself. So no ^ (unixhiersep), no wildcards, no {, no }, etc.
Exactly what kind of crazy thing does kolab do with mailboxes that it needs
the above changes?
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347659: [Pkg-Cyrus-imapd-Debian-devel] Bug#347659: please discuss patch for ldap authentification (Kolab)
On Thu, 12 Jan 2006, Philip Thiem wrote: Cyrus 2.2 Supporta Virtual domains and SASL has or at least can be properly patched for LDAP authentication. It always seemed to me like SASL was the There are three mechanisms that much act together to properly have accounts in LDAP: 1. LDAP auth (SASL with auxprop+LDAP patch -- not in Debian, we need to update to latest sasl + the patches; saslauthd works, but it is on its way out) 2. Cyrus ptloader autorization module for LDAP (IMAP ACL support) This is how upstream wants it done, and there is a damn good ptloader module for LDAP, we would do well to support that one in Debian, but it is useless if we don't fix the SASL packages. 3. Cyrus mailboxes database, which is *NOT* in LDAP -- usually people work around this one using the autocreate patches, and scripts to remove outdated mailboxes. I am completely against messing with (3) in any way that will not work in 2.3 in the replicated Murder with Virtual Domains scenario, and I am also completely against anything that does not do (2) correctly. So, I am completely against the ldap mess kolab did on the virtual domain code: we don't want to support non-kolab users using that. Now AFAIK (so far), kolab needs to filddle with a lot of stuff because they did something that *everyone* who ever tried to do it that way before had been told to Not Do It by Cyrus upstream: they got information that is out of band (the domain) and placed it in-band ([EMAIL PROTECTED] mailboxes). So please excuse me if I am dead set against adding such stuff to regular Cyrus, it is asking for trouble. OTOH, I don't mind adding a cyrus-kolab package with the patches that break cyrus so that kolab can work applied (I will talk about this on the ML thread about the kolab+cyrus team collaboration). * Patching SASL if the upstream stream isn't ready (i'm using a patched package myself). We should have a proper LDAP-worthy SASL in Debian, but nobody stepped up to take care of the monster of a package that is SASL, and I simply do NOT have the time right now. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342887: util-linux: please copy /etc/localtime
On Thu, 12 Jan 2006, Martin Stolle wrote: The only valid solution is to copy the appropriate timezone info to /etc/localtime. Rerunning tzconfig or recopying this file when That's what will be done, when we prove it to the glibc people that it is save (i.e. please do so on your system, and report back that NOTHING breaks...). I have that running on two systems already, no problems so far. I believe we have to test the KDE and GNOME timezone setting stuff too, but those should be changed in Debian to use tzconfig and /etc/timezone anyway, so if they break, we just fix them and go ahead. /usr/share/zoneinfo is updated is a perfectly fine solution and by far the least hackiest solution. Yes. TZ=something is just a workaround. BTW, RedHat does what we are trying to do, so I am pretty sure we won't have much problems, just some Debian scripts (in the glibc package) to fix. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347659: [Pkg-Cyrus-imapd-Debian-devel] Bug#347659: please discuss patch for ldap authentification (Kolab)
On Thu, 12 Jan 2006, Sven Mueller wrote:
-{ virtdomains, off, ENUM(off, userid, on) }
+{ virtdomains, off, ENUM(off, userid, ldap, on) }
THAT I didn't like at all. If it is an authz module, it should have been
plugged to the ptloader. Looks more like a hack to the vir. domain system.
From what I saw in the patch, it uses the LDAP userid (uid field) to
look up the primary email address of the user. It then returns that
email address canonified for authentication (i.e. the user logs in with
his uid, but mail is stored and passwords looked up in sasl according to
his primary email address.
That ain't how it works with Cyrus. The user logs in with his *mailbox*,
which is [EMAIL PROTECTED] To change that, you add a canonization plugin that
gets whatever was sent to Cyrus as the mailbox, and changes it to the real
user and domain. But AFAIK, canonization is *global*.
Which means you DELIVER through LMTP to the pre-canonized account, do IMAP
logins and POP3 logins to the pre-canonized account... Depending on how
early SASL is called, SASL may have do deal with the pre-canonized account
as well, I didn't check.
Besides thinking that the patch is somewhat incomplete (it doesn't
handle alternate addresses at all AFAICT), I don't see how it could harm
normal cyrus operation.
I am afraid it might cause subtle bugs, but that's not the worst problem
IMHO. It is that we have no reason to believe it will be easily
forward-portable to 2.3, and 2.3 requires one to be very careful as the
entire murder code has been unified with the normal daemons, and there is
the whole replication system to take into account.
Well, I don't really see how to map LDAP uids (which are normally also
login names for servers/workstations) to email addresses (on which cyrus
operates. The only alternative would be to not use vdomains in cyrus and
use the MTA to deliver mails to any of the mail addresses of a user to
uid.
IF you are logging in (imap, pop) using [EMAIL PROTECTED], or using different
listening interfaces to automatically detect vdomain, in which case you
_can_ just use userid instead:
Email, you deliver to [EMAIL PROTECTED] using LMTP. This is done by teaching
the MTA to ask LDAP about the accounts, and where to deliver mail for an
account; that's how everyone doing email delivery of any sort using LDAP
have been doing things for years.
Cyrus logins are [EMAIL PROTECTED], mapped to SASL as userid=userid,
REALM=vdomain, and used internally by Cyrus as user userid, in domain
vdomain. *SASL* has to map that back to LDAP dn to check the credentials,
usually doing some string substitution to get a dn. If you need to do it
using LDAP *searches*, you have to improve the SASL LDAP auxprop module --
actually, I think the latest one can do it already, it has been a LONG time
since I mucked with cyrus+ldap.
After the authentication (SASL), Cyrus needs to ask stuff on LDAP only to
expand group ACLs (during authorization). That is supposed to be done
through a ptloader LDAP plugin, and definately not a new vdomain scheme.
Heck, tweaking cyrus so that it can canonize each type of service login
differently, and to use dynamically selected canonization schemes would
have been a nice and clean way to do what kolab seems to need done (if I
understood things correctly).
I hope this makes a bit more clear my misgivings about including the patch.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347813: amavisd-new: amavis not checking for spam or viruses after upgrade
On Thu, 12 Jan 2006, Christopher Wagner wrote:
After upgrading to the latest Etch version of amavisd-new yesterday, I
reconfigured amavis from scratch (doing away with my old amavis.conf). I made
Please send me a tarball with the entire contents of /etc/amavis. Please
overwite any sensitive information with XXX.
Jan 12 12:12:52 toober /usr/sbin/amavisd-new[21815]: ANTI-VIRUS codeNOT
loaded
Jan 12 12:12:52 toober /usr/sbin/amavisd-new[21815]: ANTI-SPAM codeNOT
loaded
This tipically happens if for some reason or another, the config is subtly
wrong, especially since the config files in /usr will DISABLE the anti-virus
and anti-spam code, so something weird happening in later config files will
probably cause the checks to remain disabled.
The config files are processed one-by-one, so it is very likely that the
problem is in 15-content-filter-mode (if you did not change the variables
controlling av and sa in another file). Just in case, I am attaching a
known-valid 15-content-filter-mode file with *enables* AV and SPAM checks.
You could try overwriting the one you're using with that one (or using diff)
to see if some sort of small typo escaped your checks.
Make sure all the config files return 1.
Make sure there are no open-ended , ', {, (, and so on.
You can run amavis in debug mode through the perl debugger, to see if it
is processing the config files as expected.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
use strict;
# You can modify this file to re-enable SPAM checking through spamassassin
# and to re-enable antivirus checking.
#
# Default antivirus checking mode
# Uncomment the two lines below to enable it back
#
@bypass_virus_checks_maps = (
\%bypass_virus_checks, [EMAIL PROTECTED], \$bypass_virus_checks_re);
#
# Default SPAM checking mode
# Uncomment the two lines below to enable it back
#
@bypass_spam_checks_maps = (
\%bypass_spam_checks, [EMAIL PROTECTED], \$bypass_spam_checks_re);
1; # insure a defined return
Bug#283027: status update on this bug.
I can't recall why I tagged this bug pending but never closed it. Chances are it has been fixed already, probably by 1:2.3.3-1 or maybe even earlier. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342451: pbuilder-buildpackage-funcs: missing install on apt-get line
Package: pbuilder
Version: 0.140
Severity: important
See attached patch, it is an obviously correct one-line fix. Without it,
pbuilder won't work when EXTRAPACKAGES is not empty.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.3-debian4+bluesmoke+atapassthru+lm85
Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1)
Versions of packages pbuilder depends on:
ii cdebootstrap 0.3.9 Bootstrap a Debian system
ii coreutils 5.93-5 The GNU core utilities
ii debianutils 2.15.1 Miscellaneous utilities specific t
ii debootstrap 0.3.3 Bootstrap a basic Debian system
ii gcc 4:4.0.2-1 The GNU C compiler
ii wget 1.10.2-1 retrieves files from the web
Versions of packages pbuilder recommends:
ii devscripts2.9.10 Scripts to make the life of a Debi
ii fakeroot 1.5.5 Gives a fake root environment
ii sudo 1.6.8p9-3 Provide limited super user privile
-- no debconf information
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--- pbuilder-buildpackage-funcs.orig2005-12-07 12:30:30.301625633 -0200
+++ pbuilder-buildpackage-funcs 2005-12-07 12:30:40.891320907 -0200
@@ -50,7 +50,7 @@
fi
# install extra packages to the chroot
if [ -n $EXTRAPACKAGES ]; then
- $CHROOTEXEC usr/bin/apt-get -y --force-yes ${EXTRAPACKAGES}
+ $CHROOTEXEC usr/bin/apt-get -y --force-yes install ${EXTRAPACKAGES}
fi
}
Bug#342660: cyrus22-imapd: suggest making skiplist the default database backend for new installs
On Fri, 09 Dec 2005, Mark Nipper wrote: anything BDB. There are seemingly known issues even using db4.3 and db4.3 != db4.2... and there is *NO* *CHANCE* of we linking to BDB 4.3 anytime soon, if I can help it. Skiplist is sensitive to corruption. As in: if it happens, you can start crying. It *can* and *does* deal well with aborted transactions, that's not what I am talking about. bdb 4.2 is fairly resilient to corruption, most of the time a db4.2_recover will do just that, with no data loss. It is also faster than skiplist for random lookups (mailboxes DB/TLS DB/duplicate delivery suppression DB), *especially* when you have a huge ammount of processes doing it (which happens to the mailbox db). So, I really think we should keep using BDB 4.2 as a default for those functions where upstream recommends doing so for performance reasons. although I upgraded all of my existing db3 files to db4.2 using db4.2_upgrade, I still ended up having cyrmaster crash on me due to critical database errors. Cyrus needs to be stopped for that to work without causing corruption, AFAIK. I didn't attempt a db migration yet using Cyrus, but it is always posible to do so using dumps. At the very least, I would mention this as either part of a debconf message or in one of the Debian README files so that folks are aware of the potential dangers in using the BDB backend and a really simple way to avoid trouble by using only skiplist instead. No debconf obnoxious messages. This is non-negotiable. But discussing about the good and bad of each database backend in the documentation is a good idea. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342314: [Pkg-Cyrus-imapd-Debian-devel] Bug#342314: cyrus22-imapd: long line bug in Cyrus
On Sat, 10 Dec 2005, Benjamin Seidenberg wrote: Found this patch, it's the same[0]. Do you want to patch using dpatch or actually patch the source tree? If you let me know, I can commit tonight. We should always use dpatch, but I'd place this one first in the dpatch chain, with 00_cvsps id_upstream_what the patch does, or something to the same effect. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343158: Fcron runs with group camera.
On Tue, 13 Dec 2005, Olleg Samoylov wrote: Package: fcron Version: 3.0.0-2 Severity: normal File created by fcron scripts have group camera. Only if somehow your system has fucked up its passwd/shadow files. Did you change the system users in *any* way? Activated NIS? Changed /etc/passwd? Changed the passwd map in /etc/nsswitch.conf? Removed the fcron user in some way behind the package's back? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343158: Fcron runs with group camera.
On Tue, 13 Dec 2005, Olleg Samoylov wrote: How fcron know what group to choose? There are no group settings neither in config file nor in command options. Did gid setted in compile time? By name (getpwent() lookup). The name is set to 'fcron'. I don't recall if it uses this only to locate the user and then uses the primary group for that user, or if it also chegid to fcron. But in postinst don't set explicitly what group id assign to fcron group. Yes, it does: adduser --system --group --home /var/spool/fcron \ --no-create-home --disabled-password fcron This creates a fcron _system_ user AND a fcron _system_ group. I have no idea how fcron could get things wrong without external tampering. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343420: Split directories can only be turned off for the imap spool
tag 343420 upstream wontfix thanks 2.1 is in Deep Maintenance mode. Only Debian-packaging related bugs, or sofware defects will be fixed, wishilist requests for new functionality in the software itself will all be denied. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343854: amavisd-new: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67
severity 343854 important thanks On Sun, 18 Dec 2005, Giovanni Biscuolo wrote: Package: amavisd-new Version: 20030616p10-5 Severity: critical Justification: breaks the whole system As in it destroyed your harddrive, stopped the entire boot process or somesuch? I seriously doubt so. Don't file critical bugs claiming that they break the whole system unless they do exactly that. Downgrading to important. Starting amavisd: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67. I will check that in chroot later. Meanwhile, you can try the version in experimental if you want a non-ancient amavisd-new. *BUT* if you do, please don't file bugs against experimental versions at any priority over normal. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343854: amavisd-new: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67
On Sun, 18 Dec 2005, Henrique de Moraes Holschuh wrote: Starting amavisd: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67. I will check that in chroot later. Meanwhile, you can try the version in I cannot duplicate the bug. Plese send me a copy of *all* amavisd-new configuration files, that might help me track down the bug. Also, please make sure you are using up-to-date Etch. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343854: amavisd-new: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67
On Mon, 19 Dec 2005, Steve Langasek wrote: Yes, critical is the wrong severity, but why is important the wrong one? I will assume you meant why is 'important' the right one? He seems to be describing a bug that makes amavisd unusable, which would still be grave, yes? If it was affecting everybody, sure. Unfortunately it isn't, so it is giving me trouble to track it down. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343854: amavisd-new: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67
On Mon, 19 Dec 2005, Giovanni Biscuolo wrote: * Henrique de Moraes Holschuh [EMAIL PROTECTED] [2005-12-18 11:56:26 -0200]: I cannot duplicate the bug. Plese send me a copy of *all* amavisd-new configuration files, that might help me track down the bug. All? I use /etc/amavis/amavisd.conf, you can find it attached. Also /etc/init.d/amavis* and /etc/default/amavis*. And you forgot to attach the amavisd.conf file :-) I *think* you have a problem with perl. I cannot reproduce it here (i386), and really: Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67. Dec 19 10:57:54 amavisd-new[5823]: Net::Server: 2005/12/19-10:57:54 Insecure dependency in `` while running with -T switch at /usr/share/perl5/Net/Server/Daemonize.pm line 67.\n\n at line 251 in file /usr/share/perl5/Net/Server.pm Dec 19 10:57:54 amavisd-new[5823]: Net::Server: 2005/12/19-10:57:54 Server closing! That would have caught my eye immediately were it an amavisd-new bug, and it would have been reported quite a while ago too, the amavisd-new you are using is in *sarge*, and it has been there for a damn big while now. So either a perl change broke it, or it rooted out a latent bug. Also, please make sure you are using up-to-date Etch. Before my bug report I made an aptitude dist-upgrade, is there anything else I can check? As long as your mirror is current, and you did an aptitude update beforehand, an aptitude upgrade (or dist-upgrade) would be all you need to do, to have an up-to-date system. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344045: cyrus21-common: non \n terminated lines at end of mail will be lost invoking mail -s xyz [EMAIL PROTECTED]
I did not track the problem down but in the /var/spool/cyrus/ mailbox the missing lines are not present. To reproduce the problem call: echoThis works | mail -s Test with newline[EMAIL PROTECTED] echo -n This is lost | mail -s Test without newline [EMAIL PROTECTED] The bug is something more insiduous. I don't think LMTP can even allow such a thing to happen, but I will need to re-read the LMTP RFC. Please send me a full protocol dump of the LMTP transaction between cyrus and your MTA while trying to deliver the This is lost email. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338028: jadetex: breaks tetex upgrade
Package: jadetex Version: 3.13-6 Severity: important Jadetex breaks completely any upgrades from pre 3.0 tetex to 3.0 tetex. Purging it and reinstalling it later after tetex was upgraded works. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages jadetex depends on: ii debianutils 2.15.1 Miscellaneous utilities specific t ii tetex-bin 3.0-10.1 The teTeX binary files ii tetex-extra 3.0-10 Additional library files of teTeX Versions of packages jadetex recommends: ii jade 1.2.1-45 James Clark's DSSSL Engine Versions of packages tetex-base depends on: ii dpkg 1.13.11.0.1 package maintenance system for Deb ii tex-common 0.9 Common infrastructure for using an ii ucf 2.003 Update Configuration File: preserv Versions of packages tetex-bin depends on: ii debconf [debconf-2.0]1.4.58 Debian configuration management sy ii debianutils 2.15.1 Miscellaneous utilities specific t ii dpkg 1.13.11.0.1 package maintenance system for Deb ii ed 0.2-20 The classic unix line editor ii libc62.3.5-7 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-3 GCC support library ii libice6 6.8.2.dfsg.1-10 Inter-Client Exchange library ii libkpathsea4 3.0-10.1path search library for teTeX (run ii libpaper11.1.14-3Library for handling paper charact ii libpng12-0 1.2.8rel-5 PNG library - runtime ii libsm6 6.8.2.dfsg.1-10 X Window System Session Management ii libstdc++6 4.0.2-3 The GNU Standard C++ Library v3 ii libt1-5 5.1.0-2 Type 1 font rasterizer library - r ii libx11-6 6.8.2.dfsg.1-10 X Window System protocol client li ii libxaw8 6.8.2.dfsg.1-10 X Athena widget set library ii libxext6 6.8.2.dfsg.1-10 X Window System miscellaneous exte ii libxmu6 6.8.2.dfsg.1-10 X Window System miscellaneous util ii libxp6 6.8.2.dfsg.1-10 X Window System printing extension ii libxpm4 6.8.2.dfsg.1-10 X pixmap library ii libxt6 6.8.2.dfsg.1-10 X Toolkit Intrinsics ii mime-support 3.35-1 MIME files 'mime.types' 'mailcap ii perl 5.8.7-7 Larry Wall's Practical Extraction ii sed 4.1.4-4 The GNU sed stream editor ii tetex-base 3.0-10 Basic library files of teTeX ii ucf 2.003 Update Configuration File: preserv ii xlibs6.8.2.dfsg.1-10 X Window System client libraries m ii zlib1g 1:1.2.3-6 compression library - runtime Versions of packages tetex-extra depends on: ii dpkg 1.13.11.0.1 package maintenance system for Deb ii tetex-base 3.0-10 Basic library files of teTeX ii tetex-bin3.0-10.1The teTeX binary files ii ucf 2.003 Update Configuration File: preserv -- debconf information excluded -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344401: firefox: Printing support (CUPS) completely hosed
Package: firefox Version: 1.5.dfsg-2 Severity: important Firefox is one step ahead on the road of getting printing completely wrong. Now, it pops up a dialog which supposedly should get the printer's profile from CUPS, but screws that up. Royally. And I cannot even fix this dumbass software by telling it to call xpp instead of lpr (xpp does things right). The result of the new printer support is that NONE of the printer's capabilities are available since firefox screws that up, BUT now firefox refuses to print at all just because my printer has a4 paper and I cannot get even the fucking postscript/generic driver (which should support ALL paper sizes, damn it!) to work. [EMAIL PROTECTED] PoS software thinks that even postscript/generic must support only letter-sized paper! And the Debian paperconfig default in this machine is a4 just to add insult to the injury. I am not sure if you guys are aware, but letter size is NOT a good way to try to print on a4 paper (it causes information loss), which is used in most of the world. If firefox is going to pretend it knows about printing, it must get at least THAT much right. Please remove all intelligent printing crap from firefox until it is ready for use. Let us use xpp or kprint or something else that actually works for now. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.3-debian4+bluesmoke+atapassthru+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages firefox depends on: ii debianutils 2.15.2 Miscellaneous utilities specific t ii fontconfig 2.3.2-1.1 generic font configuration library ii libatk1.0-0 1.10.3-1The ATK accessibility toolkit ii libc62.3.5-9 GNU C Library: Shared libraries an ii libcairo21.0.2-3 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-5 GCC support library ii libglib2.0-0 2.8.4-2 The GLib library of C routines ii libgtk2.0-0 2.8.9-2 The GTK+ graphical user interface ii libidl0 0.8.5-1 library for parsing CORBA IDL file ii libjpeg626b-11 The Independent JPEG Group's JPEG ii libpango1.0-01.10.1-2Layout and rendering of internatio ii libpng12-0 1.2.8rel-5 PNG library - runtime ii libstdc++6 4.0.2-5 The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-11 X Window System protocol client li ii libxcursor1 1.1.3-1 X cursor management library ii libxext6 6.8.2.dfsg.1-11 X Window System miscellaneous exte ii libxft2 2.1.7-1 FreeType-based font drawing librar ii libxi6 6.8.2.dfsg.1-11 X Window System Input extension li ii libxinerama1 6.8.2.dfsg.1-11 X Window System multi-head display ii libxp6 6.8.2.dfsg.1-11 X Window System printing extension ii libxrandr2 6.8.2.dfsg.1-11 X Window System Resize, Rotate and ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt6 6.8.2.dfsg.1-11 X Toolkit Intrinsics ii psmisc 21.8-1 Utilities that use the proc filesy ii zlib1g 1:1.2.3-9 compression library - runtime firefox recommends no packages. -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344406: firefox: Firefox should never suggest an user to restart his system under Unix!
Package: firefox Version: 1.5.dfsg-2 Severity: minor After a crash, trying to re-run firefox causes an extremely aggravating dialog to show up which suggests that one has to *restart* his system to get rid of the broken-but-still-running firefox. This is *nix, not Windows. Get rid of that dialog and tell people to kill the firefox process instead. Heck, even in non-ancient microsoft windows that would work too. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.3-debian4+bluesmoke+atapassthru+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages firefox depends on: ii debianutils 2.15.2 Miscellaneous utilities specific t ii fontconfig 2.3.2-1.1 generic font configuration library ii libatk1.0-0 1.10.3-1The ATK accessibility toolkit ii libc62.3.5-9 GNU C Library: Shared libraries an ii libcairo21.0.2-3 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-5 GCC support library ii libglib2.0-0 2.8.4-2 The GLib library of C routines ii libgtk2.0-0 2.8.9-2 The GTK+ graphical user interface ii libidl0 0.8.5-1 library for parsing CORBA IDL file ii libjpeg626b-11 The Independent JPEG Group's JPEG ii libpango1.0-01.10.1-2Layout and rendering of internatio ii libpng12-0 1.2.8rel-5 PNG library - runtime ii libstdc++6 4.0.2-5 The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-11 X Window System protocol client li ii libxcursor1 1.1.3-1 X cursor management library ii libxext6 6.8.2.dfsg.1-11 X Window System miscellaneous exte ii libxft2 2.1.7-1 FreeType-based font drawing librar ii libxi6 6.8.2.dfsg.1-11 X Window System Input extension li ii libxinerama1 6.8.2.dfsg.1-11 X Window System multi-head display ii libxp6 6.8.2.dfsg.1-11 X Window System printing extension ii libxrandr2 6.8.2.dfsg.1-11 X Window System Resize, Rotate and ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt6 6.8.2.dfsg.1-11 X Toolkit Intrinsics ii psmisc 21.8-1 Utilities that use the proc filesy ii zlib1g 1:1.2.3-9 compression library - runtime firefox recommends no packages. -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338028: jadetex: breaks tetex upgrade
On Thu, 22 Dec 2005, Frank Küster wrote: These are all now ancient versions. Is the bug still reproducible, or at do you have still the temporary file that the postinst script asked you to include in the bugreport? It's called /tmp/jadetex.postinst.* Postinst didn't ask anything, and I have been through at least five reboots since then (and /tmp is tmpfs here, you figure it out :-) ). How should I go about reproducing this, now? I don't think there is a way for me to give you more information on this bug. You can tag it unreproducible and close it if you want, if it is still happening, someone will reopen it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Bug#344401: firefox: Printing support (CUPS) completely hosed
severity 344401 grave retitle 344401 firefox: all printing support broken thanks It gets better and better. I tried various combinations, and here's what I found: 1. xprint usually lets one change paper size and still works, but if you try to print to file, you're likely to get something like this: *** glibc detected *** double free or corruption (fasttop): 0x411f9838 *** and firefox obviously crashes on that. 2. the CUPS queues either don't work (because of the paper size braindamage, sometimes even when paper size is left at the default), or they print to file just fine. They didn't crash firefox, unlike xprint. And the CUPS queues sometimes ignore the print command, and sometimes respect it. Often the command is reset to the default (!) after it works *once*. This is higly worrysome, there are obviously dangling pointers or worse in this mess, I cannot reproduce *anything* reliably, it is like hunting ghosts. I am bumping this bug to grave, this crap cannot reach testing. Feel free to downgrade if, for some reason or another it works for most users. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344045: [Pkg-Cyrus-imapd-Debian-devel] Bug#344045: cyrus21-common: non \n terminated lines at end of mail will be lost invoking mail -s xyz [EMAIL PROTECTED]
On Fri, 23 Dec 2005, Leif Jakob wrote: Could you reproduce the problem? LMTP session protocol dump, please. The only thing I can think of is that sendmail is closing the door on Cyrus' face, and some bug is causing it to drop the last EOL. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335657: amavisd-new: Amavis reports email format error on correctly formed subject field
tag 335657 moreinfo thanks On Tue, 25 Oct 2005, Thue Janus Kristensen wrote: Version: 20030616p10-5 Subject: =?ISO-8859-1?B?MTIzNDU2Nzg5IDEyMzQ1Njc4OSAxMjM0NQ==?= =?ISO-8859-1?B?Njc4OSAxMjM0NTY3ODkgMTIzNDU2Nzg5IA==?= =?ISO-8859-1?B?MTIzNDU2Nzg5IDEyMzQ1Njc4OSA=?= (123456789 123456789 123456789 123456789 123456789 123456789 123456789 encoded in base64). However, amavis appends the error message X-Amavis-Alert: BAD HEADER Improper use of control character (char 0D hex) in message header 'Subject' Subject: ...5IDEyMzQ1Njc4OSAxMjM0NQ==?=\r\n =?ISO-8859-1?... ^ I cannot reproduce this here with 2.3.3, even if the code *looks* like it should be buggy. Can you confirm you still have this problem with amavisd-new 2.3.3 ? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342887: hwclock must run after /usr
Let's go over the way things work, and see how we can fix them back so that they work correctly. Please bear with me while I go over the entire problem, and feel free to correct any mistakes I make. Reading manpage tzset(3) before you read any further is advised. AFAIK There are ONLY TWO valid modes of early boot operation: 1. UTC (hardware clock in UTC, UTC=yes) 2. Non-UTC with TZ set or /etc/localtime in the root filesystem (hardware clock in local time, UTC=no, system knows timezone) Anything else is an invalid system configuration, and must be fixed. By invalid configuration, I mean one where the system UTC clock (which has nothing to do with the hardware clock) is NOT set to the correct UTC time. I would bet it is common to find people with invalid configurations, since a separate /usr is common, TZ is not mentioned at the top of /etc/init.d/hwclockfirst.sh, and there isn't a way for d-i to set that up either. Also, do refer to tzset(3), we would need to use the simplest TZ form, since it must work without data that is in /usr/share. It is good to remember that timezones can be changed at will, by any user (just set TZ) at any time, and also that TZ overrides /etc/localtime so we don't want to define it system-wide. What that means? Below are the two valid configurations and what actions hwclock initscripts should do (doing anything else is probably a big bad bug ;-) ), and the most common invalid configuration. (*) are the points where hwclock scripts must take some action. UTC mode: 0. Kernel might boot with correct time (if it reads the RTC by itself) * 1. hwclockfirst sets kernel time to the correct UTC time 2. system runs with a local timezone (if /etc/localtime is readable) or with UTC as a timezone 3. something mounts /usr 4. System runs with the proper timezone Early boot runs fine, system thinks timezone is UTC if /usr is not mounted, or reads timezone from /etc/localtime if it is mounted. No big deal, as apps use UTC for persitent timekeeping. e2fsck should not be going bonkers in this case. hwclock should try to set the system clock only on early boot. Non-UTC valid config mode, with /usr as a separate partition 0. kernel boots with wrong time (even if it reads the RTC by itself) * 1. TZ is set so hwclockfirst sets the kernel time to the correct UTC time 2. system runs with a local timezone (if /etc/localtime is readable) or with UTC as a timezone 3. Something mounts /usr 4. System runs with the proper timezone Again, hwclock should try to set the system clock only on early boot. Notice that TZ must be set only for the hwclockfirst initscript, we don't want it in the global environment. I'd suggest removing UTC from /etc/default/rcS, and adding TZ and UCT to a new file, /etc/default/timezone. Non-UTC *valid config* mode, /usr inside the root partition 0. kernel boots with wrong time (even if it reads the RTC by itself) 1. /etc/localtime is readable, so everything else runs just like it does in UTC mode. With a valid configuration, hwclockfirst does all the job that doesn't need a timezone and must run VERY early. hwclock does the jobs that require a timezone (which is actually just displaying the time in the local timezone so that the users have a better clue of what's happening, and we don't increase d-user traffic with RTC problems again). This means hwclock.sh *must* run after /usr is mounted. That's the only time we *know* the timezone will be correct, no matter which configuration is used (including invalid ones -- hwclock after /usr is a *debugging aid*). What would happen in the typical broken configuration? Non-UTC, /usr separate, no TZ defined anywhere: 0. kernel boots with wrong time (even if it reads the RTC by itself) * 1. hwclock sets the kernel UTC time to the local time in the RTC, and thus the system clock could be wrong by several hours in either direction. 2. System runs with wrong time. e2fsck can croak, etc. 3. something mounts /usr * 4. hwclock runs, and tells the user a completely ludricous time (timezone applied twice :P) === We could fix the mess here, so if the user doesn't hit a bug (e.g. e2fsck) before, he would not suffer much from his broken config. hwclock MUST be run after /usr is mounted to be able to help fix the mess (well work around it, realy). Now, there's a bug in that hwclockfirst should bitch to all winds if it detects an invalid config, currently it just outputs a meek System clock was not updated at this time and bangs out with exit status 1. There is also a bug in that hwclockfirst must be one of the VERY first things to be run, AND that hwclock must be run AFTER /etc/localtime is working well in a typical Debian system. I.e. *after* /usr is mounted. And there is a third bug which is the lack of easy TZ handling and lack of documentation. The funny thing is that I could swear I added TZ and some
Bug#342887: hwclock must run after /usr
Please remember this is bug is being dealt with with util-linux perspective when reading my answers... On Sun, 01 Jan 2006, Nate Eldredge wrote: Right. Which is kind of painful in the daylight savings case. I can't Correct. It is *flat out impossible* to fix this issue completely (as in do everything transparently) in util-linux. Either one must have one's clock on UTC as any non-braindamaged system does, OR one's /etc/localtime better be in the root partition. Otherwise, one has to keep daylight savings in mind and fix TZ by himself... or risk breakage. Yes. Note that setting TZ is rather inconvenient. First because you have Using a hardware clock not in UTC is extremely inconvenient, as well. In fact, supporting that has been extremely inconvenient for long YEARS, now. I'd have dropped that support a lng time ago. At least this time, I know there is nothing better we can do. The user has two choices, either he must have the hw clock in UTC, or he must have his system fully timezone-capable since instant zero, which means /etc/localtime MUST be in the root partition. Setting TZ is kind of a middleground fix, a best effort fix if you will. And it does work, but it means people have to go and manually fix TZ when entering and leaving daylight savings time... forget which package has the config script where you select your timezone, libc6 has tzconfig. but I guess it could in principle apply it in both places. But that's Yes, it could be changed. kind of ugly, and anyway the Debian philospohy is not to force people into using config scripts. Well, if we were to do it in the strict Debian way (always do what is more correct technically speaking), we would drop non-UTC support. It complicates the boot procedure, it is prone to *very* subtle bugs, and it is technically insane to have a hardware clock in local time, and Microsoft itself only does so because they were dumb enough not to fix that in Windows 95, and because of MSDOS before that. But we try our best to support it, since people seem to find it useful. If that means they will have to jump through loops, that means they will have to jump through loops. But we certainly need to document this better, and d-i should warn the user right away that using the hardware clock in local time mode IS NOT a good idea, and that the system might not be able to deal automatically with daylight savings in that case. What would happen in the typical broken configuration? Non-UTC, /usr separate, no TZ defined anywhere: 0. kernel boots with wrong time (even if it reads the RTC by itself) * 1. hwclock sets the kernel UTC time to the local time in the RTC, and thus the system clock could be wrong by several hours in either direction. 2. System runs with wrong time. e2fsck can croak, etc. 3. something mounts /usr * 4. hwclock runs, and tells the user a completely ludricous time (timezone applied twice :P) === We could fix the mess here, so if the user doesn't hit a bug (e.g. e2fsck) before, he would not suffer much from his broken config. hwclock MUST be run after /usr is mounted to be able to help fix the mess (well work around it, realy). I don't have my unstable box handy to check right now, but it gets fixed eventually. I think when hwclock runs after /usr is mounted, it sets the time correctly. So it's only wrong before that point. I used to have Yes, but this bug showed up exactly because it is not running after /usr anymore (which is in fact broken behaviour and should be fixed, as I explained). You know, another solution would be to relocate the whole /usr/share/zoneinfo hierarchy to the root filesystem. I don't really like That's 5MiB more in the root filesystem. One can always ask the glibc maintainers to do it, or one can ask them to add something that keeps track of /etc/localtime and updates it every time glibc is updated or tzconfig is run, so only the required data would end up in the root partition (and /etc/localtime would not be a symlink anymore). I won't though. If the submitter feels like doing it, be my guest. Remember to point the glibc people to this bug so that they get the whole story. to local time, which isn't really the Unix way. (I only did it because I was dual-booting Windows, which insisted on having the hw clock in local time.) Does it even do that anymore? Anyway, just lie about your timezone to Windows so that you get the correct time, and keep the clock in UTC. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309270: this is not negotiable
tag 309270 + wontfix severity 309270 wishlist thanks I am unable to fix this in any way that would not compromise security, so it will remain as is. 2.1.18 is in deep-maintenance mode, such changes are NOT anywere close to the simple-and-obvious requirements for it. You can add user cyrus to a tls group, and chgrp the certificates to group tls. If THAT doesn't work, reply to the bug and I will track down why. AFAIK cyrus inits supplementary groups just fine. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314724: looks like an openldap bug to me
tag 314724 moreinfo thanks This looks like a bug in your self-compiled openldap 2.1.30. Are you sure you did nothing like: Having two different versions of openldap loaded dynamically (maybe because of nsswitch/glibc) one of which does not use versioned symbols? Having openldap cause [EMAIL PROTECTED]@#$@ libsasl to attempt reentrancy, which often causes it to blow up in pieces? (openldap libs compiled against libsasl and called by sasl from within a sasl context, i.e. you are attempting to authenticate over ldaps)? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320358: (no subject)
This is not a bug. cyrus21-admin works just fine without cyrus21-imapd, if you are administrating a remote imapd. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293503: hplip: Cannot scan with PSC 950
tags 293503 + moreinfo thanks René, do you still have problems with the HPLIP in unstable? If you need it for stable, just download the source, edit debian/control and changelibsnmp9-dev to libsnmp5-dev if any is in there, and build. The resulting binary packages will work fine in Debian Sarge. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Bug#323301: (no subject)
While this whole thing DOES look like it is broken, tc should accept action in place of conform-exceed just fine. But it doesn't because of some bug in tc (not in tcc). action drop works. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332814: racoon-tool has braindead 25s wait on shutdown
Package: racoon Version: 1:0.6.1-1 Severity: normal Utter stupidity in racoon-tool makes everyone wait 25s on every racoon shutdown. This can be quite catasthropic if the machine is being shutdown in a hurry due to imminent power failure for example. The fucking thing should kill -15, sleep at most 1s, kill -0 to see if it is still there, and repeat it at most 25 times, then kill -9 it and go right ahead. It *definately* should not kill -15 then sleep 25 then kill -9 like it is doing now. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.3+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages racoon depends on: ii debconf [debconf-2.0] 1.4.58 Debian configuration management sy ii ipsec-tools 1:0.6.1-1 IPsec tools for Linux ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libssl0.9.7 0.9.7g-3 SSL shared libraries ii perl 5.8.7-5Larry Wall's Practical Extraction racoon recommends no packages. -- debconf information: * racoon/config_mode: racoon-tool -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332846: nut: poweroff action for S90halt never works because /var is offline
Package: nut Version: 2.0.2-1 Severity: important The poweroff action for /etc/init.d/ups-monitor (symlinked to nut) needs to run at S90halt, to power off the load. At that time, everything is unmounted or mounted readonly, etc. So there is no way a serial-line ups can be commanded by nut to poweroff the load (there is no /var with a socket, no running UPS driver...). I am not sure if the serial-line ups driver should try to reopen the device if it cannot open /var/run/nut/* and do it by force, but that certainly would fix it. Still, waiting for the driver to resyncronize with the UPS to send the command can take a long time (~10s for my APC SmartUPS XL with the apcsmart driver), which is not acceptable at this stage. I don't know of a good fix for this. Depending on the UPS, you can just tell it to power off the load in five minutes earlier in the shutdown sequence, and that's it. That means calling /etc/init.d/nut poweroff during /etc/init.d/nut stop IF the powerdown flag is set. One could also move all UPS driver sockets from /var/run to /dev/shm and request that it never be umounted during shutdown since it MUST be on RAM. Debian sort of requires /dev/shm anyway. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.3+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages nut depends on: ii adduser 3.67.2 Add and remove users and groups ii debconf [debconf-2.0] 1.4.58 Debian configuration management sy ii libc6 2.3.5-6GNU C Library: Shared libraries an nut recommends no packages. -- debconf information: nut/major_upstream_changes: nut/remove_debian_conf: nut/major_conf_changes: nut/2_0_upstream_changes: nut/change_system_user: -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333349: openssl: Must either version symbols or conflict with ALL libraries linked to previous version
Package: openssl Version: 0.9.8-2 Severity: critical Justification: breaks unrelated software OpenSSL does not version symbols. This means all applications that somehow end up linked to both openssl 0.9.7 and 0.9.8 segfault or behave otherwise erratically (which would be a critical bug by itself, as openssl is a data privacy/authentication framework with severe consequences for overall system security). Therefore, ANY new ABI-introducing version of openssl has to conflict with ALL **libraries** (not applications) that are linked against other openssl versions. Not doing so is just hiding the mess for the users to find out as segfaults. Transitions like this should be enforced by package dependencies, always. The whole deal is made even worse because some of the libraries linking to openssl are used by PAM modules and/or nssswitch modules, and thus dlopen()ed by a lot/potentially all applications in the system. The conflicts are quite messy, but unless either symbol versioning or another technique that avoids the symbol mess while linked is employed (weak symbols might do it, I think -- but symbol versioning is much easier to predict and understand), it is what must be done. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages openssl depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libssl0.9.8 0.9.8-2SSL shared libraries openssl recommends no packages. -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332846: nut: poweroff action for S90halt never works because /var is offline
On Wed, 26 Oct 2005, Arnaud Quette wrote: The poweroff action for /etc/init.d/ups-monitor (symlinked to nut) needs to run at S90halt, to power off the load. At that time, everything is unmounted or mounted readonly, etc. So there is no way a serial-line ups can be commanded by nut to poweroff the load (there is no /var with a socket, no running UPS driver...). I've already made (upstream) the needed changes in NUT 2.0.3-pre1: From the changelog: 2.0.3-pre1 Thu Aug 16 10:51:17 UTC 2005 / Arnaud Quette [EMAIL PROTECTED] ... - drivers now don't chroot to statepath if called for power off (using -k). This avoid unneeded failure to poweroff the UPS if /var is umounted (thanks to Gaspar Bakos). /etc/init.d/nut stop will have run then. Do the drivers run without the need for any other nut component running in memory? I fixed this on my system by modifying /etc/init.d/nut to initiate the UPS shutdown when needed. The UPS gives the load 5 minutes to finish shutting down before it powers it off. Are there immediate-poweroff UPSes that don't support this delay? Those are not useable with Linux anyway, as the kernel will not have marked RAID arrays clean and read-only at S99, nor will it have flushed drive caches. That happens at final system powerdown. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332846: nut: poweroff action for S90halt never works because /var is offline
On Wed, 26 Oct 2005, Arnaud Quette wrote: About your last question (Are there immediate-poweroff UPSes that don't ...), I don't know for the moment. The RAID problem is known and documented. For the drives, these should already be flushed as we're remounted RO... That is different from a drive cache flush command, and component devices of MD devices won't be flushed without it, since those are NOT clean and read-only at S99. Even if you sent the proper flush commands to the devices that support or need it (and there is the PATA, SATA and SCSI variations of those...), it'd still screw up MD RAID arrays. If you want to support dumb UPSes properly, you have to do so in the kernel as the last thing before a ACPI/APM shutdown or final halt. IMO, the best way to support poweroff with dumb UPSes is to not power them off at all. Let them run near dry and power off the load by themselves. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335814: udevd: get_netlink_msg: no ACTION in payload found
On Wed, 26 Oct 2005, Rogério Brito wrote: On Oct 26 2005, Henrique de Moraes Holschuh wrote: I see it on mounts caused by automount. I don't see it on mounts caused by mount. So, we have one possible culprit. I see it with manual mounting of removable media (e.g., CDs). Hmm... come to think of it, that's what I use automout for. It could be removable media, then. Anyway, I can't reproduce it anymore, since 8 days ago: daemon.log.0:Oct 18 00:47:44 khazad-dum udevd[14729]: get_netlink_msg: no ACTION in payload found, skip event 'umount' It was not the kernel upgrade, that happened on Oct 11 (previously I was running stock 2.6.13.3 and warnings did show). It was not an udev upgrade on that day either, according to aptitude logs. Log shows that I did an init 1 approximately at that time, so it could have been a clean restart of automount or udev (I often kill udevd when I go to single-user mode). If it was a restart of udevd that fixed it, then the upgrade from 0.070-4 to 0.070-5 could be of significance. There are no automount upgrades in the logs. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Bug#336263: hplip-data: Please don't depend on hplip
tag 336263 wontfix severity 336263 wishlist thaks On Sat, 29 Oct 2005, Samuel Mimram wrote: I want to use hplip but I don't need all the qt stuff (in hplip). From the You are out of luck. Upstream mixed things so much that I am dropping hplip-base. I will reconsider this again when hplip goes 1.0.0 with fax support, but for now it will be a single arch any package, plus hpijs (arch any), and the two arch-all packages hplip-ppds and hplip-data. hplip-base description, hplip-base is all I need. However, hplip-base hplip-base is gone with the 0.9.6-1 upload. The new packages conflict with it, it should be impossible to upgrade to 0.9.6 and still remain with hplip-base in the system. depends on hplip-data which now depends on hplip. Is hplip really Parts of hplip-data are needed by the basic daemons, and I am not going to split hplip-data right now. A new package split will happen only when upstream finishes fax support and releases 1.0.0, as I hope that things will settle down, then. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336287: hplip: hp-toolbox does not start
On Sat, 29 Oct 2005, Tibor Hajling wrote: Traceback (most recent call last): File /usr/bin/hp-toolbox, line 274, in ? sys.exit(main(sys.argv[1:])) File /usr/bin/hp-toolbox, line 237, in main client = tbx_client() File /usr/bin/hp-toolbox, line 74, in __init__ self.connect((prop.hpssd_host, prop.hpssd_port)) File /usr/lib/hplip/base/async_qt.py, line 201, in connect raise socket.error, err socket.error: 111 Make sure hpiod and hpssd are running. If they are not, please locate the error messages, and and send them here. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336287: hplip: hp-toolbox does not start
On Sat, 29 Oct 2005, Hajling Tibor wrote: Saturday 29 October 2005 12.41 dátummal Henrique de Moraes Holschuh ezt írta: Make sure hpiod and hpssd are running. If they are not, please locate the error messages, and and send them here. They are not running. There is an error message: You are missing a dpkg-statoverride on /var/run/hplip. Fix it, otherwise you risk silent breakage on upgrades. There is no such a file. What should I do? Run dpkg --pending --configure as root. What happens? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Bug#336643: kernel-package: missing recommends on xmlto (kernel_doc target)
Package: kernel-package Version: 9.008.4 Severity: important xmlto is required for the make-kpng kernel_doc target to work so it should be recommended by kernel-package. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages kernel-package depends on: ii dpkg 1.13.11.0.1 package maintenance system for Deb ii dpkg-dev 1.13.11 package building tools for Debian ii gcc [c-compiler] 4:4.0.2-1 The GNU C compiler ii gcc-2.95 [c-compiler] 1:2.95.4-22.1 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-10The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.4-9 The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.2-3 The GNU C compiler ii gcc272 [c-compiler]2.7.2.3-19The GNU C compiler. ii make 3.80-11 The GNU version of the make util ii perl 5.8.7-7 Larry Wall's Practical Extraction Versions of packages kernel-package recommends: ii bzip2 1.0.2-10 high-quality block-sorting file co ii libc6-dev [libc-dev] 2.3.5-7GNU C Library: Development Librari -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333643: iproute: New upstream: 051007 available
Package: iproute Version: 20041019-3 Severity: wishlist From: Stephen Hemminger [EMAIL PROTECTED] To: netdev@vger.kernel.org Subject:[ANNOUNCE] iproute2 (051007) Date: Fri, 7 Oct 2005 15:43:44 -0700 Cc: lartc@mailman.ds9a.nl Fix one serious bug (in libnetlink), and a couple of other minor patches. http://developer.osdl.org/dev/iproute2/download/iproute2-... Stephen Hemminger Reenable ip mroute Mike Frysinger Handle pfifo_fast that has no qopt without segfaulting Mads Martin Joergensen Trivial netem ccopts Jerome Borsboom Fix regression in ip addr (libnetlink) handling -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages iproute depends on: ii libatm1 2.4.1-17 shared library for ATM (Asynchrono ii libc6 2.3.5-6GNU C Library: Shared libraries an iproute recommends no packages. -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333645: coreutils: dd needs to add O_DIRECT support
Package: coreutils Version: 5.2.1-2.1 Severity: normal Filling this bug as normal instead of wishlist because the lack of O_DIRECT in dd during big io takss causes the kernel to pratically discard all useful cached data and inodes, thus degrading system performance a great deal for no good reason. Coreutils dd does not yet support opening input and output files in O_DIRECT mode, which would be extremely helpful for a great number of operations dd is used for, which are almost always done only once. The RAW devices are scheduled for removal from Linux in December 2005. They are currently the only possible way to work around dd's lack of O_DIRECT support. The use of O_DIRECT should be user-selectable, of course. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages coreutils depends on: ii libacl1 2.2.29-1.0.1 Access control list shared library ii libc6 2.3.5-6 GNU C Library: Shared libraries an coreutils recommends no packages. -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333645: coreutils: dd needs to add O_DIRECT support
On Thu, 13 Oct 2005, Michael Stone wrote: That's a kernel issue, not a dd issue. There are plans to fix that in 2.6.14 by less aggressively caching data for processes that behave like dd (or copy, which does exactly the same thing). Hmm, yes, that would help. Still, it would be good to have O_DIRECT support in dd for all sort of activities that should not cache at all. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333668: fcron: invalid syntax in fcrontab systab
On Thu, 13 Oct 2005, Peter Colberg wrote: A syntax error seems to have slipped in the with the updated fcrontab /var/spool/fcron/systab.orig. fcron requires a space between the leading ampersand and the first time field. I see. The documentation is broken, then. This is in fact a lot more than just minor, I am doing an upload right now. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333645: coreutils: dd needs to add O_DIRECT support
On Thu, 13 Oct 2005, Michael Stone wrote: On Thu, Oct 13, 2005 at 07:34:17AM -0300, Henrique de Moraes Holschuh wrote: Hmm, yes, that would help. Still, it would be good to have O_DIRECT support in dd for all sort of activities that should not cache at all. And, presumably, in cp and mv and any other command that does a lot of I/O. It's much better to paper over a kernel deficiency by modifying every program than by fixing the kernel... Well, IME cp and mv are not *regularly* used to deal with reads/writes from several hundred megabytes to several hundred gigabytes in size, while dd is. So, IMO O_DIRECT support in dd is of much more pratical use than in cp or mv. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333645: coreutils: dd needs to add O_DIRECT support
On Thu, 13 Oct 2005, Michael Stone wrote: Why on earth would you believe that? I think's it's far more common for people to copy something than to dd it. I have never heard of anyone prefering to cp or cat a block device over using dd with a proper block size when doing partition/device zeroing (or as I prefer to do it, urandom'ing :P )/copying, or data cd/dvd copying. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333645: coreutils: dd needs to add O_DIRECT support
On Thu, 13 Oct 2005, Michael Stone wrote: On Thu, Oct 13, 2005 at 08:52:16AM -0300, Henrique de Moraes Holschuh wrote: I have never heard of anyone prefering to cp or cat a block device over using dd with a proper block size when doing partition/device zeroing (or as I prefer to do it, urandom'ing :P )/copying, or data cd/dvd copying. Well, I've never heard of people using dd instead of cp for moving large groups of files from one place to another, which causes exactly the same problem on the system as dd'ing a device and is much more common. And can only be fixed by kernel changes, yes. But how is that related to the fact that dd is likely to be used to manipulate a continuous stream of major proportions from/to a single source/destination and could really benefit from O_DIRECT as an option (I never asked it to be the default mode of operation or anything like that) ? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333746: cupsys: CUPSYS needs an interface for easy reinstall of updated PPDs
Package: cupsys Version: 1.1.23-12 Severity: important CUPS lacks a proper interface for automated update of PPDs. This causes updates in hpijs that require up-to-date hplip-ppds/foomatic-filters-ppds PPDs to silently break printing on people's systems, often in very annoying ways. Ideally, CUPS should reload any PPDs that have been modified on disk, or at the very least allow us to command it to do so programatically. The current way to unbreak printing due to an outdated PPD requires manual intervention from the printing administrator, which needs to Modify the printer in a CUPS administrative interface to force a PPD reload. This is not only very sub-par and user unfriendly, it is also quite often very annoying (CUPS does *NOT* pre-fill the forms with all the current settings, which is a bug on its own). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages cupsys depends on: ii adduser 3.67.2 Add and remove users and groups ii debconf [debconf-2. 1.4.58 Debian configuration management sy ii gs-esp 8+8.15rc4.dfsg.1-2.1 The Ghostscript PostScript interpr ii libc6 2.3.5-6 GNU C Library: Shared libraries an ii libcupsimage2 1.1.23-12Common UNIX Printing System(tm) - ii libcupsys2 1.1.23-12Common UNIX Printing System(tm) - ii libgnutls12 1.2.6-1 the GNU TLS library - runtime libr ii libpam0g0.79-3 Pluggable Authentication Modules l ii libpaper1 1.1.14-3 Library for handling paper charact ii libslp1 1.2.1-3 OpenSLP libraries ii patch 2.5.9-2 Apply a diff file to an original ii perl-modules5.8.7-5 Core Perl modules ii procps 1:3.2.5-1/proc file system utilities ii xpdf-utils 3.01-2 Portable Document Format (PDF) sui ii zlib1g 1:1.2.3-4compression library - runtime Versions of packages cupsys recommends: ii cupsys-client 1.1.23-12Common UNIX Printing System(tm) - ii foomatic-filters3.0.2-20050720-1 linuxprinting.org printer support ii smbclient 3.0.14a-6a LanManager-like simple client fo -- debconf information excluded -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333645: coreutils: dd needs to add O_DIRECT support
tags 333645 = fixed-upstream thanks On Thu, 13 Oct 2005, Jim Meyering wrote: Package: coreutils Version: 5.2.1-2.1 [...] FYI, this option was added for coreutils-5.3.0: * Major changes in release 5.3.0 (2005-01-08) [unstable] ... dd has new iflag= and oflag= options with the following flags: ... directuse direct I/O for data Nice! Thanks, I have tagged the bug accordingly. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333850: (fwd) hplip 0.9.5 bug with network connected printer
Package: hplip Version: 0.9.5-2 Severity: important - Forwarded message from tm [EMAIL PROTECTED] - From: tm [EMAIL PROTECTED] Subject: hplip 0.9.5 bug with network connected printer Date: Wed, 12 Oct 2005 23:33:08 +0300 Hello, Current hplip package (0.9.5-2ubuntu2) has a bug with hp-printing utils when the printer is connected over the ethernet. hpssd daemon tries to ping a network connected printer first but as it runs non-root it will fail in creating a raw icmp socket. This goes mostly undetected by the system, nothing really happens and no error messages are reported back to the user. My simple fix was to redefine doOne in /usr/lib/hplip/base/utils.py as def doOne( destAddr, timeout=10 ): return 1 to indicate that the pinging is always successful (and if there are no printer in the net the outcome from the utils is not much different as it is now). After that at least otherwise non functional utils like hp-info, hp-align, hp-toolbox etc are working again. cheers, tatu - End forwarded message - -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334010: net-snmp: NMU for openssl 0.9.8 transition will be uploaded for a 2-day NMU
Package: net-snmp Severity: wishlist Version: 5.2.1.2-3 I will upload soon a NMU to the 2-day delayed upload queue. The NMU diff is attached. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh diff -ruN net-snmp-5.2.1.2/debian/changelog net-snmp-5.2.1.2.new/debian/changelog --- net-snmp-5.2.1.2/debian/changelog 2005-10-14 20:10:52.480904404 -0300 +++ net-snmp-5.2.1.2.new/debian/changelog 2005-10-14 20:10:25.430190254 -0300 @@ -1,3 +1,10 @@ +net-snmp (5.2.1.2-3.1) unstable; urgency=low + + * NMU + * Version builddep on libssl-dev and rebuild, for openssl transition + + -- Henrique de Moraes Holschuh [EMAIL PROTECTED] Fri, 14 Oct 2005 20:09:45 -0300 + net-snmp (5.2.1.2-3) unstable; urgency=low * Apply official library-version-update-5.2.1.2.patch to clean up the diff -ruN net-snmp-5.2.1.2/debian/control net-snmp-5.2.1.2.new/debian/control --- net-snmp-5.2.1.2/debian/control 2005-10-14 20:10:52.479904525 -0300 +++ net-snmp-5.2.1.2.new/debian/control 2005-10-14 20:09:43.334303751 -0300 @@ -2,7 +2,7 @@ Section: net Priority: optional Maintainer: Jochen Friedrich [EMAIL PROTECTED] -Build-Depends: debhelper (=4.0), libtool, libwrap0-dev, libssl-dev, perl (=5.8), autoconf, automake, debianutils (=1.13.1), bash (=2.05), findutils (=4.1.20), libsensors-dev (=2.8.5) +Build-Depends: debhelper (=4.0), libtool, libwrap0-dev, libssl-dev ( 0.9.8), perl (=5.8), autoconf, automake, debianutils (=1.13.1), bash (=2.05), findutils (=4.1.20), libsensors-dev (=2.8.5) Standards-Version: 3.6.2 Package: snmpd
Bug#334010: net-snmp: NMU for openssl 0.9.8 transition will be uploaded for a 2-day NMU
On Sun, 16 Oct 2005, Steve Langasek wrote: Why are you telling maintainers that you are going to NMU for the openssl transition? Such NMUs have not been discussed with either the release team Well, I am not telling maintainer*s*, so far I just filed a single bug against net-snmp. Because of ld being quite clear that my system was about to go to segfault-happy land, and warning me I was getting stuff doubly linked against openssl 0.9.7 and 0.9.8 already (and net-snmp was the one bringing 0.9.7 to the chain). The openssl transition is under way, the release team was not clear on what we were to do about it, either. I was fully expecting 0.9.8 to be removed off the archive immediately until it was properly fixed. No such luck. The packages for 0.9.8 were not removed, we all waited for a proper fix (versioned symbols) for a bit (thread on d-devel), none was forthcoming and the maintainer made it clear he wouldn't do it without the blessing of upstream or the other distros (but no status updates came about whether such a thing was being attempted or not). 0.9.7 made it back to the archive, with no conflicts and no versioned symbols. I filed a grave/critical bug about 0.9.8 not conflicting with all libs built against 0.9.7... cc'ed to d-devel, even. No reply whatsoever. What is one to do in these conditions? I filed a bug, waited a bit for the NMU (which I didn't even upload, because the maintainer acted much faster), and even if I had, it would have stalled for 2 days. A conservative approach IMHO, given the facts outlined above. I hope my reasons for filling the bug are crystal clear, now. I really AM sorry for disturbing the C++ transition even further, the sooner it is done, the better. But the scenario was not exactly set up to make it easier for such a mistake not to be made. or the QA team, and they would be disruptive of the release team's efforts to complete the C++ ABI transition for KDE and related libraries -- of which there are about a dozen tied in that do *not* come from KDE, and net-snmp is one of them. The openssl transition is not a priority compared to the C++ The net-snmp maintainer clearly was not well informed of this, otherwise instead of doing the upload, he would have told me to hold the NMU (which I would have). ABI transition, and uploads like the net-snmp 5.2.1.2-4 upload that your bug prompted will delay the C++ transition without helping the openssl transition. (net-snmp will have to be rebuilt anyway once libssl0.9.8 provides versioned symbols.) AH, so *now* we are officially told that there WILL be a 0.9.8 with versioned symbols? Glad to know, I certainly could not guess such would happen in the foreseable future, given the messy 0.9.7 upload + callous 0.9.8 upload_s_ we have had so far, and the fact that I read no replies whatsoever to that effect in the d-devel thread. I am less than impressed with the OpenSSL team's way of handling this, so far. Please refrain from bug reports or NMUs for the openssl transition without first discussing the specific case with the release team. I will refrain from doing it of course, now that I have been told about it. Jochen, if you weren't already aware, the libsnmp9 transition is tangled up with the KDE transition because php4 and php5 depend on both; so if you could also hold off on further net-snmp uploads except for RC bugfixes until libsnmp9 makes it into testing, that would also be appreciated. May I humbly suggest that from now on, we have weekly d-d-a emails about all ongoing transitions and naming all packages that are to be left alone (no NMUs, no maintainer uploads without first talking to the release team) ? Better yet, da-katie could be improved to put a source package on hold for manual approval by the release team (after it is approved by the ftp-masters or builtin katie policies) to enforce these transitions more smoothly. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334010: net-snmp: NMU for openssl 0.9.8 transition will be uploaded for a 2-day NMU
On Sun, 16 Oct 2005, Steve Langasek wrote: So now the segfaults move another step down the chain, to someone else running a different application that needs net-snmp built against 0.9.7... Indeed. Until all have transitioned, segfaults would happen. There was no other fix for a openssl without versioned symbols other than transition EVERYTHING as fast as possible. The openssl transition is under way, the release team was not clear on what we were to do about it, either. I was fully expecting 0.9.8 to be removed off the archive immediately until it was properly fixed. No such luck. The options for undoing such a thing once it's started are few, and they all suck. The problem here is comunication, or rather the lack of it, which sucks even more. Nevertheless, it has been discussed on the pkg-openssl-devel mailing list and with the release team: If you don't tell others what you are trying to do, do not complain if they take action without taking into account what you have planned to do... Except that I submitted a patch for your bug less than 24 hours after it was submitted: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=49;msg=16 And the maintainers are considering it. Sorry for not cc:ing you, but all the same, I don't really see how in the absence of versioned symbols, you would feel that one-off NMUs of packages would help the transition. One less package needing to transition is always a help, and in this case it was one that was bothering me. I *had* to force-transition it on my local system or I could not work on my packages, and since the work was already done, why not NMU? As far as I know, other openssl rdeps might be uploading new builds soon (unless they HAVE been told to hold all uploads already). Yes, I'm aware of that. My mail was meant to bring the full situation to your (and Jochen's) attention, to forestall any further openssl-related bugs/NMUs at this point. Well, I certainly won't upload/NMU anything. May I humbly suggest that from now on, we have weekly d-d-a emails about all ongoing transitions and naming all packages that are to be left alone (no NMUs, no maintainer uploads without first talking to the release team) ? The problem is that it's very difficult to identify all packages affected by a transition before the transition is near the point of being ready. Such notification DURING transitions would be already a good enough help, you don't need to simulate a transition and notify people of the definite list of packages before it starts, IMO. Telling people this is the list of packages not to upload, when we don't know it's complete, is worse than telling people this is the transition going on right now. Even that may not be sustainable given the number of transitions that are currently in the air for etch. :/ How come we cannot track down whatever is linked to whatever in the archive? Let's fix this, and it becomes easy to track library transitions with 100% accuracy. I trust the C++ transition can be tracked just like a library one due to libstdc++ ? Better yet, da-katie could be improved to put a source package on hold for manual approval by the release team (after it is approved by the ftp-masters or builtin katie policies) to enforce these transitions more smoothly. Well, that's an idea, but there are a number of other dak/britney changes that are of much higher priority... As long as they happen before hell freezes over... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333349: acknowledged by developer (Bug#330867: fixed in openssl 0.9.8a-1)
On Mon, 17 Oct 2005, Debian Bug Tracking System wrote: * include symbol versioning in Configure (closes: #330867) Thanks! -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334648: Empty /usr/lib/cryptsetup directory inside the deb package
Package: cryptsetup Version: 20050111-3 Severity: minor Either something should be inside /usr/lib/cryptsetup, and it isn't... or the directory should not be there in the first place. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages cryptsetup depends on: ii dmsetup 2:1.01.05-1 The Linux Kernel Device Mapper use ii libc62.3.5-7 GNU C Library: Shared libraries an ii libdevmapper1.01 2:1.01.05-1 The Linux Kernel Device Mapper use ii libgcrypt11 1.2.1-4 LGPL Crypto library - runtime libr ii libgpg-error01.1-4 library for common error values an ii libpopt0 1.7-5 lib for parsing cmdline parameters cryptsetup recommends no packages. -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305366: Please act on this soon
Wesley, Please act on this bug very soon, or I will coordinate with Ubuntu and Michael, and upload a cryptsetup-luks package to superseed cryptsetup. At least reply to this bug and tell us what you think about adding LUKS support, even if it is no, I won't do it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305366: Please act on this soon
On Wed, 19 Oct 2005, Wesley W. Terpstra wrote: On Oct 19, 2005, at 4:47 AM, Henrique de Moraes Holschuh wrote: Please act on this bug very soon, or I will coordinate with Ubuntu and Michael, and upload a cryptsetup-luks package to superseed cryptsetup. This is Michael Pitt? Or someone else? The bug submitter, actually. I've added him to the recipient list. When a LUKS cryptsetup is uploaded, I would like to see it replace cryptsetup. There's little point to having both, IMO. Ok. The easiest way is to change what is inside the cryptstup package, then. Michael Pitt [EMAIL PROTECTED] was going to add LUKS support. I haven't heard back from him in some time, however, so perhaps he's not going to do it anymore. I will bug him, and if he doesn't reply soon, I will take over the mission until he shows up again. If you are interested as well, we could coordinate all things dm-crypt thorugh alioth. Do you think that is worthwhile? Are you using cryptsetup actively? Part of the reason I keep letting the bug reports accumulate is so I can hit them all at once with a reasonable amount of testing. I don't run it much anymore, so unless I sit down to test it, it doesn't get tested. Actually yes, due to the laptop and USB key that really require crypto for the sensivity of the things I carry in them. I use them sporadically, but it is easy enough to move them to everyday use. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334805: dmraid: bad package description
Package: dmraid Severity: important This package is all about supporting SOFTWARE S?ATARAID controlers. You know, winraid crap. The current package description is completely incorrect. I strongly suggest that the package description be changed to the one suggested upstream (FROM http://people.redhat.com/heinzm/sw/dmraid/readme). Here is a slightly edited version of it: Description: Device-Mapper Software RAID support tool dmraid discovers, activates, deactivates and displays properties of software RAID sets (eg, ATARAID) and contained DOS partitions. . dmraid uses the Linux device-mapper to create devices with respective mappings for the ATARAID sets discovered. . The following ATARAID mappings are supported: Highpoint HPT37X and HPT45X Intel Software RAID LSI Logic MegaRAID NVidia NForce RAID Promise FastTrack Silicon Image Medley VIA Software RAID . Please read the documentation in /usr/share/doc/dmraid BEFORE attempting any use of this software. Improper use can cause data loss! Please fix the package description. The tool does NOT manage any hardware controller. Chipsets have nothing to do with it. Also, none of the controllers listed are hardware raid controllers at all. They are just regular ATA/SATA controllers plus a lot marketing spin. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334815: please add a /usr/bin/lyx alternative
Package: lyx Version: 1.3.6-1 Severity: wishlist Please consider adding an alternative /usr/bin/lyx which switches between lyx-xforms and lyx-qt, with a higher priority to lyx-qt (since it has better functionality). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages lyx depends on: ii groff 1.18.1.1-10 GNU troff text-formatting system ii imagemagick6:6.2.4.5-0.2 Image manipulation programs ii libtiff-tools 3.7.4-1 TIFF manipulation and conversion t ii lyx-common 1.3.6-1 High Level Word Processor - common ii lyx-qt 1.3.6-1 High Level Word Processor - Qt fro ii mime-support 3.35-1MIME files 'mime.types' 'mailcap ii preview-latex-style0.9.1-3 LaTeX style files for editor embed ii tetex-bin 3.0-9 The teTeX binary files ii tetex-extra3.0-9 Additional library files of teTeX Versions of packages lyx recommends: ii acroread [pdf-vi 7.0.1-0.0 Adobe Acrobat Reader: Portable Doc ii aspell 0.60.3-5GNU Aspell spell-checker ii cupsys-bsd [lpr] 1.1.23-12 Common UNIX Printing System(tm) - ii elinks [www-brow 0.10.6-1advanced text-mode WWW browser ii gnuhtml2latex0.3-1 A Perl script that converts html f ii gs-esp [postscri 8+8.15rc4.dfsg.1-2.1The Ghostscript PostScript interpr ii gs-gpl [postscri 8.15-4 The GPL Ghostscript PostScript int ii gv [pdf-viewer] 1:3.6.1-12 PostScript and PDF viewer for X ii ispell 3.1.20.0-4 International Ispell (an interacti ii kdeprint 4:3.4.2-3 print system for KDE ii konqueror [www-b 4:3.4.2-3 KDE's advanced file manager, web b ii latex2html 2002-2-1-20050114-3 LaTeX to HTML translator ii linuxdoc-tools 0.9.21-0.1 SGML converters for the LinuxDoc D ii lynx [www-browse 2.8.5-2 Text-mode WWW Browser ii mozilla-browser 2:1.7.12-1 The Mozilla Internet application s ii mozilla-firefox 1.0.7-1 lightweight web browser based on M ii rcs 5.7-16 The GNU Revision Control System ii sgmltools-lite 3.0.3.0.cvs.20010909-13 convert DocBook SGML source into H ii w3m [www-browser 0.5.1-4 WWW browsable pager with excellent ii wv 1.0.2-0.1 Convert and preview Microsoft Word ii xemacs21-gnome-m 21.4.17-2 highly customizable text editor -- ii xemacs21-mule [w 21.4.17-2 highly customizable text editor -- ii xpdf-reader [pdf 3.01-2 Portable Document Format (PDF) sui ii xpdf-utils [pdf- 3.01-2 Portable Document Format (PDF) sui -- debconf information excluded -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334827: NMU: aspell-pt_0.50-2-4.1 diff
Package: aspell-pt-common Version: 0.50-2-4.1 Severity: wishlist I am uploading NMU 0.50-2-4.1 to the DELAYED/1 (one day) queue. Diff attached. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85 Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages aspell-pt-common depends on: ii aspell0.60.3-5 GNU Aspell spell-checker aspell-pt-common recommends no packages. -- no debconf information -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh diff -ruN aspell-pt-0.50-2/debian/aspell-pt.files aspell-pt-0.50-2.new/debian/aspell-pt.files --- aspell-pt-0.50-2/debian/aspell-pt.files 2005-10-20 00:11:39.940904616 -0200 +++ aspell-pt-0.50-2.new/debian/aspell-pt.files 2005-10-20 00:04:48.190915444 -0200 @@ -1,3 +1,2 @@ -usr/lib/aspell-0.60/pt_PT-only.rws +usr/lib/aspell/pt_PT-only.rws usr/share/doc/aspell-pt - diff -ruN aspell-pt-0.50-2/debian/changelog aspell-pt-0.50-2.new/debian/changelog --- aspell-pt-0.50-2/debian/changelog 2005-10-20 00:11:39.939904740 -0200 +++ aspell-pt-0.50-2.new/debian/changelog 2005-10-20 00:11:13.782148042 -0200 @@ -1,3 +1,13 @@ +aspell-pt (0.50-2-4.1) unstable; urgency=low + + * NMU + * Adjust dependencies and install dictionaries to /usr/lib/aspell +so that we are compatible with the new aspell packages. +NOTE: Since this is a NMU, I did not switch to the new install-time +hashing method (closes: #319670, #324799) + + -- Henrique de Moraes Holschuh [EMAIL PROTECTED] Thu, 20 Oct 2005 00:07:56 -0200 + aspell-pt (0.50-2-4) unstable; urgency=low * Built against aspell 0.60.2. diff -ruN aspell-pt-0.50-2/debian/control aspell-pt-0.50-2.new/debian/control --- aspell-pt-0.50-2/debian/control 2005-10-20 00:11:39.939904740 -0200 +++ aspell-pt-0.50-2.new/debian/control 2005-10-20 00:04:24.520845051 -0200 @@ -2,14 +2,14 @@ Section: text Priority: optional Maintainer: Rafael Laboissiere [EMAIL PROTECTED] -Build-Depends: debhelper ( 4.0.0), aspell-bin ( 0.60) +Build-Depends: debhelper ( 4.0.0), aspell (= 0.60.3-3) Standards-Version: 3.6.1 Package: aspell-pt-common Architecture: any -Depends: libaspell15 +Depends: aspell (= 0.60.3-3) Conflicts: aspell-pt (= 0.50-2-2) -Suggests: aspell-bin, aspell-pt, aspell-pt-br +Suggests: aspell-pt, aspell-pt-br Description: Portuguese dictionary for GNU Aspell (common files) This package contains the common files to add support for the Portuguese language to the GNU Aspell spell checker. @@ -19,9 +19,8 @@ Package: aspell-pt Architecture: any -Depends: libaspell15, aspell-pt-common -Provides: aspell6-dictionary -Suggests: aspell-bin +Depends: aspell-pt-common, aspell (= 0.60.3-3) +Provides: aspell6a-dictionary Description: European Portuguese dictionary for GNU Aspell Add support for the European Portuguese language to the GNU Aspell spell checker.
Bug#334805: [Utnubu-maintainers] Bug#334805: dmraid: bad package description
On Thu, 20 Oct 2005, Filippo Giunchedi wrote: please check out the new description: http://svn.debian.org/wsvn/utnubu/packages/dmraid/trunk/debian/?rev=0sc=0 I'd change some stuff: The following chipsets are recognized: is wrong. Chipsets have nothing to do with it, and the list is not a list of chipsets either. I much prefer The following formats are supported: Also, the highpoint entries can be merged, and probably DOS partitions are recognized ONLY inside the mappings done by dm-raid, so on SW RAIDS would be better written inside the above... BUT you already said that in the first paragraph of the extended description, so deleting that item from the list is better. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334805: [Utnubu-maintainers] Bug#334805: dmraid: bad package description
On Thu, 20 Oct 2005, Filippo Giunchedi wrote: thanks, patch accepted! please check the new description at the above url. If that's okay with you I would go for an upload Yeah, I am okay with it :-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333746: cupsys: CUPSYS needs an interface for easy reinstall of updated PPDs
On Thu, 13 Oct 2005, Roger Leigh wrote: Check out cups-genppdupdate in cupsys-driver-gutenprint. This is used I will do so, and add it to hplip-ppds if it does not look dangerous. But the bug stands, CUPS must provide a non-braindamaged way to do this, and it should have done so from day one, actually. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340467: hplip-base depends on libsnmp5 which isn't in testing
severity 340467 important retitle 340467 [britney] removes dependencies from testing making packages uninstalable reassign 340467 ftp.debian.org thanks Summary for ftp.debian.org: hplip-base is still in testing. However, one of its dependencies (Depends:) was removed from testing, making hplip-base uninstalable. hplip-base should have been removed as well, OR the package it Depends: should not have been removed in the first place. Packages involved: hplib-base, libsnmp5 On Wed, 23 Nov 2005, Ido Abramovich wrote: The package hplip-base (0.9.3-3) depends on libsnmp5, but libsnmp5 isn't in the testing repository. WTF why hplip 0.9.3 not removed from testing, then, if one of its dependencies was? This is a very serious problem in the testing archive. the lib package is only available on security.debian.org sarge/updates. That might be a data point. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400747: downgrade to 2.2.13-6 fixes this problem
found 400747 2.2.13-7 thanks On Fri, 01 Dec 2006, Benjamin Seidenberg wrote: Jochen Radmacher wrote: when I downgrade all my cyrus packages to 2.2.13-6 the murder update works again, recompiling the 2.2.13-9 Packages from source does not help. The config was the same in both cases. Jochen, Please get the 2.2.13-9 sources, and edit the debian/patches/00list file. Comment (with a #) or delete the line for patch 0019, and rebuild the package with dpkg-buildpackage. Does that fix the bug? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401895: gnupg2: [CVE-2006-6235] remotely controllable function pointer
Package: gnupg2 Version: 1.9.15-4 Severity: grave Tags: security Justification: user security hole http://lwn.net/Articles/212909/ From: Werner Koch wk-AT-g10code.com To:bugtraq-AT-securityfocus.com Subject: GnuPG: remotely controllable function pointer [CVE-2006-6235] Date: Wed, 06 Dec 2006 16:58:16 +0100 Cc:lwn-AT-lwn.net GnuPG: remotely controllable function pointer [CVE-2006-6235] === 2006-12-04 Summary === Tavis Ormandy of the Gentoo security team identified a severe and exploitable bug in the processing of encrypted packets in GnuPG. [ Please do not send private mail in response to this message. The mailing list gnupg-devel is the best place to discuss this problem (please subscribe first so you don't need moderator approval [1]). ] Impact == Using malformed OpenPGP packets an attacker is able to modify and dereference a function pointer in GnuPG. This is a remotely exploitable bug and affects any use of GnuPG where an attacker can control the data processed by GnuPG. It is not necessary limited to encrypted data, also signed data may be affected. Affected versions: All versions of GnuPG1.4.6 All versions of GnuPG-2 2.0.2 All beta versions of GnuPG-2 (1.9.0 .. 1.9.95) Affected tools: gpg, gpgv, gpg2 and gpgv2. Affected platforms: All. gpg-agent, gpgsm as well as other tools are not affected. A workaround is not known. Solution If you are using a vendor supplied version of GnuPG: * Wait for an update from your vendor. Vendors have been informed on Saturday December 2, less than a day after this bug has been reported. If you are using GnuPG 1.4: * Update as soon as possible to GnuPG 1.4.6. It has been uploaded to the usual location: ftp://ftp.gnupg.org/gcrypt/gnupg/. This version was due to be released anyway this week. See http://www.gnupg.org/download/ for details. * Or: As another and less intrusive option, apply the attached patch to GnuPG 1.4.5. This is the smallest possible fix. If you are using GnuPG 2.0: * Apply the attached patch against GnuPG 2.0.1. * Or: Stop using gpg2 and gpgv2, install GnuPG 1.4.6 and use gpg and gpgv instead. If you are using a binary Windows version of GnuPG: * A binary version of GnuPG 1.4.6 for Windows is available as usual. * Gpg4win 1.0.8, including GnuPG 1.4.6, is available. Please go to http://www.gpg4win.org . Background == GnuPG uses data structures called filters to process OpenPGP messages. These filters ware used in a similar way as a pipelines in the shell. For communication between these filters context structures are used. These are usually allocated on the stack and passed to the filter functions. At most places the OpenPGP data stream fed into these filters is closed before the context structure gets deallocated. While decrypting encrypted packets, this may not happen in all cases and the filter may use a void contest structure filled with garbage. An attacker may control this garbage. The filter context includes another context used by the low-level decryption to access the decryption algorithm. This is done using a function pointer. By carefully crafting an OpenPGP message, an attacker may control this function pointer and call an arbitrary function of the process. Obviously an exploit needs to prepared for a specific version, compiler, libc, etc to be successful - but it is definitely doable. Fixing this is obvious: We need to allocate the context on the heap and use a reference count to keep it valid as long as either the controlling code or the filter code needs it. We have checked all other usages of such a stack based filter contexts but fortunately found no other vulnerable places. This allows to release a relatively small patch. However, for reasons of code cleanness and easier audits we will soon start to change all these stack based filter contexts to heap based ones. Support === g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. As evident by the two vulnerabilities found within a week, a review of the entire code base should be undertaken as soon as possible. As maintainers we try to do our best and are working slowly through the code. The long standing plan is to scrutinize the 2.0 code base, write more test cases and to backport new fixes and cleanups to 1.4. However, as a small company our resources are limited and we need to prioritize other projects which get us actual revenues. Support contracts or other financial backing would greatly help us to improve the quality of GnuPG. Thanks == Tavis Ormandy found this vulnerability. [1] See http://lists.gnupg.org/mailman/listinfo/gnupg-devel . -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990,
Bug#401894: gnupg: [CVE-2006-6235] remotely controllable function pointer
Package: gnupg Version: 1.4.1-1 Severity: grave Tags: security Justification: user security hole http://lwn.net/Articles/212909/ From: Werner Koch wk-AT-g10code.com To:bugtraq-AT-securityfocus.com Subject: GnuPG: remotely controllable function pointer [CVE-2006-6235] Date: Wed, 06 Dec 2006 16:58:16 +0100 Cc:lwn-AT-lwn.net GnuPG: remotely controllable function pointer [CVE-2006-6235] === 2006-12-04 Summary === Tavis Ormandy of the Gentoo security team identified a severe and exploitable bug in the processing of encrypted packets in GnuPG. [ Please do not send private mail in response to this message. The mailing list gnupg-devel is the best place to discuss this problem (please subscribe first so you don't need moderator approval [1]). ] Impact == Using malformed OpenPGP packets an attacker is able to modify and dereference a function pointer in GnuPG. This is a remotely exploitable bug and affects any use of GnuPG where an attacker can control the data processed by GnuPG. It is not necessary limited to encrypted data, also signed data may be affected. Affected versions: All versions of GnuPG1.4.6 All versions of GnuPG-2 2.0.2 All beta versions of GnuPG-2 (1.9.0 .. 1.9.95) Affected tools: gpg, gpgv, gpg2 and gpgv2. Affected platforms: All. gpg-agent, gpgsm as well as other tools are not affected. A workaround is not known. Solution If you are using a vendor supplied version of GnuPG: * Wait for an update from your vendor. Vendors have been informed on Saturday December 2, less than a day after this bug has been reported. If you are using GnuPG 1.4: * Update as soon as possible to GnuPG 1.4.6. It has been uploaded to the usual location: ftp://ftp.gnupg.org/gcrypt/gnupg/. This version was due to be released anyway this week. See http://www.gnupg.org/download/ for details. * Or: As another and less intrusive option, apply the attached patch to GnuPG 1.4.5. This is the smallest possible fix. If you are using GnuPG 2.0: * Apply the attached patch against GnuPG 2.0.1. * Or: Stop using gpg2 and gpgv2, install GnuPG 1.4.6 and use gpg and gpgv instead. If you are using a binary Windows version of GnuPG: * A binary version of GnuPG 1.4.6 for Windows is available as usual. * Gpg4win 1.0.8, including GnuPG 1.4.6, is available. Please go to http://www.gpg4win.org . Background == GnuPG uses data structures called filters to process OpenPGP messages. These filters ware used in a similar way as a pipelines in the shell. For communication between these filters context structures are used. These are usually allocated on the stack and passed to the filter functions. At most places the OpenPGP data stream fed into these filters is closed before the context structure gets deallocated. While decrypting encrypted packets, this may not happen in all cases and the filter may use a void contest structure filled with garbage. An attacker may control this garbage. The filter context includes another context used by the low-level decryption to access the decryption algorithm. This is done using a function pointer. By carefully crafting an OpenPGP message, an attacker may control this function pointer and call an arbitrary function of the process. Obviously an exploit needs to prepared for a specific version, compiler, libc, etc to be successful - but it is definitely doable. Fixing this is obvious: We need to allocate the context on the heap and use a reference count to keep it valid as long as either the controlling code or the filter code needs it. We have checked all other usages of such a stack based filter contexts but fortunately found no other vulnerable places. This allows to release a relatively small patch. However, for reasons of code cleanness and easier audits we will soon start to change all these stack based filter contexts to heap based ones. Support === g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. As evident by the two vulnerabilities found within a week, a review of the entire code base should be undertaken as soon as possible. As maintainers we try to do our best and are working slowly through the code. The long standing plan is to scrutinize the 2.0 code base, write more test cases and to backport new fixes and cleanups to 1.4. However, as a small company our resources are limited and we need to prioritize other projects which get us actual revenues. Support contracts or other financial backing would greatly help us to improve the quality of GnuPG. Thanks == Tavis Ormandy found this vulnerability. [1] See http://lists.gnupg.org/mailman/listinfo/gnupg-devel . -- System Information: Debian Release: 4.0 APT prefers unstable APT policy:
Bug#319874: amarok: screws up gnome notification area
On Thu, 07 Dec 2006, Modestas Vainius wrote: 2005 m. liepa 25 d., pirmadienis 14:40, Henrique de Moraes Holschuh ra??: Amarok screws up when dealing with the GNOME notification area. It always create empty placeholders besides its icon, which remain behind when Amarok quits. This is QUITE annoying, as a fix requires killing the notification applet and adding it back to the pannel. Is it still the case with amarok 1.4.4? I have since dropped most things gnome due to their we know better than you, and we think you're a retard policy, so I wouldn't know. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398533: RFP: tp-smapi -- exposes some features of the ThinkPad - first packaging attempt
On Fri, 08 Dec 2006, Daniel Baumann wrote: You can find the packages at http://debian.die-welt.net/pool/main/tp-smapi/ - I would love to see much feedback, because this is my first real packaging attemt (but neither lintian nor linda do complain). If you're looking for a sponsor, I can do this. A few doubts about this: tp-smapi is either patch-only, or 2.6.19-only. How are you packaging it? It cannot be just built out-of-tree in 2.6.18, it will not always work as it needs to extend the DMI handling code. Also, please make it extremely clear in the package descriptions that the tp-smapi HDAPS is the one people should use (instead of stock HDAPS). Stock HDAPS is buggy and broken. As an extra icing on the cake, stock hdaps won't load if tp-smapi is active, and vice-versa. But you will get confused users wondering why one of the two is not loading... so you need tp-smapi hdaps if you have the tp-smapi drivers loaded. Anyway, the reason why I never packaged it is that to get a proper thinkpad kernel, you need a small stack of patches that are still in flux and I didn't feel it was a good idea to package yet: 1. tp-smapi (which will get through a BIG interface change soon, when the generic battery handling starts being merged, and it is not going to be merged anytime soon); 2. ibm-acpi extended fan and thermal control (got them merged into the linux-acpi test tree yesterday); 3. block queue freeze (was not working on 2.6.18 until less than one month ago, real merge work will probably start now that 2.6.19 is out and there is some in-tree support for what the patch needs), and the hdapsd userspace daemon; 4. The new experimental ACPI bay and dock handling that are in linux-acpi test tree (deprecates lt_hotswap -- out of tree bay handling), or at the very least, ibm-acpi patches for the *60 models; 5. Proper support for SATA (T43, R52 and newer; 2.6.16+), AHCI (T60, R60, X60, z60 and newer; 2.6.19+), fixed PCI-e and MSI support (T43, R52 and newer; 2.6.16 for what the T43/R52 needs, 2.6.19+ for what the *60 models need)... This means a small but scary patches to 2.6.18, one or two on 2.6.19, and a pletora of them on 2.6.17. 6. Something else I am forgetting. Especially because of (5) above, that is required for proper power management and hotplugging (docking, bay), I didn't bother. Anyone would benefit from tp-smapi is likely to want a lot more stuff that requires build your own kernel anyway. For 2.6.19, you can actually have tp-smapi work reliably as an out-of-tree build, so packaging it starts making more sense. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
