Re: [gentoo-user] Self created initramfs cannot work
Am Samstag 27 Juni 2009 03:32:50 schrieb David Shen: I build by gentoo kernel without genkernel, and I want to create the initramfs by hand. Following is the steps I did: I also did this for some years, I could send you my setup script if you want. Nowadays I've switched to putting the stuff I had in an initramfs into /boot, which is always a separate partition on my systems. You can get that script too if you want. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Self created initramfs cannot work
yep, i'd like to learn from your script. BTW, I also put my initramfs into a separate partition /boot. On Sat, Jun 27, 2009 at 2:33 PM, Dirk Heinrichsdirk.heinri...@online.de wrote: Am Samstag 27 Juni 2009 03:32:50 schrieb David Shen: I build by gentoo kernel without genkernel, and I want to create the initramfs by hand. Following is the steps I did: I also did this for some years, I could send you my setup script if you want. Nowadays I've switched to putting the stuff I had in an initramfs into /boot, which is always a separate partition on my systems. You can get that script too if you want. Bye... Dirk -- Best Regards, David Shen http://twitter.com/davidshen84
Re: [gentoo-user] Seek advice: converting Sabayon to Gentoo ?
On Saturday 27 June 2009 00:50:15 Alan E. Davis wrote: I didn't say anything about my hardware. The main hiccough, installing gentoo, has been the ath5k module, which was at one time, I think, ath_pci. Newer kernels may support this out of the box, in a gentoo install. My Acer Aspire One running Ubuntu needs that driver. IIRC up to 2.6.27, the ath5k driver was dodgy on certain chips but since 2.6.28 things are much better. The driver is in mainline as well so you should be able to just build it on 2.6.30 and have a workable system, without any need for the madwifi proprietary driver. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Seek advice: converting Sabayon to Gentoo ?
On Saturday 27 June 2009 02:28:59 Alan E. Davis wrote: Perhaps I can just edit the existing /etc/fstab, using device names. The device numbering is inconsistent between GNU/Linux distros under the (what I presume to be) new scheme, with all devices names as /dev/sdX . Default kernel names are like that deliberately. The driver assigns a unique name in the order that devices are found, and the name depends only on whatever the author decided to give it. If you use the modern ATA subsystem to drive your disks, they get called sd*. The older drivers non-SCSI still call disks hd*. This way you get a naming scheme that is guaranteed to be unique, but with no other guarantees whatsoever (not even consistency). It's the simplest thing that could possibly work (and a very sane engineering choice actually). If that doesn't suit your needs, you can customize it with udev rules, or mount by device UUID, or mount by filesystem label. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Friday 26 June 2009 22:02:54 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? I haven't looked there yet but I will. I'm on a mission here. For this machine I want emerge -e @system to install NOTHING having to do with X11. After I get to that point, depclean'ed, revdep'ed, eix-test-obsoleted, then I'm going back to installing X from scratch. I've just gotten past the emerge -e @system part now. I'm sort of surprised the openssh shows up as part of @system, or it's getting pulled in somehow, and its default flags are dragging in X. USE=X pulls in x11-apps/xauth so you likely want to disable that flag. Sort of anal I suppose but these machine have been neglected for the last couple of years being stuck with old drivers old kernels. If I'm going to try and get the newest ati-drivers working I feel like I sort of owe it to those developers (and myself) to have as few issues hanging out as possible. Look at it this way: the only known factor that leads to easy-maintainable and sane systems for all is analness coming from the top :-) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Self created initramfs cannot work
Am Samstag 27 Juni 2009 10:25:11 schrieb David Shen: yep, i'd like to learn from your script. OK, here you are. BTW, I also put my initramfs into a separate partition /boot. Seems you misunderstood. I don't use an initramfs anymore, /boot _is_ my initramfs replacement. Whatever you put into an initramfs can as well be put into /boot. I've attached both set of scripts, just choose the one you like more. mkinitfs_script.tar.bz2 contains the script to put stuff to /boot, while mkinitramfs_script.tar.bz2 contains the script to create an initramfs for use inside the kernel (kernel+initramfs will be one file). In both cases, you should adapt the /etc/mkinit*fs/config file to your needs, just adapt the list of executables you need/want in your init*fs and run the desired script. The mkinitramfs.sh script will put everything into /usr/src/initramfs. You should configure this in your kernel config so that the kernel build system can create the image for you. The other one will put everything into /boot. Out of the box, the resulting fs will be suited for accessing / from a logical volume which may optionally be encrypted using LUKS. The init script will find out at boot time wether the LV is encrypted and will run cryptsetup to prompt for a password. Finally, you need to adapt your bootloader, depending on which approach you choose: initramfs: realroot=/dev/vg/root (* NO root=, because that's the initramfs). initfs: You'll need both root=/dev/sda1, which should be your /boot, realroot= as above and rw (this is important). BTW: Newer kernels also have a configuration option for this: CONFIG_CMDLINE. In case of further questions, just send a mail. Bye... Dirk initfs_script.tar.bz2 Description: application/bzip-compressed-tar initramfs_script.tar.bz2 Description: application/bzip-compressed-tar signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Seek advice: converting Sabayon to Gentoo ?
On Samstag 27 Juni 2009, Alan McKinnon wrote: On Saturday 27 June 2009 02:28:59 Alan E. Davis wrote: Perhaps I can just edit the existing /etc/fstab, using device names. The device numbering is inconsistent between GNU/Linux distros under the (what I presume to be) new scheme, with all devices names as /dev/sdX . Default kernel names are like that deliberately. The driver assigns a unique name in the order that devices are found, and the name depends only on whatever the author decided to give it. If you use the modern ATA subsystem to drive your disks, they get called sd*. The older drivers non-SCSI still call disks hd*. This way you get a naming scheme that is guaranteed to be unique, but with no other guarantees whatsoever (not even consistency). It's the simplest thing that could possibly work (and a very sane engineering choice actually). If that doesn't suit your needs, you can customize it with udev rules, or mount by device UUID, or mount by filesystem label. or you create a software raid setup and mount mdX. Since the kernel autoassembles the stuff you don't have to care about sdX or hdX or whateverX ;)
Re: [gentoo-user] Self created initramfs cannot work
thanks a lot On Sat, Jun 27, 2009 at 7:49 PM, Dirk Heinrichsdirk.heinri...@online.de wrote: Am Samstag 27 Juni 2009 10:25:11 schrieb David Shen: yep, i'd like to learn from your script. OK, here you are. BTW, I also put my initramfs into a separate partition /boot. Seems you misunderstood. I don't use an initramfs anymore, /boot _is_ my initramfs replacement. Whatever you put into an initramfs can as well be put into /boot. I've attached both set of scripts, just choose the one you like more. mkinitfs_script.tar.bz2 contains the script to put stuff to /boot, while mkinitramfs_script.tar.bz2 contains the script to create an initramfs for use inside the kernel (kernel+initramfs will be one file). In both cases, you should adapt the /etc/mkinit*fs/config file to your needs, just adapt the list of executables you need/want in your init*fs and run the desired script. The mkinitramfs.sh script will put everything into /usr/src/initramfs. You should configure this in your kernel config so that the kernel build system can create the image for you. The other one will put everything into /boot. Out of the box, the resulting fs will be suited for accessing / from a logical volume which may optionally be encrypted using LUKS. The init script will find out at boot time wether the LV is encrypted and will run cryptsetup to prompt for a password. Finally, you need to adapt your bootloader, depending on which approach you choose: initramfs: realroot=/dev/vg/root (* NO root=, because that's the initramfs). initfs: You'll need both root=/dev/sda1, which should be your /boot, realroot= as above and rw (this is important). BTW: Newer kernels also have a configuration option for this: CONFIG_CMDLINE. In case of further questions, just send a mail. Bye... Dirk -- Best Regards, David Shen http://twitter.com/davidshen84
[gentoo-user] Removing qt4 meta
Hi all, some time ago I installed qt4 for testing. Now, after I run 'emerge --sync' and 'emerge --update world --pretend --verbose' I get a message that the qt4 meta ebuild is hard masked and that the meta ebuild should not be used anymore in the future. How can I remove all the packages in the meta package? 'emerge --unmerge qt' only removes x11-libs/qt but not the dependencies/meta ebuild Thanks for your help! -- Best regards, Marco
Re: [gentoo-user] Removing qt4 meta
Am Samstag 27 Juni 2009 15:51:20 schrieb Marco: How can I remove all the packages in the meta package? No need to do that. It's about the meta package only. 'emerge --unmerge qt' only removes x11-libs/qt but not the dependencies/meta ebuild That's correct, x11-libs/qt _is_ the meta ebuild. You may need to re-install a couple of packages which depend on it their installed version, but have their deps corrected in the portage tree. For me, those where avahi and qimageblitz. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Removing qt4 meta
Marco schrieb: On Sat, Jun 27, 2009 at 2:02 PM, Dirk Heinrichsdirk.heinri...@online.de wrote: Am Samstag 27 Juni 2009 15:51:20 schrieb Marco: How can I remove all the packages in the meta package? No need to do that. It's about the meta package only. Just in case I would want to remove all the packages, how could I do that? (I'm not doing any qt develoment anyway and I take care not to install any software that depends on qt) If you have eix installed you could use eix -I --only-names x11-libs/qt |xargs emerge -C or if you have no package that depends on qt emerge --depclean -a after emerge -C x11-libs/qt should do the job. You should do emerge -DuNva world and revdep-rebuild afterwards to be sure the system is still in clean state. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Removing qt4 meta
On Sat, Jun 27, 2009 at 2:02 PM, Dirk Heinrichsdirk.heinri...@online.de wrote: Am Samstag 27 Juni 2009 15:51:20 schrieb Marco: How can I remove all the packages in the meta package? No need to do that. It's about the meta package only. Just in case I would want to remove all the packages, how could I do that? (I'm not doing any qt develoment anyway and I take care not to install any software that depends on qt) 'emerge --unmerge qt' only removes x11-libs/qt but not the dependencies/meta ebuild That's correct, x11-libs/qt _is_ the meta ebuild. You may need to re-install a couple of packages which depend on it their installed version, but have their deps corrected in the portage tree. For me, those where avahi and qimageblitz. How to do that? Is 'emerge --update --newuse --deep world' enough? -- Regards, Marco
[gentoo-user] png2yuv belongs to ?
Hello, I'm having a senior moment here /usr/bin/png2yuv How do I discover which package(ebuild) that png2yuv, or any command found on my Gentoo systems, belongs to? I looked at equery options, but nothing jumps out at me... James
Re: [gentoo-user] png2yuv belongs to ?
On Saturday 27 June 2009 16:44:05 james wrote: Hello, I'm having a senior moment here /usr/bin/png2yuv How do I discover which package(ebuild) that png2yuv, or any command found on my Gentoo systems, belongs to? I looked at equery options, but nothing jumps out at me... equery belongs /path/to/filesystem/object -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] png2yuv belongs to ?
On 27 Jun 2009, at 15:44, james wrote: ... How do I discover which package(ebuild) that png2yuv, or any command found on my Gentoo systems, belongs to? I looked at equery options, but nothing jumps out at me... $ ls -l /usr/bin/fax2tiff -rwxr-xr-x 1 root root 13880 Aug 30 2008 /usr/bin/fax2tiff $ equery b !!:$ equery b /usr/bin/fax2tiff [ Searching for file(s) /usr/bin/fax2tiff in *... ] media-libs/tiff-3.8.2-r4 (/usr/bin/fax2tiff) $
Re: [gentoo-user] Removing qt4 meta
On Sat, Jun 27, 2009 at 2:33 PM, Sebastian Beßlerwebmas...@darkmetatron.de wrote: Marco schrieb: On Sat, Jun 27, 2009 at 2:02 PM, Dirk Heinrichsdirk.heinri...@online.de wrote: Am Samstag 27 Juni 2009 15:51:20 schrieb Marco: [...] If you have eix installed you could use eix -I --only-names x11-libs/qt |xargs emerge -C or if you have no package that depends on qt emerge --depclean -a after emerge -C x11-libs/qt should do the job. Is there a way to find out if packages depend on qt? Although I think I did not install any packages that depend on qt (saving space) I am not 100% sure... You should do emerge -DuNva world and revdep-rebuild afterwards to be sure the system is still in clean state.
Re: [gentoo-user] Removing qt4 meta
Am Samstag 27 Juni 2009 18:13:56 schrieb Marco: Is there a way to find out if packages depend on qt? Although I think I did not install any packages that depend on qt (saving space) I am not 100% sure... Well, paludis said it couldn't uninstall it because there were packages depending on it (don't know what emerge does in this case since I didn't use it for a very long time now). Those packages should be reinstalled first. revdep-rebuild doesn't work here. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Removing qt4 meta
On Saturday 27 June 2009 18:13:56 Marco wrote: On Sat, Jun 27, 2009 at 2:33 PM, Sebastian Beßlerwebmas...@darkmetatron.de wrote: Marco schrieb: On Sat, Jun 27, 2009 at 2:02 PM, Dirk Heinrichsdirk.heinri...@online.de wrote: Am Samstag 27 Juni 2009 15:51:20 schrieb Marco: [...] If you have eix installed you could use eix -I --only-names x11-libs/qt |xargs emerge -C or if you have no package that depends on qt emerge --depclean -a after emerge -C x11-libs/qt should do the job. Is there a way to find out if packages depend on qt? Although I think I did not install any packages that depend on qt (saving space) I am not 100% sure... equery depends package_name Note that this lists packages that *could* depend on the named package, not just those that *do* depend on your specific machine. also look at qdepends -d -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. I will repeat the experiment this morning and post back info on the steps as I go along. I suppose I could copy Nikos on this thread directly to possibly catch his attention but I ll save that for later. Cheers, Mark Cheers, Mark
Re: [gentoo-user] mesa build failure
On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ #
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions drwxr-xr-x 2 root root 4096 Jun 27 10:28 include drwxr-xr-x 2 root root 4096 Jun 27 10:28 lib myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 8 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/include/ total 716 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. -rw-r--r-- 1 root root 90752 Jun 27 10:28 gl.h -rw-r--r-- 1 root root 461180 Jun 27 10:28 glext.h -rw-r--r-- 1 root root 17155 Jun 27 10:28 glx.h -rw-r--r-- 1 root root 34142 Jun 27 10:28 glxext.h -rw-r--r-- 1 root root 2453 Jun 27 10:20 glxmd.h -rw-r--r-- 1 root root 77887 Jun 27 10:20 glxproto.h -rw-r--r-- 1 root root 10613 Jun
[gentoo-user] kernel cross compilation
My workstation is an AMD64 and I want to build a 486 kernel. I've tried oldconfig, menuconfig, and xconfig and they all change the .config from X86_32 to X86_64. How do I stop this behavior? FWIW, below is a partial diff between the 486 .config and the new config. Thanks. David r...@osage linux # diff -u .config.old .config --- .config.old 2009-04-15 18:47:58.0 -0400 +++ .config 2009-06-27 13:26:53.0 -0400 @@ -1,18 +1,19 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.27 -# Wed Apr 15 18:47:58 2009 +# Linux kernel version: 2.6.27.25 +# Sat Jun 27 13:26:53 2009 # -# CONFIG_64BIT is not set -CONFIG_X86_32=y -# CONFIG_X86_64 is not set +CONFIG_64BIT=y +# CONFIG_X86_32 is not set +CONFIG_X86_64=y CONFIG_X86=y -CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig +CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig # CONFIG_GENERIC_LOCKBREAK is not set ...
Re: [gentoo-user] kernel cross compilation
Am Samstag 27 Juni 2009 19:33:48 schrieb David Relson: My workstation is an AMD64 and I want to build a 486 kernel. I've tried oldconfig, menuconfig, and xconfig and they all change the .config from X86_32 to X86_64. How do I stop this behavior? make CROSS_COMPILE=i686-pc-linux-gnu- ARCH=i386 ... HTH... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] mesa build failure
Copying Nikos as I think he may have the answer right on the tip of his tongue. Bulk of message posted at the bottom. On Sat, Jun 27, 2009 at 10:32 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions drwxr-xr-x 2 root root 4096 Jun 27 10:28 include drwxr-xr-x 2 root root 4096 Jun 27 10:28 lib myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 8 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/include/ total 716 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. -rw-r--r-- 1 root root 90752 Jun 27 10:28 gl.h -rw-r--r-- 1 root root 461180 Jun 27 10:28 glext.h -rw-r--r-- 1 root root
[gentoo-user] Re: png2yuv belongs to ?
Peter Ruskin peter.ruskin at dsl.pipex.com writes: /usr/bin/png2yuv qfile /usr/bin/png2yuv media-video/mjpegtools (/usr/bin/png2yuv) qfile seems to much faster than equery. thanks guys for the info, (remembering the path) James
Re: [gentoo-user] mesa build failure
On Samstag 27 Juni 2009, Mark Knecht wrote: Copying Nikos as I think he may have the answer right on the tip of his tongue. Bulk of message posted at the bottom. On Sat, Jun 27, 2009 at 10:32 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions drwxr-xr-x 2 root root 4096 Jun 27 10:28 include drwxr-xr-x 2 root root 4096 Jun 27 10:28 lib myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 8 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/include/ total 716 drwxr-xr-x 2 root root 4096 Jun 27 10:28 .
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 1:25 PM, Volker Armin Hemmannvolkerar...@googlemail.com wrote: On Samstag 27 Juni 2009, Mark Knecht wrote: Copying Nikos as I think he may have the answer right on the tip of his tongue. Bulk of message posted at the bottom. On Sat, Jun 27, 2009 at 10:32 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions drwxr-xr-x 2 root root 4096 Jun 27 10:28 include drwxr-xr-x 2 root root 4096 Jun 27 10:28 lib myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/extensions/ total 8 drwxr-xr-x 2 root root 4096 Jun 27 10:28 . drwxr-xr-x 5 root root 4096 Jun 27 10:28 .. myth12 ~ # ls -al
Re: [gentoo-user] mesa build failure
On Samstag 27 Juni 2009, Mark Knecht wrote: On Sat, Jun 27, 2009 at 1:25 PM, Volker Armin Hemmannvolkerar...@googlemail.com wrote: On Samstag 27 Juni 2009, Mark Knecht wrote: Copying Nikos as I think he may have the answer right on the tip of his tongue. Bulk of message posted at the bottom. On Sat, Jun 27, 2009 at 10:32 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions drwxr-xr-x 2 root root 4096 Jun 27 10:28 include drwxr-xr-x 2 root root 4096 Jun 27 10:28
Re: [gentoo-user] mesa build failure
On Sat, Jun 27, 2009 at 2:00 PM, Volker Armin Hemmannvolkerar...@googlemail.com wrote: On Samstag 27 Juni 2009, Mark Knecht wrote: On Sat, Jun 27, 2009 at 1:25 PM, Volker Armin Hemmannvolkerar...@googlemail.com wrote: On Samstag 27 Juni 2009, Mark Knecht wrote: Copying Nikos as I think he may have the answer right on the tip of his tongue. Bulk of message posted at the bottom. On Sat, Jun 27, 2009 at 10:32 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:27 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:25 AM, Mark Knechtmarkkne...@gmail.com wrote: On Sat, Jun 27, 2009 at 10:18 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 19:10:43 Mark Knecht wrote: On Sat, Jun 27, 2009 at 2:34 AM, Alan McKinnonalan.mckin...@gmail.com wrote: On Saturday 27 June 2009 06:24:12 Mark Knecht wrote: On Fri, Jun 26, 2009 at 12:30 PM, Alan McKinnonalan.mckin...@gmail.com wrote: On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? Unfortunately it seem that there are bug reports on this and more unfortunately they have apparently been going on nearly a year now. It's not a Gentoo thing specifically as there are Ubuntu, Debian and other distros with reports in their forums. There was a possible by hand fix for it but I'll need to look at that over the weekend to see if it makes sense on this machine. Bummer. I hate banging my head up against a wall made of problems no one seems to be fixing. http://bugs.gentoo.org/247685 The fix seems (in principle at least) to be brain-dead easy: - all ebuilds that merge opengl files should put them in distinct locations by name to avoid collisions - the contents of /usr/lib64/opengl/xorg-x11/extensions/ should be symlinks with a sane default put there by xorg-server and modified by eselect Nikos's comments are especially sane in that thread. Perhaps he'll come along, see this thread and help you out further. I suspect that the temporary workaround will be to delete a symlink and emerge stuff, then remember to always do this on every future re-emerge -- alan dot mckinnon at gmail dot com In concept it does seem fairly straight forward, but to some extent I'm not clear why my previous attempts didn't work, unless the questionable files remained behind. What I attempted to do was completely remove everything X, but I probably didn't specifically remove the stuff in /usr/lib/opengl/xorg-x11/extensions. I was expecting the emerge to do that. According to the bug report you mentioned earlier, the ebuild is attempting to perform eselect too late in the process, which fails, and the ebuild immediately exits. So it's not surprising that dodgy files are left behind which you must remove manually. -- alan dot mckinnon at gmail dot com So I'm little confused by a couple of the postings in that report. I did emerge -C glproto/eselect/mesa/xorg-server and then made sure there was nothing left in those directories at all. Should I emerge eselect, manually do a select, and then emerge the rest of the files? Or emerge eselect and maybe mesa, do the eselect, then xorg-server? mesa is currently building. glproto created /usr/lib/opengl/xorg-x11/include, but the other two directories are there yet. Cheers, Mark With mesa building in screen I tried the eselect step. It completes normally but the extensions directory isn't there yet so there's nothing to check. [detached] myth12 ~ # eselect opengl list Available OpenGL implementations: [1] xorg-x11 * myth12 ~ # eselect opengl set 1 Switching to xorg-x11 OpenGL interface... done myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 12 drwxr-xr-x 3 root root 4096 Jun 27 10:20 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:20 include myth12 ~ # Ok, with mesa finished building there are now two more directories with some header files added in include and some links and files in lib: myth12 ~ # ls -al /usr/lib/opengl/xorg-x11/ total 20 drwxr-xr-x 5 root root 4096 Jun 27 10:28 . drwxr-xr-x 4 root root 4096 Jun 27 10:20 .. drwxr-xr-x 2 root root 4096 Jun 27 10:28 extensions
[gentoo-user] qt3support conflict
Trying to upgrade to qt 4.5.2: kde4 wants qt3support for qt-core: x11-libs/qt-core-4.5.2 (Change USE: +qt3support) (dependency required by x11-libs/qt-qt3support-4.5.2 [ebuild]) (dependency required by kde-base/kteatime-4.2.4 [installed]) (dependency required by kde-base/kdetoys-meta-4.2.4 [installed]) (dependency required by kde-base/kde-meta-4.2.4 [installed]) OK, let's try: adding qt3support to qt-core wants qt3support for qt-gui adding qt3support to qt-gui wants qt3support for qt-sql adding qt3support to qt-sql conflicts with x11-libs/qt-opengl - last one insits on -qt3support for qt-core. At ~amd64. Where is my mistake?
[gentoo-user] Kbackup and dvd sized slices
HI, I'm in the process of doing a set of DVD backups for some of my data. I usually tell it to do them in a DVD sized slice. That option appears to have disappeared from the menu. Could someone who has it installed check to see if they have the option available? In case you are not to familiar with it, open kbackup, then under the File menu, select Profile Settings. A box should pop up and if you click the little button under Maximum Archive Size, it should show the available options. Mine has unlimited, 650Mb CD, 700Mb CD and custom. The custom will not let me enter anything in Gb. Here is some info for my system in case I did something wrong: r...@smoker / # emerge --info Portage 2.2_rc33 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.8_p20080602-r1, 2.6.25-gentoo-r9 i686) = System uname: Linux-2.6.25-gentoo-r9-i686-AMD_Athlon-tm-_XP_2500+-with-glibc2.0 Timestamp of tree: Sat, 20 Jun 2009 04:45:01 + app-shells/bash: 3.2_p39 dev-java/java-config: 2.1.7 dev-lang/python: 2.5.4-r2 dev-util/cmake: 2.6.4 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox:1.6-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.29 ACCEPT_KEYWORDS=x86 CBUILD=i686-pc-linux-gnu CFLAGS=-march=athlon-xp -O2 -pipe -fomit-frame-pointer CHOST=i686-pc-linux-gnu CONFIG_PROTECT=/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d CXXFLAGS=-march=athlon-xp -O2 -pipe -fomit-frame-pointer DISTDIR=/usr/portage/distfiles EMERGE_DEFAULT_OPTS=--with-bdeps y FEATURES=buildpkg distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch GENTOO_MIRRORS=ftp://gentoo.chem.wisc.edu/gentoo/ ftp://lug.mtu.edu/gentoo/ LANG=en_US LC_ALL=en_US.utf8 LDFLAGS=-Wl,-O1 LINGUAS=en_US en MAKEOPTS=-j2 PKGDIR=/usr/portage/packages PORTAGE_CONFIGROOT=/ PORTAGE_RSYNC_EXTRA_OPTS=--timeout=600 PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages PORTAGE_TMPDIR=/var/tmp PORTDIR=/usr/portage SYNC=rsync://rsync.namerica.gentoo.org/gentoo-portage USE=3dnow X acl acpi alsa amd arts artswrappersuid automount berkdb bzip2 cairo cddb cdr chroot cli cracklib crypt cups curl dbus dri dvd dvdr dvdread eds emboss encode esd evo exif fam fdftk fortran gdbm gif gimp gkrellm gphoto2 gpm gstreamer gtk hal hbci htmlhandbook iconv ipv6 isdnlog java javascript jbig jpeg jpeg2k justify kde ldap libnotify libwww logrotate loop-aes mad midi mikmod mmx mng mp3 mpeg mplayer mudflap ncurses nptl nptlonly nsplugin offensive ofx ogg opengl openmp pam parport pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline realmedia reflection sdl seamonkey session spell spl sqlite sse ssl startup-notification svg sysfs syslog tcl tcpd tiff tk truetype unicode usb vorbis webkit win32codecs wma wmf wmp x86 xml xorg xv yahoo zeroconf zlib ALSA_CARDS=emu10k1 ALSA_PCM_PLUGINS=adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol CAMERAS=canon ptp2 ELIBC=glibc INPUT_DEVICES=keyboard mouse evdev KERNEL=linux LINGUAS=en_US en USERLAND=GNU VIDEO_CARDS=nvidia nv Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTDIR_OVERLAY r...@smoker / # emerge -1vp kbackup These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-backup/kbackup-0.5.4-r1 USE=-debug -xinerama LINGUAS=-de -es -fr -it -pt -ru -sk -sv 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB r...@smoker / # There is really not a USE flags to change on this one. Ideas? Someone confirm it is just me or not just me? Thanks. Dale :-) :-)
[gentoo-user] Re: mesa build failure
On 06/28/2009 12:20 AM, Mark Knecht wrote: As far as the bug report went it just didn't click for me. Disappointing that after something like 10 months no one has fixed the ebuild. The latter ebuilds are fixed. They're still ~arch, but I recommend you use them because the latter driver versions are substantially less buggy than the arch ones. If you have a older card (anything less or equal to a Radeon X1950) use ati-drivers-8.593. If you a Radeon HD2000 and above, use ati-drivers-9.6.
Re: [gentoo-user] kernel cross compilation
On Sat, 27 Jun 2009 20:13:25 +0200 Dirk Heinrichs wrote: Am Samstag 27 Juni 2009 19:33:48 schrieb David Relson: My workstation is an AMD64 and I want to build a 486 kernel. I've tried oldconfig, menuconfig, and xconfig and they all change the .config from X86_32 to X86_64. How do I stop this behavior? make CROSS_COMPILE=i686-pc-linux-gnu- ARCH=i386 ... HTH... Dirk Exactly the sort of answer I wanted. Thanks, Dirk.
[gentoo-user] Re: qt3support conflict
On 06/28/2009 12:51 AM, Andrew Gaydenko wrote: Trying to upgrade to qt 4.5.2: kde4 wants qt3support for qt-core: x11-libs/qt-core-4.5.2 (Change USE: +qt3support) (dependency required by x11-libs/qt-qt3support-4.5.2 [ebuild]) (dependency required by kde-base/kteatime-4.2.4 [installed]) (dependency required by kde-base/kdetoys-meta-4.2.4 [installed]) (dependency required by kde-base/kde-meta-4.2.4 [installed]) OK, let's try: adding qt3support to qt-core wants qt3support for qt-gui adding qt3support to qt-gui wants qt3support for qt-sql adding qt3support to qt-sql conflicts with x11-libs/qt-opengl - last one insits on -qt3support for qt-core. At ~amd64. Where is my mistake? You forgot to add qt3support to qt-opengl too :) Anyway, I find all this a bit strange. qt3support is on by default, why do you have to enable it explicitly? Did you put -qt3support in make.conf? If yes, you should remove it.
Re: [gentoo-user] Re: mesa build failure
On Sat, Jun 27, 2009 at 3:17 PM, Nikos Chantziarasrea...@arcor.de wrote: On 06/28/2009 12:20 AM, Mark Knecht wrote: As far as the bug report went it just didn't click for me. Disappointing that after something like 10 months no one has fixed the ebuild. The latter ebuilds are fixed. They're still ~arch, but I recommend you use them because the latter driver versions are substantially less buggy than the arch ones. If you have a older card (anything less or equal to a Radeon X1950) use ati-drivers-8.593. If you a Radeon HD2000 and above, use ati-drivers-9.6. Nikos, Thanks for responding. I apprecaite it. ~arch on xf86-video-ati, xorg-server or both? I prefer to stay with non-~arch when possible. I've got a 9100 IGP which is listed as R200 technology. I need to use the TV Out S-Video on my machine but cannot find very good instructions on creating the right xorg.conf file. Thanks, Mark
Re: [gentoo-user] Re: qt3support conflict
On Sunday 28 June 2009 02:23:38 Nikos Chantziaras wrote: On 06/28/2009 12:51 AM, Andrew Gaydenko wrote: Trying to upgrade to qt 4.5.2: kde4 wants qt3support for qt-core: x11-libs/qt-core-4.5.2 (Change USE: +qt3support) (dependency required by x11-libs/qt-qt3support-4.5.2 [ebuild]) (dependency required by kde-base/kteatime-4.2.4 [installed]) (dependency required by kde-base/kdetoys-meta-4.2.4 [installed]) (dependency required by kde-base/kde-meta-4.2.4 [installed]) OK, let's try: adding qt3support to qt-core wants qt3support for qt-gui adding qt3support to qt-gui wants qt3support for qt-sql adding qt3support to qt-sql conflicts with x11-libs/qt-opengl - last one insits on -qt3support for qt-core. At ~amd64. Where is my mistake? You forgot to add qt3support to qt-opengl too :) Anyway, I find all this a bit strange. qt3support is on by default, why do you have to enable it explicitly? Did you put -qt3support in make.conf? If yes, you should remove it. make.conf hasn't qt3support at all. Adding qt3support to qt-opengl shows... well... something horrible (see below) :-) //== emerge -pvDuN world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] x11-libs/qt-core-4.5.2 [4.5.1] USE=glib iconv qt3support ssl -debug -doc -pch 0 kB [ebuild U ] x11-libs/qt-test-4.5.2 [4.5.1] USE=iconv -debug -pch 0 kB [blocks b ] x11-libs/qt-test-4.5.2 (x11-libs/qt-test-4.5.2 is blocking x11-libs/qt-assistant-4.5.2, x11- libs/qt-opengl-4.5.2, x11-libs/qt-xmlpatterns-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-script-4.5.2, x11-libs/qt- svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-gui-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2) [ebuild U ] x11-libs/qt-script-4.5.2 [4.5.1] USE=iconv -debug -pch (-custom-cxxflags%) 0 kB [blocks b ] x11-libs/qt-script-4.5.2 (x11-libs/qt-script-4.5.2 is blocking x11-libs/qt-assistant-4.5.2, x11- libs/qt-opengl-4.5.2, x11-libs/qt-xmlpatterns-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt- svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-gui-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2) [ebuild U ] x11-libs/qt-sql-4.5.2 [4.5.1] USE=iconv mysql qt3support sqlite -debug (-firebird) -odbc -pch - postgres (-custom-cxxflags%) 0 kB [blocks b ] x11-libs/qt-sql-4.5.2 (x11-libs/qt-sql-4.5.2 is blocking x11-libs/qt-assistant-4.5.2, x11- libs/qt-opengl-4.5.2, x11-libs/qt-xmlpatterns-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-script-4.5.2, x11-libs/qt- test-4.5.2, x11-libs/qt-svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-gui-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt-core-4.5.2) [ebuild U ] x11-libs/qt-dbus-4.5.2 [4.5.1] USE=-debug -pch (-custom-cxxflags%) 0 kB [blocks b ] x11-libs/qt-dbus-4.5.2 (x11-libs/qt-dbus-4.5.2 is blocking x11-libs/qt-assistant-4.5.2, x11- libs/qt-opengl-4.5.2, x11-libs/qt-xmlpatterns-4.5.2, x11-libs/qt-script-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt- svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-gui-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt-core-4.5.2, x11-libs/qt-sql-4.5.2) [ebuild U ] x11-libs/qt-xmlpatterns-4.5.2 [4.5.1] USE=-debug -pch (-custom-cxxflags%) 0 kB [blocks b ] x11-libs/qt-xmlpatterns-4.5.2 (x11-libs/qt-xmlpatterns-4.5.2 is blocking x11-libs/qt- assistant-4.5.2, x11-libs/qt-opengl-4.5.2, x11-libs/qt-dbus-4.5.2, x11-libs/qt-script-4.5.2, x11-libs/qt-test-4.5.2, x11-libs/qt-svg-4.5.2, x11-libs/qt-qt3support-4.5.2, x11-libs/qt-gui-4.5.2, x11-libs/qt-webkit-4.5.2, x11-libs/qt- core-4.5.2, x11-libs/qt-sql-4.5.2) [ebuild U ] x11-libs/qt-gui-4.5.2 [4.5.1-r2] USE=accessibility cups dbus glib mng qt3support tiff -debug -gtk% - nas -nis -pch -raster -xinerama (-custom-cxxflags%) (-gtkstyle%*) 0 kB
[gentoo-user] Re: mesa build failure
On 06/28/2009 01:30 AM, Mark Knecht wrote: On Sat, Jun 27, 2009 at 3:17 PM, Nikos Chantziarasrea...@arcor.de wrote: On 06/28/2009 12:20 AM, Mark Knecht wrote: As far as the bug report went it just didn't click for me. Disappointing that after something like 10 months no one has fixed the ebuild. The latter ebuilds are fixed. They're still ~arch, but I recommend you use them because the latter driver versions are substantially less buggy than the arch ones. If you have a older card (anything less or equal to a Radeon X1950) use ati-drivers-8.593. If you a Radeon HD2000 and above, use ati-drivers-9.6. Nikos, Thanks for responding. I apprecaite it. ~arch on xf86-video-ati, xorg-server or both? I prefer to stay with non-~arch when possible. I've got a 9100 IGP which is listed as R200 technology. I need to use the TV Out S-Video on my machine but cannot find very good instructions on creating the right xorg.conf file. No wait, you were talking about xf86-video-ati, not ati-drivers. Please ignore :P Sorry.
Re: [gentoo-user] Re: mesa build failure
On Sat, Jun 27, 2009 at 3:37 PM, Nikos Chantziarasrea...@arcor.de wrote: On 06/28/2009 01:30 AM, Mark Knecht wrote: On Sat, Jun 27, 2009 at 3:17 PM, Nikos Chantziarasrea...@arcor.de wrote: On 06/28/2009 12:20 AM, Mark Knecht wrote: As far as the bug report went it just didn't click for me. Disappointing that after something like 10 months no one has fixed the ebuild. The latter ebuilds are fixed. They're still ~arch, but I recommend you use them because the latter driver versions are substantially less buggy than the arch ones. If you have a older card (anything less or equal to a Radeon X1950) use ati-drivers-8.593. If you a Radeon HD2000 and above, use ati-drivers-9.6. Nikos, Thanks for responding. I apprecaite it. ~arch on xf86-video-ati, xorg-server or both? I prefer to stay with non-~arch when possible. I've got a 9100 IGP which is listed as R200 technology. I need to use the TV Out S-Video on my machine but cannot find very good instructions on creating the right xorg.conf file. No wait, you were talking about xf86-video-ati, not ati-drivers. Please ignore :P Sorry. OK - no problem. Sorry for any confusion. Cheers, Mark
[gentoo-user] Re: qt3support conflict
On 06/28/2009 01:32 AM, Andrew Gaydenko wrote: On Sunday 28 June 2009 02:23:38 Nikos Chantziaras wrote: On 06/28/2009 12:51 AM, Andrew Gaydenko wrote: Trying to upgrade to qt 4.5.2: kde4 wants qt3support for qt-core: x11-libs/qt-core-4.5.2 (Change USE: +qt3support) (dependency required by x11-libs/qt-qt3support-4.5.2 [ebuild]) (dependency required by kde-base/kteatime-4.2.4 [installed]) (dependency required by kde-base/kdetoys-meta-4.2.4 [installed]) (dependency required by kde-base/kde-meta-4.2.4 [installed]) OK, let's try: adding qt3support to qt-core wants qt3support for qt-gui adding qt3support to qt-gui wants qt3support for qt-sql adding qt3support to qt-sql conflicts with x11-libs/qt-opengl - last one insits on -qt3support for qt-core. At ~amd64. Where is my mistake? You forgot to add qt3support to qt-opengl too :) Anyway, I find all this a bit strange. qt3support is on by default, why do you have to enable it explicitly? Did you put -qt3support in make.conf? If yes, you should remove it. make.conf hasn't qt3support at all. Adding qt3support to qt-opengl shows... well... something horrible (see below) :-) //== emerge -pvDuN world These are the packages that would be merged, in order: [...] I got that too, but portage (I'm on 2.1.6.13) has automatically resolved all blocks. Are you using Paludis? If yes, uninstall all packages that are to be upgraded and install them afterwards. Or wait for someone who actually knows a Paludis workaround for this.
Re: [gentoo-user] Re: qt3support conflict
On Sunday 28 June 2009 02:41:53 Nikos Chantziaras wrote: On 06/28/2009 01:32 AM, Andrew Gaydenko wrote: On Sunday 28 June 2009 02:23:38 Nikos Chantziaras wrote: On 06/28/2009 12:51 AM, Andrew Gaydenko wrote: Trying to upgrade to qt 4.5.2: kde4 wants qt3support for qt-core: x11-libs/qt-core-4.5.2 (Change USE: +qt3support) (dependency required by x11-libs/qt-qt3support-4.5.2 [ebuild]) (dependency required by kde-base/kteatime-4.2.4 [installed]) (dependency required by kde-base/kdetoys-meta-4.2.4 [installed]) (dependency required by kde-base/kde-meta-4.2.4 [installed]) OK, let's try: adding qt3support to qt-core wants qt3support for qt-gui adding qt3support to qt-gui wants qt3support for qt-sql adding qt3support to qt-sql conflicts with x11-libs/qt-opengl - last one insits on -qt3support for qt-core. At ~amd64. Where is my mistake? You forgot to add qt3support to qt-opengl too :) Anyway, I find all this a bit strange. qt3support is on by default, why do you have to enable it explicitly? Did you put -qt3support in make.conf? If yes, you should remove it. make.conf hasn't qt3support at all. Adding qt3support to qt-opengl shows... well... something horrible (see below) :-) //== emerge -pvDuN world These are the packages that would be merged, in order: [...] I got that too, but portage (I'm on 2.1.6.13) has automatically resolved all blocks. Are you using Paludis? If yes, uninstall all packages that are to be upgraded and install them afterwards. Or wait for someone who actually knows a Paludis workaround for this. No, I don't use Paludis. What do you mean saying has automatically resolved all blocks? Do you mean you have added those qt3support flags and started emerging and got successfull upgrading to 4.5.2 without any problems and in spite of those blocks?
[gentoo-user] Re: qt3support conflict
On 06/27/2009 03:32 PM, Andrew Gaydenko wrote: make.conf hasn't qt3support at all. Adding qt3support to qt-opengl shows... well... something horrible (see below) :-) //== emerge -pvDuN world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] x11-libs/qt-core-4.5.2 [4.5.1] USE=glib iconv qt3support ssl -debug -doc -pch 0 kB [ebuild U ] x11-libs/qt-test-4.5.2 [4.5.1] USE=iconv -debug -pch 0 kB [blocks b ]x11-libs/qt-test-4.5.2 (x11-libs/qt-test-4.5.2 is blocking x11-libs/qt-assistant-4.5.2, x11- I recently went through the same thing on ~amd64 and emerge made me uninstall every qt package before it would start building the updates. I have no idea why, but everything finally came out okay. I'd say go ahead and emerge -C all of those qt blockers as emerge suggests.
[gentoo-user] coexisting GCC versions
Hello, I need gcc 4.3 to compile a specific application. I am hoping that I can install gcc 4.3 alongside 4.1.1 without suffering some awful catastrophe. This is the output of emerge on the machine in question: emerge -pv gcc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-devel/gcc-config-1.4.0-r4 [1.3.14] 0 kB [?=0] [ebuild N] app-arch/lzma-utils-4.32.7 USE=-nocxx 469 kB [0] [ebuild U ] dev-libs/mpfr-2.4.1_p1 [2.2.0_p10] 883 kB [?=0] [ebuild U ] sys-libs/glibc-2.8_p20080602-r1 [2.4-r4] USE=gd%* -debug% -glibc-omitfp (-hardened) (-multilib) -nls -profile (-selinux) -vanilla% (-build%) (-glibc-compat20%) (-nptl%*) (-nptlonly%*) 16,415 kB [?=0] [ebuild NS ] sys-devel/gcc-4.3.2-r3 [4.1.1-r3] USE=doc fortran gcj gtk mudflap openmp (-altivec) -bootstrap -build (-fixed-point) (-hardened) -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nls -nocxx -nopie -objc -objc++ -objc-gc -test -vanilla 58,990 kB [0] Can someone confirm that I'll be able to use gcc 4.3 for the specific application that needs it but then revert to 4.1.1 without having to re-compile all or most of my system? Thanks, Roger
[gentoo-user] Re: qt3support conflict
On 06/28/2009 01:51 AM, Andrew Gaydenko wrote: On Sunday 28 June 2009 02:41:53 Nikos Chantziaras wrote: I got that too, but portage (I'm on 2.1.6.13) has automatically resolved all blocks. Are you using Paludis? If yes, uninstall all packages that are to be upgraded and install them afterwards. Or wait for someone who actually knows a Paludis workaround for this. No, I don't use Paludis. What do you mean saying has automatically resolved all blocks? Do you mean you have added those qt3support flags and started emerging and got successfull upgrading to 4.5.2 without any problems and in spite of those blocks? I did not add qt3support anywhere. It seems to be enabled by default here. Anyway, you went past that problem anyway. Your current is something else: the blockers. What portage version are you using? If portage won't resolve those blockers automatically for you, you can do it the traditional way. Unmerge all packages that would be updated and then update again. I would do it like this: emerge -aC `qlist -IC x11-libs/qt*:4` emerge -auDN world
Re: [gentoo-user] coexisting GCC versions
On Sonntag 28 Juni 2009, Roger Mason wrote: Hello, I need gcc 4.3 to compile a specific application. I am hoping that I can install gcc 4.3 alongside 4.1.1 without suffering some awful catastrophe. This is the output of emerge on the machine in question: emerge -pv gcc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-devel/gcc-config-1.4.0-r4 [1.3.14] 0 kB [?=0] [ebuild N] app-arch/lzma-utils-4.32.7 USE=-nocxx 469 kB [0] [ebuild U ] dev-libs/mpfr-2.4.1_p1 [2.2.0_p10] 883 kB [?=0] [ebuild U ] sys-libs/glibc-2.8_p20080602-r1 [2.4-r4] USE=gd%* -debug% -glibc-omitfp (-hardened) (-multilib) -nls -profile (-selinux) -vanilla% (-build%) (-glibc-compat20%) (-nptl%*) (-nptlonly%*) 16,415 kB [?=0] [ebuild NS ] sys-devel/gcc-4.3.2-r3 [4.1.1-r3] USE=doc fortran gcj gtk mudflap openmp (-altivec) -bootstrap -build (-fixed-point) (-hardened) -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nls -nocxx -nopie -objc -objc++ -objc-gc -test -vanilla 58,990 kB [0] Can someone confirm that I'll be able to use gcc 4.3 for the specific application that needs it but then revert to 4.1.1 without having to re-compile all or most of my system? yes
Re: [gentoo-user] coexisting GCC versions
Roger Mason writes: I need gcc 4.3 to compile a specific application. I am hoping that I can install gcc 4.3 alongside 4.1.1 without suffering some awful catastrophe. This is the output of emerge on the machine in question: [...] Can someone confirm that I'll be able to use gcc 4.3 for the specific application that needs it but then revert to 4.1.1 without having to re-compile all or most of my system? I'm pretty sure you can. Emerge gcc 4.3, activate it with gcc-config, compile your application, and use gcc-config again to revert back to 4.1 if you like. Or keep 4.3 as default, I don't think you could run into problems. Wonko
Re: [gentoo-user] coexisting GCC versions
On Sonntag 28 Juni 2009, Alex Schuster wrote: Roger Mason writes: I need gcc 4.3 to compile a specific application. I am hoping that I can install gcc 4.3 alongside 4.1.1 without suffering some awful catastrophe. This is the output of emerge on the machine in question: [...] Can someone confirm that I'll be able to use gcc 4.3 for the specific application that needs it but then revert to 4.1.1 without having to re-compile all or most of my system? I'm pretty sure you can. Emerge gcc 4.3, activate it with gcc-config, compile your application, and use gcc-config again to revert back to 4.1 if you like. Or keep 4.3 as default, I don't think you could run into problems. Wonko he will over time. If you switch default compiler emerge -s world has to be done. But seriously, why staying with 4.1? it's old... and 4.3 was a nice release...
[gentoo-user] Success! [fluxbox on my old widescreen TV using S-Video TV output and Open Source ATI driver]
Happy, happy! Thanks to all who made contributions via other threads. Cheers, Mark
Re: [gentoo-user] Re: qt3support conflict
On Sunday 28 June 2009 03:05:48 Nikos Chantziaras wrote:
On 06/28/2009 01:51 AM, Andrew Gaydenko wrote:
On Sunday 28 June 2009 02:41:53 Nikos Chantziaras wrote:
I got that too, but portage (I'm on 2.1.6.13) has automatically resolved
all blocks. Are you using Paludis? If yes, uninstall all packages that
are to be upgraded and install them afterwards. Or wait for someone who
actually knows a Paludis workaround for this.
No, I don't use Paludis. What do you mean saying has automatically
resolved all blocks? Do you mean you have added those qt3support flags
and started emerging and got successfull upgrading to 4.5.2 without any
problems and in spite of those blocks?
I did not add qt3support anywhere. It seems to be enabled by default
here. Anyway, you went past that problem anyway. Your current is
something else: the blockers. What portage version are you using? If
portage won't resolve those blockers automatically for you, you can do
it the traditional way. Unmerge all packages that would be updated
and then update again. I would do it like this:
emerge -aC `qlist -IC x11-libs/qt*:4`
emerge -auDN world
Thanks, Portage has resolved conflicts, I'm on 4.5.2 now. It seems like
qt3support
flags deletion doesn't work for me. Now, after upgrading, I have tried to
comment out
those flags in package.use and got conflicts (below).
===
emerge -pvDuN world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] x11-libs/qt-core-4.5.2 USE=glib iconv ssl -debug -doc -pch
-qt3support* 0 kB
[ebuild R ] x11-libs/qt-gui-4.5.2 USE=accessibility cups dbus glib mng
tiff -debug -gtk -nas -
nis -pch -qt3support* -raster -xinerama 0 kB
[ebuild R ] x11-libs/qt-opengl-4.5.2 USE=-debug -pch -qt3support* 0 kB
Total: 3 packages (3 reinstalls), Size of downloads: 0 kB
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
x11-libs/qt-core:4
('ebuild', '/', 'x11-libs/qt-core-4.5.2', 'merge') pulled in by
~x11-libs/qt-core-4.5.2[glib,-debug,-qt3support] required by ('ebuild',
'/', 'x11-libs/qt-
gui-4.5.2', 'merge')
~x11-libs/qt-core-4.5.2[-debug,-qt3support] required by ('ebuild', '/',
'x11-libs/qt-
opengl-4.5.2', 'merge')
(and 19 more)
('installed', '/', 'x11-libs/qt-core-4.5.2', 'nomerge') pulled in by
=x11-libs/qt-core-4.5.1:4[qt3support,ssl] required by ('installed', '/',
'kde-
base/kfourinline-4.2.4', 'nomerge')
=x11-libs/qt-core-4.5.1:4[qt3support,ssl] required by ('installed', '/',
'kde-
base/ksystraycmd-4.2.4', 'nomerge')
=x11-libs/qt-core-4.5.1:4[qt3support,ssl] required by ('installed', '/',
'kde-base/bomber-4.2.4',
'nomerge')
(and 274 more)
x11-libs/qt-gui:4
('installed', '/', 'x11-libs/qt-gui-4.5.2', 'nomerge') pulled in by
~x11-libs/qt-gui-4.5.2[qt3support] required by ('installed', '/',
'x11-libs/qt-core-4.5.2',
'nomerge')
=x11-libs/qt-gui-4.4:4[qt3support,dbus] required by ('installed', '/',
'net-im/psi-0.12.1',
'nomerge')
~x11-libs/qt-gui-4.5.2[qt3support,accessibility,-debug] required by
('installed', '/', 'x11-
libs/qt-qt3support-4.5.2', 'nomerge')
(and 286 more)
('ebuild', '/', 'x11-libs/qt-gui-4.5.2', 'merge') pulled in by
~x11-libs/qt-gui-4.5.2[-debug,-qt3support] required by ('ebuild', '/',
'x11-libs/qt-opengl-4.5.2',
'merge')
(and 286 more)
It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in the
dependencies of two different packages, then those packages can not be
installed simultaneously.
For more information, see MASKED PACKAGES section in the emerge man page
or refer to the Gentoo Handbook.
[gentoo-user] Re: qt3support conflict
On 06/28/2009 03:35 AM, Andrew Gaydenko wrote: On Sunday 28 June 2009 03:05:48 Nikos Chantziaras wrote: On 06/28/2009 01:51 AM, Andrew Gaydenko wrote: On Sunday 28 June 2009 02:41:53 Nikos Chantziaras wrote: I got that too, but portage (I'm on 2.1.6.13) has automatically resolved all blocks. Are you using Paludis? If yes, uninstall all packages that are to be upgraded and install them afterwards. Or wait for someone who actually knows a Paludis workaround for this. No, I don't use Paludis. What do you mean saying has automatically resolved all blocks? Do you mean you have added those qt3support flags and started emerging and got successfull upgrading to 4.5.2 without any problems and in spite of those blocks? I did not add qt3support anywhere. It seems to be enabled by default here. Anyway, you went past that problem anyway. Your current is something else: the blockers. What portage version are you using? If portage won't resolve those blockers automatically for you, you can do it the traditional way. Unmerge all packages that would be updated and then update again. I would do it like this: emerge -aC `qlist -IC x11-libs/qt*:4` emerge -auDN world Thanks, Portage has resolved conflicts, I'm on 4.5.2 now. It seems like qt3support flags deletion doesn't work for me. Now, after upgrading, I have tried to comment out those flags in package.use and got conflicts. What profile do you use? (Find out with eselect profile show.)
Re: [gentoo-user] Re: qt3support conflict
On Sunday 28 June 2009 04:55:57 Nikos Chantziaras wrote: ... Thanks, Portage has resolved conflicts, I'm on 4.5.2 now. It seems like qt3support flags deletion doesn't work for me. Now, after upgrading, I have tried to comment out those flags in package.use and got conflicts. What profile do you use? (Find out with eselect profile show.) eselect profile show Current make.profile symlink: default/linux/amd64/2008.0 Something wrong with it?
[gentoo-user] Re: qt3support conflict
On 06/28/2009 04:12 AM, Andrew Gaydenko wrote: On Sunday 28 June 2009 04:55:57 Nikos Chantziaras wrote: ... Thanks, Portage has resolved conflicts, I'm on 4.5.2 now. It seems like qt3support flags deletion doesn't work for me. Now, after upgrading, I have tried to comment out those flags in package.use and got conflicts. What profile do you use? (Find out with eselect profile show.) eselect profile show Current make.profile symlink: default/linux/amd64/2008.0 Something wrong with it? Nope, I use the same. I guess I've no more ideas of why qt3support is enabled automatically on my machine, but not on yours. But in the end, it doesn't really matter that much; it's just a USE flag. The easiest way is to enable it in make.conf so that you won't have to create a dozen entries in package.use.
Re: [gentoo-user] Re: qt3support conflict
On Sunday 28 June 2009 02:54:59 walt wrote: On 06/27/2009 03:32 PM, Andrew Gaydenko wrote: make.conf hasn't qt3support at all. Adding qt3support to qt-opengl shows... well... something horrible (see below) :-) //== emerge -pvDuN world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] x11-libs/qt-core-4.5.2 [4.5.1] USE=glib iconv qt3support ssl -debug -doc -pch 0 kB [ebuild U ] x11-libs/qt-test-4.5.2 [4.5.1] USE=iconv -debug -pch 0 kB [blocks b ]x11-libs/qt-test-4.5.2 (x11-libs/qt-test-4.5.2 is blocking x11-libs/qt-assistant-4.5.2, x11- I recently went through the same thing on ~amd64 and emerge made me uninstall every qt package before it would start building the updates. I have no idea why, but everything finally came out okay. I'd say go ahead and emerge -C all of those qt blockers as emerge suggests. Walt, thanks! At my case portage has ovecome those blocks without direct unmerging.
Re: [gentoo-user] coexisting GCC versions
In linux.gentoo.user, you wrote: On Sonntag 28 Juni 2009, Alex Schuster wrote: Roger Mason writes: I need gcc 4.3 to compile a specific application. I am hoping that I can install gcc 4.3 alongside 4.1.1 without suffering some awful catastrophe. This is the output of emerge on the machine in question: [...] Can someone confirm that I'll be able to use gcc 4.3 for the specific application that needs it but then revert to 4.1.1 without having to re-compile all or most of my system? I'm pretty sure you can. Emerge gcc 4.3, activate it with gcc-config, compile your application, and use gcc-config again to revert back to 4.1 if you like. Or keep 4.3 as default, I don't think you could run into problems. Wonko he will over time. If you switch default compiler emerge -s world has to be done. But seriously, why staying with 4.1? it's old... and 4.3 was a nice release... Well, for me, media-plugins/mytharchive won't compile with gcc 4.3. Hopefully things will change with the next mythtv release. -- Regards, Gregory.
Re: [gentoo-user] coexisting GCC versions
Gregory Shearman zek...@gmail.com said: In linux.gentoo.user, you wrote: he will over time. If you switch default compiler emerge -s world has to be done. But seriously, why staying with 4.1? it's old... and 4.3 was a nice release... Well, for me, media-plugins/mytharchive won't compile with gcc 4.3. Hopefully things will change with the next mythtv release. Please file a bug so we actually know about the problem and can fix it :) https://bugs.gentoo.org/ -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgp04ctridxH3.pgp Description: PGP signature
Re: [gentoo-user] coexisting GCC versions
Volker Armin Hemmann wrote: On Sonntag 28 Juni 2009, Alex Schuster wrote: Roger Mason writes: I need gcc 4.3 to compile a specific application. I am hoping that I can install gcc 4.3 alongside 4.1.1 without suffering some awful catastrophe. This is the output of emerge on the machine in question: [...] Can someone confirm that I'll be able to use gcc 4.3 for the specific application that needs it but then revert to 4.1.1 without having to re-compile all or most of my system? I'm pretty sure you can. Emerge gcc 4.3, activate it with gcc-config, compile your application, and use gcc-config again to revert back to 4.1 if you like. Or keep 4.3 as default, I don't think you could run into problems. Wonko he will over time. If you switch default compiler emerge -s world has to be done. But seriously, why staying with 4.1? it's old... and 4.3 was a nice release... Except for me and a couple others. I had programs that crashed, couldn't get a kernel to work and other issues. I had to go back to 4.1on this rig. After going back, everything works fine. Dale :-) :-)
Re: [gentoo-user] coexisting GCC versions
On Sonntag 28 Juni 2009, Dale wrote: Volker Armin Hemmann wrote: On Sonntag 28 Juni 2009, Alex Schuster wrote: Roger Mason writes: I need gcc 4.3 to compile a specific application. I am hoping that I can install gcc 4.3 alongside 4.1.1 without suffering some awful catastrophe. This is the output of emerge on the machine in question: [...] Can someone confirm that I'll be able to use gcc 4.3 for the specific application that needs it but then revert to 4.1.1 without having to re-compile all or most of my system? I'm pretty sure you can. Emerge gcc 4.3, activate it with gcc-config, compile your application, and use gcc-config again to revert back to 4.1 if you like. Or keep 4.3 as default, I don't think you could run into problems. Wonko he will over time. If you switch default compiler emerge -s world has to be done. But seriously, why staying with 4.1? it's old... and 4.3 was a nice release... Except for me and a couple others. I had programs that crashed, couldn't get a kernel to work and other issues. I had to go back to 4.1on this rig. After going back, everything works fine. Dale :-) :-) *shrug* especially the kernel should never have had problems with 4.3 - except you were using strange patches... or very old kernels... I am at gcc 4.4 right now. Good choice actually...
Re: [gentoo-user] coexisting GCC versions
Volker Armin Hemmann writes: On Sonntag 28 Juni 2009, Alex Schuster wrote: Or keep 4.3 as default, I don't think you could run into problems. he will over time. If you switch default compiler emerge -s world has to be done. According to Alan McKinnon's (and my own experience), this is not necessary, unless there are ABI changes. But there were none between 4.1 and 4.3. http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg83724.html Wonko
Re: [gentoo-user] coexisting GCC versions
On Sonntag 28 Juni 2009, Alex Schuster wrote: Volker Armin Hemmann writes: On Sonntag 28 Juni 2009, Alex Schuster wrote: Or keep 4.3 as default, I don't think you could run into problems. he will over time. If you switch default compiler emerge -s world has to be done. According to Alan McKinnon's (and my own experience), this is not necessary, unless there are ABI changes. But there were none between 4.1 and 4.3. http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg83724.html Wonko you don't have to compile between 4.2.0 and 4.2.1 - sure. But with 4.2 to 4.3 I only got a stable system after compiling everything with the same compiler. So whatever Alan says - I know how borked my box was with half of the libs compiled by one compiler and the rest by the other.
Re: [gentoo-user] coexisting GCC versions
Volker Armin Hemmann wrote: On Sonntag 28 Juni 2009, Dale wrote: Except for me and a couple others. I had programs that crashed, couldn't get a kernel to work and other issues. I had to go back to 4.1on this rig. After going back, everything works fine. Dale :-) :-) *shrug* especially the kernel should never have had problems with 4.3 - except you were using strange patches... or very old kernels... I am at gcc 4.4 right now. Good choice actually... I was using the latest gentoo-sources and it either would fail to compile or the kernel it compiled would not boot. I also had problems with programs crashing and other odd things. After switching back to 4.1 and doing a emerge -e world, everything was fine. I plan to skip that gcc. Dale :-) :-)
[gentoo-user] plainTeX instead of LaTeX
Hi, after removing tetex and installing texlive-2008 by following his guide http://www.gentoo.org/proj/en/tex/texlive-migration-guide.xml I run into a mysterious problem: All my *.tex-files are handled as they would be written in LaTeX. But they are good old plainTeX. Where can I change thsi behaviour and what did I wrong in migrating from tetex? Thank you very much for your help in advance! Have a nice weekend! Kind regards, Meino Cramer -- Please don't send me any Word- or Powerpoint-Attachments unless it's absolutely neccessary. - Send simply Text. See http://www.gnu.org/philosophy/no-word-attachments.html In a world without fences and walls nobody needs gates and windows.
Re: [gentoo-user] coexisting GCC versions
In linux.gentoo.user, you wrote: --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gregory Shearman zek...@gmail.com said: In linux.gentoo.user, you wrote: he will over time. If you switch default compiler emerge -s world has t= o be=20 done. But seriously, why staying with 4.1? it's old... and 4.3 was a nice rel= ease... =20 Well, for me, media-plugins/mytharchive won't compile with gcc 4.3. Hopefully things will change with the next mythtv release. Please file a bug so we actually know about the problem and can fix it :) https://bugs.gentoo.org/ Have a look at this: http://bugs.gentoo.org/240379 It describes how mytharchive-0.21_p17948 requires an earlier version of mjpegtools (1.80) than the portage 1.90 version. mjpegtools-1.80 won't compile on gcc-4.3. Perhaps I didn't make myself completely clear when I said that mytharchive won't compile using gcc 4.3. It's mjpegtools 1.80 (required by mytharchive) that won't compile using gcc 4.3. -- Regards, Gregory.
