Konqueror Keeps Krashing

2003-07-25 Thread Cameron Patrick
G'day all,

The following was originally sent to another mailing list a while ago
but no-one there seemed to have any ideas on what was going on -

My Konqueror has started playing up.  When used as a web browser it
seems like it loads pages from the network properly, then when it tries
to render the page it sits with the spinning KDE gear not spinning,
sucking all my memory and swap space (~1.5GB) and is eventually killed
by the kernel with a line like the following appearing in syslog:

Jul 10 10:45:34 erdos kernel: Out of Memory: Killed process 1456 (kdeinit).

It's been doing this for a couple of weeks now; as far as I know I
haven't touched anything to make it break - certainly I've been running
this same version of Konqueror (Debian sid 3.1.2-1) since before it
started crashing so that doesn't seem likely to be the problem.

I tried creating a new user, and konqueror worked fine then, so
presumably there's something quirky in my ~/.kde that's causing
Konqueror to die.  Anyone have any ideas on what it might be and how to
fix it, short of wiping out all my KDE settings?

TIA,

Cameron.




Re: KDE update

2003-07-25 Thread Nick Boyce
On Sat, 26 Jul 2003 00:43:35 +0200, Frank Van Damme wrote:

>On Saturday 26 July 2003 00:37, Richard Ibbotson wrote:
>> I'd like to update my KDE 3.0.5a installation.  Where do I tell
>> apt-get to go tomorrow to get hold of a nice desktop ?  
>
>In sid.

If you want KDE 3.1.2 for *Woody* then point your apt at :

deb http://download.kde.org/stable/3.1.2/Debian/ stable main

Nick Boyce
Bristol, UK
--
Stenderup's Law: 
The sooner you fall behind, the more time you will have to catch up.




Re: KDE update

2003-07-25 Thread Frank Van Damme
On Saturday 26 July 2003 00:37, Richard Ibbotson wrote:
> I know that this has been covered many times.
>
> I'd like to update my KDE 3.0.5a installation.  Where do I tell
> apt-get to go tomorrow to get hold of a nice desktop ?  Can't remember
> where the FAQ is.

In sid.

-- 
Frank Van Dammehttp://www.openstandaarden.be 
~~~~
"Je pense, donc je suis breveté."




KDE update

2003-07-25 Thread Richard Ibbotson
Hi

I know that this has been covered many times.

I'd like to update my KDE 3.0.5a installation.  Where do I tell
apt-get to go tomorrow to get hold of a nice desktop ?  Can't remember
where the FAQ is.

Thanks





Richard
www.sheflug.co.uk




Re: Qt versioning (was: KDE 3.1.2 broken)

2003-07-25 Thread Ralf Nolden
On Mittwoch, 23. Juli 2003 14:35, Derek Broughton wrote:
> From: "John Gay" <[EMAIL PROTECTED]>
>
> > This will probably be a big problem. But upgrades will only work if they
> > stick with the Official debian repositories. Packages from other sources,
> > especially unofficial ones, are just not expected to work. But try
> > telling that to all the people who will have problems with this.
> >
> > >Perhaps Ralf and Madkiss have a greater plan here that I just don't
> > >understand.
> >
> > I don't think so. Ralf did a great service providing these from his own
> > work and free time, but I don't think he expected them to intigrate
> > cleanly with the rest of Debian.
>
> I agree.  I don't really see this as being Ralf's fault, anyway.  Why are
> the sid QT3 versions 3.1.1 rather than 3.1.2 like the rest of kde?  I would
> expect they're truly not 3.1.2 yet.

I updated to Qt 3.1.2 already while madkiss was forced to stay with 3.1.1 
until maybe 3.2.0 will fix the glibc issue (or a new glibc is uploaded in 
unstable). It's only a temporary issue. Upgradable versions from KDE's woody 
debs to unstable are desired, just the people in unstable are sometimes a bit 
slower due to the overall development than what can be provided for stable a 
couple of days (in the Qt area weeks due to the glibc) earlier.

Ralf
>
>  derek

-- 
We're not a company, we just produce better code at less costs.

Ralf Nolden
[EMAIL PROTECTED]

The K Desktop Environment   The KDevelop Project
http://www.kde.org  http://www.kdevelop.org


pgp4NRpM4YGNZ.pgp
Description: signature


