[gentoo-user] slow redrawing in KDE
I just emerged KDE, changing from the monolytic packages to the split ones. Now windows redrawing is painfully (and cas-ca-ding) slow. The problem seems to be the same as in http://forums.gentoo.org/viewtopic-t-344889-highlight-kde+slow+redraw.html (but no answer there...) Any idea? -- Jorge Almeida -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
Jorge Almeida wrote: I just emerged KDE, changing from the monolytic packages to the split ones. Now windows redrawing is painfully (and cas-ca-ding) slow. The problem seems to be the same as in http://forums.gentoo.org/viewtopic-t-344889-highlight-kde+slow+redraw.html (but no answer there...) Any idea? First step to isolate this problem, I'd install a minimalist wm such as x11-wm/openbox and see which apps I can reproduce the problem with there, if any. Zac -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Sun, 17 Jul 2005, Zac Medico wrote: Jorge Almeida wrote: I just emerged KDE, changing from the monolytic packages to the split ones. Now windows redrawing is painfully (and cas-ca-ding) slow. The problem seems to be the same as in http://forums.gentoo.org/viewtopic-t-344889-highlight-kde+slow+redraw.html (but no answer there...) Any idea? First step to isolate this problem, I'd install a minimalist wm such as x11-wm/openbox and see which apps I can reproduce the problem with there, if any. Zac Not that easy. The problem is more visible when the desktop is filled with a Mozilla window and I change to this desktop. I would need a wm with virtual desktops and it had to be possible to change desktops via keyboard. I'm getting tired of KDE: each upgrade brings new problems. I would give it up if I could find a wm supporting multiple desktops (with the possibility of different backgrounds) and control via keyboard. I can't get KDE's goodies, like shadows and transparency, to work, anyway... Thanks for the reply. Jorge -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
Jorge Almeida wrote: On Sun, 17 Jul 2005, Zac Medico wrote: Jorge Almeida wrote: I just emerged KDE, changing from the monolytic packages to the split ones. Now windows redrawing is painfully (and cas-ca-ding) slow. The problem seems to be the same as in http://forums.gentoo.org/viewtopic-t-344889-highlight-kde+slow+redraw.html (but no answer there...) Any idea? First step to isolate this problem, I'd install a minimalist wm such as x11-wm/openbox and see which apps I can reproduce the problem with there, if any. Zac Not that easy. The problem is more visible when the desktop is filled with a Mozilla window and I change to this desktop. I would need a wm with virtual desktops and it had to be possible to change desktops via keyboard. I'm getting tired of KDE: each upgrade brings new problems. I would give it up if I could find a wm supporting multiple desktops (with the possibility of different backgrounds) and control via keyboard. I can't get KDE's goodies, like shadows and transparency, to work, anyway... Thanks for the reply. Jorge Openbox supports multiple desktops. You can replace the default kde window manager (kwin) with openbox: http://icculus.org/openbox/docs.php?page=build.html#install-kde Zac -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Mon, 18 Jul 2005, Zac Medico wrote: Openbox supports multiple desktops. You can replace the default kde window manager (kwin) with openbox: http://icculus.org/openbox/docs.php?page=build.html#install-kde Zac Browsing the documentation, it seems it doesn't support setting the background. I'll have a look at third party applications... I really need commuting desktops with keys, and different backgrounds allow me to know where I am. Jorge -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
Jorge Almeida wrote: On Mon, 18 Jul 2005, Zac Medico wrote: Openbox supports multiple desktops. You can replace the default kde window manager (kwin) with openbox: http://icculus.org/openbox/docs.php?page=build.html#install-kde Zac Browsing the documentation, it seems it doesn't support setting the background. I'll have a look at third party applications... I really need commuting desktops with keys, and different backgrounds allow me to know where I am. Jorge I wasn't suggesting Openbox as a permanent solution. It's just a troubleshooting tool to help you isolate the problem. I use KDE 3.4.1 (split ebuilds) and haven't noticed any "redraw" problems like you're experiencing. Does the problem only affect kde apps? How about a qt app with no kde support? Gtk apps are fine? Zac -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Monday 18 July 2005 10:17, Jorge Almeida wrote: > On Sun, 17 Jul 2005, Zac Medico wrote: > > Jorge Almeida wrote: > >> I just emerged KDE, changing from the monolytic packages to the split > >> ones. > >> Now windows redrawing is painfully (and cas-ca-ding) slow. > >> The problem seems to be the same as in > >> http://forums.gentoo.org/viewtopic-t-344889-highlight-kde+slow+redraw.ht > >>ml (but no answer there...) > >> Any idea? > > > > First step to isolate this problem, I'd install a minimalist wm such as > > x11-wm/openbox and see which apps I can reproduce the problem with there, > > if any. > > > > Zac > > Not that easy. The problem is more visible when the desktop is filled > with a Mozilla window and I change to this desktop. I would need a wm > with virtual desktops and it had to be possible to change desktops via > keyboard. > so, not kde, but mozilla is slow? Slow redreaw of gtk is known. Do you have enough ram? If you need swap, kde is dead slow. Is RenderAccel on? Is KDE prelinked? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
Volker Armin Hemmann wrote: Do you have enough ram? If you need swap, kde is dead slow. This one should be *really* obvious. If the hard drive is thrashing, you're out of ram :-). Zac -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Mon, 18 Jul 2005, Volker Armin Hemmann wrote: so, not kde, but mozilla is slow? Slow redreaw of gtk is known. Do you have enough ram? If you need swap, kde is dead slow. Is RenderAccel on? Is KDE prelinked? It's not a RAM problem (512M, and top shows it's not leaking somewhere). KDE is not prelinked. I don't know about RenderAccel (how can I tell?). Anyway, I didn't change anything except KDE. Slow rendering shows mainly with Mozilla and Thunderbird. With gvim too, I suppose (hard to tell). But Mozilla was fine before. Jorge -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Monday 18 July 2005 11:47, Zac Medico wrote: > Volker Armin Hemmann wrote: > > Do you have enough ram? > > If you need swap, kde is dead slow. > > This one should be *really* obvious. If the hard drive is thrashing, > you're out of ram :-). > > Zac not really. It is enough to have some kb into swap, most of the real ram eaten by caches&buffers and kde starts to crawl BADLY. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Monday 18 July 2005 12:15, Jorge Almeida wrote: > On Mon, 18 Jul 2005, Volker Armin Hemmann wrote: > > so, not kde, but mozilla is slow? > > Slow redreaw of gtk is known. > > > > Do you have enough ram? > > If you need swap, kde is dead slow. > > Is RenderAccel on? > > Is KDE prelinked? > > It's not a RAM problem (512M, and top shows it's not leaking somewhere). > KDE is not prelinked. I don't know about RenderAccel (how can I tell?). > Anyway, I didn't change anything except KDE. Slow rendering shows mainly > with Mozilla and Thunderbird. With gvim too, I suppose (hard to tell). > But Mozilla was fine before. > well 512 is most of the time enough, but not always ;) hm, if only gtk apps are slow, it is normal - gtk IS slow. Very slow. Search google for gtk and slow and you'll find a lot ;) RenderAccel is set in your xorg.conf - if you have nvidia. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Mon, 18 Jul 2005, Volker Armin Hemmann wrote: well 512 is most of the time enough, but not always ;) I know, but I checked "top". hm, if only gtk apps are slow, it is normal - gtk IS slow. Very slow. But it wasn't noticeable before... It looks as if the several widgets were being shown _before_ the main window... Search google for gtk and slow and you'll find a lot ;) RenderAccel is set in your xorg.conf - if you have nvidia. Ati Radeon 7500. -- Jorge Almeida -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
Jorge Almeida wrote: > On Mon, 18 Jul 2005, Volker Armin Hemmann wrote: > >>> >> >> well 512 is most of the time enough, but not always ;) > > I know, but I checked "top". > >> >> hm, if only gtk apps are slow, it is normal - gtk IS slow. Very slow. > > But it wasn't noticeable before... It looks as if the several widgets > were being shown _before_ the main window... > >> >> Search google for gtk and slow and you'll find a lot ;) >> >> RenderAccel is set in your xorg.conf - if you have nvidia. > > Ati Radeon 7500. > >> > Hi, Think i can't of great help here, but at least twice when i had slow graphical performance solved it by re-emerging some packages and xorg-x11 once (i assume you have run 'revdep-rebuild' ;) As it seems your main DM is KDE it's likely that there may be issues with GTK-apps, as their libs/deps also get loaded when mozilla/etc is run. Here's some info: 1.mozilla dependencies: ...www-client/mozilla-1.7.8: crypt? !moznomail? >=app-crypt/gnupg-1.2.1 app-crypt/gnupg-1.4.1 postgres? >=dev-db/postgresql-7.2.0 dev-db/postgresql-8.0.1-r4 >=dev-libs/glib-2.2.0dev-libs/glib-2.6.4 >=dev-libs/libIDL-0.8.0 dev-libs/libIDL-0.8.5 >=media-libs/fontconfig-2.1 media-libs/fontconfig-2.2.3 >=media-libs/jpeg-6b media-libs/jpeg-6b-r4 >=media-libs/libmng-1.0.0 media-libs/libmng-1.0.8-r1 >=media-libs/libpng-1.2.1 media-libs/libpng-1.2.8 >=sys-apps/portage-2.0.36 sys-apps/portage-2.0.51.22-r1 >=sys-libs/zlib-1.1.4sys-libs/zlib-1.2.2-r1 >=www-client/mozilla-launcher-1.22 www-client/mozilla-launcher-1.32 >=www-client/mozilla-launcher-1.28 www-client/mozilla-launcher-1.32 >=x11-libs/gtk+-2.2.0x11-libs/gtk+-2.6.7 >=x11-libs/pango-1.2.1 x11-libs/pango-1.8.1 app-arch/unzip app-arch/unzip-5.50-r2 app-arch/zip app-arch/zip-2.3-r4 dev-lang/perldev-lang/perl-5.8.6-r5 dev-libs/expat dev-libs/expat-1.95.8 dev-util/pkgconfig dev-util/pkgconfig-0.17.2-r1 !bootstrap? sys-devel/patch sys-devel/patch-2.5.9 virtual/x11 x11-base/xorg-x11-6.8.2-r2 !moznoxft? virtual/xft x11-base/xorg-x11-6.8.2-r2 ~sys-devel/autoconf-2.13 sys-devel/autoconf-2.13 ... 2.GTK+ dependencies: ...x11-libs/gtk+-2.6.7: >=dev-libs/atk-1.0.1 dev-libs/atk-1.9.1 >=dev-libs/glib-2.6 dev-libs/glib-2.6.4 >=dev-util/pkgconfig-0.12.0 dev-util/pkgconfig-0.17.2-r1 jpeg? >=media-libs/jpeg-6b-r2 media-libs/jpeg-6b-r4 >=media-libs/libpng-1.2.1 media-libs/libpng-1.2.8 >=sys-devel/automake-1.7.9 sys-devel/automake-1.9.5 >=x11-libs/pango-1.8 x11-libs/pango-1.8.1 sys-devel/autoconf sys-devel/autoconf-2.59-r6 !bootstrap? sys-devel/patch sys-devel/patch-2.5.9 virtual/x11 x11-base/xorg-x11-6.8.2-r2 x11-misc/shared-mime-info x11-misc/shared-mime-info-0.16 ... IMHO you could first try emerging: glib>k+ and probably in second place: xorg-x11. There are also many image-manupulation libraries: jpeg,png,mng HTH. Rumen smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-user] slow redrawing in KDE
Jorge Almeida wrote: But it wasn't noticeable before... It looks as if the several widgets were being shown _before_ the main window... So, if I understand you correctly, some mozilla controls get drawn long before the titlebar? Is that right? If so, possibly an error with themes or alpha blending... Could you post the output "xdpyinfo"...I have a feeling the answer is going to be in there. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
Jorge Almeida wrote: > I just emerged KDE, changing from the monolytic packages to the > split ones. > Now windows redrawing is painfully (and cas-ca-ding) slow. Have you tried renaming your .kde3.4/ dir temporarily (while logged out of KDE)? And removed all kde and mcop junk from /tmp? Have you unmerged the old kde ebuilds? And done --depclean? And revdep-rebuild? Benno -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Mon, 18 Jul 2005, Richard Fish wrote: Jorge Almeida wrote: But it wasn't noticeable before... It looks as if the several widgets were being shown _before_ the main window... So, if I understand you correctly, some mozilla controls get drawn long before the titlebar? Is that right? Yep. If so, possibly an error with themes or alpha blending... But why now? Could you post the output "xdpyinfo"...I have a feeling the answer is going to be in there. $ xdpyinfo name of display::0.0 version number:11.0 vendor string:Gentoo Linux (The X.Org Foundation 6.8.2, revision r1-0.1.2) vendor release number:60802000 X.Org version: 6.8.2 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x2a00049, revert to PointerRoot number of extensions:33 BIG-REQUESTS Composite DAMAGE DEC-XTRAP DOUBLE-BUFFER DPMS Extended-Visual-Information GLX LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XFree86-DGA XFree86-DRI XFree86-Misc XFree86-VidModeExtension XInputExtension XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: print screen:no dimensions:1280x1024 pixels (325x260 millimeters) resolution:100x100 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x41 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0xfa4035 KeyPressMask ButtonPressMask EnterWindowMask LeaveWindowMask KeymapStateMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:9 default visual id: 0x23 visual: visual id:0x23 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x24 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x25 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x26 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x27 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x28 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x29 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x2a class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x3f class:TrueColor depth:32 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits -- Jorge Almeida -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Mon, 18 Jul 2005, Rumen Yotov wrote: Hi, Think i can't of great help here, but at least twice when i had slow graphical performance solved it by re-emerging some packages and xorg-x11 once (i assume you have run 'revdep-rebuild' ;) As it seems your main DM is KDE it's likely that there may be issues with GTK-apps, as their libs/deps also get loaded when mozilla/etc is run. Here's some info: 1.mozilla dependencies: ...www-client/mozilla-1.7.8: crypt? !moznomail? >=app-crypt/gnupg-1.2.1 app-crypt/gnupg-1.4.1 postgres? >=dev-db/postgresql-7.2.0 dev-db/postgresql-8.0.1-r4 >=dev-libs/glib-2.2.0dev-libs/glib-2.6.4 >=dev-libs/libIDL-0.8.0 dev-libs/libIDL-0.8.5 >=media-libs/fontconfig-2.1 media-libs/fontconfig-2.2.3 >=media-libs/jpeg-6b media-libs/jpeg-6b-r4 >=media-libs/libmng-1.0.0 media-libs/libmng-1.0.8-r1 >=media-libs/libpng-1.2.1 media-libs/libpng-1.2.8 >=sys-apps/portage-2.0.36 sys-apps/portage-2.0.51.22-r1 >=sys-libs/zlib-1.1.4sys-libs/zlib-1.2.2-r1 >=www-client/mozilla-launcher-1.22 www-client/mozilla-launcher-1.32 >=www-client/mozilla-launcher-1.28 www-client/mozilla-launcher-1.32 >=x11-libs/gtk+-2.2.0x11-libs/gtk+-2.6.7 >=x11-libs/pango-1.2.1 x11-libs/pango-1.8.1 app-arch/unzip app-arch/unzip-5.50-r2 app-arch/zip app-arch/zip-2.3-r4 dev-lang/perldev-lang/perl-5.8.6-r5 dev-libs/expat dev-libs/expat-1.95.8 dev-util/pkgconfig dev-util/pkgconfig-0.17.2-r1 !bootstrap? sys-devel/patch sys-devel/patch-2.5.9 virtual/x11 x11-base/xorg-x11-6.8.2-r2 !moznoxft? virtual/xft x11-base/xorg-x11-6.8.2-r2 ~sys-devel/autoconf-2.13 sys-devel/autoconf-2.13 ... 2.GTK+ dependencies: ...x11-libs/gtk+-2.6.7: >=dev-libs/atk-1.0.1 dev-libs/atk-1.9.1 >=dev-libs/glib-2.6 dev-libs/glib-2.6.4 >=dev-util/pkgconfig-0.12.0 dev-util/pkgconfig-0.17.2-r1 jpeg? >=media-libs/jpeg-6b-r2 media-libs/jpeg-6b-r4 >=media-libs/libpng-1.2.1 media-libs/libpng-1.2.8 >=sys-devel/automake-1.7.9 sys-devel/automake-1.9.5 >=x11-libs/pango-1.8 x11-libs/pango-1.8.1 sys-devel/autoconf sys-devel/autoconf-2.59-r6 !bootstrap? sys-devel/patch sys-devel/patch-2.5.9 virtual/x11 x11-base/xorg-x11-6.8.2-r2 x11-misc/shared-mime-info x11-misc/shared-mime-info-0.16 ... IMHO you could first try emerging: glib>k+ and probably in second place: xorg-x11. There are also many image-manupulation libraries: jpeg,png,mng HTH. Rumen I guess it's going to be a long week... Thanks :) Jorge -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Mon, 18 Jul 2005, Benno Schulenberg wrote: Have you tried renaming your .kde3.4/ dir temporarily (while logged out of KDE)? And removed all kde and mcop junk from /tmp? Have you unmerged the old kde ebuilds? And done --depclean? And revdep-rebuild? No. I think a deep cleaning is in order. Thank you. Jorge -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
Jorge Almeida wrote: ... IMHO you could first try emerging: glib>k+ and probably in second place: xorg-x11. There are also many image-manupulation libraries: jpeg,png,mng HTH. Rumen I guess it's going to be a long week... Thanks :) Jorge Something that's still unclear to me: is the problem with kde, mozilla, or both? If you experience the same problem with mozilla under openbox then your troubles have nothing to do with kde. OTOH, if you there's no problems under openbox then the problem is in X/glib/gtk/mozilla. You can greatly reduce the troubleshooting time if you go about it in a systematic way (process of elimination/scientific method) to isolate the problem. Zac -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Mon, 18 Jul 2005, Zac Medico wrote: Something that's still unclear to me: is the problem with kde, mozilla, or both? If you experience the same problem with mozilla under openbox then your troubles have nothing to do with kde. OTOH, if you there's no problems under openbox then the problem is in X/glib/gtk/mozilla. No problem under openbox. The problem manifests with mozilla, but only after upgrading KDE. All is probablly my fault, for not keeping my system clean. I'm in the cleaning process now... Jorge -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
Jorge Almeida wrote: On Mon, 18 Jul 2005, Richard Fish wrote: If so, possibly an error with themes or alpha blending... But why now? Well, one of the things that has been happening in the xorg/qt/kde world is a move towards more eye-candy with transparency, drop shadows, and so on. My guess is that this version of KDE is trying to use a new method of drawing things, that turns out to be slower than the old (or maybe more accurately, plain) method for your hardware. You might take a walk through the KDE option menus and disable anything that says "drop shadows", "transparency", or most other eye-candy. Could you post the output "xdpyinfo"...I have a feeling the answer is going to be in there. $ xdpyinfo number of extensions:33 BIG-REQUESTS Composite Could you try disabling this. From googling, it seems that something like the following in xorg.conf should do it: Section "Extensions" Option "Composite" "Disable" EndSection Everything else looks sane. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] slow redrawing in KDE
On Tue, 19 Jul 2005, Richard Fish wrote: You might take a walk through the KDE option menus and disable anything that says "drop shadows", "transparency", or most other eye-candy. I had done that already. But I like eye-candy, or I might as well use a minimalistic wm... (I didn't get shadows or transparency anyway, whwn it was enabled.) number of extensions:33 BIG-REQUESTS Composite Could you try disabling this. From googling, it seems that something like the following in xorg.conf should do it: Section "Extensions" Option "Composite" "Disable" EndSection I did it (actually, I commented out the whole section). I guess things are better. I still can see widgets in mozilla windows showing in a cascading way, but time lag is small. BTW: that Section was the last one in xorg.conf, and vim suggested there was something wrong with it (different colors than other sections), but it's beyond me to guess what. Everything else looks sane. -Richard Thanks. Jorge -- gentoo-user@gentoo.org mailing list