Re: A Round of Removals
Simon Richter <sjr@debian.org> writes:
> 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).
The API issue is even more hairy. The header of libutahglx-dev claims
to be MESA compliant, version >= 3.2. However, it does not provide
/usr/include/GL/osmesa.h which is in MESA since 1.2.4 if I can believe
the MESA docs. The source package of libutahglx-dev contains that MESA
code but it is not built. I am not interested in this package, but if
someone takes it over, _please_ check that the package really provides
what it claims to. Otherwise it will cause FTBFS and thus
release-critical bugs on other packages, like #142129.
Lukas
P.S.: I will go ahead and file that bug now, hadn't done yet because I
thought it would be gone in short time anyway.
Reply to: