Bug#391824: Fixed patch URL
The original patch URL is now dead, but it can be retrieved there: https://dev.openwrt.org/browser/packages/net/ez-ipupdate/patches/ez-ipupdate-everydns.patch?rev=4986 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509001: /etc/init.d/mldonkey-server: useless line
Package: mldonkey-server Version: 2.9.5-2 Severity: minor In /etc/init.d/mldonkey-server, the line: test -x $WRAPPER || exit 0 does not do anything, since $WRAPPER is not defined. This is cruft left behind from previous versions. No big deal, but it's confusing at first, it would only help clarity and maintenance to remove it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#506655: Strange things on QA page
Hi, On Sat, Nov 29, 2008 at 11:53 AM, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > On Sun, Nov 23, 2008 at 01:02:48PM +0100, Daniel Bonniot wrote: >> I see two strange things on this page: >> http://packages.qa.debian.org/m/mysql-dfsg-5.0.html > > Thanks for this bug report! > >> 1. it lists 5.0.32-7etch6 as the current stable and stable-security >> version, while it has been -etch8 for more than 20 days > > This was the bug part related to the PTS, due to a naming convention > mismatch, for a while security updates were not properly rendered into > QA pages (the info were there and up to date, but they were looked for > in the wrong places, which happen to contain the old out of date > information). > > This should be fixed now. Thanks a lot. Indeed the version numbers are now correct. To be picky, the link behind 5.0.32-7etch6 actually leads to a page describing -etch8. While 5.0.32-7etch8 has no link. That seems illogical. For the two testing versions, again the non-updated version is a link, this time linking to that very same version. Ideally all 4 (5 with sid) versions should link to the page describing that very version. Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#506655: Strange things on QA page
Package: qa.debian.org Hi, I see two strange things on this page: http://packages.qa.debian.org/m/mysql-dfsg-5.0.html 1. it lists 5.0.32-7etch6 as the current stable and stable-security version, while it has been -etch8 for more than 20 days 2. in the latest news section, etch8 does not appear. etch6 appears twice at different dates, same for etch5. and on http://packages.debian.org/source/stable/mysql-dfsg-5.0 There it is rightly etch8, but the link to the changelog is dead: http://packages.debian.org/changelogs/pool/main/m/mysql-dfsg-5.0/mysql-dfsg-5.0_5.0.32-7etch8/changelog I guess this is an infrastructure problem, but I CC the mysql maintainers for their information and in case they have specific information. Thanks a lot to all of you to look at it, and for your amazing work in general! Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454198: nice-mode.el: please restore compatibility with Emacs 21
Just for information, the NOERROR parameter of require does not work with XEmacs 21. I'm planning to use instead: (condition-case nil (require 'cc-fonts) (error nil)) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409462: munin-node: munin should not wake up hard drives
This patch would be very nice to include. One thing to pay attention to is that the "-n standby" parameter for smartctl is only available since smartmontools 5.37 (etch has 5.36). So I think the debian package could include this patch and add versioned Conflicts and Suggests for smartmontools. Regarding upstream, there is a related task: http://munin.projects.linpro.no/ticket/137 I had reopened it and submitted a patch before I saw this debian bug report. My patch uses hdparm -C, which is less elegant, but it will work with older versions of smartmontools, so maybe it is more appropriate for upstream at the moment. Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454198: nice-mode.el: please restore compatibility with Emacs 21
Indeed, I overlooked testing it with emacs21. Sorry about that.
I'm a bit confused by your patch, though. It looks like a patch
against the old version, ant it looks similar to the diff from 0.9.12
to 0.9.13 (but I don't have the time to check precisely right now).
Could you provide a patch against the current version (in 0.9.13)?
Thanks,
Daniel
On Dec 3, 2007 10:22 PM, Aaron M. Ucko <[EMAIL PROTECTED]> wrote:
> Package: nice
> Version: 0.9.13-1
> Severity: important
> Tags: patch
>
> In modernizing nice-mode to work with newer versions of CC Mode (as
> included in Emacs 22 and XEmacs), its authors dropped support for
> Emacs 21, breaking nice's installation on systems with that version
> installed:
>
> > Setting up nice (0.9.13-1) ...
> > install/nice: Handling install for emacsen flavor emacs21
> [...]
> > While compiling toplevel forms in file
> > /usr/share/emacs21/site-lisp/nice/nice-mode.el:
> > !! File error (("Cannot open load file" "cc-fonts"))
> > Wrote /usr/share/emacs21/site-lisp/nice/nice-startup.elc
> > Done
> > emacs-package-install: /usr/lib/emacsen-common/packages/install/nice
> > emacs21 emacs21 emacs22 xemacs21 failed at
> > /usr/lib/emacsen-common/emacs-package-install line 30, line 1.
> > dpkg: error processing nice (--configure):
> > subprocess post-installation script returned error exit status 1
>
> Please apply the attached patch, which allows nice-mode to work with
> either version AFAICT.
>
> BTW, I would also advise enabling the commented-out FLAVORTEST /
> SITEFLAG logic, as there is no need to load other packages' Emacs
> startup files (the [...] above) prior to compiling nice's elisp code.
>
> -- System Information:
> Debian Release: lenny/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.22.10 (SMP w/2 CPU cores)
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages nice depends on:
> ii blackdown-j2sdk1.4 [java2-run 1.4.2+02 Java(TM) 2 SDK, Standard Edition,
> ii gij [java-virtual-machine]4:4.2.1-6 The GNU Java bytecode interpreter
> ii gij-4.0 [java1-runtime] 4.0.3-2The GNU Java bytecode interpreter
> ii gij-4.1 [java1-runtime] 4.1.2-16 The GNU Java bytecode interpreter
> ii gij-4.2 [java1-runtime] 4.2.2-3The GNU Java bytecode interpreter
> ii jamvm [java1-runtime] 1.4.5-3+b1 virtual machine which conforms to
> ii kaffe 2:1.1.8-3 A JVM to run Java bytecode
> ii kaffe-pthreads [kaffe]2:1.1.8-3 A POSIX threads enabled version
> of
> ii sablevm [java1-runtime] 1.13-1.1 Free implementation of Java
> Virtua
> ii sun-java5-jre [java1-runtime] 1.5.0-13-1 Sun Java(TM) Runtime Environment
> (
> ii sun-java6-jre [java1-runtime] 6-03-2 Sun Java(TM) Runtime Environment
> (
>
> nice recommends no packages.
>
> -- no debconf information
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454065: jikes-classpath should be in Section devel
Package: jikes-classpath Version: 2:0.92-4ubuntu2 Severity: minor Since it provides a java compiler, jikes-classpath should be in Section devel, not libs. Thanks! -- System Information: Debian Release: lenny/sid APT prefers gutsy-updates APT policy: (700, 'gutsy-updates'), (700, 'gutsy'), (600, 'gutsy-backports'), (500, 'gutsy-security'), (200, 'hardy') Architecture: i386 (i686) Kernel: Linux 2.6.22-14-generic (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages jikes-classpath depends on: ii classpath2:0.92-4ubuntu2 clean room standard Java libraries ii java-common 0.26ubuntu1 Base of all Java packages ii jikes1:1.22-6Fast Java compiler adhering to lan jikes-classpath recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439444: cc1: error: /tmp/buildd/tcng-10b/include/default.tc: No such file or directory
Package: tcng Version: 10b-1 Severity: important When using tcng, I get that message: cc1: error: /tmp/buildd/tcng-10b/include/default.tc: No such file or directory Later, essential fields like ip_len are not recognized. This makes the package pretty unusable by itself. It looks like tcng was built using the buildd path instead of the system one. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (890, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages tcng depends on: ii cpp4:4.1.1-15The GNU C preprocessor (cpp) ii iproute20061002-3Professional tools to control the ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries tcng recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408829: backupninja: New mysql feature: backup table structure only
Package: backupninja
Version: 0.9.4-6
Severity: wishlist
Tags: patch
A long time ago I submitted a patch (that was accepted) to support the 'ignores'
option for the mysql plugin. That option completely omits certain tables from
the dump.
Here is a new patch that provides another option for mysql: 'nodata'. Qualified
tables listed in the nodata section will only have their structure dumped. This
is very useful to backup databases that have cache data you don't want to
backup, but you still need the strcture of table to exist on restore.
I took the opportunity to refactor the dump command, which was duplicated at
four places.
I had no opportunity to test the vserver mode.
Cheers,
Daniel
--- /usr/share/backupninja/mysql.orig 2006-12-15 07:12:34.0 +0100
+++ /usr/share/backupninja/mysql 2007-01-14 12:34:33.0 +0100
@@ -6,6 +6,7 @@
getconf backupdir /var/backups/mysql
getconf databases all
getconf ignores
+getconf nodata
getconf dbhost localhost
getconf hotcopy no
getconf sqldump no
@@ -47,7 +48,7 @@
## This only works for mysqldump at the moment
ignore=''
-for i in $ignores; do
+for i in $ignores $nodata; do
ignore="$ignore --ignore-table=$i"
done
@@ -243,10 +244,28 @@
fatal "Authentication problem, maybe user/password is wrong or mysqld is not running?"
fi
fi
-fi
+fi
for db in $databases
do
+ DUMP_BASE="$MYSQLDUMP $defaultsfile --lock-tables --complete-insert --add-drop-table --quick --quote-names"
+
+ # Dumping structure and data
+ DUMP="$DUMP_BASE $ignore $db"
+
+ # Dumping structure only if needed for this database
+ if echo "$nodata" | grep -E '(^|[[:space:]])'"$db\." >/dev/null
+ then
+ # Get the structure of the tables, without data
+ DUMP_STRUCT="$DUMP_BASE --no-data $db"
+ for qualified_table in $nodata
+ do
+table=$( expr match "$qualified_table" "$db\.\([^\w]*\)" )
+DUMP_STRUCT="$DUMP_STRUCT $table"
+ done
+ DUMP="( $DUMP; $DUMP_STRUCT )"
+ fi
+
if [ $usevserver = yes ]
then
# Test to make sure mysqld is running, if it is not sqldump will not work
@@ -255,9 +274,9 @@
fatal "Either you have an authentication problem, or mysqld doesn't appear to be running!"
fi
if [ "$compress" == "yes" ]; then
- execstr="$VSERVER $vsname exec $MYSQLDUMP $defaultsfile --lock-tables --complete-insert --add-drop-table --quick --quote-names $ignore $db | $GZIP > $vroot$dumpdir/${db}.sql.gz"
+ execstr="$VSERVER $vsname exec $DUMP | $GZIP > $vroot$dumpdir/${db}.sql.gz"
else
- execstr="$VSERVER $vsname exec $MYSQLDUMP $defaultsfile --lock-tables --complete-insert --add-drop-table --quick --quote-names $ignore $db -r $vroot$dumpdir/${db}.sql"
+ execstr="$VSERVER $vsname exec $DUMP -r $vroot$dumpdir/${db}.sql"
fi
else
# Test to make sure mysqld is running, if it is not sqldump will not work
@@ -266,9 +285,9 @@
fatal "Either you have an authentication problem, or mysqld doesn't appear to be running!"
fi
if [ "$compress" == "yes" ]; then
- execstr="$MYSQLDUMP $defaultsfile --lock-tables --complete-insert --add-drop-table --quick --quote-names $ignore $db | $GZIP > $dumpdir/${db}.sql.gz"
+ execstr="$DUMP | $GZIP > $dumpdir/${db}.sql.gz"
else
- execstr="$MYSQLDUMP $defaultsfile --lock-tables --complete-insert --add-drop-table --quick --quote-names $ignore $db -r $dumpdir/${db}.sql"
+ execstr="$DUMP -r $dumpdir/${db}.sql"
fi
fi
debug "su $user -c \"$execstr\""
Bug#376157: exim4-config: fails to deliver root mail
Hi, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376157 I understand this bug resulted from a misconfiguration. Problem is, it's not that hard to fall into this situation (the submitter did it, and I did it too), and the results are quite severe, like root mails being lost, and not so easy to debug for a non-guru. Couldn't something be done to try to prevent this situation? What about adding the value of /etc/mailname to the list of local domains? Either automatically and silently (any downside to this?) or at least make it the default value in the debconf question about local domains. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395042: nice: FTBFS: Exception in thread "main" java.lang.NullPointerException
Hi, There is a new verion of nice in the archive (0.9.12-2, uploaded just before your build), which already fixes a FTBFS. Could you please try it? Or is there an ETA for a new autobuild? Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379871: nice: FTBFS (amd64+i386)
For information, after discussing with kaffe developpers, the problem was most likely fixed by the upgrade to kaffe 2:1.1.7-4, which includes patches for amd64. Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331649: nice: libant1.6-java to ant transition
Salut Arnaud, Sorry to bother you again, but it's been a very long time. Should I look for another sponsor? Daniel Arnaud Vandyck wrote: Yes, busy, your mail is in red in my inbox ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331649: nice: libant1.6-java to ant transition
Arnaud Vandyck wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Daniel, I'll try to take upload it asap, thanks for your work, Salut Arnaud, I know you might be busy, I'm just checking you haven't forgotten about this. Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331649: nice: libant1.6-java to ant transition
Hi Arnaud, Sorry for not being responsive earlier. I put together a new release for Nice, and took the opportunity to fix all the standing packaging bugs at the same time. This one was easy ;-) Unfortunately I cannot build at the moment, as the testing version of kaffe is buggy (see bug report on nice). According to dalibor, the unstable should work. But I don't have unstable, and I'm hitting some pbuilder bug, so I cannot build at all. If you or anybody could try to build those with the latest kaffe: http://cristal.inria.fr/~bonniot/debian/ That would be a great help. The Buid-Depends version requirement on kaffe will need to be adjusted based on the result of this build. I'll also need a sponsor later on. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349505: planetpenguin-racer: 'c' key at race choice screen makes ppr segfault
Package: planetpenguin-racer Version: 0.3.1-5 Severity: normal When I press key 'c' at the race selection screen, ppr consistently crashes, with: Fatal signal: Segmentation Fault (SDL Parachute Deployed) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (99, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages planetpenguin-racer depends on: ii libc62.3.5-8 GNU C Library: Shared libraries an ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-5 GCC support library ii libglu1-xorg [libglu1] 6.8.2.dfsg.1-11 Mesa OpenGL utility library [X.Org ii libice6 6.8.2.dfsg.1-11 Inter-Client Exchange library ii libpng12-0 1.2.8rel-5 PNG library - runtime ii libsdl-mixer1.2 1.2.6-1.1 mixer library for Simple DirectMed ii libsdl1.2debian 1.2.9-0.0 Simple DirectMedia Layer ii libsm6 6.8.2.dfsg.1-11 X Window System Session Management ii libstdc++6 4.0.2-5 The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-11 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-11 X Window System miscellaneous exte ii libxi6 6.8.2.dfsg.1-11 X Window System Input extension li ii libxmu6 6.8.2.dfsg.1-11 X Window System miscellaneous util ii libxt6 6.8.2.dfsg.1-11 X Toolkit Intrinsics ii planetpenguin-racer-data 0.3.1-5 data files for the game PlanetPeng ii tcl8.4 8.4.11-1Tcl (the Tool Command Language) v8 ii xlibmesa-gl [libgl1] 6.8.2.dfsg.1-11 Mesa 3D graphics library [X.Org] ii zlib1g 1:1.2.3-9 compression library - runtime Versions of packages planetpenguin-racer recommends: ii planetpenguin-racer-extras0.5-2 Additional courses for PlanetPengu -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348930: debianutils: BROWSER variable not documented
Clint Adams wrote: I propose the following text as a starting point: The BROWSER variable can be used to select which browser is started by the sensible-browser command. For instance, to use firefox, add the following to /etc/environ: BROWSER=/usr/bin/mozilla-firefox Are you suggesting that this be added to environ(7) ? I guess that would be in line with documenting EDITOR there (unless EDITOR is more "standard" than BROWSER?). In this case, I guess "add the following to /etc/environ" could be replaced by "use" since people reading environ(7) now that part already. Personally, I think it might make sense to have that information in sensible-browser(1). The most important is to have that info *somewhere*, and to fix the mention that BROWSER is documented in environ(7) when it is not. Actually, "too much" doc is better than not enough, so it could be mentionned in both. Besides, sensible-browser(1) is very short at the moment, so adding that paragraph there will not overwhelm the user ;-) Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349010: debian-policy: Chapter 6 - Package maintainer scripts: redundant info about exit status
Package: debian-policy Severity: minor Section 6.1, third paragraph, says that maintainer scripts, should exit with non-zero on error. Then section 6.3 (titled "Controlling terminal for maintainer scripts"), says: "Each script should return a zero exit status for success, or a nonzero one for failure." First, I don't think this has anything to do with the controlling terminal. Second, this info should be regrouped in one place (not merely delete the second one, because the first one does not explicitely say it should be zero on success). Maybe the best would be to create a new section, just after the introduction. Proposal: 6.2 Exit status The package management system looks at the exit status from these scripts. Each script must return a zero exit status for success, or a nonzero one for failure. It is important that they exit with a non-zero status if there is an error, so that the package management system can stop its processing. For shell scripts this means that you almost always need to use set -e (this is usually true when writing shell scripts, in fact). It is also important, of course, that they don't exit with a non-zero status if everything went well. Feel free to adjust. Note that I replaced the "should return..." by "must return..." as I think it is a requirement, but undo that if I am wrong, AINAPE (policy expert!). Cheers, Daniel -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (99, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348930: debianutils: BROWSER variable not documented
Package: debianutils Version: 2.15.2 Severity: minor `man sensible-browser` says: Documentation of the EDITOR, PAGER, and BROWSER variables in environ(7) However, BROWSER is not mentionned there (EDITOR and PAGER are): lyon:/etc# man 7 environ | grep BROWSER Reformatting environ(7), please wait... lyon:/etc# Yes, it's not so hard to guess, but it would be more user friendly to have some documentation about BROWSER. This is especially important as people using Gnome will automatically have mozilla-browser installed (yelp depends on it), and it seems to have precendence when BROWSER is not set. This is not what firefox users will want, so they are going to look for the solution to change that. I propose the following text as a starting point: The BROWSER variable can be used to select which browser is started by the sensible-browser command. For instance, to use firefox, add the following to /etc/environ: BROWSER=/usr/bin/mozilla-firefox Cheers, Daniel -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (99, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages debianutils depends on: ii coreutils 5.2.1-2.1 The GNU core utilities ii libc6 2.3.5-8GNU C Library: Shared libraries an debianutils recommends no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345150: grip: Silently overwrite existing tracks (noartist/unknown_disc)
Package: grip Version: 3.3.1-4 Severity: normal When grip is ripping and encoding tracks, it silently overwrites existing files with the same directory/name combination. I understand this might be desired when CDDB information could be retrieved, and you are really ripping again the same tracks. However, this is particularly annoying when there is no CDDB information (for a custom CD for instance). In that case, the tracks will be in noartist/unknown_disc, and overwritting means deleting a completely different track, possibly losing it irremediably. (I just lost three tracks like that) I guess a simple and satisfying solution would be to detect the presence of a previous noartist/unknown_disc directory, and to generate a new one of the form noartist/unknown_disc_N. I understand this report can be considered a feature request, but since it concerns possible data-loss, I leave it at normal severity. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (99, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages grip depends on: ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libatk1.0-0 1.10.3-1The ATK accessibility toolkit ii libaudiofile00.2.6-6 Open-source version of SGI's audio ii libbonobo2-0 2.10.1-1Bonobo CORBA interfaces library ii libbonoboui2-0 2.10.1-1The Bonobo UI library ii libc62.3.5-8 GNU C Library: Shared libraries an ii libcdparanoia0 3a9.8-11Shared libraries for cdparanoia (r ii libcurl3 7.15.1-1Multi-protocol file transfer libra ii libesd0 0.2.36-1Enlightened Sound Daemon - Shared ii libfontconfig1 2.3.2-1 generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-5 GCC support library ii libgconf2-4 2.10.1-6GNOME configuration database syste ii libgcrypt11 1.2.2-1 LGPL Crypto library - runtime libr ii libglib2.0-0 2.8.3-1 The GLib library of C routines ii libgnome-keyring00.4.5-1 GNOME keyring services library ii libgnome2-0 2.10.1-1The GNOME 2 library - runtime file ii libgnomecanvas2-02.10.2-2A powerful object-oriented display ii libgnomeui-0 2.10.1-1The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.10.1-5The GNOME virtual file-system libr ii libgnutls11 1.0.16-14 GNU TLS library - runtime library ii libgpg-error01.1-4 library for common error values an ii libgtk2.0-0 2.8.9-2 The GTK+ graphical user interface ii libice6 6.8.2.dfsg.1-11 Inter-Client Exchange library ii libid3-3.8.3c2 3.8.3-4.2 Library for manipulating ID3v1 and ii libidn11 0.5.18-1GNU libidn library, implementation ii libjpeg626b-10 The Independent JPEG Group's JPEG ii libncurses5 5.5-1 Shared libraries for terminal hand ii liborbit21:2.12.4-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-01.10.1-2Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsm6 6.8.2.dfsg.1-11 X Window System Session Management ii libstdc++6 4.0.2-5 The GNU Standard C++ Library v3 ii libtasn1-2 0.2.17-1Manage ASN.1 structures (runtime) ii libvte4 1:0.11.15-4 Terminal emulator widget for GTK+ ii libx11-6 6.8.2.dfsg.1-11 X Window System protocol client li ii libxft2 2.1.7-1 FreeType-based font drawing librar ii libxml2 2.6.22-2GNOME XML library ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii xlibs6.8.2.dfsg.1-11 X Window System client libraries m ii zlib1g 1:1.2.3-8 compression library - runtime Versions of packages grip recommends: ii vorbis-tools 1.1.1-1several Ogg Vorbis tools -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318275: bittornado: IP changes not handled very well
Package: bittornado Version: 0.3.11-4 Severity: whishlist Using btdownloadcurses, I noticed that rates (both up and down) would once in a while crawl down to zero, then take some time (tens of minutes, very roughly) to restart at all. Then I noticed this happened when my IP changed. (It changed more often than it should for some reason, which is how I found this out, but it's annoying in any case). In those cases, if I stopped and restarted the client, transfer would restart quite soon. So if the client could detect such situation and handle it (possibly simply restarting everything), it would make IP changes less disruptive than currently. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (99, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages bittornado depends on: ii python2.3.5-2An interactive high-level object-o -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#286381: pppoeconf: lcp-echo-interval and lcp-echo-failure too weak
Package: pppoeconf Version: 1.7 Followup-For: Bug #286381 I agree with the submitter, these values might need to be upped. I made a fresh sarge install, and with the pppoeconf-generated setup (with 20s interval and 3 lcp-echo attempts), I was getting disconnections due to echo-requests timeouts, every 30mn-1h or so. Upping to 4x60s improved things considerably (only one disconnect during the whole night, still with activity on the link). Comparing with a previous install that was not getting such disconnects, it differs both in that the previous one used pppoe and not the plugin, and had 3x60s lcp-echos. I don't remember tweaking it, so that might be the previous default. It would be interesting to check if and why the plugin really gets more disconnects, or if the submitter also had different setting for lcp-echos. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (99, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages pppoeconf depends on: ii gettext-base0.14.5-1 GNU Internationalization utilities ii ppp 2.4.3-20050321+2 Point-to-Point Protocol (PPP) daem ii pppoe 3.5-4ubuntu1 PPP over Ethernet driver ii sed 4.1.2-8 The GNU sed stream editor ii whiptail [whiptail-prov 0.51.6-23Displays user-friendly dialog boxe -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285703: whereami, testmii and Sun Gem NIC
Andrew McMillan wrote: Hi, I've added the relevant "ifconfig $1 up" to testmii in the next-to-be-released whereami, but some testing suggests that this might screw up other network cards that are currently working :-( Do you think this problem is specific to the Sun Gem NIC? I could perhaps detect this type of NIC specifically and only do the ifconfig up if necessary? No, I also need the ifconfig up on my laptop, with a "Broadcom 4400 10/100BaseT Ethernet" card. The question is, which group should be listed? Those that need the ifconfig up, or those that can't bear it? Or could the bug be tracked to individual card drivers? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308980: whereami: testdhcp with dhclient3 does not detect failure
Package: whereami Version: 0.3.20 Severity: normal Tags: patch When testdhcp uses dhclient3, it does not detect if no DHCP offer was obtained. The reason for this is that by default dhclient3 will go to the background in that case, and return 0. It can be made to exit with non-zero instead by passing the -1 command-line option. The patch is simply: --- /tmp/testdhcp 2005-05-13 13:15:39.107870488 +0200 +++ /usr/share/whereami/tests/testdhcp 2005-05-13 10:42:46.0 +0200 @@ -143,7 +143,7 @@ case $1 in start) -$DHCLIENTPATH $QUIETFLAG $INTERFACE +$DHCLIENTPATH -1 $QUIETFLAG $INTERFACE ;; stop) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages whereami depends on: ii debconf 1.4.30.13Debian configuration management sy ii iputils-ping3:20020927-2 Tools to test the reachability of ii netbase 4.21 Basic TCP/IP networking system ii perl5.8.4-8 Larry Wall's Practical Extraction -- debconf information: * whereami/how_to_configure: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285703: whereami: +1
Package: whereami Version: 0.3.20 Followup-For: Bug #285703 I ran into the same situation, and I agree this would be a very convenient feature. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages whereami depends on: ii debconf 1.4.30.13Debian configuration management sy ii iputils-ping3:20020927-2 Tools to test the reachability of ii netbase 4.21 Basic TCP/IP networking system ii perl5.8.4-8 Larry Wall's Practical Extraction -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307767: drupal: Please include extractor.php
Finding the script would have been easier for me if you had pointed me to the contrib CVS. ;-) Oops, sorry for forgetting this. Do you think that including actual po files from the CVS might make sense? BTW, since you appear to be somwhat of an active user, could you help me with packaging 4.6.0? I'm not completely familiar with the way drupal handles translations yet. If I understand correctly, the user would still need to manually import the po files for the languages they want, right? Are the translations stored in the database after import? I suppose it also matters how big the po files are. Regarding packaging, I cannot say I have loads of free time at the moment, but if you need help badly I can try to. Concretely, how do you propose to collaborate? I can surely beta-test the packages, since I have test installation of my site. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#222244: gallery: I see the same hang
It sounds like your apache2 setup is not yet configured and that may be causing the hang. Selecting to reconfigure apache2 before it has been setup may be causing the gallery package's post installation script to hang. I haven't yet been able to reproduce this issue but I'll see what I can do to reproduce it. As far as I can see, apache2 is working fine, at least from the same machine (it does give that warning at each restart). I assume you had a previously configured 1.4.4-pl6-1 package installed, correct? Yes, I had played with gallery before the upgrade (haven't been using it seriously yet, but I did the basic configuration). Now if I visit the gallery page on localhost, it says gallery needs reconfiguration. The hanged setup is still, in case you can tell me what else to investigate. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#300953: nice: FTBFS: halts on "nice.tools.compiler.console: parsing"
tags 300953 pending thanks The error you get in sid is due to a bug in kaffe. I reported it upstream, and it has been fixed in kaffe CVS. Hopefully they will release 1.1.5 soon, and we can close this report. I'm also trying to make sure it will make it possible to upload a more recent version of nice in Debian. Not assigning the bug to kaffe to avoid bothering the maintainers, since the bug is already analysed an fixed upstream. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#300953: nice: FTBFS: halts on "nice.tools.compiler.console: parsing"
Hi Roland, Thanks for your report. Which runtime did you use to try to build? The transcript points to kaffe, but the reports says: > pn kaffe | java-virtual-machine Not found. which seems to imply that kaffe is not installed. Version numbers would be useful too. In any case, I am aware that free runtimes have a hard time build recent versions of Nice (which is why the version in Debian is outdated). I'm in the process of testing several options and filing bug reports. If anybody can help, please let me know, that would be very useful, since I'm also quite busy working on upstream. Cheers, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297841: exim4-config: Local rewrite stopped working after upgrade in sarge
Still, I think the following behaviour is also a common one: outside mail sent by smarthost, local mail delivered in spool; no incomming mail. This is typical with a dialup machine where users have their mailboxes outside the system (on an IMAP server for instance). Does the "mail sent by smarthost; received via SMTP or fetchmail" give this behaviour? Yes, it does. It _allows_ incoming mail but does not require it. And the SMTP daemon will only listen on 127.0.0.1 by default, i.e. the local loopback interface. hth, cu andreas Thanks a lot. I chose the "mail sent by smarthost; received via SMTP or fetchmail", and it indeed seems to be doing what I want. I think there are two points to consider: 1) sarge upgrade. I'm afraid I'm only one who's going to be hit by this change. Basically, when your mail box is on an outside server, I does seem logical not to select "received by SMTP or fetchmail" but instead "no local mail". It looks like this cannot be fixed automatically (since for some people keeping the same option is desired) but there really should be some big warning about possibly needing to change one's setup. Do you plan to do so? Which brings us to: 2) debconf. As said above, one can be confused by the current list of options. I think the "internet site" idea is quite good: give a short description of the type of host. Then after ";" explain more technically what will happen in that setup. Would it make sense for the second line to start with "dial-up;" and the third line with "LAN;" ? There might be better terms, but this should give the idea to most people (in particular, not to chose the 3rd if the smart host is not a local server). Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297841: exim4-config: Local rewrite stopped working after upgrade in sarge
However, it seems to me that when a mail is sent to a local user, it is not a very sensible thing to do to forward it to the smart host as is, since it will surely fail. Shouldn't the default configuration do it differently? It won't surely fail in the situation that the local host is in a company network and does not have local mailboxes. OK, I understand the behaviour makes sense in that setup, and I suppose it's not an uncommon setup. Still, I think the following behaviour is also a common one: outside mail sent by smarthost, local mail delivered in spool; no incomming mail. This is typical with a dialup machine where users have their mailboxes outside the system (on an IMAP server for instance). Does the "mail sent by smarthost; received via SMTP or fetchmail" give this behaviour? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297841: exim4-config: Local rewrite stopped working after upgrade in sarge
Thanks for the answer.
Hello,
Yes, that is caused by
- Make exim work correctly if dc_readhost ("visible, rewritten domain name
for local users") ends up as part of local_domain, which happens if
the same value is chosen for mailname and dc_readhost. This
implemented by new router, hub_user_smarthost. Previously users were
required to use something different (my.invalid.domain) for mailname.
and I actually consider this to be a correct change, fixing a bug.
I believe you that a bug was fixed, I don't know enough exim to comment on
that.
However, it seems to me that when a mail is sent to a local user, it is not a
very sensible thing to do to forward it to the smart host as is, since it will
surely fail. Shouldn't the default configuration do it differently?
> If I select "no local mail" I actually don't want local delivery.
Do you want mails to local users to fail?
This is important, because security checks, apt-changelogs, and surely other
things are sent to a local user (root) by default.
Cheers,
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294750: kaffe -vmdebug
Salut Arnaud, This has been solved in 2:1.1.4.PRECVS7-1 Oh, great. I'm surprised that reportbug didn't warn me that a new version of kaffe existed. It used to do that. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
