[gentoo-user] Slow redraw of windows following -uD --world

[gentoo-user] Slow redraw of windows following -uD --world

[reader]

Folling a major update with sync followed by -vuD --world  I'm seeing
visible slowness in X when I move a window or scroll a buffer.

I'm running kde 3.5 desktop (kdebase) but I did most of the update in
console mode and then wanted to try one of the fast light window
managers.  So installed `fluxbox' and started it up.

I saw really slow and noticable sloth when moving a window.  It redrew
from the bottom up (an xterm) and took most or all of a second.

I thought it was fluxbox and was pretty disgusted after all the hype
I've seen about how fast it is.

But then starting up kde and I see the same thing but not quite as
bad.  Or at least to my eye it seemed a little faster but still not
even close to what I saw before the update.

This is a celeron 3.06 Ghz with 2GB ram so not exactly under powered.
And I know it isn't the machine since it was not acting like this
before the update.

Here is an example.... I'm typing this in an emacs terminal running
under X.  If I move the terminal even an 1/8 of inch I see redraw
happen in two pulses either up and down or down and up taking very close
to a second.

At this moment I have Konqueror, emacs and two xterms running.
Looking at top I see  96 to 99 percent idle:

Top shows:
top - 19:37:27 up 20:02,  6 users,  load average: 0.14, 0.06, 0.02
Tasks:  99 total,   2 running,  97 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.0% us,  0.3% sy,  0.0% ni, 98.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   2075536k total,  1728552k used,   346984k free,   603132k buffers
Swap:  2008116k total,        0k used,  2008116k free,   684584k cached

So resources are not starved... I'm kind of lost as to how to debug
further...  Does the 97 sleeping jobs indicate some kind of problem or
is that pretty normal?

Any other suggestions for debugging?

Cam I do something about this in /etc/X11/xorg.conf? 


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Slow redraw of windows following -uD --world

[Hemmann, Volker Armin]

Hi,


well, you gave an example why I never use -D (deep) updates.

I bet something 'broke'  because a dependency got updated.

Try revdep-rebuild, maybe it will solve the problem.
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Slow redraw of windows following -uD --world

[reader]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:

> Hi,
>
>
> well, you gave an example why I never use -D (deep) updates.
>
> I bet something 'broke'  because a dependency got updated.

What is the advantage of never using `deep'... seems I recall reading
here that it was sort of necessary after a major update and sync.

>
> Try revdep-rebuild, maybe it will solve the problem.

Well it found a pretty basic package to be broken:
gcc-4.1.1F and is not running this:
emerge --oneshot  =sys-devel/gcc-4.1.1F

I think this will run for a while.... do think it will have bearing on
the slow redraw I see?

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Slow redraw of windows following -uD --world

[Hemmann, Volker Armin]

