hencb
Members-
Posts
13 -
Joined
-
Last visited
Recent Profile Visitors
979 profile views
hencb's Achievements
-
NikosAlexandris reacted to a post in a topic: Learning to create newer versions of e-builds
-
No, you need both emerge -e @system --exclude gcc and revdep-rebuild. You can see the full instructions in the News announcement that Oleg Vinichenko wrote: http://www.funtoo.org/News:GCC_Update
-
hencb reacted to a question: PXE Network Boot Server
-
hencb reacted to a post in a topic: Getting Rid of Forums and Moving to Reddit?
-
This seems like a great idea to share patches, it might come in handy for the difficult and large changes that cause breakage across the portage tree (like a gcc upgrade) and it might make disseminating patches easier. I'll try it out when I get the time :) Keep up the good work!
-
Learning to create newer versions of e-builds
hencb replied to NikosAlexandris's topic in Dev Central
Ok there's quite a few outdated documents and command warnings that cause problems here. First of, emerge <ebuildname>.ebuild from the current overlay directory tends to work. I generally don't use it since the ebuild tool allows you to install a package just like emerge does, but it does this by going through different stages. Let's start with the prerequisite: The manifest file. You don't have to run ebuild *.ebuild manifest, just run ebuild <ebuildname>.ebuild manifest, which will generate a manifest for all ebuilds in the current directory. There's also repoman, which Gentoo uses, and which can create manifests as well: repoman manifest will create manifest entries for all ebuilds that don't have one already. I highly recommend reading "man ebuild" on how to use the ebuild tool. It will make debugging ebuild problems a lot easier. A basic way to install a custom ebuild using the ebuild tool can be done like this, if the manifest is correct: ebuild gdal-2.0.3.ebuild fetch (downloads the package and verifies that its integrity using the manifest file) ebuild gdal-2.0.3.ebuild unpack (downloads the package and untars it into /var/tmp/portage/sci-libs/gdal-2.0.3.ebuild) ebuild gdal-2.0.3.ebuild prepare (applies any patches and prepares the ebuild) ebuild gdal-2.0.3.ebuild configure (runs the configure script of autotools) ebuild gdal-2.0.3.ebuild compile (compiles the packages) ebuild gdal-2.0.3.ebuild install (this will install the package into a sandbox, that is, into /var/tmp/portage/sci-libs/gdal-2.0.3/image folder) ebuild gda1 qmerge (install the package into the system. At this point, the whole process is completed and is equivalent to running emerge) Some phases also include others. Typically, you'll skip the fetch and configure phase, they are included in the other commands (unpack and compile). I haven't listed some of the phases due to brevity. This is still a very verbose way to install an ebuild, and a bit tedious. A simpler way to use the ebuild tool is to run: ebuild <ebuildname>.ebuild merge ,which is equivalent to running: emerge <ebuildname>.ebuild. Consider reading both man ebuild (for the tool) and man 5 ebuild (for the ebuild syntax). They're the most accurate documents at the moment. It seems somebody masked the newer versions of gdal for some reason. This needs further investigation. It might be a malformed mask and you should add an entry to package.unmask for the time being: >=sci-libs/gdal-2.0.3 Drop by on IRC sometime and I'll be glad to assist you with any questions. Just ping me (bhenc) and I'll help you get started with the ebuilds. If you're unfamiliar with IRC, the www.funtoo.org/Getting_Help page might be a good place to start. Happy hacking! -
Did you follow http://www.funtoo.org/News:GCC_Update? Revdep-rebuild is a required step for the upgrade to gcc 5
-
https://bugs.funtoo.org/browse/FL-3590possible update to gcc 5.4.0
-
hencb reacted to a post in a topic: Converting From Gentoo to Funtoo
-
hencb reacted to a post in a topic: Converting From Gentoo to Funtoo
-
hencb reacted to a post in a topic: Converting From Gentoo to Funtoo
-
These might be useful, but you probably found them: http://www.funtoo.org/Metro http://www.funtoo.org/How_Metro_Works http://www.funtoo.org/Category:Metro
-
hencb reacted to an answer to a question: Error 403: Forbidden downloading a 'snapshot' from either mirror
-
hencb reacted to an answer to a question: Error 403: Forbidden downloading a 'snapshot' from either mirror
-
The gcc ebuild has been modified to comply more with upstream versions (not Gentoo). Basically the Gentoo toolchain is in a bad shape, and Daniel Robbins has modified the gcc ebuild to fix some of the issues, and glibc is probably going to be next. You can compare the differences between the gcc ebuilds of Funtoo and Gentoo, you'll see the difference. Most of the complexity is hidden away in the Gentoo ebuild, however, that doesn't mean it isn't shabby underneath. You can try using them, if you're willing to experiment, this is Funtoo after all :) Just don't do it on a system you really care about!
-
hencb reacted to an answer to a question: "emerge nvidia-drivers" stops at dev-qt/qtcore
-
Error 403: Forbidden downloading a 'snapshot' from either mirror
hencb replied to rspartz's question in Portage Help
https://bugs.funtoo.org/browse/FL-3530It has been reported. You can try using my mirror: https://funtoo.vorangerie.com:80 It has the Funtoo portage snapshots mirrored. -
hencb reacted to an answer to a question: Stages4 and a LiveDVD
-
hencb reacted to an answer to a question: Stages4 and a LiveDVD
-
Hey no problem, that's what the forums are for, just leave a message and come back anytime. Did the suggestion fix your problem compiling?
-
It's quite a complicated topic. If I were you I'd search for related topics like: Build Linux from Scratch Cross-compiling Autotools The YOCTO project documentation Building Gentoo from a stage1. Read everything on the Funtoo wiki. That's the best advice I can give you at the moment. Most of the development time is spent fixing bugs, so if you can help with that by creating patches and ebuilds to fix stuff you could relieve the strain on the other developers who could then write the necessary documentation.
-
I guess it's possible to pull what you want provided you can grab a kernel that provides both qemu virtualization and container support. I guess that you could also run containers in a VM and have OpenStack emulate the containers. http://searchservervirtualization.techtarget.com/feature/The-debate-isnt-containers-vs-VMs-its-how-to-best-integrate-them You could potentially run an OpenStack server as your desktop and access one of the VMs as your "main desktop" Again, this is hypothetical, and far-fetched at best. Somebody might be brilliant enough to write such a thing. You're better off with Funtoo to try your luck with containter virtualization since we feature kernels that support that: http://www.funtoo.org/Funtoo_Linux_KernelsIf I recall correctly Gentoo doesn't have that feature. You can try getting qemu to work with containers. Can't help you realizing any of this, since I don't have the experience. Theoretically it could be done, although it would be rather tedious. Might be worth it if you have a beast of a PC available. Caveat emptor.
-
AdiosKid reacted to an answer to a question: Stages4 and a LiveDVD
-
Try editing the ebuild: # Building with python integration seems to fail without 8G available # RAM(!) Since the memory check in check-reqs doesn't count swap, it # may be unfair to fail the build entirely on the memory test alone. # Therefore check-reqs_pkg_pretend is deliberately omitted so that we # ewarn but not eerror. This is the comment in the ebuild, according to it, with swap you should be fine according to the comment. Comment out this line in the ledger-3.1.1 below the comment (line 58): check-reqs_pkg_setup change to: #check_reqs_pkg_setup Commenting out the line will skip the RAM check. Then, try emerging the package and see if it works.
-
Hi! I'd suggest posting a bug on bugs.funtoo.org, it's the right place to handle build failures. Segmentation faults are caused by insufficient memory. https://bugs.funtoo.org/browse/FL-3503 Rule of thumb: ~1.25GB per thread. Try compiling with MAKEOPTS="-j1" Also, you might want to read up on how to debug such build failures: https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Building_the_Gentoo_Base_System_Minus_Kernel#Troubleshooting_a_Failed_Build If your hard drive, CPU or memory are faulty, this is going to show when compiling llvm. https://bugs.funtoo.org/browse/FL-3498 I suggest running with -j1 and making sure the swap is turned on, and leave it to compile overnight. I'd run memtest, check SMART for the hard drive, and there's mprime for the CPU or equivalent. I'll try emerging llvm on a core2 system I have and report the results.
-
This could be done in a smaller fashion to include a general 64bit subarch instead of a plethora of stage4s. The complexity goes through the roof when we consider the number of subarches Funtoo currently supports: We'd have to compile at least 4x (LXDE, XFCE, KDE and GNOME desktops) the number of subarches to create every possible stage4. That's not really realistic. Creating a stage4 that could be a general 64 bit architecture to install on a system through a GUI could be sensible. Reviewers generally loose patience when they review source-based distributions. This could bridge the gap and allow them to compile and tweak smaller packages without spending hours on compiling. Bottom line is: There's no distribution that offers such a wide variety of stage3s optimized for different hardware. I'd much rather expand our reach into the embedded market with IoT and mobile devices. Except for android, it's mostly uncharted territory. YOCTO should not have to exist when we have a source-based distribution that can produce stage4s with ease. There's no reason why a Funtoo Linux Live CD should be needed if the Gentoo Linux one works fine: we share bug fixes with Gentoo and remain largely intercompatible , and we shouldn't have to duplicate the effort put into managing a Live CD without any need. Fragmentation in the Linux community is a plague; let's not create another split between distributions if we don't have to.
-
ninja: build stopped: subcommand failed. for electron-1.3.6
hencb replied to dougbmorris's question in Installation Help
The issue has been fixed by the ebuild author. It will take some time for the update to hit the Funtoo tree. You're free to try any of the workaround mentioned in the bug report: https://bugs.funtoo.org/browse/FL-3511 You can also directly add the overlay of the atom package maintainer. I hope that fixes your problem. Cheerz!