sputnik

I can only suggest things to check, I don't know the answer. I suggest changing to Mine works, I only use it for my github key: eval `/usr/bin/keychain --eval $HOME/.ssh/github-ssh-key` Also, more than once I have been bitten by file permissions. These work here: -rw-r--r-- 1 sputnik sputnik 2381 May 25 17:32 authorized_keys -rw-r--r-- 1 sputnik sputnik 1720 Aug 3 15:07 config -rw------- 1 sputnik sputnik 1679 Mar 7 2013 github-ssh-key -rw-r--r-- 1 sputnik sputnik 399 Mar 7 2013 github-ssh-key.pub -rw------- 1 sputnik sputnik 1679 Aug 21 2011 id_rsa -rw-r--r-- 1 sputnik sputnik 395 Aug 21 2011 id_rsa.pub -rw-r--r-- 1 sputnik sputnik 15278 Aug 3 20:06 known_hosts I am NEVER asked for passphrase. But when setting up new systems I often get that until I get the permissions right. Good luck

Sounds like your portage directory is broken. Not to worry, happens to everybody now & then, simply rename /usr/portage to something else and follow the instructions here: http://www.funtoo.org/Installing_Portage_From_Snapshot

Hello Sandro. I don't know if I can help, I did look. It's seems like something going on with gdbus-codegen and glib eh? And yet, I have this: [I] dev-util/gdbus-codegen Installed versions: 2.40.0-r1000{tbz2}(08:24:39 PM 06/11/2014)(PYTHON_ABIS="2.7 3.3 -2.6 -3.1 -3.2 -3.4 -3.5") [I] dev-libs/glib Installed versions: 2.40.0-r1(2){tbz2}(05:35:24 PM 06/17/2014)(mime static-libs -debug -fam -selinux -systemtap -test -utils -xattr ABI_MIPS="-n32 -n64 -o32" ABI_X86="32 -64 -x32" KERNEL="linux" PYTHON_TARGETS="python2_7 -python2_6") A good point by dantrell, but I believe Sandro has unstable. I do, and he has same versions of core programs. I wonder if you might fare better by including --exclude gdbus-codegen -- for some reason it's being forced to downgrade? And even more amazing, listed as a new emerge, yet obviously you have the 2.40xxx version. Might work, or might not, you can try it and see. Whenever you have a bunch of downgrades like that, even without blocks, it's a big clue something's not right. Sometimes you have to --unmerge it temporarily, pkgbuilds are handy for that. Often you can take the offender out of the mix, emerge the rest and magically everything is fine. Hope it goes that way for you, or others can give some better advice.

Sorry, I've been busy here, just catching up. I don't know why that's not working for you, unless epatch doesn't like patches with .diff suffix, I've never tried that, I always name mine .patch. I doubt it though. It's clear from your output that no patches are being applied. Eutils is referenced in that ebuild. Anyhow, if you are still trying, you can just modify the ebuild directly after copying it to your local portage directory. Just add a line with epatch_user above where it says elibtoolize. And have the patch available in /etc/portage/patches/media-sound/oss-4.2.2008. Be sure not to try and modify the ebuild in the normal /usr/portage directory or you will mess up the entire tree and have to delete it and download it again. If you've never done a local overlay here's an overview: http://wiki.gentoo.org/wiki/Overlay/Local_overlay You probably should also copy /usr/portage/media-sound/oss/files to your NEW /usr/local/portage/media-sound/oss directory or you can just make a link. Good luck

I've been using ARM embedded systems for a few years now. I switched my ARM system to Funtoo close to a year ago and have been very happy with it. Hah! You get the same performance from qemu-user as the target system? Lucky. I find it to be nearly worthless it is so slow. I have the best luck running distcc in pump mode. Neddy Seagoon over at Gentoo swears by it, so I gave it a try and I agree, works great. 20% of the time or so it will fail, but it just falls back into non-pump mode, so no real downside. It's "not recommended", but it works for Neddy & me too. I think we all drool over the Odroid's. I believe Jean, the Funtoo ARM dev has one. Another option, you don't say which platform you are using, I see the old pogoplugs and dockstars going for $10-15 on ebay. Pogoplug4 averages about $7 NEW (although it's pretty wimpy). If you have something like that, one of those could be compiling in the background, while your main machine is actually doing work. I'm thinking of doing that. Finally, it won't help your compile issues, but I have an ebuild for cryptodev, which unleashes the hardware encryption on many of these devices. If you do torrents, vpn, anything that uses crypto it may lower your load: https://github.com/yuyuyak/cryptodev-funtoo-gentoo-ebuild

Works great here too :) Judge got me going on this, I like it. But when I try it with Bugs JIRA it comes back with - 401 Authorization required. Am I doing something wrong or is it only for some? I was logged in at the time. Sorry for the hijacking...

Oh, and I should have added, you will see immediately as the emerge progresses, whether the patch method is working or not. Watch the output, soon after the emerge begins you will see any patches applied, if there are any "official" patches they will go first, and then you will see your patch get applied, all before the compiling begins. If you don't see your patch listed you can control-c out early and try and diagnose what's up without wasting time waiting for a compile that's just going to give the same results.

