On Thu, Oct 31, 2002 at 02:22:33PM -0500, Lukas Geyer wrote:
> 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.
So, it turns out there are even more bugs to consider than just the ones
filed against libutahglx-dev. It seems utah-glx and libutahglx1 are not
marked for removal, so I would primarily be interested in fixing the two
(now three) bugs filed against libutahglx-dev. It seems the patch on
#145977's page is meant to fix both old bugs agains libutahglx-dev.
Incidentally, it fixes 145977 by not claiming mesa compliance anymore.
In conclusion: I will try to avoid the hairy part and just apply the
patch (carefully, of course), and see whether that leads to something
NMU'able.
And by the way: There's no need to cc me; I'm subscribed to
debian-devel.
--
Matijs van Zuijlen
... designed to fill holes or cracks of not more than two cubic vims.
-- Robert Sheckley, Untouched by Human Hands
Attachment:
pgpj7p2e54cJ4.pgp
Description: PGP signature