Package: bluez
Version: 4.94-2
Severity: normal
After configuring a bluetooth mouse for the first time, all is fine and the
mouse is working.
But after turning the mouse off and on again, or after reboot, or after long
idle time (mouse sleeping?), the bluetooth mouse cannot reconnect to the
Package: bluez
Version: 4.94-3
Followup-For: Bug #635910
Upgrading bluez to 4.94-3 (from unstable) didn't help; the mouse still cannot
reconnect.
To reproduce the problem I did:
1. /etc/init.d/bluetooth stop
2. rm -rf /var/lib/bluetooth/* # to start with clean files
3.
Package: webcalendar
Version: 0.9.45-4
Severity: grave
Tags: security
Justification: user security hole
According to http://freshmeat.net/projects/webcalendar there is a new
version 1.0.0 available, which includes major security fixes of
version 1.0RC3 (all users should upgrade).
Regards
Package: aide
Version: 0.10-6.1
Followup-For: Bug #293073
Running aideinit gives the following error after upgrading to this
version of the aide package:
tombstone:~# aideinit
/usr/sbin/aideinit: /var/lib/aide/aide.conf.autogenerated: file not found
I've the same problem as reported, but
Package: munin-node
Version: 1.2.0-1
Severity: normal
Tags: patch
Munin allows long device names now, but df_abs still generates
abbreviated ones, so that ambiguous values may be transferred if two
long-named devices have the same endings.
The patch below also excludes iso9660 and tmpfs
Package: php-html-template-it
Version: 1.10-1
Severity: important
I had problems with a PHP tool (ilias), as it reported errors with
ITX.php (cannot redeclare class ...). Sorry, I've no glue of PHP.
But I found that removing /usr/share/pear/HTML/IT*.php helped; the files
are available again in
Package: munin-node
Version: 1.2.0-1
Severity: normal
Tags: patch
The plugin /usr/share/munin/plugins/df_inode doesn't convert -
characters in device names to _. Device names happen to have - if
using logical volumes. These devices currently aren't displayed via
df_inode.
The following patch
Package: distcc
Version: 2.18.1-5
Severity: normal
On one machine (NIS server), apt-get --purge remove distcc fails:
# apt-get remove distcc
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
distcc*
The usage section of amtoc(8) suggests:
amdump DailySet1 ; logdir=`amgetconf DailySet1 logdir` ;
log=`ls -1t $logdir/log.*.[0-9] | head -1` ; amtoc -a $log
This doesn't work as the START taper lines are in the log files
amdump.* only, not in the log.* files.
Hmmm, seems it wasn't a SW
Package: amanda-server
Version: 1:2.4.4p3-2
Severity: minor
The usage section of amtoc(8) suggests:
amdump DailySet1 ; logdir=`amgetconf DailySet1 logdir` ;
log=`ls -1t $logdir/log.*.[0-9] | head -1` ; amtoc -a $log
This doesn't work as the START taper lines are in the log files
Package: apt-proxy
Version: 1.9.26
Severity: minor
Tags: patch
Currently, the /etc/init.d/apt-proxy stop may do some output without
closing bracket:
root:/etc/init.d# ./apt-proxy restart
Stopping apt-proxy [wait 2.
Starting apt-proxy.
Additionally, the script *always*
Package: apt-proxy
Version: 1.9.25
Followup-For: Bug #294626
As python-twisted is only suggesting python-profiler, the package
apt-proxy has to depend on python-profiler, as apt-proxy refuses
to work otherwise.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990,
Package: apt-proxy
Version: 1.9.25
Followup-For: Bug #284432
The problem with the logrotate script is, that /etc/init.d/apt-proxy
doesn't wait on stop resp. restart until the apt-proxy server
really died before starting the new one.
If the old one didn't yet terminate, the new one won't start
Package: apt-proxy
Version: 1.9.25
Followup-For: Bug #284432
Additionally to the previous patch, now
- no sleep anymore at restart between stop and start
- no error message of cat $pidfile in case apt-proxy restart
or apt-proxy stop is called when apt-proxy is already stopped
(and so pidfile
Hi Ludovic,
On Wednesday 09 February 2005 00:32, Ludovic Drolez [EMAIL PROTECTED] wrote:
Herbert Thielen wrote:
[...]
Using this account, it may be possible to access files on the backuppc
host.
No, by default backuppc, backups /etc as user backuppc so no sensible files
are backuped
Reopened the bug as it's not mandatory to use wwwconfig-common, is it?
For the latter package, there's already a bug to support conf.d:
#237292 wwwconfig-common: Support apache conf.d
Until this is available, other mechanisms could be used, as it's done by
e.g. egroupware, phpgroupware,
Package: ddd
Version: 1:3.3.9-3
Severity: minor
ddd suggests a package bashdb which seems to be unavailable.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-k7
Locale: [EMAIL
Package: backuppc
Version: 2.1.0-8
Severity: important
After removing the package backuppc (purged), the line
Include /etc/backuppc/apache.conf
was left over in /etc/apache2/httpd.conf.
Due to this, apache2 failed to restart the next time (e.g. at next
reboot):
#
Package: backuppc
Version: 2.1.0-8
Severity: important
Backuppc installs a default Web account.
Probably this web account often won't be changed; maybe the admin just
has installed the package to try it at some time later.
Using this account, it may be possible to access files on the backuppc
Package: backuppc
Version: 2.1.0-8
Severity: normal
Currently backuppc adds (after asking the admin) a line to
/etc/apache2/httpd.conf
Instead, it should create a symlink in /etc/apache2/conf.d
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing'),
20 matches
Mail list logo
