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

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.


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: