Bug#984275: openmw is marked for autoremoval from testing

[bret curtis]

This bug is resolved with the release of OpenMW 0.47 which is waiting in
the wings for approval and upload:
https://salsa.debian.org/games-team/openmw

It relies on:
* recastnavigation being uploaded to Debian:
https://mentors.debian.net/package/recastnavigation/
* MyGUI 3.4 being uploaded to Debian:
https://salsa.debian.org/psi29a-guest/MyGUI

MyGUI could possibly be maintained by games-team, but I don't know how to
initiate that transfer.

Cheers,
Bret

Bug#961536: openmw FTBFS with openscenegraph 3.6.5

[bret curtis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Sebastian,

On 2020-06-11 at 20:28, sramac...@debian.org wrote:
> Hi Bret
>
> The build on mipsel failed:
>
https://buildd.debian.org/status/fetch.php?pkg=openmw=mipsel=0.46.0-1=1591883193=0

>
> It's missing -latomic. But I'm wondiering if it really makes sense to
> build the package on mips*. Is anyone able to play games on mips?
>
> Cheers
> --
> Sebastian Ramacher

That's not that big of a loss, 32-bit mips can only address 2GiB of memory
per process anyway. I would assume the moment you load Morrowind and its
expansions that it would quickly run out of memory anyway.

I added mipsel to the same list as armel and armhf.

Cheers,
Bret
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 7.7.9 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAGBQJe4qd+AAoJEMI3e31YTLkwmW4P/1BPe4E4RK0Vw0pdSQf5
Fyq1iQt2Xb73Y9swL3pCKdx5/3QuV+JmTgL7o563Je2KG78SvoiQr0nXeAp6
zE7ZuNUEtuWd5GSzxSvbidGv8FXyNOseiy2JqZEUkUX278Ezir5XFwBaX2na
xfobOjoIR+y61A7C/z/0saoYL53u71RRxuCrkKKGya+FLkOYyuM98Xb2EnNI
I0yEVqoxCjgWD4fgKeveSHfpMBV+loeXqcWVmuNoKRrc0Ln1LkwtzMvNKOKw
XA4wYwlX1aY1miVzcCBqm6QVBNDvxprtfQCi/gcC3CYSHgV/P0a/U2nYDOcw
EQsr6W+AF0NpZIBBTZHVK6wDvUIrHqtDaA8vrB67qeAmb56Rea1z9OsSvfmj
gZWREmHAkp0P1YdpLu6kPwTk/xnVOaPg+G+VwTQUzx1Gizir+gmp87T3wHGx
I7cfiF4QHw8HJb0E/lSo9EKvYUv01hsRw0zfAgdfC2i0x1oSa+VoaASkfldE
wJdq+9SDykFGQKWEXnU2lR0K6FHpnJqdu/WFYVLLSObdB97NUn57yG0DL8vj
AcaeWrL2d8GoLZ990OFYACzJvXjgOgCg+0RA8GmkRMtFH6sCQ/fK4TPqaB0/
2EECPawnAiSs6Pey/SB4hjvXntJqd3FmtYW9yDBcAU8FELIlJTFxvkgz5tl2
4CuP
=seRY
-END PGP SIGNATURE-

Bug#961536: openmw FTBFS with openscenegraph 3.6.5

[bret curtis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Sebastian,
On 2020-06-11 at 09:11, sramac...@debian.org wrote:
> Hi bret
>
> On 2020-06-09 18:28:02 +0200, bret curtis wrote:
> > OpenMW 0.46 has been released and I've uploaded it here, it just
> > someone kind and just to review and upload. :)
> >
> > https://salsa.debian.org/games-team/openmw
> >
> > Once uploaded and built, this bug should be closed.
>
> Thanks, uploaded with the alternative build dependencies on
> openscenegraph reversed (patch attached). The buildds only consider the
> first alternative and openscenegraph-3.4 is no longer in the archive.
>
> In d/rules, the dh_missing call should be placed in an override for
> dh_missing.
>
> Cheers
> --
> Sebastian Ramacher

That's great news, and that's fine. Thanks!  OSG 3.4 is only there for
launchpad PPA reasons as one of our last releases against 3.4.  Moving
forward to 0.47 we'll target 3.6 exclusively and drop support for OSG 3.4
so I'll drop that eventually from control.

I have a question about getting OpenMW out of 'contrib' and into 'main'.
What exactly is holding us up?

We have an example-suite (our own game for lack of a better name) that can
be run with OpenMW, would it be better to package this along with OpenMW or
package it up as something new and put a depend on OpenMW for it?

Cheers,
Bret
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 7.7.9 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAGBQJe4fsPAAoJEMI3e31YTLkwwekP/3NrQPwXR1fkLeagh9tR
/npsMGO7ZNFIYf6Ds12PGYn6ZKX5moxfeWYe7fVWqouRROMpvr7WzBGy7Fgd
KBKtLQuJLnOqPSJdWmX5dhlhgejKgeiVTMsp3fIZifl4TOyfp1qhNDjG04TD
ybR0q5vq2K7MM+/az4pkp0tr/RDewP3YOMJ5vJpFMZWt7woCWrz28mKV91R8
b8CARV1VvOgPv5QBnm6DGIDD2lGTN3L9tl3wPrqbl4ezm+9SfI4sc/hgJm9a
pRaKwTTjQj50A/ab+UOX+hvdNwhxArPLsnlI2pxaEXqnsulaLVsekQuvgHnV
zPVS4WXshlhmke7G37nsMVXHladc5jk4OICKfRvRXDloTUJTM4OYCSICAaeE
ZDtpNc0PynSfIlXH5yjCVpBSOBfBudbFQmW71AvoS4QV2gWZ1u8pIdLZshuK
o0CgWQ6iSSeX5djpyz+h7CdPwYTEaVsVqkFbkT3zpmsMYZmAwpUMwHzGcO2s
vu5buDWPeSy6926WT7r4DFwZ3X9+QMrkqPFxYq/hhzgsjrPEQ2mer+j/7A3F
DW1ngp11cMdsZ8pqwvSfrm3fcdnUNA7mpWLgiw4vqlizRT+gf40hrUqtKkQ2
fACKNwpN43ZZv5G+kBfnkegD5bVuGRz5kMYBd/+FSpppxTavMiM7MtgHXuce
LKUA
=1r1d
-END PGP SIGNATURE-


0xC2377B7D584CB930.asc
Description: application/pgp-keys

Bug#961536: openmw FTBFS with openscenegraph 3.6.5

[bret curtis]

OpenMW 0.46 has been released and I've uploaded it here, it just
someone kind and just to review and upload. :)

