Bug#1068206: ITP: jolt -- A multi core friendly rigid body physics and collision detection library, written in C++, suitable for games and VR applications.

[Bret Curtis]

Package: wnpp
Severity: wishlist
Owner: Bret Curtis 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: jolt
  Version : 4.0.2
  Upstream Contact: Jorrit Rouwe 
* URL : https://github.com/jrouwe/JoltPhysics
* License : MIT
  Programming Lang: C++
  Description : A multi core friendly rigid body physics and collision 
detection library, written in C++, suitable for games and VR applications.

A multi core friendly rigid body physics and collision detection library 
suitable for games and VR applications, used by Horizon Forbidden West.

Extra Info:
This is already in use by several other project, of which is OpenMW which will 
eventually require this physics library.

Bug#1063154: mygui: NMU diff for 64-bit time_t transition

[bret curtis]

Hello Graham,

I've modified the debdiff and applied it to master in
https://salsa.debian.org/games-team/mygui/ as well. So we're ready to go
with MyGUI 3.4.3.

Cheers,
Bret

On Mon, Feb 5, 2024 at 2:33 PM Graham Inggs  wrote:

> Source: mygui
> Version: 3.4.2+dfsg-1
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> NOTICE: these changes must not be uploaded to unstable yet!
>
> Dear maintainer,
>
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> mygui as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
>
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
>
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for mygui
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
>
> Please find the patch for this NMU attached.
>
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if
> information
> becomes available that your package should not be included in the
> transition,
> there is time for us to amend the planned uploads.
>
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
> ___
> Pkg-games-devel mailing list
> pkg-games-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel
>

Bug#1016991: ITP: VulkanSceneGraph -- VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library

[bret curtis]

Hello Matt,

On Sun, Mar 10, 2024 at 11:00 PM  wrote:

> Thanks Bret for your work to package this. I've been keeping an eye on
> upstream
> and this ITP for a while.
>

I'm glad someone is! I appreciate it.


> One thing I noticed is that upstream integrated their own fork [1] of
> glslang
> directly into the build [2] as of 1.0.3 [3]. Their reasoning was that:
>

Indeed, I created an issue to track this and Robert is aware of the
situation. AnyOldName3 and myself are working together with upstream
glslang that would make it findable and work correctly via cmake so that
cmake itself would not have to carry its own vulkan and glslang files. [1]


> I believe this approach would violate Debian Policy on vendored
> dependencies,
> which are already available in glslang-dev.
>

Agreed and I've held off pushing this further until I could get
vulkanscenegraph package to build against system glslang. It's actually
much worse that that, it will try to pull in the glslang code during cmake
configuration time, which is not allowed during buildd.


> I see a few options:
>
> 1) We work with upstream to unvendor the dependency
>

We are already doing this. :) The trickle down should be happening now.  [2]


> 2) We disable the shader compiler part of vsg
>

Please no; while this would get the package into Debian faster it would be
useless for OpenMW, or specifically the Vulkan work we are doing there
which makes use of VSG's glslang.


> 3) We patch the build to depend on Debian's glslang package
>

If we can't wait for 1 to trickle down into Debian's repo; this is a way
forward. I have a branch I've been working on that would resolve that.  [3]

What are your thoughts?

Cheers,
Bret

[1] https://github.com/vsg-dev/VulkanSceneGraph/issues/1035
[2]
https://vulkan.lunarg.com/issue/home?limit=10;q=;mine=false;org=false;khronos=false;lunarg=false;indie=false;status=new,open
[3] https://github.com/psi29a/VulkanSceneGraph/pull/5

Bug#1044135: openmw: Crosshair, interactive prompts and character creation menus not visible.

[bret curtis]

Hello Simon,

not at my terminal, but the best way to fix for MyGui 3.4.2 is to edit the
debian/rules files to add this extra cmake option:
 -DCMAKE_BUILD_TYPE="RelWithDebInfo" this is what makes the build usable.

so for example:
# build for OpenGL - Release configuration
dh_auto_configure -- -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DMYGUI_BUILD_DEMOS=FALSE -DMYGUI_RENDERSYSTEM=4 \
-DMYGUI_BUILD_DOCS=TRUE -DMYGUI_BUILD_PLUGINS=FALSE \
-DMYGUI_BUILD_TOOLS=FALSE -DMYGUI_USE_SYSTEM_GLEW=TRUE

I'd fix that for all 3 plugins.

Cheers, Bret

On Mon, Aug 28, 2023 at 3:06 PM Simon McVittie  wrote:

> Control: reassign -1 src:mygui 3.4.2+dfsg-1
> Control: affects -1 + openmw
>
> On Mon, 28 Aug 2023 at 13:17:22 +0200, bret curtis wrote:
> > On Sun, Aug 13, 2023 at 5:33 PM dwimo  wrote:
> > > After starting a new game [of openmw] the crosshair and the
> interactive prompts
> > > (fe. typing in your name, clicking 'ok' or 'yes'/'no') and the menus
> > > for character creation are not visble. They do seem to respond though
> > > (fe. clicking exit in the menu and then pressing enter stops the game
> > > like expected).
> > > Otherwise it seems I can play the game normally, except from being
> unable
> > > to create a character I want (because I don't now what has been
> selected)
> >
> > the issue is with MyGUI, a known issue, resolved upstream.[1] The problem
> > is that unless a config release type is defined, it will produce a broken
> > build. So there are two fixes proposed:
> >
> > 1) rebuild MyGUI 3.4.2 but set the build to: RelWithDebugInfo
> >
> > 2) upload MyGUI 3.4.3 which I've already prepared here:
> > https://mentors.debian.net/package/mygui
> >
> > Caveat: 3.4.3 will require a patch for OpenMW 0.48 to support as there
> are
> > ABI changes. :(
> >
> > Could someone recategorize this error as being caused by MyGUI 3.4.2
> > please? [2]
>
> Reassigning to mygui as requested.
>
> If the fixed upstream release breaks ABI and will require a transition,
> then I think it would be best if someone can prepare and test a patch
> for 3.4.2 to get this fixed (either by changing the build options or
> by patching upstream source to fix the bug), and then the transition to
> 3.4.3 can be a separate change.
>
> smcv
>

Bug#1044135: openmw: Crosshair, interactive prompts and character creation menus not visible.

[bret curtis]

Hey gang,

the issue is with MyGUI, a known issue, resolved upstream.[1] The problem
is that unless a config release type is defined, it will produce a broken
build. So there are two fixes proposed:

1) rebuild MyGUI 3.4.2 but set the build to: RelWithDebugInfo

2) upload MyGUI 3.4.3 which I've already prepared here:
https://mentors.debian.net/package/mygui

