Re: [gentoo-user] new architectures for gentoo
On Saturday 27 July 2013 01:12:59 Stefan G. Weichinger wrote: Anyone seen that ... http://www.gentoogroup.com/for-customers/ ;-) You'll expect customers that build their projects themselves.
[gentoo-user] ksuperkey
Hi All, I would like to ask the kde team whether they know the ksuperkey application or not. Would it be possible to have in the portage tree? You can find further information here: http://blog.hanschen.org/2012/10/17/open-application-launcher-with-super-key/ Btw, not an rocket science to install it, and I did to myself, but it is useful, I think. Thanks in advance! András -- -- Csanyi Andras (Sayusi Ando) -- http://sayusi.hu -- http://facebook.com/andras.csanyi -- Trust in God and keep your gunpowder dry! - Cromwell
Re: [gentoo-user] Parallella supercomputer
Hi=) as far as i heard Parallella runs linux kernel on Zynq ARM core ONLY and Parallella cores act as a co-processor. So you can't get all its fancy cores out of box=(( you'll probably need to make some extreme kernel + openjdk hacks (and may be a lot of others). The main problem is that system runs on ARM core and Parallella cores are actually OpenRISC cores and i think that linux is not ready for such multiarch system, but I hope someday it will. I wanted to get some Parallella boards too, but for my needs maybe couple of Beagle Bone Black are more appropriate=) It's an ARM Cortex-A8 dev board with 2 1GHz cores, some 3d accelerator, 512MB DDR3 RAM, 2GB integrated eMMC storage + microSD slot, LAN, USB host and micro USB client for power and external PC control, microHDMI and audio through that HDMI, and a lot of GPIO and other pins. Doesn't have so many cores but 45$ only and it may run gentoo=) Perfect for scalable OSGi/JEE home cloud. http://beagleboard.org/Products/BeagleBone%20Black http://circuitco.com/support/index.php?title=BeagleBoneBlack (sorry for bad grammar, not my native language xD)
Re: [gentoo-user] new architectures for gentoo
On Saturday 27 Jul 2013 07:11:35 Pavel Volkov wrote: On Saturday 27 July 2013 01:12:59 Stefan G. Weichinger wrote: Anyone seen that ... http://www.gentoogroup.com/for-customers/ ;-) You'll expect customers that build their projects themselves. And, finely tune them to their requirements. LOL -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ksuperkey
On Saturday 27 Jul 2013 10:22:36 András Csányi wrote: Hi All, I would like to ask the kde team whether they know the ksuperkey application or not. Would it be possible to have in the portage tree? You can find further information here: http://blog.hanschen.org/2012/10/17/open-application-launcher-with-super-ke y/ Btw, not an rocket science to install it, and I did to myself, but it is useful, I think. Thanks in advance! András Better file a bug in BGO to request adding this software in the tree and volunteer your ebuild for it. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: ksuperkey
On 27/07/2013 19:22, András Csányi wrote: Hi All, I would like to ask the kde team whether they know the ksuperkey application or not. Would it be possible to have in the portage tree? You can find further information here: http://blog.hanschen.org/2012/10/17/open-application-launcher-with-super-key/ Btw, not an rocket science to install it, and I did to myself, but it is useful, I think. Thanks in advance! András Hi, ksuperkey is a fork of xcape, which is available in portage as x11-misc/xcape. I am not familiar with the differences between the two, but perhaps it may meet your needs. Best regards, Michael
[gentoo-user] failed to setup uefi boot
Hi,Everyone: I am a new user of gentoo,I encounter an error of the efibootmgr -c -d /dev/sda -p 1 -L Gentoo -l \efi\boot\bootx64.efi command.When I execute it ,I got Failed to write variable:No space left on device Failed to write variable:Input/Output error what's wrong with it？how can I fix it？ my kernel version is 3.8.13,and all config need by efi has enabled.
Re: [gentoo-user] Re: bash-completion change?
On Fri, Jul 26 2013, Neil Bothwick wrote: On Fri, 26 Jul 2013 16:46:21 -0500, Bruce Hill wrote: You probably forgot to re-emerge all packages that provide bash completion files: emerge -av1 \$(qfile -q -S -C /usr/share/bash-completion) little syntax help: emerge -av1 $(qfile -q -S -C /usr/share/bash-completion) emerge -1a /usr/share/bash-completion Yes we learned this trick a month or two ago. allan PS But my real problem is converting to systemd!
Re: [gentoo-user] failed to setup uefi boot
Am 27.07.2013 16:44, schrieb Wankey Cheng: Hi,Everyone: I am a new user of gentoo,I encounter an error of the efibootmgr -c -d /dev/sda -p 1 -L Gentoo -l \efi\boot\bootx64.efi command.When I execute it ,I got Failed to write variable:No space left on device Failed to write variable:Input/Output error what's wrong with it？how can I fix it？ my kernel version is 3.8.13,and all config need by efi has enabled. Make sure that you're system is booted in EFI mode, and also check that the kernel module efivars is loaded. signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: systemd - are we forced to switch?
On 07/26/2013 06:39 AM, gottl...@nyu.edu wrote: must I check that every entry previously in /etc/init.d now has an entry in /usr/lib/systemd/system? What do I do if there is no corresponding entry? I actually had to write a few of my own *.service files, which belong in /etc/systemd/system/ instead of /usr/lib64/systemd/system. (systemd looks in both places for service files) I started playing with systemd on a virtual gentoo machine many months ago when gentoo's systemd was still very incomplete and lacked *.system files for several important packages. I'm hoping the gentoo devs have made progress with that problem, but fedora and arch linux have already made the switch to systemd and you can steal *.service files from those if you need to. BTW, I'm still using systemd only on my virtual machines so far. The recent upgrade on ~amd64 is an ugly mess IMHO.
[gentoo-user] Reinventing the wheel
Alan McKinnon wrote: Steven J. Long wrote: POSIX 4: Programming for the Real World (Gallmeister, 1995) UNIX Network Programming vol 2: Interprocess Communications (Stevens, 1999) More here: https://foss.aueb.gr/posix/ I'll look into those, but do take note those books are 14 and 18 years old Yes I am aware of that ;) The age is not the point. The content and its relevance are. Further, you want Lewine 1994, first published 1991, if you're at all concerned about portability, so make it 20 years; and that doesn't get you the deep insight that really matters: read the books on the site in order if you want that, doing the exercises if you want to actually implement stuff. And ask in #friendly-coders for some more books ;) - that's eternity in our world. It's only really an eternity in compute-time, afaic. Calling something innovation doesn't make it innovative. And it certainly doesn't make it an invention. Nor is the speed with which fads and modern capitalism can move, any indication of progress. Sure a lot's happened. But not much has changed. One True Way is still around, it's just mutated into N+1 True Way, as we read something about Plan to throw one away, you will anyway and we've innovated that to Throw every version away as we don't know what an ABI promise means, and it's soo easy just to push a binary update, when you don't have to deal with the consequent service failure. Basics never change, details do. Some features are here for the long haul and I doubt anything will really change them: pipes, named pipes, unix sockets and things of that ilk. Which is why a 14-year old book describing them is still valid. There's actually a decade of other books by Stevens before that, and APUE (on the site) was updated in 2005 by Rago (who was writing about SysV networking at the same time as the first UNP and APUE.) Stevens himself died unfortunately: a _great_ loss. If you look on the site, you'll see vol 1 of UNP was also updated. And that's where the eternity of changes have really taken place: in remote networking, not in local IPC, which is a solved problem. If you know the background. And a programmer always should (or get another job, if learning it is too much.) There are newer versions of both APUE and UNP vol 1, but I hear they're not as good. So I'll get them when they're a bit cheaper, and I have some idle time. The real bugbear with IPC is people reinventing the wheel over and over and over to do simple messaging - Which is exactly why it pays to know about the existing mechanisms instead of trying to reinvent them. What you're saying here is exactly my point. writing little daemons that do very little except listen for a small number of messages from localhost and react to them. Use a generic message bus for that! There's no need. Most apps have a select/poll routine (or the equivalent) in any case, especially the ones that respond to events, including pretty much all desktop apps. So either you respond to the IPC channel in the main event routine, or you do some in a thread. There's several mechanisms, and several methods to do different things. POSIX gives you the standardised components: it's up to you to put them together. wrt a generic message bus that's called a message queue. And a programmer who finds them too difficult to use is basically a nub. I've read people say that because it's not an fd, it's not worth using. Which is completely amateur afaic: that's an awfully small comfort-zone. By all means push for an eventfd in POSIX: but in the meantime, be capable of more than one thing. AF_UNIX datagram sockets are fine too, and are in fact what dbus uses. As I said, I never actually criticised dbus itself: I'm fine with a desktop-session bus, to multiplex and broadcast the various events of user interest, and I quite liked the protocol when I first read up on it. To use that as basic plumbing for other things, is a bad idea imo. All you're doing is implementing a central point of failure, that has the additional borkage of being involved with user desktop events. A complete encapsulation nightmare imo. But I don't really care what other people do with their boxes: it doesn't affect me, so why should I? As others have pointed out, dbus is certainly not required for a production server, and I sincerely doubt it ever will be. There's too many experienced admins and coders who quietly earn a living off clean systems, without ever getting involved in mailing-list debates. It fits nicely in the grand Unix tradition of do one job and do it well, See below wrt filesystems. and few apps have passing messages around as their core function. Hand it off to the system, that's what it's there for. Exactly: the operating-system. It's such a common problem, and it has wider implications to do with scheduling and priority that come up around synchronisation, that it's all been provided several times already.
Re: [gentoo-user] Portage elog messages about historical symlinks
On Wednesday 24 Jul 2013 21:43:32 Kerin Millar wrote: On 24/07/2013 19:22, Mick wrote: I am getting messages like the one below from portage every now and then. Especially, about /var/run, but in this case about a different directory: * Messages for package dev-libs/klibc-1.5.20: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /usr/lib/klibc/include/asm * Perhaps I am having a senior moment, but I am not clear what I should do despite the friendly message. This is the symlink in question: ls -la /usr/lib/klibc/include/asm lrwxrwxrwx 1 root root 7 Nov 8 2008 /usr/lib/klibc/include/asm - asm-x86 How am I supposed to *replace* it with the directory that it points to? I would take it to mean that /usr/lib/klibc/include/asm should be a directory and contain the files that are currently residing in the asm-x86 directory. For example: # rm asm # mkdir asm # mv -- asm-x86/* asm/ # rmdir asm-x86 Thanks Kerin, I did as you suggested, remerged dev-libs/klibc and now waiting to see if anything breaks. Ha! -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
First hint: it's a mess -- don't do it on a critical machine. (My main machine is ~amd64 and that's why I'm doing it on virtual ~amd64 machines first.) The new gnome-shell demands that systemd be installed, even if you don't intend to use it. The latest systemd conflicts with udev because the udev project has been rolled into systemd, which now provides all of the files previously installed by udev. Therefore your machine will still boot without udev because systemd installs all the udev files. You don't need to start or use systemd if you don't want to, but the systemd package must be installed *before* you reboot and after removing udev. Removal of udev has caused a few (temporary) problems with useflags, because a few packages still depend directly on udev instead of the newer (!systemd ? udev) which means accept either one but not both. That will get fixed soon, I'm sure. The right way to upgrade gnome is probably to remove every gnome package on the machine, which will avoid many of the conflicts I've had to fight for the last two days -- but of course I did it the hard way instead :) You can try emerge -au gnome-light early in the update, which is simpler than emerging gnome in all its immensity, but that's no guarantee of success -- I'm sure you'll still run into conflicts between packages and useflags, but it might be a bit easier. When you see conflicting packages that won't install, I suggest deleting both packages immediately -- let portage sort out the conflicts. Just keep removing packages until portage finally stops complaining. Beware of pambase, however. I finally took Canek's advice and removed consolekit from the machine and unset the useflag for all packages, including pambase and polkit. I'd suggest you get pambase and polkit re-installed with the proper useflags before you try to reboot. Dunno if that's mandatory, but I did it that way and had no problems (yet). I've finished updating my virtual gentoo systemd machine now, but I'm still fighting with the virtual openrc machine and I'm not sure how it will turn out. More tomorrow :)
Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Jul 27, 2013 4:44 PM, walt w41...@gmail.com wrote: First hint: it's a mess -- don't do it on a critical machine. (My main machine is ~amd64 and that's why I'm doing it on virtual ~amd64 machines first.) The new gnome-shell demands that systemd be installed, even if you don't intend to use it. The latest systemd conflicts with udev because the udev project has been rolled into systemd, which now provides all of the files previously installed by udev. Therefore your machine will still boot without udev because systemd installs all the udev files. You don't need to start or use systemd if you don't want to, but the systemd package must be installed *before* you reboot and after removing udev. Removal of udev has caused a few (temporary) problems with useflags, because a few packages still depend directly on udev instead of the newer (!systemd ? udev) which means accept either one but not both. That will get fixed soon, I'm sure. The right way to upgrade gnome is probably to remove every gnome package on the machine, which will avoid many of the conflicts I've had to fight for the last two days -- but of course I did it the hard way instead :) You can try emerge -au gnome-light early in the update, which is simpler than emerging gnome in all its immensity, but that's no guarantee of success -- I'm sure you'll still run into conflicts between packages and useflags, but it might be a bit easier. When you see conflicting packages that won't install, I suggest deleting both packages immediately -- let portage sort out the conflicts. Just keep removing packages until portage finally stops complaining. Beware of pambase, however. I finally took Canek's advice and removed consolekit from the machine and unset the useflag for all packages, including pambase and polkit. I'd suggest you get pambase and polkit re-installed with the proper useflags before you try to reboot. Dunno if that's mandatory, but I did it that way and had no problems (yet). I've finished updating my virtual gentoo systemd machine now, but I'm still fighting with the virtual openrc machine and I'm not sure how it will turn out. More tomorrow :) I haven't upgraded yet to the last update (although I've been using GNOME 3+systemd for years), but I do know this: the primary reason of GNOME's dependency on systemd is logind, and logind *CANNOT* run correctly if systemd is not the running init. So you not only need to install systemd: you need to use it as init. I don't even think logind can start if systemd is not running. And actually, the long term plan is for systemd --user to basically replace gnome-session-manager, so just installing systemd is not going to work at all in the future, even if it *may* seems to work now (which I'm pretty sure it doesn't). systemd provides some pretty complex functionality for logind (and therefore GNOME) while running; it's not just some libraries. Regards.
Re: [gentoo-user] Re: systemd - are we forced to switch?
walt w41...@gmail.com wrote: On 07/26/2013 06:39 AM, gottl...@nyu.edu wrote: must I check that every entry previously in /etc/init.d now has an entry in /usr/lib/systemd/system? What do I do if there is no corresponding entry? I actually had to write a few of my own *.service files, which belong in /etc/systemd/system/ instead of /usr/lib64/systemd/system. (systemd looks in both places for service files) I started playing with systemd on a virtual gentoo machine many months ago when gentoo's systemd was still very incomplete and lacked *.system files for several important packages. I'm hoping the gentoo devs have made progress with that problem, but fedora and arch linux have already made the switch to systemd and you can steal *.service files from those if you need to. BTW, I'm still using systemd only on my virtual machines so far. The recent upgrade on ~amd64 is an ugly mess IMHO. Any documentation on what is in a service file? It does not look too bad, but I would rather see the full documentation on what you can have in there and exactly how they work. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Re: systemd - are we forced to switch?
systemd.unit (5) systemd.service (5) On Jul 28, 2013 6:26 AM, cov...@ccs.covici.com wrote: walt w41...@gmail.com wrote: On 07/26/2013 06:39 AM, gottl...@nyu.edu wrote: must I check that every entry previously in /etc/init.d now has an entry in /usr/lib/systemd/system? What do I do if there is no corresponding entry? I actually had to write a few of my own *.service files, which belong in /etc/systemd/system/ instead of /usr/lib64/systemd/system. (systemd looks in both places for service files) I started playing with systemd on a virtual gentoo machine many months ago when gentoo's systemd was still very incomplete and lacked *.system files for several important packages. I'm hoping the gentoo devs have made progress with that problem, but fedora and arch linux have already made the switch to systemd and you can steal *.service files from those if you need to. BTW, I'm still using systemd only on my virtual machines so far. The recent upgrade on ~amd64 is an ugly mess IMHO. Any documentation on what is in a service file? It does not look too bad, but I would rather see the full documentation on what you can have in there and exactly how they work. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
[gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On 07/27/2013 03:08 PM, Canek Peláez Valdés wrote: And actually, the long term plan is for systemd --user to basically replace gnome-session-manager, Is Lennart part of the gnome project now? ;) so just installing systemd is not going to work at all in the future, even if it *may* seems to work now (which I'm pretty sure it doesn't). Maybe I'll be able to confirm or deny tomorrow morning :) The update will take all night (on my slower machine) but I fear that the build will quit with an error as soon as my head hits the pillow. I'll let you know in the morning. As an aside, I got this great idea for automating the update: Instead of removing all gnome packages before updating gnome (much too much boring work for lazy me) I updated the glib package first because All Things Gnome depend on glib. Then I started revdep-rebuild, which of course will automatically re- install every gnome package on the machine (and update to the latest versions of everything in the process :). Of course portage refused to do the glib update because of a zillion or more package conflicts, so I worked around that by running: #ebuild /usr/portage/dev-libs/glib/glib-2.36.3-r1 merge Let's see how many hours of pain my laziness will cost me this time :)
Re: [gentoo-user] Re: systemd - are we forced to switch?
Mark David Dumlao madum...@gmail.com wrote: systemd.unit (5) systemd.service (5) On Jul 28, 2013 6:26 AM, cov...@ccs.covici.com wrote: walt w41...@gmail.com wrote: On 07/26/2013 06:39 AM, gottl...@nyu.edu wrote: must I check that every entry previously in /etc/init.d now has an entry in /usr/lib/systemd/system? What do I do if there is no corresponding entry? I actually had to write a few of my own *.service files, which belong in /etc/systemd/system/ instead of /usr/lib64/systemd/system. (systemd looks in both places for service files) I started playing with systemd on a virtual gentoo machine many months ago when gentoo's systemd was still very incomplete and lacked *.system files for several important packages. I'm hoping the gentoo devs have made progress with that problem, but fedora and arch linux have already made the switch to systemd and you can steal *.service files from those if you need to. BTW, I'm still using systemd only on my virtual machines so far. The recent upgrade on ~amd64 is an ugly mess IMHO. Any documentation on what is in a service file? It does not look too bad, but I would rather see the full documentation on what you can have in there and exactly how they work. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com Heavens, never thought of actual man pages for those! Must be getting long in tooth. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Sat, Jul 27, 2013 at 03:56:41PM -0700, walt wrote On 07/27/2013 03:08 PM, Canek Peláez Valdés wrote: And actually, the long term plan is for systemd --user to basically replace gnome-session-manager, Is Lennart part of the gnome project now? ;) Lennart is a Redhat employee, and Gnome+systemd are Redhat's pride and joy. It's not linux anymore, it's REDHAT-GNOME-OS. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update
On Jul 27, 2013 5:57 PM, walt w41...@gmail.com wrote: On 07/27/2013 03:08 PM, Canek Peláez Valdés wrote: And actually, the long term plan is for systemd --user to basically replace gnome-session-manager, Is Lennart part of the gnome project now? ;) He has been on Planet GNOME for many years now. When people talks about GNOME OS, it implicitly includes the Linux kernel, sytemd/udev (including journald, hostnamed, logind, etc.), dbus, Avahi, PulseAudio, and all the GNOME stack from glib up to GNOME Shell. Vertical tight integration from kernel to end user apps. Regards.
Re: [gentoo-user] failed to setup uefi boot
Make sure that you're system is booted in EFI mode i didn't install a bootloader,so it can be booted in EFI mode only. and also check that the kernel module efivars is loaded. do you mean EFI variable Support via sysfs?Yes,it's built-in my kernel 2013/7/27 Michael Hampicke m...@hadt.biz Am 27.07.2013 16:44, schrieb Wankey Cheng: Hi,Everyone: I am a new user of gentoo,I encounter an error of the efibootmgr -c -d /dev/sda -p 1 -L Gentoo -l \efi\boot\bootx64.efi command.When I execute it ,I got Failed to write variable:No space left on device Failed to write variable:Input/Output error what's wrong with it？how can I fix it？ my kernel version is 3.8.13,and all config need by efi has enabled. Make sure that you're system is booted in EFI mode, and also check that the kernel module efivars is loaded.
[gentoo-user] You need at least GCC 4.7.x or Clang = 3.0 for C++11-specific compiler flags
Hello mates, I am facing the following issue, not sure why I have been trying to fix it for 3 days now. I've also installed Clang, but the same results. Additional information: ~AMD64 emerge --info here: http://tny.cz/c2210f24 Build log: ^[[32;01m * ^[[39;49;00mPackage:net-libs/webkit-gtk-2.0.4 ^[[32;01m * ^[[39;49;00mRepository: gentoo ^[[32;01m * ^[[39;49;00mMaintainer: gn...@gentoo.org ^[[32;01m * ^[[39;49;00mUSE:amd64 elibc_glibc geoloc gstreamer introspection jit kernel_linux userland_GNU webgl ^[[32;01m * ^[[39;49;00mFEATURES: preserve-libs sandbox userpriv usersandbox ^[[31;01m*^[[0m ERROR: net-libs/webkit-gtk-2.0.4::gentoo failed (pretend phase): ^[[31;01m*^[[0m You need at least GCC 4.7.x or Clang = 3.0 for C++11-specific compiler flags ^[[31;01m*^[[0m ^[[31;01m*^[[0m Call stack: ^[[31;01m*^[[0m ebuild.sh, line 93: Called pkg_pretend ^[[31;01m*^[[0m webkit-gtk-2.0.4.ebuild, line 93: Called die ^[[31;01m*^[[0m The specific snippet of code: ^[[31;01m*^[[0mdie You need at least GCC 4.7.x or Clang = 3.0 for C++11-specific compiler flags ^[[31;01m*^[[0m ^[[31;01m*^[[0m If you need support, post the output of `emerge --info '=net-libs/webkit-gtk-2.0.4::gentoo'`, ^[[31;01m*^[[0m the complete build log and the output of `emerge -pqv '=net-libs/webkit-gtk-2.0.4::gentoo'`. ^[[31;01m*^[[0m The complete build log is located at '/var/tmp/portage/net-libs/webkit-gtk-2.0.4/temp/build.log'. ^[[31;01m*^[[0m The ebuild environment file is located at '/var/tmp/portage/net-libs/webkit-gtk-2.0.4/temp/die.env'. ^[[31;01m*^[[0m Working directory: '/usr/lib64/portage/pym' ^[[31;01m*^[[0m S: '/var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4' Any help? -- Carlos Sura.- www.carlossura.com www.carlossura.com/blog
[gentoo-user] Re: You need at least GCC 4.7.x or Clang = 3.0 for C++11-specific compiler flags
Nevermind mates, I've just upgraded the GCC to latest and it worked out. Thanks! On 27 July 2013 20:55, Carlos Sura carlos.su...@googlemail.com wrote: Hello mates, I am facing the following issue, not sure why I have been trying to fix it for 3 days now. I've also installed Clang, but the same results. Additional information: ~AMD64 emerge --info here: http://tny.cz/c2210f24 Build log: ^[[32;01m * ^[[39;49;00mPackage:net-libs/webkit-gtk-2.0.4 ^[[32;01m * ^[[39;49;00mRepository: gentoo ^[[32;01m * ^[[39;49;00mMaintainer: gn...@gentoo.org ^[[32;01m * ^[[39;49;00mUSE:amd64 elibc_glibc geoloc gstreamer introspection jit kernel_linux userland_GNU webgl ^[[32;01m * ^[[39;49;00mFEATURES: preserve-libs sandbox userpriv usersandbox ^[[31;01m*^[[0m ERROR: net-libs/webkit-gtk-2.0.4::gentoo failed (pretend phase): ^[[31;01m*^[[0m You need at least GCC 4.7.x or Clang = 3.0 for C++11-specific compiler flags ^[[31;01m*^[[0m ^[[31;01m*^[[0m Call stack: ^[[31;01m*^[[0m ebuild.sh, line 93: Called pkg_pretend ^[[31;01m*^[[0m webkit-gtk-2.0.4.ebuild, line 93: Called die ^[[31;01m*^[[0m The specific snippet of code: ^[[31;01m*^[[0mdie You need at least GCC 4.7.x or Clang = 3.0 for C++11-specific compiler flags ^[[31;01m*^[[0m ^[[31;01m*^[[0m If you need support, post the output of `emerge --info '=net-libs/webkit-gtk-2.0.4::gentoo'`, ^[[31;01m*^[[0m the complete build log and the output of `emerge -pqv '=net-libs/webkit-gtk-2.0.4::gentoo'`. ^[[31;01m*^[[0m The complete build log is located at '/var/tmp/portage/net-libs/webkit-gtk-2.0.4/temp/build.log'. ^[[31;01m*^[[0m The ebuild environment file is located at '/var/tmp/portage/net-libs/webkit-gtk-2.0.4/temp/die.env'. ^[[31;01m*^[[0m Working directory: '/usr/lib64/portage/pym' ^[[31;01m*^[[0m S: '/var/tmp/portage/net-libs/webkit-gtk-2.0.4/work/webkitgtk-2.0.4' Any help? -- Carlos Sura.- www.carlossura.com www.carlossura.com/blog -- Carlos Sura.- www.carlossura.com www.carlossura.com/blog
