Bug#765000: Was helpful for me...

[Fabien C.]

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

auto eth2
iface eth2 inet manual

auto eth3
iface eth3 inet manual

auto br0
iface br0 inet static
 bridge_ports eth0 eth1

auto br1
iface br0 inet static
 bridge_ports eth2 eth3



If it can be of any help... 

I feel like this /etc/network/interfaces way of configuring the network is
getting old, less and less appropriate as time goes on.

Fabien 

Bug#319832: bridge-utils: cannot handle more than one stanza in /etc/network/interfaces

[Fabien C.]

Sorry, my last message was supposed to be sent to bug #765000...

Bug#319832: bridge-utils: cannot handle more than one stanza in /etc/network/interfaces

[Fabien C.]

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

auto eth2
iface eth2 inet manual

auto eth3
iface eth3 inet manual

auto br0
iface br0 inet static
 bridge_ports eth0 eth1

auto br1
iface br0 inet static
 bridge_ports eth2 eth3



If it can be of any help... 

I feel like this /etc/network/interfaces way of configuring the network is
getting old, less and less appropriate as time goes on.

Fabien 

Bug#671831: gnome-screenshot: main window never appears; can't save/copy screenshots

[Fabien C.]

Hello,

I have almost the same bug here: press the screenshot keyboard button,
screen flashes, shutter noise, but no screenshot is saved.

BUT, I'm using Gnome in _Classic_ mode, NOT Gnome Shell default interface.

If I type "gnome-screenshot" from terminal, my error message is slightly
different:


** (gnome-screenshot:6160): WARNING **: Unable to use GNOME Shell's
builtin screenshot interface, resorting to fallback X11. Error:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.Shell was not provided by any .service files


Creating a ~/Pictures folder did not fix it. I searched my whole home
directory for recently modified files, but found no screenshot image.

The only alternative I found is using "gnome-screenshot --interactive"
but it is pretty cumbersome.


EDIT: apparently, using dconf-editor, then going to org > gnome >
gnome-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 Michael Biebl  wrote:
> Unfortunately, this is not a bug, but a "feature", i.e. a change made by
> upstream. gnome-screenshot no longer shows the save dialog, but simply
> saves the screenhot in ~/Pictures.
> 
> Personally, I'm not a fan of this particular upstream change.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717488: [Pkg-sysvinit-devel] Bug#717488: Please always launch /etc/init.d/ups-monitor when halting the system

[Fabien C.]

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 CPU. I think the 
*only* thing it does not is cut the power, but the system is already ready to
lose it.  

> I would have to put some effort to recall all the trouble we had in the past
> to access whether we can support this proposed change, though.
 
You are probably referring to this discussion, which I read:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358696  

Well, we could make it an option if you think it is not a good idea to have it
as default. 

> What is important is that we must not break the sane scenario, where you
> have the box properly configured to always power up on power restore, and
> the UPS configured to always cycle the load once the load (i.e. us) signals
> that it is past the point of no return (i.e. that it will require a power
> cycle to restart -- in Debian, that pretty much means as soon as we switch
> to runlevel 0).

I don't think "always power up on power restore" is a "properly configured" 
box. If a box is off, that is very probably for a good reason, and I *don't*
want it to power up based on some random event like power outage... What the 
"normal" people want is to get back to the state the machines were before the
power problem occured, no more, no less. That is restore last power state.

Any other configuration could lead to problems (like IP conflicts, too much
power consumption, etc.)

> Also, shutdown -H must NOT issue a UPS power off command [by default], it is
> documented to not do it.

We make the documentation, don't we? 

Also, I would add that /etc/init.d/ups-monitor does *not* cut the power off if 
the UPS is not running on battery. 

But once again, we could make it an option. 

Fabien


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717488: Please always launch /etc/init.d/ups-monitor when halting the system

[Fabien C.]

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/2013 23:26, Roger Leigh wrote:
> On Sun, Jul 21, 2013 at 01:23:28PM +0200, Fabien C. wrote:
>> please launch "/etc/init.d/ups-monitor poweroff" everytime /etc/init.d/halt 
>> is 
>> called, not only when INIT_HALT=POWEROFF. 
>>
>> The current script forbids that behavior because if INIT_HALT is not equal 
>> to 
>> POWEROFF, which is "unfortunately" the case with "shutdown -Hh", then 
>> /etc/init.d/ups-monitor is *never* called. 
> 
> While this change sounds reasonable, I'm not personally aware of the
> reason for the current logic.  Is changing this going to break
> anything?  Why is it currently the way it is?
> 
> 
> Regards,
> Roger
> 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717488: Please always launch /etc/init.d/ups-monitor when halting the system

[Fabien C.]

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 power.
-	if [ "$INIT_HALT" = "POWEROFF" ] && [ -x /etc/init.d/ups-monitor ]
+	if [ -x /etc/init.d/ups-monitor ]
 	then
 		/etc/init.d/ups-monitor poweroff
 	fi