https://salsa.debian.org/games-team/openmw

Once uploaded and built, this bug should be closed.

Cheers,
Bret

Bug#961536: openmw FTBFS with openscenegraph 3.6.5

[bret curtis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

That's a pity but give a few more days and 0.46 will be released. No point
in patching and going through this whole process again, I'll make sure
everything is ready to go to to upload.

Cheers,
Bret
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 7.7.7 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAGBQJe0TMYAAoJEMI3e31YTLkwkoQP/1DX1o6hIXWmpri2t6fB
6qNgG1ORzIxIgS+UFz850xApRJVbbP4s+SJqmsDi3jd75WqQnhefWCLIIrte
gXeJICbjyBdTFfnNaErZ5YsJRBKD8dIdeM7b22qXSagAAXLjxHqvvZ0Axuuz
mDLb51bizui7UN1qPPo03D0F4Y/UBLJCRoYNjr8N3DNEGih2/Ia5zhc5FI4A
qRjhHA10gk3Zd8j40gd044PIjO+PFsCK1j0HuxGJCtjxYSu8jEh3G4bi7dfn
AF6BItEfADYQXcqJjxK0bKOWMO9BehmCWEtyjqy0LTjQSF/5orYJgqMFRIru
20gPNFNQZfY44eSJg9xV7OAbFiGtZVI3eQpgM7cavdQmIQyKDJAeWv0F8XxK
ooaMO8OoZ1VaauBfuf1lXUa8c1iBr79gLadcmDhP/71EnggLpkrhLqyyoW7a
CX98DaqjQ2fq6ssRC93X7W3+t2mvPfRy2Wp0nuI41iM5RWArwhuLN45zxxkW
Jezp0ayJl/tA7rl/ccgV5r1vODDSWRkv9aSvr1yHPz+Be6JBPjMt6MamslPA
6qXlwfokdCqUBntcZi0UdJTyZEAHKIbTxdBxmB/8fG/SN+W7JzrnZzCjyDC+
SGXoCOpRpftmrdwKaRrhhTf9w5Ebd9qiBrRfKo5V1YItvoAt1xj1YKBCaCH5
aQ4S
=75vR
-END PGP SIGNATURE-

Bug#958917: openmw: random crashes

[bret curtis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

yes this is a known issue and someone needs to trigger a rebuild once OSG
3.6.5 gets out of experimental.

This is related to bug #945875

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945875

Again, this is pretty urgent because it also effect Ubuntu 20.04, a LTS
where they are shipping a busted OSG 3.6.4

Does anyone with contacts with Ubuntu known of a way to get a package (OSG)
backported into a LTS release?

Cheers,
Bret
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 7.7.7 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAGBQJesqeDAAoJEMI3e31YTLkw8ZsP/2K1JUT4r6H9ZE9REzCF
eOrEt/8Px9dolSMwzQoTPGKlHKL9X+W6pbh8iBuIe9GKRoKfhTxYilQj2Qxr
MErmeYHG2jltoth36iMonMpoATPLZeBXXNTJxnUK9FldkjwZ6Vi4ssOA1Ztw
AHhv6ya5Cdk1IxQG8iC5FwrCRsu15OBSdcOfZ1Toxa+lvLX3ivquErmuuHRz
+HEUW6+MUxK7oE3zq0yhx/lojMTPFhIEjjFvRm3/kHoOWffo8a7AxBXq2ZFJ
Z2KPpA/Dj4Ch31PjIHhj8gTnaqA/vu7AYl/hCIFWGX5y6JuOyaswMefTICBw
8HUdJaQTgLOF5GnP/FbSYcnsbCrExocOVvJThSmdprKqI1crXhvRrXFwU4se
MZhcRATpYpS9Bponwf3HFZ/gJMFcMKg5vcdPsHYnUfdUSZKa7LSGDvh2SavH
09MIWqbcfrLmy5WSy/hD2mlau/tAhg47HEqi9UVE9GStd5kpSPtoGANpsNqU
lqsFvMzUUygmgBWTpeiB6C1UIHCz/ub1OdSk4TAgcQeoqp2fYFl0ttdAsjsl
iZzYzCJXZOPbQbYY+LB/ygbji4E8ZRUdQPIXmZAKpH7p2rb0mLpT3ddCDEME
lB3eMg5ILSIxM0uhrtIWOFni3BCXiiCA44OSMEf2jIwFjSvGAd136TOM1Rl9
zrVP
=YsDW
-END PGP SIGNATURE-

Bug#945875: openmw: Crash when saving

[Bret Curtis]

On Fri, 27 Mar 2020 at 09:29, Alberto Luaces  wrote:
>
> On 27/3/20 8:26, Bret Curtis wrote:
> > The best way forward in resolving this bug is to get OpenSceneGraph
> > package bumped to 3.6.5 right away. This requires the help of Alberto
> > Fernández, it's package maintainer.
> > https://tracker.debian.org/pkg/openscenegraph
>
> Him, OSG 3.6.5 is ready
> (https://salsa.debian.org/openscenegraph-team/openscenegraph-3.2/-/blob/master/debian/changelog),
> I'm just waiting for Manuel to upload it.
>
> Regards,
>
> Alberto

Man, it's be in there a month. It would be a pity to see OSG be broken
in Buster, but hopefully we get it in before Ubuntu's LTS 20.04 Focal
release. :/

I hope it gets uploaded soon.

Cheers,
Bret

Bug#945875: openmw: Crash when saving

[Bret Curtis]

On Sun, 22 Dec 2019 11:01:55 +0100 Mel Collins  wrote:
> I also recently encountered this.
>
> It appears that there's been an update which reverts to the earlier
> version of OpenSceneGraph, but at the time of writing it's still
> awaiting a release, according to the package tracker:
>
> https://tracker.debian.org/pkg/openmw
>
>
> As a workaround, since the only change in the most recently released
> version appears to have been the OpenSceneGraph dependency, one can get
> the previous version of the packages (0.45.0-3) from the Debian snapshot
> archive:
>
> http://snapshot.debian.org/archive/debian/20190709T210115Z/pool/contrib/o/openmw/
>
> I downloaded and manually installed (dpkg -i) the packages from there,
> and have been playing with that version for the past few days without issue.
>
> --
> Mel

Hello,

OSG-3.6 (3.6.0 through 3.6.4) introduced many breaking changes from
OSG-3.4, not just breaking changes but many bugs that are still not
fixed. OpenMW has been in contact with the OSG team now for over a
year to correct them but Robert Osfield's priorities are nearly fully
focused on VSG (Vulkan Scene Graph) so movement here is slow.

OpenMW has contributed fixes to OSG and believe that a majority of
bugs have been squashed as of OSG 3.6.5 that allows OpenMW to longer
'crash' as this bug indicates but there are other performance issues
that won't be addressed until OSG 3.6.6 is released.

To this extent, the OpenMW team has been pulling double duty in
developing OpenMW further and also fixing regressions and performance
issues in OSG itself.

The best way forward in resolving this bug is to get OpenSceneGraph
package bumped to 3.6.5 right away. This requires the help of Alberto
Fernández, it's package maintainer.
https://tracker.debian.org/pkg/openscenegraph

Cheers,
Bret

Bug#914537: openmw: segfault at start

[bret curtis]

Thanks Fred!

We're tracking it upstream. Will keep this bug posted with results.

https://gitlab.com/OpenMW/openmw/issues/4737

Cheers,
Bret

Bug#885401: openmw uninstallable

[bret curtis]

Hello Markus, that would be awfully friendly of you. :)

Order of operations:
1) MyGUI needs to be bumped:
https://qa.debian.org/cgi-bin/vcswatch?package=mygui  I've cleaned up
the package a bit in the process to handle GCC7, debug symbols and
other bits.
2) OpenAL-Soft https://qa.debian.org/cgi-bin/vcswatch?package=openal-soft
needs love as well, but this isn't required for OpenMW release.
3) OpenMW, once the libraries above are available we can upload/build
OpenMW packages: https://qa.debian.org/cgi-bin/vcswatch?package=openmw

