Re: [gentoo-user] Switching to unstable
On Tuesday 13 April 2010 16:49:44 Helmut Jarausch wrote: On 13 Apr, Peter Humphrey wrote: On Monday 12 April 2010 16:55:38 Paul Hartman wrote: 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. There was a problem with its preserved-rebuild feature for a while; several people reported here that they were running it and being told they still needed to run it again. As far as I know, that's the only thing preventing release of v2, and I think it's been fixed anyway. No, I don't think so. Just recently, I had to unmerge then emerge wxpython since emerge @preserved-rebuild couldn't solve it itself. One more buglet. When doing emerge -j no of simultaneous processes - which is a very useful feature on a multicore machine - sometime a package just stops to build (which is reported as failing package). Just emerge it again. So, I'd say some new features are not ready, yet, but still very useful as they are. Helmut. Those sound like ebuild and build system bugs, not something with portage itself. Especially the -j bug - sounds like a race condition caused by a pathetic Makefile -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Switching to unstable
Tanstaafl wrote: 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... Those are the most commonly used portage type packages that I use anyway. I know recently I had portage running on the latest then equery got a tummy ache and sort of puked at me. So, I had to get the latest for equery too. Then I needed the latest eix as well. It's been pretty much happy since then tho. It works fine tho. They seem to test portage pretty well before it hits the tree. Dale :-) :-)
Re: [gentoo-user] Switching to unstable
On Monday 12 April 2010 16:55:38 Paul Hartman wrote: 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. There was a problem with its preserved-rebuild feature for a while; several people reported here that they were running it and being told they still needed to run it again. As far as I know, that's the only thing preventing release of v2, and I think it's been fixed anyway. -- Rgds Peter.
Re: [gentoo-user] Switching to unstable
On 13 Apr, Peter Humphrey wrote: On Monday 12 April 2010 16:55:38 Paul Hartman wrote: 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. There was a problem with its preserved-rebuild feature for a while; several people reported here that they were running it and being told they still needed to run it again. As far as I know, that's the only thing preventing release of v2, and I think it's been fixed anyway. No, I don't think so. Just recently, I had to unmerge then emerge wxpython since emerge @preserved-rebuild couldn't solve it itself. One more buglet. When doing emerge -j no of simultaneous processes - which is a very useful feature on a multicore machine - sometime a package just stops to build (which is reported as failing package). Just emerge it again. So, I'd say some new features are not ready, yet, but still very useful as they are. Helmut. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany
Re: [gentoo-user] Switching to unstable
On Tuesday 13 April 2010 15:49:44 Helmut Jarausch wrote: On 13 Apr, Peter Humphrey wrote: As far as I know, that's the only thing preventing release of v2, and I think it's been fixed anyway. No, I don't think so. Just recently, I had to unmerge then emerge wxpython since emerge @preserved-rebuild couldn't solve it itself. Ah. I supposed that it had been fixed as I haven't seen it recently. One more buglet. When doing emerge -j no of simultaneous processes - which is a very useful feature on a multicore machine - sometime a package just stops to build (which is reported as failing package). Just emerge it again. I've noticed that too. I don't know where the problem lies, but as you say, it's easily evaded. So, I'd say some new features are not ready, yet, but still very useful as they are. Agreed. -- Rgds Peter.
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
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] 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] 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] 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] 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] Switching to unstable
On Sun, 11 Apr 2010 20:36:37 +0200, Damian wrote: The reason for doing so is that what is considered as unstable as been regarded as stable releases for the developers, and the truth is that the problems I got for using outdated software were more that the ones I had for using unstable versions. That's because what you describe as unstable has nothing to do with stability of the software. ~arch is testing ebuilds, they are unstable in that they change more often, but as you say, the upstream software is considered fit for use. Thus, I'm thinking about switching all of my system to the unstable branch. But first I want to be sure that this is reasonable given the problems I described before. Can you provide me some useful advice according to your experience? Switching to testing is as easy as changing ACCEPT_KEYWORDS in make.conf and doing emerge -uaDN @world. Switching back is less easy, but if this is what you want to do, then go for it. I have run testing for years, with far less problems than some people running mixed arch systems. -- Neil Bothwick CPU: (n.) acronym for Central Purging Unit. A device which discards or distorts data sent to it, sometimes returning more data and sometimes merely over-heating. signature.asc Description: PGP signature
Re: [gentoo-user] Switching to unstable
On Sunday 11 April 2010 20:36:37 Damian wrote: Hello, I've been using the gentoo stable branch since I began with this distro (around 4 years ago), but lately I've been unmasking almost all packages I use in my daily work (emacs, firefox, gnome*, xmonad, etc). The reason for doing so is that what is considered as unstable as been regarded as stable releases for the developers, and the truth is that the problems I got for using outdated software were more that the ones I had for using unstable versions. Thus, I'm thinking about switching all of my system to the unstable branch. But first I want to be sure that this is reasonable given the problems I described before. Can you provide me some useful advice according to your experience? Thanks in advance, Damian. I run ~arch everywhere, and I seldom have trouble. The hiccups that do occur are usually blockers between the latest version of something and the previous version, very easy to fix if you have read the portage man pages. But these days portage knows how to deal with that, so it doesn't expect you to hunt, search, unmerge, merge. It just tells you what it will do and waits for you to tell it to get on with it. Nice :-) Reading this list for many years leads me to conclude: - running ~arch is OK if you can drive portage. Few breakages, on the whole they are easily fixed - running arch. Tends to run a bit behind latest stuff out there, but stable. - mixing the two. No, this is not something you want to do. You are doing it now, so just update make.conf to use ~arch and be done with it. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Switching to unstable
Damian writes: Thus, I'm thinking about switching all of my system to the unstable branch. But first I want to be sure that this is reasonable given the problems I described before. Can you provide me some useful advice according to your experience? I have asked a similar question here, I suggest you read the thread [*]. I did not regret the switch and would also suggest running ~arch. Beware the update to openrc, and do what the elog messages tell you to do before rebooting. Wonko [*] http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg94206.html
Re: [gentoo-user] Switching to unstable
On Sun, Apr 11, 2010 at 12:43 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 11 Apr 2010 20:36:37 +0200, Damian wrote: The reason for doing so is that what is considered as unstable as been regarded as stable releases for the developers, and the truth is that the problems I got for using outdated software were more that the ones I had for using unstable versions. That's because what you describe as unstable has nothing to do with stability of the software. ~arch is testing ebuilds, they are unstable in that they change more often, but as you say, the upstream software is considered fit for use. Thus, I'm thinking about switching all of my system to the unstable branch. But first I want to be sure that this is reasonable given the problems I described before. Can you provide me some useful advice according to your experience? Switching to testing is as easy as changing ACCEPT_KEYWORDS in make.conf and doing emerge -uaDN @world. Switching back is less easy, but if this is what you want to do, then go for it. I have run testing for years, with far less problems than some people running mixed arch systems. -- Neil Bothwick I have a new machine that just came up yesterday. I was thinking of running ~arch on it and seeing how things work out. Seems like it's a good time to do it if I'm ever going to as I haven't started using it and it's going to get busy. If your answers are dependent on the work done then this machine is (hopefully) going to run a bunch of vmware instances at the same time. Any problem doing that under ~amd64? I've never run more than 1 in the past. This time hopefully 5 at a time. Question - after adding ~amd64 to make.conf do I then ever need anything in package.keywords again because the whole system is ~amd64? It seems that there would be some use flag changes required: cruncher ~ # emerge -pvDuN @world These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds built with USE flags to satisfy =sys-fs/udev-145[extras]. !!! One of the following packages is required to complete your request: - sys-fs/udev-151-r1 (Change USE: +extras) (dependency required by gnome-base/gvfs-1.4.3 [ebuild]) (dependency required by gnome-base/libgnome-2.28.0 [ebuild]) (dependency required by gnome-base/libbonoboui-2.24.3 [ebuild]) (dependency required by gnome-base/libgnomeui-2.24.3 [ebuild]) (dependency required by net-libs/xulrunner-1.9.2.3-r1 [ebuild]) (dependency required by www-client/mozilla-firefox-3.6.3 [ebuild]) (dependency required by @world [argument]) cruncher ~ # Will there be a lot of this before I execute the emerge? I know udev is pretty special. - Mark
Re: [gentoo-user] Switching to unstable
On Sun, Apr 11, 2010 at 2:24 PM, Mark Knecht markkne...@gmail.com wrote: On Sun, Apr 11, 2010 at 12:43 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 11 Apr 2010 20:36:37 +0200, Damian wrote: The reason for doing so is that what is considered as unstable as been regarded as stable releases for the developers, and the truth is that the problems I got for using outdated software were more that the ones I had for using unstable versions. That's because what you describe as unstable has nothing to do with stability of the software. ~arch is testing ebuilds, they are unstable in that they change more often, but as you say, the upstream software is considered fit for use. Thus, I'm thinking about switching all of my system to the unstable branch. But first I want to be sure that this is reasonable given the problems I described before. Can you provide me some useful advice according to your experience? Switching to testing is as easy as changing ACCEPT_KEYWORDS in make.conf and doing emerge -uaDN @world. Switching back is less easy, but if this is what you want to do, then go for it. I have run testing for years, with far less problems than some people running mixed arch systems. -- Neil Bothwick I have a new machine that just came up yesterday. I was thinking of running ~arch on it and seeing how things work out. Seems like it's a good time to do it if I'm ever going to as I haven't started using it and it's going to get busy. If your answers are dependent on the work done then this machine is (hopefully) going to run a bunch of vmware instances at the same time. Any problem doing that under ~amd64? I've never run more than 1 in the past. This time hopefully 5 at a time. Question - after adding ~amd64 to make.conf do I then ever need anything in package.keywords again because the whole system is ~amd64? It seems that there would be some use flag changes required: cruncher ~ # emerge -pvDuN @world These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds built with USE flags to satisfy =sys-fs/udev-145[extras]. !!! One of the following packages is required to complete your request: - sys-fs/udev-151-r1 (Change USE: +extras) (dependency required by gnome-base/gvfs-1.4.3 [ebuild]) (dependency required by gnome-base/libgnome-2.28.0 [ebuild]) (dependency required by gnome-base/libbonoboui-2.24.3 [ebuild]) (dependency required by gnome-base/libgnomeui-2.24.3 [ebuild]) (dependency required by net-libs/xulrunner-1.9.2.3-r1 [ebuild]) (dependency required by www-client/mozilla-firefox-3.6.3 [ebuild]) (dependency required by @world [argument]) cruncher ~ # Will there be a lot of this before I execute the emerge? I know udev is pretty special. - Mark OK - I walked through the list until it told me things were OK. These are the use flag additions I had to add: sys-fs/udev extras gnome-base/gvfs gdu sys-apps/parted device-mapper sys-auth/consolekit policykit net-libs/opal sip net-libs/ptlib wav x11-base/xorg-server kdrive A couple more questions: 1) I don't see any mention of hald dbus in the upgrade guide. I currently have them turned on. Are they still necessary? I know hald is going away one of these days. Is it too early for me to dump it. Possibly dump hald before the upgrade, make sure everything is consistent, and then do the ~amd64 work? 2) Any problem if I do emerge -DuN @system and then make the changes in the upgrade guide followed by @world? I've turned of xdm. I don't have a UPS on this system yet so @system would shrink the window of a power outage causing me problems. (It's pouring rain here today. It will likely happen no matter what) ;-) Thanks, Mark
Re: [gentoo-user] Switching to unstable
On Sun, 11 Apr 2010 14:24:18 -0700, Mark Knecht wrote: I have a new machine that just came up yesterday. I was thinking of running ~arch on it and seeing how things work out. Seems like it's a good time to do it if I'm ever going to as I haven't started using it and it's going to get busy. If your answers are dependent on the work done then this machine is (hopefully) going to run a bunch of vmware instances at the same time. Any problem doing that under ~amd64? I've never run more than 1 in the past. This time hopefully 5 at a time. I have run several VMs at once in workstation. Question - after adding ~amd64 to make.conf do I then ever need anything in package.keywords again because the whole system is ~amd64? Only if you want to use packages that do not have amd64 or ~amd64 keywords. It seems that there would be some use flag changes required: That's not strictly down to the use of ~amd64, it's a change that will affect everyone in due course, you just get to find out these things that bit sooner now. -- Neil Bothwick On the other hand, you have different fingers. signature.asc Description: PGP signature
Re: [gentoo-user] Switching to unstable
On Sun, 11 Apr 2010 14:59:07 -0700, Mark Knecht wrote: 1) I don't see any mention of hald dbus in the upgrade guide. I currently have them turned on. Are they still necessary? I know hald is going away one of these days. Is it too early for me to dump it. Possibly dump hald before the upgrade, make sure everything is consistent, and then do the ~amd64 work? Don't try to second guess what the system needs, just upgrade and do a --depclean. #~Portage will let you know if anything is no longer needed. You'll probably find depclean wants to remove a few things, but hal won't be one of them. 2) Any problem if I do emerge -DuN @system and then make the changes in the upgrade guide followed by @world? I've turned of xdm. I don't have a UPS on this system yet so @system would shrink the window of a power outage causing me problems. (It's pouring rain here today. It will likely happen no matter what) ;-) 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. -- Neil Bothwick Everywhere is walking distance if you have the time. signature.asc Description: PGP signature
Re: [gentoo-user] Switching to unstable
On Sun, Apr 11, 2010 at 3:55 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 11 Apr 2010 14:59:07 -0700, Mark Knecht wrote: 1) I don't see any mention of hald dbus in the upgrade guide. I currently have them turned on. Are they still necessary? I know hald is going away one of these days. Is it too early for me to dump it. Possibly dump hald before the upgrade, make sure everything is consistent, and then do the ~amd64 work? Don't try to second guess what the system needs, just upgrade and do a --depclean. #~Portage will let you know if anything is no longer needed. You'll probably find depclean wants to remove a few things, but hal won't be one of them. OK. 2) Any problem if I do emerge -DuN @system and then make the changes in the upgrade guide followed by @world? I've turned of xdm. I don't have a UPS on this system yet so @system would shrink the window of a power outage causing me problems. (It's pouring rain here today. It will likely happen no matter what) ;-) 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. My first really nice machine in years. Thanks! Cheers, Mark -- Neil Bothwick Everywhere is walking distance if you have the time.
Re: [gentoo-user] Switching to unstable
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. Oh, is that all, I thought you had something quite fast? :P -- Neil Bothwick God is real, unless specifically declared integer. signature.asc Description: PGP signature
Re: [gentoo-user] Switching to unstable
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. Oh, is that all, I thought you had something quite fast? :P Fast for under 100 lbs of iron. I'm sure the big boys must have things much faster. Full KDE in 109 minutes seemed pretty good to me, and it's fun to watch 12 processors max out at the same time. 3 drive RAID1 for Gentoo and backups, 2 drive RAID0 for where the VMs will run. 1 extra drive in the box in case a drive goes bad one of these days. 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. If I get to the end, do the hand edits and manage to reboot then I'll do an emerge -e @system just to make sure things are really OK before dealing with @world. Thanks, Mark
Re: [gentoo-user] Switching to unstable
On Sun, Apr 11, 2010 at 5:13 PM, Mark Knecht markkne...@gmail.com wrote: SNIP 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. SNIP So it's done and I'm editing. In /etc/init.d I see a blinking link: runscript.sh - ../../sbin/runscript.sh Remove it or is there a problem? - Mark
Re: [gentoo-user] Switching to unstable
On Sun, Apr 11, 2010 at 5:22 PM, Mark Knecht markkne...@gmail.com wrote: On Sun, Apr 11, 2010 at 5:13 PM, Mark Knecht markkne...@gmail.com wrote: SNIP 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. SNIP So it's done and I'm editing. In /etc/init.d I see a blinking link: runscript.sh - ../../sbin/runscript.sh Remove it or is there a problem? - Mark So help2man won't build due to some missing perl module. I'm assuming this isn't bad enough to stop a reboot from being successful but @system is @system so no reboot until I hear something back. (Or I get bored waiting...) ;-) Cheers, Mark checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed checking for library containing dlsym... -ldl checking for library containing bindtextdomain... none required configure: error: perl module Locale::gettext required !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sys-apps/help2man-1.37.1/work/help2man-1.37.1/config.log * ERROR: sys-apps/help2man-1.37.1 failed: * econf failed * * Call stack: * ebuild.sh, line 48: Called src_compile * environment, line 2332: Called econf '--enable-nls' * ebuild.sh, line 538: Called die * The specific snippet of code: * die econf failed * * If you need support, post the output of 'emerge --info =sys-apps/help2man-1.37.1', * the complete build log and the output of 'emerge -pqv =sys-apps/help2man-1.37.1'. * The complete build log is located at '/var/tmp/portage/sys-apps/help2man-1.37.1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-apps/help2man-1.37.1/temp/environment'. * S: '/var/tmp/portage/sys-apps/help2man-1.37.1/work/help2man-1.37.1' Failed to emerge sys-apps/help2man-1.37.1, Log file: '/var/tmp/portage/sys-apps/help2man-1.37.1/temp/build.log'
Re: [gentoo-user] Switching to unstable
On Sun, Apr 11, 2010 at 5:33 PM, Mark Knecht markkne...@gmail.com wrote: SNIP So help2man won't build due to some missing perl module. I'm assuming this isn't bad enough to stop a reboot from being successful but @system is @system so no reboot until I hear something back. (Or I get bored waiting...) ;-) Cheers, Mark checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed checking for library containing dlsym... -ldl checking for library containing bindtextdomain... none required configure: error: perl module Locale::gettext required !!! Please attach the following file when seeking support: !!! /var/tmp/portage/sys-apps/help2man-1.37.1/work/help2man-1.37.1/config.log * ERROR: sys-apps/help2man-1.37.1 failed: * econf failed * * Call stack: * ebuild.sh, line 48: Called src_compile * environment, line 2332: Called econf '--enable-nls' * ebuild.sh, line 538: Called die * The specific snippet of code: * die econf failed * * If you need support, post the output of 'emerge --info =sys-apps/help2man-1.37.1', * the complete build log and the output of 'emerge -pqv =sys-apps/help2man-1.37.1'. * The complete build log is located at '/var/tmp/portage/sys-apps/help2man-1.37.1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-apps/help2man-1.37.1/temp/environment'. * S: '/var/tmp/portage/sys-apps/help2man-1.37.1/work/help2man-1.37.1' Failed to emerge sys-apps/help2man-1.37.1, Log file: '/var/tmp/portage/sys-apps/help2man-1.37.1/temp/build.log' emerge -e @system cleared that problem up and the reboot appears to have been clean. I don't know exactly what to make of the output from df. Clearly this is a new way of looking at things: cruncher ~ # df Filesystem 1K-blocks Used Available Use% Mounted on rootfs51612984 8799528 40191652 18% / /dev/root 51612984 8799528 40191652 18% / rc-svcdir 102468 956 7% /lib64/rc/init.d udev 10240 256 9984 3% /dev shm6152104 0 6152104 0% /dev/shm cruncher ~ # rootfs? /dev/root? Did I miss something in my editing? I mount /dev/md3 in fstab. It becomes something else in this environment I guess... Anyway, it rebooted cleanly and for the most part the instructions were pretty good. XFCE4 is rebuilding, I'll check that X works and then on to Gnome and KDE. Cheers, Mark
