friartek

Sorry for the delay getting back to this, other obligations come first. Not sure what steps got me to that point, but using the epro command to set the environment would cause the lines in the parent file to be reset to %s:... Updating ego to 1.1.3-r5 and running 'epro update' cleared up this issue. Checking command history showed that I hadn't run 'epro update' previously. I thought it was something I had done, but my command history says differently. As epro appears to modify parent, directly or indirectly I surmise hand modifying parent was not the way to go. But nothing is mentioned in either the ego or epro man pages about the parent file. A web search didn't turn up much either. The relationship is mentioned in Funtoo Profiles, but may need to be updated to reflect kits depending on how kits is to be addressed. The document does state "Typically, users don't need to modify this file, instead using ego and epro to make changes...", so it doesn't state that you can't or shouldn't modify it yourself. Kits may change how this should be looked at. My emerge issues, as mention earlier, most likely shouldn't be part of this discussion.

Understand and agree. If I hand edit parent, things look better. The problem is every time I set something with epro, those 19 lines get changed back to: %s:funtoo/kits/python-kit/3.4-prime Even changing parent by hand doesn't get me any farther as emerge has many dependency errors. I'm not sure if there is just one thing causing these issues, or if their are multiple things that are incorrect. Something I changed has caused this, just hope it wasn't something stupid. So far the system is still running(knock on wood). I just can't update anything. I have the space, and as I have spent way to much time already troubleshooting this, I'm going to rebuild from the most recent stage3. If and when time allows I will revisit this, at least then I'll have something to compare it to. It will take a while to set up and I need to run errands first, so If anyone has anything else to offer, I would be willing to try before rebuilding. I hate not knowing what caused this(which I may never know) and it would be nice to fix so if someone in the future has the same issue, there would be a solution. I want to thank all for your help.

/etc/portage/make.profile/parent looks strange, at least to me: core-kit:funtoo/1.0/linux-gnu/arch/pure64 %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime %s:funtoo/kits/python-kit/3.4-prime 19 identical lines? I'm guessing at a minimum the %s of each line should have been substituted with something else. Need to find what created this file.

Sadly I can't remember what got me into this same state. Python 3.4 instead of 3.5, but other then that, same identical error. Decided to follow the same course and removed /var/git and reinstalled kits(https://github.com/funtoo/meta-repo) as linked from http://forums.funtoo.org/topic/1193-eix-and-kits/. Among the commands having the error epro. After the reinstall: > epro show === Enabled Profiles: === arch: (not set) build: (not set) subarch: (not set) flavor: (not set) mix-ins: (not set) === Python kit: === branch: 3.4-prime WARNING: No arch defined. Please set a arch. WARNING: No build defined. Please set a build. WARNING: No flavor defined. Please set a flavor. At least I got output, and not the recursion error. So started to set profile: > epro arch pure64 === Enabled Profiles: === arch: pure64 build: (not set) subarch: (not set) flavor: (not set) mix-ins: (not set) >>> Set arch to pure64. WARNING: No build defined. Please set a build. WARNING: No flavor defined. Please set a flavor. As the man was heard to say after jumping of the roof, as he was passing a lower floor of the building, "So far so good". > epro build current Traceback (most recent call last): File "/usr/sbin/epro", line 9, in <module> portdir = portage.settings.repositories.mainRepoLocation() File "/usr/lib64/python3.4/site-packages/portage/proxy/objectproxy.py", line 22, in __getattribute__ result = object.__getattribute__(self, '_get_target')() File "/usr/lib64/python3.4/site-packages/portage/__init__.py", line 695, in _get_target return _get_legacy_global(name) File "/usr/lib64/python3.4/site-packages/portage/_legacy_globals.py", line 35, in _get_legacy_global portage.db = portage.create_trees(**kwargs) File "/usr/lib64/python3.4/site-packages/portage/__init__.py", line 585, in create_trees env=env, eprefix=eprefix) File "/usr/lib64/python3.4/site-packages/portage/proxy/objectproxy.py", line 31, in __call__ return result(*args, **kwargs) File "/usr/lib64/python3.4/site-packages/portage/package/ebuild/config.py", line 566, in __init__ locations_manager.load_profiles(self.repositories, known_repos) File "/usr/lib64/python3.4/site-packages/portage/package/ebuild/_config/LocationsManager.py", line 125, in load_profiles repositories, known_repos) File "/usr/lib64/python3.4/site-packages/portage/package/ebuild/_config/LocationsManager.py", line 249, in _addProfile self._addProfile(parentPath, repositories, known_repos) ... File "/usr/lib64/python3.4/site-packages/portage/package/ebuild/_config/LocationsManager.py", line 249, in _addProfile self._addProfile(parentPath, repositories, known_repos) File "/usr/lib64/python3.4/site-packages/portage/package/ebuild/_config/LocationsManager.py", line 227, in _addProfile parents = grabfile(parentsFile) File "/usr/lib64/python3.4/site-packages/portage/util/__init__.py", line 131, in grabfile mylines = grablines(myfilename, recursive, remember_source_file=True) File "/usr/lib64/python3.4/site-packages/portage/util/__init__.py", line 567, in grablines mylines = myfile.readlines() RuntimeError: maximum recursion depth exceeded while calling a Python object Back to where I started. Not sure where to go next. Still looking, but if anyone has any suggestions, I'd like to hear them. Must be missing something. So far my system is still running, just can't do any updates. emerge, same errors but with python2.7. Thanks in advance, Jim

Cardinal, Thanks for the information and direction to follow. FL-3288 has been created. Jim

Hi, First post, so if this is in the wrong place please let me know. Around July 18 some checksum files stopped being "archived"(for lack of a better word). To see what I mean please check out: http://build.funtoo.org/funtoo-stable/snapshots/ http://build.funtoo.org/funtoo-stable/x86-64bit/generic_64/2016-07-31/ These are just examples of what is happening. The *-latest.tar.xz.hash.txt file(s) are there, but when downloading older images, not all have a checksum file for verification. As I haven't checked all sub-archs I don't know how wide spread this issue is. Haswell appears not to have been affected so far. Just thought I should bring this to someone's attention. Again if this is posted in the wrong place, let me know. Sincerely, Jim