Bug#717488: Please always launch /etc/init.d/ups-monitor when halting the system

[Fabien C.]

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 "shutdown -h +0", to something like "shutdown -Hh +0" 
(see /etc/nut/upsmon.conf). This could be done so that the machine does 
poweroff the disks and stop the system, but does *not* cut the power off, 
waiting for the UPS to do so. This is nice when your BIOS is configured to 
restore the last power state before the power went down: "On/Off state: Last 
state". 

The current script forbids that behavior because if INIT_HALT is not equal to 
POWEROFF, which is "unfortunately" the case with "shutdown -Hh", then 
/etc/init.d/ups-monitor is *never* called. 

Thank you. 


-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
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 initscripts depends on:
ii  coreutils   8.13-3.5
ii  debianutils 4.3.2
ii  libc6   2.13-38
ii  lsb-base4.1+Debian8+deb7u1
ii  mount   2.20.1-5.3
ii  sysv-rc 2.88dsf-41
ii  sysvinit-utils  2.88dsf-41

Versions of packages initscripts recommends:
ii  e2fsprogs  1.42.5-1.1
pn  psmisc 

initscripts suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl

[Fabien C.]

Hello, 

I think Ismaël has a point here: 

> I'm bumping this bug to point out that the problem is not 100% fixed.
> Even though "su -c" is now safe, interactive "su" or "su -" are still at
> risk and this should probably be reflected here on the BTS.

I successfully used this on my up-to-date Squeeze 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. 


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#696563: [Pkg-openldap-devel] Bug#696563: slapd not ready when start script exits, plase add sleep in starting script

[Fabien C.]

Hello,

> I suggest reading followup #2 in
> , 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:
---
> Some distros already deal with this in other ways - e.g. OpenSuSE waits
> until an ldapsearch on the null DN succeeds. This is done in the init.d
> script.

This is still by far the best solution. [...]
---

Maybe we could try this?

> The real solution is to switch to back-mdb from back-bdb/hdb, which
> doesn't have the heavy startup load that BDB based backends do.

Is that a real solution? I mean:
 - does it *guarantee* any result?
 - is it a good idea to restrict the user within this kind of choice?

Fabien


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#696563: slapd not ready when start script exits, plase add sleep in starting script

[Fabien C.]

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 meanwhile is a good thing, especially when it takes 2 minutes to
be done.

Then, we can try to find and correct the *source* of the problem, fixing
it and remove the ugly workaround.

Still better than discussing a long time about how and why it went wrong
while everyone still uses "quite frequently" buggy software, IMHO.

> We need to find
> out why the parent slapd process is again exiting before it's ready to
> listen for connections - this is a regression, for a bug that was very
> specifically supposed to have been fixed upstream in 2.4.28.  See bug
> #589915 for the history.
> 
> The source files that were being patched for this haven't changed upstream
> since 2.4.28, so I'm not sure what will have gone wrong.

According to what you say, Squeeze should never have had this issue. Did
anyone check if the fix on 2.4.28 was ever really efficient?

Also, I'm not sure if this is relevant, but I don't use the Squeeze
provided dhcp-server. Yet the init scripts sequence starts it after
slapd in the boot dependency order (S02 slapd, S03dhcp if I remember well).

Fabien


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#696563: slapd not ready when start script exits, please add sleep in starting

[Fabien C.]

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 have 
my DHCP server (isc-dhcp-server) starting, and the dhcp configuration 
configuration is within the local LDAP tree. But, on bootup, dhcp fails to 
start because it cannot connect to the LDAP server: 

---
dhcpd: Error: Cannot login into ldap server localhost:389: Can't contact LDAP 
server
dhcpd: Configuration file errors encountered -- exiting
[...]
dhcpd: exiting
---

Of course, everything works if I just try to start dhcp manually after bootup. 

It is probably necessary to add in the /etc/init.d/slapd script, either a 
"sleep 2" or more, either a detection of the "readyness" of the slapd daemon. 
One could also patch the slapd server, so it could handle this situation 
itself. 


--- a/slapd 2012-05-30 04:41:07.0 +0200
+++ b/slapd 2012-11-13 15:05:46.194599093 +0100
@@ -146,6 +146,8 @@ start_slapd() {
if [ ! -h /var/run/ldapi ] && [ ! -e /var/run/ldapi ] ; then
ln -s slapd/ldapi /var/run/ldapi
fi
+
+   sleep 2
 }
 
 # Stop the slapd daemon and capture the error message (if any) to



Thank you, 
Fabien 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#696563: slapd not ready when start script exits, plase add sleep in starting script

[Fabien C.]

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 configuration 
configuration is within the local LDAP tree. But, on bootup, dhcp fails to 
start because it cannot connect to the LDAP server: 