On Friday 16 June 2006 03:42, reader@newsguy.com wrote:
> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:
> > Hi,
> >
> >
> > well, you gave an example why I never use -D (deep) updates.
> >
> > I bet something 'broke'  because a dependency got updated.
>
> What is the advantage of never using `deep'... seems I recall reading
> here that it was sort of necessary after a major update and sync.
>
> > Try revdep-rebuild, maybe it will solve the problem.
>
> Well it found a pretty basic package to be broken:
> gcc-4.1.1F and is not running this:
> emerge --oneshot  =sys-devel/gcc-4.1.1F
>
> I think this will run for a while.... do think it will have bearing on
> the slow redraw I see?


no, maybe it is fontconfig, maybe your update changed the opengl you are using 
(have you checked, that you are using nvidia-glx as a nvidia user and 
atis-glx as ati user?), maybe something else. Do you have amd64 and 
cool'n'quiet activated? Or a P4 that is overheating and throttling?

--deep is almost never needed. Some people love it and tell everybody to use 
it. Usually people who are version number freaks. But in 90% it is useless to 
harmfull.
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Slow redraw of windows following -uD --world

[reader]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:

>> > Try revdep-rebuild, maybe it will solve the problem.
>>
>> Well it found a pretty basic package to be broken:
>> gcc-4.1.1F and is not running this:
>> emerge --oneshot  =sys-devel/gcc-4.1.1F
>>
>> I think this will run for a while.... do think it will have bearing on
>> the slow redraw I see?
>

I've run into some kind of madness with gcc.  Afer the rebuild cited
above I'm told it installed successfully but then another fresh revdep
tells me this is broken:

  broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcjawt.laes (requires
  /usr/lib/lib-gnu-java-awt-peer-gtk.la)

  broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgij.la (requires
 /usr/lib/libgcj.la) done.

And wants to run the hours long oneshot again.

but since you say its not likely to be related to my redraw problem I
think I'll start a new thread about that. 

> no, maybe it is fontconfig, maybe your update changed the opengl you
> are using (have you checked, that you are using nvidia-glx as a
> nvidia user and atis-glx as ati user?), maybe something else. Do you
> have amd64 and cool'n'quiet activated? Or a P4 that is overheating
> and throttling?

About checking glx.  I'm not sure what you meant there...  I guess
nvidia-glx and atis-glx are modules?... Modprobe knows nothing about
them here. /usr/src/linux/.config shows one setting related to nvidia:
CONFIG_AGP_NVIDIA=m. 
Can you explain a little more what you mean there?

I have an MSI FX5700LE-TD256 vid card.  But prior to this upgrade I
had good redraw / scroll speeds.

No amd64... its Celeron MSI 865PE mobo. about overheat: I see the
redraw problem right at boot too before overheating would have happened.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Slow redraw of windows following -uD --world

[Rumen Yotov]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

Hi,
reader@newsguy.com wrote:
> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:
> 
>>>> Try revdep-rebuild, maybe it will solve the problem.
>>> Well it found a pretty basic package to be broken:
>>> gcc-4.1.1F and is not running this:
>>> emerge --oneshot  =sys-devel/gcc-4.1.1F
>>>
>>> I think this will run for a while.... do think it will have bearing on
>>> the slow redraw I see?
> 
> I've run into some kind of madness with gcc.  Afer the rebuild cited
> above I'm told it installed successfully but then another fresh revdep
> tells me this is broken:
> 
>   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcjawt.laes (requires
>   /usr/lib/lib-gnu-java-awt-peer-gtk.la)
> 
>   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgij.la (requires
>  /usr/lib/libgcj.la) done.
> 
> And wants to run the hours long oneshot again.
> 
> but since you say its not likely to be related to my redraw problem I
> think I'll start a new thread about that. 
> 
Check Bug-125728 for a solution (must change toolchain.eclass in an
overlay) and rebuild GCC *or* just manually fix/change broken .la files.
...SKIP...
> 
HTH.Rumen


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3493 bytes --]

[gentoo-user] Re: Slow redraw of windows following -uD --world

[reader]

Rumen Yotov <rumen@qrypto.org> writes:

> Check Bug-125728 for a solution (must change toolchain.eclass in an
> overlay) and rebuild GCC *or* just manually fix/change broken .la files.
> ...SKIP...

Can you explain a little more about the manual fix...?
In the bug reports one poster mentions setting a symlink but doesn't
spell out the details.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Slow redraw of windows following -uD --world

[Rumen Yotov]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

reader@newsguy.com wrote:
> Rumen Yotov <rumen@qrypto.org> writes:
> 
>> Check Bug-125728 for a solution (must change toolchain.eclass in an
>> overlay) and rebuild GCC *or* just manually fix/change broken .la files.
>> ...SKIP...
> 
> Can you explain a little more about the manual fix...?
> In the bug reports one poster mentions setting a symlink but doesn't
> spell out the details.
> 
Hi again,
Don't have your original mail (with error messages) but shortly:
Open the 'broken' *.la file/s and find the place where the broken paths
are (IIRC it's /usr/lib/... instead of /usr/lib/../../../..).
One solution is to manually edit the 'broken' *.la files putting the
right paths *or* IMHO create a link with the short-path name pointing to
the correct one. Sorry if this is too vague. Used the first method.
PS: could use 'qlist' or 'equery' with 'grep' to find the right paths.
Rumen

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3493 bytes --]

Re: [gentoo-user] Re: Slow redraw of windows following -uD --world

[Hemmann, Volker Armin]

On Friday 16 June 2006 16:12, reader@newsguy.com wrote:

> About checking glx.  I'm not sure what you meant there...  I guess
> nvidia-glx and atis-glx are modules?... Modprobe knows nothing about
> them here. /usr/src/linux/.config shows one setting related to nvidia:
> CONFIG_AGP_NVIDIA=m.
> Can you explain a little more what you mean there?
>
> I have an MSI FX5700LE-TD256 vid card.  But prior to this upgrade I
> had good redraw / scroll speeds.
>
> No amd64... its Celeron MSI 865PE mobo. about overheat: I see the
> redraw problem right at boot too before overheating would have happened.

since rumen answered the gcc problem....
(I would backup the la files and remove then, than rebuild gcc. AFAIK they are 
not needed anymore and leftovers), I try to answer your opengl question.

No, nvidia-glx is NOT the kernel module. That is nvidia-kernel!

You don't have the latest nvidia drivers installed?

That might be the culprit!

emerge nvidia-kernel
emergen nvidia-glx
eselect opengl set nvidia (or opengl-update nvidia)
change 'nv' in /etc/X11/xorg.conf to nvidia

restart X.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Vladimir G. Ivanovic]

On Fri, 2006-06-16 at 15:01 +0200, Hemmann, Volker Armin wrote:

> --deep is almost never needed. Some people love it and tell everybody to use 
> it. Usually people who are version number freaks. But in 90% it is useless to 
> harmfull.

Could you be more specific, please? How is it harmful? What happens to
your system when you use --deep? 

Why is it that despite --deep being recommended[1] and used (I assume)
by the majority of Gentoo users, I haven't heard of any ill effects of
using --deep? (You are the first and so far the only person to recommend
against it.)

I *always* use --deep when upgrading because then I am assured of
getting *all* of the dependencies of packages I am emerging. I am not
aware of *ever* having system problems due to using --deep. How do you
prevent packages from being installed that are missing dependencies?

Thanks.

--- Vladimir

[1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1

-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Slow redraw of windows following -uD --world

[reader]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:

> No, nvidia-glx is NOT the kernel module. That is nvidia-kernel!
>
> You don't have the latest nvidia drivers installed?
>
> That might be the culprit!
>
> emerge nvidia-kernel
> emergen nvidia-glx
> eselect opengl set nvidia (or opengl-update nvidia)
> change 'nv' in /etc/X11/xorg.conf to nvidia

OK this looks like a nice adventure but know one thing.  Before this
update I didn't have the nvidia-kernel either and redraw was fine.

So something else has happened ... eh?

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Slow redraw of windows following -uD --world

[reader]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:

> emergen nvidia-glx

OOPS:
emerge -vp nvidia-glx

Calculating dependencies... done!

[blocks B     ] >=x11-base/xorg-server-1.0.99 
   (is blocking media-video/nvidia-glx-1.0.8762)
 [ebuild  N    ] media-video/nvidia-glx-1.0.8762  
    USE="-dlloader" 0 kB 


So nvidia-glx replaces xorg-server?

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Using --deep

[reader]

"Vladimir G. Ivanovic" <vgivanovic@comcast.net> writes:

>> --deep is almost never needed. Some people love it and tell everybody to use 
>> it. Usually people who are version number freaks. But in 90% it is useless to 
>> harmfull.
>
> Could you be more specific, please? How is it harmful? What happens to
> your system when you use --deep? 
>
> Why is it that despite --deep being recommended[1] and used (I assume)
> by the majority of Gentoo users, I haven't heard of any ill effects of
> using --deep? (You are the first and so far the only person to recommend
> against it.)

Being the thread owner so to speak, I'd like to ask something of you
here.  The converse of your question.  How is it good.  

Can't speak for Hermman of course but I think he was suggesting that
somewhere `Deep' in the dependancies of something things got tangled
up and caused something to bread that has bearing on my `slow redraw' 
problem ending up with a need to revdep-rebuild to find the problems.

I still haven't seen what is at the root of my redraw problem and
haven't really heard any advice about how to debug it further.

I would like to hear both sides of this since you both are obviously
quite knowledgale about how gentoo works

> I *always* use --deep when upgrading because then I am assured of
> getting *all* of the dependencies of packages I am emerging. I am not
> aware of *ever* having system problems due to using --deep. How do you
> prevent packages from being installed that are missing dependencies?

I have been using --deep as a matter of course when upgrading and I
can say I have had system problems *absolutely every time* I've
upgraded.  And (Embarrassing given the sad state of my skill level)
but I've been running gentoo for something like 2 or more years .  

I don't know if the problems I've had are attributable to --deep in
any way, but I can say its likey to be at least in part due to ill
informed bumbling on my part.

The problems haven't always been big ones but there have always been
some requiring me to post here for advice.  Many were about the
tangled web of kde dependancies.

How would you recognize that a system problem was or was not
attributable to `--deep'?  Also isn't emerge supposed to find
dependancies as a default behavior?

