Matijs, > > libutahglx-dev > I'm sorry to see this go, since utah is the only way 3D acceleration > will work on my video card (ATI Mach64). The bug reports include a > patch, but it doesn't seem to have been applied. I am not a DD, but is > there something I can do? Since the utah-glx package is maintained by the QA group, I believe noone is too unhappy if someone does an NMU of the package. I can do the uploading, however I cannot do any compliation/testing ATM since I'm sitting at the server console since my Amiga went up in smoke, and the server neither has enough CPU power for compiles nor a 3D card. A short look over the bugs page tells me that there are in fact only four bugs: - config.guess/config.sub outdated. Solution: Either upgrade them once, which works for now, or add a dependency on autotools-dev and copy the files over in the clean target of debian/rules. - libutahglx-dev misses a depencency on xlibs-dev and now to the hairy part: - four texture handling requests have two different wire representations each (if I understood it correctly). Solution: hunt down the "patches" everyone has been talking about in the bug report and make sure they are applied. - The XGetProcAddressARB() function is missing from the client library. One should look around whether there is a patch for this (actually, this function is rather simple - it returns the address of a GL function by name; full spec is included in the bug reports). If you are interested in bringing this package back to life, just go ahead (there is no maintainer currently). I can (hopefully) help with many of the technical issues, but as I said, I can neither compile nor test ATM. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
Attachment:
pgpdq3VqX5AiN.pgp
Description: PGP signature