Compiling filelight

2003-07-25 Thread Christof Hurschler
I'm trying to compile filelight on my Woody system with KDE 3.1.2 Qt 3.2.1 and 
get the following error.  Seems like a problem with the code itself, or not??

Thanks again, Chris

Script started on Thu Jul 24 19:05:31 2003
k6:/usr/src/filelight-0.5.1# make
make  all-recursive
make[1]: Entering directory `/usr/src/filelight-0.5.1'
Making all in filelight
make[2]: Entering directory `/usr/src/filelight-0.5.1/filelight'
source='filetree.cpp' object='filetree.o' libtool=no \
depfile='.deps/filetree.Po' tmpdepfile='.deps/filetree.TPo' \
depmode=gcc /bin/sh ../admin/depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/kde -I/usr/share/qt3/include 
-I/usr/X11R6/include   -DQT_THREAD_SUPPORT  -D_REENTRANT  -O0  -c -o 
filetree.o `test -f 'filetree.cpp' || echo './'`filetree.cpp
filetree.cpp: In function `int selector(const dirent64 *)':
filetree.cpp:73: invalid use of undefined type `struct dirent64'
filetree.cpp:71: forward declaration of `struct dirent64'
filetree.cpp:73: invalid use of undefined type `struct dirent64'
filetree.cpp:71: forward declaration of `struct dirent64'
filetree.cpp: In method `class Directory * FileTree::scan(const char *, const 
char *, unsigned int = 0)':
filetree.cpp:90: implicit declaration of function `int scandir64(...)'
filetree.cpp:95: aggregate `struct stat64 statbuf' has incomplete type and 
cannot be initialized
filetree.cpp:103: invalid use of undefined type `struct dirent64'
filetree.cpp:71: forward declaration of `struct dirent64'
filetree.cpp:105: invalid use of undefined type `struct dirent64'
filetree.cpp:71: forward declaration of `struct dirent64'
filetree.cpp:113: confused by earlier errors, bailing out
make[2]: *** [filetree.o] Error 1
make[2]: Leaving directory `/usr/src/filelight-0.5.1/filelight'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/filelight-0.5.1'
make: *** [all] Error 2
k6:/usr/src/filelight-0.5.1# exit
Script done on Thu Jul 24 19:05:40 2003




Backporting Yammi

2003-07-25 Thread Christof Hurschler
I'm trying to compile yammi on my Woody system with KDE 3.1.2 Qt 3.2.1 and get 
the following error.  Any suggestions??

Thanks, Chris

Script started on Fri Jul 25 21:10:11 2003
k6:/usr/src/yammi-0.8.2# make
..
source='main.cpp' object='main.o' libtool=no \
depfile='.deps/main.Po' tmpdepfile='.deps/main.TPo' \
depmode=gcc /bin/sh ../admin/depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/share/qt3/include -I/usr/include/kde 
-I/usr/share/qt3/include -I/usr/X11R6/include   -DQT_THREAD_SUPPORT  
-D_REENTRANT  -O2 -fno-exceptions -fno-check-new  -c -o main.o `test -f 
main.cpp || echo './'`main.cpp
main.cpp:8: qwindowsstyle.h: No such file or directory
make[3]: *** [main.o] Error 1
make[3]: Leaving directory `/usr/src/yammi-0.8.2/yammi'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/yammi-0.8.2/yammi'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/yammi-0.8.2'
make: *** [all] Error 2




Re: Konqueror, UTF-8

2003-07-25 Thread Stephen Gran
This one time, at band camp, Craig Dickson said:
> I find that Konqueror (3.1.2-1.1, current Debian unstable) does not cope
> with UTF-8 web sites very well; it displays some characters well, and
> others not, even when Mozilla Firebird on the same machine (in the same
> KDE session, using the same fonts) can display them all correctly. An
> example of such a site can be found here:
> 
> http://aletheuo.ath.cx

They both look about the same to me - slight font change, but the shapes
are the same.  Of course, I don't know Greek, so my help is limited :)