In particular how can we determine what is wrong in my system causing
the slow redrawing of windows and slow scrolling.  Its getting
annoying enough that I'm thinkin about trashing this install and going
back to a stage install from snapshots and see if I still get this
slow redraw.

The revdep-rebuild that Hermman suggested did find problems with gcc
that I fixed by re emerging  it with USE="-gcj".  But apparently this
is not related to `slow redraw'.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Slow redraw of windows following -uD --world

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Fri, 16 Jun 2006 19:29:40 -0500, reader@newsguy.com wrote:

> Calculating dependencies... done!
> 
> [blocks B     ] >=x11-base/xorg-server-1.0.99 
>    (is blocking media-video/nvidia-glx-1.0.8762)
>  [ebuild  N    ] media-video/nvidia-glx-1.0.8762  
>     USE="-dlloader" 0 kB 
> 
> 
> So nvidia-glx replaces xorg-server?

No. The current nvidia drivers are incompatible with the new Xorg 7.1
API. If you want to use the nvidia drivers you have to mask xorg-server
>1.0.99 until Nvidia fix them, probably with the first 9xxx release.


-- 
Neil Bothwick

Microsoft is to Software as McDonalds is to Cuisine

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: Slow redraw of windows following -uD --world

[Hemmann, Volker Armin]

On Saturday 17 June 2006 02:29, reader@newsguy.com wrote:
> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:
> > emergen nvidia-glx
>
> OOPS:
> emerge -vp nvidia-glx
>
> Calculating dependencies... done!
>
> [blocks B     ] >=x11-base/xorg-server-1.0.99
>    (is blocking media-video/nvidia-glx-1.0.8762)
>  [ebuild  N    ] media-video/nvidia-glx-1.0.8762
>     USE="-dlloader" 0 kB
>
>
> So nvidia-glx replaces xorg-server?

nope, the 'newest' Xorg 7.1 had some incompatible ABI changes. And 
nvidia+latest X CAN result in missing fonts. There are ways to circumvent it.
Hm, have you unmasked any X stuff - or is everything over 7.0 unmasked already 
(if it is unmasked by the devs: why? 7.1 makes lots of troubles. Not smart. 
If it is unmasked by you, check your /etc/portage/package.mask)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Slow redraw of windows following -uD --world

[Hemmann, Volker Armin]

On Saturday 17 June 2006 02:25, reader@newsguy.com wrote:
> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:
> > No, nvidia-glx is NOT the kernel module. That is nvidia-kernel!
> >
> > You don't have the latest nvidia drivers installed?
> >
> > That might be the culprit!
> >
> > emerge nvidia-kernel
> > emergen nvidia-glx
> > eselect opengl set nvidia (or opengl-update nvidia)
> > change 'nv' in /etc/X11/xorg.conf to nvidia
>
> OK this looks like a nice adventure but know one thing.  Before this
> update I didn't have the nvidia-kernel either and redraw was fine.
>
> So something else has happened ... eh?

maybe. Maybe a fontconfig update, maybe a X update, maybe some other lib, X 
depends on was installed, that is slower than the old version.

But hardware acceleration is never wrong ;)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Hemmann, Volker Armin]

On Friday 16 June 2006 23:36, Vladimir G. Ivanovic wrote:
> On Fri, 2006-06-16 at 15:01 +0200, Hemmann, Volker Armin wrote:
> > --deep is almost never needed. Some people love it and tell everybody to
> > use it. Usually people who are version number freaks. But in 90% it is
> > useless to harmfull.
>
> Could you be more specific, please? How is it harmful? What happens to
> your system when you use --deep?

because sometimes a lib/dependency may be upgraded to an incompatible version, 
resulting in open and hidden breakage.

>
> Why is it that despite --deep being recommended[1] and used (I assume)
> by the majority of Gentoo users, I haven't heard of any ill effects of
> using --deep? (You are the first and so far the only person to recommend
> against it.)

IT IS NOT RECOMMENDED!
Read again!

Code Listing 13: Updating your system
  # emerge --update --ask world

owever, it will only verify the versions for the applications you have 
explicitly installed - not the dependencies. If you want to update every 
single package on your system, add the --deep argument: 

So it only says 'if you want to update everything' not 'we recommend it'.

Oh, and it says 'sometimes to catch security updates'. Not 'everytime you 
update'.

You can catch the security updates by being on the gentoo-announce mailing 
list. No need for --deep.

>
> I *always* use --deep when upgrading because then I am assured of
> getting *all* of the dependencies of packages I am emerging. I am not
> aware of *ever* having system problems due to using --deep. How do you
> prevent packages from being installed that are missing dependencies?

I don't prevent packages installed with missing deps. Portage does this.

You don't need --deep to 'Get all dependencies' portage will does that for 
you. --deep upgrades everything in your system,which is totally different 
from dependency solution and might break stuff, because a dependency might 
get upgraded to an incompatible version.

I am using gentoo since 1.0

And for some time, I used --deep. Until I got A LOT of breakage. KDE here, 
enlightenment there, XFCE too, this game started to be crashy, that 
application did not show jpegs/gifs/png anymore and so on and so forth.

I have seen the damage --deep can do first hand, and I strongly recommend not 
to use it.

Security updates - that is what gentoo-announce is for.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Slow redraw of windows following -uD --world

[Pavel Kouřil]

Hemmann, Volker Armin wrote:
> On Saturday 17 June 2006 02:29, reader@newsguy.com wrote:
>   
>> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:
>>     
>>> emergen nvidia-glx
>>>       
>> OOPS:
>> emerge -vp nvidia-glx
>>
>> Calculating dependencies... done!
>>
>> [blocks B     ] >=x11-base/xorg-server-1.0.99
>>    (is blocking media-video/nvidia-glx-1.0.8762)
>>  [ebuild  N    ] media-video/nvidia-glx-1.0.8762
>>     USE="-dlloader" 0 kB
>>
>>
>> So nvidia-glx replaces xorg-server?
>>     
>
> nope, the 'newest' Xorg 7.1 had some incompatible ABI changes. And 
> nvidia+latest X CAN result in missing fonts. There are ways to circumvent it.
> Hm, have you unmasked any X stuff - or is everything over 7.0 unmasked already 
> (if it is unmasked by the devs: why? 7.1 makes lots of troubles. Not smart. 
> If it is unmasked by you, check your /etc/portage/package.mask
>   
I answered in the `[gentoo-user]  remove xorg-server to emerge
nvidia-glx <=Normal?' There's a link on packages.mask, what will solve
your problem 
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Using --deep

