Jump to content
funtoo forums

skunk

Members
  • Content Count

    27
  • Joined

  • Last visited

About skunk

  • Rank
    Member

Personal

  • Location
    granada

Recent Profile Visitors

439 profile views
  1. skunk

    fastpull server is not fast in Spain

    While setting an empty GENTOO_MIRRORS makes portage use gentoo's mirrors with way better network performance, you may now either miss some package or size/sum mismatch any other... After some tests I've found out that: sometimes the download speed is as slow as 56kbps when this happens downloads from remote networks are still decently speedy (tried from data centers in the US and EU) running local speedtest with other servers in Santa Fe (where the fastpull server is located) don't show the same slow down I live in Granada and I think my ISP (Movistar/Telefonica) is to blame since I'm suffering also interruptions with Netflix...
  2. https://bugs.funtoo.org/browse/FL-5140
  3. 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.
  4. skunk

    chromium 65

    https://bugs.funtoo.org/browse/FL-4888
  5. skunk

    chromium 65

    hello, any chance to get safe chromium ebuild to the tree? thank you
  6. skunk

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

    kit's master branches

    nevermind it doesn't work the way i've thought, i've created my own overlay instead...
  8. skunk

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

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

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

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

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

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

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

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