Jump to content

drobbins

Funtoo Linux BDFL
  • Content Count

    426
  • Joined

  • Last visited

  • Days Won

    202

Reputation Activity

  1. Great Post
    drobbins got a reaction from eyesee in Funtoo Linux 1.4 MR 5 stages available   
    Funtoo Linux stages have been updated to contain the latest stuff in Funtoo: GNOME 3.36.2, latest Mesa/GL stack, support for Intel Iris graphics ("epro mix-in -gfxcard-intel +gfxcard-intel-iris; emerge -auDN @world for those who want to try), and many other updates.
    Download here: https://www.funtoo.org/Subarches
    Install docs here: https://www.funtoo.org/Install
    Enjoy!
  2. Great Post
    drobbins got a reaction from will1942 in Funtoo Linux 1.4 MR 5 stages available   
    Funtoo Linux stages have been updated to contain the latest stuff in Funtoo: GNOME 3.36.2, latest Mesa/GL stack, support for Intel Iris graphics ("epro mix-in -gfxcard-intel +gfxcard-intel-iris; emerge -auDN @world for those who want to try), and many other updates.
    Download here: https://www.funtoo.org/Subarches
    Install docs here: https://www.funtoo.org/Install
    Enjoy!
  3. Great Post
    drobbins got a reaction from AdiosKid in Funtoo Linux 1.4 MR 5 stages available   
    Funtoo Linux stages have been updated to contain the latest stuff in Funtoo: GNOME 3.36.2, latest Mesa/GL stack, support for Intel Iris graphics ("epro mix-in -gfxcard-intel +gfxcard-intel-iris; emerge -auDN @world for those who want to try), and many other updates.
    Download here: https://www.funtoo.org/Subarches
    Install docs here: https://www.funtoo.org/Install
    Enjoy!
  4. Great Post
    drobbins got a reaction from windceltic in Core-gl-kit updated to 2.0-release (default)   
    Just going to follow up with some more info.
    First, thanks to pross for pointing out I had a typo in the 'epro' command above, now fixed! 🙂
    The difference between Intel Iris and 'classic' Intel is that 'classic' Intel uses the xf86-video-intel driver (with ebuild of same name), which has classically been the way you get accelerated video with Intel Integrated graphics.
    The Iris graphics uses the more generic 'modesetting' driver (no special ebuild for this), and uses a gallium-based driver which is now a part of media-libs/mesa so xf86-video-intel is not used at all.
    During testing I found that if you have xf86-video-intel installed, you *won't* get the Iris graphics. xf86-video-intel seems to have priority and will get initialized first. So if you are doing troubleshooting or not using the magic mix-ins, you'll want to make sure that xf86-video-intel is not installed if you want to use Iris. The way to check what driver is being used -- the definitive way -- is to look at /var/log/Xorg.0.log and search for 'modesetting' and 'intel' and determine which if any are initialized. In some circumstances, you may see references to both so you need to look very carefully at the end to see which one is active.
    Now, about the mix-ins themselves which handle all the complication for you, so you just set the right one and don't have to tweak everything by hand. The gfxcard-intel (gfxcard-intel-classic) and gfxcard-intel-iris mix-ins do the 'magic' for you -- gfxcard-intel-iris will MASK xf86-video-intel, and enable video_cards_gallium-iris, which along with a dep in xorg-drivers will BLOCK xf86-video-intel from being installed (forcing it to be uninstalled.) Thus, the "magic" that gets your system in the proper state for Iris. The mix-ins live in /var/git/meta-repo/kits/core-gl-kit/profiles/funtoo/mix-ins if you want to look at their exact settings. You will see there also associated USE flags associated with each mix-in that are passed to the mesa ebuild which are different for the classic and Iris configuration.
  5. Great Post
    drobbins got a reaction from windceltic in Core-gl-kit updated to 2.0-release (default)   
    Hi All,
    core-gl-kit is now on 2.0-release by default. You will see updates to many packages.
    Now available are Intel Iris graphics, which is much faster and supported on modern Intel integrated graphics chipsets.
    To use Intel Iris, perform the following steps:
    # epro mix-ins -gfxcard-intel +gfxcard-intel-iris # emerge -auDN @world --jobs=3 If you want to continue with the classic drivers, or are not using Intel integrated graphics at all, you can just do the world update to get updates.
    Please report any issues you encounter to bugs.funtoo.org! There have been major updates to packages so I am expecting some bugs (and some have already been reported and fixed.)
  6. Great Post
    drobbins got a reaction from AdiosKid in Core-gl-kit updated to 2.0-release (default)   
    Just going to follow up with some more info.
    First, thanks to pross for pointing out I had a typo in the 'epro' command above, now fixed! 🙂
    The difference between Intel Iris and 'classic' Intel is that 'classic' Intel uses the xf86-video-intel driver (with ebuild of same name), which has classically been the way you get accelerated video with Intel Integrated graphics.
    The Iris graphics uses the more generic 'modesetting' driver (no special ebuild for this), and uses a gallium-based driver which is now a part of media-libs/mesa so xf86-video-intel is not used at all.
    During testing I found that if you have xf86-video-intel installed, you *won't* get the Iris graphics. xf86-video-intel seems to have priority and will get initialized first. So if you are doing troubleshooting or not using the magic mix-ins, you'll want to make sure that xf86-video-intel is not installed if you want to use Iris. The way to check what driver is being used -- the definitive way -- is to look at /var/log/Xorg.0.log and search for 'modesetting' and 'intel' and determine which if any are initialized. In some circumstances, you may see references to both so you need to look very carefully at the end to see which one is active.
    Now, about the mix-ins themselves which handle all the complication for you, so you just set the right one and don't have to tweak everything by hand. The gfxcard-intel (gfxcard-intel-classic) and gfxcard-intel-iris mix-ins do the 'magic' for you -- gfxcard-intel-iris will MASK xf86-video-intel, and enable video_cards_gallium-iris, which along with a dep in xorg-drivers will BLOCK xf86-video-intel from being installed (forcing it to be uninstalled.) Thus, the "magic" that gets your system in the proper state for Iris. The mix-ins live in /var/git/meta-repo/kits/core-gl-kit/profiles/funtoo/mix-ins if you want to look at their exact settings. You will see there also associated USE flags associated with each mix-in that are passed to the mesa ebuild which are different for the classic and Iris configuration.
  7. Great Post
    drobbins got a reaction from AdiosKid in Core-gl-kit updated to 2.0-release (default)   
    Hi All,
    core-gl-kit is now on 2.0-release by default. You will see updates to many packages.
    Now available are Intel Iris graphics, which is much faster and supported on modern Intel integrated graphics chipsets.
    To use Intel Iris, perform the following steps:
    # epro mix-ins -gfxcard-intel +gfxcard-intel-iris # emerge -auDN @world --jobs=3 If you want to continue with the classic drivers, or are not using Intel integrated graphics at all, you can just do the world update to get updates.
    Please report any issues you encounter to bugs.funtoo.org! There have been major updates to packages so I am expecting some bugs (and some have already been reported and fixed.)
  8. Great Post
    drobbins got a reaction from klipkyle in Core-gl-kit updated to 2.0-release (default)   
    Hi All,
    core-gl-kit is now on 2.0-release by default. You will see updates to many packages.
    Now available are Intel Iris graphics, which is much faster and supported on modern Intel integrated graphics chipsets.
    To use Intel Iris, perform the following steps:
    # epro mix-ins -gfxcard-intel +gfxcard-intel-iris # emerge -auDN @world --jobs=3 If you want to continue with the classic drivers, or are not using Intel integrated graphics at all, you can just do the world update to get updates.
    Please report any issues you encounter to bugs.funtoo.org! There have been major updates to packages so I am expecting some bugs (and some have already been reported and fixed.)
  9. Great Post
    drobbins got a reaction from d4g33z in Updated Python Eclasses and Autogen   
    Hi All,
    To get ready for future improvements to Funtoo, I am adopting a multi-phased approach to 'fix Python'. First step is to address some issues that exist in the Gentoo python eclasses. I've updated these eclasses to be at least somewhat better than they are in Gentoo. These changes will be hitting the tree in an hour or so. For new ebuilds, you can now use the following rather than enumerating every single version of Python:
    PYTHON_COMPAT=( python3+ ) Because the minimum version of python3 we support is 3.7, this will ensure that the ebuild will be marked compatible with 3.7 and later versions of Python. Using the '+' symbol is the preferred way to mark ebuilds using PYTHON_COMPAT because it eliminates the time-consuming process used in Gentoo of tagging every single python-using ebuild when a new version of Python comes out. I don't know how they deal with this but it is a lot of wasted energy.
    Also supported in the new eclasses are the following:
    PYTHON_COMPAT=( python2+ ) # python2_7, python3_7, and beyond PYTHON_COMPAT=( python3_7+ ) # same as python3+ since we start counting at 3_7 PYTHON_COMPAT=( python3_8+ ) # should be self-explanatory... PYTHON_COMPAT=( python3_9+ ) Note that pypy and pypy3 still need to be manually specified, and it is fine to combine as in the usual way:
    PYTHON_COMPAT=( python3+ pypy3 ) And another important change I made to the eclass is that any ebuilds still referencing python3_5 or python3_6 will be 'auto-upgraded' to python3_7 compatibility with no user intervention. So this could close a whole slew of bugs. I'm also enabling eclass support for the upcoming Python 3.9.
    IMPORTANT FOR ALL USERS: These changes will result in all of your Python-based and Python-using packages being rebuilt. This rebuild is for cosmetic purposes only -- it's due to a weirdness in emerge and the eclasses -- and really is optional and doesn't actually result in any changes except changes to the /var/db/pkg database USE flags. Therefore, these rebuilds can be completed at your convenience as they are not important. More adventurous users may look for ways to write a script to update /var/db/pkg so that these rebuilds are unnecessary -- if you attempt this, please back up /var/db/pkg first and read the following technical note!
    TECHNICAL NOTE: Due to how Gentoo implemented the python eclasses, our deprecation of python3_5 and python3_6 in PYTHON_TARGETS will result in some ebuilds going from 'PYTHON_SINGLE_TARGET' mode to just regular 'PYTHON_TARGET' mode. What you will see is that some ebuilds will be turning off python_single_target_python3_7. This is OK. This is just how the eclasses were written by Gentoo -- PYTHON_SINGLE_TARGET is only enabled when there is more than one active implementation of Python in PYTHON_COMPAT. Otherwise it just falls back to using PYTHON_TARGETS.
    On another note, our continued use of auto-generation continues to go well with many more packages now in the tree that are auto-generated. Expect this direction to continue.
    Best,
    Daniel
  10. Great Post
    drobbins got a reaction from raker in GNOME 3.36.2, latest OpenSSL, latest Docker stack   
    Hi all,
    GNOME 3.36.2 has hit the tree, as well as an OpenSSL update and updates to Docker. To update, perform the following:
    # ego sync # emerge -auDN @world --jobs=3 # emerge @preserved-rebuild While GNOME is upgrading, apps may not launch. This is normal. After upgrading GNOME, a reboot is recommended to flush out all older GNOME processes and start up a GNOME 3.36.2 environment.
  11. Great Post
    drobbins got a reaction from eyesee in Updated Python Eclasses and Autogen   
    Hi All,
    To get ready for future improvements to Funtoo, I am adopting a multi-phased approach to 'fix Python'. First step is to address some issues that exist in the Gentoo python eclasses. I've updated these eclasses to be at least somewhat better than they are in Gentoo. These changes will be hitting the tree in an hour or so. For new ebuilds, you can now use the following rather than enumerating every single version of Python:
    PYTHON_COMPAT=( python3+ ) Because the minimum version of python3 we support is 3.7, this will ensure that the ebuild will be marked compatible with 3.7 and later versions of Python. Using the '+' symbol is the preferred way to mark ebuilds using PYTHON_COMPAT because it eliminates the time-consuming process used in Gentoo of tagging every single python-using ebuild when a new version of Python comes out. I don't know how they deal with this but it is a lot of wasted energy.
    Also supported in the new eclasses are the following:
    PYTHON_COMPAT=( python2+ ) # python2_7, python3_7, and beyond PYTHON_COMPAT=( python3_7+ ) # same as python3+ since we start counting at 3_7 PYTHON_COMPAT=( python3_8+ ) # should be self-explanatory... PYTHON_COMPAT=( python3_9+ ) Note that pypy and pypy3 still need to be manually specified, and it is fine to combine as in the usual way:
    PYTHON_COMPAT=( python3+ pypy3 ) And another important change I made to the eclass is that any ebuilds still referencing python3_5 or python3_6 will be 'auto-upgraded' to python3_7 compatibility with no user intervention. So this could close a whole slew of bugs. I'm also enabling eclass support for the upcoming Python 3.9.
    IMPORTANT FOR ALL USERS: These changes will result in all of your Python-based and Python-using packages being rebuilt. This rebuild is for cosmetic purposes only -- it's due to a weirdness in emerge and the eclasses -- and really is optional and doesn't actually result in any changes except changes to the /var/db/pkg database USE flags. Therefore, these rebuilds can be completed at your convenience as they are not important. More adventurous users may look for ways to write a script to update /var/db/pkg so that these rebuilds are unnecessary -- if you attempt this, please back up /var/db/pkg first and read the following technical note!
    TECHNICAL NOTE: Due to how Gentoo implemented the python eclasses, our deprecation of python3_5 and python3_6 in PYTHON_TARGETS will result in some ebuilds going from 'PYTHON_SINGLE_TARGET' mode to just regular 'PYTHON_TARGET' mode. What you will see is that some ebuilds will be turning off python_single_target_python3_7. This is OK. This is just how the eclasses were written by Gentoo -- PYTHON_SINGLE_TARGET is only enabled when there is more than one active implementation of Python in PYTHON_COMPAT. Otherwise it just falls back to using PYTHON_TARGETS.
    On another note, our continued use of auto-generation continues to go well with many more packages now in the tree that are auto-generated. Expect this direction to continue.
    Best,
    Daniel
  12. Great Post
    drobbins got a reaction from AdiosKid in Intel Iris Graphics Ready for Testing (core-gl-kit 2.0-release)   
    Hi All,
    If you are interested in testing Intel Iris graphics (new accelerated graphics for newer Intel chipsets), here's how you do it:
    First, make sure your system is up-to-date and you have the latest available version of ego installed (2.8.1)
    Next, add the following to /etc/ego.conf:
    [kits] core-gl-kit = 2.0-release xorg-kit = skip This will result in our 2.0-release core-gl-kit being activated, which completely replaces xorg-kit, as all of xorg has been integrated into core-gl-kit 2.0-release.
    We do not have a mix-in yet for intel Iris graphics. For now, set the following in /etc/make.conf:
    VIDEO_CARDS="$VIDEO_CARDS intel gallium-iris vulkan-intel xa xvmc vdpau" Now:
    # emerge -auDN @world *Unmerge* xf86-video-intel:
    # emerge -C xf86-video-intel Now, restarting X should result in Intel Iris being active.
    General feedback can be posted to this Funtoo issue: https://bugs.funtoo.org/browse/FL-7195
    Specific failures can be reported in their own issues. Please be sure to report any problems including difficulty upgrading to core-gl-kit 2.0-release.
    Please note that 2.0-release core-gl-kit is BETA and I am actively working on redoing the xorg-server stack, so active development is going on in this kit branch.
     
  13. Great Post
    drobbins got a reaction from AdiosKid in GNOME 3.36.2, latest OpenSSL, latest Docker stack   
    Hi all,
    GNOME 3.36.2 has hit the tree, as well as an OpenSSL update and updates to Docker. To update, perform the following:
    # ego sync # emerge -auDN @world --jobs=3 # emerge @preserved-rebuild While GNOME is upgrading, apps may not launch. This is normal. After upgrading GNOME, a reboot is recommended to flush out all older GNOME processes and start up a GNOME 3.36.2 environment.
  14. Great Post
    drobbins got a reaction from dutch-master in * Error: circular dependencies   
    I've already found the issue and resolved it. 🙂 Fix should be in the tree on next regen, in about 25 minutes.
  15. Great Post
    drobbins got a reaction from Fran?ois in Updated Python Eclasses and Autogen   
    Hi All,
    To get ready for future improvements to Funtoo, I am adopting a multi-phased approach to 'fix Python'. First step is to address some issues that exist in the Gentoo python eclasses. I've updated these eclasses to be at least somewhat better than they are in Gentoo. These changes will be hitting the tree in an hour or so. For new ebuilds, you can now use the following rather than enumerating every single version of Python:
    PYTHON_COMPAT=( python3+ ) Because the minimum version of python3 we support is 3.7, this will ensure that the ebuild will be marked compatible with 3.7 and later versions of Python. Using the '+' symbol is the preferred way to mark ebuilds using PYTHON_COMPAT because it eliminates the time-consuming process used in Gentoo of tagging every single python-using ebuild when a new version of Python comes out. I don't know how they deal with this but it is a lot of wasted energy.
    Also supported in the new eclasses are the following:
    PYTHON_COMPAT=( python2+ ) # python2_7, python3_7, and beyond PYTHON_COMPAT=( python3_7+ ) # same as python3+ since we start counting at 3_7 PYTHON_COMPAT=( python3_8+ ) # should be self-explanatory... PYTHON_COMPAT=( python3_9+ ) Note that pypy and pypy3 still need to be manually specified, and it is fine to combine as in the usual way:
    PYTHON_COMPAT=( python3+ pypy3 ) And another important change I made to the eclass is that any ebuilds still referencing python3_5 or python3_6 will be 'auto-upgraded' to python3_7 compatibility with no user intervention. So this could close a whole slew of bugs. I'm also enabling eclass support for the upcoming Python 3.9.
    IMPORTANT FOR ALL USERS: These changes will result in all of your Python-based and Python-using packages being rebuilt. This rebuild is for cosmetic purposes only -- it's due to a weirdness in emerge and the eclasses -- and really is optional and doesn't actually result in any changes except changes to the /var/db/pkg database USE flags. Therefore, these rebuilds can be completed at your convenience as they are not important. More adventurous users may look for ways to write a script to update /var/db/pkg so that these rebuilds are unnecessary -- if you attempt this, please back up /var/db/pkg first and read the following technical note!
    TECHNICAL NOTE: Due to how Gentoo implemented the python eclasses, our deprecation of python3_5 and python3_6 in PYTHON_TARGETS will result in some ebuilds going from 'PYTHON_SINGLE_TARGET' mode to just regular 'PYTHON_TARGET' mode. What you will see is that some ebuilds will be turning off python_single_target_python3_7. This is OK. This is just how the eclasses were written by Gentoo -- PYTHON_SINGLE_TARGET is only enabled when there is more than one active implementation of Python in PYTHON_COMPAT. Otherwise it just falls back to using PYTHON_TARGETS.
    On another note, our continued use of auto-generation continues to go well with many more packages now in the tree that are auto-generated. Expect this direction to continue.
    Best,
    Daniel
  16. Great Post
    drobbins got a reaction from AdiosKid in Funtoo Linux 1.4 MR 4 stages now available   
    Everyone,
    New 1.4 Maintenance Release 4 stages have been built. These include GNOME 3.34.5 as well as updated Firefox and other packages. As we continue to expand the use of our autogen framework (metatools) , more and more desktop packages are staying up-to-date automatically. Enjoy the new builds -- they are now available for download via www.funtoo.org and our CDN77-powered CDN.
    Best,
    Daniel
  17. Great Post
    drobbins got a reaction from klipkyle in Funtoo Linux 1.4 MR 4 stages now available   
    Everyone,
    New 1.4 Maintenance Release 4 stages have been built. These include GNOME 3.34.5 as well as updated Firefox and other packages. As we continue to expand the use of our autogen framework (metatools) , more and more desktop packages are staying up-to-date automatically. Enjoy the new builds -- they are now available for download via www.funtoo.org and our CDN77-powered CDN.
    Best,
    Daniel
  18. Great Post
    drobbins got a reaction from minzord in Funtoo Linux 1.4 MR 4 stages now available   
    Everyone,
    New 1.4 Maintenance Release 4 stages have been built. These include GNOME 3.34.5 as well as updated Firefox and other packages. As we continue to expand the use of our autogen framework (metatools) , more and more desktop packages are staying up-to-date automatically. Enjoy the new builds -- they are now available for download via www.funtoo.org and our CDN77-powered CDN.
    Best,
    Daniel
  19. Haha
    drobbins reacted to rage in funtoo logo ideas   
    I had two new ideas for this,
    1) Fortissimo symbol

     
    This one is a bit of a math joke- funfun (fun x 2); which is expressed by the above symbol..
    2) Something involving an exclamation point!
    Funtoo is fun and exciting! So it only makes sense that the logo includes a symbol that depicts the same energy.
     
  20. Great Post
    drobbins got a reaction from s4uliu5 in Updated Python Eclasses and Autogen   
    Hi All,
    To get ready for future improvements to Funtoo, I am adopting a multi-phased approach to 'fix Python'. First step is to address some issues that exist in the Gentoo python eclasses. I've updated these eclasses to be at least somewhat better than they are in Gentoo. These changes will be hitting the tree in an hour or so. For new ebuilds, you can now use the following rather than enumerating every single version of Python:
    PYTHON_COMPAT=( python3+ ) Because the minimum version of python3 we support is 3.7, this will ensure that the ebuild will be marked compatible with 3.7 and later versions of Python. Using the '+' symbol is the preferred way to mark ebuilds using PYTHON_COMPAT because it eliminates the time-consuming process used in Gentoo of tagging every single python-using ebuild when a new version of Python comes out. I don't know how they deal with this but it is a lot of wasted energy.
    Also supported in the new eclasses are the following:
    PYTHON_COMPAT=( python2+ ) # python2_7, python3_7, and beyond PYTHON_COMPAT=( python3_7+ ) # same as python3+ since we start counting at 3_7 PYTHON_COMPAT=( python3_8+ ) # should be self-explanatory... PYTHON_COMPAT=( python3_9+ ) Note that pypy and pypy3 still need to be manually specified, and it is fine to combine as in the usual way:
    PYTHON_COMPAT=( python3+ pypy3 ) And another important change I made to the eclass is that any ebuilds still referencing python3_5 or python3_6 will be 'auto-upgraded' to python3_7 compatibility with no user intervention. So this could close a whole slew of bugs. I'm also enabling eclass support for the upcoming Python 3.9.
    IMPORTANT FOR ALL USERS: These changes will result in all of your Python-based and Python-using packages being rebuilt. This rebuild is for cosmetic purposes only -- it's due to a weirdness in emerge and the eclasses -- and really is optional and doesn't actually result in any changes except changes to the /var/db/pkg database USE flags. Therefore, these rebuilds can be completed at your convenience as they are not important. More adventurous users may look for ways to write a script to update /var/db/pkg so that these rebuilds are unnecessary -- if you attempt this, please back up /var/db/pkg first and read the following technical note!
    TECHNICAL NOTE: Due to how Gentoo implemented the python eclasses, our deprecation of python3_5 and python3_6 in PYTHON_TARGETS will result in some ebuilds going from 'PYTHON_SINGLE_TARGET' mode to just regular 'PYTHON_TARGET' mode. What you will see is that some ebuilds will be turning off python_single_target_python3_7. This is OK. This is just how the eclasses were written by Gentoo -- PYTHON_SINGLE_TARGET is only enabled when there is more than one active implementation of Python in PYTHON_COMPAT. Otherwise it just falls back to using PYTHON_TARGETS.
    On another note, our continued use of auto-generation continues to go well with many more packages now in the tree that are auto-generated. Expect this direction to continue.
    Best,
    Daniel
  21. Great Post
    drobbins got a reaction from AdiosKid in Updated Python Eclasses and Autogen   
    Hi All,
    To get ready for future improvements to Funtoo, I am adopting a multi-phased approach to 'fix Python'. First step is to address some issues that exist in the Gentoo python eclasses. I've updated these eclasses to be at least somewhat better than they are in Gentoo. These changes will be hitting the tree in an hour or so. For new ebuilds, you can now use the following rather than enumerating every single version of Python:
    PYTHON_COMPAT=( python3+ ) Because the minimum version of python3 we support is 3.7, this will ensure that the ebuild will be marked compatible with 3.7 and later versions of Python. Using the '+' symbol is the preferred way to mark ebuilds using PYTHON_COMPAT because it eliminates the time-consuming process used in Gentoo of tagging every single python-using ebuild when a new version of Python comes out. I don't know how they deal with this but it is a lot of wasted energy.
    Also supported in the new eclasses are the following:
    PYTHON_COMPAT=( python2+ ) # python2_7, python3_7, and beyond PYTHON_COMPAT=( python3_7+ ) # same as python3+ since we start counting at 3_7 PYTHON_COMPAT=( python3_8+ ) # should be self-explanatory... PYTHON_COMPAT=( python3_9+ ) Note that pypy and pypy3 still need to be manually specified, and it is fine to combine as in the usual way:
    PYTHON_COMPAT=( python3+ pypy3 ) And another important change I made to the eclass is that any ebuilds still referencing python3_5 or python3_6 will be 'auto-upgraded' to python3_7 compatibility with no user intervention. So this could close a whole slew of bugs. I'm also enabling eclass support for the upcoming Python 3.9.
    IMPORTANT FOR ALL USERS: These changes will result in all of your Python-based and Python-using packages being rebuilt. This rebuild is for cosmetic purposes only -- it's due to a weirdness in emerge and the eclasses -- and really is optional and doesn't actually result in any changes except changes to the /var/db/pkg database USE flags. Therefore, these rebuilds can be completed at your convenience as they are not important. More adventurous users may look for ways to write a script to update /var/db/pkg so that these rebuilds are unnecessary -- if you attempt this, please back up /var/db/pkg first and read the following technical note!
    TECHNICAL NOTE: Due to how Gentoo implemented the python eclasses, our deprecation of python3_5 and python3_6 in PYTHON_TARGETS will result in some ebuilds going from 'PYTHON_SINGLE_TARGET' mode to just regular 'PYTHON_TARGET' mode. What you will see is that some ebuilds will be turning off python_single_target_python3_7. This is OK. This is just how the eclasses were written by Gentoo -- PYTHON_SINGLE_TARGET is only enabled when there is more than one active implementation of Python in PYTHON_COMPAT. Otherwise it just falls back to using PYTHON_TARGETS.
    On another note, our continued use of auto-generation continues to go well with many more packages now in the tree that are auto-generated. Expect this direction to continue.
    Best,
    Daniel
  22. Great Post
    drobbins got a reaction from Metal in Auto-updated ebuilds: Zoom-bin, google-chrome and others   
    Greetings during unusual times --
    I wanted to let everyone know that the following ebuilds are currently being auto-updated using our new, amazing autogen framework. That means we will always have current versions:
    www-client/firefox-bin www-client/google-chrome www-client/google-chrome-beta www-client/google-chrome-unstable www-client/brave-bin app-admin/pass app-admin/passwordsafe net-misc/anydesk-bin mail-client/thunderbird-bin net-im/discord-bin net-im/zoom-bin net-im/slack-bin More are on the way! For those working remotely, I recommend checking out zoom-bin (Zoom meetings) as well as anydesk-bin (AnyDesk) for fast remote desktop. They work great under Funtoo.
    Enjoy, and stay safe.
    -Daniel
  23. Great Post
    drobbins got a reaction from nrc in Auto-updated ebuilds: Zoom-bin, google-chrome and others   
    Greetings during unusual times --
    I wanted to let everyone know that the following ebuilds are currently being auto-updated using our new, amazing autogen framework. That means we will always have current versions:
    www-client/firefox-bin www-client/google-chrome www-client/google-chrome-beta www-client/google-chrome-unstable www-client/brave-bin app-admin/pass app-admin/passwordsafe net-misc/anydesk-bin mail-client/thunderbird-bin net-im/discord-bin net-im/zoom-bin net-im/slack-bin More are on the way! For those working remotely, I recommend checking out zoom-bin (Zoom meetings) as well as anydesk-bin (AnyDesk) for fast remote desktop. They work great under Funtoo.
    Enjoy, and stay safe.
    -Daniel
  24. Great Post
    drobbins got a reaction from lycaeum in Auto-updated ebuilds: Zoom-bin, google-chrome and others   
    Greetings during unusual times --
    I wanted to let everyone know that the following ebuilds are currently being auto-updated using our new, amazing autogen framework. That means we will always have current versions:
    www-client/firefox-bin www-client/google-chrome www-client/google-chrome-beta www-client/google-chrome-unstable www-client/brave-bin app-admin/pass app-admin/passwordsafe net-misc/anydesk-bin mail-client/thunderbird-bin net-im/discord-bin net-im/zoom-bin net-im/slack-bin More are on the way! For those working remotely, I recommend checking out zoom-bin (Zoom meetings) as well as anydesk-bin (AnyDesk) for fast remote desktop. They work great under Funtoo.
    Enjoy, and stay safe.
    -Daniel
  25. Great Post
    drobbins got a reaction from tux in Auto-updated ebuilds: Zoom-bin, google-chrome and others   
    Greetings during unusual times --
    I wanted to let everyone know that the following ebuilds are currently being auto-updated using our new, amazing autogen framework. That means we will always have current versions:
    www-client/firefox-bin www-client/google-chrome www-client/google-chrome-beta www-client/google-chrome-unstable www-client/brave-bin app-admin/pass app-admin/passwordsafe net-misc/anydesk-bin mail-client/thunderbird-bin net-im/discord-bin net-im/zoom-bin net-im/slack-bin More are on the way! For those working remotely, I recommend checking out zoom-bin (Zoom meetings) as well as anydesk-bin (AnyDesk) for fast remote desktop. They work great under Funtoo.
    Enjoy, and stay safe.
    -Daniel
×
×
  • Create New...