[Vladimir G. Ivanovic]

On Fri, 2006-06-16 at 22:08 -0500, reader@newsguy.com wrote:

> Being the thread owner so to speak, I'd like to ask something of you
> here.  The converse of your question.  How is it good.  

--deep catches dependencies of dependencies.
> 
> Can't speak for Hermman of course but I think he was suggesting that
> somewhere `Deep' in the dependancies of something things got tangled
> up and caused something to bread that has bearing on my `slow redraw' 
> problem ending up with a need to revdep-rebuild to find the problems.

I manually re-emerge any packages identified by
        emerge -av --depclean
and then I fix whatever 
        revdep-rebuild -av
complains about. I do this after deep updates (usually). I have not run
into package dependency-related problems.

> 
> I still haven't seen what is at the root of my redraw problem and
> haven't really heard any advice about how to debug it further.
> 
> I would like to hear both sides of this since you both are obviously
> quite knowledgale about how gentoo works
> 
> > I *always* use --deep when upgrading because then I am assured of
> > getting *all* of the dependencies of packages I am emerging. I am not
> > aware of *ever* having system problems due to using --deep. How do you
> > prevent packages from being installed that are missing dependencies?
> 
> I have been using --deep as a matter of course when upgrading and I
> can say I have had system problems *absolutely every time* I've
> upgraded.  And (Embarrassing given the sad state of my skill level)
> but I've been running gentoo for something like 2 or more years .  
> 
> I don't know if the problems I've had are attributable to --deep in
> any way, but I can say its likey to be at least in part due to ill
> informed bumbling on my part.
> 
> The problems haven't always been big ones but there have always been
> some requiring me to post here for advice.  Many were about the
> tangled web of kde dependancies.

