j-g-

But if you are a voluntary package maintainer or developer, in an open source distro where users aren't forced, you are being forced to maintain unit files and, init scripts, also deal with bugs for both. I see the forcing of systemd on many distros as a misfortune, due to the lack of man power to keep both maintained by different people, so maintainers aren't forced either to maintain compatibility with a software the don't use or dislike, as I said previously, I understand why funtoo devs would disable systemd from portage, it would just be an annoyance on the bugtracker. If you are a distro leader you would have to prioritize to keep in a good mood the people that contributes the most. certainly it would make less harm the forum rants than the increased bugs unhandled due to maintainers leaving burn-out. This is actually a strong point of systemd, remember you can have a shell-less boot, and run in your machine just to find a few examples: $ egrep -rn ' sed | awk | grep ' /etc/init.d/ And the fast boot is rather than a intended feature, a consequence of running less programs at boot to get services going. about dbus, I haven't dealt with it directly, so I can't say much. but supposedly kdbus is an intent to take the good of it and ditch the bad. I don't think companies are all good intentions, but I don't really see much problem, when they: - Want to hire open source developers, this is a really good thing if you are a developer, doing what you like and get paid for it. -The code produced is being open sourced. The fact that most companies are unlike this, is a shame, everyone would have so much better software if more talented developers would get paid to improve open source tools, and not so much home-grown stuff, totally closed.

The flamewar was already started, and the tread was deviated(I even read a bit of a wayland rant) from the intent of the OP many posts before mine, contrary to your experience I've seen many times help given on the gentoo mailing list to people that want to try it, and lots of patience, It's a shame you didn't asked the right people, but if you go anywhere with the argument 'Theres no documentation' when there is and its even local, it's likely the one who took the effort to read and grasp the manuals(and don't say most manuals are easy, look at bash), might get unfriendly, because you don't want to put any effort, remember asking for help in the open source it's taking someone time for free, so an extra effort is required, to show appreciation of the time given to you.

I've mentioned this here a few times, I use systemd with Funtoo(Or should I say NotFuntoo since drobbins says Funtoo is only Funtoo with OpenRC), I would have bothered to do what l33tlinuxh4x0r did, and post a guide and even an overlay, but I anticipated a flamewar like this, for no reason, anyway getting systemd to run isn't that hard, and any competent user would figure out the changes needed. Many of you seem to know little about systemd, or can't read manuals(Undocumented?), and yet have big opinions on it, anyway this this has shown to be the tendency in among most of the systemd detractors. I understand devs don't want the burden of having to deal with bugs related to a software they dislike, but certainly It isn't attractive either to try to contribute for the few of us who like it, when any intent would turn into a flame war.

Did you tried using g++ -std=c++11 ... to compile the program with gcc?

Why don't you take a look at how sabayon is put together, and maybe even use entropy to manage your binary packages, It has the advantage of being an already known and tested suite, You might be able to use a lot of their stuff for building your project. PD: I have never used sabayon, I know some people who have, and were pleased with it, so maybe their tools are good.

cgdisk /dev/sda first partition- 500M 8300 second partition- 250M EF02 third partition- 2G 8200 forth partition- 20G 8300 fith partition 40G 8300 mkfs.vfat /dev/sda1 mkdosfs -n efi-boot /dev/sda2 This, the efi-boot partition MUST be the first. you could try backup sda1 and sda2, and just make those again in the correct order and copy the files back again.

See eclean-dist --help , it has many useful options.

I would do it in two steps, base system, and then @world emerge -avNe --with-bdeps=y @system emerge -avNe --with-bdeps=y @world -N for new USE flags, -e for empty tree: "-emptytree (-e) Reinstalls target atoms and their entire deep dependency tree, as though no packages are currently installed. You should run this with --pretend first to make sure the result is what you expect. " WARNING: You might bump into some bugs when doing a full rebuild, or compilation might strangely stop, the only time I have done this, it took 4 'emerge --resume' to get it done.(But I have limited ram and not much cores, I blame it on that) PD: you can migrate your current system to another partition like you would take a VM and run it bare-metal, just make sure the boot process is correct.(fstab and bootloader configuration mainly)

Those instructions are from an installation with PORTDIR="/var/portage/tree/funtoo/", the default is PORTDIR="/usr/portage". see the make.conf(5) manual.

The two distros that put effort on systemd initially OpenSUSE and Fedora(Red Hat), aren't bigger in manpower, than the combination of Arch. Debian(and derivates), Gentoo, Canonical, and Slackware, developer comunities, I don't see how being majority 4 years ago distros that didn't used systemd, were politically forced to use it, the man power was there, if they would have wanted the organization of a better and moder init system would have happened. The political argument doesn't make practical sense.

No one is forcing anything, you chose Funtoo and you don't have to use it, the thing is, code does more than rant threads like this, you say Lennart is publicly a prick? Yeah that prick who has written more free software than anyone on this thread and put it available for free. and guess what? people chose to use it. He's indeed a paid employee who works to make what I think he likes the most: write free software. I don't know, but I don't think any if you given the chance(and being ~25) would turn down a Red Hat job offer, and if you did, clearly you would be very stupid, anyway, working for someone doesn't take away your freedom of speech(Sorry if you don't have that in your country), you can post whatever you want in your personal social media, and Lennart most of the time post technical and interesting stuff in his blog, unlike the insightful analogies between filming porn and developing free software I've read in this forum[1]. It's true saying today 'if you don't like systemd make your own', is stupid, given how much development systemd has had, but, the 'Rethinking PID 1' post[2] that was published in the beginnings of systemd, and describes the vision of the development, was four years ago, and none of the people that has been ranting since then, did anything more than that, just rant. And many others, those who knew what is useful to change, wrote code, but they did it for systemd(also upstart and OpenRC, but clearly they where less). Anyway, This post is getting too long, So... :wq [1] http://0pointer.de/blog/projects/systemd.html [2] http://forums.funtoo.org/index.php?/topic/111-gnome-312-is-here/?p=571 PD: Code says and does more than prose when it comes to software.

