Bug#681590: [mythtv-backend] /etc/cron.weekly/mythtv-database throws error
Package: mythtv-backend Version: 0.25-dmo2 Severity: normal --- Please enter the report below this line. --- anacron reports the following error once a week probably since an dist-upgrade around 05/12/2012: /etc/cron.weekly/mythtv-database: mysqldump: ambiguous option '--all' (all-databases, allow-keywords) There seems to be no parameter --all for mysqldump. Is --all-databases meant instead? Greetings, Gert --- System information. --- Architecture: amd64 Kernel: Linux 3.4-4.slh.8-aptosid-amd64 Debian Release: wheezy/sid 500 unstableftp.uni-erlangen.de 500 unstabledebian.netcologne.de 500 unstabledeb.opera.com 100 experimental-snapshots qt-kde.debian.net --- Package information. --- Depends(Version) | Installed -+-=== mythtv-common (= 0.25-dmo2) | 0.25-dmo2 libc6 (= 2.3.2) | 2.13-34 libgcc1 (= 1:4.1.1) | 1:4.7.1-5 libmyth-0.25-0 (= 0.25) | 0.25-dmo2 libmythavcodec52 (= 0.25) | 0.25-dmo2 libmythavformat52 (= 0.25) | 0.25-dmo2 libmythavutil50(= 0.25) | 0.25-dmo2 libmythswscale0(= 0.25) | 0.25-dmo2 libqt4-network (= 4:4.5.3) | 4:4.8.2-1 libqt4-script (= 4:4.5.3) | 4:4.8.2-1 libqt4-sql (= 4:4.5.3) | 4:4.8.2-1 libqt4-xml (= 4:4.5.3) | 4:4.8.2-1 libqtcore4(= 4:4.7.0~beta1) | 4:4.8.2-1 libqtgui4 (= 4:4.5.3) | 4:4.8.2-1 libstdc++6 (= 4.6) | 4.7.1-5 cron | 3.0pl1-124 wget | 1.13.4-3 transcode| 4:1.1.7-0.4 libjs-jquery | 1.7.2+debian-2 Recommends (Version) | Installed ==-+-=== mythtv-database| 0.25-dmo2 logrotate | 3.8.1-4 xmltv-util | Suggests (Version) | Installed ==-+-=== mythtv-frontend| 0.25-dmo2 mythweb|
Bug#648960: solved upstream -- medit lost standard hotkeys
This issue is fixed in medit 1.0.5. It would be great if this version could be packaged for sid soon. https://sourceforge.net/tracker/?func=detailaid=3427193group_id=167563atid=843451 Thanks, Gert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648960: medit lost standard hotkeys
Package: medit Version: 1.0.3-1+b1 (Using debian/sid via aptosid) Many medit hotkeys do not work anymore. E.g. ctrl+f for the find requester or ctrl+s for saving changes do not have an effect anymore. On startup medit prints many warnings to the console that probably are related to this issue. Here are just some examples: ... (medit:5374): Moo-WARNING **: in file mooutils/mooaccel.c, line 347, function _moo_accel_register: could not parse accelerator 'Primary7' (medit:5374): Moo-WARNING **: in file mooutils/mooaccel.c, line 248, function set_accel: could not parse accelerator 'Primary7' (medit:5374): Moo-WARNING **: in file mooutils/mooaccel.c, line 347, function _moo_accel_register: could not parse accelerator 'Primary9' (medit:5374): Moo-WARNING **: in file mooutils/mooaccel.c, line 248, function set_accel: could not parse accelerator 'Primary9' (medit:5374): Moo-WARNING **: in file mooutils/mooaccel.c, line 347, function _moo_accel_register: could not parse accelerator 'Primary8' (medit:5374): Moo-WARNING **: in file mooutils/mooaccel.c, line 248, function set_accel: could not parse accelerator 'Primary8' (medit:5374): Moo-WARNING **: in file mooutils/mooaccel.c, line 347, function _moo_accel_register: could not parse accelerator 'Primaryg' (medit:5374): Moo-WARNING **: in file mooutils/mooaccel.c, line 347, function _moo_accel_register: could not parse accelerator 'PrimaryAltf' (medit:5374): Moo-WARNING **: in file mooutils/mooaccel.c, line 248, function set_accel: could not parse accelerator 'PrimaryAltf' ... I also tried to reconfigure the hotkeys on the medit GUI, but this did not work. The newly configured hotkey does not work, and when opening the hotkey configuration window again, the hotkey is resetted to Default which is empty, again. On trying to set the hotkey medit prints the following lines to the console: (medit:5385): Moo-CRITICAL **: in file mooutils/mooaccel.c, line 309, function _moo_get_default_accel: Condition 'accel != NULL' failed (medit:5385): Moo-CRITICAL **: in file mooutils/mooaccel.c, line 309, function _moo_get_default_accel: Condition 'accel != NULL' failed (medit:5385): Moo-WARNING **: in file mooutils/mooaccel.c, line 700, function _moo_accel_normalize: could not parse accelerator 'Primarys' (medit:5385): Moo-CRITICAL **: in file mooutils/mooaccel.c, line 380, function moo_modify_accel_real: Condition 'new_accel != ((void *)0)' failed Greetings, Gert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631621: [reportbug-ng] Crash on not readable source.list.d/file
Package: reportbug-ng Version: 1.24 Severity: normal --- Please enter the report below this line. --- I did start report-ng for the first time and it did crash with the following output: Traceback (most recent call last): File /usr/bin/reportbug-ng, line 72, in module gui = RngGui(args) File /usr/share/reportbug-ng/rnggui.py, line 43, in __init__ self.setupUi(self) File /usr/share/reportbug-ng/ui/mainwindow.py, line 29, in setupUi self.lineEdit = PackageLineEdit(self.centralwidget) File /usr/share/reportbug-ng/ui/packagelineedit.py, line 15, in __init__ cache = FilteredCache(Cache()) File /usr/lib/python2.6/dist-packages/apt/cache.py, line 93, in __init__ self.open(progress) File /usr/lib/python2.6/dist-packages/apt/cache.py, line 140, in open self._list.read_main_list() SystemError: E:Opening /etc/apt/sources.list.d/opera.list - ifstream::ifstream (13: Permission denied) The file opera.list was only readable for user root (-rw---). Making it readable for all did solve the problem. So IMHO reportbug-ng should check the accessability of the file and either report it in a more userfriendly way, or if the information is optional, just print a warning and continue without this file. Greetings, Gert --- System information. --- Architecture: amd64 Kernel: Linux 2.6.39-2.slh.1-aptosid-amd64 Debian Release: wheezy/sid 500 unstableftp.uni-erlangen.de 500 unstabledebian.netcologne.de 500 unstabledeb.opera.com --- Package information. --- Depends(Version) | Installed -+- python | 2.6.6-14 python-support (= 0.90.0) | 1.0.13 python-debianbts(= 1.0) | 1.10 python-qt4 | 4.8.3-2+b1 xdg-utils| 1.1.0~rc1-2 xterm| 270-1 python-apt (= 0.7.93) | 0.8.0 Package's Recommends field is empty. Package's Suggests field is empty.
Bug#631626: [xmoto] Xorg crashes on quitting xmoto
Package: xmoto Version: 0.5.2-2+b1 Severity: serious --- Please enter the report below this line. --- Running xmoto does work fine. But when choosing Quit in the game the whole X- Server does crash and you get back to the display manager (here kdm). In the /var/log/Xorg.0.log.old file I have found: [ 8530.518] Backtrace: [ 8530.520] 0: /usr/bin/X (xorg_backtrace+0x26) [0x4a3836] [ 8530.520] 1: /usr/bin/X (0x40+0x65049) [0x465049] [ 8530.520] 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f78c6c0c000+0xf020) [0x7f78c6c1b020] [ 8530.520] 3: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (0x7f78c2971000+0x80521) [0x7f78c29f1521] [ 8530.520] 4: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (0x7f78c2971000+0x69fe6) [0x7f78c29dafe6] [ 8530.520] 5: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (0x7f78c2971000+0x5a244) [0x7f78c29cb244] [ 8530.520] 6: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (0x7f78c2971000+0x13fc63) [0x7f78c2ab0c63] [ 8530.520] 7: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (0x7f78c2971000+0x13dabc) [0x7f78c2aaeabc] [ 8530.520] 8: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (0x7f78c2971000+0x13dc9a) [0x7f78c2aaec9a] [ 8530.520] 9: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so (0x7f78c2971000+0x1021db) [0x7f78c2a731db] [ 8530.520] 10: /usr/lib/xorg/modules/extensions/libglx.so (0x7f78c43b3000+0x22d17) [0x7f78c43d5d17] [ 8530.520] 11: /usr/lib/xorg/modules/extensions/libglx.so (0x7f78c43b3000+0x254d5) [0x7f78c43d84d5] [ 8530.520] 12: /usr/bin/X (0x40+0x32d09) [0x432d09] [ 8530.520] 13: /usr/bin/X (0x40+0x26fae) [0x426fae] [ 8530.520] 14: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7f78c5945ead] [ 8530.520] 15: /usr/bin/X (0x40+0x2729d) [0x42729d] [ 8530.520] Segmentation fault at address (nil) [ 8530.520] Fatal server error: [ 8530.520] Caught signal 11 (Segmentation fault). Server aborting [ 8530.520] [ 8530.520] I am running KDE with composite (OpenGL) activated on an intel HD-3000 machine: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Giga-byte Technology Device d000 Flags: bus master, fast devsel, latency 0, IRQ 45 Memory at fb40 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at ff00 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 # dpkg -l *xorg* | grep ii | sort ii xserver-xorg1:7.6+7 X.Org X server ii xserver-xorg-core 2:1.10.2-2 Xorg X server - core server ii xserver-xorg-input-all 1:7.6+7 X.Org X server -- input driver metapackage ii xserver-xorg-input-evdev1:2.6.0-2+b1 X.Org X server -- evdev input driver ii xserver-xorg-input-mouse1:1.7.0-4 X.Org X server -- mouse input driver ii xserver-xorg-input-synaptics1.4.0-1+b1 Synaptics TouchPad driver for X.Org server ii xserver-xorg-input-vmmouse 1:12.7.0-2 X.Org X server -- VMMouse input driver to use with VMWare ii xserver-xorg-input-wacom0.10.10+20110203-1+b1 X.Org X server -- Wacom input driver ii xserver-xorg-video-apm 1:1.2.3-2+b1 X.Org X server -- APM display driver ii xserver-xorg-video-ark 1:0.7.3-2+b1 X.Org X server -- ark display driver ii xserver-xorg-video-ati 1:6.14.2-1 X.Org X server -- AMD/ATI display driver wrapper ii xserver-xorg-video-chips1:1.2.4-1+b1 X.Org X server -- Chips display driver ii xserver-xorg-video-cirrus 1:1.3.2-4+b1 X.Org X server -- Cirrus display driver ii xserver-xorg-video-fbdev1:0.4.2-4+b1 X.Org X server -- fbdev display driver ii xserver-xorg-video-i128 1:1.3.4-2+b1 X.Org X server -- i128 display driver ii xserver-xorg-video-intel2:2.15.0-3 X.Org X server -- Intel i8xx, i9xx display driver ii xserver-xorg-video-mach64 6.9.0-1 X.Org X server -- ATI Mach64 display driver ii xserver-xorg-video-mga 1:1.4.13.dfsg-3+b1 X.Org X server -- MGA display driver ii xserver-xorg-video-neomagic
Bug#596255: icedove: Mails missing the References-Header open a new thread
Package: icedove Version: 3.0.6-1 Hello, I have configured icedove to let the mails be sorted by date and threaded. Now I have recieved a replying mail. This mail has set the In-Reply-To header but not the References header. How this mail is sorted: This mail does open a new thread. How this mail should be sorted: Regarding to https://wiki.mozilla.org/MailNews:Message_Threading if the References header is not given a fallback should be made to the In-Reply-To header. So the mail should be sorted into the existing thread, shouldn't it? If I choose other actions - show in conversation from the displayed mail a new tab is opened and the whole thread is displayed with the problematic mail correctly included. So the wrong behaviour is only in the normal folder mail list. Thanks, Gert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552162: This still happens with 1.24-2
Today chrony version 1.24-2 came in and the dist-upgrade aborted again with the same error. I had to manually insert the sleep commands again, so apt-get -f install was successfull. Greetings, Gert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#463518: chrony: no sources
Hello, I do have the same problem as described above. I am using chrony with dnsmasq as local nameserver. But the system is not going online at boot time, but later on demand manually (AFAIU chrony exactly is designed for this case?). So at the time chrony is started the ntp servers are not available and are discarded from the sources list. The /etc/ppp/ip-up.d/chrony does not change the situation when going online (via pppoe). I have tried the Should-Start: $named entry but this does not help in my case. Probably because the servers are not available even after starting the named dnsmasq while the system is still offline. It only helps to stop/start the chronyd after dial in. Is there any hope that this will be fixed soon? Thanks, Gert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552162: this bug breaks installing of chrony
Hi, I did run into this bug, too, when installing the package: # apt-get install chrony Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: chrony 0 upgraded, 1 newly installed, 0 to remove and 12 not upgraded. Need to get 0B/319kB of archives. After this operation, 782kB of additional disk space will be used. Selecting previously deselected package chrony. (Reading database ... 152775 files and directories currently installed.) Unpacking chrony (from .../chrony_1.23-7_i386.deb) ... Processing triggers for install-info ... Processing triggers for man-db ... Processing triggers for menu ... Setting up chrony (1.23-7) ... Ignoring install-info called from maintainer script The package chrony should be rebuilt with new debhelper to get trigger support Creating config file /etc/chrony/chrony.conf with new version Starting /usr/sbin/chronyd... /usr/sbin/chronyd failed to start. invoke-rc.d: initscript chrony, action start failed. dpkg: error processing chrony (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for menu ... Errors were encountered while processing: chrony E: Sub-process /usr/bin/dpkg returned an error code (1) Inserting the sleep 1 commands did fix this problem for me. Thanks, Gert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#375794: ldapscripts should not depends on slapd, libpam-ldap and libnss-ldap
Hello, may I second this wish, if it is technically possible to not let ldapscripts depend on slapd, etc? I want to install the scripts on my desktop where I do not need the slapd to be installed. It is a question of keeping the installation small and also it is a security topic. As more software is installed as more bugs and holes can come in. Especially server software should only be installed where required. Thanks, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488480: kdm: grep @@@ToBeReplacedByDesktopBase@@@ does not respect commented line
Package: kdm
Version: 4:3.5.9.dfsg.1-2+c0.sidux.2
(This is currently a sidux-vesion of the package, but this should not
make a difference, I think.)
In /etc/init.d/kdm a grep is done to check if the kdmrc is maintained by
kdmtheme:
#if configuration is changed by kdmtheme or other tools, don't do magick
if grep -q Theme=@@@ToBeReplacedByDesktopBase@@@ ${KDMRC} grep -q
Wallpaper=default_blue.jpg ${BACKGROUNDRC}
These two greps find the strings even if they are commented. So the grep
pattern better should be
^[^#]*Theme=@@@ToBeReplacedByDesktopBase@@@
and
^[^#]*Wallpaper=default_blue.jpg
Regards,
Gert
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479184: xmoto freezes
I can confirm this on my nearly up to date sidux system. xmoto does freeze here, too. (where e.g. bzflag runs fine) Package: xmoto Version: 0.4.2-1 Severity: normal -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-1.slh.2-sidux-686 (SMP w/1 CPU core; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xmoto depends on: ii libbz2-1.0 1.0.5-0.1 high-quality block-sorting file co ii libc6 2.7-10GNU C Library: Shared libraries ii libcurl3-gnutls7.18.1-1 Multi-protocol file transfer libra ii libgcc11:4.3.0-3 GCC support library ii libgl1-mesa-glx [libgl 7.0.3-1 A free implementation of the OpenG ii libglu1-mesa [libglu1] 7.0.3-1 The OpenGL utility library (GLU) ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii liblua5.1-05.1.3-1 Simple, extensible, embeddable pro ii libode0debian1 2:0.9-1 Open Dynamics Engine - runtime lib ii libpng12-0 1.2.27-1 PNG library - runtime ii libsdl-mixer1.21.2.8-3 mixer library for Simple DirectMed ii libsdl-ttf2.0-02.0.9-1 ttf library for Simple DirectMedia ii libsdl1.2debian1.2.13-2 Simple DirectMedia Layer ii libsqlite3-0 3.5.8-3 SQLite 3 shared library ii libstdc++6 4.3.0-3 The GNU Standard C++ Library v3 ii xmoto-data 0.4.2-1 2D motocross platform game ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479184: libsqlite3 is the problem
a downgrade of libsqlite3-0 to version 3.5.7-2 solved the problem here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476128: kernel differs
No kernel differences? Indeed the kernel versions differ: The client without the problem runs 2.6.22-3-686. On the sidux box that does show the symptom, several 2.6.24 versions have been run. The ubuntu clients currently are using 2.6.24-16-generic. So this might be a reason. I hope to soon find the time to cross-test the versions on the machines. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476128: 2.6.22 does work
I now have tested several kernel versions on the sidux box (using the sidux kernels): 2.6.22.10-rc1-slh-smp-1 works. There are no locking/timeout problems. With all other versions the problem occurs: 2.6.23.14-slh-smp-1 2.6.24-2.6.24.5.slh.1-sidux-686 2.6.25-0.slh.12-sidux-686 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476128: Not on every sid-client
This is strange. We have the described problem with 2 Ubuntu Hardy Heron clients and one debian/sid (sidux) client. Another client (pure sid) does not show this symptom. All clients are up to date. We already have compared several things (NIS-configuration, autofs-scripts, mount-options, etc.) but cannot find the point that makes the difference. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476128: 2 minutes timeouts on accessing unpermitted NFS-shares
Package: nfs-common Version: 1:1.1.2-2 An ubuntu-stable server does share a directory via NFS restricted to one host. If a debian/sid machine does not have permissions to mount this share, mounting is blocked until a timeout of 2 minutes. In my case this e.g. does result in a freezing up iceweasel and icedove if a file-requester should be opened. I think this is the same problem as described here: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/214041 The nfs-version on the ubuntu server is 1:1.1.1~git-20070709-3ubuntu1 Greetings, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456882: Should linux-image-2.6-k7 depend on linux-image-2.6.23-1-486/686?
Package: linux-image-2.6-k7 Version: 2.6.22+11 Hello, I did wonder why the k7 flavor of the 2.6.23 linux-image does not show up in debian/sid for a while now. As I did find out the k7 flavor has been dropped. Is this correct? The question now is which linux image should one install instead? The 486 or the 686 flavor? To make this clear the meta package linux-image-2.6-k7 should IMHO depend on the preferred current linux image. Thanks, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437228: closed by Fabio Tranchitella [EMAIL PROTECTED] (Bug#437228: fixed in dovecot 1:1.0.3-3)
Thank you for fixing. Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437228: S21dovecot failed = S21dovecot.conf: not readable
Roland Stigge wrote:
1. Starting the server multiple times is possible
2. This is done with NAME=${0##*/}
3. cosmetical changes
Since this (2. above) seems to break the init scripts (starting the
server on bootup) at the basic approach of the changes, we shouldn't use
it at all.
As a quick fix you could fall back to dovecot.conf if e.g.
S21dovecot.conf cannot be found.
For starting the server multiple times, I propose the following:
multiple config files are ok, but the init script should be called just
once to start all instances at once. Otherwise we would change semantics
of the init system and cause unexpected problems like the one here.
I second this. The conf-Filename should not be related to the order of
the init-scripts. If you change S21dovecot to S22dovecot it still should
start the server(s) in the same way as before.
Greetings,
Gert
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437228: S21dovecot failed = S21dovecot.conf: not readable
Package: dovecot-common
Version: 1:1.0.3-1
Severity: important
When executing
/etc/rc2.d/S21dovecot start
the following error occurs:
/etc/dovecot/S21dovecot.conf: not readable: S21dovecot failed!
The Problem is that the name of the starting script is used as
config-filename:
NAME=${0##*/}
CONF=/etc/dovecot/${NAME}.conf
The normal dovecot.conf is not loaded.
I wonder that this bug seems not to be reported yet, at least I did not
find such a report. Sorry if I have missed something or set up my system
in a wrong way.
Gert
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423498: missing dependency
you have to install the package libcegui-mk2-dev to make the missing shared library available. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422341: hdparm --security-freeze failes in combination with other settings
Package: hdparm Version: 7.1-2 Hello, executing the following command /sbin/hdparm --security-freeze -u 1 -m 16 -c 1 -k 1 -K 1 -d 1 /dev/hda fails. Instead of setting the parameters hdparm just displays the Usage-Text: hdparm - get/set hard disk parameters - version v7.1 Usage: hdparm [options] [device] .. Options: -a get/set fs readahead -A get/set the drive look-ahead flag (0/1) ... The execution of a single hdparm --security-freeze /dev/hda does work fine. Also the first line without the --security-freeze option does work: /sbin/hdparm -u 1 -m 16 -c 1 -k 1 -K 1 -d 1 /dev/hda The first line did work with all older hdparm versions that came with --security-freeze support. Thanks, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422341: hdparm --security-freeze failes in combination with other settings
Stephen Gran wrote: The option parsing has recently changed. Try /sbin/hdparm -u 1 -m 16 -c 1 -k 1 -K 1 -d 1 --security-freeze /dev/hda (i.e., put long options last). Please let me know if that works for you. I now have tried /sbin/hdparm -u 1 -m 16 -c 1 -k 1 -K 1 -d 1 --security-freeze /dev/hda but the parameters still are not accepted. (The Usage is printed again.) Greetings, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422381: pppoeconf - failed to parse interfaces file
Package: pppoeconf Version: 1.14 pppoeconf asked me to send a bug report, because it could not parse my /etc/network/interfaces correctly. This was my old interfaces file: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 # gateway 192.168.1.1 # dns-* options are implemented by the resolvconf package, if installed # dns-nameservers 192.168.1.1 # dns-search brinkmann iface dsl-provider inet ppp provider dsl-provider auto eth1 iface eth1 inet manual And this the new one created by pppoeconf: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 # gateway 192.168.1.1 # dns-* options are implemented by the resolvconf package, if installed # dns-nameservers 192.168.1.1 # dns-search brinkmann iface dsl-provider inet ppp pre-up /sbin/ifconfig eth1 up # line maintained by pppoeconf provider dsl-provider auto eth1 iface eth1 inet manual iface eth1 inet manual Maybe the interfaces file was set up somehow incorrectly? I have the problem that I need to do a manual ifconfig eth1 up once after reboot. Ohterwise pon will not establish a connection. (This is the case with older and also the latest pppoeconf.) Should I send a separate bug report for this? How should a working interfaces file look like? Thanks, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404948: legacy naming
I had to switch from nvidia to nv driver, because I own a Gforce2 MX/MX400 card that does not work with legacy neither with the latest drivers. ...we will need something like... nvidia-graphics-drivers nvidia-graphics-drivers-legacy nvidia-graphics-drivers-ancient You will run out of names when nvidia will drop the next card generations. Perhaps you can name the packages like this: nvidia-graphics-drivers-200704 nvidia-graphics-drivers-200601 nvidia-graphics-drivers-200506 with the MM date attached is the date when nvidia did drop some cards. One whos card does work with nvidia-graphics-drivers-200704 will not have a problem when the next generation of nvidia drivers, e.g. nvidia-graphics-drivers-200711, are published Ok, this is a problem, because people with more recent cards do not automatically will get the newer drivers. So you need a meta-installer package nvidia-graphics-drivers. This analyzes the installed card and automatically installs the correct package. jm2c Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378667: Workaround
As workaround for the problem you can preload the library. Seems to work here: LD_PRELOAD=libxpcom.so firefox (Well, I not really know what the preload is doing exactly. So it might be the wrong way to solve this.) Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366624: Bug 366624 - size mismatch
Hello, we have run in exactly this problem of mixing ubuntu and debian packages. On delivering a wrong package you get a size mismatch error on apt-get [dist-]upgrade. Is there a new version available yet? We would like to test it, too, if possible. How will you fix this problem? Thanks, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364506: dnsmasq process disappears on dhcp offer
Package: dnsmasq Version: 2.29-1 After dist-upgrading my debian/sid system including the new version of dnsmasq 2.28(!), dnsmasq stops running after offering an IP-address via DHCP. Updating to 2.29 did not solve the problem. I have one debian/sid-PC which is the internet-gateway via DSL. This host is running dnsmasq. I am using the DNS- and DHCP-function of dnsmasq. A notebook is running Windows2000. When this system is asking for an IP-address, the dnsmasq process disappears. So the windows client never gets the new IP-address. Also dns-resolving stops working on my debian-system, because dnsmasq is no longer present. The last log-output in daemon.log from dnsmasq is: Apr 23 22:46:30 localhost dnsmasq[8777]: DHCPDISCOVER(ethlan) 10.216.15.217 00:xx:xx:xx:xx:xx Apr 23 22:46:30 localhost dnsmasq[8777]: DHCPOFFER(ethlan) 192.168.1.90 00:08:02:d0:4b:88 (I have xx'ed out the MAC address.) In system or messages log nothing can be seen. Starting dnsmasq again solves the DNS-problems but with the next renewing of the window's IP-address dnsmasq crashes again. Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359139: enhancement: howto set up firestarter to work with dnsmasq
Package: dnsmasq Version: 2.27-1 I had some problems in getting firestarter and dnsmasq work together. Here is a good description how to manage this. This tip IMHO should be integrated in the dnsmasq FAQ. http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2005q3/000431.html Here is the content of the posting in case the link would be outdated: --- Hi folks. This email is primarily to document my learning, to hopefully save someone else some time and frustration getting Firestarter and dnsmasq working together. As seems to be a common problem, my firewall was preventing dnsmasq from working as a LAN DHCP server. By default Firestarter (naturally) denies all inbound connections, so I attempted to whitelist DHCP packets by adding 'inbound policy rules'. This turned out to be futile, as Firestarter doesn't consider broadcast DHCP packets as 'inbound' since it doesn't recognise the destination IP (255.255.255.255) as belonging to the host. Thus they were classed as 'Unknown' and discarded, regardless of policy rules. My troubleshooting was complicated by an advanced option I had enabled, titled Block broadcasts from external network, which actually dropped broadcasts on *all* interfaces. I believe this is a bug and will be following it up. Firestarter has an explicit option to Enable DHCP for the local network however this turned out to just (re)start ISC dhcpd if you had it installed. No firewall rules related to the protocol are added by this option, so it seems a bit of a red herring. My eventual solution was to add the following line to /etc/firestarter/user-pre to explicitly allow the DHCP broadcasts early in the INPUT table: $IPT -A INPUT -i $INIF -p udp -s 0.0.0.0 --sport 68 -d 255.255.255.255 --dport 67 -j ACCEPT I hope this tale didn't bore you all too much, and will be useful to someone :) Cheers, Andrew Greig --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347253: imv on multiple files does an mv instead an interactive move
Package: renameutils Version: 0.8.1-2 This is not a bug report, but a suggestion for making imv safer: If you have two files file1 and file2 in the current directory and you call an imv * in it, I had expected an interactive move for file1 first and after this one for file2. So this should be the same as calling imv two times, once for each file. Otherwise you automatically overwrite the second file, what is not very interactive. If you want enable this behaviour as a feature, e.g. for allowing an alias mv=imv you should have to enable it by an extra option: alias mv=imv --mv or something. This whould be much safer. Thanks, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339951: udev: random order of eth-devices
Package: udev Version: 0.074-3 debian/sid I think that after replacing the hotplug package by udev the eth0 and eth1 network devices are randomly swapped on boot time on my system. With this the configured pppoe-device does no longer find the dsl-modem, so the system is offline. Currently I have to reboot approx. 1 or 2 times to correct the order of the devices. AFAIK the order of the device names should be related to the MAC adresses of the devices? I have these two devices installed: # lspci -v ... :00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 91) Subsystem: Elitegroup Computer Systems: Unknown device 1808 Flags: bus master, medium devsel, latency 64, IRQ 169 I/O ports at dc00 [size=256] Memory at cffdc000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at cffa [disabled] [size=128K] Capabilities: [40] Power Management version 2 :00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8029(AS) Flags: medium devsel, IRQ 169 I/O ports at d000 [size=32] A friend of mine uses debian/testing and has the same problem after udev did replace the hotplug package recently. Thanks, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323815: bzflag: shoots trough other players
Hello, I do have the same problem here. We are running bzfs localy in our LAN. After upgrading the client from version 2.0.2.20050318 to 2.0.2.20050318-0.1 we had the same and more problems: * Connecting against the old bzfs version did work. But the new-client-tanks could not shoot the old-client-tanks. But the old ones could hit the new ones. Also the new-client-tanks moved very jumpingly, appeared here and there but did not move smoothly. * Connecting against the new bzfs version did not work. bzflag reported Error unpacking world database. = We have downgraded to the 2.0.2.20050318 version again which works fine. Thanks, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322354: gtk2-engines-industrial misses cursors/sb_left_arrow
Package: gtk2-engines-industrial Version: 0.2.46.0 Severity: wishlist The theme comes with a cursors/sb_right_arrow file but the sb_left_arrow is missing. The sb_right/left_arrow occurs in icewm that I am using when switching the desktop by using the mouse via edge-switching. The left arrow looks like the X11/cursors/core.theme arrow instead of the white Industrial cursor. Thanks, Gert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
