Jump to content

drobbins

Funtoo Linux BDFL
  • Content Count

    426
  • Joined

  • Last visited

  • Days Won

    201

drobbins last won the day on July 14

drobbins had the most liked content!

About drobbins

  • Rank
    Administrator

Online

Personal

  • Location
    Albuquerque, NM, USA
  • Interests
    Cycling, Cars, Motorcycle.... Funtoo :)

Recent Profile Visitors

5,967 profile views
  1. 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. If this is still a current issue, it should be reported to the bug tracker, not the forums.
  3. 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.
  4. 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.)
  5. Please report bugs as needed. Also, yes, currently xf86-video-intel will keep getting pulled in if you have the mix-in for it enabled. You can either disable this mix-in or emerge --exclude xf86-video-intel for now.
  6. 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.
  7. I've already found the issue and resolved it. 🙂 Fix should be in the tree on next regen, in about 25 minutes.
  8. 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.
  9. This may be a bug -- can you report to bugs.funtoo.org? It probably doesn't affect users who already have an old GNOME installed but may affect new merges.
  10. @mrl5 sorry I missed this thread, but you should always report bugs to bugs.funtoo.org and we will take it upstream as needed.
  11. And just a note, there have been improvements to Funtoo's python eclasses which should have fixed a lot of bugs related to python3.7 compatibility missing from our ebuilds. This happened in the last week. Our snapshot of Gentoo was taken at a time when Gentoo was not really converted over to 3.7 yet, and this is reflected in the state of the ebuilds in the Funtoo tree. While we have made fixes here and there, the recent Funtoo enhancements I made to the eclasses basically fix this throughout the whole Funtoo tree and also make python ebuilds more maintainable and auto-gennable on Funtoo going forward. So just wanted to let everyone know that we have had major improvements here, and these are just the initial steps. We plan to be ahead of Gentoo in regards to Python support very soon.
  12. I or someone else will be looking into this dnsmasq failure very soon. I know it merges fine with some combinations of USE vars at the moment since I use this ebuild often.
  13. If there is interest we can add this as a kit to Funtoo. The first step would be to have it working in an overlay and have people who will be testing it and maintaining it. I can easily convert a working overlay to be a kit in funtoo, @zogg @morphmex
  14. 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
  15. 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
×
×
  • Create New...