drobbins

Stac, the official policy on this is that funtoo containers don't have any kind of uptime guarantee, and you host things on them at your own risk. Several people do host production things on them. It's fine to do this. Just understand that if there is some issue, I'm not available 24x7 to look into it.

You're welcome. I just integrated UEFI into the install guide and tried to make it flow a lot better.

I continue to hit this build issue, so it is not fixed. It's an intermittent build failure of some kind. It will break in exactly this spot.

Hi Everyone, Be sure to check out the new Install Guide functionality documented here: http://www.funtoo.org/News:Modular_Install_Guide_Parts Best Regards, Daniel

No, don't worry about USE except when it comes up for tips/tricks related to successful install. I am automatically importing USE flag descriptions from metadata.xml for forked and overlay ebuilds and hope to add Gentoo ones soon.

We could add back grub-mkconfig in a future ebuild of grub so it's available for those who want to use it. You can open a bug on this.

Have someone do an emerge --quickpkg portage for you and install the resultant tarball by extracting to /: # tar xpf portage.tbz2 -C /

Here's the official info for testing: http://www.funtoo.org/News:Testing_GNOME_3.14

Deleting /usr/portage doesn't cause emerge to fail on --sync, so you have something else going on. It's perfectly fine to rm -rf /usr/portage and emerge --sync to get a new copy. This is something that works.

It can be really hard to figure out what is going wrong with a kernel. I am going through my own issues with a server motherboard I have. With 3.17.0, my PCI firewire card stops working. It's not related to the firewire driver exactly -- it can't allocate an IRQ! What I did, per the suggestion of the firewire devs, is to "bisect" my kernel. That means I used the "git bisect" feature to narrow down the *exact* commit that caused the kernel to start failing on my hardware. I was then able to contact the Intel developer who made the commit, who is being very helpful and considers it a regression (bug), and is trying to fix it. The basic process for bisecting a kernel is to git clone the kernel sources, and then you use the git bisect command to tag "good" and "bad" versions. git bisect will find the middle commit between good and bad, which you then compile and see if it works or not. If yes, it gets tagged as good, if not, it is tagged as bad. Eventually (took me 13 tries), I found the *exact* commit that caused my issue. Then I could contact someone who could help.

To answer the original poster's question, yes, -pulseaudio in make.conf before you merge things should disable it. There are a few things that will want pulseaudio, like if you have the GNOME mix-in enabled, etc.

Oh, and my suggestion is to try an earlier ebuild version of qemu and see if the problems go away.

It may work for some people, but please give it a name other than funtoo-sources. Maybe something like funtoo-desktop-sources as this kernel is geared for desktops.

I have not tried VNC. Spice works, but I have noticed noticeably more segfaults. These happen when rebooting a win7 image.

Yes, I use this on Funtoo servers :) Full documentation on how to set up is here: http://www.funtoo.org/Traffic_Control

I have started work on this: https://bugs.funtoo.org/browse/FL-1627

I think maybe the best approach is to create an /etc/init.d/ModemManager and add a "depend" entry to NetworkManager that says "use ModemManager". Then if you want ModemManager to be started prior to NetworkManager, you would add your ModemManager script to the default runlevel. depend{ use foo; } in an OpenRC script means "start foo first if it is already enabled for this runlevel." depend{ need foo; } means "start foo first, even if it hasn't been added to this runlevel."

If you build it in a 32-bit chroot then it will build a 32-bit verson for you. If you want, you can modify the config_extract call in src_prepare (in the ebuild) to do something a little bit different. But for right now, there is no way to control this using USE variables or the like.

This has now been fixed in our Portage tree.

Hi All, Here are some updates on Funtoo Hosting. I've added a second server, configured identically as the first, to the mix. Right now, it's in "beta" mode as it is having some cooling issues, likely due to thermal grease that needs replacement. It is stable, just hits the CPU throttle temp and performance is affected somewhat. Expect to have this resolved shortly. OpenVZ kernels have been upgraded to the latest versions on both servers. Live migration between servers is now functioning, which means i can move your container between servers without you even knowing it happened :) I can even reboot the server when I need to do a kernel update, and your system will freeze for 30 seconds and then come back online in the exact state it was in prior to reboot. Cool stuff. I have also enabled QoS on both servers which should result in much better network responsiveness, and dedicated bandwidth for UDP packets which are typically used for game hosting as well as mosh sessions. ssh interactive packets are also being prioritized to improve interactive ssh responsiveness. As part of these changes, I've also gotten HP's Health Management software working under Funtoo! I've documented how to do this here: http://www.funtoo.org/HP_Health_Management

Some good submissions here -- thanks for your work :)

This has now *really* been fixed, for all account operations :)

And please add this info to the wiki docs so everyone can benefit :)

Nothing from Lennart is unusual for a young male geek, but that doesn't mean that his approach is not harmful to the Linux community. A lot of distributions were strong-armed into using systemd to maintain compatibility with GNOME, and this hasn't bothered Lennart one bit, and it should have. I agree with several comments in earlier threads. Funtoo will remain a non-systemd system and will eventually be upgrading OpenRC to be competitive with systemd. Frankly, GNOME 3.6 worked quite a bit better than GNOME 3.12. I had tabbed terminal windows and a few other things were cleaner. So it's not always extremely useful to follow GNOME's latest release. I do like the general design of GNOME 3 but in some ways they seem to be continually regressing.

The short update is that I have been distracted by paid work, and upgrading our wiki, but this is coming back on the radar...