dkg
-
Posts
74 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Blogs
Posts posted by dkg
-
-
The 'emerge --emptytree' would do this anyway, dummy! :)
Never mind, folks.
-
I'm curious. The Upgrade Instructions have one upgrade gcc, then set the subarch. It seems you'd want subarch turned on beforehand so the gcc binary gets the benifits of the optimizations. Or, if that doesn't work because the older gcc doesn't work with the subarch profiles, then it seems best to 'emerge -u1 gcc', then 'epro subarch', then 'emerge -1 gcc'. Is this a waste of effort?
-
6 minutes ago, palica said:
and please note 1.3 release is not ready yet - the dev cycle has just started on this branch so DO NOT use it in PRODUCTION.
Are you saying that there are steps I should follow to avoid 1.3? I did not put 1.3 in ego.conf, if that's what you mean.
-
6 minutes ago, palica said:
well, basically you should follow the steps that are described on the wiki.
- ego sync with your old ego.conf settings
- upgrade ego
- change to release = 1.2 in ego.conf
- ego sync
- and follow the steps further like emerge gcc, upgrade glibc and co and
- emerge -e @world
then you don't need any tweaking of make.conf
I was following those steps. I didn't touch ego.conf. I tried to upgrade ego, and got the errors about PYTHON_TARGETS above.
-
11 minutes ago, palica said:
please provide the error messages with PYTHON_TARGET stuff.
[root@wolfie 61% ego]# emerge -1 ego These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-admin/ego-2.4.2 [2.4.0] PYTHON_SINGLE_TARGET="-python3_4* -python3_7%" PYTHON_TARGETS="-python3_4* -python3_7%" Would you like to merge these packages? [Yes/No] y >>> Verifying ebuild manifests >>> Emerging (1 of 1) app-admin/ego-2.4.2::core-kit >>> Failed to emerge app-admin/ego-2.4.2, Log file: >>> '/var/tmp/portage/app-admin/ego-2.4.2/temp/build.log' >>> Jobs: 0 of 1 complete, 1 failed Load avg: 0.08, 0.07, 0.02 * Package: app-admin/ego-2.4.2 * Repository: core-kit * Maintainer: drobbins@funtoo.org funtoo * Upstream: https://bugs.funtoo.org/ * USE: amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox * No Python implementation selected for the build. Please set * the PYTHON_SINGLE_TARGET variable in your make.conf to one * of the following values: * * python3_7 python3_4 python3_5 python3_6 * ERROR: app-admin/ego-2.4.2::core-kit failed (setup phase): * No supported Python implementation in PYTHON_SINGLE_TARGET/PYTHON_TARGETS. * * Call stack: * ebuild.sh, line 92: Called pkg_setup * ebuild.sh, line 331: Called python-single-r1_pkg_setup * python-single-r1.eclass, line 562: Called python_setup * python-single-r1.eclass, line 552: Called die * The specific snippet of code: * die "No supported Python implementation in PYTHON_SINGLE_TARGET/PYTHON_TARGETS." * * If you need support, post the output of `emerge --info '=app-admin/ego-2.4.2::core-kit'`, * the complete build log and the output of `emerge -pqv '=app-admin/ego-2.4.2::core-kit'`. * The complete build log is located at '/var/tmp/portage/app-admin/ego-2.4.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-admin/ego-2.4.2/temp/die.env'. * Working directory: '/var/tmp/portage/app-admin/ego-2.4.2/homedir' * S: '/var/tmp/portage/app-admin/ego-2.4.2/work/ego-2.4.2'
[root@wolfie 61% ego]# PYTHON_SINGLE_TARGET="python3_4" emerge -1 ego These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-admin/ego-2.4.2 [2.4.0] PYTHON_SINGLE_TARGET="-python3_7%" PYTHON_TARGETS="-python3_4* -python3_7%" Would you like to merge these packages? [Yes/No] y >>> Verifying ebuild manifests >>> Emerging (1 of 1) app-admin/ego-2.4.2::core-kit >>> Failed to emerge app-admin/ego-2.4.2, Log file: >>> '/var/tmp/portage/app-admin/ego-2.4.2/temp/build.log' >>> Jobs: 0 of 1 complete, 1 failed Load avg: 0.08, 0.02, 0.01 * Package: app-admin/ego-2.4.2 * Repository: core-kit * Maintainer: drobbins@funtoo.org funtoo * Upstream: https://bugs.funtoo.org/ * USE: amd64 elibc_glibc kernel_linux python_single_target_python3_4 userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox * The implementation chosen as PYTHON_SINGLE_TARGET must be added * to PYTHON_TARGETS as well. This is in order to ensure that * dependencies are satisfied correctly. We're sorry * for the inconvenience. * ERROR: app-admin/ego-2.4.2::core-kit failed (setup phase): * Build target (python3_4) not in PYTHON_TARGETS. * * Call stack: * ebuild.sh, line 92: Called pkg_setup * ebuild.sh, line 331: Called python-single-r1_pkg_setup * python-single-r1.eclass, line 562: Called python_setup * python-single-r1.eclass, line 532: Called die * The specific snippet of code: * die "Build target (${impl}) not in PYTHON_TARGETS." * * If you need support, post the output of `emerge --info '=app-admin/ego-2.4.2::core-kit'`, * the complete build log and the output of `emerge -pqv '=app-admin/ego-2.4.2::core-kit'`. * The complete build log is located at '/var/tmp/portage/app-admin/ego-2.4.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-admin/ego-2.4.2/temp/die.env'. * Working directory: '/var/tmp/portage/app-admin/ego-2.4.2/homedir' * S: '/var/tmp/portage/app-admin/ego-2.4.2/work/ego-2.4.2' -
7 hours ago, palica said:
and you could try putting this into your /etc/portage/make.profile/parent file
core-kit:funtoo/1.0/linux-gnu/arch/x86-64bit core-kit:funtoo/1.0/linux-gnu/arch/x86-64bit/subarch/generic_64 core-kit:funtoo/1.0/linux-gnu/build/current core-kit:funtoo/1.0/linux-gnu/flavor/coreSync was successful. I did the above. Still had issues getting ego to merge. I had to add PYTHON_SINGLE_TARGET and PYTHON_TARGETS to make.conf for some reason. Had to use this to turn ignore a file collision with a man page for boot.conf:
[root@wolfie 61% ego]# FEATURES="-collision-detect -protect-owned" ebuild ego-2.5.0.4.ebuild merge
Got this QA warning:
* QA Notice: Symbolic link /usr/sbin/boot-update points to /usr/sbin/ego which does not exist.
[root@wolfie 61% portage]# whereis ego ego: /usr/bin/ego /etc/ego.conf /usr/share/ego /usr/share/man/man1/ego.1.bz2
But at this point, epro worked well enough to get my profiles back where they were, and ego worked well enough to sync. Any tips on why I needed to set the PYTHON variables in make.conf and why 'eselect python' isn't working?
[root@wolfie 61% ego]# eselect python list Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 [root@wolfie 61% ego]# eselect python set 1 [root@wolfie 61% ego]# eselect python list Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7
-
6 hours ago, palica said:
if you mean this ^
then to actually use the cloned ego you have to write
./ego sync
:) so yes I've seen it but you missed it
Good catch! It seems to be doing a lot more now.
-
44 minutes ago, palica said:
upgrade ego first then ego sync
Also, you might have missed it, but one of the logs in the initial post shows that I tried to clone ego from git and run 'ego sync' with that.
-
38 minutes ago, palica said:
upgrade ego first then ego sync
Not so easy, when 1) I can't sync to pull an updated ego ebuild, and 2)...
[root@wolfie 61% make.profile]# emerge -tuND --pretend ego !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Empty parent file: '/etc/portage/make.profile/parent' !!! /etc/portage/make.profile is not a symlink and will probably prevent most merges. !!! It should point into a profile within /var/git/meta-repo/kits/core-kit/profiles/ !!! (You can safely ignore this message when syncing. It's harmless.) !!! Your current profile is invalid. If you have just changed your profile !!! configuration, you should revert back to the previous configuration. !!! Allowed actions are limited to --help, --info, --search, --sync, and !!! --version.
-
32 minutes ago, palica said:
I was trying, but 'ego sync' (esentially the first in there as the first steps would have been done at the end of the last upgrade) went awry.
-
I have a system that hasn't been updated in a few months. I know it was updated to kits, but not yet to 1.2, which is what I was fixing to do today. Started with 'ego sync', which had an error. At that point profiles seemed to be trashed (0-length parent file), and various [ignorant] efforts to recover did not work out. Where do I need to start?
[root@wolfie 61% backup-parts]# ego sync Syncing meta-repo remote: Enumerating objects: 200, done. remote: Counting objects: 100% (200/200), done. remote: Compressing objects: 100% (101/101), done. remote: Total 1073 (delta 102), reused 195 (delta 98), pack-reused 873 Receiving objects: 100% (1073/1073), 161.63 KiB | 241.00 KiB/s, done. Resolving deltas: 100% (362/362), completed with 20 local objects. From https://github.com/funtoo/meta-repo ef81bf6..fb458da master -> origin/master M kits/core-hw-kit M kits/core-kit M kits/desktop-kit M kits/dev-kit M kits/editors-kit M kits/games-kit M kits/gnome-kit M kits/haskell-kit M kits/java-kit M kits/kde-kit M kits/lang-kit M kits/media-kit M kits/net-kit M kits/nokit M kits/php-kit M kits/python-kit M kits/ruby-kit M kits/science-kit M kits/text-kit M kits/xorg-kit Already on 'master' Your branch is behind 'origin/master' by 265 commits, and can be fast-forwarded. (use "git pull" to update your local branch) HEAD is now at ef81bf6 kit updates Skipping repository kits/python-modules-kit/ remote: Enumerating objects: 34, done. remote: Counting objects: 100% (34/34), done. remote: Compressing objects: 100% (25/25), done. remote: Total 34 (delta 10), reused 33 (delta 9), pack-reused 0 Unpacking objects: 100% (34/34), done. From https://github.com/funtoo/meta-repo * [new branch] 1.3-release -> origin/1.3-release Updating ef81bf6..fb458da Fast-forward metadata/kit-info.json | 188 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------- metadata/kit-sha1.json | 79 +++++++++++++++++++++++----------------------------------- metadata/version.json | 3 +++ 3 files changed, 152 insertions(+), 118 deletions(-) create mode 100644 metadata/version.json Traceback (most recent call last): File "/usr/bin/ego", line 120, in <module> EgoModule.run_ego_module(action, econfig, args, VERSION) File "/usr/share/ego/python/ego/module.py", line 101, in run_ego_module ego_module(*args) File "/usr/share/ego/python/ego/module.py", line 86, in __call__ self.handle() File "/usr/share/ego/modules/sync.ego", line 324, in handle self.sync_meta_repo() File "/usr/share/ego/modules/sync.ego", line 259, in sync_meta_repo success = self.sync_kit(kt, self.kits_root, branch=branch) File "/usr/share/ego/modules/sync.ego", line 53, in sync_kit branch = self.config.kit_info_metadata["kit_settings"][kit_name]["default"] KeyError: 'default'[root@wolfie 61% backup-parts]# epro update Updating profiles at /etc/portage/make.profile/parent... Traceback (most recent call last): File "/usr/bin/epro", line 120, in <module> EgoModule.run_ego_module(action, econfig, args, VERSION) File "/usr/share/ego/python/ego/module.py", line 101, in run_ego_module ego_module(*args) File "/usr/share/ego/modules/profile.ego", line 312, in __call__ super().__call__(*args) File "/usr/share/ego/python/ego/module.py", line 86, in __call__ self.handle() File "/usr/share/ego/modules/profile.ego", line 293, in handle handler() File "/usr/share/ego/modules/profile.ego", line 129, in handle_write self.tree.write(self.config, outfile) File "/usr/share/ego/python/ego/profile.py", line 449, in write python_kit_branch = config.get_configured_kit("python-kit") File "/usr/share/ego/python/ego/config.py", line 75, in get_configured_kit default = self.kit_info_metadata["kit_settings"][kit]["default"] KeyError: 'default'[root@wolfie 61% backup-parts]# ego config Traceback (most recent call last): File "/usr/bin/ego", line 120, in <module> EgoModule.run_ego_module(action, econfig, args, VERSION) File "/usr/share/ego/python/ego/module.py", line 101, in run_ego_module ego_module(*args) File "/usr/share/ego/python/ego/module.py", line 86, in __call__ self.handle() File "/usr/share/ego/modules/config.ego", line 66, in handle handler() File "/usr/share/ego/modules/config.ego", line 12, in handle_get_action val = self.config.get_setting(self.options.section[0], self.options.key[0], default="") AttributeError: 'Namespace' object has no attribute 'section'[root@wolfie 61% portage]# cd /var/tmp [root@wolfie 61% tmp]# git clone https://github.com/funtoo/ego.git Cloning into 'ego'... remote: Enumerating objects: 347, done. remote: Counting objects: 100% (347/347), done. remote: Compressing objects: 100% (231/231), done. remote: Total 2635 (delta 237), reused 211 (delta 110), pack-reused 2288 Receiving objects: 100% (2635/2635), 670.85 KiB | 274.00 KiB/s, done. Resolving deltas: 100% (1493/1493), done. [root@wolfie 61% tmp]# cd ego [root@wolfie 61% ego]# ego sync Syncing meta-repo M kits/core-hw-kit M kits/core-kit M kits/desktop-kit M kits/dev-kit M kits/editors-kit M kits/games-kit M kits/gnome-kit M kits/haskell-kit M kits/java-kit M kits/kde-kit M kits/lang-kit M kits/media-kit M kits/net-kit M kits/nokit M kits/php-kit M kits/python-kit M kits/science-kit M kits/text-kit M kits/xorg-kit Already on 'master' Your branch is up to date with 'origin/master'. HEAD is now at fb458da kit updates Skipping repository kits/python-modules-kit/ Already up to date. Traceback (most recent call last): File "/usr/bin/ego", line 120, in <module> EgoModule.run_ego_module(action, econfig, args, VERSION) File "/usr/share/ego/python/ego/module.py", line 101, in run_ego_module ego_module(*args) File "/usr/share/ego/python/ego/module.py", line 86, in __call__ self.handle() File "/usr/share/ego/modules/sync.ego", line 324, in handle self.sync_meta_repo() File "/usr/share/ego/modules/sync.ego", line 259, in sync_meta_repo success = self.sync_kit(kt, self.kits_root, branch=branch) File "/usr/share/ego/modules/sync.ego", line 53, in sync_kit branch = self.config.kit_info_metadata["kit_settings"][kit_name]["default"] KeyError: 'default'[root@wolfie 61% make.profile.old]# epro list === arch: === arm-32bit, arm-64bit, pure64, x86-32bit, x86-64bit === build: === current, experimental, stable === subarch: === None available === flavor: === core, desktop, hardened, minimal, server, workstation === mix-ins: === X, audio, cinnamon, console-extras, dvd, gfxcard-intel-glamor gnome, gnome-3.16-fixups, hardened, kde, kde-plasma-5, lxde lxqt, mate, media, media-pro, mediadevice-audio-consumer, mediadevice-audio-pro mediadevice-base, mediadevice-video-consumer, mediadevice-video-pro mediaformat-audio-common, mediaformat-audio-extra, mediaformat-gfx-common mediaformat-gfx-extra, mediaformat-video-common, mediaformat-video-extra no-emul-linux-x86, no-systemd, openvz-host, print, python3-only selinux, vmware-guest, xfce WARNING: No arch defined. Please set. WARNING: No build defined. Please set. WARNING: No flavor defined. Please set.[root@wolfie 61% make.profile.old]# epro arch x86-64bit WARNING: None === Enabled Profiles: === arch: x86-64bit build: (not set) subarch: (not set) flavor: (not set) mix-ins: (not set) >>> Set arch to x86-64bit. WARNING: No build defined. Please set. WARNING: No flavor defined. Please set. Updating profiles at /etc/portage/make.profile/parent... Traceback (most recent call last): File "/usr/bin/epro", line 120, in <module> EgoModule.run_ego_module(action, econfig, args, VERSION) File "/usr/share/ego/python/ego/module.py", line 101, in run_ego_module ego_module(*args) File "/usr/share/ego/modules/profile.ego", line 312, in __call__ super().__call__(*args) File "/usr/share/ego/python/ego/module.py", line 86, in __call__ self.handle() File "/usr/share/ego/modules/profile.ego", line 305, in handle self.handle_write() File "/usr/share/ego/modules/profile.ego", line 129, in handle_write self.tree.write(self.config, outfile) File "/usr/share/ego/python/ego/profile.py", line 449, in write python_kit_branch = config.get_configured_kit("python-kit") File "/usr/share/ego/python/ego/config.py", line 75, in get_configured_kit default = self.kit_info_metadata["kit_settings"][kit]["default"] KeyError: 'default'[root@wolfie 61% make.profile.old]# epro build current WARNING: None === Enabled Profiles: === arch: (not set) build: current subarch: (not set) flavor: (not set) mix-ins: (not set) >>> Set build to current. WARNING: No arch defined. Please set. WARNING: No flavor defined. Please set. Updating profiles at /etc/portage/make.profile/parent... Traceback (most recent call last): File "/usr/bin/epro", line 120, in <module> EgoModule.run_ego_module(action, econfig, args, VERSION) File "/usr/share/ego/python/ego/module.py", line 101, in run_ego_module ego_module(*args) File "/usr/share/ego/modules/profile.ego", line 312, in __call__ super().__call__(*args) File "/usr/share/ego/python/ego/module.py", line 86, in __call__ self.handle() File "/usr/share/ego/modules/profile.ego", line 305, in handle self.handle_write() File "/usr/share/ego/modules/profile.ego", line 129, in handle_write self.tree.write(self.config, outfile) File "/usr/share/ego/python/ego/profile.py", line 449, in write python_kit_branch = config.get_configured_kit("python-kit") File "/usr/share/ego/python/ego/config.py", line 75, in get_configured_kit default = self.kit_info_metadata["kit_settings"][kit]["default"] KeyError: 'default' -
2 hours ago, pross said:
Digital Ocean rolled out patches this week.
I had to update all our servers with a new kernel provided by Debian will the same sort of thing happen here?
When I checked my container last week, I found that it was running a patched kernel.
-
23 hours ago, palica said:
you have to download also the files directory as the ebuild is using the files from there :) as the error message states.
Got it. I guess I was expecting some command to do this. It seems strange as I've been using gentoo/funtoo for so long, but I must have never downloaded an ebuild that needed a patch before. Thanks.
-
And how do I do that?
-
I wanted to try out the latest version of darktable, v2.4.0. So, I downloaded the gentoo ebuild, put in in my local overlay, and ran 'ebuild darktable-2.4.0.ebuild manifest'. Then I ran 'emerge -u darktable'. But I got the following error:
>>> Preparing source in /var/tmp/portage/media-gfx/darktable-2.4.0/work/darktable-2.4.0 ... * Applying darktable-find-opencl-header.patch ... /var/tmp/portage/media-gfx/darktable-2.4.0/temp/environment: line 1029: /var/tmp/portage/media-gfx/darktable-2.4.0/files/darktable-find-opencl-header.patch: No such file or directory [ !! ] * ERROR: media-gfx/darktable-2.4.0::chopin failed (prepare phase): * patch -p1 failed with /var/tmp/portage/media-gfx/darktable-2.4.0/files/darktable-find-opencl-header.patch
What have I done wrong?
-
6 hours ago, znavko said:
Hello! If you search info about how to update/upgrade the kernel, check your kernel info: version and producer
Hi. Perhaps you didn't notice this was posted in the Funtoo Hosting forum. I configure and compile my own kernels usually, but this is a completely different situation. :)
-
9 hours ago, Oleg Vinichenko said:
containers are sharing the host node kernel. Update has to be performed on that servers.
Hi. I understand that the containers share the kernel on the host, and that the host kernel needs to be updated. What I do not now, not being familiar with OpenVZ, is whether something additional needs to happen with the container, like rebooting it. However, I did reboot my container yesterday, and did not see an updated kernel. Any timeline on when the host kernels will get patched? I saw on the OpenVZ support forums that they released a new kernel.
-
Is there something that I need to do? I don't seem to have a new kernel.
$ uname -a Linux dkg 2.6.32-042stab123.3 #1 SMP Sun Jun 4 01:36:20 MDT 2017 x86_64 Intel(R) Xeon(R) CPU X5650 @ 2.67GHz GenuineIntel GNU/Linux
-
Any insights on Meltdown patches for containers? I assume they are vulnerable (Intel Xeon), and that there is nothing I can do to patch it myself.
-
Let me preface this post by saying I hope it will be constructive. It's not my intention to simply complain or vent.
I wanted to share my experience updating one of my funtoo systems the past two days, because I feel that kits (so far) may not be living up to their promise. I had hoped they would smooth over some of the headaches of system upgrades. My upgrade process went something like this:
- Blockers where USE=qt4 had to be added to several packages, successively. That is... emerge @world; long wait; portage reports package needs USE=qt4; add USE flag; emerge @world; long wait; portage reports package needs USE=qt4; add USE flag; emerge @world; long wait; portage reports package needs USE=qt4; and so on.
- Blocker related to libreoffice. I had earlier keyworded libreoffice for stable only, as I really don't need the latest and it's a beast to build. Well, at this time there isn't a single stable ebuild in the tree. Oddly, there is still a stable ebuild for libreoffice-l10n. Anyway, I had to remove the stable keyword.
- To resolve some other blockers, I ended up using 'emerge -C' on 5 packages (e.g., kget and media-sound/picard). I kept a list of these so I could re-merge them at the end.
- I removed the 'legacy-systray' USE flag from plasma-desktop to resolve some other blockers.
- About this time, I was finally able to get it to start installing some updates.
- I'm getting odd build failures for virtualbox-modules, which I ignore for now and use '--keep-going' (will come back to this).
- Encountered a build failure in package pambase. With research, found an issue in the tracker that was fixed yesterday morning, so needed to 'ego sync' mid-upgrade.
- Now, it's 'emerge @preserved-rebuild' time, but it's blocked by a conflict with package doomsday. Use 'emerge -C doomsday' to resolve.
- I think it was here that I dealt with the app-emulation/wine to virtual/wine change. Not terrible, though I was a bit confused why I seem to need wine-vanilla if all I want is wine-staging. Perhaps I could if I emerge 'app-emulation/wine-staging' directly instead of going through 'virtual/wine'? I didn't want to stop the upgrade at this time to figure it out.
- Time to resolve issue with virtualbox-modules. It's giving multiple complaints that it "can't find Makefile" and "can't find .config file", and that I need to make sure that '/usr/src/linux' points to a full kernel source tree. I check, there is nothing wrong with the symlink, it points to the folder for the current running kernel, the folder contains a Makefile and .config file, and the folder still contains sources. The only possible problem I can figure is the ebuild for this kernel is no longer in the portage tree. So, I stop to upgrade the kernel, and the problem goes away.
- Now it's time to re-merge the packages I removed earlier, one of which is quodlibet. Only, portage complains it can't install the latest quodlibet because of some funky python issue with package dev-python/faulthandler I don't understand. I find no mention of this in JIRA or forums, so I just let it install the old version.
- I've just now discovered that portage is no longer picking up my local overlay. I'll need to research that, too.
It's certainly wasn't the most painful gentoo/funtoo upgrade I've ever been through, but I can't really say it was any easier than typical. Especially considering this was a shorter upgrade cycle than usual for me (only about a month), and I keep customizations on this system to a minimum. Anyway, as I said at the outset, I wanted to share my experience in the hopes it is constructive.
Cheers!
-
10 hours ago, cardinal said:
strace shows file paths scanned by eix
This was very helpful. Your output...
open("/etc/portage/repos.conf/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3My output...
open("/etc/portage/repos.conf/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)It turns out that /etc/portage/repos.conf/ is owned by root:root. Presumably, eix is using the portage user, and in combination with my default umask=077, it did not have permission. It's not a problem for /var/git/meta-repo/ because it is owned by portage:portage. I had adjusted the permissions of /var/git/meta-repo/ and one point, but never touched /etc/portage/repos.conf/. Occasionally, umask=077 does lead to some oddities.
I have it working now.
Thank you.
-
On 11/25/2017 at 10:31 AM, cardinal said:
rj@funtoo ~ $ eix --print PORTDIR /var/git/meta-repo/kits/core-kit/Where on your system is this PORTDIR set?
-
On 11/26/2017 at 2:47 AM, jhan said:
And make sure that there is no /etc/repos.conf, as eix would look for that as well and probably use it first.
No /etc/repos.conf.
-
On 11/26/2017 at 12:18 AM, palica said:
I haven't done anything to my systems and eix just works. It is something with your system that is miss-configured and you have to find it. I was just trying to help to narrow down the causes.
what is in /var/git/meta-repos/repos.conf/default ?
[root@chopin ~]# cat /var/git/meta-repo/repos.conf/default [DEFAULT] main-repo = core-kit
You have no /etc/eixrc or ~/.eixrc files? For the record, I do not. Do you have PORTDIR set somewhere? I do not. Yet, 'eix --print PORTDIR' returns '/usr/portage', which is wrong.
Upgrade Instrunctions and python
in General Help
Posted
I think the Upgrade Instructions may be missing steps regarding the python upgrade. It says to run these commands:
Both systems that I've upgraded to 1.2, I got this message when trying to remove python-3.4:
I don't recall exactly what I did the last time (it was some time ago), but today I tried first to use 'eselect python set'. This removed the '(fallback)' status for python3.6, but did not get rid of the above message. I ended up using 'eselect python edit' and entering a '-' before python3.4. This has happened to me twice now, which suggests it's not something weird that I did.