bonus points:
4) WildMIDI should be updated as well:
https://qa.debian.org/cgi-bin/vcswatch?package=wildmidi  <-- this has
nothing to with OpenMW but is a new upstream release that I maintain.
:)

Cheers,
Bret

On Thu, Dec 28, 2017 at 5:49 PM, Markus Koschany <a...@debian.org> wrote:
> On Thu, 28 Dec 2017 12:47:01 +0100 bret curtis <psi...@gmail.com> wrote:
>> Hello Bret,
>>
>> There are two things going on here. One is that libopenscenegraph
>> needs to be rebuilt since that specific (version) gdal package (so
>> many dependencies down) is no longer available. Look at the apt
>> output, OSG depends on gdal-abi.
>>
>> The second problem is that openmw on Debian is two releases behind. I
>> have them all ready for upload, they just someone who has the upload
>> permissions to upload the package. I, as package (unsigned) maintainer
>> do not have that ability. In additional to uploading, the MyGUI
>> library needs to be rebuilt with GCC7 before OpenMW can be uploaded.
>> Again, this is out of my hands and we're waiting patiently for someone
>> who has the ability to upload, to upload. Everything is more or less
>> ready to go.
>
> Hello Bret,
>
> I can review and sponsor your packages. You just have to tell me in
> which order I shall upload them and where I can find them.
>
> Regards,
>
> Markus
>

Bug#885401: openmw uninstallable

[bret curtis]

Hello Bret,

There are two things going on here. One is that libopenscenegraph
needs to be rebuilt since that specific (version) gdal package (so
many dependencies down) is no longer available. Look at the apt
output, OSG depends on gdal-abi.

The second problem is that openmw on Debian is two releases behind. I
have them all ready for upload, they just someone who has the upload
permissions to upload the package. I, as package (unsigned) maintainer
do not have that ability. In additional to uploading, the MyGUI
library needs to be rebuilt with GCC7 before OpenMW can be uploaded.
Again, this is out of my hands and we're waiting patiently for someone
who has the ability to upload, to upload. Everything is more or less
ready to go.

