Jump to content

hencb

Members
  • Content Count

    13
  • Joined

  • Last visited

Posts posted by hencb


  1. 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!


  2. 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!


  3. Hi, sorry for the late reply. Thanks so much for the kind advice -- I am giving these a shot ... will post back ASAP. Cheers!!

     

    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?


  4. 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.


  5. 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.


  6. 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.


  7. 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.


  8. 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.


  9. I think it's a good idea,

     

    Advantages:

    - If it lowers the strain on you guys and allows you to focus on more important issues, I'm all for it.

    - More exposure is great.

     

    But there are downsides (or rather, issues to be resolved):

     

    Automation:

     

    this one hurts the most in the long run. Can we connect reddit to the chat in the same way the bugtracker and git commits are

    integrated into the chat? Reddit might be more interested in displaying ads than helping us with using their platform. And you

    cannot display ads to an automated script.

     

    - How do you create backups of reddit posts?

    I mean, not everyone posts to the bug tracker, and if for example a bug is resolved in a reddit post, how do you index that?

    I've heard of mailing lists containing priceless information on the fine details of how a distro works, without backups. If you loose

    the mailing list, you'd be in serious trouble.

     

    - How do you distinguish real funtoo users from gentoo users on reddit?

    I'm not against them helping people, but I really would like some visual identification that someone actually using funtoo is

    replying to issues. The more funtoo diverges from gentoo (like the epro profiles) the more we'll be in trouble with gentoo

    users assuming they know what they are doing.

    If I see a reddit post, I really want to be able to glance at a reddit post and see that a funtoo user responded.

     

    Also, there are also guides on the funtoo forums on how to setup stuff e.g.:

    http://forums.funtoo.org/blog/13/entry-15-setting-up-a-web-server-nginx

    http://forums.funtoo.org/blog/10/entry-11-adding-ssl-to-tengine-nginx/

     

    - If we're in the same boat as reddit, we also inherit the reddit community

    All the trolling, spamming, DDoSing etc. If reddit goes down (hell, github was taken

    down some time ago) do I loose anything?

     

    I think they shouldn't be lost, A half-decent backup would be great.

    But I'd make a good backup of the forums and store it somewhere safe.

     

    Also relevant:

    http://www.abovetopsecret.com/forum/thread1148643/pg1

    This is a serious issue: reddit is a company and should be distrusted in the same manner as any other company.

    They're not a community: they are a company.

     

    I'd recommend to do a complete search on the bad sides of reddit, and to do it with multiple search engines.

    I'd post more but I'm kinda strapped for time this week.

     

    TL;DR I'm for it, but make sure you're aware of the disadvantages.

×
×
  • Create New...