I do not see this and I have kde-meta installed.

> 
> How would you recognize that a system problem was or was not
> attributable to `--deep'?  Also isn't emerge supposed to find
> dependancies as a default behavior?

See above.

> 
> In particular how can we determine what is wrong in my system causing
> the slow redrawing of windows and slow scrolling.  Its getting
> annoying enough that I'm thinkin about trashing this install and going
> back to a stage install from snapshots and see if I still get this
> slow redraw.

I ran glxgears recently, and I was shocked to see how slowly they
turned. (I'm getting ~500 FPS.) I remember the gears turning much, much
faster. Perhaps my upgrade to xorg 7.0 has something to do with it.

But, regardless, I don't think slow GLX is due to emerging problems
caused by using --deep.  I may have misconfigured a package, or
installed something that I shouldn't, but my dependencies are not out of
whack.

> 
> The revdep-rebuild that Hermman suggested did find problems with gcc
> that I fixed by re emerging  it with USE="-gcj".  But apparently this
> is not related to `slow redraw'.
> 

--- Vladimir 

-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

On Sat, 17 Jun 2006 10:53:17 +0200, Hemmann, Volker Armin wrote:

> > Could you be more specific, please? How is it harmful? What happens to
> > your system when you use --deep?
> 
> because sometimes a lib/dependency may be upgraded to an incompatible
> version, resulting in open and hidden breakage.

