Bug#944706: firefox-esr: Tab crashes immediately after start up and Firefox ESR was unusable.

[ISHIKAWA,chiaki]

Package: firefox-esr
Version: 68.2.0esr-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I don't know where to report, but I want to share an experience and
possible workaround.

I hav filed a mozilla bugzilla entry:
https://bugzilla.mozilla.org/show_bug.cgi?id=1596338
Bug 1596338
firefox-esr 68.2.0.ESR startup error under Debian GNU/Linux

My debian kernel version is:
$ uname -a
Linux ip030 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) x86_64 
GNU/Linux


I am using a testing package of Debian. So, that may be one of the
reasons of ill-behavior.

SYMPTOM of the problem:

(1) I upgraded my Debian GNU/Linux packages, and firefox seemed to
updated itself some days ago or yesterday, I am not sure when.

When I tried to run Firefox for the first time after these events by
invoking it from the application menu maybe for the first time in a
few days, Firefox was not usable because any tab including the startup
tab(s) that I wanted to create crashed, and firefox displayed the
error message and offered to close the tab or restore the tab.

Since the tab(s) crashed immediately after startup, if I closed the
tab, Firefox terminated.
If I tried to restore the tabs, this again resulted in the same tab
crashing dialog screen page.  There was no way out.

(2) Another bug I noticed is incorrect link in the help dialog.

I get Page not found error when I clicked on the "What's New" link:

HELP -> About Firefox -> What's New link

I get Page not Found error.

The page shown with BIG "Whoops1" message has URL:
https://www.mozilla.org/en-US/und/firefox/68.2.0/releasenotes/?utm_campaign=whatsnew_medium=firefox-browser_source=firefox-browser

If I delete the "/und" part manually and hit return in the URL bar,
I think the correct page s being accessed.
(I am not sure if the incorrect URL is Debian-specific or originated
in the mozilla binary.)

In then accessed page I see clearly the following message. So it *IS*
the release note.

--- begin quote

Firefox ESR
Release Notes

Release Notes tell you what’s new in Firefox. As always, we welcome
your feedback. You can also file a bug in Bugzilla or see the system
requirements of this release.

    Desktop
    Android
    iOS
    Pre-releases

68.2.0
Firefox ESR

October 22, 2019
Version 68.2.0, first offered to ESR channel users on October 22, 2019

--- end quote



ERROR messages:
While the error in (1) was observed, I saw something like the
following (quoted/pasted at the end of this memo.)
in the startup console where I typed /usr/bin/firefox-esr

Possible Workaround ??? :

I found a solution by accident. I have no idea if this works for everybody.

I tried to restart Firefox after disabling plugin, i.e., safe-mode
from the menu.
This operation failed again and no window was created.
Usually Firefox restart after disabling plugins. But I saw no such
window and there does not seem to be any live firefox process anymore.

ps axg | grep firefox

does not show firefox process.

So, after this, I ran firefox-esr again by typing the command line
this time.  To my relief, this time no tab crashed error screen
appeared, and I can access google search, for example eventually.
Something, maybe some profile or whatever, was changed for the better
(?) is my best guess.

Just thought to share my experience.

---
Note; Some error messages that appeared on the command tty window where I
typed
firefox-esr to start Firefox.

Error messages uring the error (1) above:

$ firefox-esr
IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 
PLayerTransaction::Msg_ReleaseLayer Processing error: message was 
deserialized, but the handler returned false (indicating failure)


IPDL protocol error: Handler returned error code!

###!!! [Parent][DispatchAsyncMessage] Error: 

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

On Sun, 3 Nov 2019 08:19:20 +0900 "ISHIKAWA,chiaki" 
 wrote:

> Hi,
>
> If I am not mistaken, Ubuntu version used on Mozilla's build server
> farms uses rather very old version of sqlite3.
>
>
> > [task 2019-10-31T22:44:44.290Z] ++ NAME=Ubuntu
> > [task 2019-10-31T22:44:44.290Z] ++ VERSION='16.04.5 LTS (Xenial Xerus)'
> > [task 2019-10-31T22:44:44.290Z] ++ ID=ubuntu
>
>
> Maybe I should downgrade to this and then upgrade a bit until local 
test breaks.

>
> From: https://launchpad.net/ubuntu/xenial/+source/sqlite3
>
> Updates
>
> Package versions including new features after the distribution
> release has been made. Updates are usually turned on by default
> after a fresh install.
>
> * sqlite3 3.11.0-1ubuntu1.2
> <https://launchpad.net/ubuntu/+source/sqlite3/3.11.0-1ubuntu1.2>
> (main)
>

I downgraded the sqlite to 3.11.0 used in the first release of ubutno 
Xenial Xerus as noted above.


Unfortunately, the indexedDB errors I saw with mozilla Thunderbird test 
suite did not disappear.


This means that something else that changed between late August and 
middle October (quite likely some other packages) may be to blame.


I will continue investigating, but I *think* sqlite3 was not to blame 
for Thunderbird test failures.


Sorry for the noise.

TIA

Chiaki

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

Hi,

If I am not mistaken, Ubuntu version used on Mozilla's build server 
farms uses rather very old version of sqlite3.


  

[task 2019-10-31T22:44:44.290Z] ++ NAME=Ubuntu
[task 2019-10-31T22:44:44.290Z] ++ VERSION='16.04.5 LTS (Xenial Xerus)'
[task 2019-10-31T22:44:44.290Z] ++ ID=ubuntu



Maybe I should downgrade to this and then upgrade a bit until local test breaks.

From: https://launchpad.net/ubuntu/xenial/+source/sqlite3

Updates

   Package versions including new features after the distribution
   release has been made. Updates are usually turned on by default
   after a fresh install.

 * sqlite3 3.11.0-1ubuntu1.2
   
   (main)

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

Dear Laszló,

Thank you for your e-mail.

