Jump to content
funtoo forums


  • Content count

  • Joined

  • Last visited

About skunk

  • Rank


  • Location

Recent Profile Visitors

337 profile views
  1. https://bugs.funtoo.org/browse/FL-5140
  2. i don't know if it's wise to get rid of gcc-6.4.0 that fast since the most recent versions of cuda sdk/toolkit still depends on it as gcc versions later than 6 are not supported. however i can confirm that forcing compilation of cuda depending applications (like net-p2p/xmr-stak or app-crypt/johntheripper) by replacing "#if __GNUC__ > 6" with "#if __GNUC__ > 7" on /opt/cuda/include/crt/host_config.h:119, didn't give me any compilation or runtime problem so far... so please either leave gcc 6 ebuild alone or patch dev-util/nvidia-cuda-toolkit to ignore upstream unsupported gcc 7, thank you.
  3. chromium 65

  4. chromium 65

    hello, any chance to get safe chromium ebuild to the tree? thank you
  5. 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"
  6. kit's master branches

    nevermind it doesn't work the way i've thought, i've created my own overlay instead...
  7. 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
  8. 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...
  9. 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
  10. 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...
  11. 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...
  12. 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...
  13. 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...
  14. 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...
  15. 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