Bug#1068206: ITP: jolt -- A multi core friendly rigid body physics and collision detection library, written in C++, suitable for games and VR applications.
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
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
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.
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.
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
-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
-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
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
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
-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
tags -1 - moreinfo
Bug#1001620: RFS: mygui
Control: tags 1001620 moreinfo
Bug#1001620: RFS: mygui
Control: tags 1 moreinfo
Bug#1001620: RFS: mygui
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
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
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
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)
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)
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
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)
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)
Control: tags 989365 - moreinfo >
Bug#989365: Acknowledgement (RFS: recastnavigation)
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)
> 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
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)
-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
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
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&arch=mipsel&ver=0.46.0-1&stamp=1591883193&raw=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
-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&arch=mipsel&ver=0.46.0-1&stamp=1591883193&raw=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
-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
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
-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
-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
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
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?
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&arch=kfreebsd-amd64&ver=1.5.4-1&stamp=1546785287&raw=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
> > 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?
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
> > 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
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
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
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?
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
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&t=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 +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
Bug#612509: Bug#684115: Any news on relaxing to only suggest wildmidi-config?
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
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&suite=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
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 wrote: > On Thu, 28 Dec 2017 12:47:01 +0100 bret curtis 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
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
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
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
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
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 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
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&arch=armhf&ver=0.41.0-1&stamp=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
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
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
On Wed, Sep 28, 2016 at 9:34 AM, Alberto Luaces 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
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&arch=armhf&ver=0.40.0-1&stamp=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
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&arch=armhf&ver=0.40.0-1&stamp=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
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
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)
package: wnpp Severity: wishlist Owner: Bret Curtis *Package Name : opl3-soundfont Version : 1.0 Upstream Author : Zandro Reveille *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
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
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
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
On Mon, Oct 26, 2015 at 8:10 PM, Emilio Pozuelo Monfort wrote: > On 26/10/15 18:30, Scott Howard wrote: > > On Mon, Oct 26, 2015 at 5:12 AM, Emilio Pozuelo Monfort > > 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&t=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
On Sat, 27 Dec 2014 08:40:01 -0500 Scott Bennett 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
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 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
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 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
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 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
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
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 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
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)
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
Package: wnpp Severity: wishlist Owner: Bret Curtis * Package name: OpenMW Version : 0.26.0 Upstream Author : Marc Zinnschlag * 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
Package: wnpp Severity: wishlist Owner: Bret Curtis * Package name: OpenMW Version : 0.26.0 Upstream Author : Marc Zinnschlag * 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