(Sorry my local system does not seem to have the correct font for the 
character in your name, and so I am not sure if I am writing the name 
correctly.

I hope it will show correctly on your end.)

My comments inline:

On 2019/11/01 23:44, László Böszörményi (GCS) wrote:

Hi Chiaki,

On Thu, Oct 31, 2019 at 9:09 PM ISHIKAWA,chiaki  wrote:

I vouch that there seems to be a serious issue in libsqlite3 3.30.1-1.

  It's not that fatal like it may seem so.

I wish that is  the case.

I came here because it seems that I have an issue with sqlite3 on my
linux installation.
The problem manifested as database operation failures during thunderbird
mail client regression testing (called mach xcpshell-tests|)

  Is there a documented way to get and run it locally?


There is a series of documents.
However, it is such a long winding path, it may take a few days to set 
up and  run correctly.

I can't really suggest that you take the steps outlined below casually.

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Thunderbird_build

My summary is as follows.

First you have to download the source for C-C (comm-central) AND M-C 
(mozilla-central.)

M-C should be installed somewhere with mozilla directory name.
C-C needs to be installed as comm immediately below mozilla directory.

Then you have to configure the development environment.
Setting environment variables and configuration file and set an 
environment variable, MOZCONFIG,

that points to the config file.
You have to specify the MOZ_OBJDIR that stores the generated binary: 
this object directory MUST be

outside the source tree.

Before building,
you have to download a series of debian package header files and 
libraries (i.e., development library packages) that are used by

the thunderbird build process.
There are a lot actually under Debian that we need to install on top of 
regular installation.


*THEN*
We run the compilation process using so-called |../mach build| command 
in the C-C topmost directory (comm) immediately below M-C (mozill)a 
directory.


This command will likely suggest that we need to install clang c++ 
compiler and rust compiler with many packages.

It prints out the commands how to perform these actions. So I follow it.

Once the compilation is successful, we can finally run
xpcshell test by

cd $MOZOBJ || exit 1

...    mozilla/mach --log-no-times xpcshell-test

where mach command is in the mozilla source directory (M-C).

Build takes about 1 hour on my Ryzen1700 with 16GB memory.
(Actually, Debian GNU/Linux amd64 image that runs inside VirtualBox that 
runs on top Windows10 Pro 64 bit)


If you really are interested, I can help.

There are all sorts of minor issues that pop up from time to time when 
we use open source tools and libraries.
Usually error messages are clear, but sometimes python and other script 
language errors pop up and they are difficult to analyze.




I looks someone on Ubuntu did not see it this month and mozilla's
compilation and testing farm machines do not seem to see it. They run
CentOs if I am not mistaken.

  Which version of CentOS? Its latest release, versioned 8 has SQLite3
3.26.0 if I'm not mistaken.


Oh, I was wrong. The compilation/test farm machines have transitioned to 
Ubuntu sometime before.
I did not know that. Maybe we can know what sqlite3 version is working 
there.

I see the following version info of OS. It seems a very old OS package.

[task 2019-10-31T22:44:44.290Z] ++ NAME=Ubuntu
[task 2019-10-31T22:44:44.290Z] ++ VERSION='16.04.5 LTS (Xenial Xerus)'
[task 2019-10-31T22:44:44.290Z] ++ ID=ubuntu
[task 2019-10-31T22:44:44.290Z] ++ ID_LIKE=debian
[task 2019-10-31T22:44:44.290Z] ++ PRETTY_NAME='Ubuntu 16.04.5 LTS'
[task 2019-10-31T22:44:44.291Z] ++ VERSION_ID=16.04

from 
https://taskcluster-artifacts.net/OtJtVGBiQkax0LeOVJAcbw/0/public/logs/live_backing.log

This is from a build/test job submission result:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central=e1c9f00a40034361a9a3b6c4abdf0807e22c5d7e

Mozilla has a rather nice build/test farm setup.




https://bugzilla.mozilla.org/show_bug.cgi?id=1589779

So I thought maybe the current installation of libsqlite3 on my linux PC
was to blame.

  Might be, but SQLite3 3.30.1 should be safe.

I am still trying to find out what changed between latest August and 
beginning of October.


It can be

- my PC environment changes (including package updates), or
- even testing environment change (but unlikely).

Since someone under Ubuntu told me the test works there without an 
issue, I think

local package version issue is more like it.


Well, it looks that is the case if I read the exchanges here correctly.
My libsqlite3 seems to be affected: the version is 3.30.1-1
(The problem was not observed in August. I am not sure if the upgrade of
libsqlite3 happened during then and now.)

What do people suggest that best course of action under the circumstances

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

Hi,

I vouch that there seems to be a serious issue in libsqlite3 3.30.1-1.

I came here because it seems that I have an issue with sqlite3 on my 
linux installation.
The problem manifested as database operation failures during thunderbird 
mail client regression testing (called mach xcpshell-tests|)


I looks someone on Ubuntu did not see it this month and mozilla's 
compilation and testing farm machines do not seem to see it. They run 
CentOs if I am not mistaken.


https://bugzilla.mozilla.org/show_bug.cgi?id=1589779

So I thought maybe the current installation of libsqlite3 on my linux PC 
was to blame.


Well, it looks that is the case if I read the exchanges here correctly.
My libsqlite3 seems to be affected: the version is 3.30.1-1
(The problem was not observed in August. I am not sure if the upgrade of 
libsqlite3 happened during then and now.)


What do people suggest that best course of action under the circumstances?

Downgrade (to which version and how) or install newer libsqlite3 (where)?

Your guidance is appreciated.

TIA

Chiaki

PS: if necessary, I can file a separate bug report to escalate this 
issue, but it would be weeks until I can come up with a very simplified 
test case since the problems occur inside the complex test harness: I 
don't understand the innards very well.


