Don't know if this we'll help, but I was able to solve some problems with
bridges listed in /etc/network/interfaces by replacing "allow-hotplug" by
"auto".
All my interfaces are auto, like this (simplified here):
auto eth0
iface eth0 inet manual
auto eth1
iface eth1 inet manual
Sorry, my last message was supposed to be sent to bug #765000...
Don't know if this we'll help, but I was able to solve some problems with
bridges listed in /etc/network/interfaces by replacing "allow-hotplug" by
"auto".
All my interfaces are auto, like this (simplified here):
auto eth0
iface eth0 inet manual
auto eth1
iface eth1 inet manual
-screenshot, then editing the attribute auto-save-directory to
file:///tmp fixes the problem. Still a bug though as this attribute
was empty by default.
I'm on an up-to-date Wheezy:
- gnome-screenshot 3.4.1-1
- gnome-shell 3.4.2-7+deb7u1
Thanks,
Fabien C.
On Mon, 07 May 2012 21:03:56 +0200
On 26/07/2013 03:06, Henrique de Moraes Holschuh wrote:
It is basically not a good idea at all to cut power instead of issuing a
hardware shutdown command. Lots of stuff on server boxes get highly pissed
off if you just cut power.
Hmmm, shutdown -hH still shuts down the disks, and halts the
tags 717488 patch
thanks
Here is a patch to describe my bug report.
Thanks.
diff -urN a/etc/init.d/halt b/etc/init.d/halt
--- a/etc/init.d/halt 2012-10-15 19:30:41.0 +0200
+++ b/etc/init.d/halt 2013-07-21 20:03:17.840931573 +0200
@@ -33,7 +33,7 @@
fi
# See if we need to cut the
Well, I don't know. I guess it just wasn't logic enough to call ups-monitor
with the poweroff argument when the system INIT_HALT is not set to poweroff
itself...
Let's ask Arnaud and Laurent (nut maintainers) if they have more information on
the matter (cc).
Regards,
Fabien C.
On 21/07
Package: initscripts
Version: 2.88dsf-41
Severity: normal
Dear Maintainer,
please launch /etc/init.d/ups-monitor poweroff everytime /etc/init.d/halt is
called, not only when INIT_HALT=POWEROFF.
This is necessary because the user can customize the nut/upsmon shutdown
command, which default to
system.
However, one can use the following workaround to avoid giving root access:
# exec su baduser
However this is still problematic:
niceguy$ su
root$ exec su badguy
badguy$ ./exploit.pl
= the command is still launched by niceguy.
Not sure if a good solution exists...
Fabien C
Hello,
I suggest reading followup #2 in
http://www.openldap.org/its/index.cgi/?findid=6848, the upstream ITS
dealing with this. It is specifically noted that on a heavily loaded
system, this can still occur.
I think the part dealing with an actual solution is more interesting:
Package: slapd
Version: 2.4.31-1
Severity: normal
Tags: patch
Hello,
I noticed that during bootup, when the /etc/init.d/slapd script returns, the
LDAP server is not fully available. I noticed this because, right after, I have
my DHCP server (isc-dhcp-server) starting, and the dhcp
retitle 696563 slapd not ready when start script exits, please add sleep in
starting
thanks
[re-sending with text wrapping, sorry]
Hello,
I noticed that during bootup, when the /etc/init.d/slapd script returns, the
LDAP server is not fully available. I noticed this because, right after, I
Hello,
This is absolutely not an acceptable fix for this bug. A 'sleep' only
reduces the frequency of a race, it does not eliminate it.
Yes, I totally agree, it would only be a dirty workaround. However, when
the issue is complicated to fix, I think that reducing problem frequency
in the
the
code, in php-svn-1.0.0/svn-1.0.0/php_svn.h, line 31 :
#define PHP_SVN_VERSION 0.6.0-dev
I suppose this is a bug updstream because the 1.0.0 version available on
http://pecl.php.net/package/svn also show the 0.6.0-dev version.
Thanks,
Fabien C.
-- System Information:
Debian Release: 6.0.6
the problem:
ip addr add 192.168.5.1/24 label br0:1 broadcast 192.168.5.255 dev br0
-OR-
ifconfig br0:1 192.168.5.1/24
Then it would say:
dhcpd: No subnet declaration for br0:0 (no IPv4 addresses)
Thanks,
Fabien C.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
Package: slapd
Version: 2.4.23-7.2
Severity: high
Hello,
slapd segfaults when the RDN of the entry is changed for an attribute like,
audio or jpegImage.
With the Apache Directory Studio client, I double clicked on the cn=myentry
entry which is used in the RDN (dn=cn=myentry,dc=mydomain,dc=com),
Package: isc-dhcp-server-ldap
Version: 4.1.1-P1-15+squeeze3
Severity: normal
* Summary: I cannot use isc-dhcp-server-ldap from Squeeze with my LDAP
configuration. I have an old one (v. 3.0.5) working properly, and the one from
unstable (v. 4.2.2-2) working too.
--
Hello,
I used a quite
I'm kind of surprised that this only started happening with chromium
15, though --- chromium 14 should have already been affected. Do you
know what upgrade triggered this on your machine? Was it a chromium
upgrade or an nss one?
When I backported chromium 14 from Sid to Squeeze I had that
In sandbox.c, I would suppress chdir(), chroot() and chdir() calls in
SpawnChrootHelper(). I would also replace MoveToNewNamespaces() by
return true;. Running with no limit for core dumps would allow to get
a core file. Maybe this will give additional hints.
I may be wrong here, but
Thank you very much for this clarification Urs!
I would suggest calling this option Default text encoding then,
instead of Text encoding. This way, nobody could think changing this
would change the way ID3v2 tags are displayed.
Fabien
--
To UNSUBSCRIBE, email to
Package: kid3
Version: 1.4-1+b1
Severity: normal
Kid3 displays ID3v2 tags with the ISO-8859-1 charset even if it is configured to
use UTF-8 for these tags.
The configuration option can be found this way : Settings, Configure Kid3, Tags
tab, ID3v2 section, Text encoding option).
However, the
* This bug also occurs on chromium 14 backported on Squeeze.
Michael Gilbert and I have been making unofficial backports of Chromium (for
quite a long time), but since version 14, we couldn't get it to work, because
of the Aw, Snap! problem described here.
However the browser was working
Package: exiftran
Version: 2.07-6
Severity: normal
Tags: patch
Exiftran exits on fchown() error. This error occurs on filesystems which do
not support file ownership or permissions such as FAT.
It may still display an error message, but should not exit for such a tiny
problem, whithout having
Package: icedove
Version: 3.0.11-1+squeeze1
Severity: normal
Here is the self-explanatory problem:
$ icedove -mail nntp://
Segmentation fault
zsh: exit 139 icedove -mail nntp://
Thanks.
-- System Information:
Debian Release: 6.0
APT prefers squeeze-updates
APT policy: (500,
Hello,
This bug has been reported on the kernel bugtracker :
https://bugzilla.kernel.org/show_bug.cgi?id=30712
Fabien
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: acpi-fakekey
Version: 0.137-5
Severity: wishlist
I'm not sure whether it is normal to find a fifo file named acpi_fakekey in
/dev/shm or if it is here according to a Debian policy, but it bothers me :)
Would it be possible to move it to /tmp or /var/run or any more regular place
This is indeed a problem that has plagued Audacious on and off for
years. It is apparently a bug in ALSA's DMix resampler, though still no
one knows exactly what triggers it. Audacious 2.4.3 has a workaround
No, I meant that those numbers were really a power saving failure :)
Why?
Alright, let me add something like that (I may rename vaariables) on the
next upload.
No problem :)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Here is the bad guy:
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
Down freq: 1000MHz / Up freq: 2200MHz
/sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:109000
/sys/devices/system/cpu/cpufreq/ondemand/sampling_rate_min:10900
to handle such
a user modified conffile exist.
it's less than 10min of work. if you
don't want to do that, let me know and i'll prepare a patch.
Come on! If it's trivial as you say so Daniel, please propose something.
Thanks!
Fabien C.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
Plus Mattia is not against low priority debconf integration...
For now I won't fix this bug, in the future I may consider adding low
priority debconf questions to autogenerate the config file and keep
those questions away from users not interested in it.
--
To UNSUBSCRIBE, email to
be a kernel bug. What do
you think?
Fabien C.
-- System Information:
Debian Release: 6.0
APT prefers squeeze-updates
APT policy: (500, 'squeeze-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.37 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8
Hi John,
Thanks for the info, I should probably report a bug in ALSA in this
case, given the Warning message from the workaround patch...
Fabien C.
PS: Sorry for my first message broken wrapping.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
Here is the bugreport in the ALSA bugtracker:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5278
Oh, and I tested with the original Debian kernel as well, and it doesn't
change anything.
Fabien C.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
? :)
Fabien C.
[*] Archived bugs about audacious CPU usage (mid-2009) : #533559, #532081,
#588633
[**] http://boards.audacious-media-player.org/viewtopic.php?f=1t=193
-- System Information:
Debian Release: 6.0
APT prefers squeeze-updates
APT policy: (500, 'squeeze-updates'), (500, 'stable
35 matches
Mail list logo
