Bug#400718: DSA says this bug is fixed.
On Thu, Feb 15, 2007 at 10:48:25PM -0800, Jiggly Puff wrote: I'm sorry if I'm stepping on anybody's toes, but this reeks of unnoticed loose end. This bug is still identified as grave, and is counted as release critical in etch. It isn't counted as release-critical in etch because it's tagged 'sarge', but it doesn't hurt to document it as closed in that etch version either. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410948: license issues with des.tcl
Le jeudi 15 février 2007 21:17, Stephen Gran a écrit : This one time, at band camp, Philippe Cloutier said: Steve Langasek a écrit : On Wed, Feb 14, 2007 at 03:55:53PM -0500, Filipus Klutiero wrote: GOVERNMENT USE: If you are acquiring this software on behalf of the U.S. government, the Government shall have only Restricted Rights in the software and related documentation as defined in the Federal Acquisition Regulations (FARs) in Clause 52.227.19 (c) (2). If you are acquiring the software on behalf of the Department of Defense, the software shall be classified as Commercial Computer Software and the Government shall have only Restricted Rights as defined in Clause 252.227-7013 (c) (1) of DFARs. This part clarifies that that the government has no additional rights beyond those of the license. Notwithstanding the foregoing, the authors grant the U.S. Government and others acting in its behalf permission to use and distribute the software in accordance with the terms specified in this license. And this grants them standard rights under the GPL. No, this is a statement that the copyright on the work is not *waived* where the federal government is concerned. It doesn't contradict the GPL, it merely clarifies that the government has no implicit, special rights over the software beyond those specified in the GPL. Hum, this is not what I read. Do you agree that the license basically states that the Department of Defense has only Restricted Rights as defined in Clause 252.227-7013 (c) (1) of DFARs on the software? Does that make it clearer? No, sorry. I already know that the first part is the restrictive one and the last part is the permissive one. The problem is that I see them as conflicting.
Bug#410948: license issues with des.tcl
Le jeudi 15 février 2007 21:41, Steve Langasek a écrit : On Thu, Feb 15, 2007 at 09:07:25PM -0500, Philippe Cloutier wrote: GOVERNMENT USE: If you are acquiring this software on behalf of the U.S. government, the Government shall have only Restricted Rights in the software and related documentation as defined in the Federal Acquisition Regulations (FARs) in Clause 52.227.19 (c) (2). If you are acquiring the software on behalf of the Department of Defense, the software shall be classified as Commercial Computer Software and the Government shall have only Restricted Rights as defined in Clause 252.227-7013 (c) (1) of DFARs. Notwithstanding the foregoing, the authors grant the U.S. Government and others acting in its behalf permission to use and distribute the software in accordance with the terms specified in this license. IANAL, but this seems to prohibit some things allowed by the GPL to the U.S. government. If I understand right, the U.S. Department of Defense is not allowed to redistribute or copy freely des.tcl, which would violate the DFSG. No, this is a statement that the copyright on the work is not *waived* where the federal government is concerned. It doesn't contradict the GPL, it merely clarifies that the government has no implicit, special rights over the software beyond those specified in the GPL. Hum, this is not what I read. Do you agree that the license basically states that the Department of Defense has only Restricted Rights as defined in Clause 252.227-7013 (c) (1) of DFARs on the software? Have you read the cited clause of DFARs? Yes. The numbering listed in this clause appears to be obsolete, but Restricted Rights as specified in the current version enumerates an extensive list of things the government is allowed to do. Yes but as I wrote this doesn't seem allow to redistribute or copy freely. But in any case, the following sentence is what matters: Notwithstanding the foregoing, the authors grant the U.S. Government and others acting in its behalf permission to use and distribute the software in accordance with the terms specified in this license. IOW, in *spite* of citing this government regulation, permission is granted to use and distribute the software *under the normal license*. This is also what I read. Do you agree that given the content of this government regulation, the license is/looks conflicting? Again, this is an effort to keep the government from claiming *more* rights over the software than what's permitted by the usual license, not to prevent the government from exercising rights that are granted to everyone else. To make it clear, I believed you when you first stated this. But re-reading the license, it's still not how I interpret what's written.
Bug#411113: ogre: FTBFS: cannot allocate an object of abstract type 'CEGUI::OgreCEGUITexture'
Package: ogre Version: 1.0.6-1.4 Severity: serious Hello, There was a problem while autobuilding your package: Automatic build of ogre_1.0.6-1.4 on nasya by sbuild/sparc 0.52 Build started at 20070216-0723 ** ... then mv -f .deps/OgreXMLConverter-tinyxmlerror.Tpo .deps/OgreXMLConverter-tinyxmlerror.Po; else rm -f .deps/OgreXMLConverter-tinyxmlerror.Tpo; exit 1; fi if sparc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../OgreMain/include -I../../../OgreMain/include -I../../../Tools/XMLConverter/include -DTIXML_USE_STL -g -O2 -MT OgreXMLConverter-tinyxmlparser.o -MD -MP -MF .deps/OgreXMLConverter-tinyxmlparser.Tpo -c -o OgreXMLConverter-tinyxmlparser.o `test -f 'tinyxmlparser.cpp' || echo './'`tinyxmlparser.cpp; \ then mv -f .deps/OgreXMLConverter-tinyxmlparser.Tpo .deps/OgreXMLConverter-tinyxmlparser.Po; else rm -f .deps/OgreXMLConverter-tinyxmlparser.Tpo; exit 1; fi /bin/sh ../../../libtool --tag=CXX --mode=link sparc-linux-gnu-g++ -g -O2 -o OgreXMLConverter -L../../../OgreMain/src OgreXMLConverter-OgreXMLMeshSerializer.o OgreXMLConverter-OgreXMLSkeletonSerializer.o OgreXMLConverter-main.o OgreXMLConverter-tinystr.o OgreXMLConverter-tinyxml.o OgreXMLConverter-tinyxmlerror.o OgreXMLConverter-tinyxmlparser.o -lOgreMain -lILU -lIL -lpthread -lz -lm -ldl mkdir .libs sparc-linux-gnu-g++ -g -O2 -o .libs/OgreXMLConverter OgreXMLConverter-OgreXMLMeshSerializer.o OgreXMLConverter-OgreXMLSkeletonSerializer.o OgreXMLConverter-main.o OgreXMLConverter-tinystr.o OgreXMLConverter-tinyxml.o OgreXMLConverter-tinyxmlerror.o OgreXMLConverter-tinyxmlparser.o -L/build/buildd/ogre-1.0.6/build-tree/ogre-free/OgreMain/src /build/buildd/ogre-1.0.6/build-tree/ogre-free/OgreMain/src/.libs/libOgreMain.so /usr/lib/libILU.so /usr/lib/libIL.so -lpthread -lz -lm -ldl creating OgreXMLConverter make[4]: Leaving directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/XMLConverter/src' make[4]: Entering directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/XMLConverter' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/XMLConverter' make[3]: Leaving directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/XMLConverter' Making all in MeshUpgrader make[3]: Entering directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/MeshUpgrader' Making all in src make[4]: Entering directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/MeshUpgrader/src' if sparc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../OgreMain/include -I../../../OgreMain/include -I../../../Tools/MeshUpgrader/include-g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cpp; \ then mv -f .deps/main.Tpo .deps/main.Po; else rm -f .deps/main.Tpo; exit 1; fi /bin/sh ../../../libtool --tag=CXX --mode=link sparc-linux-gnu-g++ -g -O2 -o OgreMeshUpgrade -L../../../OgreMain/src main.o -lOgreMain -lILU -lIL -lpthread -lz -lm -ldl mkdir .libs sparc-linux-gnu-g++ -g -O2 -o .libs/OgreMeshUpgrade main.o -L/build/buildd/ogre-1.0.6/build-tree/ogre-free/OgreMain/src /build/buildd/ogre-1.0.6/build-tree/ogre-free/OgreMain/src/.libs/libOgreMain.so /usr/lib/libILU.so /usr/lib/libIL.so -lpthread -lz -lm -ldl creating OgreMeshUpgrade make[4]: Leaving directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/MeshUpgrader/src' make[4]: Entering directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/MeshUpgrader' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/MeshUpgrader' make[3]: Leaving directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/MeshUpgrader' Making all in MaterialUpgrader make[3]: Entering directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/MaterialUpgrader' Making all in include make[4]: Entering directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/MaterialUpgrader/include' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/MaterialUpgrader/include' Making all in src make[4]: Entering directory `/build/buildd/ogre-1.0.6/build-tree/ogre-free/Tools/MaterialUpgrader/src' if sparc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../OgreMain/include -I../../../OgreMain/include -I../../../Tools/MaterialUpgrader/include-g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cpp; \ then mv -f .deps/main.Tpo .deps/main.Po; else rm -f .deps/main.Tpo; exit 1; fi if sparc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../OgreMain/include -I../../../OgreMain/include -I../../../Tools/MaterialUpgrader/include-g -O2 -MT OldMaterialReader.o -MD -MP -MF .deps/OldMaterialReader.Tpo -c -o OldMaterialReader.o OldMaterialReader.cpp
Bug#410946: debsecan: Overwrites local configuration
* Frank Küster: Since all that debsecan-create-cron does is to choose a random time, set the suite and decide whether the file should exist at all, it shouldn't be hard to do that in a policy-conformant way: The main reason why I did this way is that it's difficult to reschedule the actual work done by debsecan merely by editing the crontab entry. - chosing a random time is only needed when the file doesn't exist Okay. - the suite can be changed by a simple sed -i command This is also wrong because this is a crontab entry, not a configuration file. You cannot assume anything about its syntax (beyond the part which is interpreted by cron). sed -i is also not available on sarge IIRC, but it's esay to work around that. It seems that the correct fix is another level of indirection: The actual configuration has to be put into a file with tighter syntactic constraints.
Bug#411118: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability
Package: clamav Version: 0.84-2.sarge.13 Severity: serious All versions prior to 0.90 are suspected to be vulnerable to a resource consumption vulnerability in Clam AntiVirus' ClamAV allows remote attackers to degrade the service of the clamd scanner. E.g., legitimate email can be refused because of this bug. v0.90RC1.1 is confirmed to be vulnerable. Upstream 0.90 fixes this. A sarge security fix backport will probably be needed. Ciao, -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages clamav depends on: ii clamav-freshclam [cla 0.84-2.sarge.13downloads clamav virus databases f ii libbz2-1.01.0.2-7high-quality block-sorting file co ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an ii libclamav10.84-2.sarge.13virus scanner library ii libcurl3 7.13.2-2sarge5 Multi-protocol file transfer libra ii libgmp3 4.1.4-6Multiprecision arithmetic library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libssl0.9.7 0.9.7e-3sarge4 SSL shared libraries ii zlib1g1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411117: clamav: CVE-2007-0898 - MIME Header Directory Traversal
Package: clamav Version: 0.84-2.sarge.13 Severity: serious Hello, All versions prior to the 0.90 stable release are suspected to be vulnerable to a directory traversal vulnerability that allows remote attackers to overwrite files owned by the clamd scanner, such as the virus database file. This has been assigned the name CVE-2007-0898, and has been fixed in upstream 0.90. A sarge security fix backport will probably be needed. Ciao, -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages clamav depends on: ii clamav-freshclam [cla 0.84-2.sarge.13downloads clamav virus databases f ii libbz2-1.01.0.2-7high-quality block-sorting file co ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an ii libclamav10.84-2.sarge.13virus scanner library ii libcurl3 7.13.2-2sarge5 Multi-protocol file transfer libra ii libgmp3 4.1.4-6Multiprecision arithmetic library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libssl0.9.7 0.9.7e-3sarge4 SSL shared libraries ii zlib1g1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 411118 is important
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.27 # DoS is important, not serious severity 48 important Bug#48: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability Severity set to `important' from `serious' End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410843: fixed in spamassassin 3.1.7-2
Hello, Duncan Findlay wrote (15 Feb 2007 05:47:03 GMT) : Source: spamassassin Source-Version: 3.1.7-2 We believe that the bug you reported is fixed in the latest version of spamassassin, which is due to be installed in the Debian FTP archive: Are there plans to prepare sarge packages backporting the security fix ? Ciao, -- intrigeri [EMAIL PROTECTED] | gnupg key @ http://intrigeri.boum.org/intrigeri.asc | The impossible just takes a bit longer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408249: marked as done (linux-sound-base: postinst fails: ln: creating symbolic link `/etc/modutils/linux-sound-base_noOSS' to `/lib/linux-sound-base/noOSS.modutils.conf': No such file or director
Your message dated Fri, 16 Feb 2007 12:02:03 + with message-id [EMAIL PROTECTED] and subject line Bug#408249: fixed in alsa-driver 1.0.13-4 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: linux-sound-base Version: 1.0.13-3 Severity: serious Usertags: grid5000 piuparts Hi, During a piuparts run over all the packages in etch, I ran into a problem with your package: Setting up linux-sound-base (1.0.13-3) ... ln: creating symbolic link `/etc/modutils/linux-sound-base_noOSS' to `/lib/linux-sound-base/noOSS.modutils.conf': No such file or directory dpkg: error processing linux-sound-base (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: linux-sound-base E: Sub-process /usr/bin/dpkg returned an error code (1) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | ---End Message--- ---BeginMessage--- Source: alsa-driver Source-Version: 1.0.13-4 We believe that the bug you reported is fixed in the latest version of alsa-driver, which is due to be installed in the Debian FTP archive: alsa-base_1.0.13-4_all.deb to pool/main/a/alsa-driver/alsa-base_1.0.13-4_all.deb alsa-driver_1.0.13-4.diff.gz to pool/main/a/alsa-driver/alsa-driver_1.0.13-4.diff.gz alsa-driver_1.0.13-4.dsc to pool/main/a/alsa-driver/alsa-driver_1.0.13-4.dsc alsa-source_1.0.13-4_all.deb to pool/main/a/alsa-driver/alsa-source_1.0.13-4_all.deb linux-sound-base_1.0.13-4_all.deb to pool/main/a/alsa-driver/linux-sound-base_1.0.13-4_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jordi Mallach [EMAIL PROTECTED] (supplier of updated alsa-driver package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 16 Feb 2007 10:32:45 +0100 Source: alsa-driver Binary: linux-sound-base alsa-source alsa-base Architecture: source all Version: 1.0.13-4 Distribution: unstable Urgency: medium Maintainer: Debian ALSA Maintainers [EMAIL PROTECTED] Changed-By: Jordi Mallach [EMAIL PROTECTED] Description: alsa-base - ALSA driver configuration files alsa-source - ALSA driver sources linux-sound-base - base package for ALSA and OSS sound systems Closes: 408249 Changes: alsa-driver (1.0.13-4) unstable; urgency=medium . [ Elimar Riesebieter ] * Added etc/modutils and etc/modprobe.d to debian/linux-sound-base.dirs. This will offer the possibility to upgrade from 2.4 to 2.6 kernels as well to downgrade from 2.6. to 2.4 kernels. The links from /lib/linux-sound-base/ will be created for sure now. (closes: #408249) Thanks to Lucas Nussbaum and Gregor Herrmann. * Urgency set to medium as this will affect etch significantly. Files: f5c60261b893db51e604988895a97dbe 850 sound optional alsa-driver_1.0.13-4.dsc b3db45cd09155090d7e01565e01f1a7f 265701 sound optional alsa-driver_1.0.13-4.diff.gz b040443e204cb14a9c60135ebff25388 28218 sound optional linux-sound-base_1.0.13-4_all.deb b0f9c0ef24c55cf0033b17316e562f1f 168588 sound optional alsa-base_1.0.13-4_all.deb 10ec37d5d5a7a5fa2f8ab15b3240ec90 2539116 sound optional alsa-source_1.0.13-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF1Zu0JYSUupF6Il4RAtshAKDfZLkWn41lbm8oJPPufIrJIcXNqQCgylOI NJ50x2Wk2BEDW7rXYADubAE= =4k9b -END PGP SIGNATURE- ---End Message---
Bug#411117: clamav: CVE-2007-0898 CVE-2007-0897
found 47 0.84-2.sarge.13 found 47 0.88.7-1 found 47 0.90~rc3-1 notfound 47 0.84-2.sarge.14 notfound 47 0.88.7-2 notfound 47 0.90-1 close 47 0.90-1 close 47 0.88.7-2 close 47 0.84-2.sarge.14 found 48 0.84-2.sarge.13 found 48 0.88.7-1 found 48 0.90~rc3-1 notfound 48 0.84-2.sarge.14 notfound 48 0.88.7-2 notfound 48 0.90-1 close 48 0.90-1 close 48 0.88.7-2 close 48 0.84-2.sarge.14 thanks Fixes for these have been uploaded to stable-security, volatile, testing-proposed-updates, and unstable. Sorry about any wait time - it's now out of my hands. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Processed: Re: Bug#411117: clamav: CVE-2007-0898 CVE-2007-0897
Processing commands for [EMAIL PROTECTED]: found 47 0.84-2.sarge.13 Bug#47: clamav: CVE-2007-0898 - MIME Header Directory Traversal Bug marked as found in version 0.84-2.sarge.13. found 47 0.88.7-1 Bug#47: clamav: CVE-2007-0898 - MIME Header Directory Traversal Bug marked as found in version 0.88.7-1. found 47 0.90~rc3-1 Bug#47: clamav: CVE-2007-0898 - MIME Header Directory Traversal Bug marked as found in version 0.90~rc3-1. notfound 47 0.84-2.sarge.14 Bug#47: clamav: CVE-2007-0898 - MIME Header Directory Traversal Bug marked as not found in version 0.84-2.sarge.14. notfound 47 0.88.7-2 Bug#47: clamav: CVE-2007-0898 - MIME Header Directory Traversal Bug marked as not found in version 0.88.7-2. notfound 47 0.90-1 Bug#47: clamav: CVE-2007-0898 - MIME Header Directory Traversal Bug marked as not found in version 0.90-1. close 47 0.90-1 Bug#47: clamav: CVE-2007-0898 - MIME Header Directory Traversal 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug marked as fixed in version 0.90-1, send any further explanations to [EMAIL PROTECTED] close 47 0.88.7-2 Bug#47: clamav: CVE-2007-0898 - MIME Header Directory Traversal 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug marked as fixed in version 0.88.7-2, send any further explanations to [EMAIL PROTECTED] close 47 0.84-2.sarge.14 Bug#47: clamav: CVE-2007-0898 - MIME Header Directory Traversal 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug marked as fixed in version 0.84-2.sarge.14, send any further explanations to [EMAIL PROTECTED] found 48 0.84-2.sarge.13 Bug#48: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability Bug marked as found in version 0.84-2.sarge.13. found 48 0.88.7-1 Bug#48: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability Bug marked as found in version 0.88.7-1. found 48 0.90~rc3-1 Bug#48: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability Bug marked as found in version 0.90~rc3-1. notfound 48 0.84-2.sarge.14 Bug#48: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability Bug marked as not found in version 0.84-2.sarge.14. notfound 48 0.88.7-2 Bug#48: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability Bug marked as not found in version 0.88.7-2. notfound 48 0.90-1 Bug#48: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability Bug marked as not found in version 0.90-1. close 48 0.90-1 Bug#48: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug marked as fixed in version 0.90-1, send any further explanations to [EMAIL PROTECTED] close 48 0.88.7-2 Bug#48: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug marked as fixed in version 0.88.7-2, send any further explanations to [EMAIL PROTECTED] close 48 0.84-2.sarge.14 Bug#48: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug marked as fixed in version 0.84-2.sarge.14, send any further explanations to [EMAIL PROTECTED] thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410946: debsecan: Overwrites local configuration
Florian Weimer [EMAIL PROTECTED] wrote: - the suite can be changed by a simple sed -i command This is also wrong because this is a crontab entry, not a configuration file. You cannot assume anything about its syntax (beyond the part which is interpreted by cron). That's a point. sed -i is also not available on sarge IIRC, but it's esay to work around that. Yes, is debsecan on backports.org? It seems that the correct fix is another level of indirection: The actual configuration has to be put into a file with tighter syntactic constraints. That's what I wanted to suggest when I read your remark. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#410557: /etc/dokuwiki/.htaccess doesn't exist in Debian package and allow access to acl and users
Hi, There are more web applications in Debian accessing to /etc. For example PhpMyAdmin: ~$ ls -l /usr/share/phpldapadmin/config/config.php config.php - /etc/phpldapadmin/config.php Thanks for using my package as an example, but this way of referencing the config is not insecure. Thijs signature.asc Description: This is a digitally signed message part
Bug#406465: [bind backend] TXT record parsing overflow with special characters
On Sat, Feb 10, 2007 at 11:13:11AM +0100, Jeroen van Wolffelaar wrote: An option, therefore, is to have a pdns uploaded without the bind backend, and a NEWS.Debian stating that sorry, no bind backend available, because it's not of release quality or something. Since other than our brief attempt at using pdns-with-bind-backend, I'm not having any experience with pdns, I don't feel comfortable making this change (and decision) myself, it's also pretty invasive so not typically something to do in a NMU. Maintainers, what's the status? As it stands now, powerdns runs the risk of being removed from testing and that way not making it into etch. If you'd give your opinion on whether or not removing the bind backend would be an acceptable solution, someone could make an upload of it. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289739: marked as done (inform-docs: postinst use test -e update-menus instead of test -x update-menus)
Your message dated Fri, 16 Feb 2007 13:02:02 + with message-id [EMAIL PROTECTED] and subject line Bug#289739: fixed in inform 6.30-2.1 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: inform-docs Version: 6.30-1 Severity: serious Hello Mark, postinst and postrm include if [ -e /usr/bin/update-menus ]; then update-menus fi Actually they should check whether /usr/bin/update-menus is executable (with -x), it is not sufficient to check if the file exists, since /usr/bin/update-menus is shipped without the x bit which is added later by menu postinst. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. ---End Message--- ---BeginMessage--- Source: inform Source-Version: 6.30-2.1 We believe that the bug you reported is fixed in the latest version of inform, which is due to be installed in the Debian FTP archive: inform-docs_6.30-2.1_all.deb to pool/non-free/i/inform/inform-docs_6.30-2.1_all.deb inform_6.30-2.1.diff.gz to pool/non-free/i/inform/inform_6.30-2.1.diff.gz inform_6.30-2.1.dsc to pool/non-free/i/inform/inform_6.30-2.1.dsc inform_6.30-2.1_i386.deb to pool/non-free/i/inform/inform_6.30-2.1_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Thijs Kinkhorst [EMAIL PROTECTED] (supplier of updated inform package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 16 Feb 2007 13:37:13 +0100 Source: inform Binary: inform-docs inform Architecture: source i386 all Version: 6.30-2.1 Distribution: unstable Urgency: medium Maintainer: Mark Baker [EMAIL PROTECTED] Changed-By: Thijs Kinkhorst [EMAIL PROTECTED] Description: inform - A compiler for adventure games inform-docs - Supplementary documentation for inform Closes: 289739 326991 406985 Changes: inform (6.30-2.1) unstable; urgency=medium . * Non-maintainer upload with maintainer consent. * Finish /usr/doc transition (Closes: #406985). * Test -x for update-menus (RC bug, closes: #289739). * Don't install Makefile under /usr/share/info (Closes: #326991). * Let inform suggest inform-docs. * Fixed the following Lintian problems: spelling-error-in-copyright, description-synopsis-might-not-be-phrased-properly, install-info-not-called-with-quiet-option, menu-file-in-usr-lib, symlink-should-be-relative, manpage-has-errors-from-man, configure-generated-file-in-source, diff-contains-substvars, outdated-autotools-helper-file Files: b6efd7c8069029af0e6dcf721f0a45f6 573 non-free/devel optional inform_6.30-2.1.dsc 579766f59b84c30a7fb8265b1249111d 82719 non-free/devel optional inform_6.30-2.1.diff.gz e6e0d5a65eedccbc6300de4966a93e3f 608368 non-free/devel optional inform-docs_6.30-2.1_all.deb 48251ebbec6179c5b9890a7ae867705d 692946 non-free/devel optional inform_6.30-2.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF1ahHJdKMxZV9WM8RAkjsAJ9wnc5AQhuZnN2yIi7V8IY6vgm6ZwCfStls xgPkEbWmcEqD0mcybPinDkk= =Omg6 -END PGP SIGNATURE- ---End Message---
Bug#406465: [bind backend] TXT record parsing overflow with special characters
On Friday 16 February 2007 13:57, Jeroen van Wolffelaar wrote: On Sat, Feb 10, 2007 at 11:13:11AM +0100, Jeroen van Wolffelaar wrote: An option, therefore, is to have a pdns uploaded without the bind backend, and a NEWS.Debian stating that sorry, no bind backend available, because it's not of release quality or something. Since other than our brief attempt at using pdns-with-bind-backend, I'm not having any experience with pdns, I don't feel comfortable making this change (and decision) myself, it's also pretty invasive so not typically something to do in a NMU. Maintainers, what's the status? As it stands now, powerdns runs the risk of being removed from testing and that way not making it into etch. Apologies. I'll contact the upstream about this bug report now. Unfortunately Matthijs is currently very busy at work so he didn't handle it yet. And I had no internet connection for a while that kept me from working on it. So the package has actually been badly maintained for a while. I will try to improve that. If you'd give your opinion on whether or not removing the bind backend would be an acceptable solution, someone could make an upload of it. Let us first see what the upstream thinks of it. If I don't get a timely answer we can still consider removing the bind backend. Help is definitely welcome in maintaining the package. But I'll get on my backlog today anyway. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402603: tomcat5.5: blocks on startup until log pipe is read
I've fixed this locally in two ways:
a) use cronolog and alter init.d (see attached diff)
Pro: simple
Con: end up with two logs
b) using log4j
Pro: catalina.log file has predictable name for log analysis
Con: more complicated
for b) you need to delete the -outfile and -errfile line from the
init.d script, then create
/usr/share/tomcat5.5/common/classes/log4j.properties (attached)
finally creating two symlinks:
ln -s ../../../java/log4j-1.2.jar
/usr/share/tomcat5.5/common/lib/log4j.jar
ln -s ../../../java/commons-logging.jar
/usr/share/tomcat5.5/common/lib/commons$
I'm actually using method b) because it's essential that I have a
predictable filename for log monitoring.
Adrian
--
Adrian Bridgett - [EMAIL PROTECTED]
GPG key available on public key servers
--- tomcat5.5.orig 2007-02-16 09:47:34.0 +
+++ tomcat5.5.cronolog 2007-02-16 13:48:27.0 +
@@ -101,6 +101,7 @@
# Define other required variables
CATALINA_PID=/var/run/$NAME.pid
LOGFILE=$CATALINA_BASE/logs/catalina.out
+CRONOLOG_OPTS=-S $CATALINA_BASE/logs/catalina.cronolog
$CATALINA_BASE/logs/catalina.%Y-%m-%d.cronolog
BOOTSTRAP_CLASS=org.apache.catalina.startup.Bootstrap
JSVC_CLASSPATH=/usr/share/java/commons-daemon.jar:$CATALINA_HOME/bin/bootstrap.jar
@@ -147,8 +148,9 @@
$CATALINA_BASE/logs/catalina.out || true
$DAEMON -user $TOMCAT5_USER -cp $JSVC_CLASSPATH \
- -outfile $LOGFILE -errfile '1' \
+ -outfile $LOGFILE -errfile '1' \
-pidfile $CATALINA_PID $JAVA_OPTS $BOOTSTRAP_CLASS
+ start-stop-daemon --start --user $TOMCAT5_USER --exec
/usr/bin/cronolog -- $CRONOLOG_OPTS $LOGFILE
else
log_progress_msg (already running)
fi
log4j.rootLogger=INFO, R
log4j.appender.R=org.apache.log4j.DailyRollingFileAppender
log4j.appender.R.File=${catalina.home}/logs/catalina.log
log4j.appender.R.DatePattern='.'-MM-dd
#log4j.appender.R.MaxFileSize=10MB
#log4j.appender.R.MaxBackupIndex=10
log4j.appender.R.layout=org.apache.log4j.PatternLayout
# default ConversionPattern doesn't include timestamps
#log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
log4j.appender.R.layout.ConversionPattern=%-5p %d{-MM-dd HH:mm:ss,SSS}
%C{1}:%M (%l) - %m%n
#log4j.logger.org.apache.catalina=INFO, R
Bug#410047: marked as done (infinite dialog popups)
Your message dated Fri, 16 Feb 2007 14:47:02 + with message-id [EMAIL PROTECTED] and subject line Bug#410047: fixed in gajim 0.10.1-7 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: gajim Version: 0.10.1-6 Severity: serious Gajim is unusable with a Wildfire server [1]. The issue is fixed in the last upstream release. Is it possible to have a backport for testing before Etch release? http://trac.gajim.org/ticket/2028 Best regards, Gonéri pgp7juDlD1TLd.pgp Description: PGP signature ---End Message--- ---BeginMessage--- Source: gajim Source-Version: 0.10.1-7 We believe that the bug you reported is fixed in the latest version of gajim, which is due to be installed in the Debian FTP archive: gajim_0.10.1-7.diff.gz to pool/main/g/gajim/gajim_0.10.1-7.diff.gz gajim_0.10.1-7.dsc to pool/main/g/gajim/gajim_0.10.1-7.dsc gajim_0.10.1-7_i386.deb to pool/main/g/gajim/gajim_0.10.1-7_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Yann Le Boulanger [EMAIL PROTECTED] (supplier of updated gajim package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 15 Feb 2007 17:56:24 +0100 Source: gajim Binary: gajim Architecture: source i386 Version: 0.10.1-7 Distribution: testing-proposed-updates Urgency: low Maintainer: Yann Le Boulanger [EMAIL PROTECTED] Changed-By: Yann Le Boulanger [EMAIL PROTECTED] Description: gajim - Jabber client written in PyGTK Closes: 410047 Changes: gajim (0.10.1-7) testing-proposed-updates; urgency=low . * Backport patch from http://trac.gajim.org/changeset/6606 to detect loop when server isn't RFC complient and handles badly subscription acknoledgment: 00_fix-infinite-dialog-popups.patch (Closes: #410047) Files: 23843da6da3e61b5b3d480cdcbea369e 724 net optional gajim_0.10.1-7.dsc 04e00eaee7aceadd0f614402ee70ff42 7989 net optional gajim_0.10.1-7.diff.gz bb956bbf1978d6d1a43f361bb8ed133d 2420318 net optional gajim_0.10.1-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF1N6VOU3FkQ7XBOoRAoT9AJ92Aeppa1E7uoJXDTxcKfamqcO+SgCePJmz MmHb/+/22co0hVPE8rtbctw= =BQ0J -END PGP SIGNATURE- ---End Message---
Bug#401916: Bug 401916: analysis and suggested solution
I've spent more time researching this by reading kernel code, checking the boot process of other distros and trolling through mailing list archives and I think I have a pretty good picture of the problem now. Description: Basically udevsettle will return once all modules have been loaded and no more uevents are pending. all modules include e.g. scsi host drivers and usb host drivers. The problem is that even if a module has been loaded for a usb host which has a storage device attached, the usb host driver will not emit uevents for the device immediately. Instead the scanning is done asynchronously and might take an arbitrary amount of time (based on things like the reset-time of the storage device, which can be several seconds, the number of hubs between the host and the device, etc). The same goes for several other buses (e.g. SCSI, Firewire, fibre-channel, etc), and we won't be able to solve it completely by watching kernel threads (the approach that I tried in earlier mails to the same BR). Short-term solution: Therefore, I think the best short-term solution (considering the ever-impending Etch release) would be to add the root_wait= boot parameter so that affected users can set the timeout value manually. If that parameter was added, and documented in the release docs, the severity of these bugs could be downgraded (imho). Alternatively, or additionally, the scripts could check whether one of several problematic modules have been loaded when udevsettle returns and if so, sleep a couple of extra seconds (most other distros that take this approach seem to wait around 6 - 10 seconds). The problem is that the list of problematic modules is potentially huge (see list of buses above) Long-term solution: In the long term (post-Etch), I think something like the following might be a good solution: Take all scripts under /usr/share/initramfs-tools/scripts/local-top/ that setup block devices (i.e. cryptsetup, lvm, evms, etc), and split them in two, a udev rule snippet and a script. The udev rule snippet would list the devices that this particular script is interested in, and tell udev to call the script whenever such a device node is created. The script is basically the old script with minor changes so that it takes a device node as argument, and also so that it doesn't preserve any state between invocations. Then the main init script is changed to sleep until $ROOT (not /dev/root but whatever is set as the $ROOT variable) appears Advantages of the long-term approach: there will be no more sleeping than necessary everything will be asynchronous there will be no need to specify dependencies between the /usr/share/initramfs-tools/scripts/local-top/ scripts The last one might seem minor, but it actually makes the system much simpler. Right now it is not possible to support both crypto-on-lvm and lvm-on-crypto without duplicating the lvm functionality in the cryptsetup initramfs script (as you can tell initramfs to run lvm before or after cryptsetup, but not both). Example: Let's say we have the scripts lvm, cryptsetup and md in /usr/share/initramfs-tools/scripts/blockdev-scripts/ Each script has a udev rule snippet in /usr/share/initramfs-tools/scripts/blockdev-rules/ Most probably these rule snippets would be something like (this is probably not a valid udev rule, I can't check the syntax right now): KERNEL=[sh]d[a-z], PROGRAM=/usr/share/initramfs-tools/scripts/blockdev-rules/md Let's say that /dev/sda1 is detected. udev will then use its rules to execute /usr/share/initramfs-tools/scripts/blockdev-scripts/lvm which will check the device, realize it's no lvm pv and exit the same thing then happens for the cryptsetup script the md script recognizes /dev/sda1 as a raid partition, but it is missing an additional device, so no action is taken Later, /dev/sdb1 is detected. udev calls the lvm script again, which exits again the same thing then happends for the cryptsetup script the md script recognizes /dev/sdb1 as a raid partition, and /dev/sda1 is the other part of the raid device, so the device is setup and a new uevent is triggered in response, udev creates /dev/md1 and starts going through the scripts again udev calls the lvm script again, which exits again udev calls the cryptsetup script which recognizes /dev/md1 as a crypto device, prompts for the password and sets it up, this generates another uevent in response, udev creates /dev/mapper/cryptroot and starts going through the scripts again udev calls the lvm script again, which recognizes /dev/mapper/cryptroot as a lvm pv and sets up the vg and its lv's the lv's generate new uevents in response, udev creates (among others) /dev/mapper/mainvg-mainlv init notices this and boot continues Phew, this mail became much longer than expectedso whaddaya think Maks? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406465: [bind backend] TXT record parsing overflow with special characters
Update: upstream says it's not a serious security issue in his opinion. He intends to release a fix this weekend anyway. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410946: another idea
Why don't we simply drop a script into /etc/cron.hourly which sleeps for up to 60 minutes and then calls debsecan, using /etc/default/debsecan to determine the suite? That would solve the problems, no? -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#410946: debsecan: Overwrites local configuration
* Frank Küster: sed -i is also not available on sarge IIRC, but it's esay to work around that. Yes, is debsecan on backports.org? I don't think so. The sid version should run on sarge without a recompile.
Bug#411063: improper PAGE_SIZE usage in vvp/main.cc
PAGE_SIZE patch for Debian verilog 0.8-4.1, fixing bug#411063.
If for some reason the sysconf() call fails, I think 0 is
the best possible result: it is obviously incorrect.
Steve, the same change should also be applied to 0.9.
- Larry
--- /home/ldoolitt/deb-src/verilog-0.8/vvp/main.cc 2004-10-03
18:10:59.0 -0700
+++ vvp/main.cc 2007-02-16 08:52:18.0 -0800
@@ -66,15 +66,17 @@
{
FILE *statm;
unsigned siz, rss, shd;
+ long page_size = sysconf(_SC_PAGESIZE);
+ if (page_size==-1) page_size=0;
statm = fopen(/proc/self/statm, r);
if (!statm) {
perror(/proc/self/statm);
return;
}
if (3=fscanf(statm, %u%u%u, siz, rss, shd)) {
- a-ru_maxrss = PAGE_SIZE * siz;
- a-ru_idrss = PAGE_SIZE * rss;
- a-ru_ixrss = PAGE_SIZE * shd;
+ a-ru_maxrss = page_size * siz;
+ a-ru_idrss = page_size * rss;
+ a-ru_ixrss = page_size * shd;
}
fclose(statm);
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410850: marked as done (CVE-2006-6980: magnatune shell escapes)
Your message dated Fri, 16 Feb 2007 17:32:04 + with message-id [EMAIL PROTECTED] and subject line Bug#410850: fixed in amarok 1.4.4-3 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: amarock Version: 1.4.4-2 Severity: grave Tags: patch, security CVE-2006-6980 says[1]: The ruby handlers in Amarok do not properly quote text in certain contexts, probably including construction of an unzip command line, which allows attackers to execute arbitrary commands via shell metacharacters. There is an open KDE bug report[2], and SuSE has patched this problem. I'm working on extracting the patches now... [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6979 [2] http://bugs.kde.org/show_bug.cgi?id=138499 -- Kees Cook@outflux.net ---End Message--- ---BeginMessage--- Source: amarok Source-Version: 1.4.4-3 We believe that the bug you reported is fixed in the latest version of amarok, which is due to be installed in the Debian FTP archive: amarok-engines_1.4.4-3_i386.deb to pool/main/a/amarok/amarok-engines_1.4.4-3_i386.deb amarok-xine_1.4.4-3_i386.deb to pool/main/a/amarok/amarok-xine_1.4.4-3_i386.deb amarok_1.4.4-3.diff.gz to pool/main/a/amarok/amarok_1.4.4-3.diff.gz amarok_1.4.4-3.dsc to pool/main/a/amarok/amarok_1.4.4-3.dsc amarok_1.4.4-3_i386.deb to pool/main/a/amarok/amarok_1.4.4-3_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ana Beatriz Guerrero Lopez [EMAIL PROTECTED] (supplier of updated amarok package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 15 Feb 2007 22:28:13 +0100 Source: amarok Binary: amarok amarok-xine amarok-engines Architecture: source i386 Version: 1.4.4-3 Distribution: unstable Urgency: high Maintainer: Adeodato Simó [EMAIL PROTECTED] Changed-By: Ana Beatriz Guerrero Lopez [EMAIL PROTECTED] Description: amarok - versatile and easy to use audio player for KDE amarok-engines - output engines for the Amarok audio player amarok-xine - xine engine for the Amarok audio player Closes: 410850 Changes: amarok (1.4.4-3) unstable; urgency=high . * Edited patch magnatune.patch fixing CVE-2006-6980: amarok magnatune unsafe shell. (Closes: #410850). The reference to the ruby scripts pointed in the bug report, is a problem that was already solved in amarok 1.4.4. * Add dep on unzip (needed to uncompress albums). Files: a3d1fc8354e3ebc6edd025da61974eb4 1000 kde optional amarok_1.4.4-3.dsc 91044a6ec9fd98c338d97306f29b1839 41951 kde optional amarok_1.4.4-3.diff.gz 9c6d05341a17b95a086ecdc4bb9c1a17 17426768 kde optional amarok_1.4.4-3_i386.deb bd68121e29de9f2b970b99f9ce31a1e0 69846 kde optional amarok-engines_1.4.4-3_i386.deb b96a3633f7ffc87749607090687644db 122418 kde optional amarok-xine_1.4.4-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Signed by Ana Guerrero iD8DBQFF1d+an3j4POjENGERAgtIAJ0U92ru/nNsF5oOiSFEQrED7LAJiACfVfnJ svLgVRKlWudc6+/lsV3oXhc= =tBev -END PGP SIGNATURE- ---End Message---
Bug#410946: intent to fix #410946
Frank Küster [EMAIL PROTECTED] wrote: The problems with ucf are: The most important reason, IMHO, was the one I forgot: You either loose a main assets of debconf, or you ask twice. Consider that in a new version of the package, a default answer to the debconf question changes, and people who upgrade should have a chance to know about this. If you parse the configuration file, anyway, you can then determine if it has the former, old default, and set the debconf question to unseen (or even display an additional note in advance). Subsequently, the postinst writes the answer into the file. If you do the same with ucf, the user will be asked by debconf, and a second time by ucf. If you use just ucf, and do not set the debconf question to unseen, the user only has the file and the comments in it, but not the (translatable) debconf questions. The double asking will also be triggered with dpkg-reconfigure. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#411170: SATA failures with amd64 version of Etch
Package: kernel
Severity: critical
Multiple attempts to install Etch fail. The syslog file is filled with
failure messages along these lines:
Feb 16 01:09:27 debootstrap: Unpacking replacement base-files ...
Feb 16 01:09:57 kernel: ata1: command 0xca timeout, stat 0x50 host_stat 0x24
Feb 16 01:09:57 kernel: ata1: status=0x50 { DriveReady SeekComplete }
Feb 16 01:09:57 kernel: sda: Current: sense key: No Sense
Feb 16 01:09:57 kernel: Additional sense: No additional sense
information
Feb 16 01:09:57 kernel: Info fld=0x0
Feb 16 01:09:57 kernel: ata2: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:09:57 kernel: ata2: status=0x50 { DriveReady SeekComplete }
Feb 16 01:09:57 kernel: sdb: Current: sense key: No Sense
Feb 16 01:09:57 kernel: Additional sense: No additional sense
information
Feb 16 01:10:27 kernel: ata1: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:10:27 kernel: ata1: status=0x50 { DriveReady SeekComplete }
Feb 16 01:10:27 kernel: sda: Current: sense key: No Sense
Feb 16 01:10:27 kernel: Additional sense: No additional sense
information
Feb 16 01:10:27 kernel: ata2: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:10:27 kernel: ata2: status=0x50 { DriveReady SeekComplete }
Feb 16 01:10:27 kernel: sdb: Current: sense key: No Sense
Feb 16 01:10:27 kernel: Additional sense: No additional sense
information
I have saved as much of syslog as was flushed right before giving up (at
the rate it was going it would have taken days to finish -- if ever --
what completed successfully in under a half hour using the i386 version)
on the last attempt (I also have the complete partman log), and will be
happy to post them (or make them available via HTTP) if you believe they
will be of any use.
I have run hardware diagnostic tests on the drives and on the memory,
and everything is reported as healthy. I did the same installation
successfully using the i386 version of Etch. For the successful
installation only two changes were made:
1. I left the results of partitioning the hardware disks from the
last pass with the amd64 installer, and picked up with doing
the RAID configuration as before; and
2. i selected a different ethernet device.
Debian versions:
Debian GNU/Linux testing Etch - Official Snapshot amd64 Binary-1
(20061110) [failed]
Debian GNU/Linux testing Etch - Official Snapshot i386 Binary-1
20070215-23:10 [succeeded]
Hardware:
ASUS A8N-VN motherboard
AMD Athlon(tm) 64 Processor 3800+ (single processor)
2GB dual-channel PC3200 DDR 400
2 x ATA WDC WD2500JS-60N Rev: 10.0 disks
[configured using Linux software RAID level 1; the RAID support on the
motherboard is disabled]
I'll be glad to supply any other information that will help track down
the cause for the failure.
--
Bob Kline
http://www.rksystems.com
mailto:[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411171: gnome-user-share: Missing mime module in dav_user_2.2.conf
Package: gnome-user-share Version: 0.10-3 Severity: grave Justification: renders package unusable As the mime module is not loaded, the TypesConfig directive cannot be used. Adding the following LoadModule directive fixes the problem : LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so Cheers, Romain. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages gnome-user-share depends on: ii apache2 2.2.3-3.3Next generation, scalable, extenda ii apache2-mpm-worker [apache2 2.2.3-3.3High speed threaded model for Apac ii avahi-daemon0.6.16-2 Avahi mDNS/DNS-SD daemon ii gconf2 2.16.0-3 GNOME configuration database syste ii libavahi-client30.6.16-2 Avahi client library ii libavahi-common30.6.16-2 Avahi common library ii libavahi-glib1 0.6.16-2 Avahi glib integration library ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries ii libgconf2-4 2.16.0-3 GNOME configuration database syste ii libglade2-0 1:2.6.0-4library to load .glade files at ru ii libglib2.0-02.12.6-2 The GLib library of C routines ii libgtk2.0-0 2.8.20-5 The GTK+ graphical user interface ii liborbit2 1:2.14.4-1 libraries for ORBit2 - a CORBA ORB ii libselinux1 1.32-3 SELinux shared libraries ii libx11-62:1.0.3-5X11 client-side library gnome-user-share recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411172: dmraid is looking for the raid45 kernel module and not the raid456 modules.
Package: dmraid Version: 1.0.0.rc13-2 Severity: grave Justification: renders package unusable I am trying to use dmraid with a NVIDIA NForce software RAID. I can see the raid metadata correctly, but when I try to activate (dmraid -ay) I get this error: ERROR: device-mapper target type raid45 not in kernel Here is the applicable parts of lsmod raid456 122912 0 md_mod 82844 1 raid456 xor10384 1 raid456 -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages dmraid depends on: ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries ii libdevmapper1.022:1.02.12-1 The Linux Kernel Device Mapper use ii libselinux1 1.32-3 SELinux shared libraries ii libsepol1 1.14-2 Security Enhanced Linux policy lib ii lsb-base3.1-23 Linux Standard Base 3.1 init scrip dmraid recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406465: more details needed please (zone data)
Jeroen (and Bas I assume), Can you provide me with a copy of your problematic a-eskwadraat zone? Thanks -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 411170 to linux-2.6
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.27 reassign 411170 linux-2.6 Bug#411170: SATA failures with amd64 version of Etch Bug reassigned from package `kernel' to `linux-2.6'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411170: SATA failures with amd64 version of Etch
On Fri, Feb 16, 2007 at 02:29:36PM -0500, Bob Kline wrote: I have saved as much of syslog as was flushed right before giving up (at the rate it was going it would have taken days to finish -- if ever -- what completed successfully in under a half hour using the i386 version) on the last attempt (I also have the complete partman log), and will be happy to post them (or make them available via HTTP) if you believe they will be of any use. I have run hardware diagnostic tests on the drives and on the memory, and everything is reported as healthy. I did the same installation successfully using the i386 version of Etch. For the successful installation only two changes were made: 1. I left the results of partitioning the hardware disks from the last pass with the amd64 installer, and picked up with doing the RAID configuration as before; and 2. i selected a different ethernet device. Debian versions: Debian GNU/Linux testing Etch - Official Snapshot amd64 Binary-1 (20061110) [failed] Debian GNU/Linux testing Etch - Official Snapshot i386 Binary-1 20070215-23:10 [succeeded] hey Bob, Its very likely that the success of the i386 install wasn't due to the architecture, but rather to a newer kernel used (kernel has changed significantly between 20061110 and 20070215). Please try the 20070215 amd64 installer. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411172: [Utnubu-maintainers] Bug#411172: dmraid is looking for the raid45 kernel module and not the raid456 modules.
On Fri, Feb 16, 2007, Paul Logasa Bogen II wrote: I am trying to use dmraid with a NVIDIA NForce software RAID. I can see the raid metadata correctly, but when I try to activate (dmraid -ay) Do you know with which kernel version it worked for you in the past? -- Loïc Minier [EMAIL PROTECTED]
Bug#408325: sfsauthd: fatal: Should not be reached - server fails on arm nslu2
Hello, I got access to an ARM box, and was unable to reproduce this problem. Linux debian 2.6.18-4-iop32x #1 Sat Feb 3 12:15:12 UTC 2007 armv5tel GNU/Linux The machine was running couple months old sid, and it was upgraded to this day, but in either case, everything works just fine. The only difference in package versions that I can see is libc6, 2.3.6.ds1-10 vs. 2.3.6.ds1-11. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400718: You're right.
You're right. It is tagged as sarge. I hadn't noticed that. For some reason, though, that tag had not propogated to the list of release critical bugs: http://bugs.debian.org/release-critical/all.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411170: SATA failures with amd64 version of Etch
dann frazier wrote: hey Bob, Its very likely that the success of the i386 install wasn't due to the architecture, but rather to a newer kernel used (kernel has changed significantly between 20061110 and 20070215). Please try the 20070215 amd64 installer. Thanks, Dann. I'll give it a try. I was trying (but I guess didn't succeed very well) to pull down the frozen release candidate of Etch when I downloaded the 20061110 images. (I've been planning a switch from RedHat to Debian for my main server, and was trying to time it with the release of Debian 4.0. I figured I'd do my part by testing it before the release to see if I could catch any bugs before it went out the door. Can you tell me which version is the release candidate for 4.0?) I'll report back the results with the newer kernel. -- Bob Kline http://www.rksystems.com mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411172: [Loïc Minier [EMAIL PROTECTED]] Seems to use raid45 targets instead of raid456
I've sent a ping to the development list. -- Loïc Minier [EMAIL PROTECTED] ---BeginMessage--- Hi, It seems the ascii_type[] table maps some RAID usage to the raid45 device mapper target, but I think the raid[45] modules were dropped in 2.6.18 in favor of raid456. This was reported as preventing any use of dmraid by Paul Logasa Bogen II in Debian bug http://bugs.debian.org/411172; he is using 2.6.18. Bye, -- Loïc Minier [EMAIL PROTECTED] ---End Message---
Bug#411170: SATA failures with amd64 version of Etch
On Fri, Feb 16, 2007 at 03:33:58PM -0500, Bob Kline wrote: dann frazier wrote: hey Bob, Its very likely that the success of the i386 install wasn't due to the architecture, but rather to a newer kernel used (kernel has changed significantly between 20061110 and 20070215). Please try the 20070215 amd64 installer. Thanks, Dann. I'll give it a try. I was trying (but I guess didn't succeed very well) to pull down the frozen release candidate of Etch when I downloaded the 20061110 images. (I've been planning a switch from RedHat to Debian for my main server, and was trying to time it with the release of Debian 4.0. I figured I'd do my part by testing it before the release to see if I could catch any bugs before it went out the door. Can you tell me which version is the release candidate for 4.0?) I'll report back the results with the newer kernel. Your best bet is one of these images: http://www.debian.org/devel/debian-installer/ RC1 is no longer usable (see the News section) - RC2 should be available Real Soon Now. I'm going to go ahead and close this bug as I'm fairly certain it has been fixed, but don't hestitate to reopen if you run into it again w/ the latest build. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411170: marked as done (SATA failures with amd64 version of Etch)
Your message dated Fri, 16 Feb 2007 13:43:43 -0700
with message-id [EMAIL PROTECTED]
and subject line Bug#411170: SATA failures with amd64 version of Etch
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: kernel
Severity: critical
Multiple attempts to install Etch fail. The syslog file is filled with
failure messages along these lines:
Feb 16 01:09:27 debootstrap: Unpacking replacement base-files ...
Feb 16 01:09:57 kernel: ata1: command 0xca timeout, stat 0x50 host_stat 0x24
Feb 16 01:09:57 kernel: ata1: status=0x50 { DriveReady SeekComplete }
Feb 16 01:09:57 kernel: sda: Current: sense key: No Sense
Feb 16 01:09:57 kernel: Additional sense: No additional sense
information
Feb 16 01:09:57 kernel: Info fld=0x0
Feb 16 01:09:57 kernel: ata2: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:09:57 kernel: ata2: status=0x50 { DriveReady SeekComplete }
Feb 16 01:09:57 kernel: sdb: Current: sense key: No Sense
Feb 16 01:09:57 kernel: Additional sense: No additional sense
information
Feb 16 01:10:27 kernel: ata1: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:10:27 kernel: ata1: status=0x50 { DriveReady SeekComplete }
Feb 16 01:10:27 kernel: sda: Current: sense key: No Sense
Feb 16 01:10:27 kernel: Additional sense: No additional sense
information
Feb 16 01:10:27 kernel: ata2: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:10:27 kernel: ata2: status=0x50 { DriveReady SeekComplete }
Feb 16 01:10:27 kernel: sdb: Current: sense key: No Sense
Feb 16 01:10:27 kernel: Additional sense: No additional sense
information
I have saved as much of syslog as was flushed right before giving up (at
the rate it was going it would have taken days to finish -- if ever --
what completed successfully in under a half hour using the i386 version)
on the last attempt (I also have the complete partman log), and will be
happy to post them (or make them available via HTTP) if you believe they
will be of any use.
I have run hardware diagnostic tests on the drives and on the memory,
and everything is reported as healthy. I did the same installation
successfully using the i386 version of Etch. For the successful
installation only two changes were made:
1. I left the results of partitioning the hardware disks from the
last pass with the amd64 installer, and picked up with doing
the RAID configuration as before; and
2. i selected a different ethernet device.
Debian versions:
Debian GNU/Linux testing Etch - Official Snapshot amd64 Binary-1
(20061110) [failed]
Debian GNU/Linux testing Etch - Official Snapshot i386 Binary-1
20070215-23:10 [succeeded]
Hardware:
ASUS A8N-VN motherboard
AMD Athlon(tm) 64 Processor 3800+ (single processor)
2GB dual-channel PC3200 DDR 400
2 x ATA WDC WD2500JS-60N Rev: 10.0 disks
[configured using Linux software RAID level 1; the RAID support on the
motherboard is disabled]
I'll be glad to supply any other information that will help track down
the cause for the failure.
--
Bob Kline
http://www.rksystems.com
mailto:[EMAIL PROTECTED]
---End Message---
---BeginMessage---
On Fri, Feb 16, 2007 at 03:33:58PM -0500, Bob Kline wrote:
dann frazier wrote:
hey Bob,
Its very likely that the success of the i386 install wasn't due to
the architecture, but rather to a newer kernel used (kernel has changed
significantly between 20061110 and 20070215). Please try the 20070215
amd64 installer.
Thanks, Dann. I'll give it a try. I was trying (but I guess didn't succeed
very well) to pull
down the frozen release candidate of Etch when I downloaded the 20061110
images. (I've been
planning a switch from RedHat to Debian for my main server, and was trying to
time it with the
release of Debian 4.0. I figured I'd do my part by testing it before the
release to see if I
could catch any bugs before it went out the door. Can you tell me which
version is the release
candidate for 4.0?)
I'll report back the results with the newer kernel.
Your best bet is one of these images:
http://www.debian.org/devel/debian-installer/
RC1 is no longer usable (see the News section) - RC2 should be
available Real Soon Now.
I'm going to go ahead and close this bug as I'm fairly certain it has
been fixed, but don't hestitate to reopen if you run into it again w/
the latest build.
--
dann frazier
---End Message---
Bug#388616: Upgrade
[cc shortened] Romain Beauxis [EMAIL PROTECTED] wrote: Le jeudi 8 février 2007 22:17, Steve Langasek a écrit : I think the bug #388616 should be granted this etc-ignore. The configuration file is never shiped with the package nor generated by the software. It is generated in config/ directory, and happen normaly only at first install. My question here is, if the software looks for the config in /var/lib out of necessity, No, it doesn't. why does the package ship a symlink under /etc/ when that symlink a) will overwrite any attempts by the user to turn this into a real file (for whatever reason), and b) will complicate upgrades in the future when mediawiki's FHS bug is fixed so that the conffile *can* be moved to /etc? Yes we could just remove the link and add a file like README.mediawiki or any other name in which we just explain where the user can find the confile... Indeed, that would propably be enought to close the two other bug for a small amount of change this time. Alternatively, you could just as well fix it. I have never used mediawiki before, but I gave it a try. It works very well with a symlink in the other direction and LocalSettings.php in /etc/mediawiki1.7/, conforming with policy. The only change that needs to be made is that $IP must be set to /var/lib/mediawiki1.7 in /etc/mediawiki1.7/LocalSettings.php For packaging the following changes need to be made: - mediawiki.1.7.links changed - the instructions in config/index.php and README.Debian must be changed to reflect the new location, - the same needs to be done with AdminSettings.php (and it's handling in postinst and config must be rewritten). All nothing that requires magic. I just didn't write a complete patch because I am not sure of the purpose of the upgrade code in config/postinst. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#411172: [Utnubu-maintainers] Bug#411172: dmraid is looking for the raid45 kernel module and not the raid456 modules.
Loïc Minier wrote: On Fri, Feb 16, 2007, Paul Logasa Bogen II wrote: I am trying to use dmraid with a NVIDIA NForce software RAID. I can see the raid metadata correctly, but when I try to activate (dmraid -ay) Do you know with which kernel version it worked for you in the past? never tried it before plb
Processed: Re: [Utnubu-maintainers] Bug#411172: dmraid is looking for the raid45 kernel module and not the raid456 modules.
Processing commands for [EMAIL PROTECTED]: severity 411172 important Bug#411172: dmraid is looking for the raid45 kernel module and not the raid456 modules. Severity set to `important' from `grave' stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411172: [Utnubu-maintainers] Bug#411172: dmraid is looking for the raid45 kernel module and not the raid456 modules.
severity 411172 important stop On Fri, Feb 16, 2007, Paul Logasa Bogen II wrote: Do you know with which kernel version it worked for you in the past? never tried it before Ok, then I'm downgrading the bug to important as it is not a regression. -- Loïc Minier [EMAIL PROTECTED]
Bug#392016: Further security patching of ELOG
Hi, the vulnerabilities on secunia.com have been fixed long time ago (see their recommendation to upgrade). The patch you supplied is actually not enough to prohibit users from entering script code. I fixed following additional cases: - Enter a user name, full name or email address conaining JavaScript - Doing a search by entering JavaScript in an attribute search field - Entering JavaScript in a quick filter text box. The fixes are contained in SVN revision 1792. Regards, Stefan Ritt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408325: sfsauthd: fatal: Should not be reached - server fails on arm nslu2
On Fri, Feb 16, 2007 at 10:26:15PM +0200, Jaakko Niemi wrote: I got access to an ARM box, and was unable to reproduce this problem. Linux debian 2.6.18-4-iop32x #1 Sat Feb 3 12:15:12 UTC 2007 armv5tel GNU/Linux The machine was running couple months old sid, and it was upgraded to this day, but in either case, everything works just fine. The only difference in package versions that I can see is libc6, 2.3.6.ds1-10 vs. 2.3.6.ds1-11. I guess the other differences are the iop32x kernel vs. the ixp4xx kernel, and the corresponding difference in hardware. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408325: sfsauthd: fatal: Should not be reached - server fails on arm nslu2
* Steve Langasek [EMAIL PROTECTED] [2007-02-16 14:37]: I guess the other differences are the iop32x kernel vs. the ixp4xx kernel, and the corresponding difference in hardware. The iop32x board is much faster which might make a difference if this is in any way related to #406552. Unfortunately, I won't have time to look at this bug in the near future. I don't know if this bug can be downgraded to important. If not, I suggest you remove the arm binary for now. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411192: CVE-2007-0981: serious cookie-stealing vulnerability
Package: iceweasel Version: 2.0.0.1+dfsg-2 Severity: grave Tags: security, fixed-upstream, patch http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0981 says: Mozilla based browsers allows remote attackers to bypass the same origin policy, steal cookies, and conduct other attacks by writing a URI with a null byte to the hostname (location.hostname) DOM property, due to interactions with DNS resolver code. Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=370445 Upstream patch: https://bugzilla.mozilla.org/attachment.cgi?id=255252 -- Kees Cook@outflux.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#410695: zope2.7 causqe upgrade failure
Processing commands for [EMAIL PROTECTED]: reassign 410695 apt Bug#410695: zope2.7 causqe upgrade failure Bug reassigned from package `upgrade-reports' to `apt'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410695: zope2.7 causqe upgrade failure
reassign 410695 apt thanks On Wed, Feb 14, 2007 at 12:06:09AM +0100, Bill Allombert wrote: On Mon, Feb 12, 2007 at 05:42:31PM -0800, Steve Langasek wrote: On Mon, Feb 12, 2007 at 06:53:53PM +0100, Bill Allombert wrote: Package: upgrade-reports Severity: serious The piuparts run below: /usr/sbin/piuparts -a -d sarge -d etch gnupg xawtv k3d-dev libcnumx0-dev mozilla-opensc xmms-coverviewer makeself koffice-i18n-nn kview libmcardplugin gij-3.4 gimp-dimage-color libast2-dev libaal-dev caudium-dev libcvsservice0 tex-guy linuxdoc-tools-latex snort-common multipath-tools isic libpam-pwdfile libotr1-dev libglib2-ruby haskelldb-bin cyrus21-imapd bsign scalapack-lam-test pyching freeswan dict-freedict-spa-eng xfaces libtie-cache-perl zope2.7-mimetypesregistry libdmsocket-0.32.5-0-dev attal-themes-medieval kde-i18n-srlatin dircproxy pica glimmer kappfinder kde-i18n-eu 9menu selflinux-pdf libgtksourceview-doc Is there a smaller minimal set of packages that can be used to reproduce the problem? Try this one: k3d-dev kview libaal-dev caudium-dev libcvsservice0 snort-common libpam-pwdfile cyrus21-imapd zope2.7-mimetypesregistry Hmm, a minimal test case that's impressive for its complexity. :) Here is another further reduction that still triggers the bug for me: k3d-dev kview kde-i18n-af zope2.7-mimetypesregistry In both cases the failure is reproducible with apt-get, and is not reproducible with aptitude (using apt-get to install the packages so none of them are marked as auto-installed, but aptitude for the dist-upgrade). I can't say whether this is because aptitude is better, or just luck of the draw. Comments on the upgrade solution arrived at for apt for this particular upgrade: k3d-dev and k3d are both upgraded, pulling in new versions of boost. If only k3d is installed, apt removes k3d and zope2.7 is removed successfully. kview and kde-i18n-af are both removed, along with kdelibs-bin and kdelibs4; if either kview or kde-i18n-af is not installed, kdelibs is still removed but zope2.7 is removed successfully. libqt3c102-mt is left untouched on the system, because nothing is pulled in that conflicts with it. This looks like an apt bug to me (and isn't the first time I've seen it). Any pointer ? Not specifically, sorry. It was a user who reported a similar bug against php, where again apt-get removed a dependency before the package depending on it under circumstances where this didn't appear to be necessary (and certainly wasn't appropriate). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411198: gquilt: doesn't start due to dependency problem
Package: gquilt Version: 0.17-2 Severity: serious Justification: renders package unusable Hello, I have recently updated python 2.4 and from this time, gquilt refused working with an error message immediately after I run it: RuntimeError: Bad magic number in .pyc file Probably there is some problem with the dependencies? I have only python 2.3 and 2.4 installed Regards Jiri Palecek -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17.3 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-2) (ignored: LC_ALL set to cs_CZ) Versions of packages gquilt depends on: ii python-central0.5.12 register and build utility for Pyt ii python-gtk2 2.8.6-8Python bindings for the GTK+ widge ii quilt 0.45-6 Tool to work with series of patche Versions of packages gquilt recommends: ii meld 1.1.3-1.2 graphical tool to diff and merge f -- no debconf information -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Bug#410204: linux-image-2.6.18-4-amd64: Data corruption on dm-crypt+XFS
Hi Sami, I'm told that dmcrypt+XFS has never worked in the upstream kernel or in Debian, so this is essentially an unsupported configuration. But you've filed this bug as critical with the justification that it causes serious data loss. Did you lose data as a result of this bug? Could you explain the process by which that happened? It's my impression that this combination is so unreliable that it will oops before you really have a chance to try to use it for storing data, so you can't really lose any data if you can't put it there in the first place. Based on the status as a known-buggy and unsupported config I think this bug should be downgraded to non-RC status for etch, but I'd like to be sure first that I understand the impact of any real-world risk of data loss. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408325: sfsauthd: fatal: Should not be reached - server fails on arm nslu2
I would say if the server binary has ever worked on any arm machine, then keep it. I did manage to start investigating this. I recompiled the package with some extra trace (very slowly, using qemu) and got some additional information. Unfortunately, I haven't had time to continue and follow it up further. Still, what I did was establish that the case that is occuring is the explicit setting of pwd to NULL in authclnt::login_unixpw. So aap-pwauth-password is presumably coming in as an empty string, and of course I was trying to sfs_register as root. That is supposed to work still, isn't it? I have a [EMAIL PROTECTED] usable sfs login on my server, but I set it up some time ago So I thought I would try registering as a non-root user, and in that case sfs_authd didn't crash, and indeed I got prompted for a unix password, which I didn't get as root. But also, as far as I could tell, I still couldn't sfs login to the machine. But that needed more checking (I'm not quite sure about host naming/resolving requirements), and I haven't got back to the problem since... If anyone is familiar enough with the code to tell what its supposed to be doing? It looks pretty odd to me, and it would be nice to know if that password is supposed to ever be empty, or whatever. -- [EMAIL PROTECTED]
Bug#411170: SATA failures with amd64 version of Etch
Bob Kline wrote: Thanks, Dann. I'll give it a try. I'll report back the results with the newer kernel. Works perfectly. Sorry for the confusion about the kernel versions. Guess I was confused about what frozen meant. (Good thing it didn't mean what I thought it meant, or I'd have been stuck with broken support for amd64 in Etch.) Thanks again! -- Bob Kline http://www.rksystems.com mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410731: python-twisted-runner should not provide modules for 2.3
tag 410731 patch thanks Given that python-twisted-runner depends: python-twisted-core (= 2.4) python twisted-core depends: python-twisted-bin (= 2.4.0-3) python-twisted-bin depends: python (= 2.4) It appears that python-twisted-runner won't actually work on python 2.3. Thus, providing modules for 2.3 is pointless. Setting Python-Version: 2.4 instead of Python-Version: 2.4, 2.3 should be enough to solve this bug, without the extra cruft that adding a Replaces: python2.3-twisted-bin would be. The included patch does that. I have tested it by installing python-twisted in a sarge chroot then upgrading the chroot to current etch. --- diff -u twisted-runner-0.2.0/debian/changelog twisted-runner-0.2.0/debian/changelog --- twisted-runner-0.2.0/debian/changelog +++ twisted-runner-0.2.0/debian/changelog @@ -1,3 +1,9 @@ +twisted-runner (0.2.0-1.1) unstable; urgency=low + + * NMU. Set XS-Python-Version to (= 2.4) (closes #410731). + + -- Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Fri, 16 Feb 2007 19:32:39 -0600 + twisted-runner (0.2.0-1) unstable; urgency=low * New upstream version. diff -u twisted-runner-0.2.0/debian/control twisted-runner-0.2.0/debian/control --- twisted-runner-0.2.0/debian/control +++ twisted-runner-0.2.0/debian/control @@ -3,7 +3,7 @@ Priority: optional Maintainer: Matthias Klose [EMAIL PROTECTED] Build-Depends: debhelper (= 5.0.37.1), python-central (= 0.4.17), python-all-dev, python-twisted-core (= 2.4), patch -XS-Python-Version: all +XS-Python-Version: (= 2.4) Standards-Version: 3.7.2 Package: python-twisted-runner --- -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Processed: python-twisted-runner should not provide modules for 2.3
Processing commands for [EMAIL PROTECTED]: tag 410731 patch Bug#410731: python-twisted-runner: file conflict with python2.3-twisted-bin There were no tags set. Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 380825
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 380825 patch Bug#380825: Python transition (#2): you are building a private python module ! There were no tags set. Tags added: patch End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391937: An upload of gnue-common would fix these bugs
tag 391937 patch tag 391941 patch tag 391942 patch tag 391947 patch tag 391950 patch thanks I've manually tested building these packages after installing in a chroot the proposed NMU by Adam Cécile available in #380825 with excelent results. Thus, making that upload would also take care of these bugs. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Processed: An upload of gnue-common would fix these bugs
Processing commands for [EMAIL PROTECTED]: tag 391937 patch Bug#391937: FTBFS: You need GNUe-Common 0.5.2 or newer installed to install GNUe-AppServer There were no tags set. Tags added: patch tag 391941 patch Bug#391941: FTBFS: You need GNUe-Common 0.5.2 or newer installed to install GNUe-Designer There were no tags set. Tags added: patch tag 391942 patch Bug#391942: FTBFS: You need GNUe-Common 0.5.2 or newer installed to install GNUe-Forms There were no tags set. Tags added: patch tag 391947 patch Bug#391947: FTBFS: You need GNUe-Common 0.5.2 or newer installed to install GNUe-Navigator There were no tags set. Tags added: patch tag 391950 patch Bug#391950: FTBFS: You need GNUe-Common 0.5.2 or newer installed to install GNUe-Reports There were no tags set. Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411198: gquilt: doesn't start due to dependency problem
Jiří Paleček wrote: Package: gquilt Version: 0.17-2 Severity: serious Justification: renders package unusable Hello, I have recently updated python 2.4 and from this time, gquilt refused working with an error message immediately after I run it: RuntimeError: Bad magic number in .pyc file Probably there is some problem with the dependencies? I have only python 2.3 and 2.4 installed A quick fix would be just delete the pyc files. The only downside to that should be a slight slowdown in start up time due to the absence of the byte compiled code. But I would recommend upgrading to a later version of gquilt (notably v-0.19). I don't know whether this is available as a Debian package yet as that is/was done by someone else but the source is available at http://downloads.sourceforge.net/gquilt/gquilt-0.19.tar.gz?use_mirror=optusnet. Regards Jiri Palecek -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17.3 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-2) (ignored: LC_ALL set to cs_CZ) Versions of packages gquilt depends on: ii python-central0.5.12 register and build utility for Pyt ii python-gtk2 2.8.6-8Python bindings for the GTK+ widge ii quilt 0.45-6 Tool to work with series of patche Versions of packages gquilt recommends: ii meld 1.1.3-1.2 graphical tool to diff and merge f -- no debconf information --Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Peter -- Peter Williams [EMAIL PROTECTED] Learning, n. The kind of ignorance distinguishing the studious. -- Ambrose Bierce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411198: gquilt: doesn't start due to dependency problem
On Sat, Feb 17, 2007 at 01:42:07PM +1000, Peter Williams wrote: Jiří Paleček wrote: Package: gquilt Version: 0.17-2 Severity: serious Justification: renders package unusable Hello, I have recently updated python 2.4 and from this time, gquilt refused working with an error message immediately after I run it: RuntimeError: Bad magic number in .pyc file Probably there is some problem with the dependencies? I have only python 2.3 and 2.4 installed A quick fix would be just delete the pyc files. The only downside to that should be a slight slowdown in start up time due to the absence of the byte compiled code. But I would recommend upgrading to a later version of gquilt (notably v-0.19). I don't know whether this is available as a Debian package yet as that is/was done by someone else but the source is available at http://downloads.sourceforge.net/gquilt/gquilt-0.19.tar.gz?use_mirror=optusnet. Regards Jiri Palecek I'm uploading a fix for this problem as fast as my sponsor gets to it. I was unaware that upstream had moved to Sourceforge, but now that I know that I'll package the new upstream version as soon as the release critical bug is fixed in etch. Peter--feel free to ignore any bugs that are specifically related to Debian packaging issues. I'll get them. Regards, Christine
Bug#411078: license.terms for utils/base64/base64.tcl not included
On Thu, Feb 15, 2007 at 03:19:42PM -0500, Filipus Klutiero wrote: utils/base64/base64.tcl's copyright notice contains # See the file license.terms for information on usage and # redistribution # of this file, and for a DISCLAIMER OF ALL WARRANTIES. This license.terms file is not included in amsn. It appears to be the one at http://tclhttpd.cvs.sourceforge.net/tclhttpd/tclhttpd/license.terms?revision=1.4view=markup which contains The authors hereby grant permission to use, copy, modify, distribute, and license this software and its documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. As the right to modify is not granted to amsn, this shouldn't be distributed in main, but also of course distributing it violates copyright as there's no permission granted to distribute. Er, what? the authors hereby grant permission to use, copy, modify, distribute, and license doesn't grant to amsn the right to modify? Yes, there is a missing license statement, and that is a serious bug. But I don't understand the claim that the file shouldn't be distributed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410948: license issues with des.tcl
On Fri, Feb 16, 2007 at 04:05:17AM -0500, Filipus Klutiero wrote: But in any case, the following sentence is what matters: Notwithstanding the foregoing, the authors grant the U.S. Government and others acting in its behalf permission to use and distribute the software in accordance with the terms specified in this license. IOW, in *spite* of citing this government regulation, permission is granted to use and distribute the software *under the normal license*. This is also what I read. Do you agree that given the content of this government regulation, the license is/looks conflicting? No; the notwithstanding clause supersedes the foregoing. Again, this is an effort to keep the government from claiming *more* rights over the software than what's permitted by the usual license, not to prevent the government from exercising rights that are granted to everyone else. To make it clear, I believed you when you first stated this. But re-reading the license, it's still not how I interpret what's written. Well, there's room for greater clarity here; there usually is with license texts. If you feel strongly about this wording needing to be improved, you can reopen the bug at a lower severity, but I wouldn't give you very good odds of getting the license changed given that citing government regs in your license is usually a good indication of an institutional mentality that loves boilerplate. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411078: license.terms for utils/base64/base64.tcl not included
Steve Langasek a écrit : On Thu, Feb 15, 2007 at 03:19:42PM -0500, Filipus Klutiero wrote: utils/base64/base64.tcl's copyright notice contains # See the file license.terms for information on usage and # redistribution # of this file, and for a DISCLAIMER OF ALL WARRANTIES. This license.terms file is not included in amsn. It appears to be the one at http://tclhttpd.cvs.sourceforge.net/tclhttpd/tclhttpd/license.terms?revision=1.4view=markup which contains The authors hereby grant permission to use, copy, modify, distribute, and license this software and its documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. As the right to modify is not granted to amsn, this shouldn't be distributed in main, but also of course distributing it violates copyright as there's no permission granted to distribute. Er, what? the authors hereby grant permission to use, copy, modify, distribute, and license doesn't grant to amsn the right to modify? Oh, sorry. this - amsn in its current state. I just meant that developers of amsn don't have the right to modify the file as long as license.terms isn't included. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