So far my experience has been, you can use /usr/local/portage, or an overlay of your own, I would recommend the overlay, since you can make changes to it as normal user. there's an skeleton overlay uploaded for funtoo in github, you can start from that. Make the directory structure for the package you wan to test in your overlay dir: $ mkdir -p ${OVERLAY_DIR}/cat/pkg/ # Edit your ebuild: $ $EDITOR ${OVERLAY_DIR}/cat/pkg/pkg-0.0.ebuild # generate a Manifest $ ebuild ${OVERLAY_DIR}/cat/pkg/pkg-0.0.ebuild manifest Add your overlay via making a overlay.xml file in /etc/layman/overlays/ (this is documented in the layman manual) or adding to your make.conf PORTDIR_OVERLAY="${PORTDIR_OVERLAY} $YOUR_OVERLAY_DIR" If you don't have the package installed already or are adding new dependencies you can do: $ sudo emerge --onlydeps '=cat/pkg-0.0' and then you can test your ebuild step by step using the 'ebuild' command, I try before merging anything I edit, generating a package, this means all the build process is made except actually getting the package in your filesystem, you can inspect the tarball generated to see everything looks right and then merge. $ sudo ebuild ${OVERLAY_DIR}/cat/pkg/pkg-0.0.ebuild package That said you should read first and mainly refer to the gentoo dev documentation.[1] or 'emerge -av devmanual' [1] http://devmanual.gentoo.org/index.html

I re-vectorized the original funtoo logo to make some wallpapers and a 3d model and posted the svg and other editable files(3d) with that logo some time ago in this tread: http://forums.funtoo.org/index.php?/topic/88-some-artwork-for-funtoo-wallpapers/&do=findComment&comment=347 look at the bottom in the post, there's a URL to a tar.xz in dropbox.

I'm no one to say when but I think a few(or many) weeks. It will take time to the gentoo developers to bump all the gnome ebuilds, and then the patches made by dantrell for funtoo would have to be tested to work and/or upgraded. It was just released today, and the work is not a simple task. Edit: If you want to adventure to try to make it work with funtoo, this overlay seems to be ahead of all the others on the gnome bump: https://github.com/thankjura/gentoo-gnome

If you crafted that manually you missed adding the initrd command to load your dracut generated initramfs, and since you are using dracut you might want to explore more of its options, you can set your kernel command line in /etc/dracut.conf, and other ineresting things, this will make the upgrading kernel process more cleaner since you don't need to add the command line every time, also make sure you have ' hostonly="yes" ' in dracut.conf.

I think you missed the '-t' or '--target' flag, and that is the part that interprets 'armv7a-hardfloat-linux-gnueabi', and maybe crossdev just was trying to build another compiler for your local target, that's why so many conflicts regarding 'x86_64-pc-linux-gnu', and the strange message 'Package 'cross-armv7a-hardfloat-linux-gnueabi/gcc-4.8.2-r2' NOT merged' Is it even supposed to be a package? Also I don't know if it would give some kind trouble to use the '-S' flag if you are running 'current', seems a contradiction, is that your case? crossdev is tricky and not really well documented, If that isn't the problem, I can't help you further, I haven't played around with arm stuff that much, and currently I don't have a decent device for that. So I would look for help in irc, from people who uses it every day(Or even its developers)

There are a few problems with your aproach. That file should be a symbolic link(upgrades), from funtoo wiki[1]: /etc/localtime ... Your timezone, which will default to UTC if not set. This should be a symbolic link to something located under /usr/share/zoneinfo (e.g. /usr/share/zoneinfo/America/Montreal) First, there's no '/etc/init.d/local.start' file so that would print and error but you are sending it to /dev/null, and It doesn't make sense to call something in /etc/init.d in a local script, read the README inside /etc/local.d/ for information on the correct use of the 'local' service. Second, why didn't you just used the init script for ntp? I see you didn't even added ntp to your default runlevel services, that would be: rc-update -v add ntp default Check that's the acutal script name you want to add, in /etc/init.d, I don't have ntp here so didn't check that, If unsure ntp is the actual provider for the service, use ` equery f ntp | grep /etc/init.d ` to confirm [1] http://www.funtoo.org/Funtoo_Linux_Installation#Configuring_your_system

