1 |
"Daiajo Tibdixious" <daiajo@×××××.com> posted |
2 |
a4a9bfcb0702010239k27520bf1ve6a54a3e235f580d@××××××××××.com, excerpted |
3 |
below, on Thu, 01 Feb 2007 21:39:08 +1100: |
4 |
|
5 |
>> If you aren't using the 3D stuff on your video card anyway, you may wish |
6 |
>> to see if the native xorg driver will run it. |
7 |
> |
8 |
> What do I have to do to run it? |
9 |
|
10 |
The first step is to see for sure what the status is with your video card. |
11 |
You mentioned ATI, but didn't mention what, tho I did get the impression |
12 |
it wasn't one of the latest generation cards, which AFAIK isn't supported |
13 |
at all yet, by the native xorg drivers. |
14 |
|
15 |
FWIW, here's an abridged list from the radeon manpage (from the native |
16 |
driver, which I run, version 6.6.3 here, on a 9200se/rv280, if your |
17 |
card is a radeon below radeon 9250, it'll work too, in 3D even, but I cut |
18 |
that out): |
19 |
|
20 |
RS400 Radeon XPRESS 200/200M IGP |
21 |
|
22 |
R300 Radeon 9700PRO/9700/9500PRO/9500/9600TX, FireGL X1/Z1 (2D only) |
23 |
|
24 |
R350 Radeon 9800PRO/9800SE/9800, FireGL X2 (2D only) |
25 |
|
26 |
R360 Radeon 9800XT (2d only) |
27 |
|
28 |
RV350 Radeon 9600PRO/9600SE/9600, M10/M11, FireGL T2 (2D only) |
29 |
|
30 |
RV360 Radeon 9600XT (2d only) |
31 |
|
32 |
RV370 Radeon X300, M22 (2d only) |
33 |
|
34 |
RV380 Radeon X600, M24 (2d only) |
35 |
|
36 |
RV410 Radeon X700, M26 PCIE (2d only) |
37 |
|
38 |
R420 Radeon X800 AGP (2d only) |
39 |
|
40 |
R423/R430 Radeon X800, M28 PCIE (2d only) |
41 |
|
42 |
R480/R481 Radeon X850 PCIE/AGP (2d only) |
43 |
|
44 |
There is experimental 3D support for some of that, I think thru the rv3xx |
45 |
series, so anything below the x700, m26 pcie, but I'm not positive of |
46 |
where the cutoff is or the exact status, and it's still fairly new so if |
47 |
you /do/ want 3D support on it, you'd want to run ~arch xorg, |
48 |
xf86-video-ati (that's the video package you'd want for native ATI incl. |
49 |
Radeon), and related packages (the rest of the drivers, extensions, |
50 |
protocols, etc, that make up modular-x). |
51 |
|
52 |
To get the driver, simply set VIDEO_CARDS="radeon" in your |
53 |
make.conf, and remerge xorg-server and mesa. They should pull in the new |
54 |
driver. |
55 |
|
56 |
If you want 3D (and the driver has support for it), you'll also need to |
57 |
ensure the proper kernel drivers are enabled and rebuild it. Under Device |
58 |
Drivers > Character devices, ensure /dev/agpgart is enabled (certain other |
59 |
things hard-enable it in which case it's displayed with --- instead of the |
60 |
usual option), that DRM is built-in or modularized (built-in here), and |
61 |
that the ATI Radeon DRM support is likewise built-in or modularized |
62 |
(modularized here). Of course if you change the built-ins, you'll need to |
63 |
reboot and run the new kernel to get them. Otherwise, you can probably |
64 |
simply modprobe them. |
65 |
|
66 |
Note that you can also get DRI/DRM separately, and might want to for newer |
67 |
cards, but I've always used the kernel built-in, so I can't get into many |
68 |
specifics on that except that I know it's possible and often recommended |
69 |
for cards where the 3D support isn't fully stable yet. |
70 |
|
71 |
Then, you'll want to change your driver in xorg.conf, from frglx or |
72 |
whatever the proprietary one is, to radeon (Driver "radeon" in |
73 |
Section "Device"). Depending on what driver specific settings you have if |
74 |
any, and how complicated your video setup is, that might be all you have |
75 |
to do, or you may have to do some additional configuration. Here, I run |
76 |
two monitors attached to the same card, in merged framebuffer mode, thus |
77 |
avoiding having to run the xinerama extension, and I have a rather complex |
78 |
setup with some driver specific settings . However, for a single monitor |
79 |
and no special settings, you may not have anything else to worry about. |
80 |
Try it and see, I'd say, then see what the log says if you don't like it |
81 |
and either man radeon and go from there or ask for further help. |
82 |
|
83 |
I'm not sure if ATI has its own eselect opengl setting or not, but if it |
84 |
does and you were using it, you'll want to switch back to xorg-x11 there, |
85 |
too. |
86 |
|
87 |
AFAIK, you should even be able to keep both setups merged on your system, |
88 |
and switch between them as desired. In any event, I'd suggest simply |
89 |
commenting out any frglx settings in xorg.conf instead of deleting them, |
90 |
at least at first, making it easy to go back if you decide you want to. |
91 |
|
92 |
>> All that said, there's one negative as well. When the packages are |
93 |
>> split, that means most of what was the single ./configure step in the |
94 |
>> monolithic package now gets run many times, once for each of the split |
95 |
>> packages. |
96 |
> |
97 |
> Wouldn't a configure cache work in this case? I haven't actually tried one |
98 |
> myself |
99 |
> (due to all the warnings), however within a KDE merge it should always be |
100 |
> the same. |
101 |
|
102 |
Um... yes. However, while I use it, it's not really supported by Gentoo |
103 |
if you run into trouble with it, which does happen occasionally, so I |
104 |
didn't mention it. Basically, certain apps apparently poison its cache, |
105 |
making trouble not for themselves, but for whatever tries to use the |
106 |
portion of the cache that was poisoned, later. The problem is therefore |
107 |
extremely hard to find since the package that fails might be the next one |
108 |
merged or might be 10 or 100 packages down the line -- and of course the |
109 |
bug ends up getting reported against the wrong package, the one that |
110 |
failed due to the invalid cached config, not the one that made the config |
111 |
invalid in the first place. You can see why certain developers, that |
112 |
happen to be the maintainers of the packages most frequently targeted by |
113 |
confcache issues not from that package, but from something else an unknown |
114 |
number of packages earlier, would begin to /hate/ the very idea of |
115 |
confcache, after they get say 20 bugs on it, when it's not their package |
116 |
at fault! |
117 |
|
118 |
So anyway, what I do is any time I get a failure, the first thing I try is |
119 |
blowing away the cached config, so confcache has to start from scratch. |
120 |
If it's a confcache issue, that /usually/ solves it, altho I've seen a |
121 |
couple packages that won't merge with confcache on at all, so I had to |
122 |
FEATURES=-confcache emerge <pkg> to get them to emerge. Fortunately, I've |
123 |
not had any devs complaining about it in my FEATURES when I bug something |
124 |
with FEATURES=confcache in my emerge --info output, but since that's the |
125 |
first thing I try killing when an emerge doesn't work, I'd not be filing |
126 |
the bug if it was confcache related |
127 |
|
128 |
FWIW there is apparently at least one KDE specific package that poisons |
129 |
the confcache for expat, which is used by something later in the kde |
130 |
upgrade process. I know this as I've triggered the thing several times |
131 |
on a kde upgrade -- and I have /tmp and thus /tmp/confcache on a tmpfs, so |
132 |
it's always clear after a reboot, and sometimes the kde upgrade has been |
133 |
the first set of emerges I've done! |
134 |
|
135 |
Still, I tend to watch my merges fairly closely (a dual Opteron and |
136 |
enough memory to have PORTAGE_TMPDIR on tmpfs means I can do merges in the |
137 |
background without too much trouble, as long as I've set |
138 |
PORTAGE_NICENESS), and find it's still worth the trouble of having to |
139 |
merge an individual package here and there after blowing away the |
140 |
confcache, before resuming the regular merge sequence. Those who have a |
141 |
slower system and find it preferable to set portage to do its merges |
142 |
while they are away or asleep, however, would likely find it pretty |
143 |
frustrating, since it would have triggered an emerge abort, less than |
144 |
half-way thru that long kde upgrade. |
145 |
|
146 |
>> In my case, there are whole swatches of several of the monolithics that |
147 |
>> I don't use at all and would prefer not to have on the system (can't |
148 |
>> cause |
149 |
> |
150 |
> Do you mind sharing the list of kde packates that you DO use? |
151 |
|
152 |
$grep kde-base /var/lib/portage/world |
153 |
kde-base/ksig |
154 |
kde-base/kdeartwork-kworldclock |
155 |
kde-base/kcalc |
156 |
kde-base/kaddressbook-plugins |
157 |
kde-base/kstart |
158 |
kde-base/kgpg |
159 |
kde-base/kmix |
160 |
kde-base/kview |
161 |
kde-base/kicker-applets |
162 |
kde-base/secpolicy |
163 |
kde-base/kdcop |
164 |
kde-base/kdict |
165 |
kde-base/kooka |
166 |
kde-base/kpager |
167 |
kde-base/kdf |
168 |
kde-base/ksystraycmd |
169 |
kde-base/kscreensaver |
170 |
kde-base/kate-plugins |
171 |
kde-base/kpat |
172 |
kde-base/kdepasswd |
173 |
kde-base/kppp |
174 |
kde-base/kfloppy |
175 |
kde-base/artsplugin-audiofile |
176 |
kde-base/knetattach |
177 |
kde-base/khexedit |
178 |
kde-base/kdeadmin-kfile-plugins |
179 |
kde-base/ksnapshot |
180 |
kde-base/kmenuedit |
181 |
kde-base/ksysguard |
182 |
kde-base/kdeaddons-kfile-plugins |
183 |
kde-base/kuser |
184 |
kde-base/kolourpaint |
185 |
kde-base/knewsticker-scripts |
186 |
kde-base/kaudiocreator |
187 |
kde-base/renamedlg-images |
188 |
kde-base/kmid |
189 |
kde-base/kcron |
190 |
kde-base/klipper |
191 |
kde-base/kdemultimedia-kfile-plugins |
192 |
kde-base/kcoloredit |
193 |
kde-base/kwalletmanager |
194 |
kde-base/kdeartwork-emoticons |
195 |
kde-base/kdeartwork-sounds |
196 |
kde-base/kdeartwork-wallpapers |
197 |
kde-base/kteatime |
198 |
kde-base/kcharselect |
199 |
kde-base/kdegraphics-kfile-plugins |
200 |
kde-base/kdebase-startkde |
201 |
kde-base/ksvg |
202 |
kde-base/konsole |
203 |
kde-base/kiconedit |
204 |
kde-base/kget |
205 |
kde-base/renamedlg-audio |
206 |
kde-base/kdeartwork-iconthemes |
207 |
kde-base/kdenetwork-kfile-plugins |
208 |
kde-base/kmail |
209 |
kde-base/kdeartwork-kwin-styles |
210 |
kde-base/kdvi |
211 |
kde-base/kdemultimedia-kappfinder-data |
212 |
kde-base/ark |
213 |
kde-base/kruler |
214 |
kde-base/kode |
215 |
kde-base/kdeartwork-styles |
216 |
kde-base/kpdf |
217 |
kde-base/artsplugin-xine |
218 |
kde-base/kregexpeditor |
219 |
kde-base/konq-plugins |
220 |
kde-base/kdemultimedia-arts |
221 |
kde-base/kgamma |
222 |
kde-base/kweather |
223 |
kde-base/konqueror-akregator |
224 |
|
225 |
There are of course others, dependencies of the packages listed in world. |
226 |
|
227 |
>> If you don't have -ldap, the profile is probably setting +ldap for you. |
228 |
>> Yes, I just checked, it's turned on by default in |
229 |
>> $PORTDIR/profiles/default-linux/amd64/2006.1/desktop in any case, so |
230 |
>> probably is in other similar profiles as well. |
231 |
> |
232 |
> I'm using that profile. I'll try to remember to check the profile as well |
233 |
> as make.conf, |
234 |
> I'd didn't realise I would have to minus some USE flags, rather than just |
235 |
> omit them. |
236 |
|
237 |
I always use the output from emerge --info when I'm checking USE flag |
238 |
status, since that way portage folds in all the ones turned on by the |
239 |
cascading profiles. With the cascading profiles, you'd otherwise have to |
240 |
check several files, not only the profile itself, but its parents, in this |
241 |
case not only desktop, but 2006.1, and amd64, and default-linux, and |
242 |
profiles/base, as well. By using emerge --info, you get what portage |
243 |
would use in general, regardless of what file it's in (with the |
244 |
exception of the package specific package.use), and if you don't like it, |
245 |
you can set your make.conf accordingly, without having to worry about |
246 |
where in the cascading profiles the setting is otherwise coming from. |
247 |
|
248 |
Additionally, I ALWAYS use either emerge --ask --verbose (which I've |
249 |
aliased to ea) or emerge --pretend --verbose (ep) previous to emerging or |
250 |
updating anything, and check either changed USE flags (for updates) or all |
251 |
USE flags (for new packages) before I merge the package, verifying whether |
252 |
it is indeed going to use the USE flags I'd prefer. That is in fact one |
253 |
of the big reasons I like Gentoo -- I like having that control and make |
254 |
use if it. Thus, knowing I have no use for LDAP, I'd have turned that off |
255 |
either when I initially went thru USE flags when I setup the system, or |
256 |
soon thereafter, when I found something trying to merge with USE=ldap. |
257 |
|
258 |
> I added -ldap to my make.conf and did a full rebuild --newuse, which took |
259 |
> most of the day. Now, despite eix showing -ldap on kde-base/dedbase, |
260 |
> 'equery depends' still shows the same list (less the older version of |
261 |
> gnupg) as above. depclean did remove 2 more packages, but not openldap. |
262 |
|
263 |
Hmm... that's weird. I'd probably be investigating further, but it's not |
264 |
something I could really explain how to do remotely. It's one of those |
265 |
things I'd try one thing, then try something else depending on the results |
266 |
I got, until I either got tired of it and gave up or resolved the issue to |
267 |
my satisfaction. |
268 |
|
269 |
> openssh (e.g.) also shows -ldap in eix, but still a dependent of openldap |
270 |
> in equery depends. |
271 |
|
272 |
Remember when I said I like the control Gentoo gives me? Well, I'm not |
273 |
sure why openssh is in the system dependencies, but having no remote |
274 |
computer, I have no intention of logging on remotely to other computers |
275 |
nor of letting anyone logon remotely to this one. In fact, just the |
276 |
/idea/ of the software existing on my computer disturbs me, given there's |
277 |
no legitimate reason I know of for it to be there, so it's not, despite |
278 |
the system dependency! It's in my /etc/portage/profile/package.provided |
279 |
file at a high enough version I shouldn't have to worry about it for |
280 |
awhile! That makes portage act as if it's merged when it's not, and as |
281 |
long as nothing else actually has to depend on it, I should be fine. I've |
282 |
been fine so far! |
283 |
|
284 |
Naturally, however, I'm not going to recommend this to anyone else, as I |
285 |
imagine there's gotta be SOME sane reason it's in system. I figure if |
286 |
whatever it is ever gets me and crashes the system, I'm a decent enough |
287 |
troubleshooter I should hope I figure it out. Meanwhile, I personally |
288 |
rest WAY better knowing its not on my system at all, so couldn't POSSIBLY |
289 |
be used to remotely login or somehow otherwise compromise my system. If |
290 |
it's not there to compromise, it can't be compromised, and I want it not |
291 |
there, so with Gentoo, I make sure it IS "not there"! |
292 |
|
293 |
So anyway, no openssl here, so regardless of the ldap USE flag setting, |
294 |
LDAP won't be a problem for openssl for me here! =8^) |
295 |
|
296 |
> It looks to me like 'equery depends' is broken. |
297 |
> |
298 |
> app-crypt/gnupg is an example of something that still has the ldap USE |
299 |
> flag enabled, |
300 |
> I've noticed some packages just blatantly ignore make.conf, and always |
301 |
> have certain USE enabled, which I don't understand. |
302 |
|
303 |
Does it have the USE flag enabled when you try an emerge --pretend? Maybe |
304 |
it's listed in /etc/portage/package.use? (Tho why it would be there if you |
305 |
didn't put it there is an even weirder question, but that's one |
306 |
explanation for individual packages diverging from the general make.conf |
307 |
setting.) |
308 |
|
309 |
If it doesn't have the USE flag enabled, but it's still depending on it, |
310 |
it can be due to a bug in the ebuild. On most (non-Gentoo) systems, |
311 |
configure scripts normally automatically detect optional packages and link |
312 |
against them if they find them. Usually, there's a configure option to |
313 |
specifically turn on or off the linking, and the ebuild can set that in |
314 |
addition to telling portage whether the package should be installed first |
315 |
as a dependency or not. However, sometimes an ebuild won't set the |
316 |
configure option to specifically turn it on or off, or sometimes the |
317 |
option won't work as intended or isn't there. In those cases, it's an |
318 |
ebuild bug, and should probably be filed as such, so the ebuild maintainer |
319 |
can figure out the problem and either enable the configure option or |
320 |
create a suitable patch and apply it as well as filing a bug upstream to |
321 |
try and get the bug fixed there as well. (Of course, do a bug search to |
322 |
see if anyone else has filed the bug before you file it yourself. |
323 |
Handling dups takes time that could otherwise be spent fixing bugs.) |
324 |
|
325 |
I'd guess gnupg may be one of these bugged packages. Since the file was |
326 |
installed, the configure script found and built against it, even tho the |
327 |
USE flag was off, so it would have no longer pulled in the dependency if |
328 |
the file wasn't there already, to be detected. If you can indeed confirm |
329 |
that case, I would suggest checking for a bug filed on it and filing one |
330 |
if you can't find one. |
331 |
|
332 |
> After learning more about "provide_old_libs" from the bug, and |
333 |
> /var/log/portage/elog, I just deleted all of broken .so files, as they |
334 |
> were supposed to have been. revdep-rebuild is now clean. |
335 |
|
336 |
Sometimes that's the easiest, particularly if you have binary-packages |
337 |
ready to replace things if you decide you made a mistake and it's needed |
338 |
after all. |
339 |
|
340 |
-- |
341 |
Duncan - List replies preferred. No HTML msgs. |
342 |
"Every nonfree program has a lord, a master -- |
343 |
and if you use the program, he is your master." Richard Stallman |
344 |
|
345 |
-- |
346 |
gentoo-amd64@g.o mailing list |