from:"Cyrille Chépélov"

Bug#855346: been hit with same

2017-11-21 Thread Cyrille Chépélov


|found|855346 1:52.4.0-1
fixed 855346 1:52.4.0-2~exp1


Greetings,

been hit with the same issue (GNOME 3.26 environment), and while I can't 
comment on what apparmor-ing was expected to achieve, the experimental 
version does fix the "can't open attachments" issue for me.


Thanks!

    -- Cyrille

Bug#879906: gnome-session: freezes after start when network is up but under captive portal

2017-11-02 Thread Cyrille Chépélov


Le 02/11/2017 à 12:55, Jeremy Bicha a écrit :

On Thu, Nov 2, 2017 at 2:12 AM, Cyrille Chépélov <cyri...@chepelov.org> wrote:

The bug is still reproducible under GNOME 3.26.1, under the exact same
conditions (including the Paris→Lyon TGV route), and so is the
(inconvenient) workaround.

Do you have network-manager-config-connectivity-debian installed?

it wasn't (indeed), and is installed now. My return trip is tomorrow 
night (now+36 hours); furthermore I'll test in a different environment 
tonight where this was reliably reproduced, and will report.


If confirmed, this could be downgraded into a UI rather than important 
bug. /Possibly/ one would need to take into account a user's lack of 
willingness to hit a Debian server at each unsuspend to still avoid 
freezing, but as far as I'm concerned this is promising.


Thanks for the trick!

    -- Cyrille

Bug#879906: gnome-session: freezes after start when network is up but under captive portal

2017-11-02 Thread Cyrille Chépélov


Followup-For: Bug #879906
Package: gnome-session
Version: 3.26.1-1

Dear Maintainer,

The bug is still reproducible under GNOME 3.26.1, under the exact same 
conditions (including the Paris→Lyon TGV route), and so is the 
(inconvenient) workaround.


Cheers,

    -- Cyrille


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable'), (400, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-session depends on:
ii  gnome-session-bin  3.26.1-1
ii  gnome-session-common   3.26.1-1
ii  gnome-settings-daemon  3.26.1-2
ii  gnome-shell    3.26.1-3

gnome-session recommends no packages.

Versions of packages gnome-session suggests:
ii  desktop-base  9.0.5
ii  gnome-keyring 3.20.1-1
ii  gnome-user-guide  3.26.1.1-1

Bug#879906: gnome-session: freezes after start when network is up but under captive portal

2017-10-27 Thread Cyrille Chépélov


Package: gnome-session
Version: 3.24.1-2
Severity: important

Dear Maintainer,

When starting a session with (wifi) network up **but** locked out of 
actual connectivity (a situation which happens in many "free" wifi spaces),
gnome-session will accept the logon, show a grey background with a mouse 
(but not the specified screen background) and sit idle.


Steps to reproduce:
  - purchase a return SNCF high-speed train ticket from Paris to Lyon
  - take the Paris→Lyon train
  - connect to their wifi ("_SNCF_WIFI_INOUI")
  - go to the captive portal page, and authenticate using your train 
ticket reference & name

  - when in Lyon, shut the laptop down entirely

  - sit down on the return train Lyon→Paris
  - start the laptop
  - attempt to log in.
 ** in background, Network-Manager will immediately reconnect to 
_SNCF_WIFI_INOUI, which will deny service (and lie over DNS) until the 
user has
    visited the captive portal and entered the train ticket 
reference & name
 ** user cannot visit as gnome-session will freeze (with mouse 
active) and not leave a chance to start a browser
 ** user cannot use links or another text-mode browser as the 
captive portal will reject it.


This situation can be reproduced in many similar settings, including 
cybercafes, airports, co-working spaces.


(annoying) Workaround:
   * start the laptop
   * switch to the text-mode console
   * "rfkill block" out the wifi interface
   * log into gnome-session
   * unblock the wifi, start firefox, log into the captive portal

Thanks in advance


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable'), (400, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-session depends on:
ii  gnome-session-bin  3.24.1-2
ii  gnome-session-common   3.24.1-2
ii  gnome-settings-daemon  3.24.3-1
ii  gnome-shell    3.22.3-3

gnome-session recommends no packages.

Versions of packages gnome-session suggests:
ii  desktop-base  9.0.5
ii  gnome-keyring 3.20.1-1
ii  gnome-user-guide  3.26.1.1-1

-- no debconf information
(END)

Bug#810817: gradle fails to install, because of circular dependency between maven core plugins

2016-01-12 Thread Cyrille Chépélov


Package: gradle
Version: 2.9-1
Severity: normal

Dear Maintainer,

While building Cascading (https://github.com/cwensel/cascading), gradle
fails to run the following task

  LC_ALL=en_US.UTF-8 gradle clean install -x test -x platformTest --stacktrace

(which works fine on Cascading's upstream CI suite), with the following
error message (abridged):

-
:cascading-core:install FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':cascading-core:install'.

Could not publish configuration 'archives'

   > org.codehaus.plexus.PlexusContainerException: Cycle detected in component 
graph in the system:

* Try:
Run with --info or --debug option to get more log output.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task 
':cascading-core:install'.
at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
at 
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
[ ]
Caused by: 
org.codehaus.plexus.component.composition.CycleDetectedInComponentGraphException:
 Cyclic requirement detected
at 
org.codehaus.plexus.component.composition.DefaultCompositionResolver.addComponentDescriptor(DefaultCompositionResolver.java:65)
at 
org.codehaus.plexus.component.repository.DefaultComponentRepository.addComponentDescriptor(DefaultComponentRepository.java:229)
at 
org.codehaus.plexus.DefaultComponentRegistry.addComponentDescriptor(DefaultComponentRegistry.java:126)
at 
org.codehaus.plexus.DefaultPlexusContainer.addComponentDescriptor(DefaultPlexusContainer.java:514)
at 
org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:969)
at 
org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:941)
at 
org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:560)
... 82 more
Caused by: org.codehaus.plexus.util.dag.CycleDetectedException:Edge between 
'Vertex{label='org.apache.maven.plugin.version.PluginVersionResolver:default'}' 
and 'Vertex{label='org.apache.maven.plugin.MavenPluginManager:default'}' 
introduces to cycle in the graph 
org.apache.maven.plugin.MavenPluginManager:default --> 
org.apache.maven.plugin.version.PluginVersionResolver:default --> 
org.apache.maven.plugin.MavenPluginManager:default

at org.codehaus.plexus.util.dag.DAG.addEdge(DAG.java:143)
at org.codehaus.plexus.util.dag.DAG.addEdge(DAG.java:123)
at 
org.codehaus.plexus.component.composition.DefaultCompositionResolver.addComponentDescriptor(DefaultCompositionResolver.java:60)
... 88 more


BUILD FAILED

--

gradle 2.9-1 from Debian pulls in maven 3.3.9

When downloading gradle 2.10 binaries from https://www.gradle.com, the build as 
specified above proceeds fine.
Gradle.com's binaries include maven 3.0.4, whereas the Debian package 
libgradle-plugins-java requires libmaven3-core-java (>= 3.3.3).

Thanks in advance

-- Cyrille


-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (950, 'stable'), (850, 'testing'), (800, 'unstable'), (500, 
'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gradle depends on:
ii  default-jre-headless [java7-runtime-headless]2:1.7-52
ii  libgradle-core-java  2.9-1
ii  libgradle-plugins-java   2.9-1
ii  openjdk-7-jre-headless [java7-runtime-headless]  7u91-2.6.3-1~deb8u1
ii  openjdk-8-jre-headless [java7-runtime-headless]  8u72-b05-2

gradle recommends no packages.


Other packages of interest:

ii  maven3.3.9-3
ii  libmaven3-core-java  3.3.9-3

Bug#807387: zookeeper: Hit by ZOOKEEPER-706

2015-12-08 Thread Cyrille Chépélov


Subject: zookeeper: Hit by ZOOKEEPER-706
Package: zookeeper
Version: 3.4.5+dfsg-2
Severity: normal
Tag: upstream fixed-upstream

Dear Maintainer,

In situations where a large number of watches are in place (such as when 
heavy YARN + heavy HBase traffic takes place on a moderately busy 
cluster), zookeeper session re-establishment can fail.


As a consequence, YARN ResourceManager fails to start after a fail-over 
situation, causing all sort of trouble down the line.


This has been identified and fixed upstream in 
https://issues.apache.org/jira/browse/ZOOKEEPER-706, which made it into 
release 3.4.7


As a workaround, I have been able to add this to /etc/zookeeper/zoo.cf:

   #
   # 2015-12-08 -- workaround for ZOOKEEPER-706
   # default is 0xf
   https://zookeeper.apache.org/doc/r3.3.2/zookeeperAdmin.html
   # got issues with lengths as big as 1820946
   jute.maxbuffer=4194303
   # 0x3f

Although the messages from ZOOKEEPER-1162 suggested deploying the 
jute.maxbuffer increase in both client and server side settings, adding 
that just to zoo.cfg seemed enough to clear proceed on my workload.


-- Cyrille

-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (950, 'stable'), (850, 'testing'), (800, 'unstable'), 
(500, 'stable-updates')

Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages zookeeper depends on:
ii  adduser  3.113+nmu3
ii  libzookeeper-java3.4.6-8
ii  openjdk-8-jre-headless [java6-runtime-headless]  8u45-b14-2

zookeeper recommends no packages.

zookeeper suggests no packages.

-- Configuration Files:
/etc/zookeeper/conf_example/myid changed [not included]
/etc/zookeeper/conf_example/zoo.cfg changed [not included]

-- no debconf information

Bug#804651: owncloud: renaming a folder can destroy all contained files

2015-11-16 Thread Cyrille Chépélov

Le 16/11/2015 13:45, David Prévot a écrit :
>
> Here's the output of cat access.log|cut -d " " -f 12- |sort |uniq
> "-"
> That doesn’t seem to contain any of the owncloud-client versions.
Aren't the "/mirall " records from owncloud-client? They seem to be
pretty close in versions  to the versions exhibited by the deployed
owncloud-client…

>
>>> Have you checked upstream issue tracker already for similar issues?
>> Yes, with no results.
> Looks like I’ve been more “lucky”. There are actually quite a lot of
> reports, in core and client issue tracker, many of them are referenced
> in [13391].
OK, great!


>
> It looks like upstream dealt with this issue by reducing time when
> updating the database [13948] and with proper locking [16237]. That is
> available in version 8 (8.2.1~~rc2~dfsg-1 already in people.d.o, and
> 8.2.1 final will probably be uploaded to experimental), but is not going
> to be handled in version 7 AFAICT.
>
> 13391: https://github.com/owncloud/core/issues/13391
> 13948: https://github.com/owncloud/core/pull/13948
> 16237: https://github.com/owncloud/core/pull/16237
This looks very encouraging! However, do you have any feedback on the
level of migration testing already done between version 7 and what's
about to land in p.d.o and experimental? I'll have to strike a very
delicate balance between non-technical users on one hand and a pretty
early packaging of a major version on the other…
(let's take the latter part off-BTS if needed)

-- Cyrille

Bug#804651: owncloud: renaming a folder can destroy all contained files

2015-11-16 Thread Cyrille Chépélov

Hi David,


>>   3. From a client's native file explorer (nautilus / Finder /
>> Explorer), rename the folder made in #1
>>   4. Result: at the end of the rename and once all machines have sync'd
>> back, some or all of the files contained within the folder have been
>> permanently destroyed.
> What are the clients (platform, version number) used to synchronize?
Here's the output of cat access.log|cut -d " " -f 12- |sort |uniq
"-"
"CalDAV-Sync/0.4.27 (LGE; g3_global_com; Android 4.4.2; fr_FR;
org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
"CalDAV-Sync/0.4.27 (Sony; E2333; Android 5.0; fr_FR;
org.dmfs.caldav.lib/732; like iOS/5.0.1 (9A405) dataaccessd/1.0)"
"CardDAV-Sync/0.4.19 (LGE; g3_global_com; Android 4.4.2; fr_FR;
org.dmfs.carddav.Sync/139)"
"gvfs/1.24.1"
"iOS/9.1 (13B143) dataaccessd/1.0"
"Mac OS X/10.10.5 (14F27) AddressBook/1579"
"Mozilla/5.0 (Linux) mirall/2.0.0"
"Mozilla/5.0 (Linux) mirall/2.0.2"
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101
Thunderbird/38.3.0 Lightning/4.0.3.1"
"Mozilla/5.0 (Macintosh) mirall/2.0.2"
"Mozilla/5.0 (Windows) mirall/1.4.2"
"Mozilla/5.0 (Windows) mirall/2.0.1"
"Mozilla/5.0 (Windows) mirall/2.0.2"
"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.3.0 Lightning/4.0.3.1"
"Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
Lightning/3.3.7"
"Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0
Lightning/3.3.2"
"Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0
Lightning/4.0.2.1"


> Have you checked upstream issue tracker already for similar issues?
Yes, with no results.
For the record, the issue was already happening in 6.x times (Debian
wheezy packages) 12-18 months ago, while upstream was at 7.x. I had
refrained to report at the time, for concern this might be disregarded
as "obsolete debiannery" by upstream. I hereby apolgise for my
irresponsibility.


>
> The issue might be in the client used where the renaming happened, but
> in any other client used to synchronize the instance too, so it would be
> nice to narrow it down (can you reproduce the issue with a Debian client
> on the move side, and a Debian client on the other side for example, or
> what combination provokes the issue?).
We've been burned multiple times, with no apparent distinction between
the initiating owncloud-client platform (Windows, Linux, Mac).
It /is/ possible that the variety of clients accessing the system is a
factor, as well as possible timing issues (some of the computers are
away, ~150 millisecond from the central machine while others are local;
and there are about 10K files for a total of about 10GiB depending on
users' permissions).
 
So far we're really glad Apple Time Machine could save our day (as
owncloud's own file history really doesn't help us go back deep in time
when nested hierarchies are lost to this issue, hence the "permanently
destroyed"), but it's kind of problematic to have to rely on that.

-- Cyrille

Bug#804651: owncloud: renaming a folder can destroy all contained files

2015-11-10 Thread Cyrille Chépélov


Subject: owncloud: Renaming a folder can destroy all contained files
Package: owncloud
Version: 7.0.4+dfsg-4~deb8u3
Severity: grave
X-Severity-explanation: can cause severe data loss, especially on 
non-technical users.


Dear Maintainer,


The following procedure can, depending on timing, cause immediate data loss:
  1. On a client, create a folder with subfolders and files within each 
folder level. The folder must be within folder shared to all other clients.
  2. Ensure this folder is replicated back to owncloud server and to 
all downstream clients (here: 3 Debian Linux clients, two Windows, 1 
Mac, all running the most recent version of owncloud-client for the 
respective platform)
  3. From a client's native file explorer (nautilus / Finder / 
Explorer), rename the folder made in #1
  4. Result: at the end of the rename and once all machines have sync'd 
back, some or all of the files contained within the folder have been 
permanently destroyed.


Thanks in advance.

-- Cyrille

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), 
(500, 'stable'), (500, 'oldstable')

Architecture: amd64 (x86_64)