Are you using crossdev for that?(tell what you typed, not only the output ) I've only once compiled an armv7a-hardfloat-gnueabi and it didn't use those paths warned for installing, I can't recall everything I did, but the documentation helped me

I looked at the repo you posted, and the last commit[1] is a defconfig for the beagle bone, I would use that, run make help in the directory where you have that, and read about using defconfigs. [1] https://github.com/beagleboard/linux/blob/3.14/arch/arm/configs/bb.org_defconfig

I see at the bottom of that, the USE flags used for building, and there is '-wifi', wich means the NetworManager you compiled doesn't have wifi capabilities, since you seem to be new to portage, I'll explain you some stuff, but refer to 'man 5 portage' to learn more about portage's configuration files. You can enable wireless for NetworkManager either adding 'wifi' to the USE variable in /etc/portage/make.conf, ... USE="... wifi " ... or for using wifi only for networkmanager, add this line in /etc/portage/package.use (You can create this file, if you don't have it yet): net-misc/networkmanager wifi After any of those, remerge networkmanager with 'emerge -av net-misc/networkmanager' , this will show you the USE flags portage will use to build, check wifi is used, and let it build again, this should fix your problem. Also, what flavor did you use, when selecting a profile with 'eselect profile'? I think if you use a workstation or desktop flavor, wifi USE flag is enabled by default, but I'm not sure about this, I'll check later.

If you are using a chroot, you don't need to configure the wifi network inside it, just copy your local /etc/resolv.conf to ${FUNTOO_CHROOT_DIR}/etc/resolv.conf, or if you know what that file is for make sure you have some dns servers in there. When in the chroot, just make sure you build your kernel modules needed for your card, if you build debian-sources kernel, you are more likely OK. After you leave the chroot, and reboot, use only one network manager, wicd , NetworkManager, etc.., if you will use NetworkManager and you don't have a GUI you can use nmcli, I use it that way, a quick list of commands for managing wifi trough nmcli: nmcli c s # connection status nmcli d # list devices nmcli d w l # list wifi connections available (SSID,BSSID, etc) nmcli d w c [SSID] password <password> # connect to a network password can be eg. WPA2 or WEP if you need more help after rebooting, save and paste here after a log of: ifconfig -a # or better ip a # you will have to install iproute2 in the chroot for that cat /proc/net/wireless cat /proc/net/dev emerge --info [network_manager_installed]

Post the complete outputs, the above post really says nothing. Edit: I see you have already been given directions on the bugtracker, so there's nothing else to say.

Edit: I wrote a rather lengthy opinion on System U, and later realized it derails from the topic, and I care more about the topic so I put in a spoiler. Lets contribute to the discussion, and share some ideas about that thing people names 'User experience' and I agree with you on the concept of surveys, or something like that, but ultimately, one can't generalize the concept of 'users', there are many different types of users, and a person uses a computer as means to do something, not because of using the computer(but I bet many of us *ntoo users do exactly that), so the 'tools' used that achieve the main goal of the user, are the essential part as I see it, so efforts to make well designed tool-chains for different use cases, I think would be a better approach(eg. office, graphics edition, CAD, Business management), and take someone who isn't a power-user, and I think these are the majority, and put a launcher in his desktop for his 'work' tools, a web-brower, and a file manager for him to copy files to USB pen-drives, I bet you will have a happy user most of the time. In this regard I see the fedora spins as a really good Idea, I also always see many people saying windows is easier to use for 'end users', but really how many people you know that actually 'know how to use it', and don't just click any OK button that gets in their way, and yes, they break things this ways sometimes. So, it is my opinion use cases, a profile of a set of regular users of a specific tool-chain, surveys made to people that actually uses the software, would be better directions for developers. I think many times, FOSS developers just scratch their own itches, thus making not really well planned and studied changes, that might be a headache for a user who might have never needed the new change(feature), and I know many times for a developer, to make that 'well planned' change requires time, which many FOSS contributors don't have because they do these new features in their free time, I think fund-raising to hire paid developers to improve/make/integrate tool-chains *UPSTREAM*(I really want to emphasize that) wold make the FOSS world much better than more distro fragmentation. I have written too much, for this post, so I leave sharing a video-conference on User Experience, that taught me some very useful things I will apply as a developer, http://youtu.be/ 7OSkB4BCx00 (remove the space). PD: Excuse my English, I'm not a native speaker.

Do it the other way around, don't set static-libs gloabally, you will have more troubles, instead set it per package in package.use.

I think the first post is a pretended emerge, and ~amd64 is set globally on his make.conf, so no, it wont help. What OP could try, is unmasking the 'multilib' useflag, if his system actually supports multilib, and try emerge again, but I don't think it was masked arbitrarily, so it's likely the build fails or runtime problems might arise. echo '-multilib' >> /etc/portage/package.use.mask It might be also needed to enable the multilib use flag in package.use for media-gfx/nvidia-cg-toolkit. But I warn again, it's likely to be broken somewhere and that caused the developers to do the use flag masking (and if you look carefully, this is coming from gentoo, so I would search the gentoo bugtracker to see if I found out, why multilib is masked)