If the later version is incompatible with installed software, that
software should block the update. this behaviour indicates a broken
ebuild.

The main risk with using deep, particularly on a ~arch system, is that
you get the updates when they come out, instead of waiting until they
are needed. not using deep lets others hit the problems and get them
sorted out before you need an update.

> Code Listing 13: Updating your system
>   # emerge --update --ask world
> 
> owever, it will only verify the versions for the applications you have 
> explicitly installed - not the dependencies. If you want to update
> every single package on your system, add the --deep argument: 

That's wrong.

"emerge package" checks only the package.

"emerge --update package" check package and any first-level dependencies
and updates them all. Even if package has not been updated, if a
first-level dependency has, it will be installed. First level
dependencies are those listed in the package's ebuild.

"emerge --update --deep package" follows the complete dependency tree for
package.

Even "emerge --update --deep world" may not update everything. If a
package is not in your world file, nor a dependency of something in your
world file, it will not be updated.

> Oh, and it says 'sometimes to catch security updates'. Not 'everytime
> you update'.
> 
> You can catch the security updates by being on the gentoo-announce
> mailing list. No need for --deep.

Or by running "glsa-check --test all" every time you sync or from a cron
task.


-- 
Neil Bothwick

QOTD:
	The only easy way to tell a hamster from a gerbil is that the
	gerbil has more dark meat.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