All I can say is that the same tests that deal with database that worked 
for years suddenly broke in the last several weeks. So my bug report 
would not be that useful :-(

Bug#929482: Info received (Bug#929482: cacti: After apt-get install cacti, the installation stated something old version DB(?) and does not proceed.)

[ISHIKAWA,chiaki]

This is not a strictly speaking bug report.

But I noticed that when I try to access the mail archive of 
pkg-cacti-maint via the web interface,
my norton anti-virus's safe browser feature shuts the access off 
initially stating

that the web site is a dangerous site, etc.

What on earth is going on? I checked that Norton anti-virus regard the 
mail archive due to the

following two infected attachments in the archive.
It would be great if someone can remove the said
mails so that Norton no longer regards the archive access dangerous.


   Threat Report

small-warning
Viruses
Threats found: *2*
Here is a complete list: (for more information about a specific threat, 
click on the Threat Name below)


Threat Name:
JS.Nemucod!g1 


Location:
https://alioth-lists.debian.net/pipermail/pkg-salt-team/attachments/20150615/3ed58d65/attachment.zip 



Threat Name:
Direct Link To JS.Nemucod!g1 


Location:
http://alioth-lists.debian.net/pipermail/pkg-salt-team/attachments/20150615/3ed58d65/attachment.zip 





Just FYI.



On 2019/06/05 1:27, Debian Bug Tracking System wrote:

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Cacti Maintainer 

If you wish to submit further information on this problem, please
send it to 929...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#929482: cacti: After apt-get install cacti, the installation stated something old version DB(?) and does not proceed.

[ISHIKAWA,chiaki]

On Sat, 25 May 2019 10:18:06 +0200 Paul Gevers  wrote:
> Control: tags -1 moreinfo
>
> Hi ISHIKAWA,
>
> Thanks for reporting issues you encounter.
>
> On 24-05-2019 13:00, ISHIKAWA,chiaki wrote:
>
> dbconfig-generate-include is part of dbconfig-common. Can you check that
> you have a file
> /usr/sbin/dbconfig-generate-include?
>
> Are you by any chance running a usr-merged setup?
>
> Paul
>


Hi,

Sorry I missed reading this earlier.

I checked and I did have dbconfi-geneate-include:


env LANG=C ls -l /usr/sbin/db*
-rwxr-xr-x 1 root root 12663 Dec 13 18:32 
/usr/sbin/dbconfig-generate-include

-rwxr-xr-x 1 root root  5707 Dec 13 18:32 /usr/sbin/dbconfig-load-include



> Are you by any chance running a usr-merged setup?

I was not sure what you mean by "usr-merged".

I searched and came up with this web page.

https://wiki.debian.org/UsrMerge

usr-merged: I don't think so...

env LANG=C ls -ld /bin /sbin /lib
drwxr-xr-x  2 root root  4096 May 10 10:18 /bin
drwxr-xr-x 19 root root  4096 May 20 06:20 /lib
drwxr-xr-x  2 root root 12288 May 10 10:18 /sbin

I checked that /bin and /usr/sbin, /lib and /usr/lib and /sbin and 
/usr/sbin contained

different number of files under them.

TIA

Bug#929482: cacti: After apt-get install cacti, the installation stated something old version DB(?) and does not proceed.

[ISHIKAWA,chiaki]

Package: cacti
Version: 1.2.2+ds1-2
Severity: normal
Tags: a11y d-i

Dear Maintainer,

*** Reporter, please consider answering these questions, where 
appropriate ***


   * What led up to the situation?

 apt-get install cacti

     which I performed a few hours ago.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 After the installation, the cacti installer stated the following 
error message and won't proceed.



Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/cacti.conf
Replacing config file /etc/dbconfig-common/cacti.conf with new version
Replacing config file /etc/cacti/debian.php with new version
checking privileges on database cacti for cacti@localhost: user creation 
needed.

granting access to database cacti for cacti@localhost: success.
verifying access for cacti@localhost: success.
dbconfig-common: dumping mysql database cacti to 
/var/tmp/cacti.cacti.2019-05-24-18.09.mysql.gISAIk.

database does not exist.
dbconfig-common: dropping old mysql database cacti.
dropping database cacti: database does not exist.
creating database cacti: success.
verifying database cacti exists: success.
populating database via administrative sql...  done.
populating database via sql...  done.
dbconfig-common: flushing administrative password
Running cli/upgrade_database.php as part of package update...
You are attempting to install cacti 1.2.2 onto a 0.6.x database.
To continue, you must create a new database, import 'cacti.sql' into it,
and    update 'include/config.php' to point to the new database.

   I tried a few things. But the installer repeated stated that
   You are attempting to install cacti 1.2.2 onto a 0.6.x database.
   ...
   even if
   -  I removed the package (get-apt remove cacti)
   and RECREATE the database cacti on the fly during the installation.
  At this stage http://MYHOST/cacti/ returns an error message to
  the tune of
  make sure php data  module is installed property,
  database is created, etc.

   - Or create a database 'cactinew', and edited config.php (in this
 case, and run dpkg-reconfigure cacti, the web response changes to
 Not Found

 The requested URL /cacti/ was not found on this server.
 Apache/2.4.38 (Debian) Server at 192.168.0.30 Port 80

 This I think is the failure of cacti package. It seems to miss a
 post-inst file or something.
 See the log snippet below.

    I created a database ('root' user), and I modified the
    following files to accommodate the user and database names.
    vi /etc/cacti/debian.php
    vi /usr/share/cacti/site/include/config.php

   Note the error during dpkg-reconfigure cacti: the log says
   dbconfig-generate-include: not found

    root@ip030:/var/lib/mysql# mysql -u root cacti3 < 
/usr/share/doc/cacti/cacti.sql

    root@ip030:/var/lib/mysql# !vi
    vi /etc/cacti/debian.php
    root@ip030:/var/lib/mysql# vi /etc/cacti/debian.php
    root@ip030:/var/lib/mysql# /usr/sbin/dpkg-reconfigure cacti
    Determining localhost credentials from /etc/mysql/debian.cnf: 
succeeded.

    dbconfig-common: writing config to /etc/dbconfig-common/cacti.conf
    Replacing config file /etc/dbconfig-common/cacti.conf with new 
version
 ***   /var/lib/dpkg/info/cacti.postinst: 677: 
/var/lib/dpkg/info/cacti.postinst: dbconfig-generate-include: not found

    dbconfig-common: flushing administrative password
    Running cli/upgrade_database.php as part of package update...
    You are attempting to install cacti 1.2.2 onto a 0.6.x database.
    To continue, you must create a new database, import 'cacti.sql' 
into it,

    and    update 'include/config.php' to point to the new database.

    I cannot get out of this cycle.

   * What was the outcome of this action?

Failed installation of cacti.


 * What outcome did you expect instead?

    I expected the URL https://HOST/cacti to return cacti 
installation page.




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

Kernel: Linux 4.19.0-5-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)

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

Versions of packages cacti depends on:
ii  dbconfig-common   2.0.11
ii  dbconfig-mysql    2.0.11
ii  debconf [debconf-2.0] 1.5.71
ii  fonts-dejavu-core 2.37-1
ii  fonts-dejavu-extra    2.37-1
ii  fonts-fork-awesome    1.1.5+ds1-2
ii  javascript-common 11
ii  

Bug#861285: I must have set the severity to a non-standard value

[ISHIKAWA,chiaki]

As I was editing the text file generated by "reportbug" before sending  
it in a mail client on another machine (I did not set up outgoing mail  
on the linux box), I think I set the severity tag to a non-standard  
value by mistake.


TIA

Bug#861285: openssl enc -k path-for-keyphrase-file ...c does not fail if the keyphrase-file is missing.

[ISHIKAWA,chiaki]

Package: openssl
Version: 1.1.0e-1
Severity: major
Tags: upstream

Dear Maintainer,

*** Reporter, please consider answering these questions, where  
appropriate ***


   * What led up to the situation?

I ran the following command after setting up the
environment variables appropriately.

E.g.:

KFILE=path-for-passphrase-file  (say, ~/mypass)
BNAME=file-to-be-encrypted

openssl enc -k ${KFILE} -in  ${BNAME} -out ${BNAME}.enc -aes-256-cbc

To my surprise if ${KFILE} is missing, openssl does not complain
and seems to encrypt the input file anyway: but with what passphrase?!

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   * What was the outcome of this action?

We may end up with an encrypted file that noo ne can possibly decrypt !?
If, the intent is to remove the original file AFTER the encryption
takes place, then we lose the original file forever!

  Possible DATA LOSS. BAD!

   * What outcome did you expect instead?

I would rather see openssl complain that the passphrase file is
missing LOUD and CLEAR (and returns an error code. I checked that the  
following does not print "fail".


openssl enc -k ${KFILE} -in  ${BNAME} -out ${BNAME}.enc -aes-256-cbc  ||  
echo fail


)

*** End of the template - remove these template lines ***


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

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

Versions of packages openssl depends on:
ii  libc6  2.24-9
ii  libssl1.1  1.1.0e-1
ii  perl   5.24.1-2

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20161130

-- no debconf information

Bug#758260: The problem is serious and should be fixed IMHO.

[ISHIKAWA,chiaki]

I recently encountered the similar problem after a quick install using  
netinstall ISO.

As the original poster said,
the default partition done by
choosing guided install with separate "/home" only reserves
about only 10- GB for the "/" partion.

This is way too small since, in this set up, "/" will hold
/var, /usr, and /lib, and all of them are known to bloat (when you need  
to run apt-get upgrade, etc.)


 > pretty sure 10 GB is quite reasonable for a root filesystem, unless you

have specific requirements (which you didn't mention, so that's hard to
figure out). Last I checked, default is *not* using separate directories
so if you're switching away from it, I'm sure you could also partition
as you desire…


No, I think you are missing the point.
[It is true 10 GB root "/" is enough if "/usr", "/lib", "/var" and  
possibly others are on separate partition. But the auto-guided
partition when we instruct a separate "/home" directory does not  
separate all these bloated directories AND only reserve 10 GB "/".
This is crazy. I suspect with the easy-intall, ONLY using the entire  
partition (with the exception of swap) is really USABLE.
Pity since the easy install should give the simple and less time  
consuming step to do a REASONABLE install.

The current install when we pick "separate /home" fails this criteria.


My point is,
if we say, separate "/home", do it as instructed, but
reserve at least 30-50 GB (depending on the size of the disk/ssd/etc.)  
for the root partition so that at least, during the initial cycles of  
"get-apt update upgrade install", we won't run out of "/" partition.
Some admins are in a hurry and they expect a reasonable minimum for root  
partition.



This problem of running out of "/" partions have happened a few times in  
the last few years (especially since TeX packages have become very large  
and the default desktop requires TeX packages as part of  dependency.)


[Another issue, of course, is the non-intuitive manner to reach the  
desired FULL manual partition from the installer. I think the installer  
has DEGRADED in this regard over the years. I could not find the full  
manual partition easily this time. But I will file a different bug entry  
for the non-intuitive UI.]


I am attaching a partition list as a screen dump on a test install when  
the problem was noticed. Since the system I had was unusable when during  
the upgrade (apt-get upgrade) it ran out of "/" and nothing could be  
done further.
I could not even run debianbug command, etc. since it failed to execute  
properly.
I had to erase the crippled installation and start over. I captured the  
listing of "flist -l" before erasing the installation.


TIA

PS: if this particular bug entry is not the proper bug entry to complain  
about this grave usability issue (from the perspective busy sysadmins,  
let me know if I should file a new bug entry.

Bug#853287: Acknowledgement (gcc-6 ICE: in output_index_string,, at dwarf2out.c:25635 (reported upstream 70578))

[ISHIKAWA,chiaki]

It seems that combining -g3 and -gsplit-dwarf is the root cause for MY 
problem.


Even gcc experiences an ICE.

/usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -DNDEBUG=1 -DTRIMMED=1 
-DHAVE_CONFIG_H=vpx_config.h -fPIC -DMOZILLA_CLIENT 
-fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync 
-DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -gsplit-dwarf -g3 -Og 
./vp9_dsubexp.i
/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/libvpx/vp9/decoder/vp9_dsubexp.c:72:1: 
internal compiler error: in output_index_string, at dwarf2out.c:22895

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
ishikawa@ip030:/tmp$


Please see my followups to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578

TIA

Bug#842324: console-setup: During apt-get dist-upgrade stage, console-setup did not finish cleanly under ja_JP.UTF-8 locale.

[ISHIKAWA,chiaki]

On 2016/11/06 1:12, Anton Zinoviev wrote:

On Wed, Nov 02, 2016 at 02:44:13PM -0400, Sandro Tosi wrote:


in particular if the error in is `iconv` that program is part of
libc-bin so this bug should be reassigned to that pkg.


Yes, the bug belongs to libc-bin.  Unfortunately, I was unable to
reproduce the bug on my computer, so I won't be able to provide any
useful data to the libc-bin maintainers.  Therefore, I suppose it won't
do any good if I reassign the bug (but I can be wrong).


I'll let the console-setup maint decide what to do of course, just
posting my quick check on this RC bug.


I've commited a change that will make console-setup use untranslated
keyboard names in case of failed iconv.  This should fix the bug in
console-setup.  Of course, when we have more data or something
reproducible we can submit a bug against libc-bin.

Anton Zinoviev



I wish I could add more data point, but
iconv did fail on that particular PC I tested and LANG=C
cured the problem.

Let me look out if another iconv issue pops up on two PCs I use heavily.

TIA

Bug#805613: gcc-4.9: GCC++ 4.9 compiler had ICE (internal compiler error)

[ishikawa chiaki]

Package: gcc-4.9
Version: 4.9.2-10
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   I was compiling mozilla thunderbird mailer source tree when
   the g++ compiler experinced an ICE (internal compiler error)
   and printed error messages, etc.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Invoking the compiler on a source file of mozilla thunderbird.
 
   * What was the outcome of this action?
 Compiler quit on its own after printing errors and no object file
 was produced.
 
   * What outcome did you expect instead?
 The compiler would produce the object file without failing.


*** End of the template - remove these template lines ***


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

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

Versions of packages gcc-4.9 depends on:
ii  binutils2.25-5
ii  cpp-4.9 4.9.2-10
ii  gcc-4.9-base4.9.2-10
ii  libc6   2.19-18+deb8u1
ii  libcloog-isl4   0.18.2-1+b2
ii  libgcc-4.9-dev  4.9.2-10
ii  libgmp102:6.0.0+dfsg-6
ii  libisl100.12.2-2
ii  libmpc3 1.0.2-1
ii  libmpfr43.1.2-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages gcc-4.9 recommends:
ii  libc6-dev  2.19-18+deb8u1

Versions of packages gcc-4.9 suggests:
pn  gcc-4.9-doc   
pn  gcc-4.9-locales   
pn  gcc-4.9-multilib  
pn  libasan1-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

Bug#503658: closed by santi...@debian.org (grep is even 200x faster in multibyte locales)

[ISHIKAWA,chiaki]

Hi,

I am the original reporter.
How time flies.

Back in 2008, when I measured the speed,
 CPU was 1GHz class, one core, and the system had 512MB main memory.
(Under 32bit Debian/GNU Linux installed on real-hardware.)

In 2014: now my real CPU, Xeon, is 3GHz class (4 core, hyperthreading)
Debian GNU/Linux amd64 has 8GHZ main memory (in a VMplayer environment
with 4 CPU emulation).

So there is an issue of 64bit vs 32bit CPU and OS, but
anyway, I measured the speed again using a much larger
test input file of 63.5 MiB bytes (2014)
(vs 100 KiB (2008)) to obtain a meaningful number on today's fast CPU.

With 100KiB size bytes the speed was not measureable because CPU is now 
so faster!

(the execution log is at the end.)

Then I noticed very INTERESTING DISCOVERY.

The low case now about 9 times slow down. (In comparison to x200-x400
slow down in 2008 it is more or less acceptable? It depends.)

What is interesting is this: NOTE THAT the slowdown characteristics is
TRANSPOSED in comparison to the data in 2008!
I had to re-read the execution log to make sure that I was not 
hallucinating.

How interesting.

2014 table

value of
LANG
  |
  V   |  ja_JP.ujis |   C |=== value of  LC_ALL
--+-+---
ja_JP.ujis|  1.833s |  1.845s
--+-+--
   C  |  0.219s |  0.226s
--+-+---

While the slow execution time of 2008 is in the left COLUMN
it is the first ROW in 2014. Strange, isn't it?

I have to agree that the bug is too old now and that
the transposition of the table that shows slowdown pattern
probably means that there is a different bug
hmm, it is more likely
the UTF-8 slowdown mentioned in one of the  Savanna bugs mentioned in
the bug discussion before
(http://savannah.gnu.org/bugs/index.php?29391
-i and utf8 slowness, speedup idea
 )
ja_JP.ujis is basically UTF-8. So a known different bug now, I think)
So I concur this  bug should be closed.

I am afraid that the fast CPU speed masks all these minor deficiencies
of programs under the rug. Reminds me of MS policy of throwing faster
CPU and more memory at slow and bloated OS.
It is the curse of very fast CPU and ever advancing hardware.
Well, maybe that is life.

TIA


cf.
2008 data quoted here.
value of
LANG
  |
  V   |  ja_JP.ujis |   C |=== value of  LC_ALL
--+-+---
ja_JP.ujis|  8.084s |  0.022s
--+-+--
   C  |  8.488s |  0.010s
--+-+---

June 2014 execution log:

+ SRC=/FF-NEW/log443-mozmill-memcheck-fixstack.txt
+ wc /FF-NEW/log443-mozmill-memcheck-fixstack.txt
  608621  3316476 63137313 /FF-NEW/log443-mozmill-memcheck-fixstack.txt
+ LC_ALL=C
+ LANG=C
+ egrep -i backslash /FF-NEW/log443-mozmill-memcheck-fixstack.txt

real0m0.219s
user0m0.204s
sys 0m0.012s
+ strace -o /tmp/t-C-locale.out egrep -i backslash 
/FF-NEW/log443-mozmill-memcheck-fixstack.txt

+ LC_ALL=ja_JP.ujis
+ LANG=ja_JP.ujis
+ egrep -i backslash /FF-NEW/log443-mozmill-memcheck-fixstack.txt

real0m1.784s
user0m1.768s
sys 0m0.004s
+ strace -o /tmp/t-ja-locale.out egrep -i backslash 
/FF-NEW/log443-mozmill-memcheck-fixstack.txt

+ LC_ALL=ja_JP.ujis
+ LANG=C
+ egrep -i backslash /FF-NEW/log443-mozmill-memcheck-fixstack.txt

real0m0.223s
user0m0.216s
sys 0m0.004s
+ strace -o /tmp/t-mixed-locale-1.out egrep -i backslash 
/FF-NEW/log443-mozmill-memcheck-fixstack.txt

+ LC_ALL=C
+ LANG=ja_JP.ujis
+ egrep -i backslash /FF-NEW/log443-mozmill-memcheck-fixstack.txt

real0m1.799s
user0m1.784s
sys 0m0.012s
+ strace -o /tmp/t-mixed-locale-1.out egrep -i backslash 
/FF-NEW/log443-mozmill-memcheck-fixstack.txt

ishikawa@vm-debian-amd64:/home/ishikawa/repos/kinput2-wnn-v3.1-ci-mods$





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

Bug#690826: Patch was pushed to the upstream

[ISHIKAWA,chiaki]

The mentioned patch I posted to freedesktop.org
was finally pushed to the current master (to be released when?)
by Alan Coppersomith.

Pushed to ssh://git.freedesktop.org/git/xorg/lib/libX11:
   e7fd6f0..8f58e54  master - master

Thank you in advance for your attention.


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

Bug#611303: system-config-printer' This bug hurts.

[ISHIKAWA,chiaki]

I take exception to the closing of this bug, and
the severity wishlist.

In order to use a Windows-only printer (inexpensive kind you often find, or 
even an expensive one but that does not have
linux driver!), we need to attach this to a window PC and makes it available 
via Samba.

Such needs arose yesterday at the office and it took me more than a couple of 
hours why
system-config-printer could not find the publicized samba printer on
the latest Debian distribution while other linux distribution seemed not suffer 
from this problem.
(I searched for people with similar bad experience, but all I could find 
casually was the suceess stories
from ubuntu, centos, etc.)

So I think this bug should be deemed severity NORMAL, and
python-smbc OUGHT to be depended upon and should be installed when
system-config-printer is installed (which is the default case, I think, if you 
install the desktop by default).

TIA


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

Bug#703239: A report of my experience.

[ISHIKAWA,chiaki]

Something similar happened at the office today.

I am using 3.2.0-4 debian kernel guest inside virtualbox running on Windows XP 
host.
and had a similar issue of miscompiling of vboxvideo_drm.c, after upgrading 
virtualbox.

Basically compilation itself was fixed by the brute-force approach
mentioned in message # 50 from From: Francesco Presel f.pre...@alice.it

I defined something like DRM_RHEL63 near the beginning of the code
in the virtualbox-guest-additions-iso image.
virtualbox-guest-additions-iso is
from
http://packages.debian.org/search?keywords=virtualbox-guest-additions-isosearchon=namessuite=allsection=all

But, the video is not working well.

In a properly working set up, if we change the main virtual box window size on 
Windows XP,
the X11 window root window inside the virtual box changes the size accordingly.
Unfortunately, this does not seem to be the case. The size doesn't change and so
we occasinally have a portion of the root window hidden when we resize the 
virtualbox window size.


(This was tested after downloading pristine virtualbox image from oracle 
virtualbox
web site, and installed  [or whatever.])

TIA

PS: This happened at the office, and I failed to take detailed memo with me.
I installed a few packages to make this installation proceed as much as this 
far.
I think something about kernel level drm module or something was necessary.
(This should be clear when we look in the /var/log/vbox-install.log.


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

Bug#703239: Thank you for the info.

[ISHIKAWA,chiaki]

To Message # 60, it is great to know that at least on your setup,
resizing of windows work:

Guest: Debian Wheezy
Host:  Linux Mint Debian Edition (with Wheezy
repositories, but with the latest version of VB, directly from their own
rep

My case is

Guest: Debian Wheezy (I think. I have done dist-upgrade some time ago.)
Host:  Windows XP SP3
VirtualBox : 4.2.6, 4.2.8, 4.2.10 from Oracle's VB web site.

What irrirates me is that before my
trial to move up from VB 4.2.6 to VB 4.2.10,
the resizing, etc. worked well.
[With hindsigt, I am afraid that maybe I compiled the guestadditions from
earlier revisionf of VB under maybe a slighly earlier guest kernel,
and because WITHOUT recompiling, the older modules worked in the newer 
combination of the
VB version 4.0.6 and the guest Debian kernel,
I let it pass.
But then, when I upgraded to VB 4.2.10, it did not work initially.
Even the file sharing did not work due to a file corrpution from Oracle VB 
repository.
[This is since fixed.]
I downgraded to 4.2.8.
Then updated guest addition there (recompiled). Now file sharing worked, but I 
noticed that
video window resizing didn't work. That was the day before.

So I downgraded to 4.0.6 and tinkered, and in the process, I found to my 
surprise
that we can't compile vboxvideo_drm.c of guestadditions of 4.0.6 even. (So my
working vboxvideo_drm module must have been carried over from the older
guest addition [with maybe an older kernel???].

Anyway, it is nice to hear that it works on someone's configuration.

There is hope :-)
Although it is true that VB 4.2.10 may have issues on Windows XP (very old OS),
I will investigate for another day.

Thank you.


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

Bug#691109: libc6: memcpy-ssse3.S accesses invalid memory address area under certain conditions.

[ISHIKAWA,chiaki]

This bug appears again.

This time, it is in the context of debugging mozilla thunderbird mail client for
linux.

During running of debug build of mozilla thunderbird under valgrind, I observed 
these warnings, one of which is shown below.

When I filed this problem about valgrind at kde site,
the problem of memcpy-ssse3.S is reported not to happen under 64-bit Ubuntu 
according to
https://bugs.kde.org/show_bug.cgi?id=307828#c4
I filed a separate entry as suggested there anyway.
https://bugs.kde.org/show_bug.cgi?id=311407

The proble is for real.
I can reliably reproduce this bogus warning using the
sample program, test-copy.c, attached in
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=test-copy.c;att=2;bug=691109

These bogus warning messages are really annoying when one tries to hunt down 
real problems.

I hope this helps.

TIA


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

Bug#691109: Fix in the Upstream repostiroy

[ISHIKAWA,chiaki]

https://bugs.kde.org/show_bug.cgi?id=311407

The bug is fixed in the upstream source of valgrind and
by using the source from SVN there, I no longer see the problem.

So I hope Debian will package the latest source (3.9.0) as soon as it is
released.


TIA


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

Bug#691030: kinput2-wnn access FREEed area after a client is abruptly terminated (highly timing dependent)

[ISHIKAWA,chiaki]

Package: kinput2-wnn
Version: 3.1-10.3
Severity: normal
Tags: upstream

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
 I was running kinput2-wnn (built from source: kinput2 (3.1-10.3)
unstable;
urgency=low) under valgrind to catch memory related errors.
Then I notice that kinput2-wnn accesses FREEed area :-(

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I was typing Japanese text using kinput2-wnn into thunderbird build,
then
   thunderbird crashed due to its own error.
   When this happened, I noticed that valgrind printed the log messages
reporting
  that kinput2-wnn accessed freed memory area.

   * What was the outcome of this action?
 kinput2-wnn accessed freed memory area (that contains junk.)

   * What outcome did you expect instead?
   kinput2-wnn should not access freed memory area.

*** End of the template - remove these lines ***



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kinput2-wnn depends on:
ii  debconf [debconf-2.0]  1.5.46
ii  freewnn-common 1.1.1~a021+cvs20100325-6
ii  kinput2-common 3.1-10.3
ii  libc6  2.13-35
ii  libice62:1.0.8-2
ii  libsm6 2:1.2.1-2
ii  libwnn6-1  1.0.0-14.2+b1
ii  libx11-6   2:1.5.0-1
ii  libxaw72:1.0.10-2
ii  libxext6   2:1.3.1-2
ii  libxmu62:1.1.1-1
ii  libxpm41:3.5.10-1
ii  libxt6 1:1.1.3-1

Versions of packages kinput2-wnn recommends:
ii  xfonts-base  1:1.0.3

Versions of packages kinput2-wnn suggests:
ii  freewnn-jserver  1.1.1~a021+cvs20100325-6

-- debconf information:
  shared/kinput2/wnn/keybindings: Egg

*** /tmp/kinput2-free-bug-log.txt
...

Looks that kinput2-wnn tries to access Freed Area(!)
[after a TCP connection is disconnected!]

This happened when TB suddenly died when I tried to show version
number using [help] - [about]. 20th Oct, 2012


==30391==by 0x416420E: XtFree (in
/usr/lib/i386-linux-gnu/libXt.so.6.0.0)
==30391==by 0x806E5FA: IMProcessQueue (imdispatch.c:471)
==30391==by 0x8070A76: xBrokenPipe (imxport.c:347)
==30391==by 0x805DC05: XAEHandler (asyncerr.c:153)
==30391==by 0x42384A2: _XError (XlibInt.c:1583)
==30391==by 0x423535C: handle_error (xcb_io.c:212)
==30391==by 0x42353B6: handle_response (xcb_io.c:324)
==30391==by 0x4235E97: _XEventsQueued (xcb_io.c:363)
==30391==by 0x4235F29: _XFlush (xcb_io.c:513)
==30391==by 0x4216EB0: XFlush (Flush.c:39)
==30391==by 0x8070827: xFlush (imxport.c:407)
==30391==
==30391== Invalid read of size 4
==30391==at 0x807060E: xFlush (imxport.c:366)
==30391==by 0x806E63F: IMProcessQueue (imdispatch.c:457)
==30391==by 0x8070B5D: xinput (imxport.c:298)
==30391==by 0x4349E45: (below main) (libc-start.c:228)
==30391==  Address 0x4d0144c is 28 bytes inside a block of size 600 free'd
==30391==at 0x402618D: free (vg_replace_malloc.c:446)
==30391==by 0x416420E: XtFree (in
/usr/lib/i386-linux-gnu/libXt.so.6.0.0)
==30391==by 0x806E5FA: IMProcessQueue (imdispatch.c:471)
==30391==by 0x8070A76: xBrokenPipe (imxport.c:347)
==30391==by 0x805DC05: XAEHandler (asyncerr.c:153)
==30391==by 0x42384A2: _XError (XlibInt.c:1583)
==30391==by 0x423535C: handle_error (xcb_io.c:212)
==30391==by 0x42353B6: handle_response (xcb_io.c:324)
==30391==by 0x4235E97: _XEventsQueued (xcb_io.c:363)
==30391==by 0x4235F29: _XFlush (xcb_io.c:513)
==30391==by 0x4216EB0: XFlush (Flush.c:39)
==30391==by 0x8070827: xFlush (imxport.c:407)



==30391== Invalid read of size 4
==30391==at 0x8070614: xFlush (imxport.c:371)
==30391==by 0x806E63F: IMProcessQueue (imdispatch.c:457)
==30391==by 0x8070B5D: xinput (imxport.c:298)
==30391==by 0x4349E45: (below main) (libc-start.c:228)
==30391==  Address 0x4d01570 is 320 bytes inside a block of size 600 free'd
==30391==at 0x402618D: free (vg_replace_malloc.c:446)
==30391==by 0x416420E: XtFree (in
/usr/lib/i386-linux-gnu/libXt.so.6.0.0)
==30391==by 0x806E5FA: IMProcessQueue (imdispatch.c:471)
==30391==by 0x8070A76: xBrokenPipe (imxport.c:347)
==30391==by 0x805DC05: XAEHandler (asyncerr.c:153)
==30391==by 0x42384A2: _XError (XlibInt.c:1583)
==30391==by 0x423535C: handle_error (xcb_io.c:212)
==30391==by 0x42353B6: handle_response (xcb_io.c:324)
==30391==by 0x4235E97: _XEventsQueued (xcb_io.c:363)
==30391==by 0x4235F29: _XFlush (xcb_io.c:513)
==30391==by 0x4216EB0: XFlush (Flush.c:39)
==30391==by 0x8070827: xFlush (imxport.c:407)



==30391== Invalid read of size 4
==30391==at 

Bug#530772: libgl1-mesa-glx: Recent library update broke starsuite8 (openoffice 2 variant) and glxinfo

[ishikawa,chiaki]

Thank you for the response.

Julien Cristau wrote:

severity 530772 important
tag 530772 moreinfo unreproducible
kthxbye

On Thu, May 28, 2009 at 02:15:45 +0900, ishik...@yk.rim.or.jp wrote:


Package: libgl1-mesa-glx
Version: 7.0.3-7
Severity: critical
Justification: breaks unrelated software


if it depends on libGL, it's not unrelated.

If I am reporting this to a wrong package, forgive me.
This is the closest I could think of under the circumstances.

I have upgraded my lenny system (with testing in apt sources.list)
lately (last week). I had not done so for several weeks.


7.0.3-7 was uploaded mid December, and was in testing shortly after
that.


Since then Sun's starsuite8 (aka staroffice8 based on OpenOffice 2)
fails to start. It crashes on startup.

I used starsuite8 for a long time on this PC and so was puzzled at
the problem.

I investigated and found that startsuite8t will start if I temporarily hide
/usr/lib/libGL.so and friends by renaming them.


are you sure your libGL comes from mesa, and not nvidia or fglrx?



I am using ATI radeon chipset (actually, this PC is based on motherboard
that uses AMD 780G onboard graphics.)
In the distant past, I may have installed fglrx.

This is the libGL files under /usr/lib:

lrwxrwxrwx 1 root root 10 2009-01-05 11:29 libGL.so - libGL.so.1
lrwxrwxrwx 1 root root 12 2009-02-20 01:07 libGL.so.1 - libGL.so.1.2
-rw-r--r-- 1 root root 556108 2009-01-12 09:53 libGL.so.1.2

Do they look like they came from fglrx?

It would be mighty handy if there is  consolidated tool to figure out
the origin of these X library files.
(Now I am beginning to realize why it was
so difficult to figure out which package provides libGL.*.
I tried by searching Debian packages, but was not so sure.
From what you suggest, it seems to me that there are non-Debian packages (or
deb packages that are prepared by a third party) that provides the libraries
in question. Hmm...)



Cheers,
Julien



Thank you for taking the time to look into the matter.

I will upload any necessary files such as complete Xorg.0.log, etc.
or send it by e-mail before public scrutiny is required.

Sincerely
CI




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

Bug#503658: A follow-up. Ubuntu had a similar bug report.

[ishikawa,chiaki]

Thank you for keeping me updated of the progress (or lack thereof?).

If I can do anything, like testing the patch in Japanese locale, please
let me know.

Sincerely,
Chiaki Ishikawa

Aníbal Monsalve Salazar wrote:

forwarded 503658 http://savannah.gnu.org/bugs/?14472
thanks

On Tue, Oct 28, 2008 at 02:57:05AM +0900, Chiaki wrote:

Ubuntu had a similar bug report with the title huge performance hit
for -i with UTF-8 locales

https://bugs.launchpad.net/ubuntu/+source/grep/+bug/75695

Caution: In it, it was suggested that open() calls to load proper
locale-specific runtime libraries may also add to the overhead.

It is true, but the large amount of search time as observed can't be
explained by these open() calls alone.  The search time is roughly a *
s + b (s being the input size, a and b are constants. 'b' here denotes
the overhead of initial open() calls for dynamic loading. Here the
problem is the VERY LARGE 'a' in the case of ja_JP.ujis and other
locales, it seems and 'b' is not much of a problem.)

The ubuntu report states the bug is known upstream and the patch has
been proposed. (and the comment was dated 2008 summer).


http://savannah.gnu.org/bugs/?14472


I hope the fix will be made available to users soon.

--
int main(void){int j=2008;/*(c)2008 cishikawa. */
char t[] =CI @abcdefghijklmnopqrstuvwxyz.,\n\;
char *i =bqtCIuqivb,gcwe...@.ietciuqi\tqkvv isdnamz;
while(*i)((j+=(int)strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */












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