---
dhcpd: Error: Cannot login into ldap server localhost:389: Can't contact LDAP 
server
dhcpd: Configuration file errors encountered -- exiting
[...]
dhcpd: exiting
---

Of course, everything works if I just try to start dhcp manually after bootup. 

It is probably necessary to add in the /etc/init.d/slapd script, either a 
"sleep 2" or more, either a detection of the "readyness" of the slapd daemon. 
One could also patch the slapd server, so it could handle this situation 
itself. 


--- a/slapd 2012-05-30 04:41:07.0 +0200
+++ b/slapd 2012-11-13 15:05:46.194599093 +0100
@@ -146,6 +146,8 @@ start_slapd() {
if [ ! -h /var/run/ldapi ] && [ ! -e /var/run/ldapi ] ; then
ln -s slapd/ldapi /var/run/ldapi
fi
+
+   sleep 2
 }
 
 # Stop the slapd daemon and capture the error message (if any) to


Thank you, 
Fabien 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#690043: package version does not match src version in php_svn.h (0.6.0-dev)

[Fabien C.]

Package: php5-svn
Version: 1.0.0-1
Severity: normal

Hello, 

there is a difference between the version number of this package (1.0.0-1), and 
the version number the svn module reports within it's code (0.6.0-dev). 

The "svn extension version" can be seen within a phpinfo() page, or withing 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
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages php5-svn depends on:
ii  libapr11.4.2-6+squeeze4  The Apache Portable Runtime Librar
ii  libc6  2.11.3-4  Embedded GNU C Library: Shared lib
ii  libsvn11.6.12dfsg-6  Shared libraries used by Subversio
ii  php5-cli [phpapi-20090 5.3.3-7+squeeze14 command-line interpreter for the p
ii  ucf3.0025+nmu1   Update Configuration File: preserv

php5-svn recommends no packages.

php5-svn suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#590641: isc-dhcp-server: DHCP server fails to start if the subnet is not the primary subnet for a device.

[Fabien C.]

Severity: important 
thanks


Hello, 

I confirm this bug is still present on Squeeze. 


# ip addr show 

10: br0:  mtu 1500 qdisc noqueue state UP 
link/ether 00:08:a1:95:f0:3b brd ff:ff:ff:ff:ff:ff
inet 10.3.5.1/24 brd 10.3.5.255 scope global br0
inet 192.168.5.1/24 scope global br0



Problem: 


 No subnet declaration for br0 (10.3.5.1).
 ** Ignoring requests on br0.  If this is not what
you want, please write a subnet declaration
in your dhcpd.conf file for the network segment
to which interface br0 is attached. **

 Not configured to listen on any interfaces!


But I have a subnet declaration for 192.168.5.1 : 


subnet 192.168.5.0 netmask 255.255.255.0
{
...
}



Trying to add a label to the interface and launch dhcpd on this labeled 
interface like this doesn't resolve 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
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#666515: segfault when changing/renaming RDN (DN=) with an "audio" attribute

[Fabien C.]

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"), the "Rename
Entry" popup appears: "Please enter the new RDN of the selected entry" [0]. I
change the entry type from "cn", to "audio" (or "jpegImage"). I get a segfault
from slapd.

The entry I used was objectClass: inetOrgPerson, organizationalPerson and 
person.

Here is my syslog output :

[...]
log lines not relative to the segfault
[...]
Mar 30 15:19:44 toto slapd[2214]: => access_allowed: read access granted by
write(=wrscxd)
Mar 30 15:19:44 toto slapd[2214]: => acl_mask: access to entry "cn=Foo Bar
Normal,ou=addressBook,dc=X,dc=null", attr "uid" requested
Mar 30 15:19:44 toto slapd[2214]: => acl_mask: to value by
"cn=admin,dc=X,dc=null", (=0)
Mar 30 15:19:44 toto slapd[2214]: <= check a_dn_pat: 
cn=admin,dc=X,dc=null
Mar 30 15:19:44 toto slapd[2214]: <= acl_mask: [1] applying write(=wrscxd) 
(stop)
Mar 30 15:19:44 toto slapd[2214]: <= acl_mask: [1] mask: write(=wrscxd)
Mar 30 15:19:44 toto slapd[2214]: => slap_access_allowed: read access granted by
write(=wrscxd)
Mar 30 15:19:44 toto slapd[2214]: => access_allowed: read access granted by
write(=wrscxd)
Mar 30 15:20:00 toto kernel: slapd[2361]: segfault at 70 ip 0044c385 sp
7fa1a0259920 error 4 in slapd[40+12a000]

This is reproducible.


[0] http://imagepaste.nullnetwork.net/viewimage.php?id=3601


-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.4 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages slapd depends on:
ii  adduser3.112+nmu2add and remove users and groups
ii  coreutils  8.5-1 GNU core utilities
ii  debconf [debconf-2.0]  1.5.36.1  Debian configuration management sy
ii  libc6  2.11.3-3  Embedded GNU C Library: Shared lib
ii  libdb4.8   4.8.30-2  Berkeley v4.8 Database Libraries [
ii  libgnutls262.8.6-1+squeeze2  the GNU TLS library - runtime libr
ii  libldap-2.4-2  2.4.23-7.2OpenLDAP libraries
ii  libltdl7   2.2.6b-2  A system independent dlopen wrappe
ii  libperl5.105.10.1-17squeeze3 shared Perl library
ii  libsasl2-2 2.1.23.dfsg1-7Cyrus SASL - authentication abstra
ii  libslp11.2.1-7.8 OpenSLP libraries
ii  libwrap0   7.6.q-19  Wietse Venema's TCP wrappers libra
ii  lsb-base   3.2-23.2squeeze1  Linux Standard Base 3.2 init scrip
ii  perl [libmime-base64-p 5.10.1-17squeeze3 Larry Wall's Practical Extraction
ii  psmisc 22.11-1   utilities that use the proc file s
ii  unixodbc   2.2.14p2-1ODBC tools libraries

Versions of packages slapd recommends:
ii  libsasl2-modules  2.1.23.dfsg1-7 Cyrus SASL - pluggable authenticat

Versions of packages slapd suggests:
ii  ldap-utils2.4.23-7.2 OpenLDAP utilities

-- Configuration Files:
/etc/default/slapd changed:
SLAPD_USER="openldap"
SLAPD_GROUP="openldap"
SLAPD_PIDFILE=
SLAPD_SERVICES="ldap:/// ldapi:///"
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd
SLAPD_OPTIONS=""

-- debconf information:
  slapd/password_mismatch:
  slapd/tlsciphersuite:
  slapd/fix_directory: true
  slapd/invalid_config: true
* shared/organization: X
  slapd/upgrade_slapcat_failure:
  slapd/slurpd_obsolete:
  slapd/upgrade_slapadd_failure:
* slapd/backend: BDB
* slapd/dump_database: when needed
* slapd/allow_ldap_v2: false
* slapd/no_configuration: false
  slapd/migrate_ldbm_to_bdb: false
  slapd/move_old_database: true
  slapd/suffix_change: false
  slapd/slave_databases_require_updateref:
* slapd/dump_database_destdir: /var/backups/slapd-VERSION
  slapd/autoconf_modules: true
* slapd/purge_database: false
* slapd/domain: X.null




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#655364: Server doesn't read LDAP conf correctly

[Fabien C.]

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 old dhcp server (v3.0.5) compiled with the ldap patch. The 
schema was inserted into the LDAP server when the DHCP server was compiled, so 
it may be a bit old (and custom?...)

I tried using the server from Squeeze instead, and it didn't work : 
 No subnet declaration for eth0
 [...]
 Not configured to listen on any interfaces!

It seems that the DHCP server now needs a subnet declaration, despite the LDAP 
configuration, whatever, I added this in dhcpd.conf: 
 subnet 10.3.0.0 netmask 255.255.0.0
  ==> Listening on LPF/eth0/... (good, it starts listening)

I launched wireshark to see that it couldn't get it's config: 
 LDAPMessage searchRequest(4) "cn=DHCP Service 
Config,conf=Dhcp,ou=City,ou=Servers,dc=mycompany,dc=com" singleLevel 
 Filter: 
(!(|(|(objectClass=dhcpTSigKey)(objectClass=dhcpClass))(objectClass=dhcpFailOverPeer)))
  ==> LDAPMessage searchResDone(4) success (value does not conform to assertion 
syntax) [0 results]

It founds the dhcpServiceDN attribute correctly (thanks to the "ldap-base-dn" 
option in dhcpd.conf) which is [cn=DHCP Service Config,...], but then...

The subnets and hosts configuration is within the subtree (cn=DHCP Service 
Config,...) but the request returns 0 result because of the filter. I have no 
dhcpTSigKey, dhcpClass or dhcpFailOverPeer in my subtree. The first son of 
[cn=DHCP Service Config,...] is a dhcpSharedNetwork one (as explained in the 
package file /usr/share/doc/isc-dhcp-server-ldap/README.ldap.gz). 

The DHCP server version from Sid however (v. 4.2.2-2) doesn't use such a filter 
(it uses objectClass=*)  and it manages to read the configuration properly 
(according to wireshark, but I didn't tested further though). 

Do you know where the problem comes from?

Thank you, 
Fabien 


PS: You can find the problematic filter on line 1772 of 
dhcp-4.1.0-ldap-code.dpatch within the source pkg. 


-- System Information:
Debian Release: 6.0.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages isc-dhcp-server-ldap depends on:
ii  debianutils 3.4  Miscellaneous utilities specific t
ii  isc-dhcp-common 4.1.1-P1-15+squeeze3 common files used by all the isc-d
ii  isc-dhcp-server 4.1.1-P1-15+squeeze3 ISC DHCP server for automatic IP a
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libldap-2.4-2   2.4.23-7.2   OpenLDAP libraries
ii  libssl0.9.8 0.9.8o-4squeeze4 SSL shared libraries

isc-dhcp-server-ldap recommends no packages.

isc-dhcp-server-ldap suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#651912: Re: sandboxing-related renderer crash ("Aw, snap") when loading NSS modules

[Fabien C.]

> 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 "Aw, 
Snap!" problem. The workaround you gave has been working so far (from 
v14 to v16), thank you! 

Still, I don't exactly understand what bug is this, and why it has been
triggered by a Debian patch.

Has anyone been explaining it with words? ;) 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#647992: chromium 14 broken with libnss3-1d from sid

[Fabien C.]

> 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 couldn't you use the --no-sandbox option instead? 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#648904: Kid3 doesn't handle UTF-8 properly with ID3v2 tags despite configuration

[Fabien C.]

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 debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#648904: Kid3 doesn't handle UTF-8 properly with ID3v2 tags despite configuration

[Fabien C.]

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 "Text encoding" option for ID3v1 is working ok.

To reproduce :
If you do not have a mp3 with an ID3v2 tag encoded with UTF-8, you can use the
"id3v2" tool (packaged as "id3v2") to make one.

Provided that your console is using with UTF-8, you may add a utf8 comment to an
existing mp3 file like this :
 id3v2 -c "Bonne journée" myaudiofile.mp3

Then, the "é" character will not be displayed correctly with kid3, regardless of
what you charset configured to handle your tags (I have "Bonne journée" 
instead).

-- System Information:
Debian Release: 6.0.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.1 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kid3 depends on:
ii  kdebase-runtime   4:4.4.5-1  runtime components from the offici
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libflac++61.2.1-2+b1 Free Lossless Audio Codec - C++ ru
ii  libflac8  1.2.1-2+b1 Free Lossless Audio Codec - runtim
ii  libgcc1   1:4.4.5-8  GCC support library
ii  libid3-3.8.3c2a   3.8.3-13   A library for manipulating ID3v1 a
ii  libkdecore5   4:4.4.5-2+squeeze3 the KDE Platform Core Library
ii  libkdeui5 4:4.4.5-2+squeeze3 the KDE Platform User Interface Li
ii  libkio5   4:4.4.5-2+squeeze3 the Network-enabled File Managemen
ii  libogg0   1.2.0~dfsg-1   Ogg bitstream library
ii  libqt4-dbus   4:4.6.3-4+squeeze1 Qt 4 D-Bus module
ii  libqt4-network4:4.6.3-4+squeeze1 Qt 4 network module
ii  libqt4-svg4:4.6.3-4+squeeze1 Qt 4 SVG module
ii  libqt4-xml4:4.6.3-4+squeeze1 Qt 4 XML module
ii  libqtcore44:4.6.3-4+squeeze1 Qt 4 core module
ii  libqtgui4 4:4.6.3-4+squeeze1 Qt 4 GUI module
ii  libstdc++64.4.5-8The GNU Standard C++ Library v3
ii  libtag1c2a1.6.3-1TagLib Audio Meta-Data Library
ii  libtunepimp5  0.5.3-7.3  MusicBrainz tagging library
ii  libvorbis0a   1.3.1-1The Vorbis General Audio Compressi
ii  libvorbisfile31.3.1-1The Vorbis General Audio Compressi

kid3 recommends no packages.

kid3 suggests no packages.

-- no debconf information



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#647992: same bug on chromium 14 backport on squeeze

[Fabien C.]

* 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 with the --single-process or --no-sandbox 
options. 

Then, I guess this bug does not come from chromium 15, but was already present 
in some way in version 14. 

We tried to identify the bug without success due to a lack of time and/or 
knowledge. 

You can follow our discussion here : 
http://lists.alioth.debian.org/pipermail/pkg-chromium-maint/2011-October/001508.html
 

Fab 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#645838: Exiftran exits on fchown() error

[Fabien C.]

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 processed the image(s). 

reproduce with: 'exiftran -ai *.jpg' (on a FAT fs for example) 

Thanks.

-- System Information:
Debian Release: 6.0.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.4 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages exiftran depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libexif12 0.6.19-1   library to parse EXIF files
ii  libjpeg62 6b1-1  The Independent JPEG Group's JPEG 

exiftran recommends no packages.

exiftran suggests no packages.

-- no debconf information
--- fbi-2.07/jpegtools.c	2006-06-13 14:47:24.0 +0200
+++ fbi-2.07_patched/jpegtools.c	2011-10-19 01:42:59.498275393 +0200
@@ -570,18 +570,16 @@ int jpeg_transform_inplace(char *file,
 }
 out = fdopen(fd,"w");
 
-/* copy owner and permissions */
+/* copy owner and permissions (if possible with the filesystem) */
 if (-1 == fstat(fileno(in),&st)) {
 	fprintf(stderr,"fstat(%s): %s\n",file,strerror(errno));
 	goto oops;
 }
 if (-1 == fchown(fileno(out),st.st_uid,st.st_gid)) {
 	fprintf(stderr,"fchown(%s): %s\n",tmpfile,strerror(errno));
-	goto oops;
 }
 if (-1 == fchmod(fileno(out),st.st_mode)) {
 	fprintf(stderr,"fchmod(%s): %s\n",tmpfile,strerror(errno));
-	goto oops;
 }
 
 /* transform */

Bug#618691: Segfault with "icedove -mail nntp://"

[Fabien C.]

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, 'squeeze-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages icedove depends on:
ii  debianutils3.4   Miscellaneous utilities specific t
ii  fontconfig 2.8.0-2.1 generic font configuration library
ii  libasound2 1.0.23-2.1shared library for ALSA applicatio
ii  libatk1.0-01.30.0-1  The ATK accessibility toolkit
ii  libc6  2.11.2-10 Embedded GNU C Library: Shared lib
ii  libcairo2  1.8.10-6  The Cairo 2D vector graphics libra
ii  libdbus-1-31.2.24-4  simple interprocess messaging syst
ii  libfontconfig1 2.8.0-2.1 generic font configuration library
ii  libfreetype6   2.4.2-2.1 FreeType 2 font engine, shared lib
ii  libgcc11:4.4.5-8 GCC support library
ii  libglib2.0-0   2.24.2-1  The GLib library of C routines
ii  libgtk2.0-02.20.1-2  The GTK+ graphical user interface
ii  libjpeg62  6b1-1 The Independent JPEG Group's JPEG
ii  libnspr4-0d4.8.6-1   NetScape Portable Runtime Library
ii  libnss3-1d 3.12.8-1  Network Security Service libraries
ii  libpango1.0-0  1.28.3-1+squeeze2 Layout and rendering of internatio
ii  libpng12-0 1.2.44-1  PNG library - runtime
ii  libsqlite3-0   3.7.3-1   SQLite 3 shared library
ii  libstartup-notificatio 0.10-1library for program launch feedbac
ii  libstdc++6 4.4.5-8   The GNU Standard C++ Library v3
ii  libx11-6   2:1.3.3-4 X11 client-side library
ii  libxrender11:0.9.6-1 X Rendering Extension client libra
ii  libxt6 1:1.0.7-1 X11 toolkit intrinsics library
ii  psmisc 22.11-1   utilities that use the proc file s
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime

Versions of packages icedove recommends:
ii  myspell-en-us [myspell-dictio 1:3.2.1-2  English_american dictionary for my
ii  myspell-fr-gut [myspell-dicti 1:1.0-27   The French dictionary for myspell

Versions of packages icedove suggests:
ii  libdbus-glib-1-20.88-2.1 simple interprocess messaging syst
ii  libgconf2-4 2.28.1-6 GNOME configuration database syste
ii  libgnome2-0 2.30.0-1 The GNOME library - runtime files
ii  libgnomevfs2-0  1:2.24.3-1   GNOME Virtual File System (runtime
ii  libgssapi-krb5-21.8.3+dfsg-4 MIT Kerberos runtime libraries - k
ii  ttf-lyx 1.6.7-1  TrueType versions of some TeX font

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#614256: Add workaround for slow transitioning CPUs

[Fabien C.]

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

Bug#616023: Don't put temporary file acpi_fakekey in /dev/shm

[Fabien C.]

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
instead?

Thanks!

-- 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.2 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages acpi-fakekey depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib

acpi-fakekey recommends no packages.

acpi-fakekey suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#613203: audacious: High CPU usage with snd_hda_intel based soundcard

[Fabien C.]

> 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
> (http://hg.atheme.org/release/audacious-plugins-2.4.x/release/audacious-plugins-2.4.x/rev/974307743be7)
> that should eliminate the high CPU usage.

Well, once again it seems that from both sides, it's the other side's fault.

According to comments in ALSA's bugtracker
(https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5278), audacious:
 - does "not calculate the correct buffer size"
 - does not write any data by snd_pcm_writei() or snd_pcm_commit() to the sound
card in alsa_write_audio()

Where are you xmms v1? :)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#614256: Add workaround for slow transitioning CPUs

[Fabien C.]

> 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? Contact listmas...@lists.debian.org

Bug#614256: Add workaround for slow transitioning CPUs

[Fabien C.]

>> 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
>> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:109000
>>
>> And on my (nice) Intel system, I got these:
>> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:1
>> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate_min:1
>> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:1
> 
> the concept is that it makes no sense to sample cpu usage _while_
> stepping the cpu frequency and with sampling_rate set to the minimum it
> will happen 10 times.

>> Here are my results in GB/s (several averages) for the AMD CPU:
...
> but this looks really awful in terms of powersaving.

Why? Because sampling often is power consuming?

Then what about my Intel CPU which runs at nearly the same max freq and is
sampling at 1 by default? The AMD cpu samples at around 109000 by default
when it could sample 10 times more at 10900, like with the Intel one.

I think this is about finding the balance between user expectations and power
usage (kernel developers wrote that AMD latency for changing freq is really 
bad).

> What about the ignore_nice_load and io_is_busy values?
> the latter should be 0 for you on AMD.

It is.

> /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load:0
> /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy:1
> 
> Any better results tweaking these?

No. io_is_busy makes no real difference whether it is set to 1 or 0. Didn't
tweek ignore_nice_load though as it shouldn't change the deal IMHO.

> Are you sure your results aren't faked by something else going on and
> stepping the cpu to a higer frequency?

Pretty sure, even if the mesured values may not be really accurate (I got
slighly lower values today). What I can't doubt however is that there is a real
perf difference when the workaround is used: it's always better.

> it looks useful. It would be nice to make it more generic at this point
> and allow tweaking all the values if they are available for the selected
> governor.

I agree, but let's use this for good's sake before working for betterness' sake 
;)

> I think the issue should be reported to the cpufreq development mailing
> list if you have a case worth looking into. Independently of the patch
> to debian's init scripts.

I agree.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#614256: Add workaround for slow transitioning CPUs

[Fabien C.]

Package: cpufrequtils
Version: 007-1
Severity: wishlist
Tags: patch

Hello,

Some CPUs (particularly from AMD) have a very high latency for frequency
changes. This is visible at the user level and can lead the user to change it's
cpufreq governor to performance, thus wasting energy.

This is particularly noticeable since Squeeze kernel is using the ondemand
governor by default, and cpufrequtils is configured the same way.

The following texte is taken from the kernel's description of the conservative
governor (drivers/cpufreq/Kconfig) :
-
[...] if you are using a laptop, PDA or even an AMD64 based computer (due to
the unacceptable step-by-step latency issues between the minimum and maximum
frequency transitions in the CPU) [...]
-

(The conservatice governor is recommended to smooth out the latency issues.
However this is bad for user experience (or server responsiveness) which needs
all CPU power for very short and specific periods of time (I want it all, and I
want it now!) as this governor takes not only its time to fall but also to rise
frequency. But anyway, even the ondemand gov performs poorly with some CPUs.)

I found that when possible, tweeking the sampling_frequency can get things
better or even good. I ran some tests on an impacted AMD cpu and compared some
sysfs values with an "Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz". Both were on
a 2.6.37 kernel (however this issue is quite old and I'm pretty sure older or
official Debian kernel wouldn't resolve the problem).

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
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:109000

And on my (nice) Intel system, I got these:
/sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:1
/sys/devices/system/cpu/cpufreq/ondemand/sampling_rate_min:1
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:1

First, it is strange to see that the default sampling on AMD is not the equal
to rate_min, considering that the Intel cpu has the same values everywhere.
Then we notice that the transition_latency is about 10 times worst on the AMD 
cpu.

I found that a simple 'cat sampling_rate_min >| sampling_rate' makes things
better. And that's what my workaround is all about.

For testing, I simply ran the following command and compared transfer rates
(GB/s):
dd if=/dev/zero of=/dev/null bs=300k count=1000

Or (using zsh) the following can give me an average rate on 50 samples:
moy=0 ; for val in `i=50 ; while [ $i -gt 0 ] ; do nice -n -19 dd if=/dev/zero
of=/dev/null bs=300k count=1000 2>&1 | tail -n 1 | awk '{print $8}' | sed
s/,/\./ ; sleep 0.5 ; i=$(($i-1)) ; done` ; do moy=$(($moy+$val)) ; done ; echo
$(($moy/50.))

Here are my results in GB/s (several averages) for the AMD CPU:
--
performance :
7.61 / 7.61 / 7.61 / 7.56 / 7.37

ondemand (no-tweaking) :
4.83 / 4.68 / 4.73 / 5.14 / 5.51 / 5.37

ondemand (sampling_rate = rampling_rate_min, i.e. default/10) :
7.00 / 7.07 / 7.03 / 7.06 / 7.02 / 7.01 / 7.04
--

Changing sampling_rate seems to be worth the patch. So my patch adds an option
to the init.d/cpufrequtils for tweeking sampling_rate (set it to the s_r_min)
if it detects a slow transitioning CPU.

It is not very intrusive because disabled by default, and even when enabled,
tries to detect a slow CPU before tweeking anything (safemode).

This said, having such a bad default sampling_rate may 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 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cpufrequtils depends on:
ii  debconf [debconf-2.0]   1.5.36.1 Debian configuration management sy
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libcpufreq0 007-1shared library to deal with the cp
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip

cpufrequtils recommends no packages.

cpufrequtils suggests no packages.

-- debconf information:
  cpufrequtils/enable: true

If you want to provide additional information, please wait to receive the bug
tracking number via email; you may then send any extra information to
n...@bugs.debian.org (e.g. 999...@bugs.debian.org), where n is the bug number.
Normally you will receive an acknowledgement via email including the bug report
number within an hour; if you haven't received a confirmation, then the bug
reporting process failed at some point (reportbug or MTA 

Bug#607329: cpufrequtils should use /etc/default

[Fabien C.]

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 debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#607329: cpufrequtils should use /etc/default

[Fabien C.]

As a user I would like to have this default conffile in /etc/default. I
did what Mattia thought would happen: looked into
/etc/init.d/cpufrequtils then went to /etc/default to tweek some
settings (change the init.d file is just not a good practice) and was
surprised not to find a default file with the config vars ready to be
customized.

I would have to copy/paste the good vars from the init.d script... And
yet, the file wouldn't be removed on package purge, letting an orphan
conffile in /etc. Sounds like a quick'n'dirty hack.

And it's much more surprising knowing that the mechanisms 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...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#613203: audacious: High CPU usage with snd_hda_intel based soundcard

[Fabien C.]

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 of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#613203: audacious: High CPU usage with snd_hda_intel based soundcard

[Fabien C.]

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 of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#613203: audacious: High CPU usage with snd_hda_intel based soundcard

[Fabien C.]

Package: audacious
Version: 2.3-2
Severity: important
Tags: upstream

CPU Usage is too high when playing audio files. Considering old bug reports and 
various internet sources, it seems to occur particularly with Intel HDA 
(snd_hda_intel) soundcards, the model I have on this box. 
On Intel Core2 CPU with "ondemand" governor (lowest freq.: 800Mhz) audacious 
consumes about 12 to 35-40% of CPU according to top while playing a file on a 
fresh Squeeze install. 
This behavior is apparently not new[*], and still it is not sure wheter it 
comes from a broken soundcard driver, alsa, or audacious. But other players do 
not have such behavior... 

The problem disappears if I change the ALSA Output plugin conf and manually 
select the PCM device as "front" (Front Speakers), but with this solution other 
apps are not able to play sound over audacious anymore. The soundcard is not 
available anymore for them. 

Anyway, while browsing the web[**] I found a workaround: 

Edit ~/.asoundrc and paste this resamplig stuff: 

pcm.!default {
  type plug
  slave.pcm {
type dmix
ipc_key 1024
slave {
   pcm "hw:0,0"
   rate 44100
}
  }
}
----

Strange enough? :)

Fabien C. 


[*]  Archived bugs about audacious CPU usage (mid-2009) : #533559, #532081, 
#588633 
[**] http://boards.audacious-media-player.org/viewtopic.php?f=1&t=193 

-- 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 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages audacious depends on:
ii  audacious-plugins  2.3+dfsg-1+b1 Base plugins for audacious
ii  dbus   1.2.24-4  simple interprocess messaging syst
ii  dbus-x11   1.2.24-4  simple interprocess messaging syst
ii  gtk2-engines-pixbuf2.20.1-2  Pixbuf-based theme for GTK+ 2.x
ii  libatk1.0-01.30.0-1  The ATK accessibility toolkit
ii  libaudclient2  2.3-2 audacious dbus remote control libr
ii  libaudcore12.3-2 audacious core engine library
ii  libaudid3tag2  2.3-2 audacious id3 tag manipulation lib
ii  libc6  2.11.2-10 Embedded GNU C Library: Shared lib
ii  libcairo2  1.8.10-6  The Cairo 2D vector graphics libra
ii  libdbus-1-31.2.24-4  simple interprocess messaging syst
ii  libdbus-glib-1-2   0.88-2.1  simple interprocess messaging syst
ii  libfontconfig1 2.8.0-2.1 generic font configuration library
ii  libfreetype6   2.4.2-2.1 FreeType 2 font engine, shared lib
ii  libglib2.0-0   2.24.2-1  The GLib library of C routines
ii  libgtk2.0-02.20.1-2  The GTK+ graphical user interface 
ii  libice62:1.0.6-2 X11 Inter-Client Exchange library
ii  libmcs10.7.1-1   Abstraction library to store confi
ii  libmowgli1 0.6.1-1   a high performance development fra
ii  libpango1.0-0  1.28.3-1+squeeze1 Layout and rendering of internatio
ii  libsm6 2:1.1.1-1 X11 Session Management library

Versions of packages audacious recommends:
ii  unzip 6.0-4  De-archiver for .zip files

audacious suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org