Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 65607 - dev-libs/libtxc_dxtn ebuild for s3tc (New Package)
Summary: dev-libs/libtxc_dxtn ebuild for s3tc (New Package)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: High enhancement with 2 votes (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard: [x11-overlay]
Keywords: InOverlay
: 377399 (view as bug list)
Depends on:
Blocks: 65621
  Show dependency tree
 
Reported: 2004-09-27 17:10 UTC by Eric Shattow
Modified: 2011-08-24 17:26 UTC (History)
19 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
v1, dev-libs/libtxc_dxtn/libtxc_dxtn-0.0.1_pre040623.ebuild (libtxc_dxtn-0.0.1_pre040623.ebuild,1.51 KB, text/plain)
2004-09-27 17:11 UTC, Eric Shattow
Details
libtxc_dxtn-070518.ebuild (libtxc_dxtn-070518.ebuild,1.25 KB, text/plain)
2007-10-26 09:59 UTC, James Le Cuirot
Details
libtxc_dxtn-070518.ebuild (libtxc_dxtn-070518.ebuild,1.60 KB, text/plain)
2007-10-29 14:31 UTC, James Le Cuirot
Details
libtxc_dxtn-070518.ebuild (libtxc_dxtn-070518.ebuild,1.59 KB, text/plain)
2010-12-17 22:44 UTC, Andrei Slavoiu
Details
libtxc_dxtn-1.0.0.ebuild (libtxc_dxtn-1.0.0.ebuild,1.49 KB, text/plain)
2011-03-02 11:29 UTC, Jon Severinsson
Details
libtxc_dxtn-1.0.0.ebuild (based on x11 overlay version) (libtxc_dxtn-1.0.0.ebuild,1.45 KB, text/plain)
2011-03-03 07:04 UTC, Oldrich Jedlicka
Details
libtxc_dxtn-1.0.0-r1.ebuild (libtxc_dxtn-1.0.0-r1.ebuild,1.09 KB, text/plain)
2011-03-05 14:26 UTC, Jon Severinsson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Shattow 2004-09-27 17:10:01 UTC
optional library that enables more features of x11 DRI "S3TC" patch.
Comment 1 Eric Shattow 2004-09-27 17:11:27 UTC
Created attachment 40569 [details]
v1, dev-libs/libtxc_dxtn/libtxc_dxtn-0.0.1_pre040623.ebuild

the version "0.0.1_pre" is faked, to make it portage compatible.  marked ~x86
Comment 2 Eric Shattow 2004-09-27 23:57:10 UTC
tested working on ~x86 (athlon-xp k7).  played Neverwinter Nights and the improvement in visual quality is amazing.
Comment 3 Eric Shattow 2004-09-28 03:14:07 UTC
strictly speaking the patch does *not* depend on the installation of this lib.   for pre-compressed textures in many games it is not even necessary to use the lib, but if the lib is missing and it is needed, the texture compression routine will fail (which is the same behavior as without the patch). the lib might even have use outside of patched xorg-x11.
Comment 4 Donnie Berkholz (RETIRED) gentoo-dev 2004-09-28 09:04:28 UTC
See bug #65621 for why this is closed.
Comment 5 James Le Cuirot gentoo-dev 2007-10-24 16:09:06 UTC
The controversial Mesa patch has since been applied upstream. Does this change anything? The library is no longer maintained but the last update was relatively recent.
Comment 6 Donnie Berkholz (RETIRED) gentoo-dev 2007-10-24 16:36:06 UTC
It may be that we could add a RESTRICT=mirror ebuild, to ensure Gentoo doesn't actually distribute any of the code. Anyone else got thoughts?
Comment 7 James Le Cuirot gentoo-dev 2007-10-26 09:59:29 UTC
Created attachment 134405 [details]
libtxc_dxtn-070518.ebuild

Here's a new ebuild. I'm not sure where the 0.0.1 version number came from so I've just used the same date version as upstream does. The library shouldn't need any symlinks since "libtxc_dxtn.so" is what Mesa looks for and I've verified that it works.

Unfortunately this can't be included in the amd64 emul packages and Portage currently only allows a package to be installed using one ABI at a time so I've had to put the file in lib32 manually. At least it's only one file.
Comment 8 Donnie Berkholz (RETIRED) gentoo-dev 2007-10-28 07:51:04 UTC
Another way to deal with that is, if you're on an amd64 multilib system, compile the library twice (once for each ABI).
Comment 9 James Le Cuirot gentoo-dev 2007-10-28 10:29:30 UTC
That's what I did but Portage treats both as the same installation so when the second one finishes merging, the first one gets unmerged.
Comment 10 Donnie Berkholz (RETIRED) gentoo-dev 2007-10-29 06:47:32 UTC
That's not quite what I meant. I meant that within src_compile, you'd do something like: mkdir amd64; cd amd64; ../configure ....; make; cd ..; mkdir x86; cd x86; ../configure ... So the single installation has files for both ABIs.
Comment 11 James Le Cuirot gentoo-dev 2007-10-29 14:31:50 UTC
Created attachment 134639 [details]
libtxc_dxtn-070518.ebuild

Aha smart. I've done that now though I'm not sure if this was the right way to do it. Please correct it if necessary. I checked to make sure that you can override the ABIs used if you want to by explicitly defining DEFAULT_ABI and MULTILIB_ABIS.
Comment 12 Martin Mokrejš 2009-02-16 11:27:22 UTC
Hmm, the library is missing on my system. When I compile mesa-7.3 with debug and run glxgears I get the message that the library is missing. Configure of mesa reported that it will use the external library, so that's why it happens. Googling around tells me that the patches got applied upstream but people do hit this issue:

Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable

# find /lib -name libtxc_dxtn*
# find /usr/lib -name libtxc_dxtn*
#
Comment 13 James Le Cuirot gentoo-dev 2009-02-16 11:34:26 UTC
I'm not sure what your point is. We already know it's external, hence the need for this ebuild?
Comment 14 Martin Mokrejš 2009-02-16 11:44:35 UTC
(In reply to comment #13)
> I'm not sure what your point is. We already know it's external, hence the need
> for this ebuild?

Either this ebuild or could the library come out of the mesa source tree? Probably the preferred way as it got already included.
Comment 15 Martin Mokrejš 2009-02-21 18:50:46 UTC
(In reply to comment #12)
> Hmm, the library is missing on my system. When I compile mesa-7.3 with debug
> and run glxgears I get the message that the library is missing. Configure of

How to repeat:

# USE=debug CFLAGS="$CFLAGS -DDEBUG -DNDEBUG" emerge libdrm mesa mesa-progs
#

$ glxgears
Mesa: Mesa 7.3 DEBUG build Feb 21 2009 19:20:57
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
[cut]

$ ldd  /usr/bin/glxgears
        linux-gate.so.1 =>  (0xb7f9f000)
        libGL.so.1 => //usr//lib/opengl/xorg-x11/lib/libGL.so.1 (0xb7ee7000)
        libm.so.6 => /lib/libm.so.6 (0xb7ec0000)
        libc.so.6 => /lib/libc.so.6 (0xb7d54000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7c39000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7c2a000)
        libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7c23000)
        libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7c1f000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7c19000)
        libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7c0d000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7bf4000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7bf0000)
        /lib/ld-linux.so.2 (0xb7fa0000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7beb000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7be5000)
        librt.so.1 => /lib/librt.so.1 (0xb7bdc000)