On Saturday 17 June 2006 14:17, Neil Bothwick wrote:
> First level
> dependencies are those listed in the package's ebuild.

Or listed in any eclasses that the ebuild inherits.

-- 
Bo Andresen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Michael Weyershäuser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hemmann, Volker Armin wrote:
> 
> IT IS NOT RECOMMENDED!
> Read again!

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 says:

> Since security updates also happen in packages you have not explicitly 
> installed on your system (but that are pulled in as dependencies of
> other programs), it is recommended to run this command once in a
> while.

Funny, I can quite clearly see the word "recommended".

> 
> You can catch the security updates by being on the gentoo-announce mailing 
> list. No need for --deep.
> 

Not every security update gets a GLSA on gentoo-announce. And then there
are the many non-security bugfixes in every new release of a program. So
if you just want to keep your system up-to-date you should use --deep. I
am not using Gentoo as long as you do, but in a good two years on
several machines I haven't had problems that I could trace back to the
usage of --deep. Sure, you get your part of ABI breakages, but hey,
that's the price you have to pay for using a source-based distro. And
you usually get a warning in form of an einfo...


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFElAtW6q4f+IV6B/wRAnByAJ4rRXMpx/iShQWNmLRoOPxqkuBK/ACdFSIz
17IT5up7F/cR3o5vLcPYnZk=
=t4ih
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Hemmann, Volker Armin]

On Saturday 17 June 2006 16:01, Michael Weyershäuser wrote:
> Hemmann, Volker Armin wrote:
> > IT IS NOT RECOMMENDED!
> > Read again!
>
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 says:
> > Since security updates also happen in packages you have not explicitly
> > installed on your system (but that are pulled in as dependencies of
> > other programs), it is recommended to run this command once in a
> > while.
>
> Funny, I can quite clearly see the word "recommended".
>

yes, but it does not say 'everytime you update' but 'once in a while'.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Vladimir G. Ivanovic]

On Sat, 2006-06-17 at 16:11 +0200, Hemmann, Volker Armin wrote:
> On Saturday 17 June 2006 16:01, Michael Weyershäuser wrote:
> > Hemmann, Volker Armin wrote:
> > > IT IS NOT RECOMMENDED!
> > > Read again!
> >
> > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 says:
> > > Since security updates also happen in packages you have not explicitly
> > > installed on your system (but that are pulled in as dependencies of
> > > other programs), it is recommended to run this command once in a
> > > while.
> >
> > Funny, I can quite clearly see the word "recommended".
> >
> 
> yes, but it does not say 'everytime you update' but 'once in a while'.
> 

Are you saying that it's OK to use --deep every now and then, but
terrible things happen if you run it all the time?

If you believe that --deep is broken, file a bug so it can get fixed.

--- Vladiimr

-- 
Vladimir G. Ivanovic <vgivanovic@comcast.net>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On Sat, 17 Jun 2006 15:36:51 -0700, Vladimir G. Ivanovic wrote:

> If you believe that --deep is broken, file a bug so it can get fixed.

--deep is no more broken than rm. Both are tools that do exactly what you
tells them to do. If that is not what you wanted them to do, the fault
lies with the user, not the tool. There is no good and bad about using
--deep, only about using it inappropriately. Telling people never to use
--deep is as misleading as telling them always to use it. The only
correct advice is to help people decide for themselves when to use it and
when not.


-- 
Neil Bothwick

Despite the cost of living, have you noticed how it remains so popular?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Benno Schulenberg]

Neil Bothwick wrote:
> Telling people never to use --deep is as misleading as telling
> them always to use it. The only correct advice is to help people
> decide for themselves when to use it and when not.