Caveat: 3.4.3 will require a patch for OpenMW 0.48 to support as there are
ABI changes. :(

Could someone recategorize this error as being caused by MyGUI 3.4.2
please? [2]

Cheers,
Bret

[1] https://github.com/MyGUI/mygui/releases/tag/MyGUI3.4.3
[2] https://gitlab.com/OpenMW/openmw/-/issues/7539#note_1532004756


On Sun, Aug 13, 2023 at 5:33 PM dwimo  wrote:

> Package: openmw
> Version: 0.48.0-1+b1
> Severity: important
> X-Debbugs-Cc: dwinomor...@gmail.com
>
> Dear Maintainer,
>
> After starting a new game the crosshair and the interactive prompts
> (fe. typing in your name, clicking 'ok' or 'yes'/'no') and the menus
> for character creation are not visble. They do seem to respond though
> (fe. clicking exit in the menu and then pressing enter stops the game
> like expected).
> Otherwise it seems I can play the game normally, except from being unable
> to create a character I want (because I don't now what has been selected).
>
> extra info:
> I ran the game using the binaries on the openmw github release page and
> they
> work as expected (crosshair, interactive prompts and character creation
> menus are visible). When I build their latest dev build (git clone from
> their gitlab) though, I get the same bug as described above.
>
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.4.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages openmw depends on:
> ii  libavcodec607:6.0-5
> ii  libavformat60   7:6.0-5
> ii  libavutil58 7:6.0-5
> ii  libboost-filesystem1.74.0   1.74.0+ds1-22
> ii  libboost-iostreams1.74.01.74.0+ds1-22
> ii  libboost-program-options1.74.0  1.74.0+ds1-22
> ii  libbullet3.24   3.24+dfsg-2
> ii  libc6   2.37-7
> ii  libgcc-s1   13.2.0-2
> ii  libgl1  1.6.0-1
> ii  libicu7272.1-3
> ii  libluajit-5.1-2 2.1.0~beta3+git20220320+dfsg-4.1
> ii  liblz4-11.9.4-1
> ii  libmyguiengine3debian1v53.4.2+dfsg-1
> ii  libopenal1  1:1.23.1-3
> ii  libopenscenegraph1613.6.5+dfsg1-8+b3
> ii  libopenthreads213.6.5+dfsg1-8+b3
> ii  librecast1  1.5.1+git20210215.e75adf8-1+b1
> ii  libsdl2-2.0-0   2.28.2+dfsg-1
> ii  libsqlite3-03.42.0-1
> ii  libstdc++6  13.2.0-2
> ii  libswresample4  7:6.0-5
> ii  libswscale7 7:6.0-5
> ii  libtinyxml2.6.2v5   2.6.2-6
> ii  libyaml-cpp0.7  0.7.0+dfsg-8+b1
> ii  openmw-data 0.48.0-1
>
> Versions of packages openmw recommends:
> ii  openmw-launcher  0.48.0-1+b1
>
> openmw suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-games-devel mailing list
> pkg-games-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel
>

Bug#1036931: RFS: vulkanscenegraph/1.0.6-1 [ITP] -- 3D vulkan scene graph, shared libs

[bret curtis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "vulkanscenegraph":

* Package name : vulkanscenegraph
   Version  : 1.0.6-1
   Upstream contact : Robert Osfield 
* URL  : https://vsg-dev.github.io/VulkanSceneGraph/
* License  : MIT
* Vcs  : https://salsa.debian.org/games-team/vulkanscenegraph
   Section  : devel

The source builds the following binary packages:

  libvsg-dev - 3D vulkan scene graph, development files
  libvsg13 - 3D vulkan scene graph, shared libs

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/vulkanscenegraph/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/v/vulkanscenegraph/vulkanscenegraph_1.0.6-1.dsc


Changes for the initial release:

vulkanscenegraph (1.0.6-1) unstable; urgency=low
.
   [ Bret Curtis ]
   * Upstream release: VulkanSceneGraph-1.0.6 (Closes: #1016991)

Regards,
- --
  Bret Curtis
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.4.7
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCAAnBYJkdOzzCZDCN3t9WEy5MBYhBOvlFRLAKf4mCA8flsI3e31Y
TLkwAACZOQ//e7fG0UFUCSLi8PNkr9HskFP1pFrfeBM9/yZCeg4mUoiKoZUp
pV1bQQFrXRNMOnsp3QuNGwVI3gqkWaoUwHhIpGUgpQYWi7vj36/OKhwaE0sI
rfvxufF/9/SwEhGswEsNd6N9ll6pZai7A/dv6EN5kONuNXlnytMuuCTbGXV6
23PsBuUOZC+FpnMQ7PMd8TGmdh2OSrnZqU/yd4IdLTWMC53CvXyEL+1VcgZn
WgPFxYlv88GvEMLeH4lYLggkupyyikKn58IjivjD0jzQW+xtYhtNZH8UevV3
vE/8ZpFVUCahJI4BEYdnK710bS8k39h92PUerUA22Iab08m9CNbFp3leIm/g
VLYSzAV79G93K+hnSlQSvOwlRPL/ucjxOwHKAaP4kLnUamDEiIFbXJIhmpKz
c4NCxiul3AmFHTE07tmYhy7rH0gV0z3PfuSFMrk0f5h3YltZ2vDxHohFbqVT
bzJKW5uuM2nOMa0EvVGfa6uj++Gtib1vtHXgzFL013ARmq+qzcpsG3BCVBTV
7yu5ko/k136394DMXtLRG7hlBnAQ/gWSfdsIB+XrnC3TEJR0pM6V7ESOkLwY
PB7FMRym7ewgIhF+JlXlzznTm7R/jMr2k7rG0AQOGkqR5fUiZCPaQbTb6vAG
YrGvTDcYo0leotDTr3nloSdoW8PvQOk4ojE=
=ncs7
-END PGP SIGNATURE-

Bug#1027315: RFS: vulkanscenegraph/1.0.2-1 [ITP] -- 3D vulkan scene graph

[bret curtis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "vulkanscenegraph":

* Package name : vulkanscenegraph
   Version  : 1.0.2-1
   Upstream contact : Robert Osfield 
* URL  : https://vsg-dev.github.io/VulkanSceneGraph/
* License  : MIT
* Vcs  : https://salsa.debian.org/games-team/vulkanscenegraph
   Section  : devel

The source builds the following binary packages:

  libvsg-dev - 3D vulkan scene graph, development files
  libvsg10 - 3D vulkan scene graph, shared libs

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/vulkanscenegraph/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/v/vulkanscenegraph/vulkanscenegraph_1.0.2-1.dsc


Changes for the initial release:

vulkanscenegraph (1.0.2-1) unstable; urgency=low
.
   [ Bret Curtis ]
   * Upstream release: VulkanSceneGraph-1.0.2 (Closes: #1016991)

Regards,
- --
  Bret Curtis
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.4.0
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCAAGBQJjrrvqACEJEMI3e31YTLkwFiEE6+UVEsAp/iYIDx+Wwjd7
fVhMuTAJZA//fs9DQc3ePb8EHIjrW3N60zzYgBLkPnARNEYTN8Q5WxUw67Dh
i/IjNVMJiKVTJwi73eMig58yKhi+XTtrn7dgEPhbxafq3l+teG38MaOPcGgT
2pQsWTN4xxIUMAShvrx/bv7yB7q0DnpBePvQF7+STsp4SXmxf06XwfzdHobi
zO8fHe+xf5PTKY0g8wKPjnyLMNZcjxMi5HbTNaFAxrGQlL91buEhPTrktnAo
PVkmOBB0GyhzcN/1KKoRwYW5SCqMwPjmIW2zscTvfu67kOzR/PSdu1FqsJ7R
pT7YTariHOzw7AoQYyUqkPxKmrtMAOrixzPetzMIab4wrsh+mKVM1IjhxfRD
ZXvPh2KnPITgfAxN7r3xIIaN4bTwq7aj2/3P1sBWZPVDgPh1oshqg8D3wJuP
NWayZUntmWE/IC16OIC7rUlCZeWAd6VaPL97TOh1t2FMyzU5VuNF+RX8Zi8N
Ik9t4h6Z5gahMabAuMbcFjdPSEyPKbFLdOGeDjeBvli4txmSGp0/Gyu9Wi4d
I6rUhCgKo3se8sQdBjbvyq5ZlkT88/+Pur0Dnf6gwTFQNvzfv3xcRKbC7x5y
ISPUgthmgEfARBepHSrI7PyOn1lCCJUrDLTOd85fBvoN0wqLG+WrBbINftSo
0DniNyKapfrNdsFcSsCYeXDQMnCu345EeII=
=Z1oa
-END PGP SIGNATURE-


0xC2377B7D584CB930.asc
Description: application/pgp-keys

Bug#1016991: ITP: VulkanSceneGraph -- VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library

[bret curtis]

Thanks Berto,

I have a basic build up and I'm working through lintian issues now. Any
help or advice you can give would be greatly appreciated. :)

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

Cheers,
Bret

On Fri, Aug 12, 2022 at 1:50 AM Alberto Garcia  wrote:

> On Wed, Aug 10, 2022 at 11:21:37PM +0200, Bret Curtis wrote:
>
> > * Package name : VulkanSceneGraph
>
> Note that package names cannot have upper case letters. See the Debian
> Policy, section 5.6.1:
>
>https://www.debian.org/doc/debian-policy/ch-controlfields.html#source
>
> Berto
>

Bug#1016991: ITP: VulkanSceneGraph -- VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library

[Bret Curtis]

Package: wnpp 
Severity: wishlist
Owner: Bret Curtis  
X-Debbugs-Cc: debian-de...@lists.debian.org 

* Package name : VulkanSceneGraph 
  Version : 0.1.10 
  Upstream Author : Robert Osfield 
* URL : https://github.com/vsg-dev/VulkanSceneGraph
* License : MIT/X
  Programming Lang: C++
  Description : VulkanSceneGraph (VSG), is a modern, cross platform, high 
performance scene graph library built upon Vulkan graphics/compute API.

The project aims to bring the performance of Vulkan to the wider developer 
community by providing a modern, 
high quality software library that is easy to use and focused on making the 
development of high performance 
graphics and compute applications a productive and fun experience. Sharing the 
same lead author as the 
OpenSceneGraph, all the lessons about software quality, performance and the 
needs of application developers 
are applied to VulkanSceneGraph to provide a distillation of what a next gen 
scene graph needs to be.

Extra Info:
 - VSG will be used by OpenMW as it is a replacement for the current OSG 
library.
 - osgEarth will probably transition to vsgEarth as well.
 - Co-maintainers from OSG welcome.
 - I would maintain it and hopefully members of the games-team as well.
 - Sponsors always welcome.

Bug#1003922: recastnavigation: reproducible-builds: BuildId differences triggered by RPATH

[bret curtis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thank you for the patch, it's applied along with a changelog update.

It's awaiting review and upload from a DD. :)

Cheers,
Bret

On 2022-01-18 at 06:00, vagr...@reproducible-builds.org wrote:
> Source: recastnavigation
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> The RPATH contains the build path resulting in different buildid:
>
>
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/recastnavigation.html

>
> The attached patch to debian/rules passes
> -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
> which should use a relative path for RPATH.
>
> Alternately, updating the packaging to debhelper compat level 14 should
> fix this, although it is currently an experimental compat level.
>
> With this patch applied, recastnavigation should build reproducibly on
> tests.reproducible-builds.org!
>
> Thanks for maintaining recastnavigation!
>
> live well,
>   vagrant
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.2.1
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCAAGBQJh5n0bACEJEMI3e31YTLkwFiEE6+UVEsAp/iYIDx+Wwjd7
fVhMuTAJ8hAAjUd+DUyV26EckH60Fn5qp/93j+iuO7FOIJzCvyjFg6DYXzZy
rCQtRmZiMrYumgVYlPvw9xD9PtdxGZ7/YZzp7hfml14xubrK5QDpc5FZ8VMc
PIrHE9yfttylYQV4yztb1lZOINheyg95cHlSFdZ9KaOvzqeY2xndPLco0tXt
jVMfAIoNojmcAPVPssHSofuFqzx5QhffPRO0CsLushjv1uBagh1eayCRnJV6
doGvIw5P/JuigA9AjUD3s1V+tJYROecsQE1eqiYYHKFdn4CmVj4kOYtcEcEO
OXwxjO7FJEj1sc/UtQiuS5MK7Jk414fG99pFdrq+EkYoW1iKNJ6cizAuzfMJ
1MmaLmQWDmRtxztY7ySoQPBoWRftXvabupTEQvvJQjU3sbzE+0lyZ9z1aeFj
YFnWO0nNp+aLVvt23WEmWGPO6RlOV9CiCDKdBLhGxZT8763o1EoPaPoQvLKU
DBqgq2eElGOCPDppyV9fMSELUwR3WyByBLgXoXOOO5ij4myFwE6FlZjIYYax
5d6bMgMAqRMNa5xmaksCJM8gKzzzS/luMb9TiG7VmgmhDPNxGFMe5xxpGO9f
uaIMSio4eeMsFPEvaAZ1qMgwdLoflkDy5nH+YnEu2Z7gabjceLx5QSRQU+dy
iGxQup8LHS2PXP6lIBQk9jGPRxkHGTL9mCg=
=+Byt
-END PGP SIGNATURE-


0xC2377B7D584CB930.asc
Description: application/pgp-keys

Bug#1001620: RFS: mygui

[bret curtis]

tags -1 - moreinfo

Bug#1001620: RFS: mygui

[bret curtis]

Control: tags 1001620 moreinfo

Bug#1001620: RFS: mygui

[bret curtis]

Control: tags 1 moreinfo

Bug#1001620: RFS: mygui

[bret curtis]

Control: tags moreinfo

Hello Bastian,

Please reduce the two d/changelog entries
>
> mygui (3.4.1+dfsg-2) UNRELEASED; urgency=medium
> mygui (3.4.1+dfsg-1) experimental; urgency=medium
>
> to 3.4.1+dfsg-1. Do you want it to go to experimental or unstable?
>

Done, merged the two changelogs together and marked for unstable.



> There was one NMU which changed only d/changelog.
> Please acknowledge it by copying that entry (-2.1).
>
> Please add a "Closes: #984248" tag to the changelog.
>

Added Steven Langasek's patch and attribution in changelog


>
> Untag moreinfo when you are done.
>

I hope I untagged correctly.

Thank you!

Cheers,
Bret

Bug#1001621: RFS: OpenMW

[bret curtis]

Package: sponsorship-requests
Severity: wishlist

Hello Debian,

I've prepared the OpenMW 0.47.0 package for validation and upload. It is
lintian clean and tested with pbuilder. Further information about this
package can be accessed from the URL :
https://salsa.debian.org/games-team/openmw

Caveat: it requires librecast-dev which is still awaiting approval for
upload by FTP-Master:
https://ftp-master.debian.org/new.html

it's been put into use here.
https://launchpad.net/~openmw/+archive/ubuntu/openmw/+packages

Cheers,
Bret Curtis

Bug#1001620: RFS: mygui

[bret curtis]

Package: sponsorship-requests
Severity: wishlist

Hello Debian,

I've prepared the MyGUI 3.4.1 package for validation and upload. It is
lintian clean and tested with pbuilder. Further information about this
package can be accessed from the URL :
https://salsa.debian.org/games-team/mygui

it's been put into use here, as it is a build dependency for the upcoming
OpenMW release.
https://launchpad.net/~openmw/+archive/ubuntu/openmw/+packages

Cheers,
Bret Curtis

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#989365: Acknowledgement (RFS: recastnavigation)

[bret curtis]

Hello Bastian,

I agree to the relicense of debian/* to zlib. That is not a problem for me.
Is this enough, do you need me to do anything else?

I appreciate the time and apologize for the delay.

Would you then also help sponsor the upload of MyGUI 3.4 and OpenMW 0.47
(which uses both MyGUI 3.4 and recastnavigation) which I also have waiting?
:)

Cheers,
Bret

On Sun, Oct 31, 2021 at 6:03 PM Bastian Germann  wrote:

> On Mon, 14 Jun 2021 23:27:25 +0200 bret curtis wrote:
> > Nit picked. Everything is taken care of as well. We have a mix of: BSL-1,
> > Apache, MIT and GPL-3 :)
>
> Hi Bret,
>
> Looks good for me. I commited some changes including missing/wrong
> copyright info.
>
> I will sponsor this package if you relicense debian/* under the same
> license as upstream (Zlib).
> In the event that a patch is added that falls back to GPL-3 now which
> would make the library GPL-3
> covered. Users of the library would not expect that.
>
> Thanks,
> Bastian
>

Bug#989365: Acknowledgement (RFS: recastnavigation)

[bret curtis]

Control: tags 989365 - moreinfo

Hello Tobias,

would you be able to help sponsor recastnavigation? I believe the final
upload (#5) is the right now and according to:
https://mentors.debian.net/package/recastnavigation/
lintian is green/happy. The package is listed as needing a sponsor but so
far no takers. :(

Time is running out as openmw-0.47.0 has been tagged and it depends on
recastnavigation to build. Hopefully I've done my due-diligence here.|

As a side note, I'm also prepping openmw as well. Could I bother you with
uploading that as well or do I need to go through the same route?

Cheers,
Bret

On Mon, Jun 14, 2021 at 11:27 PM bret curtis  wrote:

> tags 989365 - moreinfo
>
>
> On Sun, Jun 13, 2021 at 10:29 AM Tobias Frost  wrote:
>
>> On Sun, Jun 13, 2021 at 12:03:26AM +0200, bret curtis wrote:
>> > > New packages (ITPs) can go to unstable; (they don't interfere with
>> the freeze)
>> >
>> > https://mentors.debian.net/package/recastnavigation/
>>
>> - the watch file seems not to work; (take a look at uscan(1) and
>>   https://wiki.debian.org/debian/watch#GitHub)
>>   You can also do some commit-based watch-file with uscan, uscan(1) says
>> how to
>>   (I doing something like that in dhewm3 and rbdoom3bfg)
>
>
> I updated this, but I couldn't test it directly because I was on a Ubuntu
> laptop and the uscan failed on version=4
> Can you validate this please?
>
> - d/control:
>>   - cmake (>= 3) | cmake3
>> - there is no cmake3 package; drop that alternative.
>> - the versioned dependency is not needed; even oldstable has cmake > 3
>>   - shouln't the library package also be named librecastnavigation?
>> (it should match the -dev package's name
>>   - you)
>>
>>
> Took care of all of this as well.
>
>
>> - d/copyright:
>>   - Can you add a debian/* section with your name to d/copyright?
>>   - I saw at least one file where the copyright years where 2010 and one
>> file
>> under PD not mentioned at all. There is also a font without source.
>> (in the Demo)
>> Please review every file and check your copyright file to make sure
>> that it
>> is complete.
>>   - (nitpick: Trailing whitespaces in d/copyright; plz remove…
>> as you likely know wrap-and-sort(1) can do that for you.
>>
>
> Nit picked. Everything is taken care of as well. We have a mix of: BSL-1,
> Apache, MIT and GPL-3 :)
>
>
>> (for the todo list -- not needed for this upload -- embedded code
>> library: fastlz)
>>   This library is intended to be copied in the source;
>>   - that copy  seems to be rather old. Maybe ask upstream to update
>> to some more recent version?
>>   - Possibly fastlz should be pacakged… A file search seems to
>> indicate that there would be other pacakges benefiting from this as
>> well.
>>   - Check for more details: https://wiki.debian.org/EmbeddedCopies
>>   - It seems only be used in the demo; if you dont use the demo in any
>> way,
>> you could Files-Exclude the demo and be done. This would also fix the
>> font
>> issue.
>>
>>
> fastlz is just for the demo and we do not currently ship the demo, so I'm
> not worried about this. Upstream is aware of this and they rather embed
> than use submodules, though I did push them to use cmake, so perhaps I can
> convince them to use cmake's fetch content instead? They are
> primarly focused on premake though. The Demo is not made here, so nothing
> to Exclude. :)
>
>
>> (can be done later too; no blocker for this upload:)
>> I see a tests folder… Would it make sense to run them in autopkgtsts?
>>
>
> This one I didn't do, but I can add this later. Is that okay?
>
>
>> please review your package and remove the moreinfo tag when ready.
>>
>
> Cool, thanks! :)
>
> Cheers,
> Bret
>

Bug#995194: libopenal1: i386 baseline violation

[bret curtis]

Hello,

On Mon, Sep 27, 2021 at 9:21 PM Nicholas Guriev  wrote:

> Package: libopenal1
> Version: 1:1.19.1-2
>
> Dear maintainer,
>
> The library is not usable on the i386 Debian platform which is in fact
> i686 with no MMX nor SSE. This is roughly corresponds to Pentium Pro
> released in late 1995 (it's even older than me ️).
>
> https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1
>
> I can see the package was build with -msse2 -mfpmath=sse compiler
> switches. Build scripts in general should not set machine dependent
> flags. Please remove them. Actually, you can utilize SSE on i386
> provided that code consults CPUID at runtime.
>

To be honest, if you're still running on hardware that is older than
yourself then I would have to pragmatically ask if you or anyone actually
runs openal-soft on that particular hardware platform. Keep in mind for
example that you can still run 32-bit on 64-bit x86 hardware, as there is a
practical use-case here.

I would venture that the usefulness of having a 32-bit build that makes use
of SSE2 far outweighs any use-case that sees the use of openal-soft on an
actual Pentium Pro.

I've had a chat with upstream and here is the response:

By default, builds for 32-bit x86 use SSE2 code generation because of
> performance issues with the x87 FPU (denormals, square roots, and
> more). This can be disabled with the ALSOFT_ENABLE_SSE2_CODEGEN=FALSE
> cmake option, which will let it use the compiler default, though it's
> not recommended.


OpenAL Soft does utilize some SSE on 32-bit x86 based on runtime
> detection, but there's also a number of places it doesn't, and making
> SSE variants with runtime selection of all the code that may matter is
> quite a daunting task with its own downsides (since it's more code,
> more maintenance, and more runtime checks or indirect calls, for
> hardware that's quite weak to begin with). So disabling SSE2 codegen
> will allow it to work for pre-SSE2 CPUs, but worsen 32-bit performance
> for SSE2-capable CPUs (x86-64 itself requires SSE2, so the option is
> ignored for 64-bit builds).


So we either use the SSE extensions, or don't even bother shipping i386
openal-soft.

Does anyone actually run or want to run openal-soft on a Pentium Pro?
Thoughts?

Cheers,
Bret

Bug#989365: Acknowledgement (RFS: recastnavigation)

[bret curtis]

Control: tags 989365 - moreinfo

I've uploaded the latest changes, as requested.
Which can be found here:
https://mentors.debian.net/package/recastnavigation/

The renaming of debian/librecast1.install to
debian/librecastnavigation1.install has lead to addition lintian warnings
that didn't previously exist however.

Please advise. :)

Cheers,
Bret

>

Bug#989365: Acknowledgement (RFS: recastnavigation)

[bret curtis]

Control: tags 989365 - moreinfo

>

Bug#989365: Acknowledgement (RFS: recastnavigation)

[bret curtis]

tags 989365 - moreinfo


On Sun, Jun 13, 2021 at 10:29 AM Tobias Frost  wrote:

> On Sun, Jun 13, 2021 at 12:03:26AM +0200, bret curtis wrote:
> > > New packages (ITPs) can go to unstable; (they don't interfere with the
> freeze)
> >
> > https://mentors.debian.net/package/recastnavigation/
>
> - the watch file seems not to work; (take a look at uscan(1) and
>   https://wiki.debian.org/debian/watch#GitHub)
>   You can also do some commit-based watch-file with uscan, uscan(1) says
> how to
>   (I doing something like that in dhewm3 and rbdoom3bfg)


I updated this, but I couldn't test it directly because I was on a Ubuntu
laptop and the uscan failed on version=4
Can you validate this please?

- d/control:
>   - cmake (>= 3) | cmake3
> - there is no cmake3 package; drop that alternative.
> - the versioned dependency is not needed; even oldstable has cmake > 3
>   - shouln't the library package also be named librecastnavigation?
> (it should match the -dev package's name
>   - you)
>
>
Took care of all of this as well.


> - d/copyright:
>   - Can you add a debian/* section with your name to d/copyright?
>   - I saw at least one file where the copyright years where 2010 and one
> file
> under PD not mentioned at all. There is also a font without source.
> (in the Demo)
> Please review every file and check your copyright file to make sure
> that it
> is complete.
>   - (nitpick: Trailing whitespaces in d/copyright; plz remove…
> as you likely know wrap-and-sort(1) can do that for you.
>

Nit picked. Everything is taken care of as well. We have a mix of: BSL-1,
Apache, MIT and GPL-3 :)


> (for the todo list -- not needed for this upload -- embedded code library:
> fastlz)
>   This library is intended to be copied in the source;
>   - that copy  seems to be rather old. Maybe ask upstream to update
> to some more recent version?
>   - Possibly fastlz should be pacakged… A file search seems to
> indicate that there would be other pacakges benefiting from this as
> well.
>   - Check for more details: https://wiki.debian.org/EmbeddedCopies
>   - It seems only be used in the demo; if you dont use the demo in any way,
> you could Files-Exclude the demo and be done. This would also fix the
> font
> issue.
>
>
fastlz is just for the demo and we do not currently ship the demo, so I'm
not worried about this. Upstream is aware of this and they rather embed
than use submodules, though I did push them to use cmake, so perhaps I can
convince them to use cmake's fetch content instead? They are
primarly focused on premake though. The Demo is not made here, so nothing
to Exclude. :)


> (can be done later too; no blocker for this upload:)
> I see a tests folder… Would it make sense to run them in autopkgtsts?
>

This one I didn't do, but I can add this later. Is that okay?


> please review your package and remove the moreinfo tag when ready.
>

Cool, thanks! :)

Cheers,
Bret

Bug#989365: Acknowledgement (RFS: recastnavigation)

[bret curtis]

> New packages (ITPs) can go to unstable; (they don't interfere with the freeze)

Great, updated. :)


> Would you mind to upload a package to mentors for easier consumption?
> (Sponsors like me are lazy and have some automation in place for mentors, but
> not for git as working from git makes them often need to guess what exactly
> wants to be sponsored)

I hope I did it right. I signed up at mentors, created .changes,
signed it and uploaded.
https://mentors.debian.net/package/recastnavigation/

Cheers,
Bret

Bug#989365: RFS: recastnavigation

[bret curtis]

Package: sponsorship-requests
Severity: wishlist

Hello Debian,

I've prepared the packaging of recastnavigation. It is lintian clean
and tested with pbuilder. Further information about this package can
be accessed from the URL :
https://salsa.debian.org/games-team/recastnavigation

it's been put into use here, as it is a build dependency for the upcoming
OpenMW release.
https://launchpad.net/~openmw/+archive/ubuntu/openmw/+packages

Please consider it for review and possible upload for 'experimental', at
least until Bullseye has been released. :)

Cheers,
Bret Curtis

Bug#913828: Fwd: Bug#913828: Acknowledgement (ITP: recastnavigation -- Navigation-mesh Toolset for Games)

[bret curtis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm currently looking for a sponsor to review/upload the recastnavigation
package I've created to resolve Bug #913828

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

Idea is to get it into experimental and once the freeze is over, to have
this in for the next release.

Is there anything else that needs to be done?

Cheers,
Bret

On 2018-11-15 at 17:39, ow...@bugs.debian.org wrote:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 913828:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913828.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   debian-de...@lists.debian.org
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  w...@debian.org
>
> If you wish to submit further information on this problem, please
> send it to 913...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 913828: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913828
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.0.2
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCAAGBQJgPpqLACEJEMI3e31YTLkwFiEE6+UVEsAp/iYIDx+Wwjd7
fVhMuTCzTA//fxzoAaj9hbU9oSFbZk2jkc3ZvimY++vOIp5sg4r6hT6pIygG
v8YGriqZGpOPLlo6QnMR2iO87Nxhdr9jSEG36W5w6Xac0bzD6nmpnzoR6ujd
n8KpMZKzoothTS3cl3CFKxqkwt9+yeE7bPz+XkOEImN2Z8io9BWJSPh3sb6a
Xc4QWOyP+BKYhpxqqHMoXjFywUp8ORQc3dpAoiMlea0n/kGBFe6PkJc2Sk5m
7NCjR1DsRyEf8vYzCrVDWurxrLLM2feA1xjJ0bUS7GPT0oZOg1x4h/Wx3sJO
XnhrcLbkJrE5R9H7qestL/M/nlCO5Gp4WF0TmQmALE95hra+NMsSCWmLpiwm
6gM5vfQOAahE50RSFhbLDSJpVR0k79azGvnyy5JEj1QBeFD7HIQnDZsLfmYB
fPR0+ORvyUwd7ALoNl6lEo1qCGtrTe1sQTHP0Tg947Rf9ieteZ1+uCjYORaC
KejrqmjMZ7eyUIGCyVngaLrBzq5eVInlF+dtnRNyuju69WFGXSSxoCh1hemy
VnRI4Gv2vfzZlcBUskGVAbAe/JnZ+yhD/3ujkk8F+mZJFVHzuHUXQKuPgaYM
Qm6f39XGUfSQolljesDwFlpufdtgIsCQ9Dsv14hKpqA/WEc3VpRe8Ag3x2OR
9FqRhj0scMEJ50ESX2er2I1vn9s6fPAC0ik=
=KE9g
-END PGP SIGNATURE-

Bug#981731: bullet: Provide a multithreaded bullet packages

[Bret Curtis]

Package: bullet
Severity: normal

Dear Maintainer,

Multhreaded bullet has been available since 2014, yet is still not packaged. 
Since bullet already ships with single and double precision packages, it 
seems not to be too much trouble to introduce a -mt version as well.

Arch already has a bullet-multithreaded package, as seen here:
https://aur.archlinux.org/pkgbase/bullet-multithreaded/

One package that would directly benefit from this would be OpenMW:   
https://tracker.debian.org/pkg/openmw
they currently make use of async physics (putting bullet into its   
own thread), but can spawn off additional threads of the bullet
library if it has been compiled with mt support.

I'm also willing to help where needed to make this happen. :)

Cheers,
Bret Curtis


-- System Information:
Debian Release: bullseye/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Bug#962874: openmw FTBFS on mipsel: undefined reference to __atomic_fetch_{add,sub}_8

[bret curtis]

Hey Adrian,


On Mon, Jun 15, 2020 at 2:57 PM Adrian Bunk  wrote:
>
> Source: openmw
> Version: 0.46.0-1
> Severity: important
> Tags: ftbfs patch
>
> https://buildd.debian.org/status/fetch.php?pkg=openmw=mipsel=0.46.0-1=1591883193=0
>
> ...
> /usr/bin/ld: ../../components/libcomponents.a(navmeshtilescache.cpp.o): in 
> function `std::__atomic_base::operator++()':
> /usr/include/c++/9/bits/atomic_base.h:319: undefined reference to 
> `__atomic_fetch_add_8'
> /usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:319: undefined reference 
> to `__atomic_fetch_add_8'
> /usr/bin/ld: ../../components/libcomponents.a(navmeshtilescache.cpp.o): in 
> function `std::__atomic_base::operator--()':
> /usr/include/c++/9/bits/atomic_base.h:327: undefined reference to 
> `__atomic_fetch_sub_8'
> /usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:327: undefined reference 
> to `__atomic_fetch_sub_8'
> collect2: error: ld returned 1 exit status
> make[3]: *** [apps/openmw/CMakeFiles/openmw.dir/build.make:4068: openmw] 
> Error 1
>
>
> The same would happen on armel, but the package is not currently
> built there for unrelated reasons.
>
> Fix/workaround:
>
> --- debian/rules.old2020-06-13 14:13:59.344764465 +
> +++ debian/rules2020-06-13 14:15:54.546736499 +
> @@ -16,6 +16,10 @@
>  # Uncomment to view all compilation commands and fix W-compiler-flags-hidden
>  export VERBOSE=1
>
> +ifneq (,$(filter $(DEB_HOST_ARCH), armel mipsel))
> +  export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
> -Wl,--as-needed
> +endif
> +
>  #CMake silently ignores CPPFLAGS. Below will properly set CFLAGS/CXXFLAGS
>  #https://wiki.debian.org/Hardening#Notes_for_packages_using_CMake
>  CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)

Thanks, but it doesn't resolve the fact that openmw wouldn't run on
armel/armhf/mipsel because those arches use GLES (Thanks Qt team)
while OpenMW doesn't support GLES. So it is effectively broken on
those platforms.

Just because it compiles doesn't mean it works. :(

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#918667: libopenal-dev on kFreeBSD: missing dependency libsndio?

[bret curtis]

Hello,

what happens if you use -lsndio when you compile? This is just out of curiosity.

Cheers,
Bret

On Tue, Jan 8, 2019 at 10:27 AM Коля Гурьев  wrote:
>
> Package: libopenal-dev
> Version: 1:1.19.1-1
> Control: affects -1 telegram-desktop
>
> I try to build a simple example[1] found on the world wide web. It
> requires libalut or libaudio. And it uses no any header or function of
> libsndio, but I get the following error.
>
> cc openal-example.o -o openal-example -lopenal -lalut
> /usr/bin/ld: warning: libsndio.so, needed by 
> /usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so, not 
> found (try using -rpath or -rpath-link)
> /usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
> undefined reference to `sio_getpar'
> /usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
> undefined reference to `sio_write'
> /usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
> undefined reference to `sio_setpar'
> /usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
> undefined reference to `sio_close'
> /usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
> undefined reference to `sio_read'
> /usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
> undefined reference to `sio_initpar'
> /usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
> undefined reference to `sio_stop'
> /usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
> undefined reference to `sio_open'
> /usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
> undefined reference to `sio_start'
> collect2: error: ld returned 1 exit status
>
> The issue affects also telegram-desktop on kfreebsd-amd64[2].
>
>  [1]: https://github.com/ffainelli/openal-example
>  [2]: 
> https://buildd.debian.org/status/fetch.php?pkg=telegram-desktop=kfreebsd-amd64=1.5.4-1=1546785287=0
>
> ___
> Pkg-games-devel mailing list
> pkg-games-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel

Bug#881333: tracking OpenGL support for specific boards

[bret curtis]

> > Many of those chipsets you list, as I understand, have a mesa driver
> > for them that support opengl and gles.
> > Such as freedreno which supports A4XX series. https://mesamatrix.net/
> >
> > Keep in mind, only the proprietary drivers seem to not support opengl
> > while the hardware is perfectly capable of doing so.
>
> Not necessarily.
> If the manufacturer specifies OpenGL ES support, then - on the hardware
> level - it is a GLES renderer and may or may not support the entire
> OpenGL specification natively. It usually requires considerable work to
> make GLES hardware support OpenGL.
> Eric Anhold can tell you all about the hard work he has put into
> bastardising his VC4 mesa driver to make up for the lack of hardware
> support:
>

When Eric jumped from Intel to Broadcom, I was there at the beginning
of his VC4 work doing testing and getting OpenMW running on the RPi.
One of our conversations revolved around why only GLES support and not
full GL support in the binary blob and his answer was that VC4 can do
both but only to a point, it depends entirely on what the hardware is
capable of. VC4 is fully capable of OpenGL 2.1 but with a few more
extensions that were GLES 2.0 specific. No bastardisation. His biggest
hurdle (still?) is dealing with the fact that the VC4 has no memory
space protection because there is no MMU. He has to use a CMA which is
_very_ slow and has had to put in a ton of work to get that working.
[1] That has nothing to do with what the GPU was capable of in terms
of GL/GLES. You can't have GLES 2.0 without first having GLES 1.1
which is backwards compatible with OpenGL 1.5 in hardware.

That is why I stated that it is the driver developer that makes the
decision as to what is exposed which is a cost/price decision of the
company pushing the hardware. If they only have to target GLES then
why expose GL? Less time to market and less money spent in
development?

Take for example the S3TC opengl extension: EXT_texture_compression_s3tc
This is not supported in hardware which is the reason, even after the
patent was expired, that Eric (or anyone) could not implement it.
Broadcom simply didn't bother (cost cutting?). So if you ever have
texture that loads in with a S3TC, all you'll see is pink (or whatever
is used as alpha).

There is no, if extension doesn't exist, we'll just emulate it in
software in VC4.

I would be seriously flabbergasted if there was a chipset out there
that supported GLES2, that on hardware, wasn't capable of at least
OpenGL 1.5. I'm talking about on hardware, not a proprietary binary
blog that only exposes GLES.

> https://github.com/anholt/mesa/wiki/VC4-OpenGL-support
>

I know, I've posted this several time in previous Qt related threads. :)

Cheers,
Bret

[1] https://dri.freedesktop.org/docs/drm/gpu/vc4.html

Bug#612509: Bug#684115: Any news on relaxing to only suggest wildmidi-config?

[bret curtis]

Hello Fabian,

We're finally ready!

Your patch is included along with a new upstream release:
https://github.com/Mindwerks/wildmidi/releases/tag/wildmidi-0.4.3

https://salsa.debian.org/psi29a-guest/WildMIDI

Cheers,
Bret
On Tue, Mar 27, 2018 at 12:27 PM Fabian Greffrath  wrote:
>
> Hi Bret,
>
> bret curtis wrote:
> > Would you be able to check and upload when ready?
>
> yes, of course. Please let me know when it is ready.
>
> Cheers,
>
>  - Fabian
>
>

Bug#881333: tracking OpenGL support for specific boards

[bret curtis]

> > https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls
> >
> > Any feedback, correction and addition that could benefit this discussion 
> > would be appreciated.
>
> Great that you collected that dataset, and put it public.
>
> What would help further would be for such information having references
> to sources, and each information point be referencable (not only the
> dataset as a whole).
>

Isn't this already done for us here?
https://gpuinfo.org/

If anything, it should be used to fill in that list.
Many of those chipsets you list, as I understand, have a mesa driver
for them that support opengl and gles.
Such as freedreno which supports Mali A4XX series. https://mesamatrix.net/

Keep in mind, only the proprietary drivers seem to not support opengl
while the hardware is perfectly capable of doing so.

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#913828: ITP: recastnavigation -- Navigation-mesh Toolset for Games

[Bret Curtis]

Package: wnpp
Severity: wishlist
Owner: Bret Curtis 

* Package name: recastnavigation
  Version : 1.5.1
  Upstream Author : Ben Hymers 
* URL : https://github.com/recastnavigation/recastnavigation
* License : Zlib
  Programming Lang: C++
  Description : Navigation-mesh Toolset for Games

Recast is state of the art navigation mesh construction toolset for games.
Recast is accompanied with Detour, a path-finding and spatial reasoning 
toolkit. 
You can use any navigation mesh with Detour, but of course the data generated 
with Recast fits perfectly.

The package is useful because it is already used in many editors such as 
Unity and Unreal Editor and as a result used in many AAA games.

It is also used in OpenMW, the open world RPG engine.

I plan on maintaining the package along with upstream developers on salsa along
with the other packages I maintain. If there are others that would like to help,
great!

I'm looking for a sponsor to help review and upload when ready.

Cheers,
Bret Curtis

Bug#910238: libopenal1: an upgrade to openal 1.19 triggers audio clicks in wine (wine-staging) applications

[bret curtis]

Hello Beren,

thanks for the update! Apparently upstream is already aware:
https://github.com/kcat/openal-soft/issues/226

there is a patch we can apply right now or if we wait a few days, they
will drop a 1.19.1 release with additional fixes.

We'll get it resolved one way or another.

Cheers,
Bret



On Wed, Oct 3, 2018 at 8:36 PM Beren Minor  wrote:
>
> Package: libopenal1
> Version: 1:1.19.0-1
> Severity: normal
>
> Dear Maintainer,
>
> I recently had an update to libopenal1 package in debian unstable, and since
> then when playing Divinity Original Sin 2 Definitive Edition with Wine, the
> siybsound has frequent clicks.
>
> I use wine-staging, from unofficial winehq so this might be an issue with 
> wine,
> but I tried several versions with lutris and they all have the same issue.
>
> Rolling back to openal 1.18.2 from debian testing solves the issue.
>
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
> 'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.18.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)
> LSM: AppArmor: enabled
>
> ___
> Pkg-games-devel mailing list
> pkg-games-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel

Bug#612509: Bug#684115: Any news on relaxing to only suggest wildmidi-config?

[bret curtis]

Hello Fabian,

thank you for the patch. I'm getting read for a new WildMIDI upstream
release and will add this alone. Multiple-birds, one stone.

Would you be able to check and upload when ready?

Cheers,
Bret


On Thu, Mar 8, 2018 at 9:48 AM, Fabian Greffrath  wrote:
> tags 612509 + patch
> tags 612509 + patch
> thanks
>
> Please find attached a working approach to fixing this.
>
>  - Fabian

Bug#852423: openscenegraph-3.4 should use libGL instead of libGLESv2 for armhf and armel

[bret curtis]

Hello!

It's been a year and still no movement on this issue.

To recap, OSG-3.4 on armhf/armel is compiled against GLESv2 and not GL
like on other archs. The reason for this is because the osgQt plugin
links against Qt that is compiled against GLESv2. This was in order to
fix compilation errors that would not exist had Qt be compiled against
GL instead.

OSG-3.4 only has one reverse dependancy: OpenMW

OpenMW doesn't support GLESv2 (and likely never will), so it can't be
shipped on armhf/armhf which is a pity because it does run just fine
on a Raspberry Pi using Stretch with a custom OSG-3.4 that is linked
to GL. [1] [2]

In addition to this, in OSG-3.6 (to be released), they've removed the
osgQt plugin anyway.

To fix this, all we need to do is remove any armhf/armel related
issues in debian/control and debian/rules and remove a build
dependency on libqt5. Then OSG-3.4 builds without osgQt, against GL
and OpenMW works again on armhf/armel. Not only in Debian, but also
Ubuntu, Raspbian and any other downstream distros based on Debian. A
huge win all around.

I've rebased my patch, including s3tc fix (which is backported from
OSG-3.6 but required for armhf/armel support of rendering s3tc
textures) and attached it to help.

Cheers,
Bret Curtis


[1] https://forum.openmw.org/viewtopic.php?f=2=5057
[2] https://www.dropbox.com/s/6r3saos1n4dhtci/openmw_debs.zip?dl=0
diff --git debian/control debian/control
index 545a8bbff..bf6fd04b1 100644
--- debian/control
+++ debian/control
@@ -21,17 +21,13 @@ Build-Depends: debhelper (>= 9),
libgdal-dev,
libx11-dev,
libxmu-dev,
-   freeglut3-dev [!armel !armhf],
-   libgl1-mesa-dev [!armel !armhf] | libgl-dev [!armel !armhf],
-   libegl1-mesa-dev [armel armhf],
-   libgles2-mesa-dev [armel armhf],
+   freeglut3-dev,
+   libgl1-mesa-dev | libgl-dev,
libxine2-dev,
libavcodec-dev,
libswscale-dev,
libavdevice-dev,
libavresample-dev,
-   qtbase5-dev,
-   libqt5opengl5-dev,
librsvg2-dev,
libpoppler-glib-dev,
liblua5.2-dev,
@@ -46,8 +42,7 @@ Architecture: any
 Section: libdevel
 Depends: ${misc:Depends},
  libopenthreads-dev,
- libgl1-mesa-dev [!armel !armhf] | libgl-dev [!armel !armhf],
- libgles2-mesa-dev [armel armhf],
+ libgl1-mesa-dev | libgl-dev,
  libglu-dev,
  libopenscenegraph-3.4-131 (= ${binary:Version})
 Suggests: openscenegraph-doc,
diff --git debian/libopenscenegraph-3.4-131.lintian-overrides debian/libopenscenegraph-3.4-131.lintian-overrides
index 70731b276..1f17e24f3 100644
--- debian/libopenscenegraph-3.4-131.lintian-overrides
+++ debian/libopenscenegraph-3.4-131.lintian-overrides
@@ -1 +1 @@
-package-name-doesnt-match-sonames libosg131 libosgAnimation131 libosgDB131 libosgFX131 libosgGA131 libosgManipulator131 libosgParticle131 libosgPresentation131 libosgQt131 libosgShadow131 libosgSim131 libosgTerrain131 libosgText131 libosgUI131 libosgUtil131 libosgViewer131 libosgVolume131 libosgWidget131
+package-name-doesnt-match-sonames libosg131 libosgAnimation131 libosgDB131 libosgFX131 libosgGA131 libosgManipulator131 libosgParticle131 libosgPresentation131 libosgShadow131 libosgSim131 libosgTerrain131 libosgText131 libosgUI131 libosgUtil131 libosgViewer131 libosgVolume131 libosgWidget131
diff --git debian/patches/s3tc.patch debian/patches/s3tc.patch
new file mode 100644
index 0..b85acafa0
--- /dev/null
+++ debian/patches/s3tc.patch
@@ -0,0 +1,602 @@
+From b6ec7bb7a4cd06ae95bda087d48c0fb7d5ca0abf Mon Sep 17 00:00:00 2001
+From: Laurens Voerman <l.voer...@rug.nl>
+Date: Thu, 12 Oct 2017 13:49:57 +0200
+Subject: [PATCH] added dxtc support in Image::getColor, enhanced
+ Image::isImageTranslucent to test opacity of dxt3 and dxt5 images
+
+cherrypick note: will allow running OpenMW on systems not supporting S3TC like Raspberry PI (if combined with a commit in OpenMW that uses the new getColor functionality)
+---
+ src/osg/Image.cpp|   8 +-
+ src/osg/dxtctool.cpp | 447 +--
+ src/osg/dxtctool.h   |  24 ++-
+ 3 files changed, 462 insertions(+), 17 deletions(-)
+
+diff --git a/src/osg/Image.cpp b/src/osg/Image.cpp
+index 4fe84746e4c..4f06d7521c6 100644
+--- a/src/osg/Image.cpp
 b/src/osg/Image.cpp
+@@ -1718,7 +1718,7 @@ bool Image::isImageTranslucent() const
+ case(GL_COMPRESSED_RGBA_S3TC_DXT1_EXT):
+ case(GL_COMPRESSED_RGBA_S3TC_DXT3_EXT):
+ case(GL_COMPRESSED_RGBA_S3TC_DXT5_EXT):
+-return dxtc_tool::CompressedImageTranslucent(_s, _t, _pixelFormat, _data);
++return dxtc_tool::isCompressedImageTranslucent(_s, _t, _pixelFormat, _data);
+ default:
+ return false;
+ }
+@@ -1918,6 +1918,12 @@ Vec4 _readColor(GLenum pixel

Bug#612509: Bug#684115: Any news on relaxing to only suggest wildmidi-config?

[bret curtis]

We've asked for people to come up with a solution that works, for 5
years and still have yet to get a response.  We then say we are going
to close the bug in one month if no one objects. That is hardly
"running around closing bugs", you're making yourself ridiculous in
saying that. Emory explained the situation, wildmidi is useless
without pats, I agree with him. If you or someone else can't come up
with a reasonable solution within another month, I'll close them agai
have another DD close it for me.

Thank you,
Bret

On Thu, Mar 8, 2018 at 8:49 AM, Fabian Greffrath  wrote:
> repoen 612509
> reopen 684115
> thanks
>
> Erm, no!
>
> Please don't run around closing Debian bugs, just because a minimal Ubuntu
> install is now available that is even smaller. The issue behind these
> reports is still not fixed. Please close bugs only when they are fixed in
> Debian.
>
> Thanks!
>
>  - Fabian
>
>

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

[bret curtis]

We've been wrestling with this for ages now, because libqt5opengl5-dev
behaves differently on arm64 than on armel, can you guarantee that
changing the dep to libqt5opengl5-desktop-dev will force to build
against opengl and not gles2?

If that is the case, then we can also begin shipping openmw-cs against
on armel. :)

Cheers,
Bret

On Thu, Jan 4, 2018 at 10:55 PM, Adrian Bunk  wrote:
> Source: openmw
> Version: 0.43.0-2
> Severity: important
>
> https://buildd.debian.org/status/package.php?p=openmw=sid
>
> ...
> /<>/components/sceneutil/lightmanager.cpp: In member function 
> 'void SceneUtil::LightStateAttribute::applyLight(GLenum, const osg::Light*) 
> const':
> /<>/components/sceneutil/lightmanager.cpp:78:34: error: 
> 'GL_AMBIENT' was not declared in this scope
>  glLightfv( lightNum, GL_AMBIENT,   
> light->getAmbient().ptr() );
>   ^~
> /<>/components/sceneutil/lightmanager.cpp:78:34: note: suggested 
> alternative: 'GL_BLEND'
>  glLightfv( lightNum, GL_AMBIENT,   
> light->getAmbient().ptr() );
>   ^~
>   GL_BLEND
> /<>/components/sceneutil/lightmanager.cpp:78:13: error: 
> 'glLightfv' was not declared in this scope
>  glLightfv( lightNum, GL_AMBIENT,   
> light->getAmbient().ptr() );
>  ^
> /<>/components/sceneutil/lightmanager.cpp:78:13: note: suggested 
> alternative: 'mLights'
>  glLightfv( lightNum, GL_AMBIENT,   
> light->getAmbient().ptr() );
>  ^
>  mLights
> ...
>
>
> Ideally it should be made working to build when Qt is using
> OpenGL ES, bug if that is not possible it would be better to
> avoid the FTBFS by changing the build dependency from
> libqt5opengl5-dev to libqt5opengl5-desktop-dev.

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#874599: openmw: Please upgrade to version 0.42.0

[bret curtis]

Gladly, it is awaiting an uploader and someone to rebuild mygui
because it has problems with gcc7 that need to be addressed.

#871299
#871235

Cheers,
Bret

On Thu, Sep 7, 2017 at 9:16 PM, Sam Protsenko  wrote:
> Package: openmw
> Version: 0.41.0-1+b1
> Severity: wishlist
>
> Dear Maintainer,
>
> Please upgrade openmw to new upstream version (0.42.0).
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (400, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.12.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:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages openmw depends on:
> ii  libavcodec5710:3.3.3-dmo3
> ii  libavformat57   10:3.3.3-dmo3
> ii  libavutil55 10:3.3.3-dmo3
> ii  libboost-filesystem1.62.0   1.62.0+dfsg-4+b1
> ii  libboost-program-options1.62.0  1.62.0+dfsg-4+b1
> ii  libboost-system1.62.0   1.62.0+dfsg-4+b1
> ii  libbullet2.86   2.86.1+dfsg-2
> ii  libc6   2.24-17
> ii  libgcc1 1:7.2.0-3
> ii  libgl1-mesa-glx [libgl1]13.0.6-1+b2
> ii  libmyguiengine3debian1v53.2.2-5
> ii  libopenal1  1:1.17.2-4+b2
> ii  libopenscenegraph-3.4-130   3.4.0+dfsg1-4+b4
> ii  libopenthreads203.2.3+dfsg1-2+b5
> ii  libqtcore4  4:4.8.7+dfsg-11
> ii  libqtgui4   4:4.8.7+dfsg-11
> ii  libsdl2-2.0-0   2.0.5+dfsg1-3
> ii  libstdc++6  7.2.0-3
> ii  libswresample2  10:3.3.3-dmo3
> ii  libswscale4 10:3.3.3-dmo3
> ii  libtinyxml2.6.2v5   2.6.2-4
> ii  openmw-data 0.41.0-1
>
> Versions of packages openmw recommends:
> ii  openmw-launcher  0.41.0-1+b1
>
> openmw suggests no packages.
>
> -- no debconf information

Bug#852423: openscenegraph-3.4 should use libGL instead of libGLESv2 for armhf and armel

[bret curtis]

Source: openscenegraph-3.4
Severity: important

Dear Maintainer,

in following up these OpenMW bugs #850021 and #838792 it is currently
impossible to run OpenMW on armhf and armel with OSG-3.4 when the later
is compiled against libGLESv2. While OpenMW will compile, it spams
stderr with warnings and results in a black screen.

The reason for this is because of OSG-3.4's osgQt library that links
links against Qt which is also compiled with libGLESv2 support on armhf
and armel.

Once you disable building osgQt by removing the Qt dependency, OSG-3.4
builds without problem on both armhf and armel. This will help resolve
bug #838792 where OSG-3.4 FTBFS on armel. OpenMW is able to be built
and run as expected on armhf and armel hardware.

I've attached a patch to help get the ball rolling here.

Thanks,
Bret Curtis

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500,
'testing'), (500, 'stable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
diff --git a/debian/control b/debian/control
index 1877a5d..8531ea6 100644
--- a/debian/control
+++ b/debian/control
@@ -19,17 +19,13 @@ Build-Depends: debhelper (>= 7.0.50),
libgdal-dev,
libx11-dev,
libxmu-dev,
-   freeglut3-dev [!armhf],
-   libgl1-mesa-dev [!armhf] | libgl-dev [!armhf],
-   libegl1-mesa-dev [armhf],
-   libgles2-mesa-dev [armhf],
+   freeglut3-dev,
+   libgl1-mesa-dev | libgl-dev,
libxine2-dev,
libavcodec-dev,
libswscale-dev,
libavdevice-dev,
libavresample-dev,
-   qtbase5-dev,
-   libqt5opengl5-dev,
librsvg2-dev,
libpoppler-glib-dev,
liblua5.2-dev,
diff --git a/debian/rules b/debian/rules
index f2113fb..92855f8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -64,24 +64,6 @@ CXXFLAGS := ${CXXFLAGS} ${ARCH_CXX_FLAGS}
 
 LDFLAGS += -Wl,--as-needed
 
-ifeq (armhf,$(DEB_HOST_ARCH))
-EGL_LDFLAGS=$(shell pkg-config egl --libs)
-OPENGLES_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_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_egl_LIBRARY:STRING="${EGL_LDFLAGS}"
-endif
-
 #
 # Shared libraries version numbers
 #
@@ -329,8 +311,6 @@ MANEXAMPLES = \
 	osgwidgettable.1 \
 	osgwidgetwindow.1 \
 	osgwindows.1 \
-	osgQtBrowser.1 \
-	osgQtWidgets.1 \
 	osganalysis.1 \
 	osganimationeasemotion.1 \
 	osganimationmorph.1 \
@@ -352,12 +332,10 @@ MANEXAMPLES = \
 	osguserstats.1 \
 	osgvertexattributes.1 \
 	osgviewerGTK.1 \
-	osgviewerQtContext.1 \
 	osgviewerSDL.1 \
 	osgvirtualprogram.1 \
 	present3D.1 \
 	osguserdata.1 \
-	osgviewerQt.1 \
 	osgviewerWX.1 \
 	osgatomiccounter.1 \
 	osgcomputeshaders.1 \
@@ -432,7 +410,7 @@ doc-stamp:
 	mkdir -p html
 	doxygen debian/Doxyfile-openscenegraph
 # Use Debian's jquery.js
-	rm html/openscenegraph/jquery.js
+	rm -f html/openscenegraph/jquery.js
 	find html -name "*.html" -print0 | xargs -0 perl -i -pe 's|src="jquery.js"|src="/usr/share/javascript/jquery/jquery.js"|'
 	touch doc-stamp
 
@@ -451,7 +429,6 @@ build-stamp:
 		-D CMAKE_BUILD_TYPE=RelWithDebInfo \
 		-D CMAKE_RELWITHDEBINFO_POSTFIX="" \
 		-D OSG_USE_LOCAL_LUA_SOURCE:BOOL=OFF \
-		${ARMHF_DEFINES} \
 		../..
 	${MAKE} ${PARALLEL_OPTIONS} VERBOSE=1 -C build/osg
 

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

[bret curtis]

Hello all,

I've attached a patch for openscenegraph-3.4 that will get it build
with libGL instead of libGLESv2 for armhf. In theory this patch should
also allow OSG-3.4 to be built on armel as well.

Cheers,
Bret


On Tue, Jan 3, 2017 at 11:25 AM, Andreas Beckmann <a...@debian.org> wrote:
> Control: reassign -1 ftp.debian.org
> Control: severity -1 normal
> Control: retitle -1 RM: openmw [armhf] -- RoQA; needs OSG built against libGL
>
> On 2017-01-03 11:15, bret curtis wrote:
>> 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.
>
> So let's remove the outdated openmw armhf binary packages until
> OSG has been "fixed".
>
>
> Andreas
diff --git a/debian/control b/debian/control
index 1877a5d..8531ea6 100644
--- a/debian/control
+++ b/debian/control
@@ -19,17 +19,13 @@ Build-Depends: debhelper (>= 7.0.50),
libgdal-dev,
libx11-dev,
libxmu-dev,
-   freeglut3-dev [!armhf],
-   libgl1-mesa-dev [!armhf] | libgl-dev [!armhf],
-   libegl1-mesa-dev [armhf],
-   libgles2-mesa-dev [armhf],
+   freeglut3-dev,
+   libgl1-mesa-dev | libgl-dev,
libxine2-dev,
libavcodec-dev,
libswscale-dev,
libavdevice-dev,
libavresample-dev,
-   qtbase5-dev,
-   libqt5opengl5-dev,
librsvg2-dev,
libpoppler-glib-dev,
liblua5.2-dev,
diff --git a/debian/rules b/debian/rules
index f2113fb..92855f8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -64,24 +64,6 @@ CXXFLAGS := ${CXXFLAGS} ${ARCH_CXX_FLAGS}
 
 LDFLAGS += -Wl,--as-needed
 
-ifeq (armhf,$(DEB_HOST_ARCH))
-EGL_LDFLAGS=$(shell pkg-config egl --libs)
-OPENGLES_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_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_egl_LIBRARY:STRING="${EGL_LDFLAGS}"
-endif
-
 #
 # Shared libraries version numbers
 #
@@ -329,8 +311,6 @@ MANEXAMPLES = \
 	osgwidgettable.1 \
 	osgwidgetwindow.1 \
 	osgwindows.1 \
-	osgQtBrowser.1 \
-	osgQtWidgets.1 \
 	osganalysis.1 \
 	osganimationeasemotion.1 \
 	osganimationmorph.1 \
@@ -352,12 +332,10 @@ MANEXAMPLES = \
 	osguserstats.1 \
 	osgvertexattributes.1 \
 	osgviewerGTK.1 \
-	osgviewerQtContext.1 \
 	osgviewerSDL.1 \
 	osgvirtualprogram.1 \
 	present3D.1 \
 	osguserdata.1 \
-	osgviewerQt.1 \
 	osgviewerWX.1 \
 	osgatomiccounter.1 \
 	osgcomputeshaders.1 \
@@ -432,7 +410,7 @@ doc-stamp:
 	mkdir -p html
 	doxygen debian/Doxyfile-openscenegraph
 # Use Debian's jquery.js
-	rm html/openscenegraph/jquery.js
+	rm -f html/openscenegraph/jquery.js
 	find html -name "*.html" -print0 | xargs -0 perl -i -pe 's|src="jquery.js"|src="/usr/share/javascript/jquery/jquery.js"|'
 	touch doc-stamp
 
@@ -451,7 +429,6 @@ build-stamp:
 		-D CMAKE_BUILD_TYPE=RelWithDebInfo \
 		-D CMAKE_RELWITHDEBINFO_POSTFIX="" \
 		-D OSG_USE_LOCAL_LUA_SOURCE:BOOL=OFF \
-		${ARMHF_DEFINES} \
 		../..
 	${MAKE} ${PARALLEL_OPTIONS} VERBOSE=1 -C build/osg
 

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#810201: openmw: diff for NMU version 0.37.0-1.1

[bret curtis]

Hello there,

we're about to upload 0.38 which already includes the change
from libpng12-dev to  libpng-dev.

Cheers,
Bret


On Thu, Jan 21, 2016 at 4:49 PM, Gianfranco Costamagna <
costamagnagianfra...@yahoo.it> wrote:

> Control: tags 810201 + patch
> Control: tags 810201 + pending
>
>
> Dear maintainer,
>
> I've prepared an NMU for openmw (versioned as 0.37.0-1.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
>
> diff -Nru openmw-0.37.0/debian/changelog openmw-0.37.0/debian/changelog
> --- openmw-0.37.0/debian/changelog  2015-12-03 00:52:31.0 +0100
> +++ openmw-0.37.0/debian/changelog  2016-01-21 16:42:14.0 +0100
> @@ -1,3 +1,11 @@
> +openmw (0.37.0-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Change libpng12-dev build-dependency to libpng-dev, to ease libpng
> +transition (Closes: #810201)
> +
> + -- Gianfranco Costamagna   Thu, 21 Jan 2016
> 16:41:36 +0100
> +
> openmw (0.37.0-1) unstable; urgency=medium
>
> [Scott Howard]
> diff -Nru openmw-0.37.0/debian/control openmw-0.37.0/debian/control
> --- openmw-0.37.0/debian/control2015-12-02 23:06:39.0 +0100
> +++ openmw-0.37.0/debian/control2016-01-21 16:42:37.0 +0100
> @@ -8,7 +8,7 @@
> libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev, libice-dev,
> libopenal-dev, libsm-dev, uuid-dev, libqt4-dev, libtinyxml-dev,
> libx11-dev, libxaw7-dev, libxrandr-dev, libxt-dev, libzzip-dev, libz-dev,
> - libpng12-dev, libavcodec-dev, libavformat-dev, libavdevice-dev,
> libavutil-dev,
> + libpng-dev, libavcodec-dev, libavformat-dev, libavdevice-dev,
> libavutil-dev,
> libswscale-dev, libpostproc-dev, libswresample-dev, libsdl2-dev,
> libmygui-dev (>= 3.2.1), libunshield-dev, libopenscenegraph-dev,
> libqt4-opengl-dev
>

Bug#812097: ITP: opl3-soundfont -- A SoundFont designed to simulate the classic MIDI sound of the Sound Blaster 16 (and other YM262 enabled hardware)

[bret curtis]

package: wnpp
Severity: wishlist
Owner: Bret Curtis <psi...@gmail.com>

*Package Name : opl3-soundfont
 Version : 1.0
 Upstream Author : Zandro Reveille <zan...@googlemail.com>
*URL :  http://zandro.freeunixhost.com/opl3/
*License : CC-BY-SA 4.0
*Description :  A SoundFont designed to simulate the classic MIDI sound of
the Sound Blaster 16 (and other YM262 enabled hardware).

This package provides a soundfont (sf2) that can be used by FluidSynth,
Timidity and WildMidi to play MIDI (and MIDI-like files) using the samples
created by the OPL3 (SB16/YM262) chip. This also allows applications like
DOSBox, ZDoom and others to play back MIDI without having to emulate the
OPL3, which can be costly in terms of CPU usage to emulate accurately.

Bug#803848: openmw: FTBFS with FFmpeg 2.9

[bret curtis]

On Thu, Nov 12, 2015 at 7:14 PM, Andreas Cadhalpun <
andreas.cadhal...@gmail.com> wrote:

> Hi Bret,
>
> On 11.11.2015 09:04, bret curtis wrote:
> > thanks for the revamped patch. I massaged it a bit to work upstream and
> tested it, it works for me on Debian and Ubuntu.
>
> Great!
>

Indeed, it looks like we'll get it in for 0.37 which should drop in a few
days as we are in the RC phase. I had to modify the patch a bit further to
handle duplicate and bad packets correctly and drop our libav compatibility
wrapper. Thank you again for pushing us in the right direction. ;)


>
> > It does however break compatibility with older ffmpegs and other distros
> which we need to support. Any way we can work around this?
>
> You could use some ifdeffery, e.g. for AV_PIX_FMT_*:
> #if LIBAVUTIL_VERSION_MAJOR > 51
>
> The library/version to use can be found in ffmpeg's APIchanges [1].
> Though, all of these changes should be compatible with any FFmpeg version
> since 2.0,
> and using older versions isn't really a good idea.
>

We made the decision to just drop libav since only Debian/Ubuntu supported
it, and since libav is now being dropped we figured now is the moment to do
the same. The only problem was our OSX builds that were still using 1.2.4
(and worked), and the packager said it wouldn't be a problem to use a
release >= 2.0.

This means that we are +20 −282 of 302 lines changed in the PR here:
https://github.com/OpenMW/openmw/pull/800

So I'll mark this bug (and others) closed when 0.37 is released.

Thanks again!

Cheers,
Bret

Bug#803848: openmw: FTBFS with FFmpeg 2.9

[bret curtis]

Hello again,

thanks for the revamped patch. I massaged it a bit to work upstream and
tested it, it works for me on Debian and Ubuntu.

https://github.com/OpenMW/openmw/pull/800

It does however break compatibility with older ffmpegs and other distros
which we need to support. Any way we can work around this?

Here is the output: https://gist.github.com/zinnschlag/e5cbdef5f95ac71975c2

The other bugs will be closed after 0.37's release because we're switching
away from Ogre and to OSG which solves a number of problems for us.This bug
will be closed on 0.37's release.

Thank you again!

Cheers,
Bret



On Tue, Nov 10, 2015 at 10:45 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> Hi Bret,
>
> On 10.11.2015 12:52, bret curtis wrote:
> > thank you for taking the time to create the patch.
> > I did test it against upstream since we are about to make a 0.37 release
> > soon and it fails. Reverting the patch solves the problem. I'm going to
> > assume that the patch is not yet ready.
>
> Thanks for testing the patch. Too bad that it doesn't work.
>
> Can you please test attached new patch?
>
> By the way, openmw doesn't start here due to #803513, which is actually
> #793641.
>
> Best regards,
> Andreas
>

Bug#803848: openmw: FTBFS with FFmpeg 2.9

[bret curtis]

Hello there,

thank you for taking the time to create the patch. I did test it against
upstream since we are about to make a 0.37 release soon and it fails.
Reverting the patch solves the problem. I'm going to assume that the patch
is not yet ready.

Here is the output:
Input #0, bink, from 'video\bethesda logo.bik':
  Duration: 00:00:16.00, start: 0.00, bitrate: 2324 kb/s
Stream #0:0[0x0]: Video: binkvideo (BIKi / 0x694B4942), yuv420p,
640x480, 30.06 fps, 30.06 tbr, 30.06 tbn, 30.06 tbc
Stream #0:1[0x0]: Audio: binkaudio_rdft, 44100 Hz, stereo, flt
[binkvideo @ 0x34a8720] DC value went out of bounds: 37839
terminate called after throwing an instance of 'std::runtime_error'
  what():  Error decoding video frame

I'll be sure to raise the issue upstream and point to the patch here as a
base to work from.

Cheers,
Bret

On Mon, Nov 2, 2015 at 10:07 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> Package: openmw
> Version: 0.36.1-1
> Severity: important
> Tags: patch
> User: pkg-multimedia-maintain...@lists.alioth.debian.org
> Usertags: ffmpeg2.9
>
> Dear Maintainer,
>
> your package fails to build with the upcoming ffmpeg 2.9.
> This bug will become release-critical at some point when the
> ffmpeg2.9 transition gets closer.
>
> Attached is a patch replacing the deprecated functionality.
> It also works with ffmpeg 2.8.
> Please apply this patch and forward it upstream, if necessary.
>
> These changes are non-trivial and should be runtime-tested.
>
> Best regards,
> Andreas
>
>

Bug#802912: nmu: openmw_0.36.1-1

[bret curtis]

On Mon, Oct 26, 2015 at 8:10 PM, Emilio Pozuelo Monfort <po...@debian.org>
wrote:

> On 26/10/15 18:30, Scott Howard wrote:
> > On Mon, Oct 26, 2015 at 5:12 AM, Emilio Pozuelo Monfort
> > <po...@debian.org> wrote:
> >> On 25/10/15 02:27, Scott Howard wrote:
> >>> Package: release.debian.org
> >>> Severity: normal
> >>> User: release.debian@packages.debian.org
> >>> Usertags: binnmu
> >>>
> >>> nmu openmw_0.36.1-1 . ANY . unstable . -m "rebuild against new
> libbullet"
> >>>
> >>> The maintainer (Bret Curtis) is busy but asked me to request this
> binNMU
> >>>
> >>> Game crashes because it was compiled against an old libbullet. More
> info:
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801914
> >>> https://forum.openmw.org/viewtopic.php?f=2=3053
> >>
> >> Sounds like you need a library transition.
> >>
> >> Emilio
> >
> > Yes, but the discussion on the libbullet transition went another way:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790988#35
>
> As you can see in that bug report, there already was a bullet transition
> for the
> GCC 5 / libstdc++6 breaks.
>
> The problem is that openmw 0.36.1-1+b2 was built against bullet
> 2.83.5+dfsg-2,
> but upgrading bullet to 2.83.6+dfsg-1 breaks openmw. That means bullet
> broke the
> ABI and needs a transition.
>
> Cheers,
> Emilio
>

As of today:
   openmw: flagged for removal in 7.6 days

is there any way to prevent it's removal and having to go through the whole
ITP again?

Is there anything being done about bullet?

Cheers,
Bret

Bug#765471: openarena: crashes randomly

[bret curtis]

On Sat, 27 Dec 2014 08:40:01 -0500 Scott Bennett sbennet...@gmail.com
wrote:


 In looking at the backtrace, I also noticed that most of the traces
seemed to
 have something to do with PulseAudio.  One thing I tried was turning off
 OpenAL, and since I've done that I have not been able to reproduce the
problem
 in over an hour of playing... it never took longer than five minutes
before.


We have a new release in experimental, 0.16.0, which fixes quite a few bugs
such as the SSE issue. See the release information here.
https://packages.qa.debian.org/o/openal-soft/news/20150209T000506Z.html

Please test to see if openarena still crashes.

Cheers,
Bret

Bug#776780: on usage, libopenal leads to crash when compiled with SSE

[bret curtis]

In 1.16, there is a new way for handling SSE (and other bits). Can you give
this a spin yourself to see if it fixes the problem?

1.16 is ready to be uploaded, at least to experimental since we are in the
middle of a package freeze for Jessie.
https://qa.debian.org/developer.php?login=psi...@gmail.com
^-- Check VCS

Cheers,
Bret



On Sun, Feb 1, 2015 at 5:44 PM, e est mtes...@yandex.com wrote:

 Package: libopenal1
 Version: 1:1.15.1-5

 When I'm enabling sound with Minetest, a game that uses libopenal,
 minetest crashes. I've found out that when I compile libopenal with
 disabled SSE support, the crash isn't reproducible anymore.
 Could you disable SSE support until upstream has fixed SSE support? Thank
 you.

 This crash somehow doesn't create a nice backtrace with gdb, therefore i
 recommend to use valgrind.

 See more (stacktraces, etc.) in the corresponding launchpad bug:

 https://bugs.launchpad.net/ubuntu/+source/openal-soft/+bug/1416042

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

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-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#680742: Request: Reactivation of RoarAudio support in openal-soft

[bret curtis]

Status report:

We're currently on OpenAL-Soft 1.14, libroar doesn't look to be
dropped as it is still in sid and is going into Jessie.

The libroar (libsndio is a virtual package to libroar) package is
marked as 'suggested' by OpenAL-Soft but still required for building.
It hasn't gone anywhere, so if you install it yourself, it should
still be usable by OpenAL-Soft.

At this point, unless anyone objects or gives a better recommendation
in 2 weeks (as of today), I'll close this bug.

Cheers,
Bret


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

Bug#751686: ping

[bret curtis]

I would love to, but I'm still waiting for a sponsor to upload my
wonderful 0.30.0 package.  It nearly time for 0.31.0! :)

Cheers,
Bret

On Thu, Jul 10, 2014 at 12:14 PM, Sven Bartscher
sven.bartsc...@weltraumschlangen.de wrote:
 I just wanted to make sure that you notice that both blocking bugs were
 solved two weeks ago and ogre transitioned to boost-1.55.
 Are you still at this?

 If you need help with this you can contact me and I can look what I can
 do.

 Regards
 Sven


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

Bug#735277: wildmidi: Forked repo, a new release and an offer to help maintain the wildmidi package

[Bret Curtis]

Package: wildmidi
Version: 0.2.3.4-2.1
Severity: wishlist
Tags: upstream

Dear Maintainer,

In February 2012, Chris Ison, made a 0.2.3.5 release and the wildmidi package
in Debian is still at 0.2.3.4 with a few bugs still unresolved and patches.

The 0.2.3.5 release was the last release by Chris, he had just a few more
commits in February and is stopped. His responses stop on Sourceforge, his
commits, his twitter feed. All attempts to contact him have also failed. The
queue of bugs and patches have been piling up as well.

In attempt to fix bugs for myself, I decided to fork his SVN repo and have
created a github repo with his commit history still intact here:
https://github.com/psi29a/wildmidi

Since then, there have been a number of contributors and patches have been
poring in. We've gutted the autotools and replaced it with a cmake system.
We're now able to cleanly, without warnings, build against latest GCC and Clang
on Debian and Ubuntu. We even managed to get wildmidi to compile with Visual
Studio 2010 and run. We're currently working on getting to running again on
OSX.

We're still ABI/API compatible, none of the symbols/exports have changed. You
can drop this in and link against it without any code changes in other
projects.

We've also kept the door open for Chris' return and can give the git repo to
him, or can join or stay where he is and just pull in our changes.

That being said, we propose a switch from old upstream to the new upstream.

I also would like to help with the package's maintenance in Debian.

What can I do here to help. :)

Cheers,
Bret Curtis


-- System Information:
Debian Release: wheezy/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11.0-14-generic (SMP w/8 CPU cores)


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

Bug#711658: wildmidi: Wildmidi segfaults when running with reverb (-b option)

[bret curtis]

Hello,

I've tested both of the midi files provided with -b (reverb) on
wildmidi version 0.2.3.5.

Just to be clear, this version is from February 2012, so it could use
a bump on Debian. Sadly this is the last release by the current
author.

I currently maintain a fork with additional patches here:
github: https://github.com/psi29a/wildmidi
travis-ci: https://travis-ci.org/psi29a/wildmidi

Cheers,
Bret


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

Bug#727194: ITP: OpenMW -- Reimplementation of The Elder Scrolls III: Morrowind game engine

[Bret Curtis]

Package: wnpp
Severity: wishlist
Owner: Bret Curtis psi...@gmail.com

* Package name: OpenMW
  Version : 0.26.0
  Upstream Author : Marc Zinnschlag m...@zpages.de
* URL : http://www.openmw.org/
* License : GPLv3
  Programming Lang: C++
  Description : Reimplementation of The Elder Scrolls III: Morrowind game 
engine

 OpenMW is a reimplementation of the Bethesda Game Studios game 
 The Elder Scrolls III: Morrowind.
 .
 The Morrowind Data Files from the original game are required to play.


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

Bug#727195: ITP: OpenMW -- Reimplementation of The Elder Scrolls III: Morrowind

[Bret Curtis]

Package: wnpp
Severity: wishlist
Owner: Bret Curtis psi...@gmail.com

* Package name: OpenMW
  Version : 0.26.0
  Upstream Author : Marc Zinnschlag m...@zpages.de
* URL : http://www.openmw.org/
* License : GPLv3
  Programming Lang: C++
  Description : Reimplementation of The Elder Scrolls III: Morrowind

 Reimplementation of The Elder Scrolls III: Morrowind
 OpenMW is a reimplementation of the Bethesda Game Studios game 
 The Elder Scrolls III: Morrowind.
 .
 The Morrowind Data Files from the original game are required to play.


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