1)
File "/usr/lib/python-exec/python3.6/RigoDaemon_app.py", line 362, in _pusher
fobj.write(chunk)
TypeError: write() argument must be str, not bytes
2)
File "/usr/lib64/python3.6/site-packages/entropy/spm/plugins/interfaces/portage_plugin/__init__.py", line 77, in __init__
self.buffer = Writer(self, self._std.buffer)
AttributeError: 'FakeOutFile' object has no attribute 'buffer'
With Python 3, data in sqlite from packagesignatures.gpg column was binary on
read (because it was binary on write) but a string was actually required.
The problem was visible with GPG signed packages: when injected into database
using eit with Python 3, it would then explode during equo update/install on
client side.
error from Python 2:
File "/usr/lib64/python2.7/site-packages/entropy/client/interfaces/package/actions/fetch.py", line 1063, in do_signatures_validation
if hash_val in signatures:
TypeError: writable buffers are not hashable
error from Python 3:
File "/usr/lib64/python3.6/site-packages/entropy/client/interfaces/package/actions/fetch.py", line 1023, in do_compare_gpg
tmp_f.write(hash_val)
TypeError: write() argument must be str, not bytes
Added a new way to retrieve list of kernel available
that uses directory /etc/kernels/availables/{sabayon,sabayon-lts}.
If this directory is present is not used current logic for
retrieve the list of kernel.
Under /etc/kernels/avaiables/ directory files with 'lts' extension
are used for retrieve list of LTS kernels.
An user could return his kernel list just if he creates and
maintains his file in a similar format:
$# cat /etc/kernel/availables/mykernel
sys-kernel/linux-sabayon:4.9
sys-kernel/linux-mykernel:4.4
This logic now is used as an additional feature after retrieve
the existing kernels based on virtual/linux-binary or
virtual/linux-binary-lts.
ConfigurationFiles._load_maybe_add (equo.client.misc): path is in bytes here
_std_write (entropy.output): fixes crash in equo conf update with "Replace
original with update" when there is an error in which case msg can be bytes:
File ".../entropy/lib/entropy/tools.py", line 687, in movefile
print_generic("!!! Failed to move", src, "to", dest)
File ".../entropy/lib/entropy/output.py", line 596, in print_generic
_std_write(msg, stderr = stderr)
File ".../entropy/lib/entropy/output.py", line 493, in _std_write
obj.write(msg)
Function callers, in order (during eit commit):
1. filename='lib/entropy/server/interfaces/main.py', function='switch_default_repository', code_context=[' self.close_repositories()\n'], index=0)
2. filename='server/eit/commands/command.py', function='_call_exclusive', code_context=[' server.close_repositories()\n'], index=0)
3. filename='lib/entropy/client/interfaces/client.py', function='destroy', code_context=[' self.close_repositories(mask_clear = False)\n'], index=0)
4. filename='lib/entropy/server/interfaces/main.py', function='destroy', code_context=[' self.close_repositories()\n'], index=0)
Third one triggers packages set synchronization (which would cause "dictionary
changed size during iteration"), and marks sets as being synchronized.
Fourth does not trigger sets synchronization, so closes all repositories
without new ones being opened in the meantime.
Side note:
It's similar to this in "client," lib/entropy/client/interfaces/methods.py:
def close_repositories(self, mask_clear = True):
...
# list() -> python3 support
for item, val in list(repo_cache.items()):
...
repo_cache.pop(item).close(_token = repository_id)
...
but (based on shallow look), it doesn't do as much magic; just calls .pop()
(not sure if there are similar side effects in close() there, though), so the
explanation may possibly apply to the lib/entropy/server function only.
1. Command to execute (diff) was getting arguments like b"path".
2. Crash when priting message.
3. In Python 3, b'x'[0] is int, not str, so a test (if) was (silently)
always true. This way, upon eit commit (at least) and with Python 3,
warning about not merged configuration files was newer printed.
(3) prevented prior discovery of (1) and (2).
Based on my checks, there are no more problems like (3), but I cannot
tell for sure.
[Not tagged so in their git repository... whatever.]
With -R / it prints bogus lines making Entropy crash:
File "/usr/lib64/python2.7/site-packages/portage/dbapi/vartree.py", line 748, in aux_get
raise KeyError(mycpv)
KeyError: 'plib_registry:'
The change was done in portage-utils, commit f05c78008b1754a79e31e793a67d07ed8f5d11bc
Make qfile also check the prune lib registry
and the problem with qfile was reported to Gentoo in bug 699558.
It will break with older qfile but Entropy should fallback to slower,
non-qfile code branch.
In 0.74 -e was available, and in 0.80 it is not present.
In both versions, and with the same set of options used, -e and -v
provide the same result so -v is now used to work on both.
Changed in portage-utils, commit 951a8711a59b1a7d49125f5f5214ff1ae9e50074:
qfile: drop non-functional --exact option
Bug: https://bugs.gentoo.org/678632
Note: <tab> below can mean double <tab>.
This commit fixes cases such like the following ones:
* crash (issue !73) - e.g. KeyError: u'--mtime':
- equo security oscheck --mtime <tab>
- equo query graph --complete <tab>
(this was due to a typo in variable name)
* now prints options, previously it didn't:
- equo install -a <tab>
* crashed, or (with only variable name fixed) didn't print all options:
- equo security oscheck --mtime <tab>
(note that it worked with more special -q instead of --mtime etc.)
* didn't print all options:
- equo query list installed <tab>
(now shows also --by-user)
The following behaviour is still buggy:
* last typed word (note: no space before <tab>) disappears upon completion:
- equo security oscheck<tab>
(not a regression)
- equo install --deep<tab>
(here it's an option; regression! - previously it didn't complete but
didn't cause the word to be erased either)
These can be corrected reliably when something like ${COMP_WORDS[COMP_CWORD]}
(from complete -F) is passed to the Python side.
Without this it's not possible to distinguish between `recognized_option<tab>`
(completion of recognized_option) and `recognized_option <tab>`.