$
Comment 16 James Le Cuirot gentoo-dev 2009-02-21 21:05:33 UTC
I've looked at the source for Mesa 7.3 and the library is definitely not included. It wouldn't be for legal reasons. When they say that "the patches were applied", they probably meant support for this external library, not the inclusion of the library itself within Mesa.
Comment 17 Andrei Slavoiu 2010-12-17 22:44:29 UTC
Created attachment 257450 [details]
libtxc_dxtn-070518.ebuild

Even if it's not going into portage I'll upload here an updated version of the ebuild. Fixes from the previous version (made by chewi):
- update HOMEPAGE and SRC_URI
- make it actualy build on my amd64 with multilib
Comment 18 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-12-18 09:02:25 UTC
Reopening, I'll see what Trustees think of it.
Comment 19 Nikoli 2011-01-01 23:16:59 UTC
Xonotic (new Nexuiz) needs this lib, please add it in portage.
Comment 20 Nikos Chantziaras 2011-01-18 19:21:48 UTC
This doesn't seem to work with Gallium3D drivers.
Comment 21 Thomas Capricelli 2011-01-18 19:36:56 UTC
no, gallium doesn't support this yet. For example:
http://www.x.org/wiki/RadeonFeature
Comment 22 Andrius Štikonas 2011-02-15 15:39:51 UTC
(In reply to comment #21)
> no, gallium doesn't support this yet. For example:
> http://www.x.org/wiki/RadeonFeature
> 

Today s3tc support (using this external library) was added to r600g driver.
Comment 23 James Le Cuirot gentoo-dev 2011-02-15 15:48:56 UTC
Yes, I was very pleased to hear it. I haven't tried it yet but I will do when the next Mesa version is out.
Comment 24 Nikos Chantziaras 2011-02-15 16:09:55 UTC
Just tried it.  Seems to work OK for the case I need it (VMWare supporting 3D inside guests.)

The steps to make it work:

* Emerge mesa-9999
* Edit your /etc/env.d/99local and insert R600_ENABLE_S3TC=1
* Make sure you're using Gallium (eselect mesa set r600 gallium)
* /etc/init.d/xdm restart

Then it works for everything.  KWin also uses S3TC now.  Not sure what it does with it though.
Comment 25 Mark 2011-02-15 18:03:44 UTC
(In reply to comment #24)
> Just tried it.  Seems to work OK for the case I need it (VMWare supporting 3D
> inside guests.)

I confirm that it is working; I tested it with two games based on the Source Engine in wine and native Unreal Tournament, using the R600 gallium driver from mesa-9999 on my amd64 with multilib. Before that, one game did not even start because it needed compressed textures and the other game had white rectangles instead of real graphics.

Is it possible to include the ebuild into portage without the ability to download the libtxc_dxtn but with support to install it if the user copies it into /usr/portage/distfiles? This would fix the legal issues, wouldn't it? Gentoo had ebuilds with fetch restriction before.
Comment 26 James Le Cuirot gentoo-dev 2011-02-15 20:23:01 UTC
That's one possibility. ACCEPT_LICENSE is probably more appropriate but the default is to allow more or less everything.
Comment 27 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-02-17 15:14:02 UTC
We've commited an ebuild for this into the x11 overlay for testing.
Comment 28 Jan Buecken 2011-02-18 08:52:54 UTC
A hint for amd64 users:
Make sure you build r600g 32 bit, too. (In my case I linked /usr/lib32/dri/r600_dri.so to the gallium lib) 
You have to do it manually.

Portage does not install the 32 bit library. Maybe one can change that similar to comment 10 here (maybe optional with a useflag "32bit"). And maybe eselect mesa can handle both, 32 bit and 64 bit lib in future?

I testet s3tc with the quake4-demo and wine (32bit) FEAR-demo and DXTViewer on my rv630 / Radeon HD Mobility 2600. Works with latest git mesa, libdrm, xf86-video-ati and the drm-radeon-testing kernel branch by Dave Airlie. You must have the overhaul comment stream checker patch in your kernel, otherwise it will not work (or you use a kernel without cs checker).

I did not test the ebuild in this bug / in the x11 overlay yet.
Comment 29 Jon Severinsson 2011-03-02 11:29:52 UTC
Created attachment 264351 [details]
libtxc_dxtn-1.0.0.ebuild

Updated ebuild for the just released version 1.0.0.

Also installs the header. While not necessary for s3tc support in mesa, it it the right thing to do...
Comment 30 Nikos Chantziaras 2011-03-02 11:50:14 UTC
Thanks.  Works fine here on ~amd64.  There are QA warnings though about the two *.so files lacking sonames.
Comment 31 Rémi Cardona (RETIRED) gentoo-dev 2011-03-02 20:31:21 UTC
(In reply to comment #30)
> There are QA warnings though about the two *.so files lacking sonames.

I've looked at the makefile and that's to be expected. Nothing to worry about.
Comment 32 Andrei Slavoiu 2011-03-02 22:05:12 UTC
(In reply to comment #29)
> Created an attachment (id=264351) [details]
> libtxc_dxtn-1.0.0.ebuild
> 
> Updated ebuild for the just released version 1.0.0.
> 
> Also installs the header. While not necessary for s3tc support in mesa, it it
> the right thing to do...
> 

I see you removed the lines "multilib_toolchain_setup ${ABI}; CC=$(tc-getCC)" from src_compile(). This causes the build to fail on amd64, I presume you only tested it on x86, right?
Comment 33 Oldrich Jedlicka 2011-03-03 07:02:57 UTC
(In reply to comment #32)
> (In reply to comment #29)
> > Created an attachment (id=264351) [details] [details]
> > libtxc_dxtn-1.0.0.ebuild
> > 
> > Updated ebuild for the just released version 1.0.0.
> > 
> > Also installs the header. While not necessary for s3tc support in mesa, it it
> > the right thing to do...
> > 
> 
> I see you removed the lines "multilib_toolchain_setup ${ABI}; CC=$(tc-getCC)"
> from src_compile(). This causes the build to fail on amd64, I presume you only
> tested it on x86, right?

Not only that, it was based on the ebuild from attachments here and not on the most recent from x11 overlay. So the license is wrongly masked as BSD too.
Comment 34 Oldrich Jedlicka 2011-03-03 07:04:41 UTC
Created attachment 264563 [details]
libtxc_dxtn-1.0.0.ebuild (based on x11 overlay version)

Try this one instead based on x11 overlay version. Tested on x86.
Comment 35 Oldrich Jedlicka 2011-03-03 07:07:05 UTC
Maybe the HOMEPAGE could be changed too, but I'm not sure which one is the "real" home for this code.
Comment 36 Nikos Chantziaras 2011-03-03 07:29:29 UTC
The author of libtxc_dxtn is Marek Olšák, so the homepage is:

http://cgit.freedesktop.org/~mareko/libtxc_dxtn
Comment 37 Nikos Chantziaras 2011-03-03 07:36:35 UTC
(In reply to comment #36)
> The author of libtxc_dxtn is Marek Olšák

Nope, I take that back.  Turns out he isn't.  I don't know why Market thought he can release a 1.0 version of something he's not the author of.  I'm confused now ...
Comment 38 James Le Cuirot gentoo-dev 2011-03-03 10:28:01 UTC
Because this is free software. ;) And because the original author, Roland Scheidegger, gave it up. It was effectively orphaned until Marek picked it up.
Comment 39 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-03-03 14:39:58 UTC
To my knowledge, the package is orphaned ATM. Marek pushed one commit to it but I don't want to attribute the package to him unless I see him stating that he is actually taking over the maintainership.
Comment 40 Mark 2011-03-05 08:33:45 UTC
The announcement is here: http://lists.freedesktop.org/archives/mesa-dev/2011-March/005712.html (he is not claiming ownership, but he has his own branch) and the source-trees can be compared here:
http://cgit.freedesktop.org/~mareko/libtxc_dxtn/
http://cgit.freedesktop.org/~cbrill/libtxc_dxtn/
The patch is included in the cbrill-tree too, so it doesn't really matter which one to use (from a user's point of view), except that the mareko tree has a tarball for this latest version, tagged 1.0.0 and the cbrill tree would need a git ebuild (which is less preferred in gentoo afaik).

cbrill is the official tree, as it is reachable from http://dri.freedesktop.org/wiki/S3TC but the page http://people.freedesktop.org/~cbrill/libtxc_dxtn/ clearly states that the code is not longer maintained, so why not use the mareko tree? It is obviously maintained and has a ready to use tarball. Plus, Marek Olšák committed 7.4% of mesa 7.9 video code, which is quite much for a single person. I would definitley use his source tree, not the dead one :-)
Comment 41 Andrew Savchenko gentoo-dev 2011-03-05 12:10:55 UTC
I don't understand why this package is fetch restricted. Possible patent issues are not the valid case here, because at least a half of media codecs may clash with some software patents in some countries and even popular gtk/qt interfaces may do so (afaik, there are US patents affecting a double click and a scrollbar). And all these packages are not fetch restricted aside from libtxc_dxtn.

The fetch restriction usually applies when a package license restricts redistribution, but the license of this library is MIT and allows redistribution, so the fetch restriction should be removed.
Comment 42 Jon Severinsson 2011-03-05 14:26:30 UTC
Created attachment 264841 [details]
libtxc_dxtn-1.0.0-r1.ebuild

(In reply to comment #32)
> This causes the build to fail on amd64, I presume you only tested it on x86,
> right?
Actually, I've only tested it on multilib amd64, and both the 32bit and 64bit binaries "works for me"™.

(In reply to comment #33)
> Not only that, it was based on the ebuild from attachments here and not on the
> most recent from x11 overlay. So the license is wrongly masked as BSD too.
Oups, I wasn't aware that the x11 overlay had an updated ebuild.
As for the license, the upstream homepage makes the same mistake ("the code itself is all BSD licensed"), so I think that mistake is excusable...

(In reply to comment #34)
> Created an attachment (id=264563) [details]
> libtxc_dxtn-1.0.0.ebuild (based on x11 overlay version)
> 
> Try this one instead based on x11 overlay version. Tested on x86.
Except that it's fetch restricted and doesn't install the header, it works fine for me on amd64 multilib.

(In reply to comment #41)
> I don't understand why this package is fetch restricted. Possible patent
> issues are not the valid case here, because at least a half of media codecs
> may clash with some software patents in some countries and even popular
> gtk/qt interfaces may do so (afaik, there are US patents affecting a double
> click and a scrollbar). And all these packages are not fetch restricted aside
> from libtxc_dxtn.
> 
> The fetch restriction usually applies when a package license restricts
> redistribution, but the license of this library is MIT and allows
> redistribution, so the fetch restriction should be removed.

While your comparison isn't the best, as there is a matter of whether the patent is known to be enforced, I do agree with your conclusion. Compare to the situation with freetype before that patent expired. The source wasn't hidden behind a RESTRICT="fetch", but compilation and binary redistribution was hidden behind USE="bindist". In light of that I think RESTRICT="bindist" makes sense, while RESTRICT="fetch" doesn't.

Attaching an updated ebuild that is based on the one by Oldrich Jedlicka, but isn't fetch restricted and installs the header .
Comment 43 Nikos Chantziaras 2011-03-05 22:04:46 UTC
The fetch restriction doesn't make any sense. With that logic, portage should fetch restrict every MP3 and H.264 player in portage as well as any JPEG image viewer.

It doesn't make sense.
Comment 44 Rémi Cardona (RETIRED) gentoo-dev 2011-03-07 20:24:58 UTC
(In reply to comment #43)
> The fetch restriction doesn't make any sense. With that logic, portage should
> fetch restrict every MP3 and H.264 player in portage as well as any JPEG image
> viewer.
> 
> It doesn't make sense.

The patents involved are very different and the licensing schemes are very different.

Committing ebuilds to the central portage tree is a responsibility, one I do not intend to take lightly.

IANAL and as far as I can tell tell, you're not one either. I'll trust whatever our trustees and/or what upstream X.org/Mesa says (they have proper counsel as well).

Thanks
Comment 45 James Le Cuirot gentoo-dev 2011-03-07 21:15:13 UTC
This debate may be about to become irrevelant as there is talk of this code being merged into Mesa and being put behind a configure flag. We shall see.
Comment 46 Rémi Cardona (RETIRED) gentoo-dev 2011-03-07 22:46:23 UTC
(In reply to comment #45)
> This debate may be about to become irrevelant as there is talk of this code
> being merged into Mesa and being put behind a configure flag. We shall see.

This is what I was referring to when I said "what upstream X.org/Mesa says".

Hopefully, we'll get some form of answer in the coming days/weeks.

Thanks
Comment 47 Christoph Brill (egore) (RESIGNED) 2011-03-07 23:42:04 UTC
I updated the "official website" at http://people.freedesktop.org/~cbrill/libtxc_dxtn/ to reffer to Marek's repository and removed my repository to stop the confusion.

Marek is the maintainer now and is even accepting patches for the library. I also took the time to create a tar.gz from the 1.0.0 tag to reduce the load of the cgit server of freedesktop.org.
Comment 48 Matt Turner gentoo-dev 2011-07-31 06:37:09 UTC
I don't see any reason to keep this out of the tree. It's in the x11 overlay, so why don't we just move it over?
Comment 49 Chí-Thanh Christopher Nguyễn gentoo-dev 2011-08-02 10:09:53 UTC
*** Bug 377399 has been marked as a duplicate of this bug. ***
Comment 50 Richard 2011-08-23 06:05:37 UTC
(In reply to comment #48)
> I don't see any reason to keep this out of the tree. It's in the x11 overlay,
> so why don't we just move it over?

It would be nice to have this in-tree.
Comment 51 Nikos Chantziaras 2011-08-23 06:17:45 UTC
And probably pulled-in as a dep by default too, since most people are not aware what S3TC is when their applications abort or lack textures.

I suppose the ebuild could listen to the global "bindist" USE flag and refuse to merge if that's set to avoid legal problems with binary packages.
Comment 52 Tomáš Chvátal (RETIRED) gentoo-dev 2011-08-23 06:47:04 UTC
Also for -bindist we can use snapshot of s2tc i have in my dev overlay, as it is not patented and should work.
Comment 53 Matt Turner gentoo-dev 2011-08-23 13:46:32 UTC
(In reply to comment #51)
> And probably pulled-in as a dep by default too, since most people are not aware
> what S3TC is when their applications abort or lack textures.
> 
> I suppose the ebuild could listen to the global "bindist" USE flag and refuse
> to merge if that's set to avoid legal problems with binary packages.

That seems like a bad idea.

> Also for -bindist we can use snapshot of s2tc i have in my dev overlay, as it
> is not patented and should work.

I'll just add both and we can let users install them.
Comment 54 Nikos Chantziaras 2011-08-23 16:29:16 UTC
(In reply to comment #53)
> (In reply to comment #51)
> > And probably pulled-in as a dep by default too, since most people are not aware
> > what S3TC is when their applications abort or lack textures.
> > 
> > I suppose the ebuild could listen to the global "bindist" USE flag and refuse
> > to merge if that's set to avoid legal problems with binary packages.
> 
> That seems like a bad idea.

Hm? Why? We can do this since we're source based and not distributing binaries.
Comment 55 Matt Turner gentoo-dev 2011-08-23 16:59:01 UTC
(In reply to comment #54)
> Hm? Why? We can do this since we're source based and not distributing binaries.

I don't think Mesa technically depends on libtxc_dxtn. It's more like a plugin.

What's wrong with having users install libtxc_dxtn if they want s3tc?
Comment 56 Richard 2011-08-23 17:24:28 UTC
Mesa has a preprocessor directive called USE_EXTERNAL_DXTN_LIB. When it is enabled, code is added to Mesa to load this library if it is available, but it is only enabled on certain processor architectures:

http://dri.freedesktop.org/wiki/S3TC

Gentoo supports multiple processor architectures and in order to do that properly, we need a way to override this setting. USE flags were made specifically for this purpose, so it makes sense to use them for this. Also, the code for loading this library is entirely dead code unless the library is present, so we should have an option to strip it from Mesa for the people that want minimalist systems.
Comment 57 Richard 2011-08-23 17:28:10 UTC
I forgot to mention that if we don't have a USE flag for this and users install it themselves, then portage won't be able to do dependency management properly and an upgrade to mesa could break X Windows if the API changes. Having a USE flag would avoid that unfortunate situation.
Comment 58 Matt Turner gentoo-dev 2011-08-23 17:35:04 UTC
(In reply to comment #56)
> Mesa has a preprocessor directive called USE_EXTERNAL_DXTN_LIB. When it is
> enabled, code is added to Mesa to load this library if it is available, but it
> is only enabled on certain processor architectures:
> 
> http://dri.freedesktop.org/wiki/S3TC
> 
> Gentoo supports multiple processor architectures and in order to do that
> properly, we need a way to override this setting. USE flags were made
> specifically for this purpose, so it makes sense to use them for this. Also,
> the code for loading this library is entirely dead code unless the library is
> present, so we should have an option to strip it from Mesa for the people that
> want minimalist systems.

Thank you. I'm familiar.

The USE_EXTERNAL_DXTN_LIB directive controls only whether src/mesa/main/texcompress_s3tc.c:_mesa_init_texture_s3tc() does anything. It controls ~40 lines of code that aren't in a common path. There's no need for a USE flag.

(In reply to comment #57)
> I forgot to mention that if we don't have a USE flag for this and users install
> it themselves, then portage won't be able to do dependency management properly
> and an upgrade to mesa could break X Windows if the API changes. Having a USE
> flag would avoid that unfortunate situation.

That's not true. Please look at the code. Mesa attempts to dlopen libtxc_dxtn. If it fails, Mesa_DXTn is left equal to GL_FALSE.
Comment 59 Richard 2011-08-23 17:47:42 UTC
Gentoo prides itself on flexibility through USE flags. Why is this so different from everything else that it cannot be consistent with the rest of the system?
Comment 60 Matt Turner gentoo-dev 2011-08-23 17:57:10 UTC
(In reply to comment #59)
> Gentoo prides itself on flexibility through USE flags.

Don't do that.

> Why is this so different
> from everything else that it cannot be consistent with the rest of the system?

You're telling me that you really want a USE flag to control whether 40 lines of code are included in the build?

This bug is now fixed, by the way. I added media-libs/libtxc_dxtn to the tree (we think media-libs makes more sense, since mesa is for instance in media-libs, and these libraries can be/are used by Wayland)
Comment 61 Richard 2011-08-23 18:00:19 UTC
(In reply to comment #60)
> You're telling me that you really want a USE flag to control whether 40 lines
> of code are included in the build?

It is needed for people using non-Intel architectures.
Comment 62 Matt Turner gentoo-dev 2011-08-23 18:04:39 UTC
(In reply to comment #61)
> (In reply to comment #60)
> > You're telling me that you really want a USE flag to control whether 40 lines
> > of code are included in the build?
> 
> It is needed for people using non-Intel architectures.

Because libtxc_dxtn doesn't have keywords for architectures other than x86 and amd64? Or, why?

And if so, adding a USE flag to control a dependence on would only actually create this problem...

I don't see anything in the Mesa code that wouldn't allow it to work on any other architecture.
Comment 63 Nikos Chantziaras 2011-08-23 18:13:49 UTC
(In reply to comment #55)
> (In reply to comment #54)
> > Hm? Why? We can do this since we're source based and not distributing binaries.
> 
> I don't think Mesa technically depends on libtxc_dxtn. It's more like a plugin.

For legal reasons only.  Everyone wants S3TC, if they don't know they want it.  It's a basic feature of the OpenGL standard.


> What's wrong with having users install libtxc_dxtn if they want s3tc?

Who's gonna tell them what S3TC is and why they need it? :-)
Comment 64 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-08-23 18:53:05 UTC
(In reply to comment #63)
> (In reply to comment #55)
> > (In reply to comment #54)
> > > Hm? Why? We can do this since we're source based and not distributing binaries.
> > 
> > I don't think Mesa technically depends on libtxc_dxtn. It's more like a plugin.
> 
> For legal reasons only.  Everyone wants S3TC, if they don't know they want it. 
> It's a basic feature of the OpenGL standard.
> 
> 
> > What's wrong with having users install libtxc_dxtn if they want s3tc?
> 
> Who's gonna tell them what S3TC is and why they need it? :-)

Just give it a conditional elog in pkg_postinst() and that will be fine.
Comment 65 Nikos Chantziaras 2011-08-23 19:07:09 UTC
(In reply to comment #64)
> (In reply to comment #63)
> > (In reply to comment #55)
> > > What's wrong with having users install libtxc_dxtn if they want s3tc?
> > 
> > Who's gonna tell them what S3TC is and why they need it? :-)
> 
> Just give it a conditional elog in pkg_postinst() and that will be fine.

Well, my point was that S3TC is an important OpenGL feature and therefore it makes more sense to have it by default rather than not.  It's like disabling JPEG support in Gtk or Qt or whatever and have an elog telling users how to enable it.

The only reason Gentoo would not install this by default is due to legal reasons.  Since I'm not a lawyer, I'll refrain from offering any kind of advice on this (since it would be useless.)  If there's no legal problem in installing by default, then it doesn't make sense no to do it.
Comment 66 Richard 2011-08-23 19:12:49 UTC
(In reply to comment #65)
> (In reply to comment #64)
> > (In reply to comment #63)
> > > (In reply to comment #55)
> > > > What's wrong with having users install libtxc_dxtn if they want s3tc?
> > > 
> > > Who's gonna tell them what S3TC is and why they need it? :-)
> > 
> > Just give it a conditional elog in pkg_postinst() and that will be fine.
> 
> Well, my point was that S3TC is an important OpenGL feature and therefore it
> makes more sense to have it by default rather than not.  It's like disabling
> JPEG support in Gtk or Qt or whatever and have an elog telling users how to
> enable it.
> 
> The only reason Gentoo would not install this by default is due to legal
> reasons.  Since I'm not a lawyer, I'll refrain from offering any kind of advice
> on this (since it would be useless.)  If there's no legal problem in installing
> by default, then it doesn't make sense no to do it.

As far as I know, legal advice to avoid properly integrating it has also not been provided by a lawyer.

In my opinion, the conditional elog would be an improvement on the current situation.
Comment 67 Matt Turner gentoo-dev 2011-08-23 19:28:13 UTC
(In reply to comment #66)
> In my opinion, the conditional elog would be an improvement on the current
> situation.

I still don't know what you meant in comment 61.
Comment 68 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-08-23 19:51:35 UTC
(In reply to comment #65)
> (In reply to comment #64)
> > (In reply to comment #63)
> > > (In reply to comment #55)
> > > > What's wrong with having users install libtxc_dxtn if they want s3tc?
> > > 
> > > Who's gonna tell them what S3TC is and why they need it? :-)
> > 
> > Just give it a conditional elog in pkg_postinst() and that will be fine.
> 
> The only reason Gentoo would not install this by default is due to legal
> reasons.  Since I'm not a lawyer, I'll refrain from offering any kind of advice
> on this (since it would be useless.)  If there's no legal problem in installing
> by default, then it doesn't make sense no to do it.

The another one is that it is optional, and we don't have a proper way of dealing with optional runtime deps (bug #373323).
Comment 69 Andrew Savchenko gentoo-dev 2011-08-24 07:48:06 UTC
(In reply to comment #60)
> This bug is now fixed, by the way. I added media-libs/libtxc_dxtn to the tree

Huh? Why it is fetch restricted? Half of the multimedia packages have unclear patent situation. bindist restriction is sufficient.
Comment 70 Andrew Savchenko gentoo-dev 2011-08-24 08:45:07 UTC
(In reply to comment #63)
> Who's gonna tell them what S3TC is and why they need it? :-)

I myself found about libxtc_dxtn only when I was wondering why OpenGL textures in the same application are so different on my netbook with i945 card and nvidia-based desktop. That was quite a pain to figure things out and I bet most of people wouldn't do this.
Comment 71 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-08-24 09:51:05 UTC
I've added a simple postinst message to mesa-9999.
Comment 72 Nikos Chantziaras 2011-08-24 17:26:25 UTC
(In reply to comment #71)
> I've added a simple postinst message to mesa-9999.

libtxc_dxtn works with all Mesa versions, not just current Git.