Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 06/11/2020 in all areas

  1. 3 points
    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.)
  2. 2 points
    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.
  3. 1 point
    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. 1 point
    cardinal

    gimp failed to start

    File an issue report at bugs.funtoo.org rj@funtoo ~ $ gimp (gimp:14880): GLib-GObject-CRITICAL **: 10:19:51.172: g_param_spec_internal: assertion 'is_valid_property_name (name)' failed gimp: fatal error: Segmentation fault (gimp-org-pagecurl:14912): LibGimpBase-WARNING **: 10:19:51.227: gimp-org-pagecurl: gimp_wire_read(): error Always try to start a program in terminal when it fails by clicking shortcut in start menu. The error message enabled me to find the closed upstream bug report and a temporary workaround. https://gitlab.gnome.org/GNOME/gimp/-/issues/4392
  5. 1 point
    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.
  6. 1 point
    drobbins

    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
×
×
  • Create New...