Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


sputnik last won the day on January 5 2019

sputnik had the most liked content!

About sputnik

  • Rank
    Advanced Member

Recent Profile Visitors

896 profile views
  1. Gentoo had an issue with this also. Their solution was to freeze x11-libs/pango at 1.42.xx. pango 1.44 was prompted by a security issue in 1.42.xx, but the fixes have been backported to 1.42.xx. It's doubtful that a patch is forthcoming for pangox-compat because it is deprecated, indeed no fix is currently available, rather the packages that depend upon it hopefully will drop that dependency. In my case the only package was celestia, which depends upon it indirectly due to a dependency on gtkglext which in turn depends upon pangox-compat. Looking deeper I see that celestia-9999 has droppe
  2. Not a criticism or to belittle Drobbins hard work, but I have been doing this for years with a simple bash script. If you haven't seen his video on fchroot on the forum here and don't know what it does search for fchroot. I simply keep 2 bash scripts in ROOT directory of any device I want to use it with, navigate to that directory (mounted via NFS) from the BIG BOY computer and run 1st one script to enter the QEMU chroot, the other to cleanup when exiting. Here's an example from my odroid C1+, armv7a: #MOUNTDIRS - script name mount -t proc none proc mount --rbind /sys sys mount --r
  3. sputnik

    Distcc makeopts

    See the readme here: https://github.com/TemptorSent/overlay-dev-gcc-kit/tree/master/sys-devel/gcc
  4. sputnik

    Distcc makeopts

    I want a 65 core cpu too! I've been using distcc on Funtoo for years and yes, both of those lines are required for distcc. Unless you want the jobs to default to the number of cores on the local cpu, and don't care about the load. Finally distcc & pump mode are not default features.
  5. The version of crossdev is of no consequence as long as it works, it's just a shell script. While qemu has value, it's _much too slow for general use. The docker idea sounds good, except it might be a hassle if you are using it for distcc, I don't know, never do docker. Setting up a local overlay is quite simple and almost surely you are going to do it sooner or later anyhow. I believe crossdev itself requires it, I don't know what it would use for an overlay (and it does need an overlay) without it.. The "custom ebuilds" are already done so I don't see an issue there. 5
  6. I've been using crossdev for various devices on Funtoo very successfully for years now. There are differences from gentoo, only general gentoo instructions apply. 1st, a must read is this: https://www.funtoo.org/Cross-compiling_with_Crossdev. Then you will understand that the Funtoo gcc ebuilds do not work out of the box with crossdev at all. I have created ebuilds that seamlessly replace the official tree gcc ebuilds and at the same time also work with crossdev, see this: https://bugs.funtoo.org/browse/FL-3787 . I recommend using these ebuilds in your local PORTDIR, removing the _rc
  7. Ref: http://forums.funtoo.org/topic/832-revdep-rebuild-issue/ I'm happy to report that I removed the workaround mentioned in that thread in /etc/env.d/99local, did env-update and source /etc/profile and at least on my ARMv7a device, revdep-rebuild no longer complains about missing libraries.
  8. I do exactly that with a bash script, but it is QUITE complex for many assorted reasons. I have several computers updated by the one script. Issues are: I don't allow root ssh access, so workarounds for that. I also backup all computers nightly with it. 1 computer is the ringleader, it's on 24/7. Different computers have different needs. On and on... But not to discourage you, I love it. It took about 1.5 years to get it more or less right, it's the biggest mess of spaghetti you can imagine and even minor changes have great potential to upset the apple cart. Oh, and I don't bother try
  9. I have an ancient laptop with a HD of that size, mini IDE I believe it was called. And I have another 32?G mini IDE drive. The 32G recently died, it was used approx. a couple of hours per day. The laptop with the 40G is still ticking, but recently had a severe disk hit and I had to reformat it, luckily I back up everything so it was easy to fix. That machine is rarely turned on. End of life? perhaps... Anyhow, if it's ext type filesystem fsck works fine of course. fsck.vfat for fat32, ntfsfix for ntfs. I never use badblocks but I wonder if you could have all blocks intact and yet stil
  10. Glad to hear you got it going. One good trick for forcing python version without changing the setting in eselect is to make a link like this: mkdir /opt/python2_link ln -s /usr/bin/python2.7 /opt/python2_link/python2.7 Then at the beginning of run.sh add this line: export PATH=/opt/python2_link:$PATH Now it'll find python 2.7 FIRST, but the rest of your system will be running on 3.3 as it should.
  11. ok, I actually went and looked at it, the readme says I'm not so great on java, so hopefully someone who is will speak up, but I think if you do what it says you'll be good. After that (I think!) you just start it by running that run.sh file as root. Also Koush is one of the giants of the android developer world, I'm sure he could help you if you asked him.
  12. I know nothing of ClockworkMod Tether, but I was faced with a similar thing on my armv7a device recently. In that case it was chromium, there is a Debian compile of 45 series chromium for armv7a's, I don't find anybody with anything more current than that. I spent weeks trying myself ;) Although I suspect I could compile the 45 series from an old ebuild, I also saw stories of 11 hours just in the linking phase, Add to that 6 hours (thanks to distcc and two core duo machines) it took to compile the 47-48 series chromium (successfully here!, but failed linking, only 1G ram available). I jus
  13. Yes, as you can see I started to refer to that bug, but hesitated because I wasn't sure it was the same thing and didn't want to give misleading info. Thought I'd wait and see what others had found. I am at a loss as to how it is impossible to reproduce this bug, it's been there a long time, one x86 machine, two armvte5 machines, one of them with a fresh, clean newly installed rootfs, and a couple of months ago I got an armv7a machine, again, fresh, clean install, problem right out of the box. Thankfully the workaround solves it without harm it seems. I believe /etc/env.d/99local is a more
  14. Supposedly the GPL restrictions on the nvidia drivers problem is solved, but I find it not to be so on the 340.xx series, has been an issue since 4.2.0. So I have to patch the kernel with this: # cat /usr/src/fix_gpl #!/bin/bash sed -i 's/EXPORT_SYMBOL_GPL(flush_workqueue/EXPORT_SYMBOL(flush_workqueue/' linux/kernel/workqueue.c So that solves the GPL problem. I just leave that snippet in my /usr/src directory and run it before compiling each kernel. Additionally another patch is needed for the driver itself. I can't give a reference for this patch, I found a fellow talking about it on
  • Create New...