Jump to content
funtoo forums


  • Content count

  • Joined

  • Last visited

About skunk

  • Rank


  • Location

Recent Profile Visitors

253 profile views
  1. chromium 65

  2. chromium 65

    hello, any chance to get safe chromium ebuild to the tree? thank you
  3. new ego and inactive kit branches

    if you don't want to downgrade and keep staying up to date with kde-kit's stuff, this is what i did: # check out gentoo's tree: cd /var/git git clone git://anongit.gentoo.org/repo/gentoo.git # create a script that syncs kde-kit's stuff from the gentoo's tree to a local overlay: cat > /root/sync_kde.sh #!/bin/bash cd /var/git/gentoo git pull cd /var/git/meta-repo/kits/kde-kit for i in *-* do [[ ! -d /usr/local/portage/kde/$i ]] && mkdir /usr/local/portage/kde/$i cd $i for j in * do [[ -d /var/git/gentoo/$i/$j ]] && rsync -a --delete /var/git/gentoo/$i/$j /usr/local/portage/kde/$i/ done cd .. done # add the following to /etc/eix-sync.conf: @/root/sync_kde.sh || true # and finally add the overlay to make.conf: PORTDIR_OVERLAY="/usr/local/portage/kde"
  4. kit's master branches

    nevermind it doesn't work the way i've thought, i've created my own overlay instead...
  5. kit's master branches

    i've created my own kde-kit branch, how can i mark it active so that it might be chosen from ego.conf please? thank you
  6. kit's master branches

    ok, i can live with it for some time, however why forcing everybody on 5.10-prime branch if they where on master if neither branch won't get updates anymore? downgrading from master to 5.10-prime isn't something worth doing if you already are on plasma-5.11.1/apps-17.08.2/framework-5.39, imho...
  7. kit's master branches

    hello again, i've the following set into my ego.conf: xorg-kit = 1.19-prime media-kit = 1.1-prime kde-kit = master however on today sync i've got this message: "Kit kde-kit branch master specified in ego.conf is not currently active; using default kit instead." so why can i not choose kde-kit's master branch anymore in ego.conf? i've forced the master branch checkout by adding: @git -C /home/meta-repo/kits/kde-kit checkout origin/master || true into eix-sync.conf, however i wonder why these kind of hacks are necessary... thank you
  8. kits logic

    well yes, would be nice to have the possibility to choose between kde-plasma-release and kde-plasma-lts... however if it's too much fuss, just branch using kde-apps as reference instead of kde-desktop...
  9. kits logic

    i'm pretty sure they actually do it since one component release can be quite far away (in terms of time) from the other...
  10. kits logic

    what do you mean exactly with updating kde parts asynchronously? kde-apps/frameworks/plasma have different independent release schedules and gentoo adds new ebuild short after there is a release of any of the 3 components afaik...
  11. kits logic

    it would also be very cool to have an lts branch (like eg.18.08.3-lts-prime) which would install latest kde-apps-18.08.3 with kde-desktop-5.12.7 instead of kde-desktop-5.13.5 like 18.08.3-prime would do...
  12. kits logic

    well... none... :) if you ask me, i would better branch on kde-apps version instead of kde-desktop version and number it as follows: 17.08.3-prime which includes kde-apps-17.08.3 (due nov. 6) kde-desktop-5.10.5 (released) kde-framework-5.40 (due nov. 4) 17.12.3-prime which includes kde-apps-17.12.3 (due march 8) kde-desktop-5.11.5 (due jan. 2) kde-framework-5.whatever on march 8 18.04.3-prime which includes kde-apps-18.04.3 (due sometime in july) kde-desktop-5.12.6 (due june 20) kde-framework-5.whatever in july branching it on kde-desktop version would need to push kde-apps fixes releases to the branch, even more for a wider definition... doing it on kde-apps instead just have to push -r releases with security issues, again imho...
  13. kits logic

    thank you daniel for your explication, kde software compilation, how it's called today, consists of 3 components: kde-framework: with a monthly release schedule which may include both bugfixes and new features, since there are no minor versions, it may be snapshotted at any time kde-plasma: with frequent minor releases (for bugfixes) and a new major release every 5-6 months, since there usually are just 5 minor versions (except from lts releases), taking a snapshot when it reach a 5.x.5 version it would make an ideal point for a prime release kde-apps: with about monthly minor releases (for bugfixes) and a new major release every 4 months, here too since there are just 3 minor versions, taking a snapshot every yy.mm.3 version would be a good point for a stable prime release imho a prime snapshot should be taken whenever we have a yy.mm.3 kde-apps release and it should include whatever 5.x.5 kde-plasma version it's available at that time if prime snapshots are meant to be (almost) static. else if snapshots would allow minor changes it would be nice to have for example a 5.12.x lts prime snapshot where bugfixes are pushed when released upstream and (if sub-kits would exist) kde-apps snapshots could be pulled and installed on top of it... i also notice that dev-qt stuff was added to the kde-kit, i'm not sure if that's a good idea since there are other desktop environments in the desktop-kit that depends on qt5 like lxqt and lumina, but mostly because making a certain kde release dependant from a concrete qt5 release can complicate the snapshotting even more in case of (security) bugfixes that only qt can deliver, so a separate qt-kit would make more sense... of course imho... ;) thank you
  14. kits logic

    so in my kde-kit example shall i expect a new, let's say, 5.10-prime-r1 branch with kde-apps-17.08.2 or will it only (kde-apps-17.08.2) be available into the new 5.11-prime branch? if the latter it would be very unfortunate for someone wanting to stay stable (keep on plasma 5.10 while getting apps 17.08 bugfixes)... thank you
  15. kits logic

    hello devs (oleg) :) i wonder what are the rules behind this new kit organization... do packages from the master branch eventually make into a prime branch or are prime branches virtually immutable? if the former, after lying into the the master branch for some time (like gentoo's stable/unstable)? how long? any other criterion instead? if the latter, are "stable users" supposed to jump from prime-n to prime-n+1 branches at their discretion? for example i'm on the default 5.10-prime kde-kit's branch and i see that kde-plasma-5.11.0, kde-frameworks-5.39 and kde-apps-17.08.2 were added to the master branch. i expect at least kde-apps-17.08.2 to make into the 5.10-prime branch since it's a bug fix release, while kde-plasma-5.11.0 to be sometimes added to a new default 5.11-prime branch since it's a major release, not sure about frameworks-5.39 but i consider it pretty safe to include it into 5.10-prime after reaching master for some time... so just curious to know how this new kit organization method works and what's its internal rules :) thank you