Cheers,
Bret

On Tue, Dec 26, 2017 at 7:39 PM,   wrote:
> Subject: openmw uninstallable
> Source: openmw
> Version: 0.41.0-1+b1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> Attempting to install openmw with apt fails.
>
> When I try to install:
>
> sudo apt install openmw
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  openmw : Depends: libopenscenegraph-3.4-130 but it is not going to be 
> installed
>   Recommends: openmw-launcher but it is not going to be installed
> E: Unable to correct problems, you have held broken packages.
>
> sudo apt install libopenscenegraph-3.4-130
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  libopenscenegraph-3.4-130 : Depends: gdal-abi-2-2-1 but it is not installable
> E: Unable to correct problems, you have held broken packages.
>
> sudo apt install gdal-abi-2-2-1
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package gdal-abi-2-2-1 is not available, but is referred to by another 
> package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> It appears that I have the necessary libs on my machine, and that the virtual 
> package that libgdal20 provides is missing.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Bug#871299: libmyguiengine3debian1v5: requires rebuild against GCC 7 and symbols/shlibs bump

[bret curtis]

Hello,

I've hopefully addressed the issues brought up and made an additional
commit/push. Can you review and see if this is correct and ready for
upload?  I have no access.

Cheers,
Bret

On Mon, Sep 25, 2017 at 11:31 AM, Simon McVittie  wrote:
> On Mon, 07 Aug 2017 at 15:47:16 +0100, jcowg...@debian.org wrote:
>> It appears that your package provides an external symbol that is
>> affected by the recent name mangling changes in GCC 7. See:
>> https://gcc.gnu.org/gcc-7/porting_to.html#conversion-op-mangling
>
> I started to look into fixing this bug and noticed that there is a new
> version prepared and tagged in collab-maint git. However, I reviewed that
> version and I don't think it's ready for a sponsored upload.
>
> I would suggest not tagging versions until they are finalized and
> uploaded. Now that there is a tag for -6 that never got uploaded,
> the least confusing thing to do would probably be to skip -6 and have
> the next maintainer upload be versioned -7.
>
>> To ensure that new executables will pull in the newer version of the
>> library built with GCC 7:
>> - Your library package should Build-Depend on g++ (>= 4:7).
>
> This has not yet been done in the version in collab-maint.
>
>> - If your package provides a symbols file, ensure that the new
>>   conversion operator symbols have a version matching the version this
>>   bug is fixed in (including the Debian revision and tilde if
>>   necessary).
>
> Neither has this. The minimal version for the affected symbols in the
> affected library should be bumped to the version that is uploaded to
> fix this, plus "~" (so for 3.2.2-6 they should have been 3.2.2-6~).
>
> Because openmw's symbols files contain the mangled names
> (_ZN5MyGUI10DataStreamC1EPSi@Base) and not the unmangled names like apt's
> symbols file
> ((c++)"MyGUI::DataStream::DataStream(std::basic_istream std::char_traits >*)@Base")
> it might be sufficient to let dpkg-makeshlibs add the new symbols at build
> time. However, it's probably better if the symbols file in the source
> package is updated.
>
> From the updated package in git:
>>   * Cleanup and rebuild (Closes: #871235, #871299)
>
> I don't think this changelog entry (or its accompanying git commit message)
> is sufficient. It doesn't describe what cleanup took place or mention why
> the rebuild is desirable.
>
> I would be happier with something like:
>
>   * debian/copyright_hints: Remove
>   * Update Standards-Version to 4.0.0 (no changes required)
>   * Rebuild with g++ 7 to pick up name-mangling changes and be compatible
> with recently-rebuilt dependencies (Closes: #871235, #871299)
>
> Lintian also complains that Thu, 18 Sep 2017 never existed (the 18th was
> a Monday). Copy/paste error?
>
> Regards,
> smcv

Bug#850021: openmw: FTBFS on armhf: error: 'GL_AMBIENT' was not declared in this scope

[bret curtis]

Known issue, please read this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838792

Summation: OSG is being built with libGLESv2 and not with libGL on
armhf, OpenMW doesn't support GLESv2, nor GLESv1. If we 'fix' the
build issue, OpenMW will run, but you only see a black screen. OSG is
compiled with libGLESv2 support because of the plugin osgQt.so which
requires Qt. Qt is compiled with GLESv2 support instead of libGL on
armhf.

Short term solution: Have OSG build without Qt support thus disabling
osgQt plugin, then remove the armhf hacks to support GLESv2. It will
compile

Long term solution: Qt on armhf needs to be built with libGL instead
of libGLESv2.

If necessary, please file a bug against OSG-3.4. Hopefully this won't
be necessary as I've added Alberto to conversation who maintains
OSG-3.4

For example, on OpenMW's launchpad, we have our own OSG-3.4 builds
that use libGL instead of libGLESv2 on armhf and OpenMW works just
fine on armhf.
https://launchpad.net/~openmw/+archive/ubuntu/openmw/+packages
https://launchpad.net/~openmw/+archive/ubuntu/openmw/+files/openscenegraph-3.4_3.4.0+dfsg1-4+openmw1~xenial1.debian.tar.xz

I hope this helps. I guess this bug will stay open until either
OSG-3.4 is updated (implying either removal of osgQt or update of Qt
itself) or we remove OpenMW from armhf support.

Cheers,
Bret


On Tue, Jan 3, 2017 at 10:29 AM, Andreas Beckmann  wrote:
> Package: openmw
> Version: 0.41.0-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> Hi,
>
> openmw FTBFS on armhf, but built there previously:
>
> https://buildd.debian.org/status/fetch.php?pkg=openmw=armhf=0.41.0-1=1482596646
>
> [  8%] Building CXX object 
> components/CMakeFiles/components.dir/sceneutil/lightmanager.cpp.o
> cd /«PKGBUILDDIR»/build/components && /usr/bin/c++   
> -DGLOBAL_CONFIG_PATH=\"/etc\" -DGLOBAL_DATA_PATH=\"/usr/share/games\" 
> -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB 
> -DTIXML_USE_STL -D__STDC_CONSTANT_MACROS -I/«PKGBUILDDIR»/. -isystem 
> /usr/include/SDL2 -isystem /usr/include/MYGUI -isystem /usr/include/AL 
> -isystem /usr/include/bullet -isystem /usr/include/qt4 -isystem 
> /usr/include/qt4/QtOpenGL -isystem /usr/include/qt4/QtGui -isystem 
> /usr/include/qt4/QtNetwork -isystem /usr/include/qt4/QtCore 
> -I/«PKGBUILDDIR»/build/components  -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wundef 
> -Wno-unused-parameter -std=c++98 -pedantic -Wno-long-long 
> -Wno-unused-but-set-parameter -O2 -g -DNDEBUG   -o 
> CMakeFiles/components.dir/sceneutil/lightmanager.cpp.o -c 
> /«PKGBUILDDIR»/components/sceneutil/lightmanager.cpp
> /«PKGBUILDDIR»/components/sceneutil/lightmanager.cpp: In member function 
> 'void SceneUtil::LightStateAttribute::applyLight(GLenum, const osg::Light*) 
> const':
> /«PKGBUILDDIR»/components/sceneutil/lightmanager.cpp:61:34: error: 
> 'GL_AMBIENT' was not declared in this scope
>  glLightfv( lightNum, GL_AMBIENT,   
> light->getAmbient().ptr() );
>   ^~
> /«PKGBUILDDIR»/components/sceneutil/lightmanager.cpp:61:86: error: 
> 'glLightfv' was not declared in this scope
>  glLightfv( lightNum, GL_AMBIENT,   
> light->getAmbient().ptr() );
>   
> ^
> /«PKGBUILDDIR»/components/sceneutil/lightmanager.cpp:62:34: error: 
> 'GL_DIFFUSE' was not declared in this scope
>  glLightfv( lightNum, GL_DIFFUSE,   
> light->getDiffuse().ptr() );
>   ^~
> /«PKGBUILDDIR»/components/sceneutil/lightmanager.cpp:63:34: error: 
> 'GL_SPECULAR' was not declared in this scope
>  glLightfv( lightNum, GL_SPECULAR,  
> light->getSpecular().ptr() );
>   ^~~
> /«PKGBUILDDIR»/components/sceneutil/lightmanager.cpp:64:34: error: 
> 'GL_POSITION' was not declared in this scope
>  glLightfv( lightNum, GL_POSITION,  
> light->getPosition().ptr() );
>   ^~~
> /«PKGBUILDDIR»/components/sceneutil/lightmanager.cpp:70:34: error: 
> 'GL_CONSTANT_ATTENUATION' was not declared in this scope
>  glLightf ( lightNum, GL_CONSTANT_ATTENUATION,  
> light->getConstantAttenuation() );
>   ^~~
> /«PKGBUILDDIR»/components/sceneutil/lightmanager.cpp:70:92: error: 'glLightf' 
> was not declared in this scope
>  glLightf ( lightNum, GL_CONSTANT_ATTENUATION,  
> light->getConstantAttenuation() );
>   
>   ^
> /«PKGBUILDDIR»/components/sceneutil/lightmanager.cpp:71:34: error: 

Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr

[bret curtis]

Hello everyone,

this is a follow-up email because while the bug was closed and OpenMW
compiles (and runs) on armhf, what is rendered to the screen via
OSG-3.4 is everything but pretty. The short term solution is to
disable building OpenMW on armhf and rebuild any builds still online.

I have more below inline...


On Thu, Sep 29, 2016 at 11:36 PM, Alberto Luaces  wrote:
>
> This is a list of facts that I know:
>
> - OSG "as is" does FTBFS on arm platforms.  You can verify that reading
>   the logs for 3.4: armhf (configured for GLES2) succeeds while armel
>   (default configuration) breaks.
>

That is a pity about armel, unfortunately OSG-3.4 with only GLESv2 is
useless to OpenMW, regardless of architecture. To my knowledge, OpenMW
is the only application linking against OSG-3.4 at the moment.

> - The decision of using GLES2 was already made by the Ubuntu team from
>   whom I took the patches that I told you I was going to apply
>   beforehand.  I suppose they choose GLES2 because nowadays it is rare
>   to find new hardware supporting GLES1 but not GLES2, but this is mere
>   speculation.

I do not know the reason, but I find any reason to not use standard GL
dubious regardless of architecture, specifically when it comes to
running Debian and/or Ubuntu on any platform. Not all arm[el|hf] have
the same support but GL is the baseline while GLESv[1|2] are just
subsets. Normally you would want a derivative Debian or Ubuntu to fork
to a specific target GL version.

I think it best to try to resolve the issue so that normal GL and not
ES[1|2] is used for OSG-3.4 on all platforms since Debian is trying to
be consistent across all platforms and architectures.

> - On Debian and for 3.4, which depends on Qt5, the decision of using
>   GLES2 is also taken already for us.  See their dependencies on armhf
>   and armel:
>
> https://sources.debian.net/src/qtbase-opensource-src/5.6.1%2Bdfsg-3/debian/control/#L309
>

This is just plan wrong, as I stated above we should be providing a
standard across the board. Qt5 should be using GL on armel/armhf. If
this can't be the case, then as a workaround, we should disable
building the osgQt plugin. This would allow us to build OSG-3.4 on
armhf and armel with GL instead of GLESv2.

> I do not know what would happen if we build OSG with GLES1 but linking
> to GLES2-enabled Qt5.  Does it have any chances of not breaking at
> run-time?  I am not sure.

I tried working around this with OpenMW by disabling building armhf
version of openmw-cs that makes use of osgQt. The problem is that
GLESv2 render used by OSG-3.4 cannot render OpenMW very well. It
doesn't crash which is surprising, and it renders stuff... just
nothing anyone would want to play. :)

> To me this looks like a packaging problem, because we have to decide
> what dependencies we need from a global point of view, instead of in
> a case-by-case basis.
>

It does indeed. I've tested compiling OSG-3.4 without osgQt without
the armhf patches (no GLES or EGL) and it compiled just fine. I
installed them on my RPi2 and then compiled OpenMW against it. It too
compiled without my little work-around patch. The best part is that
OpenMW runs, as expected in 1080p glory at 15fps! :)

