Re: [gentoo-user] Switching to unstable
Am Sun, 11 Apr 2010 17:13:26 -0700 schrieb Mark Knecht markkne...@gmail.com: On Sun, Apr 11, 2010 at 5:00 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 11 Apr 2010 16:11:53 -0700, Mark Knecht wrote: Doing system first makes good sense. Then you can update your config files, follow the openrc update etc and then reboot. The world part of the update will take quite a while, especially if you use KDE or GNOME. hehe Less than most PC. It's an i7-980x with 24GB of RAM with RAID1. Gah, I'm getting PC envy ;-) ! A couple of packages in this OpenRC upgrade aren't building. I hope they are less important. So far groff and help2man have failed so I did --resume --skip-first and moved on for now. Just a note: you can also specify --keep-going and portage will do that for you and even recalculate the dependencies before continuing. After it's done, it gives you a message listing the packages that failed. Thanks, Mark HTH -- Marc Joliet -- Lt. Frank Drebin: It's true what they say: cops and women don't mix. Like eating a spoonful of Drāno; sure, it'll clean you out, but it'll leave you hollow inside. signature.asc Description: PGP signature
[gentoo-user] wlan0 config questions
Here's /etc/conf.d/net on my Gentoo netbook system... config_eth0=192.168.123.249 broadcast 192.168.123.255 netmask 255.255.255.248 mtu 1452 routes_eth0=( default via 192.168.123.254 metric 2 192.168.123.248/29 via 192.168.123.254 metric 0 ) The multiple routes allow eth0 to remain connected to my router and talk to the other machine on the lan while running a dialup connection. I want to try out my netbook wifi, and I find that it works too well!!! Here's the output after starting up wlan0. The ESSID and MAC address of my neighbours in the condo have been masked to protect the innocent... aa1 init.d # /etc/init.d/net.wlan0 restart * Stopping wlan0 * Bringing down wlan0 * Stopping dhcpcd on wlan0 ... [ ok ] * Shutting down wlan0 ...[ ok ] * Starting wlan0 * Configuring wireless network for wlan0 * WEP key is not set for KGB zone** keep OFF** - not connecting * wlan0 connected to ESSID *** at **:**:**:**:**:** * in managed mode on channel 6 (WEP disabled) * Configuration not set for wlan0 - assuming DHCP * Bringing up wlan0 * dhcp * Running dhcpcd ... wlan0: dhcpcd 4.0.15 starting wlan0: broadcasting for a lease wlan0: offered 192.168.0.103 from 192.168.0.1 wlan0: ignoring offer of 192.168.0.103 from 192.168.0.1 wlan0: acknowledged 192.168.0.103 from 192.168.0.1 wlan0: checking 192.168.0.103 is available on attached networks wlan0: leased 192.168.0.103 for 604800 seconds [ ok ] * wlan0 received address 192.168.0.103/24 After picking my jaw off the floor, I downed wlan0. Just to be safe, I ran rmmod ath5k. I want to be able to scan available connections and then select which one I want, e.g. I want to try it at the local public library. I do not like the concept of the netbook automatically connecting to the first available access point. What do I have to do to *NOT* connect automatically? -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] can't get accelerated opengl renderer ati radeon xpress 200M
On Sat, Apr 10, 2010 at 11:31 PM, Gregory Shearman zek...@gmail.com wrote: Why are libX11-xcb.so.1, libX11.so.6, libdrm.so.2 in the /opt/gfx-test/lib directory rather than in /usr/lib as they are on my machine? Sorry about that, this /opt/gfx-test/ directory was something I created to test a hand compiled X stack. It shouldn't be interfering with running the portage installed X stack, but I should make sure to be completely certain. Have you followed the Hardware Acceleration Guide's Kernel config directions? I've got the: Processor type and features --- * MTRR (Memory Type Range Register) support Device drivers --- Graphics support --- M /dev/agpgart (AGP Support) --- M Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) --- selected, as well as: M ATI Radeon After you mentioned this I decided to check my kernel configuration again. Device drivers --- Graphics support --- Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) --- [*] Enable modesetting on radeon by default - NEW DRIVER Here's part of the description for this option: Choose this option if you want kernel modesetting enabled by default. This is a completely new driver. It's only part of the existing drm for compatibility reasons. It requires an entirely different graphics stack above it and works very differently from the old drm stack. i.e. don't enable this unless you know what you are doing it may cause issues or bugs compared to the previous userspace driver stack. When kernel modesetting is enabled the IOCTL of radeon/drm driver are considered as invalid and an error message is printed in the log and they return failure. This made me reconsider whether I should set this option or not... I gave it a try without the option set and I get direct rendering fine. t...@o_0 ~ $ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Mesa DRI R300 (RS400 5A62) 20090101 x86/MMX/SSE2 NO-TCL Now I have card0 in /dev/dri. I get about 100 fps now, not extremely fast but certainly a lot better than before!
[gentoo-user] Boot speedup
Hi, I've started to look around on how to speed up the Gentoo boot sequence. Looking at the bootchart output I discovered that if using parallel boot feature from the /etc/conf.d/rc (RC_PARALLEL_STARTUP=yes), things get done about 9 seconds faster that with RC_PARALLEL_STARTUP=no. Boot time is still at 45 seconds. Can boot be sped up even more? Best regards, Hinko -- Hinko Kocevar Technical support software engineer Instrumentation Technologies Velika pot 22, SI-5250 Solkan - Slovenia T:+386 5 3352600, F:+386 5 3352601 mailto: hinko.koce...@i-tech.si http://www.i-tech.si - When your users demand stability The information transmitted is intended solely for the addressee and may contain confidential and/or privileged information. Any review, retention, disclosure or other use by persons other than the intended recipient is prohibited. If you received this in error, please notify the sender and delete all copies.
Re: [gentoo-user] Boot speedup
On Mon, Apr 12, 2010 at 4:02 PM, Hinko Kocevar hinko.koce...@i-tech.si wrote: Hi, I've started to look around on how to speed up the Gentoo boot sequence. Looking at the bootchart output I discovered that if using parallel boot feature from the /etc/conf.d/rc (RC_PARALLEL_STARTUP=yes), things get done about 9 seconds faster that with RC_PARALLEL_STARTUP=no. Boot time is still at 45 seconds. Can boot be sped up even more? Best regards, Hinko -- Hinko Kocevar Technical support software engineer Instrumentation Technologies Velika pot 22, SI-5250 Solkan - Slovenia T:+386 5 3352600, F:+386 5 3352601 mailto: hinko.koce...@i-tech.si http://www.i-tech.si - When your users demand stability The information transmitted is intended solely for the addressee and may contain confidential and/or privileged information. Any review, retention, disclosure or other use by persons other than the intended recipient is prohibited. If you received this in error, please notify the sender and delete all copies. Change to testing branch with base layout 2. Your boot time'll decrease by half. -- Nguyễn Bảo Ngọc http://www.facebook.com/pymaster
[gentoo-user] Trying to use ndiswrapper caused a hell of trouble: no suspend and wl doesn't autoload
Hi, I have problems to connect to WPA wireless networks, and it seemed like those were driver related, so I've tried running ndiswrapper. After I failed to get better (or any) performance with it, I tried to revert to the previous settings, but at first the system wouldn't even boot. I've booted with an older kernel for which I haven't build neither ndiswrapper or wl, and removed ndiswrapper completely. But ever since, wl isn't loaded automatically (it does load if I load it manually) and KDE4 fails that detect my system's ACPI capabilities, which makes suspending extremely annoying to me (mostly, because I don't remember how to suspend not using KDE). I'm not sure what other information to provide. I would appreciate any help.
Re: [gentoo-user] Boot speedup
On 04/12/10 11:31, Ngoc Nguyen Bao wrote: On Mon, Apr 12, 2010 at 4:02 PM, Hinko Kocevar hinko.koce...@i-tech.si wrote: Hi, I've started to look around on how to speed up the Gentoo boot sequence. Looking at the bootchart output I discovered that if using parallel boot feature from the /etc/conf.d/rc (RC_PARALLEL_STARTUP=yes), things get done about 9 seconds faster that with RC_PARALLEL_STARTUP=no. Boot time is still at 45 seconds. Can boot be sped up even more? Best regards, Hinko -- Hinko Kocevar Technical support software engineer Instrumentation Technologies Velika pot 22, SI-5250 Solkan - Slovenia T:+386 5 3352600, F:+386 5 3352601 mailto: hinko.koce...@i-tech.si http://www.i-tech.si - When your users demand stability The information transmitted is intended solely for the addressee and may contain confidential and/or privileged information. Any review, retention, disclosure or other use by persons other than the intended recipient is prohibited. If you received this in error, please notify the sender and delete all copies. Change to testing branch with base layout 2. Your boot time'll decrease by half. Thank you! Hmm, I was looking at the http://www.gentoo.org/doc/en/openrc-migration.xml. For OpenRC I added sys-apps/openrc ~x86 to package.keywords, to get baselayout-2 ebuild I've added ACCEPT_KEYWORDS=~x86 to /etc/make.conf. Will it be enough to (re-)build the baselayout and openrc and its closest dependencies (41 packages)? Or do I need to perform complete system upgrade (~900 packages) now that ACCEPT_KEYWORDS is present? Best regards, Hinko -- Hinko Kocevar Technical support software engineer Instrumentation Technologies Velika pot 22, SI-5250 Solkan - Slovenia T:+386 5 3352600, F:+386 5 3352601 mailto: hinko.koce...@i-tech.si http://www.i-tech.si - When your users demand stability The information transmitted is intended solely for the addressee and may contain confidential and/or privileged information. Any review, retention, disclosure or other use by persons other than the intended recipient is prohibited. If you received this in error, please notify the sender and delete all copies.
Re: [gentoo-user] Boot speedup
Am 12.04.2010 11:56, schrieb Hinko Kocevar: [...] Thank you! Hmm, I was looking at the http://www.gentoo.org/doc/en/openrc-migration.xml. For OpenRC I added sys-apps/openrc ~x86 to package.keywords, to get baselayout-2 ebuild I've added ACCEPT_KEYWORDS=~x86 to /etc/make.conf. Will it be enough to (re-)build the baselayout and openrc and its closest dependencies (41 packages)? Or do I need to perform complete system upgrade (~900 packages) now that ACCEPT_KEYWORDS is present? Best regards, Hinko Hi, if you are using ACCEPT_KEYWORDS=~x86 in /etc/make.conf you should do all 900 packages. Otherwise you might get a mix of both worlds what could be bad. Be sure that you really want your system changed to testing. Otherwise you should add those 41 packages to /etc/portage/package.keywords kh
[gentoo-user] ~amd64 - my experience so far...
...is not so good actually. Certainly not the way I'd want others to experience Gentoo. OK, the ~amd64 upgrade to @system was easy and relatively painless. The documents were fairly clear. There are things to learn, and old friends like rc-update and df look different, but it worked and didn't take long - less than an hour to reboot including editing - so that's good. Unfortunately, simply allowing all environments apps on the system to go ~amd64 isn't working out as nicely. 1) xfce4 had one build failure. I masked it and the build finished. xfce starts and seems to mostly work, but I get no wallpaper and the right click for a menu on the desktop doesn't work. It's usable, but clearly 'not stable'. 2) gnome-2.28 simply doesn't build. 3) I'm currently left with lots of things in emerge @preserved-rebuild that don't build. emerge -DuN @world is not clean. QUESTION: Assume I'm happy with ~amd64 on @system, but want to build the stable version of gnome or kde. How do I get it? Since gnome-2.26 worked yesterday I tried masking =gnome-2.28. emerge -DuN gnome. Portage then didn't try to emerge the meta-package but doesn't take all of gnome back to 2.26. There's no point trying kde as gnome pulled in kde components that doesn't build either. Hopefully it's not 'mask every package in gnome by hand'. At this point I'm left with a system that's not clean and to me not terribly useful. Yesterday as stable I built xfce, gnome and kde in under 4 hours and all 3 worked. Today both gnome and xfce aren't right and I don't have kde. Probably this is some matter of learning to hold back portage that I've never done before, rather than unleashing new packages like you do on a stable system. How does one accomplish this? Thanks, Mark
Re: [gentoo-user] Boot speedup
On Mon, Apr 12, 2010 at 2:56 AM, Hinko Kocevar hinko.koce...@i-tech.si wrote: On 04/12/10 11:31, Ngoc Nguyen Bao wrote: On Mon, Apr 12, 2010 at 4:02 PM, Hinko Kocevar hinko.koce...@i-tech.si wrote: Hi, I've started to look around on how to speed up the Gentoo boot sequence. Looking at the bootchart output I discovered that if using parallel boot feature from the /etc/conf.d/rc (RC_PARALLEL_STARTUP=yes), things get done about 9 seconds faster that with RC_PARALLEL_STARTUP=no. Boot time is still at 45 seconds. Can boot be sped up even more? Best regards, Hinko -- Hinko Kocevar Technical support software engineer Instrumentation Technologies Velika pot 22, SI-5250 Solkan - Slovenia T:+386 5 3352600, F:+386 5 3352601 mailto: hinko.koce...@i-tech.si http://www.i-tech.si - When your users demand stability The information transmitted is intended solely for the addressee and may contain confidential and/or privileged information. Any review, retention, disclosure or other use by persons other than the intended recipient is prohibited. If you received this in error, please notify the sender and delete all copies. Change to testing branch with base layout 2. Your boot time'll decrease by half. Thank you! Hmm, I was looking at the http://www.gentoo.org/doc/en/openrc-migration.xml. For OpenRC I added sys-apps/openrc ~x86 to package.keywords, to get baselayout-2 ebuild I've added ACCEPT_KEYWORDS=~x86 to /etc/make.conf. Will it be enough to (re-)build the baselayout and openrc and its closest dependencies (41 packages)? Or do I need to perform complete system upgrade (~900 packages) now that ACCEPT_KEYWORDS is present? Best regards, Hinko -- Hinko Kocevar Technical support software engineer Instrumentation Technologies Velika pot 22, SI-5250 Solkan - Slovenia T:+386 5 3352600, F:+386 5 3352601 mailto: hinko.koce...@i-tech.si http://www.i-tech.si - When your users demand stability The information transmitted is intended solely for the addressee and may contain confidential and/or privileged information. Any review, retention, disclosure or other use by persons other than the intended recipient is prohibited. If you received this in error, please notify the sender and delete all copies. Be careful about going ~x86. I just went ~amd64. The OpenRC migration is painless. The KDE, gnome, xfce4 part hasn't been for me. I'm likely to remove all environments and apps, add the 41 apps to package.keywords and be done with it, assuming that actually works and doesn't uncover other problems. Read more in a post I just sent before I saw your question. - Mark
Re: [gentoo-user] ~amd64 - my experience so far...
Are you merely ranting or asking for help? If the former, well, OK i Hear you. But I don't care. If the latter, then you need to provide info like logs, output etc. ~amd64 works like a charm for me here. On Monday 12 April 2010 13:57:39 Mark Knecht wrote: ...is not so good actually. Certainly not the way I'd want others to experience Gentoo. OK, the ~amd64 upgrade to @system was easy and relatively painless. The documents were fairly clear. There are things to learn, and old friends like rc-update and df look different, but it worked and didn't take long - less than an hour to reboot including editing - so that's good. Unfortunately, simply allowing all environments apps on the system to go ~amd64 isn't working out as nicely. 1) xfce4 had one build failure. I masked it and the build finished. xfce starts and seems to mostly work, but I get no wallpaper and the right click for a menu on the desktop doesn't work. It's usable, but clearly 'not stable'. 2) gnome-2.28 simply doesn't build. 3) I'm currently left with lots of things in emerge @preserved-rebuild that don't build. emerge -DuN @world is not clean. QUESTION: Assume I'm happy with ~amd64 on @system, but want to build the stable version of gnome or kde. How do I get it? Since gnome-2.26 worked yesterday I tried masking =gnome-2.28. emerge -DuN gnome. Portage then didn't try to emerge the meta-package but doesn't take all of gnome back to 2.26. There's no point trying kde as gnome pulled in kde components that doesn't build either. Hopefully it's not 'mask every package in gnome by hand'. At this point I'm left with a system that's not clean and to me not terribly useful. Yesterday as stable I built xfce, gnome and kde in under 4 hours and all 3 worked. Today both gnome and xfce aren't right and I don't have kde. Probably this is some matter of learning to hold back portage that I've never done before, rather than unleashing new packages like you do on a stable system. How does one accomplish this? Thanks, Mark -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Trying to use ndiswrapper caused a hell of trouble: no suspend and wl doesn't autoload
On Mon, 12 Apr 2010 12:47:26 +0300, Yoav Luft wrote: I have problems to connect to WPA wireless networks, and it seemed like those were driver related, so I've tried running ndiswrapper. After I failed to get better (or any) performance with it, I tried to revert to the previous settings, but at first the system wouldn't even boot. I've booted with an older kernel for which I haven't build neither ndiswrapper or wl, and removed ndiswrapper completely. But ever since, wl isn't loaded automatically (it does load if I load it manually When you tried ndiswrapper, did you blacklist wl, or put something in /etc/rc.conf to stop it loading? -- Neil Bothwick Evolution stops when stupidity is no longer fatal! signature.asc Description: PGP signature
Re: [gentoo-user] ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 04:57:39AM -0700, Mark Knecht wrote: ...is not so good actually. Certainly not the way I'd want others to experience Gentoo. OK, the ~amd64 upgrade to @system was easy and relatively painless. The documents were fairly clear. There are things to learn, and old friends like rc-update and df look different, but it worked and didn't take long - less than an hour to reboot including editing - so that's good. Unfortunately, simply allowing all environments apps on the system to go ~amd64 isn't working out as nicely. 1) xfce4 had one build failure. I masked it and the build finished. xfce starts and seems to mostly work, but I get no wallpaper and the right click for a menu on the desktop doesn't work. It's usable, but clearly 'not stable'. Are there any bugs on this? Perhaps it's a configurations thing :-) 2) gnome-2.28 simply doesn't build. Attatch the log? I doubt I can help you, but I'm pretty sure someone else on the list will be able to :-) 3) I'm currently left with lots of things in emerge @preserved-rebuild that don't build. emerge -DuN @world is not clean. it isn't? The way I see it, it's every bit as clean as emerge -DuN world, the difference is that now there's a set to take care of what revdep-rebuild did. I could be mistaken then ;) QUESTION: Assume I'm happy with ~amd64 on @system, but want to build the stable version of gnome or kde. How do I get it? Since gnome-2.26 worked yesterday I tried masking =gnome-2.28. emerge -DuN gnome. Portage then didn't try to emerge the meta-package but doesn't take all of gnome back to 2.26. There's no point trying kde as gnome pulled in kde components that doesn't build either. Hopefully it's not 'mask every package in gnome by hand'. The way to hold packages back would be adding foo/bar -~arch to your package.keywords file. That way portage will only look at the stable packages. It's tedious to do it by hand (and I don't know any automated process), but if most of your system will be running ~arch then I'd suggest that you stay ~arch, and vice versa if most of the system is running arch. At this point I'm left with a system that's not clean and to me not terribly useful. Yesterday as stable I built xfce, gnome and kde in under 4 hours and all 3 worked. Today both gnome and xfce aren't right and I don't have kde. Probably this is some matter of learning to hold back portage that I've never done before, rather than unleashing new packages like you do on a stable system. How does one accomplish this? Thanks, Mark Hope it helps :-) -- Zeerak Waseem pgpg5d5RuLYNb.pgp Description: PGP signature
Re: [gentoo-user] wlan0 config questions
On 12 April 2010 08:11, Walter Dnes waltd...@waltdnes.org wrote: Here's /etc/conf.d/net on my Gentoo netbook system... config_eth0=192.168.123.249 broadcast 192.168.123.255 netmask 255.255.255.248 mtu 1452 routes_eth0=( default via 192.168.123.254 metric 2 192.168.123.248/29 via 192.168.123.254 metric 0 ) The multiple routes allow eth0 to remain connected to my router and talk to the other machine on the lan while running a dialup connection. I want to try out my netbook wifi, and I find that it works too well!!! Here's the output after starting up wlan0. The ESSID and MAC address of my neighbours in the condo have been masked to protect the innocent... aa1 init.d # /etc/init.d/net.wlan0 restart * Stopping wlan0 * Bringing down wlan0 * Stopping dhcpcd on wlan0 ... [ ok ] * Shutting down wlan0 ... [ ok ] * Starting wlan0 * Configuring wireless network for wlan0 * WEP key is not set for KGB zone** keep OFF** - not connecting * wlan0 connected to ESSID *** at **:**:**:**:**:** * in managed mode on channel 6 (WEP disabled) * Configuration not set for wlan0 - assuming DHCP * Bringing up wlan0 * dhcp * Running dhcpcd ... wlan0: dhcpcd 4.0.15 starting wlan0: broadcasting for a lease wlan0: offered 192.168.0.103 from 192.168.0.1 wlan0: ignoring offer of 192.168.0.103 from 192.168.0.1 wlan0: acknowledged 192.168.0.103 from 192.168.0.1 wlan0: checking 192.168.0.103 is available on attached networks wlan0: leased 192.168.0.103 for 604800 seconds [ ok ] * wlan0 received address 192.168.0.103/24 After picking my jaw off the floor, I downed wlan0. Just to be safe, I ran rmmod ath5k. I want to be able to scan available connections and then select which one I want, e.g. I want to try it at the local public library. I do not like the concept of the netbook automatically connecting to the first available access point. What do I have to do to *NOT* connect automatically? You probably want to look at wpa_supplicant (in particular man wpa_gui), or any other network manager type of application would do (wicd, network manager, wifi-radar) which allows you to enable/disable access points for automatic connection to them. Alternatively, a less practical approach would be to set up config_wlan0=( null ) in your /etc/conf.d/net.wlan0, which will not allow your wireless card to obtain any address. Or, you can play with dhcpcd options like so: dhcp_eth0=release nogateway nosendhost which means that it will not bind to any wireless router as a gateway. -- Regards, Mick
Re: [gentoo-user] ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 5:00 AM, Alan McKinnon alan.mckin...@gmail.com wrote: Are you merely ranting or asking for help? If the former, well, OK i Hear you. But I don't care. If the latter, then you need to provide info like logs, output etc. ~amd64 works like a charm for me here. Neither. I think I asked a simple question. How does one get ~amd64 @system and stable everything else? If the answer is 'you can't' or 'it's immensely hard because you have to -~arch everything by hand' then I'll just go back to stable, whether it is easy or requires me to rebuild the system from scratch. I'm certainly not ranting. I don't think that tone should came across in what I wrote and if you're reading that in then it's on your end not mine. (Although I apologize for writing anything that made that happen!) I have __nothing__ on this system. The hardware is brand new. It's been said time and time again that running all ~arch on other people's systems (like yours) works great and I wanted to try it. It's certainly not working for me at this point but I'm not upset, mad, or anything like that. I'm asking a simple question. That's it. Nothing more. I am however documenting my experiences for others than come after me to this question of to ~amd64 or not ~amd64. Nothing more. It worked for Alan who is a __very__ experienced and capable person. It didn't work for Mark (at this point) who is a 10 year Gentoo user but __nothing__ more than a user type Those people can decide who they are closer to in capabilities and make their choice a bit more informed. I didn't wake up this morning thinking I could do what you and Neil and others on this list can with this distro. I'm not that silly! I just wanted to try ~amd64 to see what happened. It will take me less than 90 minutes to get to a new clean install if I blow everything away and start over. It's not a big deal. - Mark
Re: [gentoo-user] Re: iptables - do I need the nat table?
On 2010-04-11 9:20 AM, Graham Murray wrote: Tanstaafl tansta...@libertytrek.org writes: I'm a bit clueless when it comes to firewalls, and have no idea what these numbers mean/do: *raw :PREROUTING ACCEPT [4911:886011] :OUTPUT ACCEPT [4546:2818732] COMMIT The numbers are [packets:bytes] which match the rule or table concerned. Ok, so... I still don't know what they *mean*... ie, is this a hole in my firewall? What is the raw table used for, in plain english? More importantly though... When I try to remove the nat and raw tables from my firewall, they don't go away. I have always kept my rules in a separate file, and when I want to make changes, I change the external file, then do iptables-restore /path/to/iptables-current. (My rule set is very small, so this only takes a second or two, so its not/never been a problem) I've been doing it this way for a long time, and all other changes I have ever made - eg, opening a certain port for a certain host - work fine, but, when I comment out the raw and nat tables, then restore the rules, then do iptables-save path/to/iptables-current-dump, the examined file still shows the raw and nat tables loaded... ???
Re: [gentoo-user] ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 5:14 AM, Zeerak Mustafa Waseem zeera...@gmail.com wrote: On Mon, Apr 12, 2010 at 04:57:39AM -0700, Mark Knecht wrote: ...is not so good actually. Certainly not the way I'd want others to experience Gentoo. OK, the ~amd64 upgrade to @system was easy and relatively painless. The documents were fairly clear. There are things to learn, and old friends like rc-update and df look different, but it worked and didn't take long - less than an hour to reboot including editing - so that's good. Unfortunately, simply allowing all environments apps on the system to go ~amd64 isn't working out as nicely. 1) xfce4 had one build failure. I masked it and the build finished. xfce starts and seems to mostly work, but I get no wallpaper and the right click for a menu on the desktop doesn't work. It's usable, but clearly 'not stable'. Are there any bugs on this? Perhaps it's a configurations thing :-) Between xfce4 gnome I've seen about a dozen packages fail to build this morning and haven't yet checked bug reports. I suspect that many or more kde packages would get added to the list if I tried ~amd64 kde. I'm sure you're possibly right about it being a 'configuration thing'. SNIP QUESTION: Assume I'm happy with ~amd64 on @system, but want to build the stable version of gnome or kde. How do I get it? Since gnome-2.26 worked yesterday I tried masking =gnome-2.28. emerge -DuN gnome. Portage then didn't try to emerge the meta-package but doesn't take all of gnome back to 2.26. There's no point trying kde as gnome pulled in kde components that doesn't build either. Hopefully it's not 'mask every package in gnome by hand'. The way to hold packages back would be adding foo/bar -~arch to your package.keywords file. That way portage will only look at the stable packages. It's tedious to do it by hand (and I don't know any automated process), but if most of your system will be running ~arch then I'd suggest that you stay ~arch, and vice versa if most of the system is running arch. Thanks. The -~arch thing is what I was looking for info wise. However doing that to all of gnome or kde's packages is too much work. SNIP Hope it helps :-) -- Zeerak Waseem It does, very much! Thanks! Cheers, Mark
Re: [gentoo-user] Boot speedup
Hi, On 04/12/10 12:26, KH wrote: Am 12.04.2010 11:56, schrieb Hinko Kocevar: [...] Thank you! Hmm, I was looking at the http://www.gentoo.org/doc/en/openrc-migration.xml. For OpenRC I added sys-apps/openrc ~x86 to package.keywords, to get baselayout-2 ebuild I've added ACCEPT_KEYWORDS=~x86 to /etc/make.conf. Will it be enough to (re-)build the baselayout and openrc and its closest dependencies (41 packages)? Or do I need to perform complete system upgrade (~900 packages) now that ACCEPT_KEYWORDS is present? Best regards, Hinko Hi, if you are using ACCEPT_KEYWORDS=~x86 in /etc/make.conf you should do all 900 packages. Otherwise you might get a mix of both worlds what could be bad. Be sure that you really want your system changed to testing. Otherwise you should add those 41 packages to /etc/portage/package.keywords Crap. I though there will be some other simpler way of doing this. I guess I'll leave as-is, at 45 second boot, since I don't want to compromise my current setup with 'testing' packages where I don't want/need them.. Thank you all! Best regards, Hinko -- Hinko Kocevar Technical support software engineer Instrumentation Technologies Velika pot 22, SI-5250 Solkan - Slovenia T:+386 5 3352600, F:+386 5 3352601 mailto: hinko.koce...@i-tech.si http://www.i-tech.si - When your users demand stability The information transmitted is intended solely for the addressee and may contain confidential and/or privileged information. Any review, retention, disclosure or other use by persons other than the intended recipient is prohibited. If you received this in error, please notify the sender and delete all copies.
Re: [gentoo-user] ~amd64 - my experience so far...
I am however documenting my experiences for others than come after me to this question of to ~amd64 or not ~amd64. Nothing more. It worked for Alan who is a __very__ experienced and capable person. It didn't work for Mark (at this point) who is a 10 year Gentoo user but __nothing__ more than a user type Those people can decide who they are closer to in capabilities and make their choice a bit more informed. I didn't wake up this morning thinking I could do what you and Neil and others on this list can with this distro. I'm not that silly! I just wanted to try ~amd64 to see what happened. It will take me less than 90 minutes to get to a new clean install if I blow everything away and start over. It's not a big deal. - Mark Is there a reason why you want to run all @system as ~amd64, and the rest stable. To me it makes more sense (especially for production systems) to run @system as stable and only ~amd64 those apps and dependencies you want/need to be bleeding edge. Anyhow, what I really wanted to say is for more sensible unmasking, check out autounmask: moriah home # esearch autounmask [ Results for search key : autounmask ] [ Applications found : 1 ] * app-portage/autounmask Latest version available: 0.27 Latest version installed: [ Not Installed ] Size of downloaded files: 3 kB Homepage:http://download.mpsna.de/opensource/autounmask/ Description: autounmask - Unmasking packages the easy way License: GPL-2 moriah home #
Re: [gentoo-user] Boot speedup
On Apr 12, 2010, at 7:01 AM, Mark Knecht markkne...@gmail.com wrote: On Mon, Apr 12, 2010 at 2:56 AM, Hinko Kocevar hinko.koce...@i-tech.si wrote: On 04/12/10 11:31, Ngoc Nguyen Bao wrote: On Mon, Apr 12, 2010 at 4:02 PM, Hinko Kocevar hinko.koce...@i-tech.si wrote: Hi, I've started to look around on how to speed up the Gentoo boot sequence. Looking at the bootchart output I discovered that if using parallel boot feature from the /etc/conf.d/rc (RC_PARALLEL_STARTUP=yes), things get done about 9 seconds faster that with RC_PARALLEL_STARTUP=no. Boot time is still at 45 seconds. Can boot be sped up even more? Best regards, Hinko . Change to testing branch with base layout 2. Your boot time'll decrease by half. Thank you! Hmm, I was looking at the http://www.gentoo.org/doc/en/openrc-migration.xml. For OpenRC I added sys-apps/openrc ~x86 to package.keywords, to get baselayout-2 ebuild I've added ACCEPT_KEYWORDS=~x86 to /etc/make.conf. Will it be enough to (re-)build the baselayout and openrc and its closest dependencies (41 packages)? Or do I need to perform complete system upgrade (~900 packages) now that ACCEPT_KEYWORDS is present? Best regards, Hinko Be careful about going ~x86. I just went ~amd64. The OpenRC migration is painless. The KDE, gnome, xfce4 part hasn't been for me. I'm likely to remove all environments and apps, add the 41 apps to package.keywords and be done with it, assuming that actually works and doesn't uncover other problems. Read more in a post I just sent before I saw your question. - Mark Concider / on SSD, /tmp in RAM, /var on spinning disk. A free society is a single class society where everyone has the same rights.
Re: [gentoo-user] ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 5:42 AM, William Kenworthy bi...@iinet.net.au wrote: I am however documenting my experiences for others than come after me to this question of to ~amd64 or not ~amd64. Nothing more. It worked for Alan who is a __very__ experienced and capable person. It didn't work for Mark (at this point) who is a 10 year Gentoo user but __nothing__ more than a user type Those people can decide who they are closer to in capabilities and make their choice a bit more informed. I didn't wake up this morning thinking I could do what you and Neil and others on this list can with this distro. I'm not that silly! I just wanted to try ~amd64 to see what happened. It will take me less than 90 minutes to get to a new clean install if I blow everything away and start over. It's not a big deal. - Mark Is there a reason why you want to run all @system as ~amd64, and the rest stable. To me it makes more sense (especially for production systems) to run @system as stable and only ~amd64 those apps and dependencies you want/need to be bleeding edge. Anyhow, what I really wanted to say is for more sensible unmasking, check out autounmask: moriah home # esearch autounmask [ Results for search key : autounmask ] [ Applications found : 1 ] * app-portage/autounmask Latest version available: 0.27 Latest version installed: [ Not Installed ] Size of downloaded files: 3 kB Homepage: http://download.mpsna.de/opensource/autounmask/ Description: autounmask - Unmasking packages the easy way License: GPL-2 moriah home # William, In general I agree logically. There was no _strong_ reason for me to run ~arch on anything. I just wanted to try it out since the machine was new and this was a good time to get the experience vs having lots of stuff on the machine and trying to switch later. ~arch @system was mainly to get a jump on the OpenRC migration before I had so much stuff on the system that I couldn't afford to just reformat and start over if I had problems with it. Having done it once I now know it won't be difficult later when it moves to stable. ~arch xfce/gnome/kde on the other hand is not something I needed. It just comes with ~arch and for me didn't work so well. For me the desktop environment is mostly just a platform to get a browser or VMWare up and running. kde and it's brethren move forward but the revision level changes hardly impact me in normal life. Again, based on Alan's response, this isn't about me being upset or anything like that. I'm not upset in the least. Just trying things out. Thanks, Mark
Re: [gentoo-user] ~amd64 - my experience so far...
On Monday 12 April 2010 14:29:00 Mark Knecht wrote: On Mon, Apr 12, 2010 at 5:00 AM, Alan McKinnon alan.mckin...@gmail.com wrote: Are you merely ranting or asking for help? If the former, well, OK i Hear you. But I don't care. If the latter, then you need to provide info like logs, output etc. ~amd64 works like a charm for me here. Neither. I think I asked a simple question. How does one get ~amd64 @system and stable everything else? If the answer is 'you can't' or 'it's immensely hard because you have to -~arch everything by hand' then I'll just go back to stable, whether it is easy or requires me to rebuild the system from scratch. You can't do that easily, and it certainly is not advisable. The only way I can think of would be to put every package in @system into package.keywords and leave ACCEPT_KEYWORDS at arch. This will cause problems: 1. stable is just that: stable. By and large the full stable set is known to work 2. when devs commit to ~arch, they tend to run ~arch on their test boxes. Issues are easy to spot and get fixed quickly. If you have a mixture of the two, then you have a combination that no-one but you is using, and it will not have been tested. The odds are good that you will often run into problems that are hard to trace (conflicting versions of packages). Running ~arch is actually more stable than a mixture as many folk have those packages and there are more eyeballs on it. I'm certainly not ranting. I don't think that tone should came across in what I wrote and if you're reading that in then it's on your end not mine. (Although I apologize for writing anything that made that happen!) I have __nothing__ on this system. The hardware is brand new. It's been said time and time again that running all ~arch on other people's systems (like yours) works great and I wanted to try it. It's certainly not working for me at this point but I'm not upset, mad, or anything like that. I'm asking a simple question. That's it. Nothing more. I am however documenting my experiences for others than come after me to this question of to ~amd64 or not ~amd64. Nothing more. It worked for Alan who is a __very__ experienced and capable person. It didn't work for Mark (at this point) who is a 10 year Gentoo user but __nothing__ more than a user type Those people can decide who they are closer to in capabilities and make their choice a bit more informed. I didn't wake up this morning thinking I could do what you and Neil and others on this list can with this distro. I'm not that silly! I just wanted to try ~amd64 to see what happened. It will take me less than 90 minutes to get to a new clean install if I blow everything away and start over. It's not a big deal. Considering the kind of software you use, I'd advise you to just run ~amd64 and be done with it. Your usage-profile is of someone who needs recent features. I would only go back to amd64 if some genuine show-stopper blockage pops up, or if the packages you use are updated often (and usually with brand new shiny bugs - enlightenment is a lot like that which is why I had to stop using it) -- alan dot mckinnon at gmail dot com
[gentoo-user] Re: ~amd64 - my experience so far...
On 12/04/2010 12:57, Mark Knecht wrote:
QUESTION: Assume I'm happy with ~amd64 on @system, but want to build
the stable version of gnome or kde. How do I get it? Since gnome-2.26
You could opt to retain the ~amd64 keyword on system packages alone.
Consider the following (which requires portage-utils):
$ emerge -qep system | sed -rne '/^\[ebuild/{s/(^| )\[[^]]*\]( |$)//gp}'
| xargs qatom | awk '{ print $1/$2 }'
You might then proceed to place the output of the above command in
package.keywords then switch ACCEPT_KEYWORDS back to amd64.
Cheers,
--Kerin
[gentoo-user] Re: ~amd64 - my experience so far...
On 04/12/2010 05:35 AM, Mark Knecht wrote: Between xfce4 gnome I've seen about a dozen packages fail to build this morning and haven't yet checked bug reports. Let's start with xfce4 then because it's much smaller than gnome. What fails to build, and with what errors? I actually use gnome, so I could probably give you more help with that. I haven't seen any build failures on my ~amd64 machine lately, so there must be a fairly basic problem on your machine if you are seeing that many build failures. Some specific error messages would help, though.
[gentoo-user] Re: ~amd64 - my experience so far...
On 12/04/2010 13:42, William Kenworthy wrote: Is there a reason why you want to run all @system as ~amd64, and the rest stable. To me it makes more sense (especially for production Perhaps he simply doesn't feel like re-installing. By going down this road, the breakage caused by dowgrading system packages - glibc in particular - can be avoided. Chhers, --Kerin
Re: [gentoo-user] ~amd64 - my experience so far...
On Mon, 12 Apr 2010 05:29:00 -0700, Mark Knecht wrote: It's certainly not working for me at this point but I'm not upset, mad, or anything like that. I'm asking a simple question. That's it. Except you didn't really ask a question, at least not in manner that could be answered. Posting the output of the failures would make it a question that could be answered. While you are getting multiple failures, there may only be one or two problems, fix those and everything should fall into place. -- Neil Bothwick I'm not anti-social, I'm just not user friendly signature.asc Description: PGP signature
Re: [gentoo-user] Switching to unstable
On Mon, Apr 12, 2010 at 2:06 AM, Marc Joliet mar...@gmx.de wrote: Am Sun, 11 Apr 2010 17:13:26 -0700 schrieb Mark Knecht markkne...@gmail.com: A couple of packages in this OpenRC upgrade aren't building. I hope they are less important. So far groff and help2man have failed so I did --resume --skip-first and moved on for now. Just a note: you can also specify --keep-going and portage will do that for you and even recalculate the dependencies before continuing. After it's done, it gives you a message listing the packages that failed. I use the --keep-going always, it was a great addition and especially helpful when there is a bad package that won't compile for a week or two, it makes it easier to just ignore it. Also on big upgrade emerges like that sometimes packages will fail during the big emerge but after you finish, etc-update, env-update whatever, they will build okay, for whatever reason. Maybe related to gcc/binutils/other libs stuff not matching for a short while...
Re: [gentoo-user] Switching to unstable
when there is a bad package that won't compile for a week or two I've already seen packages doing that, but they shouldn't happen, right? :-)
Re: [gentoo-user] Switching to unstable
On 2010-04-12 11:05 AM, Paul Hartman wrote: I use the --keep-going always, it was a great addition and especially helpful when there is a bad package that won't compile for a week or two, it makes it easier to just ignore it. Hopefully no one will mind a slight OT question, but still related... Is the testing version of portage 2.2 stable enough for production machines? There are a number of new features I'd like to take advantage of, but have always hesitated to and any non-stable system packages. Portage 2.2 is just taking forever to go stable... currently its on the 67th release candidate? That must be some kind of record (although earlier versions of dovecot came close)... :P -- Charles
Re: [gentoo-user] ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 6:57 AM, Mark Knecht markkne...@gmail.com wrote:
...is not so good actually. Certainly not the way I'd want others to
experience Gentoo.
OK, the ~amd64 upgrade to @system was easy and relatively painless.
The documents were fairly clear. There are things to learn, and old
friends like rc-update and df look different, but it worked and didn't
take long - less than an hour to reboot including editing - so that's
good.
Unfortunately, simply allowing all environments apps on the system
to go ~amd64 isn't working out as nicely.
1) xfce4 had one build failure. I masked it and the build finished.
xfce starts and seems to mostly work, but I get no wallpaper and the
right click for a menu on the desktop doesn't work. It's usable, but
clearly 'not stable'.
Hi,
I'm using ~amd64 for my whole system (for years). I have a similar
system to yours, but only a Core i7 920, :) and at the moment every
package on my system builds fine.
Which package failed? Which profile and GCC are you using? I just
emerged xfce4-meta and everything worked. Here's my GCC, profile and
xfce versions (I also use unmasked portage):
[ebuild R ] sys-devel/gcc-4.4.3 USE=fortran gcj graphite gtk
mudflap (multilib) nls nptl objc objc++ objc-gc openmp (-altivec)
-bootstrap -build -doc (-fixed-point) (-hardened) (-libffi) -multislot
(-n32) (-n64) -nocxx -test -vanilla 0 kB
$ sudo gcc-config -l
[1] x86_64-pc-linux-gnu-4.4.3 *
$ sudo eselect profile show
Current make.profile symlink:
default/linux/amd64/10.0/desktop
My cflags:
CFLAGS=-march=native -O3 -floop-interchange -floop-strip-mine
-floop-block -ggdb -pipe
CXXFLAGS=${CFLAGS}
LDFLAGS=-Wl,--as-needed
$ emerge -vp xfce4-meta
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N] xfce-base/libxfce4util-4.7.1 USE=-debug 0 kB
[ebuild N] dev-util/xfce4-dev-tools-4.7.2 0 kB
[ebuild N] x11-themes/xfce4-icon-theme-4.4.3 0 kB
[ebuild N] x11-themes/gtk-engines-xfce-2.6.0 0 kB
[ebuild N] xfce-base/xfconf-4.7.2 USE=perl -debug -profile 0 kB
[ebuild N] xfce-base/exo-0.3.106 USE=hal libnotify python -debug 0 kB
[ebuild N] xfce-base/libxfce4menu-4.6.1 USE=-debug 0 kB
[ebuild N] xfce-base/libxfcegui4-4.6.3 USE=startup-notification
-debug -glade 0 kB
[ebuild N] xfce-base/xfce4-panel-4.6.2-r1
USE=startup-notification -debug 0 kB
[ebuild N] xfce-base/xfce-utils-4.6.1 USE=dbus lock -debug 0 kB
[ebuild N] xfce-base/xfwm4-4.6.1 USE=startup-notification
xcomposite -debug 0 kB
[ebuild N] xfce-base/xfce4-settings-4.6.3-r1 USE=keyboard
libnotify -debug -sound 0 kB
[ebuild N] xfce-base/xfce4-session-4.6.1-r1 USE=-debug -fortune
-gnome -gnome-keyring -profile 0 kB
[ebuild N] xfce-base/thunar-1.0.1 USE=dbus exif hal pcre
startup-notification trash-plugin -debug -doc -gnome -test 0 kB
[ebuild N] xfce-base/xfdesktop-4.6.1-r1 USE=branding
menu-plugin thunar -debug -doc LINGUAS=-be -ca -cs -da -de -el -es
-et -eu -fi -fr -he -hu -it -ja -ko -nb_NO -nl -pa -pl -pt_BR -ro -ru
-sk -sv -tr -uk -vi -zh_CN -zh_TW 0 kB
[ebuild N] xfce-base/xfce4-meta-4.6.1 USE=session -minimal 0 kB
The xfce wallpaper thing sounds like what I experienced with xfce
during the jpeg-6-to-7 upgrade process. At the time, jpeg was not
slotted and there was jpeg-compat for programs that were incompatible
with jpeg-7. Now we have jpeg-8 as well, and 6/7/8 are in slots, so
maybe the solution is different. Back then, I unmerged and masked
jpeg-6, revdep-rebuild everything that depended on jpeg so that it was
built against jpeg-7 and then everything was fine. (Maybe there was a
gtk+ patch I had to apply on day 0, but that was long ago made
obsolete by newer versions of gtk+ in portage)
2) gnome-2.28 simply doesn't build.
I'm not a gnome user but I can try this if you want (135 packages to
emerge in my case), or if you have more specific info about which part
doesn't build I can try only the specifics.
3) I'm currently left with lots of things in emerge @preserved-rebuild
that don't build. emerge -DuN @world is not clean.
Maybe you can unmerge those packages, allowing emerge to get rid of
the preserved libs, then emerge world to bring those packages back.
Re: [gentoo-user] Switching to unstable
On Mon, Apr 12, 2010 at 10:18 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2010-04-12 11:05 AM, Paul Hartman wrote: I use the --keep-going always, it was a great addition and especially helpful when there is a bad package that won't compile for a week or two, it makes it easier to just ignore it. Hopefully no one will mind a slight OT question, but still related... Is the testing version of portage 2.2 stable enough for production machines? There are a number of new features I'd like to take advantage of, but have always hesitated to and any non-stable system packages. I've been using portage unmasked for a very long time and don't remember having any portage-related problems. I'm sure there must be some (or else why is it still RC?) but for me the new features are worth the potential risk of using less-tested code.
Re: [gentoo-user] Boot speedup
Am 12.04.2010 11:02, schrieb Hinko Kocevar: Hi, I've started to look around on how to speed up the Gentoo boot sequence. Looking at the bootchart output I discovered that if using parallel boot feature from the /etc/conf.d/rc (RC_PARALLEL_STARTUP=yes), things get done about 9 seconds faster that with RC_PARALLEL_STARTUP=no. Boot time is still at 45 seconds. Can boot be sped up even more? The fastest way to boot is not to boot at all. Just use Suspend2Disk or SuspendToRam. Take a look at TuxOnIce and hibernate-script. Unless something is broken, I hardly ever reboot. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] X11 and HP2475w: First steps?
On Sat, Apr 10, 2010 at 3:21 AM, meino.cra...@gmx.de wrote: Hi, before damaging delicate electronic equipment I want to ask, what the best way is to switch from a 1600x1200 pixel analogous Iiyama monitor to an Flat panel HP2475w (LCD) with 1980x1200 pixel monitor? Graphics card is a (info via lspci): nVidia Corporation G73 [GeForce 7600 GT] (rev a2) With one analog and one digital output. Thank you very much for any help in advance! If you're using binary nvidia driver I think it should autodetect your monitor and everything should be fine... no need to specific modelines or anything like that (however if you have done that with your old monitor you may need to remove it). I switch between monitors often and it Just Works(tm). :) If you use framebuffer maybe you'll need to edit your grub config to use a different mode, but LCD usually just scales invalid modes to fit the screen anyway. I don't think you should worry about damaging it.
Re: [gentoo-user] Switching to unstable
Paul Hartman wrote: On Mon, Apr 12, 2010 at 10:18 AM, Tanstaafltansta...@libertytrek.org wrote: On 2010-04-12 11:05 AM, Paul Hartman wrote: I use the --keep-going always, it was a great addition and especially helpful when there is a bad package that won't compile for a week or two, it makes it easier to just ignore it. Hopefully no one will mind a slight OT question, but still related... Is the testing version of portage 2.2 stable enough for production machines? There are a number of new features I'd like to take advantage of, but have always hesitated to and any non-stable system packages. I've been using portage unmasked for a very long time and don't remember having any portage-related problems. I'm sure there must be some (or else why is it still RC?) but for me the new features are worth the potential risk of using less-tested code. +1 I been using the latest portage for a long time too. I don't recall any problems with it and the new features sure do help. If you keyword portage, you need to do the same for its friends. Mainly gentoolkit and eix. They seem to go together better. If you run one without the other, it can do some weird things. Dale :-) :-)
Re: [gentoo-user] ~amd64 - my experience so far...
Am 12.04.2010 14:57, schrieb Alan McKinnon: [...] 2. when devs commit to ~arch, they tend to run ~arch on their test boxes. Issues are easy to spot and get fixed quickly. If you have a mixture of the two, then you have a combination that no-one but you is using, and it will not have been tested. The odds are good that you will often run into problems that are hard to trace (conflicting versions of packages). Running ~arch is actually more stable than a mixture as many folk have those packages and there are more eyeballs on it. Hi, someone always brings that up. I think it might be right when mixing packages randomly. But not everybody is doing that. Let's say: I only like to have personas for firefox. Unmasking firefox, xulrunner, nss and two more will not bring you in the problem mentioned. In general I believe this is true for any program as long as it doesn't need a general library or anything like that unmasked. kh
Re: [gentoo-user] Trying to use ndiswrapper caused a hell of trouble: no suspend and wl doesn't autoload
No, I haven't. I've also checked all files in /etc/modprobe.d/,
/etc/modules.d/ and /etc/{modules,modprobe}.conf to see if it isn't
blacklisted. I have checked the rc files yet, but I haven't changed
anything. Just to be sure, I grepped for wl, and it's not
blacklisted. ndiswrapper does alias a lot of device names to itself in
modprobe.conf, although I removed it completely.
On Mon, Apr 12, 2010 at 3:13 PM, Neil Bothwick n...@digimed.co.uk wrote:
On Mon, 12 Apr 2010 12:47:26 +0300, Yoav Luft wrote:
I have problems to connect to WPA wireless networks, and it seemed
like those were driver related, so I've tried running ndiswrapper.
After I failed to get better (or any) performance with it, I tried to
revert to the previous settings, but at first the system wouldn't even
boot. I've booted with an older kernel for which I haven't build
neither ndiswrapper or wl, and removed ndiswrapper completely. But
ever since, wl isn't loaded automatically (it does load if I load it
manually
When you tried ndiswrapper, did you blacklist wl, or put something
in /etc/rc.conf to stop it loading?
--
Neil Bothwick
Evolution stops when stupidity is no longer fatal!
Re: [gentoo-user] Boot speedup
On 12. 4. 2010 14:36, Hinko Kocevar wrote: I've added ACCEPT_KEYWORDS=~x86 to /etc/make.conf. Will it be enough to (re-)build the baselayout and openrc and its closest dependencies (41 packages)? Or do I need to perform complete system upgrade (~900 packages) now that ACCEPT_KEYWORDS is present? if you are using ACCEPT_KEYWORDS=~x86 in /etc/make.conf you should do all 900 packages. Crap. I though there will be some other simpler way of doing this. I guess I'll leave as-is, at 45 second boot, since I don't want to compromise my current setup with 'testing' packages where I don't want/need them.. OMG, why 41 or even 900 packages? There's no need to accept ~x86 globaly. IIRC, you need ~x86 only for openrs stuff. I have this in my /etc/package.keywords (everything else is stable!): sys-apps/makedev ~amd64 sys-apps/openrc ~amd64 sys-apps/baselayout ~amd64 sys-apps/sysvinit ~amd64 Shift to baselayout2 was really simple and it works like charm. Actually, I wonder why is baselayout2 still ~x86/~amd64? Seems quite stable to me, never had any problem with it in the last year... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] Re: iptables - do I need the nat table?
On Mon, Apr 12, 2010 at 8:31 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2010-04-11 9:20 AM, Graham Murray wrote: Tanstaafl tansta...@libertytrek.org writes: I'm a bit clueless when it comes to firewalls, and have no idea what these numbers mean/do: *raw :PREROUTING ACCEPT [4911:886011] :OUTPUT ACCEPT [4546:2818732] COMMIT The numbers are [packets:bytes] which match the rule or table concerned. Ok, so... I still don't know what they *mean*... ie, is this a hole in my firewall? What is the raw table used for, in plain english? More importantly though... When I try to remove the nat and raw tables from my firewall, they don't go away. I have always kept my rules in a separate file, and when I want to make changes, I change the external file, then do iptables-restore /path/to/iptables-current. (My rule set is very small, so this only takes a second or two, so its not/never been a problem) I've been doing it this way for a long time, and all other changes I have ever made - eg, opening a certain port for a certain host - work fine, but, when I comment out the raw and nat tables, then restore the rules, then do iptables-save path/to/iptables-current-dump, the examined file still shows the raw and nat tables loaded... ??? Here is a very useful book. I think he is the expert. He will answer email. LINUX FIREWALLS Attack Detection and Response with iptables, psad, and fwsnort by Michael Rash ISBN-10: 1-59327-141-7 ISBN-13: 978-1-59327-141-1 No Starch Press, Inc. 555 De Haro Street, Suite 250, San Francisco, CA 94107 phone: 415.863.9900; fax: 415.863.9950; i...@nostarch.com; www.nostarch.com Librar y of Congress Cataloging-in-Publication Data Rash, Michael. Linux firewalls : attack detection and response with iptables, psad, and fwsnort / Michael Rash. p. cm. Includes index. ISBN-13: 978-1-59327-141-1 ISBN-10: 1-59327-141-7 1. Computers--Access control. 2. Firewalls (Computer security) 3. Linux. I. Title. QA76.9.A25R36 2007 005.8--dc22 2006026679 -- If we can but prevent the government from wasting the labours of the people, under the pretence of taking care of them, they must become happy. - Thomas Jefferson
Re: [gentoo-user] X11 and HP2475w: First steps?
On Mon, Apr 12, 2010 at 12:18 PM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Sat, Apr 10, 2010 at 3:21 AM, meino.cra...@gmx.de wrote: Hi, before damaging delicate electronic equipment I want to ask, what the best way is to switch from a 1600x1200 pixel analogous Iiyama monitor to an Flat panel HP2475w (LCD) with 1980x1200 pixel monitor? Graphics card is a (info via lspci): nVidia Corporation G73 [GeForce 7600 GT] (rev a2) With one analog and one digital output. Thank you very much for any help in advance! If you're using binary nvidia driver I think it should autodetect your monitor and everything should be fine... no need to specific modelines or anything like that (however if you have done that with your old monitor you may need to remove it). I switch between monitors often and it Just Works(tm). :) If you use framebuffer maybe you'll need to edit your grub config to use a different mode, but LCD usually just scales invalid modes to fit the screen anyway. I don't think you should worry about damaging it. LCD monitors have to have the correct settings or they won't work. You can damage them. You probably have your system set up to detect your hardware just like a LiveCD does. -- If we can but prevent the government from wasting the labours of the people, under the pretence of taking care of them, they must become happy. - Thomas Jefferson
[gentoo-user] kde4-menu updating tool not working
Hello, My menu updating tool for kde4 does not seem to work, any suggestions of fixes? James
Re: [gentoo-user] Switching to unstable
On Mon, Apr 12, 2010 at 12:06 AM, Marc Joliet mar...@gmx.de wrote: Am Sun, 11 Apr 2010 17:13:26 -0700 schrieb Mark Knecht markkne...@gmail.com: On Sun, Apr 11, 2010 at 5:00 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 11 Apr 2010 16:11:53 -0700, Mark Knecht wrote: Doing system first makes good sense. Then you can update your config files, follow the openrc update etc and then reboot. The world part of the update will take quite a while, especially if you use KDE or GNOME. hehe Less than most PC. It's an i7-980x with 24GB of RAM with RAID1. Gah, I'm getting PC envy ;-) ! A couple of packages in this OpenRC upgrade aren't building. I hope they are less important. So far groff and help2man have failed so I did --resume --skip-first and moved on for now. Just a note: you can also specify --keep-going and portage will do that for you and even recalculate the dependencies before continuing. After it's done, it gives you a message listing the packages that failed. Thanks for pointing that out. When doing a long set it means I don't have to keep coming in here to make sure it's doing the most it can. Nice addition. Cheers, Mark
Re: [gentoo-user] ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 10:45 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: I'm not a gnome user but I can try this if you want (135 packages to emerge in my case), or if you have more specific info about which part doesn't build I can try only the specifics. I went ahead and emerged gnome-base/gnome-2.28.2 while I was at lunch. All packages emerged properly without any issues. So the good news is there's nothing apparently wrong with ~amd64 in general, and it's probably a configuration difference between my system and yours, or maybe growing pains if you have still got some packages at amd64 and some at ~amd64. If you'd like to compare set-ups I'd be happy to try to help you get it sorted out (either on list or in email).
Re: [gentoo-user] Re: VirtualBox bridge mode eth0
On Thursday 08 April 2010 14:45:49 Joseph wrote: On 04/08/10 13:40, Nikos Chantziaras wrote: On 04/08/2010 07:11 AM, Joseph wrote: I've activated Network adapter in VirtualBox (running Windows XP) but I it is not working. It works only in NAT mode not in Bridge mode. The worst part is when I enable bridge mode on second adapter the keyboard lock up, so I need to reboot the box :-/ I've copied the VM into my other box and VirtualBox Network part is working in both Bridge and NAT mode. So I can not seem to understand why it is working on one box but not the other. Does it have something to do with Promiscuous Mode? Promiscuous Mode is needed for bridging to work. This is why NAT mode is preferable, btw, unless you have a good reason to use bridging. How to check if network card is set/support promiscuose mode? I know to set it is: ifconfig eth0 promisc If you run ifconfig eth0 it should show you in the details of the interface if it is running in promiscuous mode. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] X11 and HP2475w: First steps?
On Mon, Apr 12, 2010 at 12:38 PM, stosss sto...@gmail.com wrote: On Mon, Apr 12, 2010 at 12:18 PM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Sat, Apr 10, 2010 at 3:21 AM, meino.cra...@gmx.de wrote: Hi, before damaging delicate electronic equipment I want to ask, what the best way is to switch from a 1600x1200 pixel analogous Iiyama monitor to an Flat panel HP2475w (LCD) with 1980x1200 pixel monitor? Graphics card is a (info via lspci): nVidia Corporation G73 [GeForce 7600 GT] (rev a2) With one analog and one digital output. Thank you very much for any help in advance! If you're using binary nvidia driver I think it should autodetect your monitor and everything should be fine... no need to specific modelines or anything like that (however if you have done that with your old monitor you may need to remove it). I switch between monitors often and it Just Works(tm). :) If you use framebuffer maybe you'll need to edit your grub config to use a different mode, but LCD usually just scales invalid modes to fit the screen anyway. I don't think you should worry about damaging it. LCD monitors have to have the correct settings or they won't work. You can damage them. True, I was only thinking about resolution but if he is manually forcing sync rates then anything can happen. :) You probably have your system set up to detect your hardware just like a LiveCD does. Well like I said, if he is using nvidia-drivers he can leave the configuration empty and it'll use the default mode which is nvidia-auto-select, which reads EDID from his new monitor and configure everything properly without any trouble. Auto detecting monitor capabilities is the default action unless you've specifically told it to do otherwise.
Re: [gentoo-user] Re: ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 6:07 AM, walt w41...@gmail.com wrote:
On 04/12/2010 05:35 AM, Mark Knecht wrote:
Between xfce4 gnome I've seen about a dozen packages fail to build
this morning and haven't yet checked bug reports.
Let's start with xfce4 then because it's much smaller than gnome. What
fails to build, and with what errors?
I actually use gnome, so I could probably give you more help with that.
I haven't seen any build failures on my ~amd64 machine lately, so there
must be a fairly basic problem on your machine if you are seeing that
many build failures. Some specific error messages would help, though.
OK, let's start with xfce4-meta because there was only one failure.
eix-update was done this morning and emerge -DuN @system is clean
using ~arch in make.conf. I'll paste make.conf emerge --info at the
end of this message
cruncher ~ # emerge -pvDuN @system
These are the packages that would be merged, in order:
Calculating dependencies... done!
Total: 0 packages, Size of downloads: 0 kB
cruncher ~ #
cruncher ~ # emerge -pvDuN xfce4-meta
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] dev-perl/glib-perl-1.222 [1.200] 0 kB
[ebuild N] xfce-base/xfce4-meta-4.6.1 USE=session -minimal 0 kB
Total: 2 packages (1 upgrade, 1 new), Size of downloads: 0 kB
cruncher ~ #
cruncher ~ # emerge -DuN xfce4-meta
Calculating dependencies... done!
Verifying ebuild manifests
Starting parallel fetch
Emerging (1 of 2) dev-perl/glib-perl-1.222
* Glib-1.222.tar.gz RMD160 SHA1 SHA256 size ;-) ...
[ ok ]
* checking ebuild checksums ;-) ...
[ ok ]
* checking auxfile checksums ;-) ...
[ ok ]
* checking miscfile checksums ;-) ...
[ ok ]
* CPV: dev-perl/glib-perl-1.222
* REPO: gentoo
* USE: amd64 elibc_glibc kernel_linux multilib userland_GNU
Unpacking source...
Unpacking Glib-1.222.tar.gz to
/var/tmp/portage/dev-perl/glib-perl-1.222/work
Source unpacked in /var/tmp/portage/dev-perl/glib-perl-1.222/work
Preparing source in
/var/tmp/portage/dev-perl/glib-perl-1.222/work/Glib-1.222 ...
Source prepared.
Configuring source in
/var/tmp/portage/dev-perl/glib-perl-1.222/work/Glib-1.222 ...
* Using ExtUtils::MakeMaker
Can't locate ExtUtils/Depends.pm in @INC (@INC contains:
/usr/lib64/perl5/site_perl/5.10.1/x86_64-linux
/usr/lib64/perl5/site_perl/5.10.1 /usr/lib64/perl5/site_perl
/usr/lib64/perl5/vendor_perl/5.10.1/x86_64-linux
/usr/lib64/perl5/vendor_perl/5.10.1 /usr/lib64/perl5/vendor_perl
/usr/lib64/perl5/5.10.1/x86_64-linux /usr/lib64/perl5/5.10.1 .) at
(eval 6) line 1.
BEGIN failed--compilation aborted at (eval 6) line 1.
Checking if your kit is complete...
Looks good
MakeMaker FATAL: prerequisites not found.
ExtUtils::Depends not installed
Please install these modules first and rerun 'perl Makefile.PL'.
* ERROR: dev-perl/glib-perl-1.222 failed:
* Unable to build! (are you using USE=build?)
*
* Call stack:
* ebuild.sh, line 48: Called src_configure
* environment, line 2616: Called perl-module_src_configure
* environment, line 2362: Called perl-module_src_prep
* environment, line 2423: Called die
* The specific snippet of code:
* perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor
INSTALLMAN3DIR='none' DESTDIR=${D} ${myconf} ${pm_echovar} ||
die Unable to build! (are you using USE=\build\?);
*
* If you need support, post the output of 'emerge --info
=dev-perl/glib-perl-1.222',
* the complete build log and the output of 'emerge -pqv
=dev-perl/glib-perl-1.222'.
* The complete build log is located at
'/var/tmp/portage/dev-perl/glib-perl-1.222/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/dev-perl/glib-perl-1.222/temp/environment'.
* S: '/var/tmp/portage/dev-perl/glib-perl-1.222/work/Glib-1.222'
Failed to emerge dev-perl/glib-perl-1.222, Log file:
'/var/tmp/portage/dev-perl/glib-perl-1.222/temp/build.log'
That failure is not unlike many others I saw emerging other things.
Maybe we can find the error of my ways and I can move forward.
BTW - The -cups -java flags doesn't mean I don't want cups and java. I
found previously that putting those flags on the individual packages
that I wanted cups and java support reduced the number of packages
emerged during emerge -e @system and meant I could update @system more
often and faster, and then work on @world at more quiet times. It did
not change the number of packages emerged, just whether they were
called in during @system or @world.
Thanks,
Mark
make.conf:
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
CFLAGS=-O2 -march=native -pipe
#Safe CFlags for the Core-i7 (web info) saved for reference
#CFLAGS=-march=core2 -msse4 -mcx16 -msahf -O2 -pipe
CXXFLAGS=${CFLAGS}
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult
Re: [gentoo-user] Re: ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 1:44 PM, Mark Knecht markkne...@gmail.com wrote: Checking if your kit is complete... Looks good MakeMaker FATAL: prerequisites not found. ExtUtils::Depends not installed If part of your transition was upgrading from perl 5.8 to 5.10 you need to run perl-cleaner like the ewarn says in the perl ebuild. If you didn't do that yet then maybe that's the cause. /usr/sbin/perl-cleaner --all Otherwise if you've already done that, I would try unmerging and emerging the following packages (if they are installed): Archive-Tar Digest-SHA CPAN CPANPLUS Encode ExtUtils-MakeMaker Module-Build Module-CoreList PodParser Test-Harness podlators
Re: [gentoo-user] Re: ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 1:57 PM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Apr 12, 2010 at 1:44 PM, Mark Knecht markkne...@gmail.com wrote: Checking if your kit is complete... Looks good MakeMaker FATAL: prerequisites not found. ExtUtils::Depends not installed If part of your transition was upgrading from perl 5.8 to 5.10 you need to run perl-cleaner like the ewarn says in the perl ebuild. If you didn't do that yet then maybe that's the cause. /usr/sbin/perl-cleaner --all Otherwise if you've already done that, I would try unmerging and emerging the following packages (if they are installed): Archive-Tar Digest-SHA CPAN CPANPLUS Encode ExtUtils-MakeMaker Module-Build Module-CoreList PodParser Test-Harness podlators Oops, sorry, those are module names not package names.
Re: [gentoo-user] Re: ~amd64 - my experience so far...
Mark Knecht writes: OK, let's start with xfce4-meta because there was only one failure. eix-update was done this morning and emerge -DuN @system is clean using ~arch in make.conf. I'll paste make.conf emerge --info at the end of this message [...] Source prepared. Configuring source in /var/tmp/portage/dev-perl/glib-perl-1.222/work/Glib-1.222 ... * Using ExtUtils::MakeMaker Can't locate ExtUtils/Depends.pm in @INC (@INC contains: [...] MakeMaker FATAL: prerequisites not found. ExtUtils::Depends not installed Please install these modules first and rerun 'perl Makefile.PL'. wo...@weird ~ $ equery b $( locate ExtUtils/Depends.pm ) * Searching for /usr/lib/perl5/vendor_perl/5.10.1/ExtUtils/Depends.pm ... dev-perl/extutils-depends-0.302 (/usr/lib/perl5/vendor_perl/5.10.1/ExtUtils/Depends.pm) So I guess you do not have dev-perl/extutils-depends installed? In this case, emerge it, and let's hope all the other errors are similar ones. Wonko
Re: [gentoo-user] Re: ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 11:57 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Apr 12, 2010 at 1:44 PM, Mark Knecht markkne...@gmail.com wrote: Checking if your kit is complete... Looks good MakeMaker FATAL: prerequisites not found. ExtUtils::Depends not installed If part of your transition was upgrading from perl 5.8 to 5.10 you need to run perl-cleaner like the ewarn says in the perl ebuild. If you didn't do that yet then maybe that's the cause. /usr/sbin/perl-cleaner --all OK, it appears that this was part of the issue. Don't know how I missed the warning other than there were a number of things and it must have been in there somewhere. This allowed me to do emerge -C kde xfce4-meta and get old stuff off. Now emerge -DuN @world is clean with 390 packages currently installed. I cleaned everything out of my user directory just to ensure that any problems aren't caused by old config files. First step behind me. Now, at this point I started looking at emerging xfce4-meta again, it failed with messages about rebuilding xorg-server. When I attempted that I got error messages about invalid gcc profiles which led me to discover this problem: cruncher ~ # gcc-config -l * gcc-config: Active gcc profile is invalid! [1] x86_64-pc-linux-gnu-4.4.3 cruncher ~ # gcc-config 1 * Switching native-compiler to x86_64-pc-linux-gnu-4.4.3 ... * gcc-config: Active gcc profile is invalid! * Your gcc has a bug with GCC_SPECS. * Please re-emerge gcc. * http://bugs.gentoo.org/68395 Regenerating /etc/ld.so.cache... [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * # source /etc/profile cruncher ~ # The bug report suggested the above idea but I couldn't set the profile to '1' so I did emerge -1 gcc. Hey, at least it lets me watch 12 processor cores max out at 100%. ;-) 5 minutes later cruncher ~ # gcc-config -l [1] x86_64-pc-linux-gnu-4.4.3 * cruncher ~ # Now the profile is set and emerge -DuN xfce4-meta was clean. Progress, I think, but when I try to log in I get logged out automatically with a message to look at the .xession-errors file: cruncher mark # cat .xsession-errors /etc/X11/gdm/Xsession: Beginning session setup... /etc/X11/gdm/Xsession: Cannot find Xclients /etc/X11/gdm/Xsession: line 203: exec: xterm: not found cruncher mark # cruncher mark # eix -I xterm No matches found. cruncher mark # updatedb cruncher mark # slocate xterm | grep bin cruncher mark # Unmet dependencies? Because I'm paranoid about gcc problems and I need to run some errands I'm going to send this now and start an emerge -e @world. That should finish up in about 90 minutes I think (I'll time it for fun) and I'll try again after that. Thanks, Mark
Re: [gentoo-user] Switching to unstable
On 2010-04-12 12:23 PM, Dale wrote: +1 I been using the latest portage for a long time too. I don't recall any problems with it and the new features sure do help. If you keyword portage, you need to do the same for its friends. Mainly gentoolkit and eix. They seem to go together better. If you run one without the other, it can do some weird things. Ok, I'm seriously considering it... thanks. Are those really the only 3? Thanks again... -- Charles
Re: [gentoo-user] Re: ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 4:03 PM, Mark Knecht markkne...@gmail.com wrote: cruncher mark # cat .xsession-errors /etc/X11/gdm/Xsession: Beginning session setup... /etc/X11/gdm/Xsession: Cannot find Xclients /etc/X11/gdm/Xsession: line 203: exec: xterm: not found cruncher mark # cruncher mark # eix -I xterm No matches found. cruncher mark # updatedb cruncher mark # slocate xterm | grep bin cruncher mark # Unmet dependencies? In my system, xterm is a dependency of xinit, which in turn is a dependency of xorg-server. That is weird and I don't know how it would not be installed (assuming you've got xorg-server installed).
Re: [gentoo-user] Boot speedup
Florian Philipp writes: Am 12.04.2010 11:02, schrieb Hinko Kocevar: Can boot be sped up even more? The fastest way to boot is not to boot at all. Just use Suspend2Disk or SuspendToRam. Take a look at TuxOnIce and hibernate-script. Unless something is broken, I hardly ever reboot. I wonder why this seems to be working for everyone but me... I tried TuxOnIce for various times, with different systems, for years now, and still no real success. Well, it works sometimes on my desktop PC, but I have to issue the hibernate command up to ten times for this, and sometimes it still does not hibernate. And I also experience that trying to hibernate sometimes freezes the system, or has weird side effects. But luckily, at least hibernate-ram suddenly seems to work well, and I'm sticking to that now. Wonko
Re: [gentoo-user] Trying to use ndiswrapper caused a hell of trouble: no suspend and wl doesn't autoload
On Mon, 12 Apr 2010 19:52:19 +0300, Yoav Luft wrote:
No, I haven't. I've also checked all files in /etc/modprobe.d/,
/etc/modules.d/ and /etc/{modules,modprobe}.conf to see if it isn't
blacklisted. I have checked the rc files yet, but I haven't changed
anything. Just to be sure, I grepped for wl, and it's not
blacklisted. ndiswrapper does alias a lot of device names to itself in
modprobe.conf, although I removed it completely.
modprobe.conf is autogenerated from the contents of modprobe.d, and any
file installed in there with ndiswrapper won't have been removed when you
unmerged it. Check you haven't got a file in there setting up the
ndiswrapper aliases.
--
Neil Bothwick
In 1750 Issac Newton became discouraged when he fell up a flight of
stairs.
signature.asc
Description: PGP signature
Re: [gentoo-user] Re: ~amd64 - my experience so far...
On Mon, Apr 12, 2010 at 2:14 PM, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Mon, Apr 12, 2010 at 4:03 PM, Mark Knecht markkne...@gmail.com wrote: cruncher mark # cat .xsession-errors /etc/X11/gdm/Xsession: Beginning session setup... /etc/X11/gdm/Xsession: Cannot find Xclients /etc/X11/gdm/Xsession: line 203: exec: xterm: not found cruncher mark # cruncher mark # eix -I xterm No matches found. cruncher mark # updatedb cruncher mark # slocate xterm | grep bin cruncher mark # Unmet dependencies? In my system, xterm is a dependency of xinit, which in turn is a dependency of xorg-server. That is weird and I don't know how it would not be installed (assuming you've got xorg-server installed). Really? Doesn't seem to be true here. It doesn't seem to be installed because of xorg-server nor included in xorg-server: cruncher ~ # emerge -ep xorg-server | grep xterm cruncher ~ # equery files xorg-server | grep xterm cruncher ~ # I see it as a separate package: cruncher ~ # eix -c xterm [N] lxde-base/lxterminal ((~)0.1.7): Lightweight vte-based tabbed terminal emulator for LXDE [N] net-misc/ajaxterm ((~)0.10): Ajaxterm is a web based terminal [N] x11-misc/xtermcontrol ((~)2.10): xtermcontrol enables dynamic control of XFree86 xterm properties [N] x11-terms/cxterm (--): A Chinese/Japanese/Korean X-Terminal [N] x11-terms/roxterm ((~)1.16.3): A terminal emulator designed to integrate with the ROX environment [N] x11-terms/xterm ((~)255): Terminal Emulator for X Windows Found 6 matches. cruncher ~ # Very strange. Flag issue of some type? I emerged it explicitly and it let me start an xsession which was only an xterm. When I typed exit X locked up and didn't go back to the login screen. It's a mess. So obviously I'm back from my errand and unfortunately my emerge -e @world failed with another perl failure. cruncher ~ # time emerge -e @world SNIP * Messages for package x11-libs/libdrm-2.4.20: * libdrm's ABI may have changed without change in library name * Please rebuild media-libs/mesa, x11-base/xorg-server and * your video drivers in x11-drivers/*. * Messages for package dev-lang/perl-5.10.1: * ERROR: dev-lang/perl-5.10.1 failed: * emake failed * * Call stack: * ebuild.sh, line 48: Called src_compile * environment, line 2844: Called _eapi2_src_compile * ebuild.sh, line 640: Called die * The specific snippet of code: * emake || die emake failed * * If you need support, post the output of 'emerge --info =dev-lang/perl-5.10.1', * the complete build log and the output of 'emerge -pqv =dev-lang/perl-5.10.1'. * The complete build log is located at '/var/tmp/portage/dev-lang/perl-5.10.1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-lang/perl-5.10.1/temp/environment'. * S: '/var/tmp/portage/dev-lang/perl-5.10.1/work/perl-5.10.1' * Regenerating GNU info directory index... * Processed 103 info files. real23m38.050s user28m16.088s sys 4m42.603s cruncher ~ # Not that this should necessarily be posted to this list, but since we've started I'll continue along until you tell me to go away. The last two are huge so I'll only post the start and end for now. Keep in mind that ALL of this worked in stable. This is only since going to ~amd64 that I've seen any of this. cruncher ~ # emerge --info =dev-lang/perl-5.10.1 Portage 2.2_rc67 (default/linux/amd64/10.0/desktop, gcc-4.4.3, glibc-2.11-r1, 2.6.34-rc3 x86_64) = System Settings = System uname: linux-2.6.34-rc3-x86_64-intel-r-_core-tm-_i7_cpu_x_9...@_3.33ghz-with-gentoo-2.0.1 Timestamp of tree: Mon, 12 Apr 2010 10:45:01 + app-shells/bash: 4.1_p5 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.5-r1, 3.1.2-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox:2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1 sys-devel/gcc: 4.4.3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.33 ACCEPT_KEYWORDS=amd64 ~amd64 ACCEPT_LICENSE=* -...@eula dlj-1.1 PUEL CBUILD=x86_64-pc-linux-gnu CFLAGS=-O2 -march=native -pipe CHOST=x86_64-pc-linux-gnu CONFIG_PROTECT=/etc /usr/share/X11/xkb CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo CXXFLAGS=-O2 -march=native -pipe DISTDIR=/usr/portage/distfiles EMERGE_DEFAULT_OPTS=--with-bdeps y FEATURES=assume-digests buildpkg distlocks fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch GENTOO_MIRRORS=http://gentoo.osuosl.org/ LDFLAGS=-Wl,-O1 LINGUAS=en MAKEOPTS=-j13 PKGDIR=/usr/portage/packages PORTAGE_CONFIGROOT=/ PORTAGE_RSYNC_OPTS=--recursive --links
