sputnik

You don't have wpa_supplicant in rc do you? Only NetworkManager should be there, no dhcpcd either. My best guess.

I thought maybe that was it, having restarted hostname a few times, but no, this morning on start I've got duped entries, cleaned it last night. Snooped around a little last night, didn't see anything that jumps out & grabs me. Also noticed the arms are doing it too, watched it closely a couple of months ago after the change, was working right then. So maybe a funky version? Hope they fix it. Maybe a little creativity with the /etc/init.d/hostname file...

It's pretty annoying, isn't it? Especially since without warning it nukes your /etc/hosts file with no backup. Fear not though, still the same, the aliases just get copied over automatically from your /etc/conf.d/hostname file each startup. Check that file out, it tells you how to do it. cat /etc/conf.d/hostname # Set to the hostname of this machine hostname="thishearmachine" #aliases="" aliases="192.168.1.100 thishearrouter 192.168.1.102 someothermachine" etc. And then it was released in stages. My arm machines a couple of months ago, amd64 a week ago, x86 a couple of days later. Never a dull moment. BUT Once I got used to it on the arms, it works fine. Today though I noticed that it was repeatedly pasting the aliases in the /etc/hosts file over and over again on my amd64, apparently not rewriting new each time as the arms do, and as is implied. I don't know what that's about yet, gotta check it out.

Issue solved, see latest bug report post. But I don't know how long it will take to implement the fix, so you may wish to go ahead with above instructions.

Oh, thank you too. I'll do that too. I love it when I don't have to think.

I had serious problems with the 3932 version. Please refer to the bug report to keep up if you are interested, I will be posting further updates there.

I believe I have that issue too. I rarely use hibernate, so too lazy to fix it. I do know however, I had an issue with sleep and found that the linux ethernet driver didn't like to sleep for me. The manufacturer's driver had other issues, but would sleep. So I would trade them out (I still do this): # cat /etc/pm/sleep.d/77ethernet #!/bin/bash case $1 in suspend) modprobe -r r8169 modprobe r8168 ethtool -s eth0 wol bg ;; resume) modprobe -r r8168 modprobe r8169 ethtool -s eth0 wol bg ;; esac Every new kernel I rebuild the manufacturer driver too. So there's some extra confusion if you decide to go after this.

The compiz team apparently is having some problem with that particular vintage. https://bugs.funtoo.org/browse/FL-2212 If you are really set on doing this soon you can follow my instructions on setting up the local repository. When you save the ebuild, change this line in it: # change this: SRC_URI="http://bazaar.launchpad.net/~compiz-team/compiz/0.9.12/tarball/3919 -> ${P}.tgz" # to this: SRC_URI="http://bazaar.launchpad.net/~compiz-team/compiz/0.9.12/tarball/3932 -> ${P}.tgz" And you'll want to be sure and set up your make.conf my way, so that the compiz-0.9.12 in your local repository takes precedence. Welcome to the bleeding edge, it's the very latest build :D I just installed it, gonna reboot after writing this. Else you'll have to wait for Oleg to fix it.

Yes, once again I must apologize to you for misunderstanding Sandro. You did everything right, there is some problem, the ebuild is not downloading the file properly, I got the same thing you did. I'll find out why and file a bug, we'll fix it soon.

Oh my. I just re-read your post #10, apparently you did get it to work in stable without a local rebuild, it just had trouble downloading? Perhaps you might hold off doing the local repository, I'll try it here and see if they are having some problem. BRB