> In my opinion, that tiny patch for OpenMW on Debian looks like a good
> compromise.

Sadly, I tested this and while it does compile and run, it just render
anything useful nor enjoyable.

> Regards,
>
> Alberto

Thanks for your comments, we really appreciate your work! :)  I hope
we can work through this!

My recommendation is if we can't get Qt-[4|5] to commit to using GL
across all platforms, that OSG-3.4 should disable building the osgQt
plugin.

Cheers,
Bret

Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr

[bret curtis]

With the attached patch to OSG, I can get it to compile on armhf with
GLESv1 (libgles1-mesa-dev). It disables GLESv2 however, I got an error
while they were both enabled.

I installed the resulting packages on my RPi2 without a problem and
got OpenMW to compile on there as well.

Was there a reason why GLESv2 as chosen over GLESv1?  Are there any
other packages that depend on OSG-3.4?  Can we use GLESv1 instead of
GLESv2? It would be even better if we can just use "Desktop OpenGL" on
armhf instead of the GLESvX.

Thoughts?

Cheers,
Bret
diff --git a/debian/control b/debian/control
index 1877a5d..ab2ba2d 100644
--- a/debian/control
+++ b/debian/control
@@ -22,6 +22,7 @@ Build-Depends: debhelper (>= 7.0.50),
freeglut3-dev [!armhf],
libgl1-mesa-dev [!armhf] | libgl-dev [!armhf],
libegl1-mesa-dev [armhf],
+   libgles1-mesa-dev [armhf],
libgles2-mesa-dev [armhf],
libxine2-dev,
libavcodec-dev,
diff --git a/debian/rules b/debian/rules
index f2113fb..408c533 100755
--- a/debian/rules
+++ b/debian/rules
@@ -66,19 +66,20 @@ LDFLAGS += -Wl,--as-needed
 
 ifeq (armhf,$(DEB_HOST_ARCH))
 EGL_LDFLAGS=$(shell pkg-config egl --libs)