There is no "right" way, whatever seems right to you is the right way. Tidiness? If you figure out a way, we'd all like to know :D But yeah, it's a little easier that way.

It seems to me you have the right idea. I really have no experience with foobashrc. Perhaps just try my bashrc example and see if it works for you? And the following applies if you try this: Item 2: There's no need to make that symbolic link, emerge will see /etc/portage/bashrc on EVERY emerge. Done. Items 3&4: Use /etc/portage/patches, instead of localpatches. Finally, there is no need for anything to be added to make.conf with this method. Good luck.

http://bugs.funtoo.org/browse/FL-1278

Common internet forum venacular. OP=original poster

Since I don't quite comprehend the original question by the OP I don't know if this helps him. But I have discovered that laptop-mode tools has had a major change that deprecates the usb-autosuspend module. So my statements in /etc/laptop-mode/conf.d/usb-autosuspend.conf no longer had any effect whatsoever. There is a new runtime-pm.conf in the same directory that is in control instead. By blacklisting my mouse in there now all works as before. #/etc/laptop-mode/conf.d/runtime-pm.conf AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST="046d:c016"

It would appear that this is not a widespread problem, but in case others have it I'll post what I found. No clue as to what made this suddenly appear in my peaceful little world. Ruled out laptop-mode tools right away, which brought me to the kernel autosuspend stuff in /sys/bus/usb/devices/<your device>/power. Echo -1 > /sys/bus/usb/devices/<your device>/power/autosuspend turns off the autosuspend completely, although I'd prefer to simply make it wake up properly, will work on that. Paul Bradbury over at gentoo forums posted a handy script to tell you your device name: for d in /sys/bus/usb/devices/[0-9]* ; do if [[ -e $d/product ]] ; then echo -e "`basename $d`\t`cat $d/power/control`\t`cat $d/speed`\t`cat $d/product`" ; fi ; done

Hmm, not sure what OP is saying, but am suspicious, I have a minor usb mouse problem I have attributed to xorg-server >1.15.0. Last night I emerged these and the the problem noted at http://bugs.funtoo.org/browse/FL-1300?focusedCommentId=17124&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17124 began: x11-base/xorg-server-1.15.0 x11-drivers/xf86-video-fbdev-0.4.4 x11-libs/glamor-0.6.0-r1 x11-drivers/xf86-input-evdev-2.8.4 x11-drivers/xf86-input-synaptics-1.7.6 x11-drivers/xf86-video-intel-2.99.911-r1 app-portage/elogviewer-2.1-r1 gnome-base/librsvg-2.40.2 media-libs/libsdl-1.2.15-r6 media-sound/mpg123-1.20.1 app-text/poppler-0.26.2 x11-drivers/xf86-video-intel-2.99.912-r1

Patches are not automatically applied that way unless you make a custom bashrc file in /etc/portage that implements installing patches. Here's mine (edited to show only that function): post_src_prepare() { if type epatch_user &> /dev/null ; then cd ${S} epatch_user fi } There are other ways as well, this way is perhaps the easiest. This only works if hmm, is it eutils? is in the ebuild, most seem to have that. More info here: http://www.funtoo.org/Localpatch_%28Tutorial%29

It would seem your issue is kernel related, you may want to try a different kernel. Although, the Debian kernel is built to be "one size fits all", but then again, so is the systemrescuecd standard kernel and yet, you had to use the alternate. The usb drivers are part of the kernel, either built-in or modules.

I joined back up when the new forum was created as my previous user. The computer I was using has since...died. Fortunately I had logged in with my backup computer and have been getting around on the forum, JIRA, etc. just fine. However, the new JIRA, like the old one, logs you out every couple of weeks or so and now it wants me to sign in. I've been more cautious about passwords lately, who knows what I used? My old standbys don't work. I've searched through my registered email, find no reference. Although I'm still auto signed in here, when I go to account settings and try to change password it takes me to new account settings 9093, and of course tells me that sputnik is already taken. How can I fix this?

It seems the answer is today I got an update (and of course, had to update package.license as well) for googletalk plugin, it's now at 5.4.2.0. So possibly in the transition the old version wasn't available, I recommend trying today. Your accept license = "*" should be good for everything. Also, ahem, it could be handy to use a U.S. proxy address.

Do you have: =www-plugins/google-talkplugin-5.4.1.0 Google-TOS in /etc/portage/package.license?

I have those flags, but as drobbins says, I believe they are only a gentoo thing, not needed here and I should remove them. But zero issues because of them. I think it's likely you need to do python-updater, painless and at the very least you'll rule out any problem there.

I wonder if perhaps your kernel is not set up to read the particular drive you are using? I had a similar experience recently setting up a friend's computer, don't remember all the details but it was something like what you are getting and that was the issue. Using something like systemrescuecd of course, it's set up generically to work with anything. Best guess...