The following changes since commit c88551e939ed9349e7cc9be3e384749633b79655:
I am in awe of /etc/etckeeper/*.d/ (2019-03-18 14:36:14 +0000)
are available in the Git repository at:
https://github.com/sourcejedi/etckeeper.git
for you to fetch changes up to 040f5b2cb808ad9791d2c6f2f916fd887d2e16fa:
DNF: fix logging, now it will work from Ansible (2019-04-13 18:21:47 +0100)
Alan Jenkins (1): DNF: fix logging, now it will work from Ansible
etckeeper-dnf/etckeeper.py | 48 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 42 insertions(+), 6 deletions(-)
Please find a revised commit in the dnf branch of https://github.com/sourcejedi/etckeeper.git
commit id: afbdce2d24b46bc91840044b953aca8b68f20fd3
(The previous commit was not as safe as I thought.
If the etckeeper output includes an un-decodable byte, we would convert it to a unicode string which contains U+FFFD. This codepoint is not available in all character encodings, so it can cause UnicodeEncodeError. It's not fatal in current versions of dnf, because they set logging.RaiseExceptions = false. However it could lose an entire line of output.)
dnfpluginscore is not core support for dnf plugins, it is just a collection of "core plugins" for dnf. There is equally dnfpluginsextras and dnfpluginsextras.logger.
A comment in dnf.logger comment says the logger name 'dnf.plugin' is "api". So we can safely rely on that name.
Technically you can install etckeeper without the dnfpluginscore package (at least I managed to run into this for python2, on a Fedora 29 system which uses python3 for dnf by default).
Given the difficulty in feeding etckeeper output through this, would it perhaps be better to do something else with its output in this case, either /dev/nulling it or writing it to the syslog or something like that?
Hi,
I've been tracking down this issue on the Ansible side and just wanted to share this comment on GitHub.
Any estimations on when this gets applied upstream?
See same github repo, branch "dnf2", commit 7cda9678b1e60c0495a2a522721b319843d5fae0
Sorry for the delay. I can't find a record of an email notification.
In response to Joey's comment, I've tried sending all the etckeeper output to /dev/null. I find the resulting code more friendly to read, because it avoids my very long code comment :).
I interpreted "in this case" as just meaning "in etckeeper-dnf". I think you could technically check whether you are dnf v.s. a different libdnf client like Ansible, but I didn't want to :).
syslog.syslog() did not seem very helpful. In python2 it appears to encode unicode using ascii, regardless of the locale. I think we might be able to drop support for python2-dnf. But still, the system log seems a bit unexpected, compared to stderr, /var/log/dnf.plugin.log, /var/log/dnf.log, or whatever custom logger the host program set up.
dnf2 sinks etckeeper's stdout and stderr to /dev/null
etckeeper pre-install, whenAVOID_COMMIT_BEFORE_INSTALLis set, outputs an error to stderr, and exits nonzero. The expectation is that the package installation is canceled. (I don't know if that happens with etckeeper-dnf; it kind of looks like it warns and continues?)If etckeeper pre-install exiting nonzero does prevent the upgrade from happening, and the message about it goes to /dev/null, that seems like a surprising situation for the user to be confronted with.
In Fedora, we have that patch for a while now. However recently, someone stumbled over the issue joey described in his last comment. Seems like there is indeed only a warning and dnf continues instead of cancelling package installation.
The commit message of the patch reads:
hence I suspect, some more investigation has to happen on how to actually cancel the transaction from within a dnf plugin/hook?