Hey there... an openal-soft maintainer here (who also works closely with openal-soft upstream),
On Fri, Jul 25, 2014 at 3:20 PM, Philipp Schafft <l...@lion.leolix.org> wrote: > reflum, > > On Fri, 2014-07-25 at 09:47 +0100, Simon McVittie wrote: >> affects 755846 libopenal1 >> thanks >> >> > I will have a look in the next days if it is possible with the current >> > upstream code base. >> >> I think the most appropriate answer would be for libopenal1 to either drop >> the libroar-compat2 dependency again, or turn it into a dynamically-loaded >> plugin that can be dropped to Suggests (like its dependency >> on libportaudio2). I would say "... or Recommends, like libpulse0", >> but according to popcon, roaraudio is several orders of magnitude >> less widely used than pulseaudio, and only 0.45% of libroar-compat2 >> installations actually have roaraudio installed. > > RoarAudio isn't used in Debian *because* Ron Lee droped all the useful > dependencies to it while his personal vendeta (see the archives). > Droping dependencies is what broke the package. > And Debian seems to be all about 'drop it, NEVER fix it!'. This bug > report supports this. It's no longer about fixing but went directly into > a droping request. > > As upstream I often hear from people that they wonder why RoarAudio > isn't working when they install the debian package: The answer is > because Debian decided (see archives) NOT to support RoarAudio because > of.... in fact I never heared about any technical reason for that. > If someone wants to pick it up, dust it off, fix it up and upload it, I doubt anyone would stop them. The problem now is finding someone willing to do that. > I will consider to recommend Patrick Matthäi to send a removal request > for RoarAudio as this ongoing drama is more harming the RoarAudio > project than bringing anyone forward. > > Btw. as you also pointed to the DECnet support: It's perfectly the same: > Dependencies to it were drop not fixed so it became useless while I see > people worring about it on the project's mailinglist as they actually > use it to make money. > > It's said to see such a grate project as Debian being no longer > interesting in fixing problems. > If no one is interested in fixing the problem, then yeah, the problem gets dropped for the sake of expediency in solving a larger problem. > >> Looking into libopenal1 in more detail, it doesn't actually have a >> backend to support roaraudio: what it supports is (among other things) >> libsndio, which as far as I can tell is the OpenBSD audio API. >> In OpenAL 1.14 this *was* dlopened, but in 1.15 it was changed >> upstream to use ordinary library linking. That makes perfect sense >> if you're on OpenBSD and libsndio is "the" audio API, but doesn't really >> make sense on Debian where "sndio" is really roaraudio. >> >> OpenAL maintainers, please consider reverting the sndio backend to use >> dlopen like 1.14 did, or dropping roaraudio-via-fake-sndio support >> until/unless someone provides an actual roaraudio backend analogous >> to the pulseaudio backend. > Roger that, I'll get on this. I plan on keeping with upstream so it is likely that we'll go with option 2 until someone takes up the roaraudio packages. At this point, unless someone takes up that torch, we'll drop roaraudio-via-fake-sndio support until this gets fixed. (See below as to the real problem.) > >> A real roaraudio backend would make configuration >> make more sense, too: it seems more reasonable to enable roaraudio via >> "drivers=roaraudio" than to use "drivers=sndio" and rely on knowing that >> sndio is really roaraudio. > > If someone is going to work on this, please let me know. I'm sure this > can be done in a nice and smooth way! > If someone would be so kind as to provide a patch upstream for Chris, I'm sure he would take it. It would eliminate our roaraudio-via-fake-sndio problem. >> However, libroar2 depends on libdnet (#755934, etc.) which is not ready for >> multiarch: it contains /usr/lib/librms.so.2 which you will notice is not >> architecture-prefixed; so making libroar-compat2 and libroar2 multiarch >> while libdnet is used would just move this bug a couple of steps down the >> stack, to "I can't install both libdnet:i386 and libdnet:amd64". > > This is what I meant above: a sub-sub-sub-sub-sub depneds of a is not > ready (but could be fixed) so let's drop a direct depends. Yay. > > Why is there no one working on getting librms fixed? At least upstream > wasn't informed about any problem so it's debian internal again? > Is there already a bug filed for librms? If this is the root of all evil and drama, then it should be handled. Cheers, Bret -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
