Re: qt3 "Hello World"
> > Any suggestions? > g++ -I/usr/include/qt Also, you may want to consider using the Qt3 qmake utility. It looks like it makes pure Qt3 projects a LOT easier to compile for any platform that Qt supports. Ciao, Gordon
Re: More on libkdeui problems FIXED!
On Thu, Nov 29, 2001 at 12:12:31AM +, John Gay wrote: > By removing the /usr/local/kylix/bin from my ld.so.conf file and > re-running ldconfig I was able to sucessfully start a kde app! This > should allow me to return to a KDE desktop again! I jsut won't be able > to run my kylix apps. I don't know pascal anyway. You can probably stil run Kylix by modifying its startup script (or making your own) to set the LD_LIBRARY_PATH env variable like so: export LD_LIBRARY_PATH=/usr/local/kylix/bin:$LD_LIBRARY_PATH Ciao, Gordon
Re: kapm-idle
On Tue, Nov 27, 2001 at 09:07:31PM -0500, Tom Allison wrote: > > What is this? I believe that kapm-idled is a kernel process. You've probably got APM (power management) enabled in your kernel. > When ever I check 'top' this thing is cranking away like crazy. It's taking up all your processor's idle time and doing some special APM thing with it. I've got it too and I'm not running KDE. Ciao, Gordon
Re: ARTS, ALSA, and DevFS
It depends on what version of alsa you're using. arts only supports the older 0.5 (stable) version of alsa. If you're using alsa 0.9, you're outta luck and you'll have to get the OSS compatibility layer working in alsa and use the normal OSS version of arts. There is a new version of arts in the works to support 0.9 but it's not done yet, AFAIK. About getting the OSS compatability to work, I've got a config for alsa and some devfs config stuff that makes it all autoload. Unfotunately, I'm not at that machine but I can send it to you later this evening if you want. Ciao, Gordon - Original Message - From: "Josh Hansen" <[EMAIL PROTECTED]> To: Sent: Friday, November 09, 2001 12:08 PM Subject: ARTS, ALSA, and DevFS Boy oh boy oh boy - three cutting edge technologies that just aren't quite agreeing with each other. Here is my problem: I am using devfs, so when I load my ALSA sound modules the usual /dev/dsp and /dev/mixer etc. aren't created, only the things like /dev/snd/hwD0C0 and other ALSA-specific devices. Seems to me that if I am using the ALSA version of ARTS it shouldn't matter if the OSS-compatibility devices like /dev/dsp are there or not (perhaps my reasoning is wrong???) So, what device do I point ARTS to so it uses ALSA natively? Or is it absolutely necessary to have a /dev/dsp ??? I would prefer not to have to modify the devfsd to create a /dev/dsp when ALSA loads - rather I would like to run ARTS in pure ALSA-native mode. Thank you for any advice! - josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde's sound works, other utilities' doesn't
On Thu, Nov 01, 2001 at 09:02:42PM -0800, sucks the bag wrote: > just started running kde (off the testing branch) recently and everything is > fantastic EXCEPT for sound-wise. all of kde's built-in sounds play find and > artsplay plays waves as it should, but non-kde applications complain about > the device being hijacked. xmms says "/dev/dsp: Device or resource busy", > mpg321 says "Error opening libao oss driver. (Is device in use?)", audacity > just freezes. all of these programs work as usual under windowmaker. i'm a > member of audio, my /dev/dsp permissions are right: artsd is using your sound device, thus it is busy. You'll need to find artsd versions of whatever non-KDE apps you use. Ciao, Gordon
Re: filters in kmail
> contains debian-kde@lists.debian.org > and > Cc contains debian-kde@lists.debian.org I imagine that would have to be an OR instead of an AND. Ciao, Gordon
Re: Kwork/Koffice
- Original Message - From: "Bruce Miller" <[EMAIL PROTECTED]> Sent: Friday, October 26, 2001 10:40 AM > On the appearance of the guide: This was the first document that I have > drafted in AbiWord. As a work in progress, AbiWord has no help files. The You might want to consider using DocBook. KDE uses DocBook for all its documentation and it can be converted into numerous formats. http://www.docbook.org/ Ciao, Gordon
Re: kdm dies
On Sun, Oct 21, 2001 at 01:18:50PM -0400, Daniel Jones wrote: > With kdm debugging enabled, I'm now getting an error in > syslog to the effect that "can't start > /urs/X11R6/bin/XF86_SVGA" I've uninstalled XF86_SVGA and > reconfigured xfree. Manually starting xfree with "startx" > works fine, using xserver-xfree86. I assume that kdm still > trying to use the old server is the result of an error in a > configuration file somewhere. Which configuration file > would cause kdm to use a different server than startx? I think it's something like Xserverrc in /etc/X11/kdm. But this will probably be a better way to find it: grep -r XF86_SVGA /etc/X11 Ciao, Gordon
Re: Anti-aliased fonts in KDE 2.2.1: ``Adobe" fonts not available when anti-aliasing enabled
> is marked or not. The most obvious difference is that the well- > known 35 Type 1 fonts (including Helvetica, Times, etc) disappear > when anti-aliased fonts are implemented by using the checkbox. Is there line like this in your XftConfig file? dir "/usr/X11R6/lib/X11/fonts/Type1" It should be right at the top along with a similar line that references the TrueType font directory. Ciao, Gordon
Re: "No Text!" again..
> > suppose you learn something new every day (like how removing a package and > > putting it back doesn't always work :-)) > > > > cheers! > > Just apt-get remove'ing won't always work, but dpkg --purge does :-) And 'apt-get --purge remove evilpackage' works as well. Ciao, Gordon
Re: [wturkal@cbu.edu: Bug#114274: libarts-alsa: will not drive alsa]
On Wed, Oct 03, 2001 at 05:45:33PM -0600, Ivan E. Moore II wrote: > On Wed, Oct 03, 2001 at 12:05:23PM -0400, Gordon Tyler wrote: > > I guess then the fault lies with alsa and it's packaging. It shouldn't allow > > an old library that is incompatible with the newer kernel modules to > > co-exist. > > how is it supposed to know and why should they not co-exist? libasound1 and > libasound2 do not have the same files...so there is no need for them > to conflict. This allows folks like me to develop for libasound2 while > keeping > a functional libasound1 system. But libasound1 uses the alsa 0.5 device protocol whereas libasound2 uses the alsa 0.9 device protocol. If you have the alsa 0.9 driver modules installed, then libasound1 is useless. But yes, I can see your point about how is it supposed to know, since the alsa driver modules have to be compiled and installed separately and they don't have an identifiable package name that the libasound* could depend/conflict on. So I guess what I'm trying to say is that the bug reporter's problem is that he probably has the alsa 0.9 driver modules installed which don't work with libarts yet. Ciao, Gordon
Re: [wturkal@cbu.edu: Bug#114274: libarts-alsa: will not drive alsa]
> Package: libarts-alsa > Version: 4:2.2.1-5 > Depends: libaudiofile0, libc6 (>= 2.2.3-7), libstdc++2.10-glibc2.2 (>= 1:2.95.4-0.010810), xlibs (>> 4.1.0), libasound1 (>= 0.5.5) > ^ > > libasound1 does not conflict with libasound2...so you can have both > libraries installed at the same time. I guess then the fault lies with alsa and it's packaging. It shouldn't allow an old library that is incompatible with the newer kernel modules to co-exist. Ciao, Gordon
Re: [wturkal@cbu.edu: Bug#114274: libarts-alsa: will not drive alsa]
> arts does not work with alsa 0.9. only 0.5 currently. Then how come it installs on a system that has alsa 0.9 installed? Surely that means the depends are not set correctly. Or else alsa's packages are just in a mess. I'm leaning towards the latter, I had lots of fun getting alsa to work. Ciao, Gordon
Re: [wturkal@cbu.edu: Bug#114274: libarts-alsa: will not drive alsa]
> Who all is having problems with the libarts-alsa package? I don't use KDE currently (it randomly freezes on my laptop a few minutes after login) but I have had some experience with ALSA recently. The latest version of arts is 0.9betasomething whereas the latest version of libarts-alsa is 0.5something. From my experiences with ALSA, there was a change in the protocol ALSA uses in communicating through the /dev devices. Thus applications which use ALSA 0.5 libraries won't work with ALSA 0.9 kernel modules. It's a bit of a mess actually. There are 0.9 versions of the various ALSA packages in testing except alsa-base or something like that which are 0.5 in testing and 0.9 in unstable. In order to get ALSA to work on my system I hade to install all the 0.9 packages from testing and some from unstable. Two possible solutions would be to recompile/port libarts-alsa with alsa 0.9 or split it into a 0.5 and 0.9 version. Ciao, Gordon
Re: 2.2.1
> A) when will 2.2 be in Testing ? (Soo, looking forward to this) It's already there. At least on the mirror that I use. > > B) Will 2.2.1 make it into woody before the release ? (Beg beg beg.. or do we > have to bribe you some more ? :) ) Ditto. Ciao, Gordon