Kernel: Linux 3.17-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages owncloud depends on:
ii  apache2 [httpd] 2.4.10-10+deb8u3
ii  apache2-mpm-event [httpd] 2.4.10-10+deb8u3
ii  apache2-mpm-worker [httpd] 2.4.10-10+deb8u3
ii  fonts-font-awesome  4.2.0~dfsg-1
ii  fonts-liberation1.07.4-1
ii  fonts-linuxlibertine5.3.0-2
ii  fonts-lohit-deva2.5.3-1
ii  fonts-sil-gentium-basic 1.1-7
ii  fonts-wqy-microhei  0.2.0-beta-2
ii  libjs-chosen0.9.11-2
ii  libjs-dojo-dojox 1.10.2+dfsg-1
ii  libjs-jcrop 0.9.12+dfsg-1
ii  libjs-jquery-minicolors 1.2.1-1
ii  libjs-jquery-mousewheel 10-1
ii  libjs-jquery-timepicker 1.2-1
ii  libjs-mediaelement 2.15.1+dfsg-1
ii  libjs-pdf 1.0.907+dfsg-1+deb8u1
ii  libjs-underscore1.7.0~dfsg-1
ii  libphp-phpmailer5.2.9+dfsg-2
ii  owncloud-doc0~20141208-2
ii  php-assetic 1.2.0-2
ii  php-doctrine-dbal   2.4.3-1
ii  php-getid3  1.9.8-3
ii  php-opencloud   1.10.0-2
ii  php-patchwork-utf8  1.1.25-1
ii  php-pear 5.6.14+dfsg-0+deb8u1
ii  php-pimple  1.1.1-1
ii  php-sabre-dav   1.8.10-2
ii  php-seclib  0.3.8-1
ii  php-symfony-class-loader [php-symfony-classloader] 2.3.21+dfsg-4+deb8u1
ii  php-symfony-classloader 2.3.21+dfsg-4+deb8u1
ii  php-symfony-console 2.3.21+dfsg-4+deb8u1
ii  php-symfony-routing 2.3.21+dfsg-4+deb8u1
ii  php5 5.6.14+dfsg-0+deb8u1
ii  php5-cli 5.6.14+dfsg-0+deb8u1
ii  php5-gd 5.6.14+dfsg-0+deb8u1
ii  php5-json   1.3.6-1
ii  php5-mysql 5.6.14+dfsg-0+deb8u1
ii  zendframework 1.12.9+dfsg-2+deb8u4

Versions of packages owncloud recommends:
ii  exim4  4.84-8
ii  exim4-daemon-light [mail-transport-agent]  4.84-8
ii  php-aws-sdk2.7.2-1
ii  php-crypt-blowfish 1.1.0~RC2-4
ii  php-dropbox1.0.0-3
ii  php-google-api-php-client  0.6.7-2
ii  php5-curl  5.6.14+dfsg-0+deb8u1
ii  php5-intl  5.6.14+dfsg-0+deb8u1
ii  php5-ldap  5.6.14+dfsg-0+deb8u1
ii  php5-mcrypt5.6.14+dfsg-0+deb8u1
ii  php5-xcache3.2.0-1
ii  smbclient  2:4.1.17+dfsg-2

Versions of packages owncloud suggests:
pn  libapache2-mod-xsendfile 
pn  libav-tools  
pn  libreoffice  
ii  mysql-server 5.5.46-0+deb8u1
ii  mysql-server-5.5 [virtual-mysql-server]  5.5.46-0+deb8u1
pn  php5-imagick 
ii  postgresql   9.4+165

-- Configuration Files:
/etc/owncloud/htaccess [Errno 13] Permission denied: 
u'/etc/owncloud/htaccess'


-- no debconf information

Bug#625739: libgconf2-4: gconfd crashes when resuming after changing BSSID

2011-05-05 Thread Cyrille Chépélov

Package: libgconf2-4
Version: 2.28.1-6
Severity: important


when performing the following procedure:
1. Log on while close to a previously known wifi hotspot 
2. suspend the laptop (close the lid)
3. Move away from the first wifi network, into another one 
4. Open the lid and resume the laptop, while close to ANOTHER wifi
hotspot, which is also previously known
5. bam, all settings lost, metacity back to defaults.

(the second hotspot is out of range from the first. e.g.
 commute from home to work, or between known places)

FWIW, connectivity is managed by network-manager-gnome.

-- Cyrille


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages libgconf2-4 depends on:
ii  gconf2-common  2.28.1-6  GNOME configuration database syste
ii  libc6  2.11.2-11 Embedded GNU C Library: Shared lib
ii  libdbus-1-31.4.6-1   simple interprocess messaging syst
ii  libdbus-glib-1-2   0.92-1simple interprocess messaging syst
ii  libglib2.0-0   2.28.4-1  The GLib library of C routines
ii  libldap-2.4-2  2.4.23-7  OpenLDAP libraries
ii  liborbit2  1:2.14.18-0.1 libraries for ORBit2 - a CORBA ORB
ii  libxml22.7.8.dfsg-2  GNOME XML library

libgconf2-4 recommends no packages.

libgconf2-4 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#624668: mt-daapd: Crashes when accessing from a remote device

2011-04-30 Thread Cyrille Chépélov

Package: mt-daapd
Version: 0.9~r1696.dfsg-16
Severity: important (crashes without serving any files)

When accessing firefly from the Android DAAP app, mt-daapd crashes with the
following stack frame:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f8a0f6bd700 (LWP 29440)]
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
31  ../sysdeps/x86_64/multiarch/../strlen.S: Aucun fichier ou dossier de
ce type.
in ../sysdeps/x86_64/multiarch/../strlen.S
(gdb) bt
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
#1  0x7f8a10efe3e6 in daap_get_size ()
   from /usr/lib/mt-daapd/plugins/out-daap.so
#2  0x7f8a10efe7df in daap_enum_size ()
   from /usr/lib/mt-daapd/plugins/out-daap.so
#3  0x7f8a10efc30f in ?? () from /usr/lib/mt-daapd/plugins/out-daap.so
#4  0x7f8a10efd859 in plugin_handler ()
   from /usr/lib/mt-daapd/plugins/out-daap.so
#5  0x0040ed69 in ws_dispatcher ()
#6  0x7f8a18a3d8ba in start_thread (arg=value optimized out)
at pthread_create.c:300
#7  0x7f8a167d53cd in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#8  0x in ?? ()


#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
31  in ../sysdeps/x86_64/multiarch/../strlen.S
(gdb) info registers
rax0x1  1
rbx0x20 32
rcx0x0  0
rdx0x29 41
rsi0x1  1
rdi0x0  0
rbp0x2765d200x2765d20
rsp0x7f8a0f6bc458   0x7f8a0f6bc458
r8 0x0  0
r9 0x0  0
r100xd5 213
r110x1999   1844674407370955161
r120x2707de040926688
r130x2707df040926704
r140x7f8a0f6bc498   140230940935320
r150x7f8a0f6bc538   140230940935480
rip0x7f8a16781b32   0x7f8a16781b32 __strlen_sse2+18
eflags 0x10246  [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0

(gdb) disassemble
Dump of assembler code for function __strlen_sse2:
   0x7f8a16781b20 +0: pxor   %xmm2,%xmm2
   0x7f8a16781b24 +4: mov%rdi,%rcx
   0x7f8a16781b27 +7: mov%rdi,%r8
   0x7f8a16781b2a +10:and$0xfff0,%rdi
   0x7f8a16781b2e +14:movdqa %xmm2,%xmm1
= 0x7f8a16781b32 +18:pcmpeqb (%rdi),%xmm2
   0x7f8a16781b36 +22:or $0x,%esi
   0x7f8a16781b39 +25:sub%rdi,%rcx
   0x7f8a16781b3c +28:shl%cl,%esi

%rdi is null. Probably, we are attempting to call strlen on a NULL string,
perhaps on a corrupted file within the library.

-- Cyrille


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages mt-daapd depends on:
ii  adduser 3.112+nmu2   add and remove users and groups
ii  avahi-daemon0.6.30-2 Avahi mDNS/DNS-SD daemon
ii  libavahi-client30.6.30-2 Avahi client library
ii  libavahi-common30.6.30-2 Avahi common library
ii  libavcodec525:0.6.2-0.1  library to encode decode multimedi
ii  libavformat52   5:0.6.2-0.1  ffmpeg file format library
ii  libavutil49 4:0.5.2-6ffmpeg utility library
ii  libc6   2.11.2-13Embedded GNU C Library: Shared lib
ii  libflac81.2.1-3  Free Lossless Audio Codec - runtim
ii  libid3tag0  0.15.1b-10   ID3 tag reading library from the M
ii  libjs-prototype 1.7.0-2  JavaScript Framework for dynamic w
ii  libjs-scriptaculous 1.9.0-2  JavaScript library for dynamic web
ii  libogg0 1.2.0~dfsg-1 Ogg bitstream library
ii  libsqlite3-03.7.5-1  SQLite 3 shared library
ii  libtagc01.7-1audio meta-data library - C bindin
ii  libvorbis0a 1.3.2-1  The Vorbis General Audio Compressi
ii  libvorbisfile3  1.3.2-1  The Vorbis General Audio Compressi
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

mt-daapd recommends no packages.

mt-daapd suggests no packages.

-- Configuration Files:
/etc/mt-daapd.conf [Errno 13] Permission non accordée: u'/etc/mt-daapd.conf'

-- 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#624496: libgconf2-4: gconfd crashes when resuming after changing BSSID

2011-04-28 Thread Cyrille Chépélov

Package: libgconf2-4
Version: 2.28.1-6
Severity: important


when performing the following procedure:
1. Log on while close to a previously known wifi hotspot 
2. suspend the laptop (close the lid)
3. Move away from the first wifi network, into another one 
4. Open the lid and resume the laptop, while close to ANOTHER
wifi hotspot, which is also previously known
5. bam, all settings lost, metacity back to defaults.

(the second hotspot is out of range from the first. e.g.
 commute from home to work, or between known places)

FWIW, connectivity is managed by network-manager-gnome.

-- Cyrille


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgconf2-4 depends on:
ii  gconf2-common  2.28.1-6  GNOME configuration
database syste
ii  libc6  2.11.2-11 Embedded GNU C Library:
Shared lib
ii  libdbus-1-31.4.6-1   simple interprocess
messaging syst
ii  libdbus-glib-1-2   0.92-1simple interprocess
messaging syst
ii  libglib2.0-0   2.28.4-1  The GLib library of C
routines
ii  libldap-2.4-2  2.4.23-7  OpenLDAP libraries
ii  liborbit2  1:2.14.18-0.1 libraries for ORBit2 - a
CORBA ORB
ii  libxml22.7.8.dfsg-2  GNOME XML library

libgconf2-4 recommends no packages.

libgconf2-4 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#610469: xserver-xorg-video-radeon: text textures torn under warzone2100 unusable either.

2011-02-21 Thread Cyrille Chépélov

whoops

#sudo apt-get  -t experimental install `dpkg -l   libgl*mesa*|egrep
^ii|awk '{print $2}'` xserver-xorg-video-radeon xserver-xorg-core
libgcrypt11

-- xserver-xorg-core from experimental depends with libgcrypt11 =
1.4.6, only 1.4.5-2 is available.

attempting same on unstable:

libdrm-dev libdrm-intel1 libdrm-nouveau1a libdrm-radeon1 libdrm2
libgcrypt11
  libgcrypt11-dev libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-dri-dbg
  libgl1-mesa-glx libgl1-mesa-glx-dbg libglu1-mesa libgpg-error-dev
  libgpg-error0 libkms1 libtalloc2 mesa-common-dev xserver-common
  + xserver-xorg-* 

xserver-xorg-video-radeon got upgraded to version 6.14.0-1,
libgl1-mesa-* 7.10-4, and generally all of xserver-xorg-*, except
xserver-xorg-video-radeonhd which got the axe (no surprise so far)

results:

* under compiz, none of the games I tried work. Compiz menus are
fine, but some windows maybe fail to get redrawn (tested in slightly too
much of a hurry). Games don't work (all of supertuxkart  warzone2100);
all that shows is a mouse cursor while the opening music plays

* without compiz, these two games start, and the corruption I
mentioned early on does not seem to appear anymore. Under supertuxkart,
I was able to start a race and run a few meters (before I quit). Under
warzone2100, the menus were perfectly clear and I could start a
skirmish, with unmeasured but apparently pretty good fps, even when
dragging the terrain around (right-click...dragshake), all text
appeared good.


In a nutshell, while there might be some fine-tuning with respect to
compiz, there is very clear progress, and the specific defect I was
complaining about simply vanished!

thanks

-- Cyrille

Le lundi 21 février 2011 à 17:17 +0100, Cyril Brulebois a écrit : 

 Hi Cyrille,
 
 Cyrille Chépélov cyri...@chepelov.org (18/01/2011):
  […]
  will reattempt a couple days from now.
 
 Ping?
 
 KiBi.

Bug#610469: xserver-xorg-video-radeon: text textures torn under warzone2100 unusable either.

2011-01-18 Thread Cyrille Chépélov

Attempting:


LC_ALL=C sudo apt-get -t experimental install `dpkg -l
libgl*mesa*|egrep ^ii|awk '{print $2}'`
[snip]
The following packages have unmet dependencies:
 libgl1-mesa-dri : Depends: libtalloc2 (= 2.0.4~git20101213)
but 2.0.1-1 is to be installed
E: Broken packages


will reattempt a couple days from now.

Le mardi 18 janvier 2011 à 22:18 +0100, Cyril Brulebois a écrit :

 Hi Cyrille,
 
 Cyrille Chépélov cyri...@chepelov.org (18/01/2011):
  When running warzone under the setup described below, text textures
  are quickly corrupted to the point of making all in-game text
  illegible. […]
 
 could you please install mesa (should be libgl*mesa*) from
 experimental and tell us whether that helps?
 
 KiBi.

Bug#555541: small precision

2009-11-10 Thread Cyrille Chépélov

the version number 2.0.7_0.0.1 corresponds in fact to our local build,
which is exactly:
   apt-get source glusterfs # 2.0.4-2
   apply our patch from #549854
   untar upstream's 2.0.7
   move 2.0.4-2's debian directory into 2.0.7
   dpkg-buildpackage -rfakeroot

AIUI, Jan's report applies to vanilla 2.0.4-2 as well. Not that we'd
mind to see #544434 closed :)

-- Cyrille





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

Bug#544434: New upstream release 2.0.7

2009-10-23 Thread Cyrille Chépélov

retitle 544434 New upstream release 2.0.7
thanks

:)

Bug#549886: Patch to fix building against DB 4.8 + provide the log dir

2009-10-23 Thread Cyrille Chépélov

tags 549886 + patch
tags 549854 + patch
tags 544433 + patch
thanks

This patch fixes building against DB 4.8 (it should apply over 2.0.4 as
well as over 2.0.7 for the Debian 2.0.4 packaging ports fine), among a
few other details.

The salient point is this:

+-#if (DB_VERSION_MAJOR == 4\
+- DB_VERSION_MINOR == 7)
++#if ((DB_VERSION_MAJOR  4) || \
++ (DB_VERSION_MAJOR == 4  DB_VERSION_MINOR = 7))
+ if (private-log_auto_remove) {
+ ret = dbenv-log_set_config (dbenv,
DB_LOG_AUTO_REMOVE, 1);


-- Cyrille

diff -urN glusterfs-2.0.4.vanilla/debian/changelog glusterfs-2.0.7/debian/changelog
--- glusterfs-2.0.4.vanilla/debian/changelog	2009-10-23 09:39:55.0 +0200
+++ glusterfs-2.0.7/debian/changelog	2009-10-23 10:50:53.0 +0200
@@ -1,3 +1,18 @@
+glusterfs (2.0.7-0.0.1) unstable; urgency=low
+  * new upstream release. (Closes: #544434)
+  * Building against DB 4.8 should not fail:
+- debian/patches/10_accept_also_db4.8: added (hits xlators/storage/bdb/src/bdb-ll.c)   
+(Closes: #549854, #549886) 
+  * add glusterfs-volgen from extras which appears now to be the correct way to 
+build new volumes. (FIXME: glusterfs-volgen.8)
+- debian/rules
+- debian/glusterfs-server.install
+  * Add the VIM and EMACS modes from extras
+- debian/libglusterfs0.install  
+  * debian/glusterfs-server.dirs: needed as well as on the client side (Closes:#544433)
+  
+ -- Cyrille CHÉPÉLOV cyrille.chepe...@keyconsulting.fr  Fri, 23 Oct 2009 10:00:00 +
+  
 glusterfs (2.0.4-2) unstable; urgency=low
 
   * Fix circular dependency with glusterfs-server (Closes: #537787)
diff -urN glusterfs-2.0.4.vanilla/debian/glusterfs-server.dirs glusterfs-2.0.7/debian/glusterfs-server.dirs
--- glusterfs-2.0.4.vanilla/debian/glusterfs-server.dirs	1970-01-01 01:00:00.0 +0100
+++ glusterfs-2.0.7/debian/glusterfs-server.dirs	2009-10-23 10:14:30.0 +0200
@@ -0,0 +1 @@
+/var/log/glusterfs
diff -urN glusterfs-2.0.4.vanilla/debian/glusterfs-server.install glusterfs-2.0.7/debian/glusterfs-server.install
--- glusterfs-2.0.4.vanilla/debian/glusterfs-server.install	2009-10-23 09:39:55.0 +0200
+++ glusterfs-2.0.7/debian/glusterfs-server.install	2009-10-23 10:48:18.0 +0200
@@ -1,3 +1,5 @@
 debian/tmp/etc/glusterfs/glusterfs.vol
 debian/tmp/etc/glusterfs/glusterfsd.vol
 debian/tmp/usr/sbin/glusterfsd
+debian/tmp/usr/sbin/glusterfs-volgen
+
diff -urN glusterfs-2.0.4.vanilla/debian/libglusterfs0.install glusterfs-2.0.7/debian/libglusterfs0.install
--- glusterfs-2.0.4.vanilla/debian/libglusterfs0.install	2009-10-23 09:39:55.0 +0200
+++ glusterfs-2.0.7/debian/libglusterfs0.install	2009-10-23 10:48:24.0 +0200
@@ -1,3 +1,6 @@
 debian/tmp/usr/lib/glusterfs/*
 debian/tmp/usr/lib/libglusterfs.so.*
 debian/tmp/usr/lib/libglusterfsclient.so.*
+debian/tmp/usr/share/vim/vim72/glusterfs.vim
+debian/tmp/usr/share/emacs/site-lisp/glusterfs-mode.el
+
diff -urN glusterfs-2.0.4.vanilla/debian/patches/00list glusterfs-2.0.7/debian/patches/00list
--- glusterfs-2.0.4.vanilla/debian/patches/00list	2009-10-23 09:39:55.0 +0200
+++ glusterfs-2.0.7/debian/patches/00list	2009-10-23 10:27:40.0 +0200
@@ -1 +1,3 @@
 01_bashism
+10_accept_also_db4.8
+
diff -urN glusterfs-2.0.4.vanilla/debian/patches/10_accept_also_db4.8 glusterfs-2.0.7/debian/patches/10_accept_also_db4.8
--- glusterfs-2.0.4.vanilla/debian/patches/10_accept_also_db4.8	1970-01-01 01:00:00.0 +0100
+++ glusterfs-2.0.7/debian/patches/10_accept_also_db4.8	2009-10-23 10:27:29.0 +0200
@@ -0,0 +1,21 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 10_accept_also_db4.8 by Cyrille CHÉPÉLOV cyrille.chepe...@keyconsulting.fr
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: fix FTBFS against DB4.8
+## DP: the version test should check against DB = 4.7 not == 4.7
+
+...@dpatch@
+--- glusterfs-2.0.7.vanilla/xlators/storage/bdb/src/bdb-ll.c	2009-10-01 15:19:54.0 +0200
 glusterfs-2.0.7/xlators/storage/bdb/src/bdb-ll.c	2009-10-23 10:24:02.0 +0200
+@@ -954,8 +954,8 @@
+ }
+ 
+ ret = 0;
+-#if (DB_VERSION_MAJOR == 4\
+- DB_VERSION_MINOR == 7)
++#if ((DB_VERSION_MAJOR  4) || \
++ (DB_VERSION_MAJOR == 4  DB_VERSION_MINOR = 7))
+ if (private-log_auto_remove) {
+ ret = dbenv-log_set_config (dbenv, DB_LOG_AUTO_REMOVE, 1);
+ } else {
diff -urN glusterfs-2.0.4.vanilla/debian/rules glusterfs-2.0.7/debian/rules
--- glusterfs-2.0.4.vanilla/debian/rules	2009-10-23 09:39:55.0 +0200
+++ glusterfs-2.0.7/debian/rules	2009-10-23 10:48:39.0 +0200
@@ -9,6 +9,7 @@
 	mv debian/tmp/etc/glusterfs/glusterfsd.vol.sample \
 	   debian/tmp/etc/glusterfs/glusterfsd.vol
 	ln -s glusterfs.8 debian/tmp/usr/share/man/man8/glusterfsd.8 
+	install -D -m 755 extras/glusterfs-volgen.py debian/tmp/usr/sbin/glusterfs

Bug#534335: network-manager: serious hanshake issues with Huawei E220 USB 3G modem until PIN is entered might be important, it certainly is for me

2009-06-23 Thread Cyrille Chépélov

Package: network-manager
Version: 0.7.1-1
Severity: normal


The Huawei E220 USB 3G (HSDPA) modem accepts to do very little until the SIM
PIN is entered. Meanwhile, it replies +CME ERROR: SIM PIN ... on any
command. This is not expected by Network Manager's modem init code; NM tries
various init strings, always falling in timeout, then eventually gives up
(making the modem unusable). Sometimes, for reasons I don't understand, one
of the init strings causes the modem to spit out another OK, which lets NM
proceed and provide the PIN. Once this happened, the modem is happy forever
(or a power loss happens, whichever is first).

It is also possible that debian/patches/04-struct_termios.patch introduces some
subtle shift of semantics and that in fact the modem intended to send both
+CME ERROR and OK aftwerwards.

The patch attached here adds +CME ERROR as a valid handshake terminator on
most exchanges; this considerably speeds up and improves the robustness of
the E220's startup. I'm not positive it's the best strategy, but it Works
For Me(tm) and might help someone else.

-- Cyrille


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-1-686 (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/bash

Versions of packages network-manager depends on:
ii  adduser  3.110   add and remove users and groups
ii  dbus 1.2.12-1simple interprocess messaging syst
ii  dhcp3-client 3.1.1-6 DHCP client
ii  hal  0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer
ii  ifupdown 0.6.8+nmu1  high level tools to configure netw
ii  libc62.9-13  GNU C Library: Shared libraries
ii  libdbus-1-3  1.2.12-1simple interprocess messaging syst
ii  libdbus-glib 0.80-4  simple interprocess messaging syst
ii  libgcrypt11  1.4.4-2 LGPL Crypto library - runtime libr
ii  libglib2.0-0 2.20.0-2The GLib library of C routines
ii  libgnutls26  2.6.6-1 the GNU TLS library - runtime libr
ii  libgpg-error 1.6-1   library for common error values an
ii  libhal1  0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer - share
ii  libnl1   1.1-5   library for dealing with netlink s
ii  libnm-glib0  0.7.1-1 network management framework (GLib
ii  libnm-util1  0.7.1-1 network management framework (shar
ii  libpolkit-db 0.9-3   library for accessing PolicyKit vi
ii  libpolkit2   0.9-3   library for accessing PolicyKit
ii  libtasn1-3   1.8-1   Manage ASN.1 structures (runtime)
ii  libudev0 0.141-1 libudev shared library
ii  libuuid1 1.41.3-1universally unique id library
ii  lsb-base 3.2-22  Linux Standard Base 3.2 init scrip
ii  wpasupplican 0.6.9-2 client support for WPA and WPA2 (I
ii  zlib1g   1:1.2.3.3.dfsg-13   compression library - runtime

Versions of packages network-manager recommends:
ii  dnsmasq-base   2.47-3A small caching DNS proxy and DHCP
ii  iptables   1.4.3.2-2 administration tools for packet fi
ii  network-manager-gnome  0.7.1-1   network management framework (GNOM
ii  policykit  0.9-3 framework for managing administrat
ii  ppp2.4.4rel-10.1 Point-to-Point Protocol (PPP) - da

Versions of packages network-manager suggests:
ii  avahi-autoipd 0.6.25-1   Avahi IPv4LL network address confi

-- no debconf information
diff -ur network-manager-0.7.1.vanilla2/ChangeLog network-manager-0.7.1/ChangeLog
--- network-manager-0.7.1.vanilla2/ChangeLog	2009-06-23 19:31:16.0 +0200
+++ network-manager-0.7.1/ChangeLog	2009-06-23 19:41:05.0 +0200
@@ -1,3 +1,10 @@
+2009-06-23  Cyrille Chépélov cyri...@chepelov.org
+
+* callouts/nm-modem-probe.c:
+- the Huawei E220 3G USB modem tends to reply +CME ERROR: instead 
+of simply ERROR before a valid PIN is entered. Adding this to 
+most terminator lists.
+
 2009-06-10  Cyrille Chépélov cyri...@chepelov.org
 
 * callouts/nm-modem-probe.c:
diff -ur network-manager-0.7.1.vanilla2/src/nm-gsm-device.c network-manager-0.7.1/src/nm-gsm-device.c
--- network-manager-0.7.1.vanilla2/src/nm-gsm-device.c	2009-04-13 00:29:59.0 +0200
+++ network-manager-0.7.1/src/nm-gsm-device.c	2009-06-23 19:00:27.0 +0200
@@ -244,7 +244,7 @@
 	NMSettingGsm *setting;
 	char *command;
 	const char *apn;
-	const char *responses[] = { OK, ERROR, NULL };
+	const char *responses[] = { OK, ERROR, +CME ERROR, NULL };
 	guint cid

Bug#533645: network-manager: Huawei E220 3G modems require a LONG settle time to work

2009-06-19 Thread Cyrille Chépélov

) {
 fprintf (stderr, Invalid delay: %s\n, optarg);
 return 1;
 			}
@@ -613,6 +618,11 @@
 		printf (ID_NM_MODEM_PROBED=1\n);
 	}
 
+	g_get_current_time (probe_end);
+	g_timeval_subtract (probe_diff, probe_end, probe_start);
+	probe_time_ms = (probe_diff.tv_sec * 1000) + (probe_diff.tv_usec / 1000);
+printf (ID_NM_MODEM_PROBE_TIME_MS=%ld\n, probe_time_ms);
+
 	verbose (%s: caps (0x%X)%s%s%s%s\n, device, caps,
 	 caps  MODEM_CAP_GSM ?  GSM : ,
 	 caps  (MODEM_CAP_IS707_A | MODEM_CAP_IS707_P) ?  CDMA-1x : ,
diff -ur network-manager-0.7.1.vanilla/ChangeLog network-manager-0.7.1/ChangeLog
--- network-manager-0.7.1.vanilla/ChangeLog	2009-03-03 17:55:45.0 +0100
+++ network-manager-0.7.1/ChangeLog	2009-06-10 01:26:55.0 +0200
@@ -1,3 +1,14 @@
+2009-06-10  Cyrille Chépélov cyri...@chepelov.org
+
+* callouts/nm-modem-probe.c:
+- increase the maximum admissible probe time to 30 seconds
+- add another property ID_NM_MODEM_PROBE_TIME_MS to report the actual
+probe time
+* callouts/77-nm-probe-modem-capabilities.rules:
+- Huawei modems' interface #1 is dangerous, don't probe it
+- Set a larger probe time (12 seconds) for Huawei modems, leave others
+at the default 3 seconds.
+
 2008-12-11  Dan Williams  d...@redhat.com
 
 	* Move NetworkManager to git.freedesktop.org

Bug#524335: xserver-xorg-video-radeonhd: Fails to render anything but the mouse

2009-04-16 Thread Cyrille Chépélov

Package: xserver-xorg-video-radeonhd
Version: 1.2.5-1
Severity: important
Justification: package is unusable on this specific setup

On this setup (ATI Radeon HD4350), this version of the driver produces a
white screen, with the mouse pointer.

The mouse pointer geometry changes according to where the usual GDM entry
fields are supposed to be, leading me to believe the driver mostly works,
except for the actually push bits to the screen part.

-- Cyrille

-- Package-specific info:
Contents of /var/lib/x11/X.roster:
xserver-xorg

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 jun 24  2007 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 1876496 avr 15 14:16 /usr/bin/Xorg

Contents of /var/lib/x11/xorg.conf.roster:
xserver-xorg

VGA-compatible devices on PCI bus:
01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350]

/etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum.

Xorg X server configuration file status:
-rw-rw-rw- 1 root root 2661 avr 16 11:57 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:

# xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type man xorg.conf at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section ServerLayout
Identifier Default Layout
Screen  0  aticonfig-Screen[0] 0 0
InputDeviceGeneric Keyboard
InputDeviceConfigured Mouse
Option  AIGLX true
EndSection

Section Files
EndSection

Section Module
Load  bitmap
Load  dbe
Load  ddc
Load  dri
Load  extmod
#   Load  freetype
Load  glx
Load  int10
Load  record
#   Load  type1
Load  vbe
#Load synaptics
#   Load  xtrap
EndSection

Section ServerFlags
Option  AllowMouseOpenFail true
#   Option  SHMConfig true
Option  DontZoom false
EndSection

Section InputDevice
Identifier  Generic Keyboard
Driver  kbd
Option  CoreKeyboard
Option  XkbRules xorg
Option  XkbModel pc105
Option  XkbLayout fr
Option  XkbVariant latin9
EndSection

Section InputDevice
Identifier  Configured Mouse
Driver  mouse
Option  CorePointer
Option  Device /dev/input/mice
Option  Protocol auto
Option  Emulate3Buttons false
EndSection

Section Monitor
Identifier   aticonfig-Monitor[0]
Option  VendorName ATI Proprietary Driver
Option  ModelName Generic Autodetecting Monitor
Option  DPMS true
EndSection

Section Device

Driver  radeonhd
#   Driver  ati
Identifier  aticonfig-Device[0]
#   Driver  fglrx
#   Driver vesa

##  Option  VideoOverlay on
##  Option  OpenGLOverlay off
##  Option  EnableMonitor crt1,lvds,tv,tmds1,crt2,tmds2,cv,tmds2i
EndSection

Section Screen
Identifier aticonfig-Screen[0]
Device aticonfig-Device[0]
Monitoraticonfig-Monitor[0]
DefaultDepth 24
SubSection Display
Viewport   0 0
Depth 24
EndSubSection
EndSection

#Section DRI
#   Mode 0666
#EndSection

#Section Extensions
#
#   #Option AIGLX off
#   Option  Composite Enable
#   #Option Composite off
#   Option  AIGLX on
#   Option  RENDER true
#   Option  DAMAGE true
#   Option  DRI   on
#EndSection



Xorg X server log files on system:
-rw-r--r-- 1 root root 36532 avr 13 19:32 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 39355 avr 16 11:58 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:

X.Org X Server 1.6.1
Release Date: 2009-4-14
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.26-1-vserver-amd64 x86_64 Debian
Current Operating System: Linux hestia 2.6.29-1-amd64 #1 SMP Sat Apr 4 16:54:07 
UTC 2009 x86_64
Build Date: 15 April 2009  12:08:18PM
xorg-server 2:1.6.1-1 (bui...@excelsior.roeckx.be) 
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Thu Apr 16 11:57:44 2009
(==)

Bug#524335: Not that severe, after all

2009-04-16 Thread Cyrille Chépélov

severity 524335 normal
title 524335 has trouble resetting the hardware into the intended state 
thanks

After a reboot, the driver did produce a working screen, in 1600x1050 at
the GDM prompt.

After logging on, for some reason the screen went pink and slightly
garbled, and at a 1440x900ish resolution, but that was functional enough
to reach for the gRandR applet and put it back into 1600x1050. So far
(and after several similar tries) the result is satisfactorily in 2D.

Seems the problem will be over once the slight issue with completely
resetting the hardware state on mode changes is solved.

Thanks

-- Cyrille





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

Bug#524335: xserver-xorg-video-radeonhd: Fails to render anything but the mouse

2009-04-16 Thread Cyrille Chépélov

Le jeudi 16 avril 2009 à 13:58 +0200, Brice Goglin a écrit :


 Did 1.2.4 work fine?


No idea; I have been on fglrx for the last few weeks (about the whole
time I've been owning this piece of hardware).


 Does the radeon driver work?


It didn't seem to when I plugged in the 4350 to replace the RS690 (IGP)
I had been using before.

I will try your suggestion with the radeon.ko DRM module. 

-- Cyrille

Bug#524335: xserver-xorg-video-radeonhd: Fails to render anything but the mouse

2009-04-16 Thread Cyrille Chépélov

Le jeudi 16 avril 2009 à 20:58 +0200, Brice Goglin a écrit :

 Cyrille Chépélov wrote:
  Does the radeon driver work?
  
 
  It didn't seem to when I plugged in the 4350 to replace the RS690
  (IGP) I had been using before.
 
  I will try your suggestion with the radeon.ko DRM module.
 
 No, don't change anything with your kernel :)


wasn't that your suggestion?:


 By the way, you might want to try with upstream drm kernel modules
 since
 they bring better support for your board.


anyway, back to this:

 Just try changing radeonhd into radeon in xorg.conf after installing
 xserver-xorg-video-radeon.

Did; except that it (again) defaulted my session into a 1440x900 mode
that is meaningless for my setup, it seem to work fine after the now
traditionnal grandr mode-switching ceremony.

 (previously I had been using a 1280x1024 LCD, switched to a 1600x1050
LCD which normally works great, except it caused the RS690 to simply
crash the system (except if I booted with the 1280x1024 on, then
swapped, and played with grandr -- didn't try to fight it, went to
grosbill to get a newer board I wanted anyway))
#insert significant_other/snide_remarks_about_windowsXP.h

-- Cyrille

Bug#521164: fglrx-kernel-src: Extra information to help to build the patch

2009-04-10 Thread Cyrille Chépélov


Le vendredi 10 avril 2009 à 09:53 +0200, Emmanuel Fleury a écrit :
 Package: fglrx-kernel-src
 Version: 1:9-3-1
 Severity: normal
 
 What did change in the 2.6.29 seems to be the following struct:
 
 - current-euid -- current-cred-euid
 - current-uid -- current-cred-uid
 - current-gid -- current-cred-gid

Way more things changed, especially with respect to the ACPI subsystem
(specifically, the driver made use of a sizeable amount of private
structures)

The following patch kind of works for me; it seems DPMS is still bust
and I get the occasional lock-up, but otherwise I've been happily
compiz'ing and gaming with it for a couple weeks.

As one of the comments mentions, some parts are still quite dirty and
possibly not DFSG compliant (borderline, at least)

The ACPI side almost works, after running it, I noticed I made the
effort to keep track of fglrx-private data (which used to be stuffed
within the acpi layer's own private data), but I forgot to rewire the
actual notifications. Should be trivial now; might explain the DPMS
troubles.

Anyway, right now I'm pretty satisfied with the way my HD 4350 behaves
with this driver... YMMV, HTH.

-- Cyrille

Seulement dans fglrx.vanilla/: configure-stamp
Seulement dans fglrx.vanilla/debian: control
diff -ur fglrx.vanilla/firegl_public.c fglrx/firegl_public.c
--- fglrx.vanilla/firegl_public.c	2009-03-29 21:08:16.0 +0200
+++ fglrx/firegl_public.c	2009-03-30 00:17:17.0 +0200
@@ -1402,7 +1402,7 @@
  */
 KCL_TYPE_Uid ATI_API_CALL KCL_GetEffectiveUid(void)
 {
-return current-euid;
+return current_euid();
 }
 
 /** /brief Delay execution for the specified number of microseconds
@@ -1774,15 +1774,19 @@
  */
 void ATI_API_CALL KCL_PosixSecurityCapSetIPCLock(unsigned int lock)
 {
+struct cred *new;
+new = prepare_creds();
+if (!new) return /* -ENOMEM */;
+
 if (lock == 0 )
 {
-cap_lower(current-cap_effective, CAP_IPC_LOCK);
+cap_raise(new-cap_effective, CAP_IPC_LOCK);
 }
 else
 {
-cap_raise(current-cap_effective, CAP_IPC_LOCK);
+cap_lower(new-cap_effective, CAP_IPC_LOCK);
 }
-return; 
+commit_creds(new);
 }
 
 /** \brief Get number of available RAM pages
@@ -2256,13 +2260,16 @@
  * kernel   2.6.27, on_each_cpu has 4 parameters.
  * kernel = 2.6.27, on_each_cpu has 3 parameters (removed the retry parameter)
  */
-#if defined(__x86_64__)  defined(__SMP__)  (LINUX_VERSION_CODE = KERNEL_VERSION(2,6,25)) 
+#if defined(__x86_64__)  defined(__SMP__)  (LINUX_VERSION_CODE = KERNEL_VERSION(2,6,25))  (LINUX_VERSION_CODE  KERNEL_VERSION(2,6,28))
 #   if (LINUX_VERSION_CODE  KERNEL_VERSION(2,6,27))
 on_each_cpu(KCL_flush_tlb_one, va, 1, 1);
 #   else
 on_each_cpu(KCL_flush_tlb_one, va, 1);
 #   endif
+#elif (LINUX_VERSION_CODE = KERNEL_VERSION(2,6,28))
+on_each_cpu(KCL_flush_tlb_one, va, 1);
 #else
+/* old code */
 flush_tlb_page(vma, va);
 #endif
 }
diff -ur fglrx.vanilla/firegl_public.h fglrx/firegl_public.h
--- fglrx.vanilla/firegl_public.h	2009-03-29 21:08:16.0 +0200
+++ fglrx/firegl_public.h	2009-03-30 00:11:20.0 +0200
@@ -161,7 +161,9 @@
 
 #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,14)
 #define PMSG_EVENT(pmsg_state) (pmsg_state).event
+#ifndef PM_EVENT_SUSPEND
 #define PM_EVENT_SUSPEND 2
+#endif
 #else
 #define PMSG_EVENT(pmsg_state) (pmsg_state)
 #define PM_EVENT_SUSPEND 3
@@ -591,6 +593,14 @@
 #define cpu_has_pge test_bit(X86_FEATURE_PGE, boot_cpu_data.x86_capability)
 #endif
 
+
+#if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,28)
+/* this is DIRTY but will circumvent the GPL-only restriction for now? */
+#undef pgprot_writecombine
+#undef pgprot_noncached
+
+#endif
+
 #ifndef pgprot_writecombine
 #define pgprot_writecombine(prot) __pgprot((pgprot_val(prot)  ~(_PAGE_PCD)) | _PAGE_PWT)
 #endif
Seulement dans fglrx.vanilla/: .firegl_public.o.d
diff -ur fglrx.vanilla/kcl_acpi.c fglrx/kcl_acpi.c
--- fglrx.vanilla/kcl_acpi.c	2009-03-29 21:08:16.0 +0200
+++ fglrx/kcl_acpi.c	2009-03-30 00:13:41.0 +0200
@@ -12,6 +12,11 @@
  * User License Agreement is included with this software and is also*
  * available by contacting ATI Technologies Inc. at http://www.ati.com  *
  *  *
+ *  *
+ *  *
+ *  blah, blah, blah.   *
+ *   I wanted to run this on kernel 2.6.29, had to do some dirty work to*
+ *   get it limping. YMMV.   Cyrille Chepelov cyri...@chepelov.org*
  /
 
 #include linux/version.h
@@ -62,6 +67,76 @@
 return acpi_get_devices(NULL, (acpi_walk_callback)callback, context, NULL);
 }
 
+
+/* store the first child */
+struct kcl_acpi_find_child {
+

Bug#506373: clarification

2008-11-28 Thread Cyrille Chépélov

the message uses an encoding consistent with the declared MIME type; I
cannot blame the originator for using a non-utf8 encoding, since it is
correctly tagged so. The problem is that Evolution ignores the encoding
on inbound messages *but* fails to nuke any invalid utf-8 sequences.
(in that respect, #505249 share a lot of things)

Originally tagged as a security issue, since remotely-controlled SEGV
are not something to ignore in my opinion (although indeed, the
workaround suggested by Y.A. Perez does work, the wording of the
question is quite different from should I attempt to display again the
message that caused me to crash?, which could lead to another round of
hair cutting (best avoided)). Won't discuss further the severity
downgrade, but one might wonder about the sorry state of Evolution, even
though it's supposed to be the default GNOME mail/calendarkitchen sink
app...

-- Cyrille

Bug#505249: more info

2008-11-28 Thread Cyrille Chépélov

Christian,

iCal's format is no different with respect to encodings than text/plain.
There's a reason why MIME allows for explicitely declaring the charset,
evo should not fail to observe that, and it should not fail to remove
invalid UTF-8 sequences in data it accepts from outside (said invalid
sequence removal should of course happen after any inbound transcoding).
Given this, I'm starting to wonder at this point whether
carefully-crafted messages mightn't be created for the purpose of doing
user-level remote execution using Evo as the entry point (given that
Ubuntu deploys evo by default, this might raise an eyebrow). I have no
beginning of proof, of course, and actually have doubts on the
feasibility, but still, this leaves a pretty bad feeling.

I won't start a revert war on the BTS, however, I would like you to
explain to me how, given this
 http://www.debian.org/Bugs/Developer.en.html#severities:

grave

makes the package in question unusable or mostly so, or
causes data loss, or introduces a security hole allowing
access to the accounts of users who use the package.


(my emphasis), the original severity was too much.

Case in point: I do not use ext3fs. I couldn't care less if e2fstools
had a data-loss bug. Should I start to go around and downgrade any such
(hypothetic) grave or critical bugs, on the grounds that the on-disk
ext3 format has weaknesses? [*]
Silently loosing years worth of (potentially business) data during a
trivial copy operation is not something I expect from a package
supposedly worthy of entering stable Debian. I would agree with
severity: important (or maybe normal even) if the failure caused a
single invalid data encountered -- copy aborted midway message box.

-- Cyrille



[*] no relationship to my actual file system usage. Illustrative purpose
only. Filmed overseas. Professional driver. Closed course.

Bug#505249: original root cause found

2008-11-24 Thread Cyrille Chépélov

Stumbling upon #506373 led me to find the root cause: my calendars are
were corrupt (from the point of view of utf-8 cleanliness) because of
the fact that Evolution processes correctly the various MIME parts that
make up a foreign invitation, EXCEPT the charset part. This is the
reason why the calendars ended up with a mixture of utf-8 and latin9.

The proper fix for this bug, of course, is to bleach again any entry
about to be copied. I suggest that each ticket gets validated from the
point of view of utf8ness, and if fails, the default encoding (as
applied in the mail view preferences) be attempted instead. Official
unknown character characters should be put in place if all fails, so
that the copy receives only valid utf-8 (as it should be).
Alternatively, another way of seeing the proper fix is to treat the copy
operation as a stricly GIGO operation, letting the correction of the
mess up to better times. Point is, there should NEVER be silent aborts
like currently.

-- Cyrille





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#506373: evolution email crashes when receiving a specific invitation from Google Calendar

2008-11-20 Thread Cyrille Chépélov

Package: evolution
Version: 2.22.3.1-1
Severity: grave
Justification: security; strangers might DoS evolution causing a crash upon 
startup until other mail piles up.


When receiving a specific e-mail message containing a Google Calendar
invitation, Evolution crashes. It then crashes again at boot, when trying
again to display the last received (same) message.

The default character set might be set to either UTF-8 or ISO-8859-15; it is
unknown at this point whether the Google Calendar invite is exactly
well-formatted with respect to character encoding. What is known is that the
second-to-last character of the subject is a lowercase eacute (U+00E9) and
that there is also another such character in the middle of the subject
string.  From looking at the way the stack trace from gdb ends up into an
UTF-8 aware gnome-terminal, it seems some mojibake issue might be at play.
libglib2.0-0 is the place of crash, for sure, but evolution (camel) proper
might as well be charged with insufficient disinfection of incoming remote 
data (a definitive security risk)

I'll attach the stack trace here, very slightly edited to remove private
data (overstriking only ASCII characters with other ASCII characters)

-- Cyrille

-- stack dump

#0  0x7f0c55b6ae30 in IA__g_markup_escape_text (
text=0x4887000 Address 0x4887000 out of bounds, length=76050432)
at /build/buildd/glib2.0-2.16.6/glib/gmarkup.c:1952
#1  0x7f0c55b6c198 in IA__g_markup_vprintf_escaped (
format=value optimized out, args=value optimized out)
at /build/buildd/glib2.0-2.16.6/glib/gmarkup.c:2272
#2  0x7f0c55b6c2fd in IA__g_markup_printf_escaped (
format=0x4564aa0 \020p9C\f\177)
at /build/buildd/glib2.0-2.16.6/glib/gmarkup.c:2329
#3  0x7f0c4af7aa39 in itip_view_set_summary (view=value optimized out, 
summary=0x4557d80 Concert Paris-Novembre (R�xx V�))

^^^ ^^^ ^ ^  ^^
(note the unknown character boxes here, should be
 U+00E9 instead.)

at itip-view.c:597

#4  0x7f0c4af73cdb in format_itip_object (efh=0x1dfe1c0, 
eb=0x7f0c3d4ba6e0, pobject=value optimized out) at
#itip-formatter.c:2017
#5  0x7f0c4fa4218f in efh_object_requested (html=value optimized out, 
eb=0x7f0c3d4ba6e0, efh=0x1dfe1c0) at em-format-html.c:625
#6  0x7f0c5bcca058 in html_g_cclosure_marshal_BOOLEAN__OBJECT (
closure=0x3d72780, return_value=0x7fff68ee8910, 
n_param_values=value optimized out, param_values=0x7fff68ee8710, 
invocation_hint=value optimized out, marshal_data=0x7f0c4fa42140)
at htmlmarshal.c:83
#7  0x7f0c56001e9d in IA__g_closure_invoke (closure=0x3d72780, 
return_value=0x7fff68ee8910, n_param_values=2, 
param_values=0x7fff68ee8710, invocation_hint=0x7fff68ee8610)
at /build/buildd/glib2.0-2.16.6/gobject/gclosure.c:490
#8  0x7f0c56014bfd in signal_emit_unlocked_R (node=0x3cb3040, detail=0, 
instance=0x3cd87e0, emission_return=0x7fff68ee8910, 
instance_and_params=0x7fff68ee8710)
at /build/buildd/glib2.0-2.16.6/gobject/gsignal.c:2440
#9  0x7f0c56015f71 in IA__g_signal_emit_valist (instance=0x3cd87e0, 
signal_id=value optimized out, detail=0, var_args=0x7fff68ee8970)
at /build/buildd/glib2.0-2.16.6/gobject/gsignal.c:2209
#10 0x7f0c560165f3 in IA__g_signal_emit (instance=0x4564aa0,
#signal_id=1, 
detail=3351806) at /build/buildd/glib2.0-2.16.6/gobject/gsignal.c:2243
#11 0x7f0c5bc8ab1e in html_engine_object_requested_cb (
engine=value optimized out, eb=0x7f0c3d4ba6e0, data=0x3cd87e0)
at gtkhtml.c:542
#12 0x7f0c5bcca058 in html_g_cclosure_marshal_BOOLEAN__OBJECT (
closure=0x3d74e40, return_value=0x7fff68ee8ef0, 
n_param_values=value optimized out, param_values=0x7fff68ee8cf0, 
invocation_hint=value optimized out, marshal_data=0x7f0c5bc8aad0)
at htmlmarshal.c:83
#13 0x7f0c56001e9d in IA__g_closure_invoke (closure=0x3d74e40, 
return_value=0x7fff68ee8ef0, n_param_values=2, 
param_values=0x7fff68ee8cf0, invocation_hint=0x7fff68ee8bf0)
at /build/buildd/glib2.0-2.16.6/gobject/gclosure.c:490
#14 0x7f0c56014bfd in signal_emit_unlocked_R (node=0x3d67470, detail=0, 
instance=0x3d8c080, emission_return=0x7fff68ee8ef0, 
instance_and_params=0x7fff68ee8cf0)
at /build/buildd/glib2.0-2.16.6/gobject/gsignal.c:2440
#15 0x7f0c56015f71 in IA__g_signal_emit_valist (instance=0x3d8c080, 
signal_id=value optimized out, detail=0, var_args=0x7fff68ee8f50)
at /build/buildd/glib2.0-2.16.6/gobject/gsignal.c:2209
#16 0x7f0c560165f3 in IA__g_signal_emit (instance=0x4564aa0,
#signal_id=1, 
detail=3351806) at /build/buildd/glib2.0-2.16.6/gobject/gsignal.c:2243
#17 0x7f0c5bcbabdf in element_parse_object (e=0x3d8c080, clue=0x454e070, 
attr=value optimized out) at htmlengine.c:1531
#18 0x7f0c5bcb8f50 in parse_one_token (e=0x3d8c080, clue=0x454e070, 
str=0x45462b7 object

Bug#506373: complement on the subject line body

2008-11-20 Thread Cyrille Chépélov

retitle 506373 Evolution recklessy ignores the charset on text/html
email fragments and causes glib's death by ana-utf8-phylactic shock
thanks

Although the subject line is (correclty) encoded in windows-1252 and
appears to contain the offending string, it does not appear to be the
cause of trouble. 

The offending string can be found in the scrap of html sent by Google as
the first MIME part of the message body; quoting  the bit:


div style=width:370px; background:#D2E6D2; border-style:solid;
border-color:#ccc; border-width:1px 1px 0 1px; padding:15px 15px
5px 15px;   margin:0 autop
style=margin:0;color:#0[EMAIL PROTECTED],
vous êtes invité(e) à participer à/p
h2 style=margin:5px 0; font-size:18px;
line-height:1.4;color:#0Concert Paris-Novembre (Réxx
Vé)/h2


(here, gedit did automatically convert that from ISO-8859-15 to UTF-8,
hence none of the diacritics appear mutilated. hexdumping the MIME bit
does confirm the ISO-8859-15 encoding:

01c0  20 73 74 79 6c 65 3d 22  6d 61 72 67 69 6e 3a 30  |
style=margin:0|
01d0  3b 63 6f 6c 6f 72 3a 23  30 22 3e 63 79 72 69 6c
|;color:#0cyril|
01e0  6c 65 40 63 68 65 70 65  6c 6f 76 2e 6f 72 67 2c  |
[EMAIL PROTECTED],|
01f0  0a 76 6f 75 73 20 ea 74  65 73 20 69 6e 76 69 74  |.vous .tes
invit|
0200  e9 28 65 29 20 e0 20 70  61 72 74 69 63 69 70 65  |.(e) .
participe|
0210  72 20 e0 3c 2f 70 3e 0a  3c 68 32 20 73 74 79 6c  |r ./p.h2
styl|
0220  65 3d 22 6d 61 72 67 69  6e 3a 35 70 78 20 30 3b  |
e=margin:5px 0;|
0230  20 66 6f 6e 74 2d 73 69  7a 65 3a 31 38 70 78 3b  |
font-size:18px;|
0240  20 6c 69 6e 65 2d 68 65  69 67 68 74 3a 31 2e 34  |
line-height:1.4|
0250  3b 63 6f 6c 6f 72 3a 23  30 22 3e 43 6f 6e 63 65
|;color:#0Conce|
0260  72 74 20 50 61 72 69 73  2d 4e 6f 76 65 6d 62 72  |rt
Paris-Novembr|
0270  65 20 28 52 e9 78 78 20  56 79 79 79 79 e9 29 3c  |e (R.xx
V.)|

Inspecting the raw RFC-2822 message, it appears that the bit of HTML
does have content-type Content-Type: text/html; charset=windows-1252.
While I regret that Google did not include redundant metadata within the
text/html bit, there not only there was proper warning that utf-8 this
was not, but also the default encoding was set to be 8859-15. Therefore,
what happened is that Evolution failed to properly convert this fragment
into proper UTF-8 before handing it over to glib (and in any case, it
definitely should have bleached it to not provide an invalid UTF-8
fragment down the HTML renderer). Assigning the blame on Evolution for
sure.

I will gladly provide the raw RFC-2822 offending message, but on a
non-disclosure basis.

Thanks in advance.

-- Cyrille

Bug#462664: evolution-data-server: multiple massive memory leaks in the caldav backend

2008-11-13 Thread Cyrille Chépélov

notforwarded 462664
title 462664 evolution-data-server: multiple massive memory leaks in the caldav 
backend
thanks

[ Hi Roland, how're ya doing? ]

justification of the notforwarded: upstream bug report is not related to 
caldav
(although it is, indeed, related to other memory leaks within E-D-S).


here follows my original bug report which by chance failed to be delivered to 
[EMAIL PROTECTED] 
before I had a chance to notice Roland's earlier report on the same topic.
--
Package: evolution-data-server
Version: 2.22.3-1.1
Severity: important
Justification: try running your system with an E-D-S gobbling up 5G of memory ;)


After a day of use of an Evolution with a single CalDAV calendar, the memory
consumption of E-D-S is very high. Running E-D-S through valgrind yields
a few interesting tracks:

==10847== 505,964 (22,392 direct, 483,572 indirect) bytes in 311 blocks are
definitely lost in loss record 68 of 113
==10847==at 0x4C20FEB: malloc (vg_replace_malloc.c:207)
==10847==by 0x7B4092E: xmlXPathWrapNodeSet (in
/usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B4ED93: (within /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B4CEF0: (within /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B4D6AE: (within /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B4FC74: (within /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B529BB: xmlXPathEvalExpression (in
/usr/lib/libxml2.so.2.6.32)
==10847==by 0xEEFFB8E: xpath_eval (e-cal-backend-caldav.c:497)
==10847==by 0xEEFFF83: synch_slave_loop (e-cal-backend-caldav.c:700)
==10847==by 0x900A4D3: (within /usr/lib/libglib-2.0.so.0.1600.5)
==10847==by 0x9AB8FC6: start_thread (in /lib/libpthread-2.7.so)
==10847==by 0x9D9D7CC: clone (in /lib/libc-2.7.so)

it seems that in function static gboolean
parse_report_response (SoupMessage *soup_message, CalDAVObject **objs, int
*len) from e-cal-backend-caldav.c, no-one attempts to free the
xmlXPathObjects that are returned by function xpath_eval() (the method to
free is xmlXPathFreeObject())

It does not appear that parse_report_response() frees memory in SVN
evolution either.


==10847== 251,005 (22,080 direct, 228,925 indirect) bytes in 184 blocks are
definitely lost in loss record 69 of 113
==10847==at 0x4C20FEB: malloc (vg_replace_malloc.c:207)
==10847==by 0x7B1222D: xmlNewNode (in /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B165B7: xmlNewDocNode (in /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B166A0: xmlNewDocRawNode (in /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B16744: xmlNewTextChild (in /usr/lib/libxml2.so.2.6.32)
==10847==by 0xEEFFD95: synch_slave_loop (e-cal-backend-caldav.c:944)
==10847==by 0x900A4D3: (within /usr/lib/libglib-2.0.so.0.1600.5)
==10847==by 0x9AB8FC6: start_thread (in /lib/libpthread-2.7.so)
==10847==by 0x9D9D7CC: clone (in /lib/libc-2.7.so)
==10847== 

==10847== 49,102 (3,456 direct, 45,646 indirect) bytes in 36 blocks are
definitely lost in loss record 75 of 113
==10847==at 0x4C20FEB: malloc (vg_replace_malloc.c:207)
==10847==by 0x7B11DBA: (within /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B14D56: xmlSetProp (in /usr/lib/libxml2.so.2.6.32)
==10847==by 0xEEFFDC2: synch_slave_loop (e-cal-backend-caldav.c:946)
==10847==by 0x900A4D3: (within /usr/lib/libglib-2.0.so.0.1600.5)
==10847==by 0x9AB8FC6: start_thread (in /lib/libpthread-2.7.so)
==10847==by 0x9D9D7CC: clone (in /lib/libc-2.7.so)
==10847== 

==10847== 38,102 (3,360 direct, 34,742 indirect) bytes in 28 blocks are
definitely lost in loss record 84 of 113
==10847==at 0x4C20FEB: malloc (vg_replace_malloc.c:207)
==10847==by 0x7B11CC6: xmlNewText (in /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B11D6B: xmlNewDocText (in /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B11E23: (within /usr/lib/libxml2.so.2.6.32)
==10847==by 0x7B14D56: xmlSetProp (in /usr/lib/libxml2.so.2.6.32)
==10847==by 0xEEFFDC2: synch_slave_loop (e-cal-backend-caldav.c:946)
==10847==by 0x900A4D3: (within /usr/lib/libglib-2.0.so.0.1600.5)
==10847==by 0x9AB8FC6: start_thread (in /lib/libpthread-2.7.so)
==10847==by 0x9D9D7CC: clone (in /lib/libc-2.7.so)

These three stacks all involve the function caldav_server_list_objects()
(apparently untouched in SVN). It seems to me that nothing ever ties the
root xmlNodePtr (from which all child nodes and attributes are created) to
the xmlDocPtr doc; hence when the document is freed using xmlFreeDoc(doc),
the root node (and its children) are lost.
line 934 might read instead 
root = xmlNewDocNode (doc, NULL, (xmlChar *)calendar-query, 
(xmlChar*)NULL);


==10847== 3,455 (56 direct, 3,399 indirect) bytes in 1 blocks are definitely 
lost in loss record 85 of 113
==10847==at 0x4C20FEB: malloc (vg_replace_malloc.c:207)
==10847==by 0x6C73079: icalproperty_new_impl (in 
/usr/lib/libecal-1.2.so.7.2.0)
==10847==by 0x6C5F28A: icalproperty_new_version (in 
//usr/lib/libecal-1.2.so.7.2.0)
==10847==by 0x6C59727:

Bug#462664: more information, on still reachable memory

2008-11-13 Thread Cyrille Chépélov

after running valgrind again with --leak-check=full and
--show-reachable=yes, it appears that a great deal of the
formally still reachable, but probably quite lost memory originates from
e_cal_backend_cache_get_components() (e-cal-backend-cache.c line 473
specifically, which calls icalparser_parse_string())
It seems this function is identical in SVN

==1641== 5,393,785 bytes in 181,741 blocks are still reachable in loss
record 102 of 107
==1641==at 0x4C1FFAB: malloc (vg_replace_malloc.c:207)
==1641==by 0x9D16DE1: strdup (strdup.c:43)
==1641==by 0x6C61604: icalvalue_set_text
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C6167D: icalvalue_new_text
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C769E2: icalvalue_new_from_string_with_error
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C688BA: icalparser_add_line
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C68CB8: icalparser_parse
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C68F20: icalparser_parse_string
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x69DE5D6: e_cal_backend_cache_get_components
(e-cal-backend-cache.c:473)
==1641==by 0xF4D20EA: synch_slave_loop (e-cal-backend-caldav.c:1259)
==1641==by 0x8FDDCA3: g_thread_create_proxy (gthread.c:635)
==1641==by 0x9A8C016: start_thread (pthread_create.c:297)
==1641== 
==1641== 
==1641== 7,568,054 bytes in 39,280 blocks are still reachable in loss
record 103 of 107
==1641==at 0x4C1F0BC: calloc (vg_replace_malloc.c:397)
==1641==by 0x8FBFA52: g_malloc0 (gmem.c:151)
==1641==by 0x8FABCC8: g_hash_table_new_full (ghash.c:358)
==1641==by 0x8FCE136: g_scanner_new (gscanner.c:228)
==1641==by 0x6ED64CA: e_sexp_new
(in /usr/lib/libedataserver-1.2.so.9.1.0)
==1641==by 0x69DF470: e_cal_backend_sexp_new
(e-cal-backend-sexp.c:1362)
==1641==by 0x69E61E7: impl_Cal_getQuery (e-data-cal.c:415)
==1641==by 0x82B3FA5: ORBit_small_invoke_adaptor
(in /usr/lib/libORBit-2.so.0.1.0)
==1641==by 0x82C327F: (within /usr/lib/libORBit-2.so.0.1.0)
==1641==by 0x82C3839: (within /usr/lib/libORBit-2.so.0.1.0)
==1641==by 0x82AD374: giop_thread_queue_process
(in /usr/lib/libORBit-2.so.0.1.0)
==1641==by 0x82ADB4E: (within /usr/lib/libORBit-2.so.0.1.0)
==1641== 
==1641== 
==1641== 10,416,032 bytes in 325,501 blocks are still reachable in loss
record 104 of 107
==1641==at 0x4C1FFAB: malloc (vg_replace_malloc.c:207)
==1641==by 0x6C7763A: pvl_new_element
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C776A1: pvl_push (in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C6864C: icalparser_add_line
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C68CB8: icalparser_parse
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C68F20: icalparser_parse_string
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x69DE5D6: e_cal_backend_cache_get_components
(e-cal-backend-cache.c:473)
==1641==by 0xF4D20EA: synch_slave_loop (e-cal-backend-caldav.c:1259)
==1641==by 0x8FDDCA3: g_thread_create_proxy (gthread.c:635)
==1641==by 0x9A8C016: start_thread (pthread_create.c:297)
==1641==by 0x9D665BC: clone (in /usr/lib/debug/libc-2.7.so)
==1641== 
==1641== 
==1641== 11,273,560 bytes in 281,839 blocks are still reachable in loss
record 105 of 107
==1641==at 0x4C1FFAB: malloc (vg_replace_malloc.c:207)
==1641==by 0x6C778DA: pvl_newlist (in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C6A093: icalproperty_new_impl
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C68617: icalparser_add_line
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C68CB8: icalparser_parse
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C68F20: icalparser_parse_string
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x69DE5D6: e_cal_backend_cache_get_components
(e-cal-backend-cache.c:473)
==1641==by 0xF4D20EA: synch_slave_loop (e-cal-backend-caldav.c:1259)
==1641==by 0x8FDDCA3: g_thread_create_proxy (gthread.c:635)
==1641==by 0x9A8C016: start_thread (pthread_create.c:297)
==1641==by 0x9D665BC: clone (in /usr/lib/debug/libc-2.7.so)
==1641== 
==1641== 
==1641== 13,541,304 bytes in 241,809 blocks are still reachable in loss
record 106 of 107
==1641==at 0x4C1FFAB: malloc (vg_replace_malloc.c:207)
==1641==by 0x6C6A079: icalproperty_new_impl
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C68617: icalparser_add_line
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C68CB8: icalparser_parse
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x6C68F20: icalparser_parse_string
(in /usr/lib/libecal-1.2.so.7.2.0)
==1641==by 0x69DE5D6: e_cal_backend_cache_get_components
(e-cal-backend-cache.c:473)
==1641==by 0xF4D20EA: synch_slave_loop (e-cal-backend-caldav.c:1259)
==1641==by 0x8FDDCA3: g_thread_create_proxy (gthread.c:635)
==1641==by 0x9A8C016: start_thread (pthread_create.c:297)
==1641==by 0x9D665BC: clone (in /usr/lib/debug/libc-2.7.so)
==1641== 
==1641== 
==1641== 36,754,968 bytes in 241,809

Bug#505248: evolution: CalDAV calendars can be stuck in 'offline' mode, unusable

2008-11-10 Thread Cyrille Chépélov

Package: evolution
Version: 2.22.3.1-1
Severity: important
Justification: once the calendars are stuck, a whole part of the
application is dead


When using remote calendars accessed over CalDAV/https on a pair of
davical
servers, evolution can paint itself in a corner where it will then
absolutely refuse to access said calendars.

Steps to reproduce:

prerequisites
the only network link (say, Wifi and/or 3G) is transient and managed by
network-manager

it MAY be possible that this procedure only reproduces the issue if evo
has been deep-closed (evo+EDS both down, e.g reboot) while online and
with an active connection.

procedure:
* start a fresh GDM session with no network connections active, or make
sure there are no network connections active and kill -9 all evolution
components

* click on the GNOME clock widget to display the calendar
* hide the calendar

* start evo. It will (correctly, at this point) show as offline

* establish the network connection. Evolution should pick up the
  connection immediately. IMAP or POP mailboxes should typically
  start syncing.

* go to the calendar panel. Try to access (caldav) calendars.
  Regardless of the status of the make available offline checkbox,
Evo will stubbornly refuse to display the calendars, claiming (wrongly)
that these have not been made or requested for offline use.

  Cycling the online/offline button changes nothing (except more
traffic on the POP/IMAP front)

workaround procedure:
* once the network connection is established, ensure evo is in
online state, then stop it. 

* ensure, a -9 signal ready at hand, that EDS is down as well.

* start evo again; it should now pick the calendars up again.

Thanks in advance

-- Cyrille

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (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/bash

Versions of packages evolution depends on:
ii  dbus   1.2.1-3   simple interprocess
messaging syst
ii  evolution-common   2.22.3.1-1architecture independent
files for
ii  evolution-data-server  2.22.3-1  evolution database backend
server
ii  gconf2 2.22.0-1  GNOME configuration
database syste
ii  gnome-icon-theme   2.22.0-1  GNOME Desktop icon theme
ii  gtkhtml3.143.18.3-1  HTML rendering/editing
library - b
ii  libart-2.0-2   2.3.20-2  Library of functions for 2D
graphi
ii  libatk1.0-01.22.0-1  The ATK accessibility
toolkit
ii  libbluetooth2  3.36-1Library to use the BlueZ
Linux Blu
ii  libbonobo2-0   2.22.0-1  Bonobo CORBA interfaces
library
ii  libbonoboui2-0 2.22.0-1  The Bonobo UI library
ii  libc6  2.7-14GNU C Library: Shared
libraries
ii  libcairo2  1.6.4-6   The Cairo 2D vector
graphics libra
ii  libcamel1.2-11 2.22.3-1  The Evolution MIME message
handlin
ii  libdbus-1-31.2.1-3   simple interprocess
messaging syst
ii  libdbus-glib-1-2   0.76-1simple interprocess
messaging syst
ii  libebook1.2-9  2.22.3-1  Client library for
evolution addre
ii  libecal1.2-7   2.22.3-1  Client library for
evolution calen
ii  libedataserver1.2-92.22.3-1  Utility library for
evolution data
ii  libedataserverui1.2-8  2.22.3-1  GUI utility library for
evolution 
ii  libegroupwise1.2-132.22.3-1  Client library for
accessing group
ii  libexchange-storage1.2 2.22.3-1  Client library for
accessing Excha
ii  libfontconfig1 2.6.0-1   generic font configuration
library
ii  libfreetype6   2.3.7-2   FreeType 2 font engine,
shared lib
ii  libgconf2-42.22.0-1  GNOME configuration
database syste
ii  libglade2-01:2.6.2-1 library to load .glade
files at ru
ii  libglib2.0-0   2.16.6-1  The GLib library of C
routines
ii  libgnome-pilot22.0.15-2.4Support libraries for
gnome-pilot
ii  libgnome2-02.20.1.1-1The GNOME 2 library -
runtime file
ii  libgnomecanvas2-0  2.20.1.1-1A powerful object-oriented
display
ii  libgnomeui-0   2.20.1.1-2The GNOME 2 libraries (User
Interf
ii  libgnomevfs2-0 1:2.22.0-5GNOME Virtual File System
(runtime
ii  libgtk2.0-02.12.11-3 The GTK+ graphical user
interface 
ii  libgtkhtml3.14-19  3.18.3-1  HTML rendering/editing
library - r
ii  libhal10.5.11-5  Hardware Abstraction Layer
- share
ii  libice6

Bug#505249: evolution: silently fails to completely copy calendars

2008-11-10 Thread Cyrille Chépélov

Package: evolution
Version: 2.22.3.1-1
Severity: grave
Justification: causes non-serious data loss


Over the time, I have grown several local calendars in Evo (about a
hundred entries each). Turns out that verious versions of evo failed to
properly sanitize inputs, so some events are (properly) in UTF-8, others
(mostly events coming from Exchange or Notes parties) are in
iso-8859-15.

When trying to copy those calendars over to CalDAV, the copy initially
appeared to work, as in random events were successfully copied over and
evo did not complain. However, it turns out that Evo stopped prematurely
and silently.

Exporting the calendars as .ics files appears to produce complete files
(although I cannot be sure, it seems everything I expect to see there is
indeed exported). No software package I tried was able to successfully
use these .ics files, as the VEvents with mojibake typically stop the
process (davical's import, iceowl, etc.). Evolution is a major offender
here, as those VEvents *silently* stop the import process, with no clue
that it stopped prematurely other than missing events.

Proper correction of this bug is three-fold:
1. Evolution should never export .ics files with invalid UTF-8.
Ever. It should instead ask the user for help with the encoding.
2. Evolution should never store events without first sanitizing the
contents with respect to character sets. Asking the user in context (or
using the metadata that might be provided or inferred from the foreign
calendar) is easier right away than at export time, much later.
3. Evolution should never silently stop the import or copy process for
encoding issues. It should at the minimum reject (atomically) the
whole .ics file; a much nicer way would be to import valid entries and
produce a .ics file with the rejected entries. The best way would be to
provide a clean-up wizard asking the user for assistance to complete
the import task.

Thanks in advance

-- Cyrille

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (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/bash

Versions of packages evolution depends on:
ii  dbus   1.2.1-3   simple interprocess
messaging syst
ii  evolution-common   2.22.3.1-1architecture independent
files for
ii  evolution-data-server  2.22.3-1  evolution database backend
server
ii  gconf2 2.22.0-1  GNOME configuration
database syste
ii  gnome-icon-theme   2.22.0-1  GNOME Desktop icon theme
ii  gtkhtml3.143.18.3-1  HTML rendering/editing
library - b
ii  libart-2.0-2   2.3.20-2  Library of functions for 2D
graphi
ii  libatk1.0-01.22.0-1  The ATK accessibility
toolkit
ii  libbluetooth2  3.36-1Library to use the BlueZ
Linux Blu
ii  libbonobo2-0   2.22.0-1  Bonobo CORBA interfaces
library
ii  libbonoboui2-0 2.22.0-1  The Bonobo UI library
ii  libc6  2.7-14GNU C Library: Shared
libraries
ii  libcairo2  1.6.4-6   The Cairo 2D vector
graphics libra
ii  libcamel1.2-11 2.22.3-1  The Evolution MIME message
handlin
ii  libdbus-1-31.2.1-3   simple interprocess
messaging syst
ii  libdbus-glib-1-2   0.76-1simple interprocess
messaging syst
ii  libebook1.2-9  2.22.3-1  Client library for
evolution addre
ii  libecal1.2-7   2.22.3-1  Client library for
evolution calen
ii  libedataserver1.2-92.22.3-1  Utility library for
evolution data
ii  libedataserverui1.2-8  2.22.3-1  GUI utility library for
evolution 
ii  libegroupwise1.2-132.22.3-1  Client library for
accessing group
ii  libexchange-storage1.2 2.22.3-1  Client library for
accessing Excha
ii  libfontconfig1 2.6.0-1   generic font configuration
library
ii  libfreetype6   2.3.7-2   FreeType 2 font engine,
shared lib
ii  libgconf2-42.22.0-1  GNOME configuration
database syste
ii  libglade2-01:2.6.2-1 library to load .glade
files at ru
ii  libglib2.0-0   2.16.6-1  The GLib library of C
routines
ii  libgnome-pilot22.0.15-2.4Support libraries for
gnome-pilot
ii  libgnome2-02.20.1.1-1The GNOME 2 library -
runtime file
ii  libgnomecanvas2-0  2.20.1.1-1A powerful object-oriented
display
ii  libgnomeui-0   2.20.1.1-2The GNOME 2 libraries (User
Interf
ii  libgnomevfs2-0 1:2.22.0-5GNOME Virtual File System
(runtime
ii  libgtk2.0-02.12.11-3 The GTK+ graphical user
interface 
ii  libgtkhtml3.14-19  3.18.3-1  HTML rendering/editing
library

Bug#505250: linux-image-2.6.26-1-686: Acer Aspire One sound patch from post-2.6.26 git applies cleanly

2008-11-10 Thread Cyrille Chépélov

Package: linux-image-2.6.26-1-686
Version: 2.6.26-8
Severity: wishlist


On the Acer Aspire One A110 netbook computer, the default behaviour of
the snd-hda-intel driver is to not set correctly the output gain.
Depending on the boot lottery, there is either quite mute or no sound.
When applying the classic model=acer modprobe tweak, the sound is loud
and reasonably correct; this is good, EXCEPT that the sensor on the
headphone jack is disabled: plugging in a headphone will fail to disable
the internal loudspeakers, which may be bad for some users.

A Realtek engineer, Kailang Yang, provided a patch for that. The patch
is commit 8ef355da64ff087b6f26c4c28a14753861e83e4b in the git tree, from
sometime between v2.6.26 and v2.6.28-rc4.

I verified that this patch applies cleanly on the tree as provided by
Debianin the 2.6.26 package (there is fuzz for a couple hundred lines on
all 8 hunks, but it applies fine). After this patch is applied and the
kernel rebuilt, providing 
options snd-hda-intel model=acer-aspire
in a file in /etc/modprobe.d fixes the sound: it's loud when requested,
and the loudspeaker's off when a headphone is plugged in.

Please consider applying if a new rev of the 2.6.26 package is due.
Please consider applying in 2.6.27 as well (if 8ef355da is after 2.6.27)
otherwise.

Thanks in advance

-- Cyrille

-- Package-specific info:
** Version:
Linux version 2.6.26-1-686 (Debian 2.6.26-8) ([EMAIL PROTECTED]) (gcc
version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 SMP Thu Oct 9
15:18:09 UTC 2008

** Command line:
root=/dev/mapper/sda5_crypt ro clocksource=hpet usb.autosuspend=1
elevator=deadline 

** Tainted: P (1)

** Kernel log: 
[   21.090856] uvcvideo: Found UVC 1.00 device USB 2.0 Camera
(0c45:62c0)
[   21.114857] input: USB 2.0 Camera as /class/input/input9
[   21.139048] usbcore: registered new interface driver uvcvideo
[   21.139139] USB Video Class driver (v0.1.0)
[   21.555044] wifi0: Atheros AR2425 chip found (MAC 14.2, PHY SChip
7.0, Radio 10.2)
[   21.687737] Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps:
0xd04771/0xa4
[   21.735263] ath_pci: wifi0: Atheros 5424/2424: mem=0x7520, irq=18
[   21.739159] ACPI: PCI Interrupt :00:1b.0[A] - GSI 16 (level,
low) - IRQ 16
[   21.739159] PCI: Setting latency timer of device :00:1b.0 to 64
[   21.744125] input: SynPS/2 Synaptics TouchPad as /class/input/input10
[   21.771408] hda_codec: Unknown model for ALC268, trying auto-probe
from BIOS...
[   21.807602] ACPI: PCI Interrupt :04:00.3[A] - GSI 19 (level,
low) - IRQ 19
[   21.807602] PCI: Setting latency timer of device :04:00.3 to 64
[   21.810565] ACPI: PCI Interrupt :00:1f.3[B] - GSI 17 (level,
low) - IRQ 17
[   28.242522] loop: module loaded
[   28.595641] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   36.476787] fuse init (API version 7.9)
[   36.869975] ReiserFS: dm-1: found reiserfs format 3.6 with standard
journal
[   36.869975] ReiserFS: dm-1: using ordered data mode
[   36.870713] ReiserFS: dm-1: journal params: device dm-1, size 8192,
journal first block 18, max trans len 1024, max batch 900, max commit
age 30, max trans age 30
[   36.870713] ReiserFS: dm-1: checking transaction log (dm-1)
[   36.877358] ReiserFS: dm-1: Using r5 hash to sort names
[   44.988428] firmware: requesting intel-ucode/06-1c-02
[   45.006182] firmware: requesting intel-ucode/06-1c-02
[   45.030675] IA-32 Microcode Update Driver: v1.14a
[EMAIL PROTECTED]
[   45.198341] microcode: CPU0 updated from revision 0x208 to 0x20a,
date = 06042008 
[   45.199084] microcode: CPU1 updated from revision 0x208 to 0x20a,
date = 06042008 
[   46.415089] NET: Registered protocol family 10
[   46.415089] lo: Disabled Privacy Extensions
[   50.194954] lp: driver loaded but no devices found
[   50.312209] ppdev: user-space parallel port driver
[   52.487281] warning: `ntpd' uses 32-bit capabilities (legacy support
in use)
[   59.752574] r8169: eth1: link down
[   59.752574] ADDRCONF(NETDEV_UP): eth1: link is not ready
[   61.516521] [drm] Initialized drm 1.1.0 20060810
[   61.532507] ACPI: PCI Interrupt :00:02.0[A] - GSI 16 (level,
low) - IRQ 16
[   61.532507] PCI: Setting latency timer of device :00:02.0 to 64
[   61.532629] [drm] Initialized i915 1.6.0 20060119 on minor 0
[   61.752374] mtrr: no more MTRRs available
[   70.354308] ath0: no IPv6 routers present
[  175.964421] ACPI: PCI interrupt for device :00:1b.0 disabled
[  183.943549] ACPI: PCI Interrupt :00:1b.0[A] - GSI 16 (level,
low) - IRQ 16
[  183.943549] PCI: Setting latency timer of device :00:1b.0 to 64
[  185.169148] hda_intel: azx_get_response timeout, switching to polling
mode: last cmd=0x003ba000
[  257.080721] ACPI: PCI interrupt for device :00:1b.0 disabled
[  293.197010] ACPI: PCI Interrupt :00:1b.0[A] - GSI 16 (level,
low) - IRQ 16
[  293.197010] PCI: Setting latency timer of device :00:1b.0 to 64
[  332.059279] mtrr: no more MTRRs available
[  396.732865] ACPI:

Bug#481407: iceweasel: (experimental) violently crashes on the Java plug-in

2008-05-16 Thread Cyrille Chépélov


Mike Hommey wrote:


Compounding issues are that this is an x86-64, and the ancient Blackdown 1.4
JVM from j2re1.4-mozilla-plugin (but there is STILL no newer solution)

The same version on an x86 (eeePC) with a Sun 1.6 JVM appears to work fine.


Could you try with the same ancient version on x86 ?


Will do, about 24 hours from now.


The previous (~b4) package had serious rendering issues on this machine but
DID allow the JVM to run.


Did it work with 3.0~b5-3 ?


No idea, but I can gladly try (please provide an URL)

-- Cyrille



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#481407: iceweasel: (experimental) violently crashes on the Java plug-in

2008-05-15 Thread Cyrille Chépélov

Package: iceweasel
Version: 3.0~b5-4
Severity: important


This version of the experimental package crashes violently on any page using
Java. 

It seems that the plugin manager now enters an infinite stack recursion
condition; extract from gdb:

--8--
#2427 0x2f918eae in CPluginServiceProvider::QueryService () from
/usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#2428 0x2f91c213 in JavaPluginFactory5::Initialize () from
#/usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#2429 0x2f91b823 in JavaPluginFactory5::Create () from
#/usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#2430 0x2f918842 in NSGetFactory () from
#/usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#2431 0x2b7d622bb618 in nsPluginFile::GetPluginInfo
#(this=0x7fff4a486f00, [EMAIL PROTECTED]) at nsPluginsDirUnix.cpp:453
#2432 0x2b7d622b2fab in nsPluginHostImpl::ScanPluginsDirectory
#(this=0x9e7200, pluginsDir=value optimized out, compManager=value
#optimized out, aCreatePluginList=1, aPluginsChanged=0x7fff4a487044,
#checkForUnwantedPlugins=0) at nsPluginHostImpl.cpp:5181
#2433 0x2b7d622b3235 in nsPluginHostImpl::ScanPluginsDirectoryList
#(this=0x9e7200, dirEnum=0x4016f30, compManager=0x67e370,
#aCreatePluginList=1, aPluginsChanged=0x7fff4a4870f8,
#checkForUnwantedPlugins=0) at nsPluginHostImpl.cpp:5284
#2434 0x2b7d622b3390 in nsPluginHostImpl::FindPlugins (this=0x9e7200,
#aCreatePluginList=1, aPluginsChanged=0x7fff4a48714c) at
#nsPluginHostImpl.cpp:5376
#2435 0x2b7d622b351c in nsPluginHostImpl::LoadPlugins
#(this=0x7fff4a42dd10) at nsPluginHostImpl.cpp:5304
#2436 0x2b7d622a9398 in nsPluginHostImpl::FindPluginForType
#(this=0x7fff4a42dd10, aMimeType=0x7fff4a42abe0 Address 0x7fff4a42abe0 out
#of bounds, aCheckEnabled=4096) at nsPluginHostImpl.cpp:4495
#2437 0x2b7d622aa1bd in nsPluginHostImpl::IsPluginEnabledForType
#(this=0x7fff4a42dd10, aMimeType=0x7fff4a42abe0 Address 0x7fff4a42abe0 out
#of bounds) at nsPluginHostImpl.cpp:4213
#2438 0x2b7d6237dc2f in nsJVMManager (this=0x4024520, outer=0x4024550)
#at nsJVMManager.cpp:395
#2439 0x2b7d62382a7a in nsJVMManagerConstructor (aOuter=0x0,
[EMAIL PROTECTED], aResult=0x7fff4a4872b0) at
#nsCJVMManagerFactory.cpp:57
#2440 0x2b7d6240bbf2 in nsComponentManagerImpl::CreateInstance
#(this=value optimized out, aClass=value optimized out, aDelegate=0x0,
[EMAIL PROTECTED], aResult=0x7fff4a4872b0) at
#nsComponentManager.cpp:1670
#2441 0x2b7d6240d661 in nsComponentManagerImpl::GetService
#(this=0x67e370, [EMAIL PROTECTED], [EMAIL PROTECTED],
#result=0x4014df0) at nsComponentManager.cpp:1882
#2442 0x2f918eae in CPluginServiceProvider::QueryService () from
#/usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#2443 0x2f91c213 in JavaPluginFactory5::Initialize () from
#/usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#2444 0x2f91b823 in JavaPluginFactory5::Create () from
#/usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#2445 0x2f918842 in NSGetFactory () from
#/usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
88---