-OPENGLES_LDFLAGS=$(shell pkg-config glesv2 --libs)
+OPENGLES1_LDFLAGS=$(shell pkg-config glesv1_cm --libs)
+OPENGLES2_LDFLAGS=$(shell pkg-config glesv2 --libs)
 ARMHF_DEFINES=-D OSG_GL1_AVAILABLE:BOOL=OFF \
 	-D OSG_GL2_AVAILABLE:BOOL=OFF \
 	-D OSG_GL3_AVAILABLE:BOOL=OFF \
-	-D OSG_GLES1_AVAILABLE:BOOL=OFF \
-	-D OSG_GLES2_AVAILABLE:BOOL=ON \
+	-D OSG_GLES1_AVAILABLE:BOOL=ON \
+	-D OSG_GLES2_AVAILABLE:BOOL=OFF \
 	-D OSG_GL_DISPLAYLISTS_AVAILABLE:BOOL=OFF \
 	-D OSG_GL_MATRICES_AVAILABLE:BOOL=OFF \
 	-D OSG_GL_VERTEX_FUNCS_AVAILABLE:BOOL=OFF \
 	-D OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE:BOOL=OFF \
 	-D OSG_GL_FIXED_FUNCTION_AVAILABLE:BOOL=OFF \
 	-D OSG_CPP_EXCEPTIONS_AVAILABLE:BOOL=OFF \
-	-D OPENGL_gl_LIBRARY:STRING="${OPENGLES_LDFLAGS}" \
+	-D OPENGL_gl_LIBRARY:STRING="${OPENGLES1_LDFLAGS}" \
 	-D OPENGL_egl_LIBRARY:STRING="${EGL_LDFLAGS}"
 endif
 

Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr

[bret curtis]

