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

Re: A Round of Removals



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: pgpfAzSq0nKnF.pgp
Description: PGP signature


Reply to: