Jump to content
Read the Funtoo Newsletter: Summer 2023 ×

hencb

Members
  • Posts

    13
  • Joined

  • Last visited

Recent Profile Visitors

979 profile views

hencb's Achievements

  1. 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
  2. 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!
  3. 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!
  4. Did you follow http://www.funtoo.org/News:GCC_Update? Revdep-rebuild is a required step for the upgrade to gcc 5
  5. https://bugs.funtoo.org/browse/FL-3590possible update to gcc 5.4.0
  6. 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
  7. 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!
  8. 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.
  9. 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?
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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!
×
×
  • Create New...