sputnik
-
Posts
122 -
Joined
-
Last visited
-
Days Won
9
Content Type
Profiles
Forums
Blogs
Posts posted by sputnik
-
-
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:
-
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
-
Hello!
Since over half an year, if not longer i been messing around with Funtoo on ARM.
I did notice weird things such as the now removed from portage qemu-user is really buggy at times and
having about the same performance at times as the System i tried building it for.
So currently i either can test/figure out how app-emulation/qemu works for static/chroot's
or just have my Netbook sit in a corner trying to compile everything. (800mhz i.MX515).
But neither seems to be a good option as documentation is scarce for qemu, such as the default setup using only one core and Portage end up being such a pain after 500 packages been emerged, dependency resolve seems to take up to 20 minutes at times.
Also anyone been building on a ODROID ? I'm considering getting one as build system.
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.
I tried it like described in http://www.funtoo.org/Localpatch (The old link does not exists anymore):
- emerged foobashrc
- made a symbolic link from etc/portage/bashrc to /etc/portage/foobashrc.bashrc
- created /etc/portage/localpatches, /etc/portage/localpatches/media-sound and /etc/portage/media-sound/oss-4.2-2008
- placed the file from newbie to /etc/portage/localpatches/media-sound/oss-4.2-2008/osscore.diff
- remerged oss
- executed /etc/init.d/oss start
with the same error message like before :( Did I made a mistake somehow through the steps?
-
-
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...
Keychain: why ssh, scp and others keep asking for the passphrase?
in Desktop Help
Posted