Hmm.  When to use it then, and when not?  Either the user follows 
gentoo-announce and runs the adviced emerges manually, without ever 
using --deep; or she uses --deep on a regular basis and can't see 
the difference between a security update and a normal bugfix.

It would be better if emerge could somehow show this difference with 
a ! or something.  Because running 'emerge --deep --changelog -u 
world -p' produces too much irrelevant information to be useful.  
And glsa-check is a bit unwieldy: 'glsa-check -ln 2>/dev/null | 
grep '\[N\]' | cut -d\  -f1 | xargs -n1 glsa-check -d'.  Plus, the 
results can be confusing as it thinks mplayer-1.0.20060415 is newer 
than mplayer-1.0_pre8.

Benno
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

On Sun, 18 Jun 2006 14:12:11 +0200, Benno Schulenberg wrote:

> And glsa-check is a bit unwieldy: 'glsa-check -ln 2>/dev/null | 
> grep '\[N\]' | cut -d\  -f1 | xargs -n1 glsa-check -d'.

What's wrong with 'glsa-check -t all'? Then investigate any GLSA numbers
it reports.

> Plus, the 
> results can be confusing as it thinks mplayer-1.0.20060415 is newer 
> than mplayer-1.0_pre8.

Yeah, the screwed up MPlayer version numbering keeps nagging me too :(


-- 
Neil Bothwick

If a book about failures doesn't sell, is it a success?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Benno Schulenberg]

Neil Bothwick wrote:
> On Sun, 18 Jun 2006 14:12:11 +0200, Benno Schulenberg wrote:
> > And glsa-check is a bit unwieldy: 'glsa-check -ln 2>/dev/null |
> > grep '\[N\]' | cut -d\  -f1 | xargs -n1 glsa-check -d'.
>
> What's wrong with 'glsa-check -t all'?

Ah.  I didn't know about "all".  I've used glsa-check just once or 
twice, saw the enormous list of all greens, and never looked again.

> Then investigate any GLSA numbers it reports.

Too much typing.  :)  It should have an option to directly list 
these numbers in full -- at least the Synopsis to Unaffected part.  
(Anyone good enough at sed or awk to produce such an extract from a 
glsa-check -d output?)  Numbers alone say nothing.

Benno
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

On Sun, 18 Jun 2006 16:00:18 +0200, Benno Schulenberg wrote:

> > Then investigate any GLSA numbers it reports.
> 
> Too much typing.  :)  It should have an option to directly list 
> these numbers in full -- at least the Synopsis to Unaffected part.  
> (Anyone good enough at sed or awk to produce such an extract from a 
> glsa-check -d output?)  Numbers alone say nothing.

glsa-check -t all | xargs -r glsa-check -d


-- 
Neil Bothwick

Compatible: Gracefully accepts erroneous data from any source.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Benno Schulenberg]

Neil Bothwick wrote:
> On Sun, 18 Jun 2006 16:00:18 +0200, Benno Schulenberg wrote:
> > It should have an option to directly list
> > these numbers in full -- at least the Synopsis to Unaffected
> > part. (Anyone good enough at sed or awk to produce such an
> > extract from a glsa-check -d output?)  Numbers alone say
> > nothing.
>
> glsa-check -t all | xargs -r glsa-check -d

Yes, but now only the Synopsis to Unaffected part.  Demanding, 
aren't we?  :)

I've aliased this: `glsa-check -t all | while read number; do 
echo =====; echo; glsa-check -d $number | grep -B88 Unaffected | 
grep --color=always -A88 Synopsis; echo; done'.

Benno
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Using --deep [Was: Slow redraw of windows following -uD --world]

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

On Sun, 18 Jun 2006 21:37:55 +0200, Benno Schulenberg wrote:

> I've aliased this: `glsa-check -t all | while read number; do 
> echo =====; echo; glsa-check -d $number | grep -B88 Unaffected | 
> grep --color=always -A88 Synopsis; echo; done'.

Neat :)


-- 
Neil Bothwick

The severity of the itch is inversely proportional to the reach.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]