Compounding issues are that this is an x86-64, and the ancient Blackdown 1.4
JVM from j2re1.4-mozilla-plugin (but there is STILL no newer solution)

The same version on an x86 (eeePC) with a Sun 1.6 JVM appears to work fine.

The previous (~b4) package had serious rendering issues on this machine but
DID allow the JVM to run. Current 2.0.0.x package do run the very same JVM
kind of fine (about 20% chance of crash upon initialization)

-- Cyrille



-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.23-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages iceweasel depends on:
ii  debianutils2.28.2Miscellaneous utilities specific t
ii  fontconfig 2.4.2-1.2 generic font configuration library
ii  libc6  2.7-10GNU C Library: Shared libraries
ii  libglib2.0-0   2.16.3-2  The GLib library of C routines
ii  libgtk2.0-02.12.9-3  The GTK+ graphical user interface 
ii  libnspr4-0d4.7.0~1.9b1-2 NetScape Portable Runtime Library
ii  libstdc++6 4.3.0-3   The GNU Standard C++ Library v3
ii  procps 1:3.2.7-6 /proc file system utilities
ii  psmisc 22.5-1Utilities that use the proc filesy
ii  xulrunner-1.9  1.9~b5-4  XUL + XPCOM application runner

iceweasel recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.

Bug#462014: xserver-xorg-video-radeonhd: wrong selection of available resolution

