Jump to content
Read the Funtoo Newsletter: Summer 2023 ×

drobbins

Funtoo Linux BDFL
  • Posts

    513
  • Joined

  • Last visited

  • Days Won

    282

Posts posted by drobbins

  1. You may have noticed that GNOME 3.12.2 is now part of Funtoo Linux, and does *not* require systemd.

     

    Many thanks to Dantrell B. for spearheading the effort to make this happen!

     

    With GNOME 3.12 integrated into our tree, we were able to unfork a lot of ebuilds and align more closely with Gentoo.

     

    For information on how to install GNOME 3.12, see GNOME First Steps on the wiki. The approach is the same as before -- using the gnome mix-in.

     

    If you have GNOME 3.6 installed, your GNOME mix-in has been auto-updated to be a GNOME 3.12 mix-in and you should be able to upgrade. Find instructions at the link above.

     

    Best Regards,

     

    Daniel

     

     

  2. Hi Everyone,

     
    I am going to be making some changes to the project soon, to fulfill the vision of a user-centric community and also make Funtoo more suitable for enterprise systems.
     
    Here is what I have found. If you have a single Funtoo system, then the continual changes that we receive from Gentoo are probably not a big deal. You do a system update daily or maybe once a week, resolve any issues, and your system continues to work well with a little hand-holding.
     
    However, there is a lot of work being done behind the scenes by angry_vincent and myself to keep things working well. Our tree is created in a totally automated way, but we "fix" things that break as various things in Gentoo are updated.
     
    And there is the problem. The automated Gentoo updates are fine for a single system, but if you like me have 5+ Funtoo systems, you do not update your systems regularly and then the various hand-holding, perl-cleaner, revdep-rebuild and blocker resolution is a huge pain.
     
    And there is another problem... Angry_vincent and I probably spend 90%+ of our Funtoo time on fixing things that are broken, which means we have no time left to actually create new awesome technology to make Funtoo better. Like a boot-update rewrite, or a metro rewrite, all things that I want to get to. Yes, I find a way to sneak in time to do various things but it is not very ideal.
     
    So, for any problem there is a solution. I have a vision of a solution that will give us the ability to have more control over quality, without doing a wholesale fork of all of Gentoo. I don't see the point of forking all of Gentoo... without better planning and technology, we will just duplicate the same problem of continuous rolling release, but have it happen on the Funtoo side. Rolling release is a good thing, but it is not suitable for all users of Funtoo or Gentoo... so we need something that will make Funtoo more capable without working against the benefits of rolling release.
     
    Since I am not only a developer, not only BDFL, but also a *user* of Funtoo Linux (and *that* is what I consider myself first and foremost,) I want Funtoo Linux to work for larger scale deployments. And I want developers and *users* to not be continually burdened with unending ebuild updates and break/fix situations.
     
    So, over the next few weeks, I am going to be reaching out to our small team of staff and get them up to speed on regular Funtoo maintenance so that I can focus my 'Funtoo' time on developing this new system. Not a new distro, but a new way that Funtoo will manage updates that will give us much more control and the ability to focus on strategic initiatives much, much more than we have in the past.
     
    Best Regards,
     
    Daniel
  3. Perl 5.18 has hit the Portage tree, as we unfork perl to align with Gentoo.

     

    The upgrade process is somewhat painful. Many dev-perl ebuilds will need to be rebuilt by running "perl-updater --modules".

     

    Those ebuilds that have EAPI=5 set will not need rebuilding, but those with EAPI=4 or below will need perl-updater to help them along.

     

    Apologies for any inconvenience in updating. I am going to make some changes to provide a more solid platform in the future.

     

    -Daniel

  4. We are getting ready to test GNOME 3.12 support in Funtoo Linux.

     

    This is being done using Dantrell's patches to allow us to have a systemd-free GNOME. This is going to be tested in the experimental branch first. When it's working okay, the idea is:

     

    • We will maintain a more minimal GNOME overlay with just a few ebuilds tweaked to allow non-systemd GNOME.
    • Many packages will then be unforked.
    • Only the packages necessary to ensure systemd-less operation will be maintained as forks.
    • GNOME profile will be updated accordingly.
    • GNOME 3.6 support will be deprecated, and 3.12+ will be maintained.

    This will help to reduce a lot of the divergence between Gentoo and Funtoo and then more resources can be focused on things besides ensuring that GNOME continues to work.

     

    -Daniel

  5. Hi All,

     
    It's the opinion of the BDFL (yours truly) that if you experience blockers or unresolved dependencies when trying to emerge something, that's a bug. 
     
    Please report all blockers that you encounter to bugs.funtoo.org so we can address them properly.
     
    Anything that makes it difficult for you to get packages installed that you need is either a bug or a potential improvement to Funtoo Linux.
     
    Thank you,
     
    Daniel Robbins
  6. Funtoo is a user-centered distribution, which means the focus is on your experience with Funtoo Linux and not on random development goals. We do try to keep things more stable than in Gentoo, by preventing unnecessary updates to the toolchain.

     

    We actually have a very small team right now. There are about 3 active committers, including myself. Although I will be working on significantly growing the team soon.

     

    The fight against package masking, preserved libs and slot conflicts are battles that I'm actively trying to fight over here in Funtoo land. We welcome you to help us fight them. Funtoo started when I tried to get my creation, Gentoo, to actually build.

     

    I can't guarantee you won't experience any issues but I can assure you that we'll be very responsive to any issues you have.

  7. Okay. I will be working on resources for new developers. Flora was run as sort of a side-project, and that was probably not the best approach. An effort like that needs to be fully integrated into the main Funtoo Linux project, which I will do. That should solve the problem by ensuring that your work is paid more attention to and you are given the resources you need to be successful and learn.

  8. Works great, thank you for that! :)

    Is the content of the feed adjustable? I'm missing the infos "Who's post is this?" and "In what forum ("General discussion", ...) has it been posted?"

    But even if this isn't possible, it still is a great hint for how I'm used to work with forums! :)

     

    I can't really change anything... this is what is supported out of the box in IP.Board 3.

  9. Sure, here's the info. The way the variables in /etc/make.conf are "merged" into the defaults in the profile is a fairly complex process, but...

     

    There is really no difference for the *FLAGS, since there is only a very generic default.

     

    You want to make sure you use the FOO="${FOO} blah" format when you have lines earlier in the same file that define FOO. If you do not, they you will overwrite your earlier settings. If you use FOO="${FOO} blah", then you will *add* blah to your existing settings you defined earlier in the same file.

     

     

    How variables are handled in /etc/make.conf is interesting -- there are two types of variables. Regular variables, and "incrementals". The incrementals are:

     

    "USE", "USE_EXPAND", "USE_EXPAND_HIDDEN",
    "FEATURES", "ACCEPT_KEYWORDS",
    "CONFIG_PROTECT_MASK", "CONFIG_PROTECT",
    "IUSE_IMPLICIT",
    "PRELINK_PATH", "PRELINK_PATH_MASK",
    "PROFILE_ONLY_VARIABLES",
     "USE_EXPAND_IMPLICIT", "USE_EXPAND_UNPREFIXED"
     
    The most common incremental is USE. What makes use incremental? "Incremental" means that if you set this in /etc/make.conf:
     
    USE="foo"
     
    ... then "foo" will be *added* to your existing USE setting. This makes it incremental.
     
    To totally wipe your USE, you must do:
     
    USE="-* foo"
     
    If something is NOT an incremental, then you can wipe the variable by going:
     
    FOO="bar"
     
    and to preserve existing settings for non-incremental, if there are any, you must do:
     
    FOO="${FOO} bar"
     
    CFLAGS, etc. are non-incremental, but there are just basic defaults of typically "-O2 -pipe", so generally people just override.
     
    -Daniel
×
×
  • Create New...