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

844 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 dropped that dependency, so I'll try fixing it that way or just do without until a better fix comes along. If you absolutely, positively must have pangox-compat you can make it work (with a fair amount of work). I did this before discovering all the above. Not for the faint of heart, but here's the details. Mask the pango-1.44.7 package: /etc/portage/package.mask =x11-libs/pango-1.44.7 Then grab the pango-1.42.4-r2 ebuild: https://raw.githubusercontent.com/gentoo/gentoo/master/x11-libs/pango/pango-1.42.4-r2.ebuild and put it in your local repo. Then copy the following folders from meta-repo to your local repo: app-text/gtkspell dev-cpp/pangomm dev-python/pygtk gnome-base/libgnomecanvas gnome-base/libgnomeui gnome-base/librsvg x11-libs/gtk+ x11-libs/vte Then change the dependency on x11-libs/pango in the following files in your local repo to >x11-libs/pango-1.41.0: gtkspell-3.0.10.ebuild pangomm-2.42.0-r1.ebuild pygtk-2.24.0-r7.ebuild libgnomecanvas-2.30.3-r1.ebuild libgnomeui-2.24.5-r2.ebuild librsvg-2.46.3-r1.ebuild gtk+-2.24.32-r1.ebuild gtk+-3.24.12.ebuild vte-0.58.2-r1.ebuild emerge -C gtkspell pangomm pygtk libgnomecanvas libgnomeui librsvg gtk+ vte emerge -av pango emerge -av gtkspell pangomm pygtk libgnomecanvas libgnomeui librsvg gtk+ vte You may not have all of the above packages, or you may have additional packages depending on pango-1.44.7, you'll have to play that by ear. Almost anything else would be better, but if you must have it, that will work. Edit: celestia-9999 worked!
  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 --rbind /dev dev mount --bind /dev/pts dev/pts mount tmpfs -t tmpfs -o rw,nosuid,nodev,noexec dev/shm mount --bind /tmp tmp cp /etc/resolv.conf etc echo "" echo "don't use pump" echo 'env -i HOME=/root TERM=$TERM DISTCC_HOSTS="star,cpp,lzo joshua,cpp.lzo mrpink,cpp,lzo micah,cpp,lzo localhost" MAKEOPTS="-j8" chroot . /bin/bash -l' # UMOUNTDIRS - script name umount proc umount -l sys umount -l dev/pts umount -l tmp umount dev/shm umount -l dev umount tmp That's it! The 1st script echoes some reminders to me and the exact line to chroot in, I just copy & paste it (the script can't run that line directly). This is a particularly good example because I also set some environment variables on the way in, shows that. Of course you must set up your makefile as drobbins states, in my case: QEMU_SOFTMMU_TARGETS="i386 arm" QEMU_USER_TARGETS="i386 arm" And install qemu. Finally, you must run /etc/init.d/binfmt either in rc-update (bootup) or add starting/stopping it to the scripts. I find it mainly handy for things that overwhelm the whopping 1G ram on the odroid, it'll work but it's s...l...o...w. If at all possible it's much faster to use the cross-compile SYSROOT method, search on the web for "gentoo cross-compile", you'll find it. Unfortunately it doesn't work with many packages, particularly the intensive ones you'd like to use it on. One notable exception is LLVM. The odroid can't build it anymore as of a couple of years ago, but I found a trick to build it natively on the powerful machine and output a 32 bit arm package in minutes. Last time I used the qemu chroot method it was > 10 hours on a core2. Here are my notes: ****WARNING!!! DO NOT DO THIS, THERE IS A PROBLEM, READ BELOW**** # LLVM trick notes: # 1. you must have same version already installed on the compile machine # 2. in $SYSROOT/etc/portage/profile/use.mask, put a file that has this in it: abi_x86_64 llvm_targets_X86 # 3. you must have libffi installed: armv7a-hardfloat-linux-gnueabi-emerge libffi type: ABI_X86="" LLVM_TARGETS="BPF ARM" armv7a-hardfloat-linux-gnueabi-emerge -BO llvm:<version> probably just this now: LLVM_TARGETS="BPF ARM" armv7a-hardfloat-linux-gnueabi-emerge -BO llvm:<version> #5. Check out the package.env stuff for llvm, see llvm.conf ENJOY! # ${SYSROOT}/etc/portage/package.env sys-devel/llvm notmpfs.conf nodistccccache.conf llvm.conf # ${SYSROOT}/etc/portage/env/llvm.conf ABI_X86="" CMAKE_EXTRA_CACHE_FILE=/usr/armv7a-hardfloat-linux-gnueabi/etc/portage/env/cmake_cache_files/llvm.cmake # ${SYSROOT}/etc/portage/env/cmake_cache_files/llvm.cmake SET (CMAKE_INSTALL_LIBDIR "lib" CACHE STRING "" FORCE) SET (LIB_SUFFIX="" CACHE STRING "" FORCE) SET (LLVM_TARGETS_TO_BUILD "ARM;BPF" CACHE STRING "" FORCE) SET (LLVM_LIBDIR_SUFFIX "" CACHE STRING "" FORCE) SET (FFI_LIBRARY_DIR "/usr/armv7a-hardfloat-linux-gnueabi/usr/lib" CACHE STRING "" FORCE) SET (FFI_INCLUDE_DIR "/usr/armv7a-hardfloat-linux-gnueabi/usr/lib/libffi-3.2.1/include" CACHE STRING "" FORCE) THE PROBLEM: This indeed makes the package in arm-32 bit format, but later I found it is linked to lib64, non-existent on the arm. In my case, the odroid does just fine with it for my uses and I'm sure that can be remedied with CMAKE_OPTIONS, but since I have no problem I haven't worked on it. I skipped Funtoo 1.3 on the odroid, when 1.4 is released I'll update to that and get to the bottom of a solution on it. It makes a package which you can then install natively on the arm with emerge -K. Hmm, it's been so long, maybe I did fix that lib problem, maybe that's why it JUST WORKS®. I dunno...try it at your risk... I used to build my arm kernels with the SYSROOT method, but nowadays I find that pump distcc on the native device is just as fast and easier. Here's the basic script for doing such a thing, minus the dracut and mkimage operations: export SYSROOT=/usr/armv7a-hardfloat-linux-gnueabi armv7a-hardfloat-linux-gnueabi-emerge odroidc1-sources #custom amlogic kernel # cd usr/src/linux # ${SYSROOT}/usr/bin/xkmake menuconfig # cd ${SYSROOT} KERNEL_VERSION=-$(readlink ${SYSROOT}/usr/src/linux|cut -d'-' --complement -s -f1) cd ${SYSROOT}/usr/src/linux ${SYSROOT}/usr/bin/xkmake -j3 ${SYSROOT}/usr/bin/xkmake -j3 modules ${SYSROOT}/usr/bin/xkmake -j3 INSTALL_MOD_PATH="/mnt/nfs/odroid" modules install ${SYSROOT}/usr/bin/xkmake -j3 uImage cp ${SYSROOT}/usr/src/linux/arch/arm/boot/uImage /mnt/nfs/odroid/mnt/sdcard/storage/uImage.funtoo cp ${SYSROOT}/usr/src/linux/arch/arm/boot/dts/meson8b_odroidc.dtb /mnt/nfs/odroid/mnt/sdcard/storage/meson8b_odroidc.funtoo.dtb Just a rough guide there to show what can be done. The gentoo cross-compile info tells you to use xkmake rather than make when using the cross-compile ${SYSROOT} method. Here's my ${SYSROOT}/usr/bin xkmake file for the odroid: #!/bin/bash make ARCH="armv7a" CROSS_COMPILE="armv7a-hardfloat-linux-gnueabi-" INSTALL_MOD_PATH="${SYSROOT}" $* My 2 cents worth...
  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 or 10 minutes to set up your local overlay, drop the gcc build you want in there, then: crossdev <OPTIONS> --init-target Then change the gcc link in the crossdev overlay as shown in my 1st link. Pretty quick and painless. Then: crossdev <OPTIONS> again. Come back in a couple of hours. If you run this cool bash script on your $TARGET machine, it will even create the crossdev line for you: #! /bin/bash A="binutils" ; B=`eselect $A show` ; BINUTILS_VER=`echo $B | cut -d- -f5-` A=`/usr/bin/gcc-config -c` ; B=`echo $A | cut -d- -f5` ; GCC_VER=`equery l sys-devel/gcc | grep $B | cut -d- -f3-` A="sys-kernel/linux-headers" ; B=`equery l $A` ; KERNEL_VER=`echo $B | cut -d- -f4-` A="sys-libs/glibc" ; B=`equery l $A` ; LIBC_VER=`echo $B | cut -d- -f3-` echo "crossdev --b =$BINUTILS_VER --g =$GCC_VER --k =$KERNEL_VER --l =$LIBC_VER -t $(portageq envvar CHOST)" Source: https://wiki.gentoo.org/wiki/Distcc/Cross-Compiling Here is crossdev-20151026-r1.
  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 _rc1 part of the name, allowing them to supersede the official ebuilds. This will cause you to have to rebuild the native gcc because I have additional use flags for arm support (in a crossdev gcc implementation) that don't exist on the official tree ebuild. Alternately you can just leave the _rc1 in the name and just call it directly on the crossdev command line, I found it too confusing to have all those versions floating around when it works just fine as a replacement. Your choice... In addition to the informational links above, I must tell you that I have had no success with any crossdev version beyond 20151026-r1, due to growing portage differences between gentoo and funtoo. Hmm, probably something from around that time here will do: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/crossdev/ I would be leery about using --stable also, I prefer to specifically call out the versions I want to match exactly the device I am building for, rather than counting on crossdev to make the right decisions for me. It didn't work well for me in the past, although I haven't tried it in a long time. When you successfully create your shiny new toolchain there is very pertinent info here also: https://wiki.gentoo.org/wiki/Distcc/Cross-Compiling
  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 trying to catch every error that needs human intervention, early on I realized 1. That would be impossible. 2. After taking care of the obvious things it's rare that it doesn't work, when that happens the human intervenes, things will work the next night :P I was going to convert it to python but 1. I'm lame at python. 2. I fear the inevitable minor changes 3. It doesn't have to be fast or cool It does everything including updating eix on all computers, doing emerge @preserved-rebuild when needed, the only thing I left for the human was emerge --depclean and revdep-rebuild, I do that 1st thing in the morning so the "human" can see what's up. Logs are kept, there are no mysteries. It is set as a cron job after my normal bedtime but I can run it directly and override the cron job, which I almost always do. Turns computers on for the update/backup, turns them off when done, makes kernels (I have to update the config 1st of course), lots of stuff. About 3 years now, never any great problem, of course, growing pains the 1st 1.5 years.
  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 still have an error in the filesystem? Don't know the answer but I suspect you could. Have you tried reformatting? Of course, he will lose all of his ancient data :)
  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 just want it for a backup, I don't plan to use it much. Just dumping the Debian libraries into the rootfs caused conflicts with depclean, portage doesn't like to find strange stuff lying around. Here's what worked: Using file-roller it was easy to unpack the .deb. The only directory you care about is, I forget, data? or data something. In there you'll probably find /usr and /lib, something like that. So I created a /opt/chromium-browser dir and put the /usr and /lib dirs there. I had to edit the /opt/chromium-browser/usr/chromium-browser launch file, in there it gave a place to point it to libraries, pointed that to the /opt/chromium-browser/libs. Then I started it at the command line, it failed looking for libraries that we have in Funtoo but it didn't know where they were. It was only 2 or 3, so I made links to those files in the /opt/chromium-browser/lib dir and it worked! No issues at all and portage hums along quite happily, not even knowing it's there. It really wasn't possible in my case but it would be better to make a custom ebuild if you can and install it properly. But the /opt dir is the place to do dirty tricks like this if need be.
  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 appropriate place for the statement, as it is suggested that all local environment changes are added to that file, so you can keep track of what YOU have added, also negating the risk of overwrite with an update, and this _should be a temporary workaround. Oh, that's Mike JOHNSON, not that I care, it's just the worldly name someone assigned to me, has nothing to do with me. https://en.wikipedia.org/wiki/Ray_J._Johnson,_Jr. Saluga's shtick as Ray J. Johnson is to become annoyed when addressed as "Mr. Johnson", exclaiming in a loud voice, "My name is Raymond J. Johnson, Jr. Now you can call me Ray, or you can call me J, or you can call me Johnny, or you can call me Sonny, or you can call me Junie, or you can call me Junior; now you can call me Ray J, or you can call me RJ, or you can call me RJJ, or you can call me RJJ Jr." ultimately ending with, "but you doesn't hasta call me Johnson!"
  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 a forum, it wasn't really given in usable patch form, but it was clear enough for me to make this patch: # cat /etc/portage/patches/x11-drivers/nvidia-drivers-340.93-r1/kernel-4.3.0.patch --- a/kernel/nv-procfs.c 2015-08-19 16:00:07.000000000 -0700 +++ b/kernel/nv-procfs2.c 2015-11-05 17:07:24.395722706 -0800 @@ -356,7 +356,8 @@ registry_keys = ((nvl != NULL) ? nvl->registry_keys : nv_registry_keys); - return seq_printf(s, "Binary: \"%s\"\n", registry_keys); + seq_printf(s, "Binary: \"%s\"\n", registry_keys); + return 0; } static ssize_t @@ -552,7 +553,8 @@ void *v ) { - return seq_puts(s, s->private); + seq_puts(s, s->private); + return 0; } NV_DEFINE_PROCFS_SINGLE_FILE(text_file); He was really talking about the 352.xx drivers, but it turned out to be so for the 340.xx series also. If you use those patches and recompile your kernel it will install. Several days now, no problems here. Good luck.
  • Create New...