adessemond

1. Are your zfs modules loaded ? 2. What are saying your system logs?

Yes definitely, this is a x86 SoC (Atom processor). I don't own one by myself but someone shared some notes: http://gentoo.ed-solutions.de/dokuwiki/start:edison I don't promise you it will be straightforward process, you might swear after getting the correct kernel configuration.

Hi, Just to make you aware that I did a more than overdue clean up with dev-util/codelite. Latests ebuilds in portage match the latest 9.x series and very older versions have been removed. See https://bugs.funtoo.org/browse/FL-3165

Everything back in working order thanks.

Just in case of this has not been corrected yet.... If opening a bug is preferable, will do. !!! Fetched file: corenetwork-1.5.3.tar.gz VERIFY FAILED! !!! Reason: Insufficient data for checksum verification !!! Got: !!! Expected: MD5 RMD160 SHA1 SHA256 SHA512 WHIRLPOOL * Fetch failed for 'sys-apps/corenetwork-1.5.3', Log file: * '/var/tmp/portage/sys-apps/corenetwork-1.5.3/temp/build.log'

I do have those errors since a long time, never managed to solve them in a clean way, at the end I did 'chown o+x /usr/libexec/dbus-daemon-launch-helper' but I don't think this to be a good idea. Already rebuild stuff like glib,dbus-glib, polkit-kde-agent, etc but no joy. Any idea?

If someone is willing to maintain it, I guess it can be possible. Just a matter of writing a new profile.

Thanks, a good way to promote our work: organize a workshop or a talk at your local LUG. You could be surprised of the interest. Here in Quebec city some friends did that but over several weeks and with an announced step-by-step agenda. More than 20 people attended the training session and this is how they made the Quebec city Gentoo/Funtoo community to be "on the map".

VLC 2.2.0 has several problems here => http://forums.funtoo.org/topic/422-forking-vlc/

I have not reported this bug so far but vlc 2.2.0 has several troubles: FreeRDP >= 1.2 removed a public function thus => "access/rdp.c:507:5: error: implicit declaration of function ?freerdp_channels_global_uninit? [-Werror=implicit-function-declaration]" The use flag rdp has been removed so a patch must be applied on VLC (or FreeRDP must be downgraded) A lot of use flags are undocumented right now Would forking the package be suitable? At least for the time taken by the upstream to fix it.

Good job!

In the case you don't set the use flags related to processor's instructions sets, the softwares you will compile will simply not take any advantage of built-in CPU hardware support for some of their operations. However not all packages but multimedia stuff (typical case) make use of enhanced processor instructions. If you want to check what package use what flag equery h will tell: # equery h mmx * Searching for USE flag mmx ... [IP-] [ ] media-libs/smpeg-0.4.4-r10:0 [IP-] [ ] media-sound/lame-3.99.5-r1:0 [IP-] [ ] media-video/mjpegtools-2.1.0-r2:1 To answer your question: you SHOULD enable support for CPU's enhanced instructions, unless you have a good reason to leave it disabled (i.e. known bug, strange crash....) However to bring a bit of nuance: a use flag is simply a handle given to you by an ebuild developer to enable/disable some features at compilation time, not having a use flag in a ebuild is not a warranty that the software will not include some CPU special instructions in its binary code.

No please don't, CPU flags shown in /proc/cpuinfo are totally unrelated to Funtoo's package system. They only give a hint about what your CPU supports.

Funtoo systems running under the testing/stable branch (glibc-2.19) are not vulnerable to this exploit (details => http://www.openwall.com/lists/oss-security/2015/01/27/9 ) Taken from the above link, here is a test-case : $cat > GHOST.c << EOF #include <netdb.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #define CANARY "in_the_coal_mine" struct { char buffer[1024]; char canary[sizeof(CANARY)]; } temp = { "buffer", CANARY }; int main(void) { struct hostent resbuf; struct hostent *result; int herrno; int retval; /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/ size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1; char name[sizeof(temp.buffer)]; memset(name, '0', len); name[len] = '\0'; retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno); if (strcmp(temp.canary, CANARY) != 0) { puts("vulnerable"); exit(EXIT_SUCCESS); } if (retval == ERANGE) { puts("not vulnerable"); exit(EXIT_SUCCESS); } puts("should not happen"); exit(EXIT_FAILURE); } EOF

From a command line, try to launch FF with a strace command (it will generate *a lot of* information, don't pay much attention to what is reported by strace at this time) then close FF and note what are the very latest displayed lines. In my case FF exits properly: $ strace firefox execve("/usr/bin/firefox", ["firefox"], [/* 40 vars */]) = 0 brk(0) = 0x193b000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9f3d24a000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 ***** A lot of omitted text **** [Firefox is closed] ***** A lot of omitted text **** munmap(0x7fec2ccff000, 8392704) = 0 write(11, "\0", 1) = 1 futex(0x7fec3a77a9d0, FUTEX_WAIT, 4015, NULL) = 0 munmap(0x7fec1fcfe000, 8392704) = 0 munmap(0x7fec39143000, 5963902) = 0 munmap(0x7fec3879f000, 10107970) = 0 futex(0x7fec353ba98c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7fec353ba988, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 futex(0x7fec352ff9d0, FUTEX_WAIT, 4034, NULL) = 0 munmap(0x7fec24eff000, 8392704) = 0 unlink("/root/.mozilla/firefox/8ejigyve.default/lock") = 0 close(6) = 0 exit_group(0) = ? +++ exited with 0 +++ Could you please post your result here? At this point your instance of Firefox might be waiting for something to happen (lock on a file to be freed, futex, etc) but it is hard to tell a priori where and why it hangs.