Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On 12/11/2008, Volker Armin Hemmann [EMAIL PROTECTED] wrote: as root: lspci Why as root? I get exactly the same output when I run it as my own user as when I run it as root. Or have I got my system set up different to everyone else? Dan
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Thursday 13 November 2008 23:05:09 Dan Wallis wrote: On 12/11/2008, Volker Armin Hemmann [EMAIL PROTECTED] wrote: as root: lspci Why as root? I get exactly the same output when I run it as my own user as when I run it as root. Or have I got my system set up different to everyone else? It means you have /usr/sbin/ in your regular user's PATH -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Thu, Nov 13, 2008 at 7:05 PM, Dan Wallis [EMAIL PROTECTED] wrote:
On 12/11/2008, Volker Armin Hemmann
[EMAIL PROTECTED] wrote:
as root: lspci
Why as root? I get exactly the same output when I run it as my own
user as when I run it as root. Or have I got my system set up
different to everyone else?
$ lspci
bash: lspci: command not found
echo ${PATH}
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.2:/opt/sun-jre-bin-1.5.0.06/bin:/opt/sun-jre-bin-1.5.0.06/javaws:/usr/games/bin
At least in my system, the lspci binary resides in /usr/sbin, which is
not in ${PATH}
So you should either call lspci as root or issue the explicit command
/usr/sbin/lspci
That said, if you want to use the -v flag of lspci (for extra
verbosity), you should be root, or you will see some fields filled
with access denied
--
Software is like sex: it is better when it is free - Linus Torvalds
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Thursday 13 November 2008, Dan Wallis wrote: On 12/11/2008, Volker Armin Hemmann [EMAIL PROTECTED] wrote: as root: lspci Why as root? I get exactly the same output when I run it as my own user as when I run it as root. Or have I got my system set up different to everyone else? maybe, I don't have /usr/sbin in my PATH. Also as root you get a bit more information.
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On 13/11/2008, Jorge Peixoto de Morais Neto
[EMAIL PROTECTED] wrote:
On Thu, Nov 13, 2008 at 7:05 PM, Dan Wallis [EMAIL PROTECTED] wrote:
On 12/11/2008, Volker Armin Hemmann
[EMAIL PROTECTED] wrote:
as root: lspci
Why as root? I get exactly the same output when I run it as my own
user as when I run it as root. Or have I got my system set up
different to everyone else?
$ lspci
bash: lspci: command not found
echo ${PATH}
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.2:/opt/sun-jre-bin-1.5.0.06/bin:/opt/sun-jre-bin-1.5.0.06/javaws:/usr/games/bin
At least in my system, the lspci binary resides in /usr/sbin, which is
not in ${PATH}
So you should either call lspci as root or issue the explicit command
/usr/sbin/lspci
Yes, I do have that directory in my PATH.
That said, if you want to use the -v flag of lspci (for extra
verbosity), you should be root, or you will see some fields filled
with access denied
Thanks for the tip; I didn't know about the verbose flag. It looks
like that'll come in useful when I do my next build in a few weeks.
Thanks
Dan
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Thursday 13 November 2008, Dan Wallis wrote:
On 13/11/2008, Jorge Peixoto de Morais Neto
[EMAIL PROTECTED] wrote:
On Thu, Nov 13, 2008 at 7:05 PM, Dan Wallis [EMAIL PROTECTED] wrote:
On 12/11/2008, Volker Armin Hemmann
[EMAIL PROTECTED] wrote:
as root: lspci
Why as root? I get exactly the same output when I run it as my own
user as when I run it as root. Or have I got my system set up
different to everyone else?
$ lspci
bash: lspci: command not found
echo ${PATH}
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.
2:/opt/sun-jre-bin-1.5.0.06/bin:/opt/sun-jre-bin-1.5.0.06/javaws:/usr/game
s/bin At least in my system, the lspci binary resides in /usr/sbin, which
is not in ${PATH}
So you should either call lspci as root or issue the explicit command
/usr/sbin/lspci
Yes, I do have that directory in my PATH.
That said, if you want to use the -v flag of lspci (for extra
verbosity), you should be root, or you will see some fields filled
with access denied
Thanks for the tip; I didn't know about the verbose flag. It looks
like that'll come in useful when I do my next build in a few weeks.
not really. For an enduser --verbose isn't very helpfull.
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Fri, Nov 14, 2008 at 12:38 AM, Volker Armin Hemmann
[EMAIL PROTECTED] wrote:
On Thursday 13 November 2008, Dan Wallis wrote:
On 13/11/2008, Jorge Peixoto de Morais Neto
[EMAIL PROTECTED] wrote:
On Thu, Nov 13, 2008 at 7:05 PM, Dan Wallis [EMAIL PROTECTED] wrote:
On 12/11/2008, Volker Armin Hemmann
[EMAIL PROTECTED] wrote:
as root: lspci
Why as root? I get exactly the same output when I run it as my own
user as when I run it as root. Or have I got my system set up
different to everyone else?
$ lspci
bash: lspci: command not found
echo ${PATH}
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.
2:/opt/sun-jre-bin-1.5.0.06/bin:/opt/sun-jre-bin-1.5.0.06/javaws:/usr/game
s/bin At least in my system, the lspci binary resides in /usr/sbin, which
is not in ${PATH}
So you should either call lspci as root or issue the explicit command
/usr/sbin/lspci
Yes, I do have that directory in my PATH.
That said, if you want to use the -v flag of lspci (for extra
verbosity), you should be root, or you will see some fields filled
with access denied
Thanks for the tip; I didn't know about the verbose flag. It looks
like that'll come in useful when I do my next build in a few weeks.
not really. For an enduser --verbose isn't very helpfull.
Don't know if I qualify as an end-user, but I find:
Kernel driver in use:
very usefull.
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Dirk Uys wrote: On Fri, Nov 14, 2008 at 12:38 AM, Volker Armin Hemmann [EMAIL PROTECTED] wrote: not really. For an enduser --verbose isn't very helpfull. Don't know if I qualify as an end-user, but I find: Kernel driver in use: very usefull. I noticed that too. That is VERY cool. Would be really cool when booting from the CD during a install. Really easy to figure out what drivers to put in the kernel for unknown hardware. Dale :-) :-)
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Freitag 14 November 2008, Dirk Uys wrote:
On Fri, Nov 14, 2008 at 12:38 AM, Volker Armin Hemmann
[EMAIL PROTECTED] wrote:
On Thursday 13 November 2008, Dan Wallis wrote:
On 13/11/2008, Jorge Peixoto de Morais Neto
[EMAIL PROTECTED] wrote:
On Thu, Nov 13, 2008 at 7:05 PM, Dan Wallis [EMAIL PROTECTED]
wrote:
On 12/11/2008, Volker Armin Hemmann
[EMAIL PROTECTED] wrote:
as root: lspci
Why as root? I get exactly the same output when I run it as my own
user as when I run it as root. Or have I got my system set up
different to everyone else?
$ lspci
bash: lspci: command not found
echo ${PATH}
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4
.1.
2:/opt/sun-jre-bin-1.5.0.06/bin:/opt/sun-jre-bin-1.5.0.06/javaws:/usr/
game s/bin At least in my system, the lspci binary resides in
/usr/sbin, which is not in ${PATH}
So you should either call lspci as root or issue the explicit command
/usr/sbin/lspci
Yes, I do have that directory in my PATH.
That said, if you want to use the -v flag of lspci (for extra
verbosity), you should be root, or you will see some fields filled
with access denied
Thanks for the tip; I didn't know about the verbose flag. It looks
like that'll come in useful when I do my next build in a few weeks.
not really. For an enduser --verbose isn't very helpfull.
Don't know if I qualify as an end-user, but I find:
Kernel driver in use:
very usefull.
ok, I know my hardware well enough for that ;)
[gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Dan Wallis [EMAIL PROTECTED] writes: The blocks regarding sys-fs/e2fsprogs, sys-libs/e2fsprogs-libs, sys-libs/ss and sys-libs/com_err were discussed recently on this list. Basically you need to: emerge -f e2fsprogs e2fsprogs-libs emerge -C com_err ss e2fsprogs emerge -1 e2fsprogs I'm not sure about the others, but fixing these should get you closer to an up-to-date system. :) That did clean those up... thanks
[gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Volker Armin Hemmann [EMAIL PROTECTED] writes: [...] Many thanks for the other useful info I've snipped [blocks b ] x11-drivers/xf86-video-nsc (x11-drivers/xf86-video-nsc is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-vga (x11-drivers/xf86-video-vga is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-imstt (x11-drivers/xf86-video-imstt is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-cyrix and you need all the videodrivers? I am sure not. So remove them and set VIDEO_CARDS in makec.conf. A light just went off over my head. For mnths, maybe yrs... I've wondered why so many x11 drivers would get installed. OK, but a quick google on `site:gentoo.org VIDEO_CARDS' didn't turn up a way to determine what card is on the machine. At least not a recognizable hit I can see is about that. I'm pretty sure I can get that info without opening the cover but I'm drawing blanks about how.
[gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Dirk Heinrichs [EMAIL PROTECTED] writes: [...] thanks for the other useful info I've snipped 4) update world with the ignore blocks option turned on (don't know which that is, since I use paludis). a quick grep of man emerge and man portage on `ignore' and on `block' didn't turn up such an option. I am updated to latest portage (sys-apps/portage-2.2_rc14)
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Am Mittwoch, 12. November 2008 20:11:33 schrieb Harry Putnam: a quick grep of man emerge and man portage on `ignore' and on `block' didn't turn up such an option. As I said, I use paludis. I was only told that emerge also has this option, just last week (or was it the week before?) on this list. Bye... Dirk
[gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Dirk Heinrichs [EMAIL PROTECTED] writes: Am Mittwoch, 12. November 2008 20:11:33 schrieb Harry Putnam: a quick grep of man emerge and man portage on `ignore' and on `block' didn't turn up such an option. As I said, I use paludis. I was only told that emerge also has this option, just last week (or was it the week before?) on this list. Sorry, didn't mean to jam you about it... I posted the grep info hoping someone else would insert some info about it... thanks again.
[gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Harry Putnam [EMAIL PROTECTED] writes: and you need all the videodrivers? I am sure not. So remove them and set VIDEO_CARDS in makec.conf. A light just went off over my head. For mnths, maybe yrs... I've wondered why so many x11 drivers would get installed. OK, but a quick google on `site:gentoo.org VIDEO_CARDS' didn't turn up a way to determine what card is on the machine. At least not a recognizable hit I can see is about that. I'm pretty sure I can get that info without opening the cover but I'm drawing blanks about how. Never mind. lspci is my friend
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Mittwoch 12 November 2008, Harry Putnam wrote: Dirk Heinrichs [EMAIL PROTECTED] writes: [...] thanks for the other useful info I've snipped 4) update world with the ignore blocks option turned on (don't know which that is, since I use paludis). a quick grep of man emerge and man portage on `ignore' and on `block' didn't turn up such an option. I am updated to latest portage (sys-apps/portage-2.2_rc14) you don't need that option. There is no option. It just works.
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Mittwoch 12 November 2008, Harry Putnam wrote: Volker Armin Hemmann [EMAIL PROTECTED] writes: [...] Many thanks for the other useful info I've snipped [blocks b ] x11-drivers/xf86-video-nsc (x11-drivers/xf86-video-nsc is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-vga (x11-drivers/xf86-video-vga is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-imstt (x11-drivers/xf86-video-imstt is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-cyrix and you need all the videodrivers? I am sure not. So remove them and set VIDEO_CARDS in makec.conf. A light just went off over my head. For mnths, maybe yrs... I've wondered why so many x11 drivers would get installed. OK, but a quick google on `site:gentoo.org VIDEO_CARDS' didn't turn up a way to determine what card is on the machine. At least not a recognizable hit I can see is about that. I'm pretty sure I can get that info without opening the cover but I'm drawing blanks about how. as root: lspci
[gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Andrey Falko [EMAIL PROTECTED] writes: lspci should show you what video card you have. Look for VGA or something like that. For example on my system: Thanks... I didn't see your post in time and posted a never mind after banging away with google and unearthing that info.
[gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Dirk Heinrichs [EMAIL PROTECTED] writes: From the output you gave, I would suggest that you 1) update portage to the latest (evantually keyword masked) version. This should be able to ignore blocks. 2) Adjust your VIDEO_CARDS, I don't think you have that many cards plugged into your machine. 3) There seem to be blocks between monolithic and splitted kde/qt (kde*-meta) ebuilds. Decide which ones to use and remove the others. qt you need to eventually update separatedly, i.e. emerge qt. 4) update world with the ignore blocks option turned on (don't know which that is, since I use paludis). 5) emerge --depclean (-p) to remove the cruft. What if I ran the --depclean before updating world. Would that help me get rid of some junk before updating it with `world'?
[gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Volker Armin Hemmann [EMAIL PROTECTED] writes: Just install the latest portage. It has a block breaking function. Then upgrade e2fsprogs like described a few douzend times on this ml and in the forums. Remove all the acient video drivers you don't need anyway. After that, most blocks should be gone. Got that part fixed what about this: From emerge -vuDNpt system [...] [nomerge ] x11-base/xorg-server-1.5.2 [1.4.2] [nomerge ] x11-libs/libpciaccess-0.10.5 USE=-debug -minimal [0] [blocks b ]x11-base/xorg-server-1.5 (x11-base/xorg-server-1.5 is blocking x11-libs/libpciaccess-0.10.5) [ebuild U ] x11-base/xorg-server-1.5.2 [1.4.2] [ebuild N] x11-libs/libpciaccess-0.10.5 USE=-debug [...] I may have trimmed that down too much .. there was a very long line of stuff after the xorg-server entries. I tried installed emerge -v x11-base/xorg-server and x11-libs/libpciaccess separately by themselves without the -uDN part but that fails too. Not too easy to see how to get around this.
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Mittwoch 12 November 2008, Harry Putnam wrote: Dirk Heinrichs [EMAIL PROTECTED] writes: From the output you gave, I would suggest that you 1) update portage to the latest (evantually keyword masked) version. This should be able to ignore blocks. 2) Adjust your VIDEO_CARDS, I don't think you have that many cards plugged into your machine. 3) There seem to be blocks between monolithic and splitted kde/qt (kde*-meta) ebuilds. Decide which ones to use and remove the others. qt you need to eventually update separatedly, i.e. emerge qt. 4) update world with the ignore blocks option turned on (don't know which that is, since I use paludis). 5) emerge --depclean (-p) to remove the cruft. What if I ran the --depclean before updating world. Would that help me get rid of some junk before updating it with `world'? no, it would completly fuck up your system.
[gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Volker Armin Hemmann [EMAIL PROTECTED] writes: Just install the latest portage. It has a block breaking function. Then upgrade e2fsprogs like described a few douzend times on this ml and in the forums. Remove all the acient video drivers you don't need anyway. After that, most blocks should be gone. Thanks again, and it appears to be working with at least `system' at this moment. After cleaning up the x11 drivers, and emerge -C 7-8 things I really don't need anymore. Even with a blocker in there, the emerge is running along just like you said it would nice. Hopefully the world part may be as easy too. I was really reluctant to take too this mess but with yours, Andreys', Dirks', Marks' and Dans' input it appears I may get this done by tomorrow. All and all, much easier than my first thought of building up a fresh gentoo install somewhere else and using that to overwrite my current install.
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Am Mittwoch, 12. November 2008 21:36:24 schrieb Volker Armin Hemmann: On Mittwoch 12 November 2008, Harry Putnam wrote: What if I ran the --depclean before updating world. Would that help me get rid of some junk before updating it with `world'? no, it would completly fuck up your system. ??? Bye... Dirk
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
Am Mittwoch, 12. November 2008 20:20:40 schrieb Harry Putnam: As I said, I use paludis. I was only told that emerge also has this option, just last week (or was it the week before?) on this list. Sorry, didn't mean to jam you about it... Oh, I didn't understand it as such, just wanted to clarify. Bye... Dirk
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Wednesday 12 November 2008 22:23:33 Harry Putnam wrote: Volker Armin Hemmann [EMAIL PROTECTED] writes: Just install the latest portage. It has a block breaking function. Then upgrade e2fsprogs like described a few douzend times on this ml and in the forums. Remove all the acient video drivers you don't need anyway. After that, most blocks should be gone. Got that part fixed what about this: From emerge -vuDNpt system [...] [nomerge ] x11-base/xorg-server-1.5.2 [1.4.2] [nomerge ] x11-libs/libpciaccess-0.10.5 USE=-debug -minimal [0] [blocks b ]x11-base/xorg-server-1.5 (x11-base/xorg-server-1.5 is blocking x11-libs/libpciaccess-0.10.5) [ebuild U ] x11-base/xorg-server-1.5.2 [1.4.2] [ebuild N] x11-libs/libpciaccess-0.10.5 USE=-debug [...] I may have trimmed that down too much .. there was a very long line of stuff after the xorg-server entries. I tried installed emerge -v x11-base/xorg-server and x11-libs/libpciaccess separately by themselves without the -uDN part but that fails too. Not too easy to see how to get around this. I think this is what you want: quickpkg xorg-server emerge -C xorg-server emerge xorg-server -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Wed, 12 Nov 2008 20:15:33 +0100, Dirk Heinrichs wrote: a quick grep of man emerge and man portage on `ignore' and on `block' didn't turn up such an option. As I said, I use paludis. I was only told that emerge also has this option, just last week (or was it the week before?) on this list. I don't think it has such an option, but it does handle blocks much better, automatically resolving many of them, including the recent e2fsprogs one. That's not ignoring blocks but dealing with them. -- Neil Bothwick Intel Inside Is a Government Warning Required by Law. signature.asc Description: PGP signature
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Wed, 12 Nov 2008 14:23:33 -0600, Harry Putnam wrote: Got that part fixed what about this: From emerge -vuDNpt system [...] [nomerge ] x11-base/xorg-server-1.5.2 [1.4.2] [nomerge ] x11-libs/libpciaccess-0.10.5 USE=-debug -minimal [0] [blocks b ]x11-base/xorg-server-1.5 (x11-base/xorg-server-1.5 is blocking x11-libs/libpciaccess-0.10.5) [ebuild U ] x11-base/xorg-server-1.5.2 [1.4.2] [ebuild N] x11-libs/libpciaccess-0.10.5 USE=-debug There's nothing to fix, just let the emerge proceed. The docs aren't clear on this, but my experience with the newer portage is that a block marked with a b will be resolved by portage, a B block is a more serious problem. -- Neil Bothwick If you hear an Onion ring, please answer it! signature.asc Description: PGP signature
Re: [gentoo-user] Re: How to fix a hefty (emerge) blocking problem
On Wed, Nov 12, 2008 at 11:05 AM, Harry Putnam [EMAIL PROTECTED] wrote: Volker Armin Hemmann [EMAIL PROTECTED] writes: [...] Many thanks for the other useful info I've snipped [blocks b ] x11-drivers/xf86-video-nsc (x11-drivers/xf86-video-nsc is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-vga (x11-drivers/xf86-video-vga is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-imstt (x11-drivers/xf86-video-imstt is blocking x11-base/xorg-server-1.5.2) [blocks b ] x11-drivers/xf86-video-cyrix and you need all the videodrivers? I am sure not. So remove them and set VIDEO_CARDS in makec.conf. A light just went off over my head. For mnths, maybe yrs... I've wondered why so many x11 drivers would get installed. OK, but a quick google on `site:gentoo.org VIDEO_CARDS' didn't turn up a way to determine what card is on the machine. At least not a recognizable hit I can see is about that. I'm pretty sure I can get that info without opening the cover but I'm drawing blanks about how. lspci should show you what video card you have. Look for VGA or something like that. For example on my system: 01:00.0 VGA compatible controller: nVidia Corporation NV44 [Quadro NVS 285] (rev a1) So for me, I'd use either the nv or nvidia driver. Also, don't you have a video card section in xorg.conf? If you are using vesa or something then put that into your VIDEO_CARDS var.
