Maintaining the OpenAL and ALUT packages

Hi all, I haven't been able to get in touch with Sven Panne, who is also the maintainer of the OpenAL and alut packages. Given the conceptual similarity between OpenAL and ALUT, and the fact there is no specific Haskell audio community, would anyone object if I was to treat this list as the maintainer of those packages (or alternatively, can anyone suggest any other lists that would better serve as maintainer)? Here are my proposals for patches to OpenAL and ALUT, respectively... ============================ With recent ghc and cabal versions, the ld-flags options don't seem to do much when compiling which ghc (since ghc handles the invocation of ld, and so the flags in the package description don't make it to the linker). This causes compilation of the shared library build of OpenAL to fail for Windows platforms, since MinGW ld is fussy (by default) about there not being symbols in a shared library that are not linked to an import library. I attach a patch which instead sets extra-libraries to include the appropriate OpenAL library, which seems to fix the build. ============================ Here is a patch doing the same thing, but for ALUT; it also changes the calling convention to be ccall, which seems to be required at least for the official freealut Win32 binaries. ============================ Finally, I also propose that the maintainer be changed to hopengl@haskell.org in the package description of both packages. Any feedback, either on the maintainership of the packages, or the specific patch proposals, would be greatly appreciated. I propose that in the absence of objection within a week or so, I upload the patched packages to Hackage. Best wishes, Andrew Miller

On Wed, Sep 21, 2011 at 3:30 PM, Andrew Miller
Hi all,
I haven't been able to get in touch with Sven Panne, who is also the maintainer of the OpenAL and alut packages.
Yes, he seems to be missing.
Given the conceptual similarity between OpenAL and ALUT, and the fact there is no specific Haskell audio community, would anyone object if I was to treat this list as the maintainer of those packages (or alternatively, can anyone suggest any other lists that would better serve as maintainer)?
My only objection is that it seems weird to put something graphics related as the maintainer of something audio related. Given the history and circumstances that's an admittedly weak objection. Do you have any interest in being the maintainer of these libraries? Do you plan to actively work on them? For me, those two questions are more important. Given the lack of response to your initial inquiry, I suspect no one here is planning to actively maintain these libraries even if the maintainer field is set to this list. Have you asked around (say on Haskell-Cafe) to see if anyone with experience is interested in being the maintainer? I hope that helps, Jason

On 29/09/11 13:38, Jason Dagit wrote:
On Wed, Sep 21, 2011 at 3:30 PM, Andrew Miller
wrote: Hi all,
I haven't been able to get in touch with Sven Panne, who is also the maintainer of the OpenAL and alut packages.
Yes, he seems to be missing.
Given the conceptual similarity between OpenAL and ALUT, and the fact there is no specific Haskell audio community, would anyone object if I was to treat this list as the maintainer of those packages (or alternatively, can anyone suggest any other lists that would better serve as maintainer)?
My only objection is that it seems weird to put something graphics related as the maintainer of something audio related. Given the history and circumstances that's an admittedly weak objection.
Do you have any interest in being the maintainer of these libraries? Do you plan to actively work on them? For me, those two questions are more important. Given the lack of response to your initial inquiry, I suspect no one here is planning to actively maintain these libraries even if the maintainer field is set to this list.
Have you asked around (say on Haskell-Cafe) to see if anyone with experience is interested in being the maintainer?
Aside from asking on #haskell (on freenode) and trying this list I haven't looked that hard for a maintainer. I don't have time to guarantee I can maintain it long term. If there is no one willing to maintain it anywhere, I guess the most correct thing to do might be to upload it with no maintainer field, and if a willing maintainer comes along in the future, then they can make themselves maintainer. Best wishes, Andrew
I hope that helps, Jason
participants (2)
-
Andrew Miller
-
Jason Dagit