steve:~$ locale
LANG=C
LC_CTYPE="en_US.ISO-8859-1"
LC_NUMERIC="en_US.ISO-8859-1"
LC_TIME="en_US.ISO-8859-1"
LC_COLLATE="en_US.ISO-8859-1"
LC_MONETARY="en_US.ISO-8859-1"
LC_MESSAGES="en_US.ISO-8859-1"
LC_PAPER="en_US.ISO-8859-1"
LC_NAME="en_US.ISO-8859-1"
LC_ADDRESS="en_US.ISO-8859-1"
LC_TELEPHONE="en_US.ISO-8859-1"
LC_MEASUREMENT="en_US.ISO-8859-1"
LC_IDENTIFICATION="en_US.ISO-8859-1"
LC_ALL=en_US.ISO-8859-1

Don't know if that helps - it may just be a font issue, although if
other apps can see it OK, probably not.

-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgptrIdG289rc.pgp
Description: PGP signature


Konqueror, UTF-8

2003-07-25 Thread Craig Dickson
I find that Konqueror (3.1.2-1.1, current Debian unstable) does not cope
with UTF-8 web sites very well; it displays some characters well, and
others not, even when Mozilla Firebird on the same machine (in the same
KDE session, using the same fonts) can display them all correctly. An
example of such a site can be found here:

http://aletheuo.ath.cx

On my system, if I bring this page up in Konqueror and Firebird side by
side, Firebird gets the Greek characters right, and Konqueror trashes
some of them. I can also see the Greek correctly on Windows XP with
either Mozilla 1.4 or IE 6.

Changing locales seems to have no effect; I have tried both en_US and
en_US.UTF-8 (the latter of which is my usual locale).

I don't see any outstanding bugs related to this. If no one knows of a
configuration change that would fix this, I can file a bug.

Craig


pgpKOGPwIEUGn.pgp
Description: PGP signature


Re: Qt versioning (was: KDE 3.1.2 broken)

2003-07-25 Thread Colin Watson
On Wed, Jul 23, 2003 at 06:59:53AM +0100, John Gay wrote:
> This brings up something I've been thinking about for a while now:
> 
> With the long release cycles of Debian, and especially the way it
> always seems to be poorly timed with other major releases, I.E. KDE,
> XFree86, Gnome etc, maybe the Debian people should look at spitting
> the releases up to allow a more up-to-date Debian.

This comes up about once a month somewhere. Not only do we not even
remotely have the infrastructure to release parts of the system
independently, but I suspect that there would be a significant loss of
efficiency due to the overheads of trying to manage multiple releases,
what with the relatively small number of people working on release
issues.

Also, I think the complexity of library dependencies precludes splitting
the system up this way. Take, for instance, the situation at the moment
where the kdelibs breakage prevents kdepim being updated in testing; a
new kdepim is needed in testing in order to avoid being broken by the
new version of pilot-link; the new version of pilot-link is needed for
the new version of gnome-pilot; and the new version of gnome-pilot is
needed in order to work with the new version of control-center. Thus
constructing a consistent system from what we've got actually requires a
fixed kdelibs in order for some parts of GNOME to be updated! What would
you do if this happened between two parts of a split release and the
other part wasn't scheduled to be released until six months down the
line.

The current testing distribution is *very* good at spotting these kinds
of problems, and releasing without those problems is a major feature of
Debian releases. If you attempt to split up the releases, I honestly
believe that it will be impossible to keep that consistency, because you
will end up saying "oh, we just need to release KDE over there in order
to release a version of base which doesn't break everything else", and
before you know it you're straight back to the current system.

The answer to our release problems is not to jiggle releases around in
an attempt to avoid having to fix packages so quickly, but to keep
packages in a working state as much as possible (e.g. KDE hasn't been
releasable even on its own for several continuous months, and is only
now beginning to approach that state). That benefits both our users and
our release cycle.

> Rather than releasing the entire system at one time, and then working
> on the next entire system, they could split it into major sections
> like: Base, XFree86, KDE, Gnome, etc. Each would work on building
> against the current stable version of the rest of the system. After
> all, KDE is releasing KDE-3.1.2 debs for stable, Brandan, Daniel Stone
> and others are releasing up-dated XFree86 packages for stable.

Adrian Bunk has a disclaimer in his stable backport repository that he
can't guarantee the safe operation of his packages with any other
backport repositories. He has an entirely fair point here, I think;
dealing with Debian unstable on its own is relatively easy, but dealing
with a forest of independent repositories is a maintenance nightmare.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]