[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Bug#36247: noatun crashes on startup with SIGSEV
From:       Charles Samuels <charles () kde ! org>
Date:       2001-12-17 9:43:22
[Download RAW message or body]

On Sunday 16 December 2001 23:04, Dan Armak wrote:
> On Monday 17 December 2001 01:35, you wrote:
> > this is caused normally by the mcopclass files in
> > noatun/library/noatunarts not being installed properly.  --prefix for
> > kdemm must be the same as for kdelibs (arts limitation)
> >
> > In any case, there is a 100% chance that this is a arts or packaging
> > error, and not noatun's fault. :)
>
> I thought as much. Leaving relocations of kdelibs etc. aside, what can be
> done about this specifically for artsd/noatun? Which parts/files/dirs
> shuold live where?

I think this is covered below.  I tend to write emails out of order :)

>
> Right now I have /usr/lib/kdelibs-2.2.2/lib/mcop and /usr/lib/mcop both,
> but the latter has many more files - in fact the former only has those
> files installed by the kdelibs package.
>
> > > Oh, and about artsd: it won't run here (len == can_write assertion
> > > fails on startup) but that's a problem with my sound driver (i810_audio
> > > from kernel 2.4.16), at least AFAIU. Hopefully it'll get fixed in
> > > 2.4.17, for now i'm using artsd -a null for testing of noatun.
> >
> > KDE 3.0's artsd features a threaded OSS driver which should fix that.
> >
> > It probably won't get fixed for 2.4.17, and you might want to backport
> > KDE3's toss driver.
>
> Thanks, I'll look into that. I was just hopeful abuot 2.4.17 in a
> wait-and-see way because it has several "i810_audio fixes" lines in its
> changelog so far.

Well, it's a common problem, actually

Certain yamaha drivers only implement 48000hz (in fact, the norm in a recent 
Alan Cox kernel)

about 5% of drivers don't implement non-blocking support that arts's oss 
driver requires.  toss doesn't use non-block support, which is why it works 
everywhere.

>
> > If you don't use the same prefix for kdemm & kdelibs, that's likely the
> > problem, otherwise, we can debug further.
> >
> > You might also want to report to me `artsd -l0` (that's EL ZERO)'s
> > output, especially the first few lines, in that it will report where it
> > looks for mcopclass files.
> >
> > For Noatun::Session, I have this file:
> >
> > /opt/kde2/lib/mcop/Noatun/Session.mcopclass
> >
> > So it should look in /opt/kde2/lib/mcop (since Noatun represents the
> > Noatun:: namespace)
> >
> > You should have a similar file/path.
>
> I have mine in /usr/lib/mcop/Noatun/. And artsd -l0 says:
> <...>
> addDirectory(/usr/lib/kdelibs-2.2.2/lib/mcop,)
> addDirectory(/usr/lib/kdelibs-2.2.2/lib/mcop/Arts,Arts)
> addDirectory(/root/.mcop/trader-cache,)
> <...>
> So obvisously it's missing /usr/lib/mcop, which I'd have taken to be the
> most std. path there is.
> Again, I have kdelibs in /usr/lib/kdelibs-2.2.2 and everything else,
> kdebase && kdemm included, in /usr. To configure packages this way I have
> to set KDEDIR=/usr/lib/kdelibs-2.2.2 and pass --prefix=/usr, otherwise they
> won't find the kde libs. It's a fault of the KDE configure script which
> doesn't have a parameter which I might pass to point to the localtion of
> kdelibs, but only searches in a number of hardcoded dirs, and the only
> likely dir is $KDEDIR.

Well, you'd have to ask stefan westerfeld how arts knows where to look.  I'm 
fairly certain that it equals --prefix 

>
> So what can I do? You say this is an inherent kdemm problem where kdemm
> must live in the kdelibsdir directory. Does this affect anything other than
> noatun? Anything other than mcop/Noatun hierarchy? In any case, isn't there
> some way to make artsd search in a user-specified dir as well as in
> kdelibsdir? What'd kde-config good for, if I can't get artsd to use it? :-)

It affects _everything_ that isn't built with the same prefix as kdelibs.

>
> If there's not immediate solution of this kind, I may look at 1) patching
> artsd to this effect or 2) making a condensation for mcop files and letting
> them all live in 1 place, with the other mcop dir (whichever I choose) a
> symlink to that one location. Any tips with these approaches?

I can't especially recommend patching artsd, since I wouldn't be shocked if 
someone forgets to do this in a future package of kde (upgrades), or if a 
user makes his own (compatible?) packages from the standard kde source code.

If I were making this choice, I'de just put all of kde in one place, since 
other customizations (like option 2) are likely to cause problems in the 
future.

Stefan: how about artsd get an API that allows me (noatun) to be able to add 
search directories, that is, tell artsd to look in my own prefix/lib/mcop ?


>
> Oh, and about the FHS/LFS: those who interpret it here say that only
> binary, precompiled pckages go in /opt. Like e.g. staroffice. But we're not

Well, sure we're not, however, I feel it's my civic duty as a linux user, and 
as a person that's had to endure all sorts of distribution stupidity, to tell 
you that not packaging big things like kde in /opt is, well, redhattish.

But I digress, and hope that Gentoo makes the right choice at the end :)

> here to discuss that. So - we have apparently already located the problem.
> Thanks a lot for your help!

Thanks for giving me an opportunity to defend the use of /opt :D

-Charles
_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]