NikosAlexandris

For a follow-up, see https://bugs.funtoo.org/browse/FL-6936.

This seems to be a "problem" for emerging various packages. For example, I cannot install `kde-plasma/systemsettings` as it ends up with the same `wayland` related requirement. I will file a ticket as I cannot understand the nature of the problem, nor I can find anything related on the web that is clearly related.

Dears, before filing an issue, is the following expected? root in ~ ❯ eix -s kde-cli-tools * kde-plasma/kde-cli-tools [1] Available versions: (5) 5.15.5^t (~)5.16.1^t {X debug +handbook (+)kdesu test} Homepage: https://cgit.kde.org/kde-cli-tools.git Description: Tools based on KDE Frameworks 5 to better interact with the system [1] "kde-kit" /var/git/meta-repo/kits/kde-kit and root in ~ took 9s ❯ USE="-wayland" emerge -av kde-cli-tools These are the packages that would be merged, in order: Calculating dependencies... done! !!! All ebuilds that could satisfy ">=dev-libs/wayland-1.2" have been masked. !!! One of the following masked packages is required to complete your request: - dev-libs/wayland-9999::xorg-kit (masked by: missing keyword) - dev-libs/wayland-1.17.0::xorg-kit (masked by: invalid: DEPEND: Invalid atom (Invalid use dep: ''), token 1, invalid: RDEPEND: Invalid atom (Invalid use dep: ''), token 1) (dependency required by "kde-plasma/kwin-5.16.1::kde-kit" [ebuild]) (dependency required by "kde-plasma/libkworkspace-5.16.1::kde-kit" [ebuild]) (dependency required by "kde-plasma/kde-cli-tools-5.16.1::kde-kit" [ebuild]) (dependency required by "kde-cli-tools" [argument]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. Why is `wayland` required?

I re-installed Funtoo 1.4, so the problems are "worked around".-

Same problem here. I remove boost which I think I don't need for the time. Thus, `hunspell` remains to be resolved. emerge -av app-office/libreoffice-bin These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-text/libexttextcat-3.4.5::text-kit USE="-static-libs" 1,017 KiB [ebuild N ] app-text/libnumbertext-1.0.5::text-kit 276 KiB [ebuild N ] sci-libs/suitesparseconfig-4.2.1-r1::science-kit USE="-abi_riscv_lp64 -abi_riscv_lp64d -static-libs" 251 KiB .. [ebuild UD ] dev-util/boost-build-1.65.0::core-kit [1.70.0::core-kit] USE="python -examples -test" PYTHON_TARGETS="python2_7" 80,662 KiB [ebuild UD ] dev-libs/boost-1.65.0:0/1.65.0::core-kit [1.70.0:0/1.70.0::core-kit] USE="icu nls python threads -abi_riscv_lp64 -abi_riscv_lp64d -context -debug -doc -mpi -static-libs -tools (-bzip2%*) (-lzma%) (-numpy%) (-zlib%*) (-zstd%)" PYTHON_TARGETS="python2_7 -python3_5 -python3_6 (-python3_7%*)" 0 KiB .. [ebuild UD ] app-text/hunspell-1.6.2-r1:0/1.6::text-kit [1.7.0:0/1.7::text-kit] USE="ncurses nls readline -static-libs" L10N="de el en fr -af -bg -ca -cs -cy -da -de-1901 -eo -es -et -fo -ga -gl -he -hr -hu -ia -id -is -it -kk -km -ku -lt -lv -mi -mk -ms -nb -nl -nn -pl -pt -pt-BR -ro -ru -sk -sl -sq -sv -sw -tn -uk -zu" 705 KiB .. and .. Total: 60 packages (3 downgrades, 54 new, 3 in new slots), Size of downloads: 346,068 KiB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: app-text/hunspell:0 (app-text/hunspell-1.6.2-r1:0/1.6::text-kit, ebuild scheduled for merge) pulled in by app-text/hunspell:0/1.6 required by (app-office/libreoffice-bin-6.2.4.2:0/0::desktop-kit, ebuild scheduled for merge) ^^^^^^ (app-text/hunspell-1.7.0:0/1.7::text-kit, installed) pulled in by app-text/hunspell:0/1.7= required by (kde-frameworks/sonnet-5.59.0:5/5.59::kde-kit, installed) ^^^^^^^ It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. The following USE changes are necessary to proceed: (see "package.use" in the portage(5) man page for more details) # required by app-office/libreoffice-bin-6.2.4.2::desktop-kit # required by app-office/libreoffice-bin (argument) >=dev-libs/xmlsec-1.2.28 nss

Typing in a cell phone, the error is actually two-fold: 1. Unable parse profile 2. Error loading '/var/cache/edb/mtimedb': invalid load key, '{'.

Dears, I managed to break my old system while trying to upgrade to 1.3 from 1.2. I have removed `python-exec` as well, while playing around! Obviously, I can't use `emerge` anymore. I now follow the "resurrection" wiki page, trying to fix both Python and Portage. I hit this `can't parse profile` problem. I managed to run the `ego profile.buold current` command but it didn't fix the profile related problem. Which I need to work around in order to re-install dev-lang/python and sys-apps/portage. Any ideas? Thank you.

Done, https://bugs.funtoo.org/browse/FL-6153.

Dears, where can I request for an update of the available net-im/signal-desktop-bin version?

Is it possible to re-use a Funtoo AWS image (https://aws.amazon.com/marketplace/pp/B07KT3VN7Q/) in an OpenStack Cloud?

I want to try out a recent version of the proj.4 (or simply PROJ) library, which supports for the Bertin 1953 projection. I was advised [0] to recompile only PROJ. Trying to find the build logs of `sci-libs/gdal` but the only related entries I found under `/var/log/portage/elog/summary.log` which are entries of failed build attempts. While the `gdal` package was still installed, however, there was no build log under `/var/log/portage/build/sci-libs/`. Perhaps it was so because I tried to clean my system recently, i.e. using `eclean-dist` commands. Here what I found, from past failed attempts: environment, line 2771: Called econf '--includedir=/usr/include/gdal' '--disable-static' '--e nable-shared' '--with-expat' '--with-geotiff' '--with-grib' '--with-libtiff' '--with-libz=/usr/' '--with-o gr' '--without-bsb' '--without-dods-root' '--without-dwgdirect' '--without-epsilon' '--without-fme' '--wit hout-grass' '--without-hdf4' '--without-idb' '--without-ingres' '--without-jp2mrsid' '--without-kakadu' '- -without-libtool' '--without-mrsid' '--without-msg' '--without-oci' '--without-pcraster' '--without-podofo ' '--without-sde' '--disable-debug' '--without-armadillo' '--with-pam' '--with-curl' '--without-ecw' '--wi thout-cfitsio' '--with-geos' '--with-gif' '--with-xerces' '--with-hdf5' '--with-pcidsk' '--with-jpeg' '--w ith-jasper' '--with-mysql=/usr/bin/mysql_config' '--with-netcdf' '--without-odbc' '--with-ogdi=/usr' '--wi th-opencl' '--with-poppler' '--without-perl' '--with-png' '--with-pg' '--with-python' '--with-spatialite' '--with-sqlite3=/usr' '--without-threads' '--with-freexl' '--with-java=/opt/oracle-jre-bin-1.8.0.112' '--w ith-mdb' 'LIBS=-lsqlite3' Related to what I am trying to get, the only piece of text in the above lines is the `'--disable-static`'. To proceed, anyhow, I removed PROJ that was installed via portage, and compiled it manually from source, as per the instructions at github.com/OSGeo/proj.4. What remains to do, is to "tell" GDAL to use this version of PROJ. Which I guess will happen automagically if there if any libproj.so is found (in `LD_LIBRARY_PATH`?) or via this option https://trac.osgeo.org/gdal/wiki/ConfigOptions#PROJSO. If I re-emerge gdal, there is now a large build log (~9MB). Questions How can I find the configuration of any built package that is currently installed? Is everything only under `/var/log/portage/build/`? Do build logs get erased after using `eclean-dist` commands? Are there notes on how to handle situations that involve updating the `LD_LIBRARY_PATH` environment variable? References [0] [gdal-dev] The "Bertin 1953" projection [1] Some post in the referenced thread [0] Thanks for any hints.

