[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A Round of Removals


> >   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.


GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD  ADC6 18A0 CC8D 5706 A4B4

Attachment: pgpdq3VqX5AiN.pgp
Description: PGP signature

Reply to: