Jump to content
funtoo forums

gissf1

Members
  • Content Count

    9
  • Joined

  • Last visited

  • Days Won

    2

gissf1 last won the day on March 7 2018

gissf1 had the most liked content!

About gissf1

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. gissf1

    ego trouble

    @pytony I've done a few package updates since I last saw the issue, but didn't change any major configuration, so its probably still the same. Here you go: # locale LANG=C LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE=POSIX LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL= I was using "set | grep LANG" and "set | grep LC" before to check my locale settings. I just learned something new. Thanks! :)
  2. gissf1

    ego trouble

    @pytony Thanks for the official patch! I installed appi-0.1.9999 (post-0.1.6, pre-0.1.7), and everything worked out of the box (without additional patching), so I would call that a fix! Also, in case it wasn't evident to others on this thread, I'm using Python 3.4 at the moment, so it absolutely can work with Python 3.4.
  3. gissf1

    ego trouble

    OK, The mystery is solved! I dug in and looked into where "ego query versions" opens the file. This search led me to /usr/lib64/python3.4/site-packages/appi/conf/profile.py (part of dev-python/appi-0.1.6::python-kit in my system) which is opening the file as text without specifying an encoding, and then throwing the trace when it reads the files and realizes there are non-ascii characters. I'm not sure what the best approach is, as I can imagine several options: use errors='ignore' on open, but I think this drops the entire input data when it dislikes even 1 character in the data use errors='replace' on open, which replaces unwanted characters with an encoding-specific character specify an encoding on open that does not throw an exception on non-ascii characters leave the open alone and catch the exception somewhere else others? I went with option 2 and it seemed to fix my problem. The patch for profile.py is as follows: --- profile.py 2018-02-17 06:12:06.000000000 -0600 +++ profile.py.modified 2018-02-24 15:52:43.000000000 -0600 @@ -112,7 +112,7 @@ k: v for k, v in context.items() if k in constant.INCREMENTAL_PORTAGE_VARS } - with open(str(path), 'r') as f: + with open(str(path), 'r', errors='replace') as f: output_vars = set(re.findall( r'^\s*(?:export\s+)?([a-z][a-z0-9_]*)=', f.read(), re.M | re.I )) Since appi is on gitlab, I created an issue https://gitlab.com/apinsard/appi/issues/15 ticket and cross referenced this forum page. I may submit a patch/pull request at some point, but thought I'd elicit some feedback before doing so. Any thoughts on what the best solution is?
  4. gissf1

    ego trouble

    @cardinal Thanks for that strace, that did help alot! I noticed one major difference while initializing. It seems that on my system its using: /usr/lib/python-exec/python3.4/../../../lib64/python3.4/encodings/ascii.py and on your system its using: /usr/lib/python-exec/python3.4/../../../lib64/python3.4/encodings/utf_8.py Using ascii instead of utf_8 in python is not completely unexpected on my system since I try to avoid building anything outside en_US locale with ISO-8859-1 encoding. Later, (on both yours and mine) it reads the file: /var/git/meta-repo/kits/core-kit/profiles/base/make.defaults In that file, it finds non-ascii (code points >0x7e) characters in the file contents as part of a utf-8 sequence in one of the first author's names in a comment, and mine dies immediately after, because the python ascii parser does not attempt to handle any extended characters and throws exceptions instead. So this brings up the next question of why my system is using ascii instead of utf_8. I do have utf-8 support enabled in some places, and I have the referenced "utf_8.py" file (the one yours loaded earlier) in my system, but it's not choosing to load it for some reason. I guess I'll dig in deeper and see where the rabbit hole leads. Thanks again cardinal!
  5. gissf1

    ego trouble

    I seem to have this issue too (nearly the same stack trace as the OP) and was wondering what else I could look for to diagnose it? I've had this issue since I first noticed ego offering the query option, probably back around November, and simply assumed my system was just outdated and that's why it wasn't working. After just recently updating my entire system with the latest ego, portage, and nearly everything else (emerge -uD @system @world) this issue is still persisting. I'm running Python 3.4, I don't have LC_ALL defined in my environment, and I included the version info for ego itself below. Stack trace: # ego query v ego Traceback (most recent call last): File "/usr/bin/ego", line 96, in <module> EgoModule.run_ego_module(action, econfig, args, VERSION) File "/usr/share/ego/python/ego/module.py", line 78, in run_ego_module ego_module(*args) File "/usr/share/ego/python/ego/module.py", line 63, in __call__ self.handle(**options) File "/usr/share/ego/modules/query.ego", line 42, in handle handler(**options) File "/usr/share/ego/modules/query.ego", line 59, in handle_versions_subcommand slot = ebuild.vars.get('SLOT', '0') File "/usr/lib64/python3.4/site-packages/appi/ebuild.py", line 122, in vars self._parse_ebuild_file() File "/usr/lib64/python3.4/site-packages/appi/ebuild.py", line 180, in _parse_ebuild_file make_conf = Profile.get_system_make_conf() File "/usr/lib64/python3.4/site-packages/appi/conf/profile.py", line 136, in get_system_make_conf context = Profile._parse_make_conf_file(path, context) File "/usr/lib64/python3.4/site-packages/appi/conf/profile.py", line 117, in _parse_make_conf_file r'^\s*(?:export\s+)?([a-z][a-z0-9_]*)=', f.read(), re.M | re.I File "/usr/lib/python-exec/python3.4/../../../lib64/python3.4/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2220: ordinal not in range(128) ego version info: # emerge --info app-admin/ego Portage 2.3.18 (python 3.4.5-final-0, funtoo/1.0/linux-gnu/arch/x86-64bit, gcc-5.4.0, glibc-2.23-r6, 4.9.16-gentoo_shard x86_64) ... SNIP ... sh bash 4.3_p48 ... SNIP ... dev-lang/python: 2.7.12::python-kit, 3.4.5::python-kit ... SNIP ... Unset: CPPFLAGS, CTARGET, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS ================================================================= Package Settings ================================================================= app-admin/ego-2.3.3-r1::core-kit was built with the following: USE="-zsh-completion" PYTHON_SINGLE_TARGET="python3_4 -python3_5 -python3_6" PYTHON_TARGETS="python3_4 -python3_5 -python3_6" Any ideas?
  6. This may help explain your situation: https://bugs.funtoo.org/browse/FL-3953 If possible, you may consider just using llvm-3.x in the meantime until the issues are resolved. If you require the lldb USE flag, consider installing a version of llvm before 3.9.0_rc. llvm-3.7.1-r3 is unmasked for me, or one could unmask one of the 3.8.x versions as well. Obviously if llvm-4.x is a requirement for your situation, this isn't going to help, but does provide a reference indicating that the problem is known and unresolved as of yet.
  7. Cool. I'll just wait for the magic to arrive then, thanks!
  8. I think I noticed some of that functionality when I installed ego-2.2.0 earlier, and I love the interface's color output! It is much easier to read and more informative than what I did in my script's dumb output. I've already updated my system to ego-2.2.1 and added the entries manually to ego.conf. Thanks for the great feature! As for my script, it should probably be deprecated now (even though it hasn't been posted for long), but if I consider making updates, I'll dig a bit more and see how hard it would be to add the functionality directly into ego's kit module and try to submit a pull/merge request instead :) One thing I would consider adding is the ability to set from the command line without an editor, as my script allowed "esync set <kit-name> <branch-name>" to set the branch for a kit. This is likely trivial to add to ego since it obviously has an ini-style parser already in use for the ego.conf file. If I get through my current system update process any time soon, I may try to do this myself. Thanks again for all you do!
  9. Based on the above script from @cafaia, I created a tool (shell + gawk) to do syncs on each metarepo section, allow selection of desired branches per kit, and persist those branch selections across syncs. Perhaps this can be useful to someone until ego does this internally. Its available here: https://github.com/gissf1/funtoo-metarepo-esync/ I don't expect it to be needed for long, but feel free to contribute to or borrow from its code as desired.
×
×
  • Create New...