Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by jhan

  1. I solved these problems by making myself an ebuild for a newer version of libreoffice-bin. Have updated it lately to libreoffice If you like you can find the ebuilds for it at: https://code.funtoo.org/bitbucket/users/jhan/repos/local-stuff/browse/app-office That is for libreoffice-bin and libreoffice-l10n. The ebuild works fine for me during my daily use. Feel free to test it. There might be some dependencies that need to be updated for funtoo 1.4 as well.
  2. This is an error that somehow got introduced into the funtoo system. So far there seems to be no solution but a workaround exists. See this bug for details.
  3. Ah, the full error messages helps. You need to add the line RESTRICT="network-sandbox" to the ebuild for it to work.
  4. I think the correct URL would be: https://github.com/Mange/rtl8192eu-linux-driver.git EGIT_REPO_URI (REQUIRED) URIs to the repository, e.g. https://foo. If multiple URIs are provided, the eclass will consider the remaining URIs as fallbacks to try if the first URI does not work. For supported URI syntaxes, read the manpage for git-clone(1). URIs should be using https:// whenever possible. http:// and git:// URIs are completely unsecured and their use (even if only as a fallback) renders the ebuild completely vulnerable to MITM attacks. Can be a whitespace-separated list or an array. Example: EGIT_REPO_URI="https://a/b.git https://c/d.git"
  5. I would do like the message suggests and check if the packages net-libs/gssdp net-libs/gupnp are installed. They are required for gupnp-idg
  6. OK, it seems the problem is a config script with pango that has hardcoded include paths: https://github.com/eiskaltdcpp/eiskaltdcpp/issues/413 https://gitlab.gnome.org/GNOME/pango/issues/387 After some tests there seem to be two solutions: - Patching the include path for kde-gtk-config to also include /usr/include/harfbuzz/ - Updating to kde-gtk-config-5.17.4 which does seem to have resolved that problem. But that would require to update most kde packages to 5.64.0 as well. Please open up a bug report at bug.funtoo.org with this information, so that the problem can get fixed one way or the other.
  7. Do you have media-libs/harfbuzz installed?
  8. The question is not if it can be fetched from the git repository but why you are getting that message. As there is no ebuild pango-9999 the problem is probably that some other ebuild is requesting a pango version that is higher than currently available in the tree. So, what did you try to emerge as you got that error and what does the build log say?
  9. Not if you emerge gimp with the USE flag '-python' pygtk is only required for gimp if you use python, as stated in the ebuild: python? ( ${PYTHON_DEPS} =dev-python/pygtk-2.10.4:2[${PYTHON_USEDEP}] =dev-python/pycairo-1.0.2[${PYTHON_USEDEP}] ) And to my knowledge you only loose the ability to use python based plugins. Everything else should work.
  10. A few more packages is still progress. And removing kde-plasma does not ensure success. But there are other ways you can try to get it working. Try equery d qtgui to see what other packages you have installed that depend on qtgui. Installing one of those might trick portage to update qtgui. You could also try uninstalling just kiconthemes. Or you can drop the parameter -D from emerge doing just a emerge -auN @world Probably some other things you can try (like installing single packages,...) but overall my experience is that working with a couple with those techniques is helpful. Always trying a world update in between to see if it works or not.
  11. I would try to update world first: emerge -auDN @world If that still wants to install kiconthemes before updating qtgui, try emerge -auDN @world --exclude kiconthemes Not sure if that won't lead to other conflicts but you can always play around with the exclude parameter (or multiple). Or try installing other packages first to reduce the number of updates needed.
  12. Look at line 101-102 in the log: ^[[01m^[[K/var/tmp/portage/kde-frameworks/kiconthemes-5.59.0/work/kiconthemes-5.59.0/src/kicontheme.cpp:^[[m^[[K In function ‘^[[01m^[[Kvoid setBreezeFallback()^[[m^[[K’: ^[[01m^[[K/var/tmp/portage/kde-frameworks/kiconthemes-5.59.0/work/kiconthemes-5.59.0/src/kicontheme.cpp:80:12:^[[m^[[K ^[[01;31m^[[Kerror: ^[[m^[[K‘^[[01m^[[KsetFallbackThemeName^[[m^[[K’ is not a member of ‘^[[01m^[[KQIcon^[[m^[[K’ or a bit clearer: /var/tmp/portage/kde-frameworks/kiconthemes-5.59.0/work/kiconthemes-5.59.0/src/kicontheme.cpp: In function void setBreezeFallback(): /var/tmp/portage/kde-frameworks/kiconthemes-5.59.0/work/kiconthemes-5.59.0/src/kicontheme.cpp:80:12: error: setFallbackThemeName is not a member of QIcon Which doesn't help much but points you in another direction. As QIcon seems to be provided by dev-qt/qtgui, this should be the next point to check. My successful test was with dev-qt/qtgui-5.12.3-r1. What version of qtgui do you have installed? As you migrated from funtoo 1.3, it could be that thus package is not yet upgraded.
  13. Those messages don't help either, as they are just warnings. They also appeared in the test install I did in a container just now, which completed successfully. The actual error has to be still higher up. And as the log file is not that large, it probably should be enough to provide the first part of it, if you can't find the error on your own.
  14. The message is only the final error. The real error is usually a bit higher up in the log file. Have a look and see if you can find another error.
  15. I would say that your are looking for the functionality of versionator.eclass or eapi7-ver.eclass. versionator.eclass can be found at https://code.funtoo.org/bitbucket/projects/AUTO/repos/gentoo-staging/browse/eclass/versionator.eclass eapi7-ver.eclass at https://code.funtoo.org/bitbucket/projects/AUTO/repos/gentoo-staging/browse/eclass/eapi7-ver.eclass
  16. I would say, looking at the code in the ebuild: REQUIRED_USE="?? ( elogind systemd )" CDEPEND=" >=dev-libs/glib-2.44:2 sys-auth/polkit elogind? ( >=sys-auth/elogind-229.4 ) introspection? ( >=dev-libs/gobject-introspection-0.9.12:= ) systemd? ( >=sys-apps/systemd-186:0= ) !systemd? ( !elogind? ( sys-auth/consolekit ) ) that it is more like that: - Either none or one of the required use USE flags need to be enabled but not both: https://devmanual.gentoo.org/ebuild-writing/variables/index.html#required_use - If USE flag systemd is set sys-apps/systemd is required - If USE flag elogind is set sys-auth/elogind is required - If systemd USE flag is not set and elogind USE flag is not set then sys-auth/consolekit is required So the question here is, why is the systemd USE flag triggered in the first place because the packages depending on accountservice sicota@farout /data/incoming $ equery d -a sys-apps/accountsservice * These packages depend on sys-apps/accountsservice: gnome-base/gdm-3.32.0 (>=sys-apps/accountsservice-0.6.12) gnome-base/gnome-control-center-3.32.2 (>=sys-apps/accountsservice-0.6.39) gnome-base/gnome-shell-3.32.2-r4 (>=sys-apps/accountsservice-0.6.14[introspection]) gnome-extra/cinnamon-desktop-3.6.2 (sys-apps/accountsservice) kde-plasma/user-manager-5.15.5 (sys-apps/accountsservice) kde-plasma/user-manager-5.16.1 (sys-apps/accountsservice) mate-base/mate-control-center-1.22.1 (accountsservice ? sys-apps/accountsservice) mate-extra/mate-polkit-1.22.0 (accountsservice ? sys-apps/accountsservice) mate-extra/mate-polkit-1.22.0-r1 (accountsservice ? sys-apps/accountsservice) x11-misc/lightdm-1.26.0-r1 (gnome ? sys-apps/accountsservice) x11-misc/lightdm-1.28.0 (gnome ? sys-apps/accountsservice) x11-misc/lightdm-1.30.0 (gnome ? sys-apps/accountsservice) x11-misc/mugshot-0.4.1 (sys-apps/accountsservice) sicota@farout /data/incoming $ do not require systemd to be set. And looking at the output of an emerge -pv kde-meta on my system the accountsservice line looks like: [ebuild N ] sys-apps/accountsservice-0.6.54-r1::gnome-kit USE="-doc -elogind -introspection (-selinux) (-systemd)" 91 KiB with systemd USE flag masked and elogind USE flag turned off. The mask for systemd is the default setting for the epro flavor "core" and also the mix-in no-systemd. To find out why the systemd USE flag is set we would need the output of: - epro - emerge -pv kde-meta
  17. That is interesting, as I see that field only in English, no matter which language I choose from the language menu.
  18. That can depend on many factors. Did you set PYTHON_SINGLE_TARGET or PYTHON_TARGETS somewhere? There are also some programs that still don't have the USE flag for python3_7 or just don't support it yet. But if your 'emerge -pv --depclean =dev-lang/python-3.6* ' output does not show more packages, that should not be the case.
  19. As plasma also has the wayland USE flag, I said it might be good to try to build the system without this USE flag first. To not have a "mixed state", where one part supports wayland and one not. As far as I know, wayland is not yet ready for "general use", there are too many things that don't work yet or still need the use of XWayland, depending on the desktop environment you want to use. Gnome seems to be working fine, KDE plasma e.g still has some problems (https://community.kde.org/Plasma/Wayland_Showstoppers) and no idea about the others. At the moment I wouldn't use it as my normal desktop, unless I have tested all applications under it first, probably on another computer. And if you say that Xorg+KDE seems to get stuck, how far does it get? How are you starting it? Any messages in the Xorg protocol or dmesg?
  20. The radeon driver is correct. The name of the driver is just radeon but it supports many different versions of similar cards: https://www.x.org/releases/current/doc/man/man4/radeon.4.xhtml
  21. If you can only start wayland but don't want or need it. You could etiher remove the wayland mix-in (which you inherited) or use the '-wayland' USE flag. That should at least give you you the possibility to to start plasma normally.
  22. That might be a good idea, as the VIDEO_CARDS setting in make.conf seems to have priority over the mix-ins setting. I tested that locally by adding the gfxcard-radeon mix-in but the USE flags for xorg-drivers and mesa only changed after I removed the VIDEO_CARDS line from make.conf. A 'emerge -pv mesa xorg-drivers' would probably enough to see if a rebuild would change anything.
  23. If you have set gfxcard-radeon as a mix-in, gallium-r600 is already set as VIDEO_CARDS: farout $ more /var/git/meta-repo/kits/core-kit/profiles/funtoo/1.0/linux-gnu/mix-ins/gfxcard-radeon/make.defaults # reference: # https://www.x.org/wiki/RadeonFeature/ # https://wiki.gentoo.org/wiki/Radeon # profile covers: r600 <= chipset <= N.Islands # GFX Core 4 and 5 VIDEO_CARDS="radeon r600 gallium-r600" USE="glamor vdpau vaapi" But so is radeon, which makes your mesa warning above look a bit suspicious but I see no profile setting that would disable it. Are you sure your local /etc/portage/ files don't accidentally contain anything that would disable it? And my guess for the r600g would be that that is the gallium-r600.
  24. Hi @upc0d3 Not sure if xorg-x11 is the opengl provider for your card but could be. @cardinal might be able to tell more. To get more output from glxgears you can use LIBGL_DEBUG=verbose glxgears You can also use glxinfo|grep DRI to see information about DRI usage. That should also be visible in the Xorg log file: cat /var/log/Xorg.0.log|grep DRI In that regard it would also be interesting to see what USE flags are used for mesa and xorg-drivers and what driver xorg is using. It might also help to have a look at the gentoo wiki page to see if there is something that might help.
  • Create New...