Sorry, busy afternoon here. Yes, you must never modify anything in /usr/portage in any way. That includes editing existing files or adding files to those directories. Almost everybody has done that once, it's called learning B) Because the next time you try to use portage you find out it's broken. Not the end of the world, you can just do rm -r /usr/portage, delete it and then do emerge --sync. But it takes about 40 minutes here to completely rebuild (heh, I know exactly how long here, is that a clue?) It's really easy Sandro. Just as you have a Funtoo tree that contains ebuilds (you can LOOK in /usr/portage to get an idea), you are going to create a Sandro tree, that augments the Funtoo tree, is used in addition. This is done for packages that can't be obtained in the normal tree for example. The Funtoo tree remains totally unchanged, you make your changes in the Sandro tree (or whatever you want to call it). Compartmentalization (bet it's the same word in Italian). So, this link on Gentoo tells you how to do it, but they are a bit out of sync with what we would do in Funtoo, so I'll go through the steps here. root # install -d /usr/local/portage/profiles root # echo 'NameOfYourOverlay' > /usr/local/portage/profiles/repo_name # I've never done the next step, I recommend skipping it, think it's Gentoo only ###skip this!!!###root # echo 'masters = gentoo' > /usr/local/portage/metadata/layout.conf root # chown -R portage:portage /usr/local/portage And there you go! Your very own repository. Now you have to tell portage to start using it: root # echo 'PORTDIR_OVERLAY="/usr/local/portage ${PORTDIR_OVERLAY}"' >> /etc/portage/make.conf Hmm, well that's what the Gentoo wiki says, I do it differently: # MY /etc/portage/make.conf # ... LOCAL="/usr/local/portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="${PORTDIR} ${LOCAL}" # ... Using my method, whichever repository is listed LAST on the {PORTDIR_OVERLAY} variable takes precedence, meaning if two identical ebuilds (and version numbers) are in both repositories, the one in {LOCAL} in my case would be used. This can be a handy feature. Now portage will search your repository as well as Funtoo's when upgrading or installing. Specifically in this case you'll add this folder to your repository: root # install -d /usr/local/portage/x11-wm/compiz Now take the ebuild above and save it as /usr/local/portage/x11-wm/compiz/compiz-0.9.12.ebuild Now we are going to cross our fingers and hope you have the patches the ebuild needs to do it's job, else I'll have to get those to you over #funtoo or something. So this is a handy cheat, just link the patch directory that already exists for compiz in the Funtoo tree: root # ln -s /usr/portage/x11-wm/compiz/files /usr/local/portage/x11-wm/compiz Any time you add an ebuild, you have to build a manifest for it. It's easy, like this: root # cd /usr/local/portage/x11-wm/compiz root # ebuild compiz.0.9.12.ebuild manifest It'll cook for a few seconds, then you will see a file called Manifest in the directory. Finally, since stable apparently only knows about compiz-0.8.8, you have to unmask your new ebuild for portage: root # echo "=x11-wm/compiz-0.9.12 **">>/etc/portage/package.accept_keywords Now you're ready! emerge -av compiz and see what pops up, it should try to install the new version. Probably we have opened a can of worms here because you most likely don't have the newer emerald too. We'll cross that bridge when we come to it.

You cannot add an ebuild to /usr/portage, it will mess up your entire funtoo repository, sorry I didn't know your capabilities. Please remove it before you sync or anything! I'll be back with more instructions shortly.

If I had your computer, even if there was nobody around to impress I would say "Vroooom vrooooom!" every time it started up. yw

Ah, I see. It's because the first entry should not have the +=. I apologize for leading you astray. Like this: "Funtoo Linux genkernel" { kernel kernel[-v] initrd initramfs[-v] params real_root=/dev/sda6 params += rootfstype=ext4 Here's mine, working fine: "And we're gonna have Funtoo!" { kernel vmlinuz[-v] initrd /initramfs-funtoo[-v] params quiet params += splash params += nomodeset params += raid=noautodetect params += pcie_aspm=force params += video=uvesafb:1440x900-32,mtrr:3,ywrap params += rootfstype=auto params += rd.luks=0 params += rd.lvm=0 params += rd.md=0 params += rd.dm=0 params += rootflags=rw,noatime,attr2,inode64,noquota params += resume=UUID=a6d5ff0d-a43c-4586-9552-651be34fa82c params += root=auto }

It's not arrested, just slowed. The big guns are all moving on to wayland, which _someday will give us better things. But there's plenty of compiz fans that are keeping it alive. There's a new version every couple of days or so. Yes, I know what you mean about that compiz-fusion and such, really it's not worth it, you will find the newer version will work great for you, much more stable. Compiz 0.9.1x is my stand-alone desktop for a couple of years now. 0.9.12 is in portage, perhaps you have to unmask it as I suggested above? I've never run stable, so not sure, but I think you should have access to it. If not, you can just download the ebuild and put it in your local repository. You'll still have to unmask it. Hmm, I don't find it readily online either. Well here's the ebuild anyhow, you may need patches, if you do, let me know I'll get them for you. #/usr/portage/x11-wm/compiz/compiz-0.9.12.ebuild # Distributed under the terms of the GNU General Public License v2 EAPI=4 #GIT_ECLASS="git-2" #EGIT_REPO_URI="https://github.com/hedmo/compiz" #inherit cmake-utils eutils ${GIT_ECLASS} gnome2-utils toolchain-funcs python # Pick your poison, EITHER the 3 lines above or the 2 lines below SRC_URI="http://bazaar.launchpad.net/~compiz-team/compiz/0.9.12/tarball/3919 -> ${P}.tgz" inherit cmake-utils eutils gnome2-utils toolchain-funcs python KEYWORDS="*" S="${WORKDIR}/~compiz-team/${PN}/${PV}" DESCRIPTION="OpenGL window and compositing manager" HOMEPAGE="http://www.compiz.org/" PATCHSET_URI="https://github.com/megabaks/stuff/blob/master/x11-wm/compiz/files/compiz-kde-4.8.patch" LICENSE="GPL-2 LGPL-2.1 MIT" SLOT="0" IUSE="+cairo debug dbus fuse gnome gtk kde +svg test" COMMONDEPEND=" dev-libs/boost dev-libs/glib:2 dev-cpp/glibmm dev-libs/libxml2 dev-libs/libxslt dev-python/pyrex dev-libs/protobuf media-libs/libpng x11-base/xorg-server x11-libs/libX11 x11-libs/libXcomposite x11-libs/libXdamage x11-libs/libXext x11-libs/libXrandr x11-libs/libXrender x11-libs/libXinerama x11-libs/libICE x11-libs/libSM x11-libs/startup-notification virtual/opengl virtual/glu cairo? ( x11-libs/cairo[X] ) fuse? ( sys-fs/fuse ) gtk? ( >=x11-libs/gtk+-2.18.0 >=x11-libs/libwnck-2.19.4 x11-libs/pango gnome? ( gnome-base/gnome-desktop gnome-base/gconf x11-wm/metacity ) ) kde? ( kde-base/kwin:4 ) svg? ( gnome-base/librsvg:2 x11-libs/cairo ) dbus? ( sys-apps/dbus )" DEPEND="${COMMONDEPEND} app-admin/chrpath virtual/pkgconfig x11-proto/damageproto x11-proto/xineramaproto test? ( dev-cpp/gtest dev-cpp/gmock )" RDEPEND="${COMMONDEPEND} dev-python/pygtk x11-apps/mesa-progs x11-apps/xvinfo x11-themes/hicolor-icon-theme" # TODO: # - Remove automagic dependency for coverage report generation tools # - Fix Xig-0 automagic resolving('CMake Warning at tests/integration/xig/CMakeLists.txt:30 (message): Xig not found, you will not be able to run X Server integration tests') # - Check proper compilation with missing gettext/intltool # - CFLAGS are NOT respected, this needs to be fixed # - Default decorator exec command in ccsm is bad # - Check all dependencies once more # - Check CMakeFiles.txt this subdirectories : # cmake - ? # src # compizconfig # plugins # tests - ? pkg_pretend() { if [[ ${MERGE_TYPE} != binary ]]; then [[ $(gcc-major-version) -lt 4 ]] || \ ( [[ $(gcc-major-version) -eq 4 && $(gcc-minor-version) -lt 6 ]] ) \ && die "Sorry, but gcc 4.6 or higher is required." fi } #src_unpack() { #git-2_src_unpack #} #src_unpack() { #} src_prepare() { #epatch "${FILESDIR}/fix_access_violation.patch" echo "gtk/gnome/compiz-wm.desktop.in" >> "${S}/po/POTFILES.skip" echo "metadata/core.xml.in" >> "${S}/po/POTFILES.skip" # Fix wrong path for icons sed -i 's:DataDir = "@prefix@/share":DataDir = "/usr/share":' compizconfig/ccsm/ccm/Constants.py.in } pkg_setup() { python_set_active_version 2 } src_configure() { BUILD_DIR=${WORKDIR}/build local mycmakeargs=( "$(cmake-utils_use_use gnome GCONF)" "$(cmake-utils_use_use gnome GNOME)" "$(cmake-utils_use_use gnome GSETTINGS)" "$(cmake-utils_use_use gtk GTK)" "$(cmake-utils_use_use kde KDE4)" "$(cmake-utils_use test COMPIZ_BUILD_TESTING)" "-DCMAKE_INSTALL_PREFIX=/usr" "-DCMAKE_C_FLAGS=$(usex debug '-DDEBUG -ggdb' '')" "-DCMAKE_CXX_FLAGS=$(usex debug '-DDEBUG -ggdb' '')" "-DCOMPIZ_DEFAULT_PLUGINS=ccp" "-DCOMPIZ_DISABLE_SCHEMAS_INSTALL=ON" "-DCOMPIZ_PACKAGING_ENABLED=ON" "-HAVE_WNCK_WINDOW_HAS_NAME=1" "-Wno-dev=ON" ) cmake-utils_src_configure } src_install() { pushd "${CMAKE_BUILD_DIR}" # Fix paths to avoid sandbox access violation # 'emake DESTDIR=${D} install' does not work with compiz cmake files! for i in `find . -type f -name "cmake_install.cmake"`;do sed -e "s|/usr|${D}/usr|g" -i "${i}" || die "sed failed" done emake install popd } pkg_preinst() { use gnome && gnome2_gconf_savelist } pkg_postinst() { use gnome && gnome2_gconf_install if use dbus; then ewarn "The dbus plugin is known to crash compiz in this version. Disable" ewarn "it if you experience crashes when plugins are enabled/disabled." fi } pkg_prerm() { use gnome && gnome2_gconf_uninstall }

Hehehe. 15 seconds instead of 5 :P What would the neighbors think if they knew? Here in the ghetto we wouldn't worry about such, but I do comprehend the workaround (I think). Staubsauger is using: GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=376b974a-9cc7-4a48-9e6a-de19471107f2 usbhid.quirks=0x1B1C:0x1B12:0x20000000 quiet splash" The only part of that relevant to your issue is the usbhid.quirks statement. So in boot.conf you would add: params += usbhid.quirks=0x1A2C:0x0021:0x20000000 To any other parameters you have. Take a deep breath, buckle your seatbelt & give 'er a boot after doing boot-update! Hold on to your hat. I don't know about the 0x20000000 option, you'll have to dig into the kernel documentation on usbhid quirks, I see also some people use 0x04 (ignore) and others. Worst case scenario: it doesn't help, so you've got nothing to lose. I did find though that this fellow came up with what may be a more elegant solution for a similar situation: http://ubuntuforums.org/showthread.php?t=1161574&p=8512485#post8512485 Using udev rules instead. Just be sure to note that he posted that 6 years ago, the udev rule syntax has changed since, in particular using SYSFS, don't. You'll have to come up with that on your own, udev makes my head hurt.

I have no idea about the conflicts you may have due to running stable, but that ancient version of compiz...well, it just plain sucks. It's mostly python, slow, whereas the newer has been rewritten in C. And just lots of problems & bugs in general in the old one. You should be able I think to unmask the newer version and give a try at installing it. It doesn't require all that compiz-fusion, fusion-icon stuff, it's just one package, although I HIGHLY recommend using Emerald with it, if it doesn't pull it in automatically. Note that only emerald-0.9.5 should be used with the newer compiz, whatever you have to do to make sure of that. echo "=x11-wm/compiz-0.9.12 **">>/etc/portage/package.accept_keywords Ought to do it. xcfe integration, I don't have that info on the top of my head, but it should be easy, lots of info on the web no doubt.

Hi Sandro. I believe that's because each param must have it's own line. Like this: ... "Funtoo Linux genkernel" { kernel kernel[-v] initrd initramfs[-v] params += real_root=/dev/sda6 params += rootfstype=ext4

After Gnome went insane I spent a few months looking for my next desktop. I finally figured out that a "desktop" is simply a symphony of programs working in harmony to create a view for you. There are 4 core functions: window manager (creates ... windows), window decorator (adds quit, minimize, scroll bar, etc. to windows), desktop manager (makes pretty background, let's you put files on desktop), and most people prefer having a panel (clock, date, running programs, taskbar, etc.). All else is just "packaging." What do I care what audio player something like Gnome is "packaged with?" I'll just emerge the one I prefer anyhow, so it's all just bloat. Why not just go out and get what you think is the best of the 4 core programs and forget the bloat? My symphony is played by compiz, emerald, spacefm and lxpanel. I love it, wouldn't change a thing. It's very lightweight and adaptable. Although if I were coding all day long I could see the benefit of a tiling desktop, I'm not, so I just want functional, beautiful and above all, customizable. One final note: people who don't use compiz yet know all about it will tell you that it is resource hungry. Not true at all, just the opposite. The static memory footprint compares with openbox. Yeah, if you have all the effects turned on, when you do things like open and close a program, your cpu usage will spike for a millisecond or two doing those fancy video effects. My 24/7 world domination code can take the hit. And even you can turn off those effects completely, now you don't even have that hit. Forget the desktop concept, roll your own the way you like it.

The function keys can be a very hairy thing. It starts at the kernel, the x86 platform specific device drivers. Even if you have that right you can still have issues and may have to use something like acpi to make it all work. I'm sorry, it's been a few years since I messed with all that so I don't remember details, but they're out there. I also don't remember much about Awesome but I doubt it's the problem. Often window managers have a hotkey assignment settings screen, that may help. You can see if the kernel has the proper drivers with grep hotkey <system log name>. Here's what I get: Feb 20 11:40:57 [kernel] [ 27.268316] input: HP WMI hotkeys as /devices/virtual/input/input11 . Never used Thunar, I wonder if it could be a dependency problem, since it's what, from xfce? You might try spacefm, it's a much lighter weight, very functional file manager.

I wonder if perhaps you are having issues with usb power management? This doc tells in detail (!) how to change it, worth a try. I have had similar in the past due to pm. All "Energy Star" (or whatever green buzzword they are using today) devices are supposed to work with it, that's the concept, the reality is some don't. In a nutshell, you've got to find out where your device is in /sys/bus/usb/devices, one way would be to lsusb to get the bus and device number, go into /sys/bus/usb/devices/<bus><device>/power directory and try changing autosuspend from 1 to 0 (such as "echo 0 > autosuspend"). Incidentally, you can control that drive spindown in laptop-mode-tools, probably the usb autosuspend too, I forget. Gotta get your hands dirty in the config files though.

I have done exactly what peje suggests for over a year, works great here. If you can't trust other peers on your own local network, who can you trust? Each computer on the network keeps it's own set of distfiles and package files, as the architecture and usage varies. You can keep the distfiles on the server too, but it gets messy trying to keep things clean and not have huge growing out of control directories.

I had this issue on a machine a couple of days ago. I found a 2 year old post on the Gentoo forum stating that argparse is deprecated and was causing the issue then. I unmerged it and python-updater went fine, it never put argparse back, so I didn't either.

Try using USE="-sound" $ eix stellarium [I] sci-astronomy/stellarium Available versions: 0.12.4^t{tbz2} **0.13.1^t {debug nls sound stars LINGUAS="af ak am ar as ast az be bg bn bo br bs ca cs cy da de el en en_CA en_GB en_US eo es et eu fa fi fil fr ga gd gl gu he hi hr hu hy ia id is it ja ka kk kn ko ky la lb lo lt lv mk ml mn mr ms mt nan nb nl nn oc pa pl pt pt_BR ro ru se si sk sl sq sr sv sw ta te tg th tl tr tt uk uz vi zh zh_CN zh_HK zh_TW zu"} Installed versions: 0.12.4^t{tbz2}(07:12:41 AM 04/14/2014)(nls -debug -sound -stars LINGUAS="en_US -af -ak -am -ar -as -ast -az -be -bg -bn -bo -br -bs -ca -cs -cy -da -de -el -en -en_CA -en_GB -eo -es -et -eu -fa -fi -fil -fr -ga -gd -gl -gu -he -hi -hr -hu -hy -ia -id -is -it -ja -ka -kk -kn -ko -ky -la -lb -lo -lt -lv -mk -ml -mn -mr -ms -mt -nan -nb -nl -nn -oc -pa -pl -pt -pt_BR -ro -ru -se -si -sk -sl -sq -sr -sv -sw -ta -te -tg -th -tl -tr -tt -uk -uz -vi -zh -zh_CN -zh_HK -zh_TW -zu") Homepage: http://www.stellarium.org/ Description: 3D photo-realistic skies in real time

Oh yes, distcc IS my primary purpose in setting up the cross-compilers. I have two x86_64 machines, they do all the work, the ARMs, I use pump emerge with -j8 or 10. Making kernels is just icing on top. I actually have a dockstar and then got a pogoplug mobile a few months ago when they were blowing them out for $7/shipped. So it is the compile workhorse, the dockstar just emerges packages from it, essentially the same machine. Works well. I depend heavily on the dockstar, asterisk server, etc., so it's all a win-win, it's just coasting all the time. Only gcc is tough, seems like last time it took the pogoplug 23 hours, I can live with that LATEST UPDATE: 43 hours & still going (but near the end I think) :lol: I'll have to give the qemu chroot another try. Tried it once, it seemed slower on the x86_64 then it was on the ARM, and it's my daily user, didn't want it tied up. But now I have a spare x86_64, so...I don't know, nothing could be worse than this swap hell. Although, it's the only thing the pogoplug has to do, so I guess not a big deal. Most of gcc will not use distcc and I suspect it's locked to make -j1, that's where the problem lies. And I've never gotten the cross-compiler to make it. The cheat I mentioned above works, but I'd like to solve this and not depend upon that. But you won't have a problem with that 1G onboard ram, I've got free -s 30|tee <file> going, it's never used more than 500M swap on this emerge.