This is fixed, see https://bugs.funtoo.org/browse/FL-5798. Apologies for the unnecessary post here.

Just a question: will ego eventually handle overlays? Background I don't seek for help regarding the following, at least not in this post. The following is to justify the question. After having installed `eselect-repository` and enabling the 'chaoslab' repository, root@carbon nik # eselect repository list -i Available repositories: [66] chaoslab * I still had to somehow make ebuilds, from external repositories, visible to `emerge`. I did this with `eix-remote update`. Perhaps wrongly so, but I don't know how else. Now, `eix -R chromium` returns a couple of available packages, in various repositories. Yet, I still can't get to install such "external" packages, i.e. emerge -av www-client/ungoogled-chromium-bin::chaoslab returns !!! Section 'chaoslab' in repos.conf has location attribute set to nonexistent directory: '/var/db/repos/chaoslab' WARNING: One or more repositories have missing repo_name entries: /var/db/repos/chaoslab/profiles/repo_name NOTE: Each repo_name entry should be a plain text file containing a unique name for the repository on the first line. These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy "www-client/ungoogled-chromium-bin::chaoslab". emerge: searching for similar names... emerge: Maybe you meant any of these: www-client/google-chrome, www-client/google-chrome-beta, www-client/google-chrome-unstable? It would be, of course, great if ego could replace `eix-remote`. Or is this a bad idea?

Another update: I had to manually recreate the '/var/cache/eix/portage.eix' file and I did set ownership to 'portage:portage'. Then, `eix-update` and all seems ok now. Not sure if all this necessary/appropriate. Thanks for any feedback.

And, root@carbon nik # ego query v gentoo-sources sys-kernel/gentoo-sources| slot| repo --------------------------+----------+------------- 4.4.150| 4.4.150| nokit/master --------------------------+----------+------------- 4.4.157| 4.4.157| nokit/master --------------------------+----------+------------- 4.4.159| 4.4.159| nokit/master --------------------------+----------+------------- 4.4.160| 4.4.160| nokit/master --------------------------+----------+------------- 4.4.161| 4.4.161| nokit/master --------------------------+----------+------------- 4.4.162| 4.4.162| nokit/master --------------------------+----------+------------- 4.9.49-r1| 4.9.49-r1| nokit/master --------------------------+----------+------------- 4.9.122| 4.9.122| nokit/master --------------------------+----------+------------- 4.9.132| 4.9.132| nokit/master --------------------------+----------+------------- 4.9.133| 4.9.133| nokit/master --------------------------+----------+------------- 4.9.134| 4.9.134| nokit/master --------------------------+----------+------------- 4.9.135| 4.9.135| nokit/master --------------------------+----------+------------- 4.14.52| 4.14.52| nokit/master --------------------------+----------+------------- 4.14.65| 4.14.65| nokit/master --------------------------+----------+------------- 4.14.71| 4.14.71| nokit/master --------------------------+----------+------------- 4.14.72| 4.14.72| nokit/master --------------------------+----------+------------- 4.14.73| 4.14.73| nokit/master --------------------------+----------+------------- 4.14.74| 4.14.74| nokit/master --------------------------+----------+------------- 4.14.75| 4.14.75| nokit/master --------------------------+----------+------------- 4.14.76| 4.14.76| nokit/master --------------------------+----------+------------- 4.14.77| 4.14.77| nokit/master --------------------------+----------+------------- 4.14.78| 4.14.78| nokit/master --------------------------+----------+------------- 4.18.9| 4.18.9| nokit/master --------------------------+----------+------------- 4.18.10| 4.18.10| nokit/master --------------------------+----------+------------- 4.18.11| 4.18.11| nokit/master --------------------------+----------+------------- 4.18.12| 4.18.12| nokit/master --------------------------+----------+------------- 4.18.13| 4.18.13| nokit/master --------------------------+----------+------------- 4.18.14| 4.18.14| nokit/master --------------------------+----------+------------- 4.18.15| 4.18.15| nokit/master --------------------------+----------+------------- 4.18.16| 4.18.16| nokit/master --------------------------+----------+------------- 4.19.0| 4.19.0| nokit/master So, `eix` and `ego query` read different things?