Jump to content

sputnik

Members
  • Content Count

    122
  • Joined

  • Last visited

  • Days Won

    9

Reputation Activity

  1. Great Post
    sputnik got a reaction from Tassie_Tux in alternative to fchroot   
    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...
  2. Great Post
    sputnik got a reaction from More_Piffle in Raspberry 3 64bit Crossdev?   
    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.
  3. Great Post
    sputnik got a reaction from More_Piffle in Raspberry 3 64bit Crossdev?   
    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
  4. Trolling
    sputnik got a reaction from pr1vacy in Latest update blows up my system   
    re-emerge pango, it hit everybody.  Your desktop will be back.
  5. Trolling
    sputnik got a reaction from freakshaman in Pango causing most of programs with gui fail to start   
    same here, it seems portage just installed it too early in that latest big batch, no need to downgrade, just reinstall?  At least here.
  6. Trolling
    sputnik got a reaction from Tassie_Tux in What was the reason for not switching to systemd ?   
    I also tried to live with systemd.  I was using archlinuxarm on my embedded device, they had no choice but to follow suit with Big Daddy arch when they switched (hmm, common, eh?).
    Generic run-of-the-mill daemon starting is easy enough, just like rc.  For me, the problem was the "in between the cracks" stuff.  Oh, Lennart Poettering is quick (and vocal) to point out the MOUNTAINS of documentation about his baby.  Also to finger people who don't care for it for whatever reason "Haters".  I'm all for spending time learning about something new if it has benefit to me, but this didn't.  And mountains of documentation, all well and fine, but wading through that to do something I could do in seconds in rc didn't seem like the direction I wanted to go in learning.
    Specifically, I had an issue using dtach.  On a limited memory device, dtach is much better than screen if you run it 24/7, since it is MUCH smaller.  It involved sockets.  At the time there was very little to go on, although I have seen a lot more now.  I spent a couple of days trying to work it out, finally decided to switch to Funtoo as I was quite familiar with it running on my "real" computers.
    By default it also ran the systemd log, journald.  On my embedded device there is a total of 128M ram, it sucked up 70M or so.  Even when I figured out how to defeat that, there was still some memory footprint of it, I never got the full 70M back.
    It keeps growing and growing in scope, 1st you don't need a system log anymore, journald replaces it (poorly IMO).  Then cron, it has it's own implimentation, login?  Nope, only systemd login needed now.  What's next?  This isn't the GNU/linux way to me.
    Finally, there are a lot of political implications, I won't go into that here, it's easy enough to find.  I do find it quite interesting that the U.S. military is Red Hat's biggest customer.
    I'm no expert on systemd, it sounds like you've put some effort into learning about it, this is just my personal experience with trying to use it for 8-9 months.
    Hah, here's a quote on wikipedia/systemd (http://en.wikipedia.org/wiki/Systemd):
    In an August 2014 article published in InfoWorld, Paul Venezia writes about the systemd controversy, and attributes the controversy to violation of the Unix philosophy, and to "enormous egos who firmly believe they can do no wrong."[39] The article also characterizes the architecture of systemd as more similar to that of Microsoft Windows software:[39]   While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux ? which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system ? from authentication to mounting shares to network configuration to syslog to cron. I take issue with the "succeeded in its original goals" statement. Haters Central: http://boycottsystemd.org/
  7. Trolling
    sputnik got a reaction from duncan.britton in Offline updates - is it possible?   
    There was a similar question in Gentoo a while back, the fellow was going to be on board a ship with no network for 6 months.  I can't find it now, but not important, j-g- has good ideas.  Especially if you have a similar computer at home <whereever> that is on the network, you can just hand carry the flash drive back & forth with the package files.  I have a machine here with all of portage on flash drive, an ancient computer with a tiny HD.  Portage doesn't care where it's DIR's are.  But if you have to chroot and use qemu then: Door #2, yes it will be a pain because it will take so long to build packages in qemu emulation mode.  If that were the case I would update portage to reflect the latest packages and take the DISTFILES to the remote machine, let it find them in $DISTFILES and build them itself.  Assuming your _home machine had the same packages installed, else you'd have to manually d/l them.  It certainly won't be painless, but you can minimize the pain.
  8. Trolling
    sputnik got a reaction from Tassie_Tux in ARM Builds, Native hardware and qemu   
    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
  9. Trolling
    sputnik got a reaction from Sandro in About services.   
    The only thing that grabs me is you don't want NetworkManager and dhcpcd both.  If you're using NetworkManager delete dhcpcd from rc.  Otherwise more or less what I have, don't know about the busybox stuff, did you add that?  I don't have it.  Here's mine:
    # rc-update NetworkManager | default acpid | default alsasound | boot autofs | default bluetooth | default bootmisc | boot chronyd | default consolekit | default cups-browsed | default cupsd | default dbus | default devfs | sysinit device-mapper | boot distccd | default dmesg | sysinit fcron | default fsck | boot fuse | default gpm | default hddtemp | default hdparm | default hostname | boot hwclock | boot ip6tables | default ipset | default iptables | default keymaps | boot killprocs | shutdown kmod-static-nodes | sysinit lm_sensors | default local | default localmount | boot lvm | boot metalog | default microcode_ctl | boot modules | boot mount-ro | shutdown mtab | boot netif.lo | sysinit netmount | default nfs | default nfsmount | default openvpn.client | default postfix | default preload | default procfs | boot qemu-binfmt | default root | boot samba | default savecache | shutdown sshd | default swap | boot swapfiles | boot sysctl | boot sysfs | sysinit termencoding | boot tmpfiles.dev | sysinit tmpfiles.setup | boot udev | sysinit udev-mount | sysinit udev-postmount | boot default urandom | boot xdm | default
  10. Trolling
    sputnik got a reaction from swamprabbit in Minimizing compile time   
    I have a Toshiba TE2000, it's a P4, 15 years old and keeps on ticking, even the CDROM!  I don't think you'll find this is much of an issue once you get over the initial install, it's not that horribly slow.
    I believe LXDE is a good choice, mine is openbox with  lxpanel, etc., I think LXDE IS openbox if I remember correctly.
    The biggest help you can give it is to use ccache and DISTCC - if you have other machines to help.  ccache irregardless of other machines.  Lots of info about those at the wikis and forums.
    swamprabbit's suggestion is excellent too.  There is also the tinderbox, the developer says it's not maintained anymore, but it seems to have recent activity: http://tinderbox.dev.gentoo.org/.  Binary compiles of many packages.  I've never used tinderbox, but I do use the binary browsers, they are a very time consuming compile.
    Also if you can spare a few bucks, mine was 1GB ram, I got 2GB on ebay for something like $12-13, new even.  That helped it alot.
    It's likely you have a tiny HD, if need be it's easy to put /usr/portage on a usb stick.  Or if you do have other machines you can just link to /usr/portage through NFS or samba, that's what I do here.
    Oh, 1 more thing you can do if you increase memory size.  You can run /var/tmp/portage as a ramdisk, should be much faster than storing intermediary compiled programs on disk, reading them back, etc. (although I must confess lately I'm not so sure).  To do this you make an entry like this in /etc/fstab:
    tmpfs /var/tmp/portage tmpfs size=2G 0 0 Don't worry about the 2G, it's smart and only uses what's available for the ramdisk.
    However, a handful of packages cannot fit into such a small size and you will have to make exceptions for them thusly:
    cat /etc/portage/package.env app-office/libreoffice notmpfs.conf app-text/poppler notmpfs.conf cat /etc/portage/env/notmpfs.conf PORTAGE_TMPDIR="/var/tmp/notmpfs" Then portage will use a "real" temporary directory for those packages.  These are examples only, for example, you would almost surely want libreoffice-bin, the compiled version is the king of long compile times.  You'll find out what needs to be added to package.env when it says "out of disk space" when it fails ;)
  11. Trolling
    sputnik got a reaction from duncan.britton in Change colors in gtk+ theme based on wallpaper   
    Life is too short for ugly desktops!
    I'm with you Duncan, and I really love that cityscape you have in the desktops thread.
    1st, I don't know of that which you ask.  Although I'm sure there is an easy way to find the predominant color in your picture in Gimp or something I don't know that either.  But it seems to me you can probably come close with just your eyeballs.
    I imagine you have looked over Gnome Look and those sorts of collections for themes.
    I use Emerald rather than GTK and it has the Emerald Theme Manager that allows you to set the colors, for one thing (many other options too).  Although it appears to me that Emerald is a (now) forgotten step-child of GTK I'm not aware of any such thing for GTK.  So I just find an Emerald theme at Gnome Look that's close enough then modify it.
    Your question peaked my interest and I did find something that may be interesting though:
    http://gnomecc.sourceforge.net/
    Sounds like it may do what you want, sans the color picker.  Much like the Emerald Theme Manager.
    I hope someone else can chime in with some better ideas.
     
    Edit: This will find your predominant color
  12. Trolling
    sputnik got a reaction from b1t in Need Help with NetworkManager/WPA_Supplicant   
    You don't have wpa_supplicant in rc do you?  Only NetworkManager should be there, no dhcpcd either.  My best guess.
  13. Trolling
    sputnik got a reaction from gnuisance in NetworkManager inactive after hibernation   
    Oh, thank you too.  I'll do that too.  I love it when I don't have to think.
  14. Trolling
    sputnik got a reaction from gnuisance in NetworkManager inactive after hibernation   
    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.
  15. Trolling
    sputnik got a reaction from uudruid74 in Sharing /home in a dual Linux scenario   
    I've done what you are trying to do before, but I switched to a different method.  The issue is you have your .config and .gnome, etc. type of config files and the OS'es can get things mixed up.  Better I think to use links for those folders you think you might want to share, then the config folders will be unique to each, sidestepping that problem.
  16. Trolling
    sputnik got a reaction from Tassie_Tux in Cannot eselect java-nsplugin to a later slot/version (dev-java/oracle-jdk-bin)   
    Yeah, it's a bit cryptic.  It wants it like this
    eselect java-nsplugin set 64bit blah Blah being the name or number of what you want to use.
     
  17. Trolling
    sputnik got a reaction from cuchumino in Cannot eselect java-nsplugin to a later slot/version (dev-java/oracle-jdk-bin)   
    Yeah, it's a bit cryptic.  It wants it like this
    eselect java-nsplugin set 64bit blah Blah being the name or number of what you want to use.
     
  18. Trolling
    sputnik got a reaction from cuchumino in I deleted /usr/portage/*   
    This never fails:http://www.funtoo.org/Installing_Portage_From_Snapshot
    Although guessing, you've still got some hidden files in /usr/portage, just finish what you started and rm /usr/portage, install -d /usr/portage and try emerge --sync, faster.  That is if you don't care about distfiles and packages.
  19. Trolling
    sputnik got a reaction from cuchumino in Lots of XFCE removed from portage?   
    There was some kind of funny stuff with the Gentoo afternoon update, I had a weird message about downgrading libreoffice for no good reason.  Happens.  Good to say "oh, well, I'll update tomorrow" when you see stuff like that.  Maybe there's something else to the xfce stuff, I just don't know, but considering the other funnyness I'd wait and see.  I re-synced later and the libreoffice downgrade was gone, although the xfce stuff you mention is still missing.
    Also, as a BTW, I used to have a lot of trouble with eix-sync, lunched my Portdir 2 or 3 times, so I quit using it.  In Funtoo, when I was using Gentoo it was no problem.  Just FYI, in case you have trouble.  Could have just been something here locally.  Now I emerge --sync && eix-update, same thing, a little more typing.
  20. Trolling
    sputnik got a reaction from 666threesixes666 in Screenshots   
    Like everyone else, I know my desktop is the most beautiful on the planet: http://imgur.com/9baiBBn
    Compiz | Lxpanel | SpaceFM | Docky - a no-desktop desktop
  21. Trolling
    sputnik got a reaction from benzolius in How can I copy/install usb driver from system rescue cd?   
    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.
×
×
  • Create New...