Jump to content
funtoo forums


Funtoo Linux Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


palica last won the day on November 11

palica had the most liked content!


About palica

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. most of the stuff gets announced https://forums.funtoo.org/forum/5-news-and-announcements/ available are always only the branches that are part of the release. 1.3-release is now release as beta quality. so test it out and report any bugs that you encounter. some of the branches get named after the release some are named after the version of the software they are incorporating like kde-5.12 gnome-3.26 perl-5.26 python-3.7 ... and others just have many different software and are simply named 1.3-release. there is no other description visible using currently available funtoo tools. stability can be found here: https://github.com/funtoo/kit-fixups/blob/master/modules/fixups/foundations.py#L5-L12 class KitStabilityRating(Enum): PRIME = 0 # Kit is enterprise-quality NEAR_PRIME = 1 # Kit is approaching enterprise-quality BETA = 2 # Kit is in beta ALPHA = 3 # Kit is in alpha DEV = 4 # Kit is newly created and in active development CURRENT = 10 # Kit follows Gentoo currrent DEPRECATED = 11 # Kit is deprecated/retired switching to kde-kit from 1.3-release while still on 1.2-release will fail when doing ego sync, but can be done manually (although not recommended and definitely not supported). You could manually switch to kde-kit from 1.3-release by checking out the appropriate sha hash of the commit as listed here: https://github.com/funtoo/meta-repo/blob/1.3-release/metadata/kit-sha1.json but this has to be done after every ego sync.
  2. thank you for your positive and friendly answers. I explained to you that 1.3-release branches will show up once you switch to 1.3-release, 5.12-prime is there from 1.2-release and master branch is a remnant of 1.0-release (at that time called 1.0-prime) here are the definitions that are used for kit generation, maybe that will answer your question https://github.com/funtoo/kit-fixups/blob/master/modules/fixups/foundations.py there is not a simple way of switching to a different branch of a kit (1.3-release for kde-kit) without actually switching the whole release = all kits to the 1.3-release. from the user perspective you should edit /etc/ego.conf and add in [global] section release = 1.2 (1.3) and perform ego sync ego will then switch the kit branches for you. There is a reason you cannot see all branches of a kit on a single release as these are untested and will probably not work. if there are multiple branches supported they are listed in ego kit list output and they can be switched using /etc/ego.conf with a value for example xorg-kit=1.20-release inside [kits] section. if you want to go your own way (switching a single kit to a different branch that is not supported for a given release) - you will probably not receive any official help from funtoo. (and definitely not from me 🙂 )
  3. so you looked at github and explored git locally - no sign of ego kit list here. You wonder if there is a way to do it with ego or any funtoo specific command -> ego kit list 1.3-release will show once you switch to 1.3-release in ego.conf [global] release = 1.3 the stability tag: current - tracking gentoo prime - somehow seen as good for production anything else - alpha, beta, dev => not good for production if you are not a developer
  4. ~ ❯❯❯ ego kit list kit is active? branch stability core-kit active 1.2-prime prime core-hw-kit active master current security-kit active 1.2-prime prime xorg-kit 1.17-prime prime active 1.19-prime prime 1.20-release dev gnome-kit active 3.20-prime prime 3.26-prime prime kde-kit active 5.12-prime prime media-kit active 1.2-prime prime perl-kit active 5.24-prime prime python-modules-kit active master current python-kit active 3.6-prime prime php-kit active master current java-kit active 1.2-prime prime ruby-kit active 1.2-prime prime haskell-kit active 1.2-prime prime ml-lang-kit active 1.2-prime prime lisp-scheme-kit active 1.2-prime prime lang-kit active 1.2-prime prime llvm-kit active 1.2-prime prime master dev dev-kit active 1.2-prime prime xfce-kit active 4.12-prime prime desktop-kit active 1.2-prime prime editors-kit active master current net-kit active master current text-kit active master current science-kit active master current games-kit active master current nokit active master current NOTE: This information comes from /etc/ego.conf and meta-repo metadata. After making changes to ego.conf, be sure to run ego sync in so that the individual kit repositories on disk are synchronized with the kit branches shown above.
  5. palica

    Build livecd

    https://github.com/matijaskala/metro-1 https://slontoo.sourceforge.io/
  6. palica

    cannot build openssl--1.1.0h on arm64

    open a bug report on bugs.funtoo.org
  7. palica

    cannot set profile

    no problem, glad we sorted it out.
  8. palica

    Trying to upgrade from funtoo 1.0

    there is no stable anymore try ./ego profile build current and try to resume from there
  9. palica

    Trying to upgrade from funtoo 1.0

    well actually he is using live master of ego can you from cloned ego folder do "ego profile "
  10. palica

    email notifications

  11. palica

    Virtualbox issues fresh Funtoo install

    try to find a log file inside VM dir somewhere, without it it is reading from a crystal ball.
  12. good plan. let us know what you find out.
  13. palica

    Virtualbox issues fresh Funtoo install

    running as what user? are you in the "virtualbox" group if not root?
  14. palica

    Virtualbox issues fresh Funtoo install

    lsmod | grep vbox
  15. it is not that much about software becoming incompatible with older release, it is more of any patches and fixes that didn't make it into 4.9-lts branch that you probably used, at the time of creation of the system, some BTRFS features that were in 4.14 branch and are not in 4.9. so creating a loop device btrfs system with 4 disks and creating a raid10 with 4.14 and then turning on all the flags like compress and such on the fs and putting some dummy data on there, and afterwards downgrading the kernel and mounting the filesystem and comparing for example the checksums of the dummy data or performing a scrub could give you information about if this downgrade is safe for your server, but also don't take this for granted and have backups!!! couple of ideas how to test without 4 harddrives can be found here: https://www.funtoo.org/BTRFS_Fun