On Wed, Sep 28, 2016 at 9:34 AM, Alberto Luaces <alua...@udc.es> wrote:
> Andreas Beckmann writes:
>
>> On 2016-09-27 12:12, bret curtis wrote:
>>> To put it simply, upstream (OpenMW) has no plans to support GLESv2 at
>>> this time. Since OSG-3.4 for armhf is compiled only for GLESv2, this
>>> complicates things drastically and at this point I'm in over my head.
>>
>> IIRC, quite some packages have been removed from arm* over the last year
>> that require Desktop OpenGL and don't work with "just" GLES.
>> I just cannot remember (or find) concrete examples.
>> So openmw is probably another RM candidate.
>>
>
> I agree with that.  As far as I know, Desktop OpenGL is not usually
> hardware-accelerated on those SOC platforms, so having OpenMW available
> there would be a moot point.
>
> Regards,
>
> Alberto

An update:

As it turns out, OpenMW uses its own osgQt and not the one that OSG
ships. This is only required for building OpenMW-CS
(editor/construction set) which normally is not something you would
want to run on armhf (SoCs in general). We can disable this for armhf
right?

To be fair, I'm able to compile and run OpenMW on Raspberry Pi 2
(Raspbian) using Desktop OpenGL, 1080p @ ~30fps. To dismiss "Desktop
OpenGL" on armhf, for me, not a very good idea.

I managed to get OpenMW to compile on armhf using the following patch
that I asked upstream to review:
https://github.com/OpenMW/openmw/pull/1080

This patch manually pulls in #include  from
libgles1-mesa-dev. Boom, works. However Scrawl (upstream) says that
adding libgles1-mesa-dev for OSG-3.4 and allowing OSG-3.4 to build
with that flag turned on (currently only GLESv2 is turned on), that
OSG should take care of adding #include  for us that would
actually fix all our problems from the OpenMW perspective.

@Alberto and @Graham: Is it possible that you can add
libgles1-mesa-dev [armhf] to the list of packages on OSG-3.4 and set
-D OSG_GLES1_AVAILABLE:BOOL=OFF to -D OSG_GLES1_AVAILABLE:BOOL=ON
please?

Another question, in OpenMW's control file, how can get the openmw-cs
package to build on all archs except for armhf?  Does `Architecture:
any [!armhf]` work? Or do I have to list all the archs?

Cheers,
Bret

Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr

[bret curtis]

Hello,

To put it simply, upstream (OpenMW) has no plans to support GLESv2 at
this time. Since OSG-3.4 for armhf is compiled only for GLESv2, this
complicates things drastically and at this point I'm in over my head.

If we try to switch out  with , we clear up the
above error but then it fails later because GLESv2 doesn't ship with
support for other things defined in  that are required
throughout the OpenMW code base.

At this point I recommend disabling OpenMW for armhf until either
OpenMW supports GLESv2 (likely not to happen soon) or OSG-3.4 (find a
better solution[1]) supports plain old OpenGL again and not
exclusively GLESv2 on armhf.

I don't understand why we can't just use plain old OpenGL on armhf and
it seems like OSG-3.4 armhf support is a bit of a hack. I had OpenMW
running on Raspberry Pi 2 for example just last year.

Any thoughts, suggestions or other workarounds?

Cheers,
Bret

[1] 
https://anonscm.debian.org/cgit/pkg-osg/openscenegraph-3.4.git/commit/?id=fa5b1385d2b82f3fec9cc6094fb3db498a36a9e3

On Sat, Sep 24, 2016 at 11:25 PM, Andreas Beckmann  wrote:
> Package: openmw
> Version: 0.40.0-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> Hi,
>
> openmw/experimental FTBFS on armhf:
>
> https://buildd.debian.org/status/fetch.php?pkg=openmw=armhf=0.40.0-1=1474694818
>
> In file included from /usr/include/osg/GL:113:0,
>  from /usr/include/osg/GLDefines:25,
>  from /usr/include/osg/GLExtensions:18,
>  from /usr/include/osg/State:18,
>  from /usr/include/osg/GraphicsContext:17,
>  from /usr/include/osgViewer/GraphicsWindow:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GLES2/gl2.h:69:25: error: conflicting declaration 'typedef 
> khronos_ssize_t GLsizeiptr'
>  typedef khronos_ssize_t GLsizeiptr;
>  ^~
> In file included from /usr/include/GL/gl.h:2055:0,
>  from /usr/include/qt4/QtOpenGL/qgl.h:88,
>  from /usr/include/qt4/QtOpenGL/QGLWidget:1,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef 
> ptrdiff_t GLsizeiptr'
>  typedef ptrdiff_t GLsizeiptr;
>^~
> In file included from /usr/include/osg/GL:113:0,
>  from /usr/include/osg/GLDefines:25,
>  from /usr/include/osg/GLExtensions:18,
>  from /usr/include/osg/State:18,
>  from /usr/include/osg/GraphicsContext:17,
>  from /usr/include/osgViewer/GraphicsWindow:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GLES2/gl2.h:70:26: error: conflicting declaration 'typedef 
> khronos_intptr_t GLintptr'
>  typedef khronos_intptr_t GLintptr;
>   ^~~~
> In file included from /usr/include/GL/gl.h:2055:0,
>  from /usr/include/qt4/QtOpenGL/qgl.h:88,
>  from /usr/include/qt4/QtOpenGL/QGLWidget:1,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GL/glext.h:469:19: note: previous declaration as 'typedef 
> ptrdiff_t GLintptr'
>  typedef ptrdiff_t GLintptr;
>^~~~
>
>
> Andreas

Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr

[bret curtis]

We know what the problem is and are working on it.

Please see the following:
https://anonscm.debian.org/cgit/pkg-osg/openscenegraph-3.4.git/commit/?id=fa5b1385d2b82f3fec9cc6094fb3db498a36a9e3

OSG-3.4 had the same problem until this was commited, now the package
builds and OpenMW was unblocked. It too now fails and will be fixed
asap.