2008-01-26 Thread Cyrille Chépélov

The elements requested by upstream have been added at the URL you
quoted.

Thanks

On ven, 2008-01-25 at 13:37 +0100, Brice Goglin wrote:
 The upstream developer (at http://bugs.freedesktop.org/show_bug.cgi?id=14234)
 would like the log of 'X -logverbose 7'. Could you send it
 with the above git version of radeonhd?
 Either send it to me or post it directly at the URL above.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#462014: xserver-xorg-video-radeonhd: wrong selection of available resolution

2008-01-21 Thread Cyrille Chépélov


On mar, 2008-01-22 at 00:37 +0100, Brice Goglin wrote:
 Can you try latest upstream git? And if it doesn't work, given how young
 radeonhd is, this should be directly discussed upstream, most likely by
 reporting a bug against xorg/radeonhd on bugzilla.freedesktop.org.

found the same results with 1.0.0-76-gbc88513. I guess, indeed, I'll
have to hit bugzilla (most likely by forwarding this, initially, so if
you're set up to bring it upstream efficiently already, I wouldn't mind
if you did so, I'll monitor there)

 By the way, you might also want to try xserver-xorg-video-ati from
 experimental (6.7.198...), it contains some support for your board.

xserver-xorg-video-ati 1:6.7.198~git20080117.6bd510a2-1 now installed.
Will try tomorrow and report.

Thanks!

-- Cyrille





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451756: add a /usr/share/bug/compiz script to bring more diag info

2007-11-18 Thread Cyrille Chépélov

Package: compiz
Version: 0.5.2-2
Severity: wishlist


please add a /usr/share/bug/compiz/script script to bring more information
during reportbug calls, such as the output of
   fglrx # if installed 
   glxinfo |grep direct
   glxinfo |grep vendor
   gconftool --get /apps/compiz/general/allscreens/options/active_plugins
etc.

this might help speed up the diagnostics (or help some users abort their
submission and solve the problem directly)

-- Cyrille   

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages compiz depends on:
ii  compiz-core 0.6.3~git20071104.c9009efd-1 OpenGL window and compositing mana
ii  compiz-gnom 0.6.3~git20071104.c9009efd-1 OpenGL window and compositing mana
ii  compiz-gtk  0.6.3~git20071104.c9009efd-1 OpenGL window and compositing mana
ii  compiz-plug 0.6.3~git20071104.c9009efd-1 OpenGL window and compositing mana

compiz recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451706: compiz yields a blank white screen

2007-11-18 Thread Cyrille Chépélov

[CC'ing fglrx-driver's maintainer]

Le dimanche 18 novembre 2007 à 00:38 +0100, Brice Goglin a écrit :
  FWIW, the pointers shown did follow the mouse pointer theme as set up in
  GNOME.
 
 http://bgoglin.livejournal.com/11253.html could possibly help a bit, but
 your problem looks much worse than what we usually observe.

ran the gconftool set-up line, as a matter of preemptive troubleshooting
(might be a good idea to check the presence of the decorate plugin as
part of /usr/bin/compiz, by the way)

  The fglrx driver may very well be the trouble maker...
 
 Right. Could be related to http://ubuntuforums.org/showthread.php?t=595213

The problems described there indeed look like it, indeed!
fglrxinfo showed the problem immediately; the fglrx kernel driver was
*not* loaded, so GL fell back on Mesa, which produced the WSOD.

  (this exchange gave me a few ideas, see #451756 )

now that I not only ran m-a a-i fglrx-driver but modprobed it as well
(duh), running compiz --replace yields:

GLX_EXT_texture_from_pixmap is not available with direct rendering.
GLX_EXT_texture_from_pixmap is not available with indirect rendering.
Aborting!

Manually grepping through glxinfo gives that GLX_EXT_texture_from_bitmap
is both a server and client glx extension.

running glxinfo with LIBGL_ALWAYS_INDIRECT=1 breaks with 
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  144 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  16
  Current serial number in output stream:  16

I suspected that the tests -lt 3 in /usr/bin/compiz might have been
bogus; so I tried commenting out the exit 1 there. Result:

/usr/bin/compiz.real (core) - Fatal: GLX_EXT_texture_from_pixmap is
missing
/usr/bin/compiz.real (core) - Error: Failed to manage screen: 0
/usr/bin/compiz.real (core) - Fatal: No manageable screens found on
display :0.0

Seems #451706 is probably not a bug (save for a couple more safeties,
such as refusing to run if the system appears to want to run with fglrx
but fglrx is not present and/or flgrx is here but the actual GLX
renderer is Mesa == White Screen of Death), but a failure of fglrx to
provide the required extensions, despite what I understood as recent
positive claims. 

As a bonus, it would be good if, upon fatal exit
of /usr/bin/compiz.real, /usr/bin/compiz attempted to restart a useable
WM (might be a tricky information to grab)

Thanks

-- Cyrille

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon X1200 Series
OpenGL version string: 2.0.6958 Release
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, 
GL_ARB_fragment_shader, GL_ARB_multisample, GL_ARB_multitexture, 
GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, 
GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow, 
GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, 
GL_ARB_texture_compression, GL_ARB_texture_cube_map, 
GL_ARB_texture_env_add, GL_ARB_texture_env_combine, 
GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, 
GL_ARB_texture_float, GL_ARB_texture_mirrored_repeat, 
GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, 
GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, 
GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_envmap_bumpmap, 
GL_ATI_fragment_shader, GL_ATI_meminfo, GL_ATI_separate_stencil, 
GL_ATI_texture_compression_3dc, GL_ATI_texture_env_combine3, 
GL_ATI_texture_float, GL_EXT_bgra, GL_EXT_blend_color, 
GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
GL_EXT_compiled_vertex_array, GL_EXT_copy_texture, 
GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_object,

Bug#451703: white screen of death under compiz

2007-11-18 Thread Cyrille Chépélov

[CC'ing your debian bug report, to alert the maintainer]

Hi David,

your report looks oddly similar to mine, save for the brand of your
graphics adapter... can you have a peek at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451706 in case Brice's
suggestions are applicable, or at least to help reach a decision on
whether we have duplicate or separate issues?

in particular, what is the output of 

glxinfo|grep direct
glxinfo|grep vendor
glxinfo|grep GLX_EXT_texture_from_pixmap
LIBGL_ALWAYS_INDIRECT=1 glxinfo|grep GLX_EXT_texture_from_pixmap

-- Cyrille




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451706: closed by Brice Goglin [EMAIL PROTECTED] (Re: Bug#451706: compiz yields a blank white screen)

2007-11-18 Thread Cyrille Chépélov


Le dimanche 18 novembre 2007 à 10:18 +, Debian Bug Tracking System a
écrit :

   Seems #451706 is probably not a bug (save for a couple more
  safeties,
   such as refusing to run if the system appears to want to run with
  fglrx
   but fglrx is not present and/or flgrx is here but the actual GLX
   renderer is Mesa == White Screen of Death), but a failure of
  fglrx to
   provide the required extensions, despite what I understood as
  recent
   positive claims. 

  Ok I am closing this bug then.
fine; although the WSOD issues probably deserve a few bits of safeties
in the wrapper script IMO.

  Out of curiosuty: Did you upgrade fglrx recently and just forgot to
  rebuild the kernel module? Was this upgrade supposed to change
  anything
  for compiz?

Yes, I did upgrade fglrx, rebuilt the kernel module, but forgot to add
it in /etc/modules (last times, I had always modprobed it manually, out
of distrust, but after several weeks of runtime, I grew confident enough
to just assume it was there...)
Not quite sure the last upgrade was supposed to change much, it just got
pulled in with the last upgrade. What was new is that I had some time to
play with compiz, which I had not had beforehand.

will keep trying whenever AMD pushes something new.

-- Cyrille

Bug#451706: compiz yields a blank white screen

2007-11-17 Thread Cyrille Chépélov

Package: compiz
Version: 0.5.2-2
Severity: important

On this system, running compiz --replace returns an empty screen, with
only the mouse pointer. The mouse seems active, does change according to
what is guessed to be under it, and applications may apparently be run.

FWIW, the pointers shown did follow the mouse pointer theme as set up in
GNOME.

The fglrx driver may very well be the trouble maker...

   -- Cyrille

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages compiz depends on:
ii  compiz-core 0.6.3~git20071104.c9009efd-1 OpenGL window and compositing mana
ii  compiz-gnom 0.6.3~git20071104.c9009efd-1 OpenGL window and compositing mana
ii  compiz-gtk  0.6.3~git20071104.c9009efd-1 OpenGL window and compositing mana
ii  compiz-plug 0.6.3~git20071104.c9009efd-1 OpenGL window and compositing mana

compiz recommends no packages.

ii  fglrx-driver 8.42.3-3 display driver for the ATI graphics cards
ii  xserver-xorg 1:7.3+3  the X.Org X server

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#449346: kvm: network sometimes just stops

2007-11-17 Thread Cyrille Chépélov


Le vendredi 16 novembre 2007 à 11:31 +0100, Jan Lübbe a écrit :
 Could you try to reproduce the problem with the current version in
 unstable (52)?
 

Lacked time to do it properly, so I skipped the ne2k_pci under kvm-48
test, but now ne2k_pci under kvm-52 shows an appearance of correct
operation, with the caveat that the console sees frequent NETDEV
WATCHDOG: eth0 transmit timeout message under network stress (none were
appearing during the -48 days). 

I can attempt to do more specific tests if you wish; for the time being
this VM will stay as is (ne2k_pci, KVM-52) until it breaks (or not).

-- Cyrille

Bug#449346: kvm: network sometimes just stops

2007-11-05 Thread Cyrille Chépélov

Package: kvm
Version: 46+dfsg-0.1
Severity: important

since running the current versions of kvm + kernel, my guest machine drops
the network after a while (not much in the way of a correlation with
anything that I can see so far, except perhaps heavy network activity). So
far I'm a bit lost with what I might do to help narrow down the problem.

It *seems* that the guest netdev watchdog triggers sometimes, but it's for
now unclear. Can't bring up much more info before about 12 hours from now.

Regards,

-- Cyrille

-- Package-specific info:


selected information from lshal(1):

  smbios.bios.release_date = '05/17/2007'  (string)
  smbios.bios.vendor = 'Phoenix Technologies, LTD'  (string)
  smbios.bios.version = 'ASUS M2A-VM ACPI BIOS Revision 0601'  (string)
  smbios.chassis.manufacturer = 'Chassis Manufacture'  (string)
  smbios.chassis.type = 'Desktop'  (string)
  smbios.system.manufacturer = 'System manufacturer'  (string)
  smbios.system.product = 'System Product Name'  (string)
  smbios.system.serial = 'System Serial Number'  (string)
  smbios.system.uuid = 'BB0F29A9-1336-58CE-E668-1103009A3329'  (string)
  smbios.system.version = 'System Version'  (string)
  system.product = 'System Product Name System Version'  (string)
  system.vendor = 'System manufacturer'  (string)


/proc/cpuinfo:

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 107
model name  : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping: 1
cpu MHz : 2300.027
cache size  : 512 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 
3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse
bogomips: 4603.48
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 107
model name  : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping: 1
cpu MHz : 2300.027
cache size  : 512 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 
3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse
bogomips: 4600.29
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps




-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages kvm depends on:
ii  adduser 3.105add and remove users and groups
ii  bridge-utils1.2-2Utilities for configuring the Linu
ii  iproute 20070313-1   Professional tools to control the 
ii  libasound2  1.0.14a-2ALSA library
ii  libc6   2.6.1-1  GNU C Library: Shared libraries
ii  libsdl1.2debian 1.2.11-9 Simple DirectMedia Layer
ii  zlib1g  1:1.2.3.3.dfsg-6 compression library - runtime

Versions of packages kvm recommends:
ii  kvm-source 46+dfsg-0.1   Source for the KVM driver
ii  linux-image-2.6.22 2.6.22-3  Linux 2.6.22 image on AMD64
ii  qemu   0.9.0+20070816-1  fast processor emulator
ii  vde2   2.1.6+r154-1+b1   Virtual Distributed Ethernet

-- no debconf information


GUEST SYSTEM: 

ii  linux-image-2.6.22-2-686 2.6.22-4 Linux 2.6.22 image on 
PPro/Celeron/PII/PIII/P4

running an otherwise vanilla 'lenny' 32-bit system.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#449346: Startup script

2007-11-05 Thread Cyrille Chépélov

here is the KVM startup script I use



run-venilia.sh
Description: application/shellscript

Bug#440508: [patch] provide a way around the lack of MPEG2 encoder

2007-09-03 Thread Cyrille Chépélov

this patch (already posted in #440216), which ought to be taken with
huge WORKS FOR ME gloves, works around the problem for me.

In order to do this, I had to fall back on the MPEG1 encoder, with tons
and tons of key frames thrown in to limit the display jagginess.

Why the big WORKS FOR ME gloves:
1. only ever tested here
2. on a 720p HDMI(DVI-D) display
3. through a HD module on Ethernet only
4. meaning, no consideration for possibly more constrained situations
(V5-HD through wifi/mimo, V4, interlaced SD display, etc) were taken. 

However, things looks acceptably great here.

-- Cyrille

Les fichiers binaires http-fbx.vanilla/freeplayer.gif et http-fbx/freeplayer.gif sont différents.
diff -u http-fbx.vanilla/play.html http-fbx/play.html
--- http-fbx.vanilla/play.html	2007-05-31 15:35:57.0 +0200
+++ http-fbx/play.html	2007-09-02 01:51:28.0 +0200
@@ -72,13 +72,13 @@
 
 		!-- audio/video with transcoding --
 		vlc id=if param1=type value 3 = /
-			vlc id=rpn param1=qfile value ' :sout=#transcode:std :sout-transcode-ab=256 :sout-transcode-acodec=mpga :sout-transcode-channels=2 :sout-transcode-vb=9000 :sout-transcode-vcodec=mp2v :sout-transcode-vt=100 :sout-transcode-fps=25.0 :sout-ffmpeg-keyint=24 :sout-ffmpeg-interlace :no-sout-ffmpeg-interlace-me :file-caching=1000 :sout-transcode-soverlay' strcat name value playlist_add vlc_play /
+			vlc id=rpn param1=qfile value ' :sout=#transcode:std :sout-transcode-ab=256 :sout-transcode-acodec=mpga :sout-transcode-channels=2 :sout-transcode-vb=12000 :sout-transcode-vcodec=mp1v :sout-transcode-vt=100 :sout-transcode-fps=25.0 :sout-ffmpeg-hurry-up=0 :sout-ffmpeg-hq=bits :sout-ffmpeg-keyint=2 :no-sout-ffmpeg-interlace-me :file-caching=1000 :sout-transcode-soverlay :sout-transcode-threads=2 :sout-ffmpeg-mpeg4-matrix=1' strcat name value playlist_add vlc_play /
 			meta name=panel_notify content=vlc id=value param1=panel value /
 		vlc id=end /
 
 		!-- picture --
 		vlc id=if param1=type value 4 = /
-			vlc id=rpn param1='fake: :sout=#transcode:std :fake-width=720 :fake-height=576 :fake-aspect-ratio=4:3 :fake-keep-ar :fake-deinterlace :deinterlace-mode=blend :sout-transcode-vb=9000 :sout-transcode-vcodec=mp2v :sout-transcode-vt=100 :sout-ffmpeg-keyint=8 :sout-ffmpeg-interlace :no-sout-ffmpeg-interlace-me :fake-file=' qfile value strcat name value playlist_add vlc_play /
+			vlc id=rpn param1='fake: :sout=#transcode:std :fake-width=720 :fake-height=576 :fake-aspect-ratio=4:3 :fake-keep-ar :fake-deinterlace :deinterlace-mode=blend :sout-transcode-vb=9000 :sout-transcode-vcodec=mp1v :sout-transcode-vt=100 :sout-ffmpeg-keyint=8 :no-sout-ffmpeg-interlace-me :fake-file=' qfile value strcat name value playlist_add vlc_play /
 			meta name=panel_notify content=vlc id=value param1=panel value /
 		vlc id=end /
 
Seulement dans http-fbx: play.html~

Bug#440702: ffmpeg: surprise removal of MPEG2 encoding capability

2007-09-03 Thread Cyrille Chépélov

Package: ffmpeg
Version: 0.cvs20070307-6
Severity: important


#439897 notwithstanding, version 0.cvs20070307-6 of the package added a
debian/strip.sh script to disable MPEG2 encoding capabilities. It might not
yet be disabled in all scenarios, but it has been disabled in an important
capability, making it useless to a large class of users in a specific
locale.

Precisely, encoding on the fly as a stream output has been broken from the
point of view of vlc, which breaks freeplayer. See bugs #440216, #440508.
Yet, apart from this excerpt from the changelog.Debian:
  * Add debian/strip.sh to strip ffmpeg upstream source disabling mpeg
based encoders as discussed with ftp-master at debconf7
there appears to be zero information about the rationale for this removal in
/usr/share/doc/ffmpeg, not even patents.txt.

Please state the rationale for this removal, in a less terse way.

Thanks.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages ffmpeg depends on:
ii  libavcodec1d0.cvs20070307-6  ffmpeg codec library
ii  libavformat1d   0.cvs20070307-6  ffmpeg file format library
ii  libavutil1d 0.cvs20070307-6  ffmpeg utility library
ii  libc6   2.6.1-1  GNU C Library: Shared libraries
ii  libfreetype62.3.5-1+b1   FreeType 2 font engine, shared lib
ii  libimlib2   1.3.0.0debian1-4 powerful image loading and renderi
ii  libsdl1.2debian 1.2.11-9 Simple DirectMedia Layer
ii  libswscale1d0.cvs20070307-6  ffmpeg video scaling library

ffmpeg recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#440216: ditto here

2007-09-01 Thread Cyrille Chépélov

ditto here.

Looking at the most probable root cause:

[EMAIL PROTECTED]:~$ ffmpeg -formats 2/dev/null|grep mpeg2
  E mpeg2video  MPEG2 video
 D VSDT mpeg2video

  ^ see that little hole here?

Seems the problem stems from this:

--
[EMAIL PROTECTED]:/tmp/ffmpeg-free-0.cvs20070307$
zcat /usr/share/doc/libavcodec1d/changelog.Debian.gz  |head
ffmpeg-free (0.cvs20070307-6) unstable; urgency=low

  * Rename the source package. We are (again) no longer shipping the
'real' upstream source of ffmpeg.
  * Add debian/strip.sh to strip ffmpeg upstream source disabling mpeg
based encoders as discussed with ftp-master at debconf7
^^ ^^^

  * update XS-Vcs tags in debian/control.
  * make ffmpeg binNMU-able by using ${binary:Version} rather than
${Source-Version}
--

So yeah, software patents at work again, successfully randomly destroy
our ability to make useful things out of Debian. [carrying my
toilet-cleaning suction cup] BWA!!! [/end roving rabbid mode]

A terrible way out is to use the MPEG1 encoder instead; patch against
package freeplayer (sorta: intended target
is /usr/share/freeplayer/http-fbx/play.html) attached here. So far so
good, but be warned I have the HD and V5 connected through Ethernet, not
wifi/mimo; I might have saturated what a wireless connection can deliver
or what a V4 chip can absorb (had to make very frequent key frames to
get an acceptably (barely so) smooth animation).

Rock'n'Roll

-- Cyrille

Versions of packages ffmpeg depends on:
ii  libavcodec1d0.cvs20070307-6  ffmpeg codec library
ii  libavformat1d   0.cvs20070307-6  ffmpeg file format library
ii  libavutil1d 0.cvs20070307-6  ffmpeg utility library
ii  libc6   2.6.1-1  GNU C Library: Shared
libraries
ii  libfreetype62.3.5-1+b1   FreeType 2 font engine,
shared lib
ii  libimlib2   1.3.0.0debian1-4 powerful image loading and
renderi
ii  libsdl1.2debian 1.2.11-9 Simple DirectMedia Layer
ii  libswscale1d0.cvs20070307-6  ffmpeg video scaling
library




Les fichiers binaires http-fbx.vanilla/freeplayer.gif et http-fbx/freeplayer.gif sont différents.
diff -u http-fbx.vanilla/play.html http-fbx/play.html
--- http-fbx.vanilla/play.html	2007-05-31 15:35:57.0 +0200
+++ http-fbx/play.html	2007-09-02 01:51:28.0 +0200
@@ -72,13 +72,13 @@
 
 		!-- audio/video with transcoding --
 		vlc id=if param1=type value 3 = /
-			vlc id=rpn param1=qfile value ' :sout=#transcode:std :sout-transcode-ab=256 :sout-transcode-acodec=mpga :sout-transcode-channels=2 :sout-transcode-vb=9000 :sout-transcode-vcodec=mp2v :sout-transcode-vt=100 :sout-transcode-fps=25.0 :sout-ffmpeg-keyint=24 :sout-ffmpeg-interlace :no-sout-ffmpeg-interlace-me :file-caching=1000 :sout-transcode-soverlay' strcat name value playlist_add vlc_play /
+			vlc id=rpn param1=qfile value ' :sout=#transcode:std :sout-transcode-ab=256 :sout-transcode-acodec=mpga :sout-transcode-channels=2 :sout-transcode-vb=12000 :sout-transcode-vcodec=mp1v :sout-transcode-vt=100 :sout-transcode-fps=25.0 :sout-ffmpeg-hurry-up=0 :sout-ffmpeg-hq=bits :sout-ffmpeg-keyint=2 :no-sout-ffmpeg-interlace-me :file-caching=1000 :sout-transcode-soverlay :sout-transcode-threads=2 :sout-ffmpeg-mpeg4-matrix=1' strcat name value playlist_add vlc_play /
 			meta name=panel_notify content=vlc id=value param1=panel value /
 		vlc id=end /
 
 		!-- picture --
 		vlc id=if param1=type value 4 = /
-			vlc id=rpn param1='fake: :sout=#transcode:std :fake-width=720 :fake-height=576 :fake-aspect-ratio=4:3 :fake-keep-ar :fake-deinterlace :deinterlace-mode=blend :sout-transcode-vb=9000 :sout-transcode-vcodec=mp2v :sout-transcode-vt=100 :sout-ffmpeg-keyint=8 :sout-ffmpeg-interlace :no-sout-ffmpeg-interlace-me :fake-file=' qfile value strcat name value playlist_add vlc_play /
+			vlc id=rpn param1='fake: :sout=#transcode:std :fake-width=720 :fake-height=576 :fake-aspect-ratio=4:3 :fake-keep-ar :fake-deinterlace :deinterlace-mode=blend :sout-transcode-vb=9000 :sout-transcode-vcodec=mp1v :sout-transcode-vt=100 :sout-ffmpeg-keyint=8 :no-sout-ffmpeg-interlace-me :fake-file=' qfile value strcat name value playlist_add vlc_play /
 			meta name=panel_notify content=vlc id=value param1=panel value /
 		vlc id=end /
 
Seulement dans http-fbx: play.html~

Bug#423559: deskbar-applet: fails to start

2007-06-27 Thread Cyrille Chépélov

Le mercredi 27 juin 2007 à 08:07 +0200, Romain Francoise a écrit :
 /usr/lib/deskbar-applet/deskbar-applet -w

rugby% /usr/lib/deskbar-applet/deskbar-applet -w
ImportError: /var/lib/python-support/python2.4/gtk-2.0/pangocairo.so:
invalid ELF header
Running installed deskbar, using
[/usr/lib/python2.4/site-packages/deskbar:$PYTHONPATH]
Data Dir: /usr/share/deskbar-applet
Handlers Dir: ['/home/cyrille/.gnome2/deskbar-applet/handlers',
'/usr/lib/deskbar-applet/handlers']
ImportError: cannot import name Screen from gtk.gdk
ImportError: cannot import name Pixbuf from gtk.gdk
Traceback (most recent call last):
  File /usr/lib/deskbar-applet/deskbar-applet, line 32, in ?
import deskbar, deskbar.DeskbarApplet, deskbar.defs
  File /usr/lib/python2.4/site-packages/deskbar/DeskbarApplet.py, line
7, in ?
from deskbar.DeskbarHistory import get_deskbar_history
  File /usr/lib/python2.4/site-packages/deskbar/DeskbarHistory.py,
line 4, in ?
from deskbar.Utils import load_icon
  File /usr/lib/python2.4/site-packages/deskbar/Utils.py, line 9, in ?
factory = gnome.ui.ThumbnailFactory(deskbar.ICON_HEIGHT)
AttributeError: 'module' object has no attribute 'ThumbnailFactory'


The first line definitely points to a corruption on my machine.
Furthermore, I had version 2.10.4-2 of python-gtk2 installed (in
theory). Upgraded to 2.10.4-3; -w now yields:

rugby% d/usr/lib/deskbar-applet/deskbar-applet -w
zsh: aucun fichier ou répertoire de ce type:
d/usr/lib/deskbar-applet/deskbar-applet
rugby% /usr/lib/deskbar-applet/deskbar-applet -w 
Running installed deskbar, using
[/usr/lib/python2.4/site-packages/deskbar:$PYTHONPATH]
Data Dir: /usr/share/deskbar-applet
Handlers Dir: ['/home/cyrille/.gnome2/deskbar-applet/handlers',
'/usr/lib/deskbar-applet/handlers']
Binding Global shortcut AltF3 to focus the deskbar
Running with options: {'popup_mode': False, 'cuemiac': False,
'do_trace': False, 'standalone': True}
Starting Deskbar instance: gnome.applet.Applet object (PanelApplet) at
0xb75fc7fc None
Set entry width: 20
Layout changed to 1
Set entry width: 20
Layout changed to 1
Changing UI to: Entriac
Loading module 'Beagle Live' from
file /usr/lib/deskbar-applet/handlers/beagle-live.py.
Loading module 'Beagle' from
file /usr/lib/deskbar-applet/handlers/beagle-static.py.
Loading module 'Signets Web del.icio.us' from
file /usr/lib/deskbar-applet/handlers/desklicious.py.
***
*** The file /usr/lib/deskbar-applet/handlers/epiphany.py
(EpiphanyBookmarksHandler) decided to not load itself: Epiphany is not
your preferred browser, not using it.
***

etc. and the applet loads standalone. And now it works properly.

I guess this bug can be closed stupid user, corrupted /usr now.
Sorry for the trouble.

-- Cyrille

Bug#423559: deskbar-applet: fails to start

2007-05-12 Thread Cyrille Chépélov

Package: deskbar-applet
Version: 2.14.2-4.2
Severity: important


hello,

for what it's worth, after tonight's batch of APT upgrades, the
deskbar-applet just fails to load. 
Not quite sure which dependency could have caused this...

-- Cyrille

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-rc6-mm1-p4m-sws2
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) (ignored: LC_ALL set to 
fr_FR)
Shell: /bin/sh linked to /bin/bash

Versions of packages deskbar-applet depends on:
ii  gconf2 2.18.0.1-3GNOME configuration database syste
ii  libart-2.0-2   2.3.19-3  Library of functions for 2D graphi
ii  libatk1.0-01.18.0-2  The ATK accessibility toolkit
ii  libbonobo2-0   2.18.0-2  Bonobo CORBA interfaces library
ii  libbonoboui2-0 2.18.0-5  The Bonobo UI library
ii  libc6  2.5-7 GNU C Library: Shared libraries
ii  libcairo2  1.4.6-1   The Cairo 2D vector graphics libra
ii  libebook1.2-5  1.6.3-5   Client library for evolution addre
ii  libedataserver1.2-71.6.3-5   Utility library for evolution data
ii  libfontconfig1 2.4.2-1.2 generic font configuration library
ii  libgconf2-42.18.0.1-3GNOME configuration database syste
ii  libglib2.0-0   2.12.12-1 The GLib library of C routines
ii  libgnome-desktop-2 2.18.1-1  Utility library for loading .deskt
ii  libgnome-keyring0  0.8.1-2   GNOME keyring services library
ii  libgnome2-02.18.0-4  The GNOME 2 library - runtime file
ii  libgnomecanvas2-0  2.14.0-2  A powerful object-oriented display
ii  libgnomeui-0   2.18.1-2  The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0 1:2.18.1-2GNOME Virtual File System (runtime
ii  libgtk2.0-02.10.12-1 The GTK+ graphical user interface 
ii  libice61:1.0.3-2 X11 Inter-Client Exchange library
ii  liborbit2  1:2.14.7-0.1  libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0  1.16.4-1  Layout and rendering of internatio
ii  libpopt0   1.10-3lib for parsing cmdline parameters
ii  libsm6 1:1.0.2-2 X11 Session Management library
ii  libstartup-notification0   0.9-1 library for program launch feedbac
ii  libx11-6   2:1.0.3-7 X11 client-side library
ii  libxcursor11:1.1.8-2 X cursor management library
ii  libxext6   1:1.0.3-2 X11 miscellaneous extension librar
ii  libxfixes3 1:4.0.1-5 X11 miscellaneous 'fixes' extensio
ii  libxi6 1:1.0.1-4 X11 Input extension library
ii  libxinerama1   1:1.0.1-4.1   X11 Xinerama extension library
ii  libxml22.6.28.dfsg-1 GNOME XML library
ii  libxrandr2 2:1.2.1-1 X11 RandR extension library
ii  libxrender11:0.9.2-1 X Rendering Extension client libra
ii  python 2.4.4-2   An interactive high-level object-o
ii  python-central 0.5.13-0.1register and build utility for Pyt
ii  python-glade2  2.10.4-2  GTK+ bindings: Glade support
ii  python-gnome2  2.18.2-1  Python bindings for the GNOME desk
ii  python-gnome2-desktop  2.18.0-2  Python bindings for the GNOME desk
ii  python-gtk22.10.4-2  Python bindings for the GTK+ widge
ii  python2.4  2.4.4-3   An interactive high-level object-o

Versions of packages deskbar-applet recommends:
ii  gnome-utils   2.18.1-1   GNOME desktop utilities
pn  python-soappy none (no description available)
ii  python2.4-beagle [python-beag 0.2.6-2python bindings for beagle

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#396123: additional info

2006-10-29 Thread Cyrille Chépélov

I just did an upgrade of all involved libs, everything (except libgcc1,
  which is not in the business of displaying hatched areas) was up to date.

-- Cyrille


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

52 matches

Mail list logo