Cheers,
Bret

On Sat, Sep 24, 2016 at 11:25 PM, Andreas Beckmann  wrote:
> Package: openmw
> Version: 0.40.0-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> Hi,
>
> openmw/experimental FTBFS on armhf:
>
> https://buildd.debian.org/status/fetch.php?pkg=openmw=armhf=0.40.0-1=1474694818
>
> In file included from /usr/include/osg/GL:113:0,
>  from /usr/include/osg/GLDefines:25,
>  from /usr/include/osg/GLExtensions:18,
>  from /usr/include/osg/State:18,
>  from /usr/include/osg/GraphicsContext:17,
>  from /usr/include/osgViewer/GraphicsWindow:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GLES2/gl2.h:69:25: error: conflicting declaration 'typedef 
> khronos_ssize_t GLsizeiptr'
>  typedef khronos_ssize_t GLsizeiptr;
>  ^~
> In file included from /usr/include/GL/gl.h:2055:0,
>  from /usr/include/qt4/QtOpenGL/qgl.h:88,
>  from /usr/include/qt4/QtOpenGL/QGLWidget:1,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef 
> ptrdiff_t GLsizeiptr'
>  typedef ptrdiff_t GLsizeiptr;
>^~
> In file included from /usr/include/osg/GL:113:0,
>  from /usr/include/osg/GLDefines:25,
>  from /usr/include/osg/GLExtensions:18,
>  from /usr/include/osg/State:18,
>  from /usr/include/osg/GraphicsContext:17,
>  from /usr/include/osgViewer/GraphicsWindow:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GLES2/gl2.h:70:26: error: conflicting declaration 'typedef 
> khronos_intptr_t GLintptr'
>  typedef khronos_intptr_t GLintptr;
>   ^~~~
> In file included from /usr/include/GL/gl.h:2055:0,
>  from /usr/include/qt4/QtOpenGL/qgl.h:88,
>  from /usr/include/qt4/QtOpenGL/QGLWidget:1,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GL/glext.h:469:19: note: previous declaration as 'typedef 
> ptrdiff_t GLintptr'
>  typedef ptrdiff_t GLintptr;
>^~~~
>
>
> Andreas

Bug#834251: openmw: FTBFS with GCC 6

[bret curtis]

We're aware of the problem and version 0.39 has been waiting in the
upload queue for ages now awaiting someone to upload it. [1] With the
0.39 release, it no longer uses unordered maps. We're also about to
make another release (0.40) shortly... we're just short in people
willing to upload our packages. :)

Any takers?

Cheers,
Bret

[1] https://qa.debian.org/cgi-bin/vcswatch?package=openmw

On Sat, Aug 13, 2016 at 8:13 PM, Santiago Vila  wrote:
> Package: openmw
> Version: 0.38.0-1
> Severity: serious
>
> Dear maintainer:
>
> This package currently fails to build from source in stretch:
>
> -
> In file included from /usr/include/c++/6/unordered_map:35:0,
>  from
> /<>/components/files/configurationmanager.hpp:7,
>  from
> /<>/components/files/configurationmanager.cpp:1:
> /usr/include/c++/6/bits/c++0x_warning.h:32:2: error: #error This file
> requires compiler and library support for the ISO C++ 2011 standard.
> This support must be enabled with the -std=c++11 or -std=gnu++11
> compiler options.
>  #error This file requires compiler and library support \
>^
> -
>
> The full build log is attached.
>
> (Note: The build log is for "dpkg-buildpackage -A" but that's probably
> irrelevant considering the way it fails).
>
> Thanks.

Bug#756066: [libopenal1] Unable to install amd64 next to i386 library

[bret curtis]

Please do, Scott has been busy lately so I've (and OpenAL-Soft) have
been in purgatory for a few days now.

Thank you for helping out!

Cheers,
Bret

On Mon, Jul 28, 2014 at 11:20 AM, Simon McVittie s...@debian.org wrote:
 severity 756066 serious
 found 756066 openal-soft/1:1.15.1-2
 notfound 756066 openal-soft/1:1.14-5
 # fixed in pkg-games git
 tags 756066 patch pending
 thanks

 On Sat, 26 Jul 2014 at 10:48:39 +0100, Simon McVittie wrote:
 On Fri, 25 Jul 2014 at 22:21:13 +0100, Franz Schrober wrote:
  The newest upload of libopenal1 adds the dependency
  libroar-compat2. This library conflicts with itself which makes it
  impossible to use the i386 version next to the amd64 version.

 (... which makes it impossible to co-install wine:i386 with anything
 for amd64 that uses OpenAL.)

 I'm bumping this up to serious so the new OpenAL won't migrate until
 this has been resolved.

 OpenAL maintainers, please overrule me and downgrade this if you
 don't think it's release-critical (it's your decision); but I think it
 ought to be considered RC, because both Wine and OpenAL games are rather
 popular.

 My suggestion on that bug was to switch the sndio (really roaraudio)
 backend back to the way it had worked in 1.14 (it used dlopen), or to
 drop sndio support until roaraudio and its dependencies are multiarch.
 After doing either of those, the severity of #755846 can be dropped.

 Bret, I notice you normally upload this package via a sponsor, and you've
 applied the second solution (drop roaraudio support) in pkg-games git.
 I am a DD in the Games Team, and would be happy to sponsor an upload
 if your usual sponsor is unavailable - let me know.

 S

 ___
 Pkg-games-devel mailing list
 pkg-games-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-games-devel


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

Bug#755846: libroar2: no multiarch possible

[bret curtis]

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