etckeeper/etckeeper-1.18.12-fix-output-for-ansible.patch

From 8266a4fb45621e08085c58537a531f33fc7eca74 Mon Sep 17 00:00:00 2001
From: Alan Jenkins <alan.christopher.jenkins@gmail.com>
Date: Wed, 10 Apr 2019 00:19:14 +0100
Subject: [PATCH 1/2] DNF: stderr is not ours to log to (and doing so breaks
 Ansible)

stderr does not belong to etckeeper-dnf
---------------------------------------

The Ansible dnf module uses the python dnf bindings.  In contexts like
these, stdout/stderr is owned by the host app (Ansible).  dnf should not
mess with stdout/stderr, unless the host app asks it to log there.

Specifically, we were breaking the JSON output of the Ansible dnf module.
This was only noticeable when the etckeeper message began with a "["
character.  Ansible has a mechanism to try and skip header messages like
login banners.  However, "[" is a valid character to start a JSON document.

https://unix.stackexchange.com/questions/511210/ansible-dnf-module-module-failure/

Solution
--------

Instead, log any non-zero exit status through the dnf logger.

For the pre-transaction etckeeper run, this message replaces an exception.
So we now avoid logging a traceback, which did not appear to add anything
useful.  (In my testing, dnf was continued to install after the exception
was logged).

I have also added a warning message for the post-transaction etckeeper run.

I switched from os.system() to subprocess.call().  The latter interface
supports better error reporting.  (When I tested os.system(), it returned
an errno number which was indistinguishable from an exit code).

etckeeper >/dev/null 2>&1
--------------------------

Any specific error messages from etckeeper are now discarded.  Because
unfortunately, python conventions about passing text strings have been
somewhat unclear.  It is an error to log strings if the encoding settings
of a registered logger cannot handle them.  Because a "bad" character
causes the entire string to be discarded, and optionally an exception
printed to stderr.  In a previous proposal I showed code that should be
correct in all expected cases.  However, the length of comment required to
define "all expected cases" was not very reassuring.

That was on top of explaining that dnf has a workaround that will avoid
raising exceptions when arbitrary unicode is logged to stdout.  My proposal
had to include that explanation, to show that we were not breaking a
system package manager.

It might sound strange to talk about error messages with characters
we cannot encode.  But I have one word for you: "filenames".

(After the recent python PR #14008[1], logging.basicConfig() defaults
to errors='backslashreplace'.  Also, errors= can be manually specified when
creating a lower-level logging "Handler".  I think this will resolve the
problem in the future.  It means that when programs are written for this
new version of python, it should be the responsibility of the log setup
code to prevent UnicodeEncodeError.)

[1] https://github.com/python/cpython/pull/14008
---
 etckeeper-dnf/etckeeper.py | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/etckeeper-dnf/etckeeper.py b/etckeeper-dnf/etckeeper.py
index e8a1a51..69edd88 100644
--- a/etckeeper-dnf/etckeeper.py
+++ b/etckeeper-dnf/etckeeper.py
@@ -9,7 +9,7 @@
 
 from dnfpluginscore import logger
 
-import os
+import subprocess
 import dnf
 
 
@@ -17,20 +17,25 @@ class Etckeeper(dnf.Plugin):
 
     name = 'etckeeper'
 
-    def _out(self, msg):
-        logger.debug('Etckeeper plugin: %s', msg)
+    def _run_command(self, command):
+        logger.debug('Etckeeper plugin: %s', command)
+        try:
+            with open("/dev/null", "wb") as devnull:
+                ret = subprocess.call(("etckeeper", command),
+                                      stdout=devnull, stderr=devnull,
+                                      close_fds=True)
+                if ret > 0:
+                    logger.warning('"etckeeper %s" failed (exit code %d)' % (command, ret))
+                if ret < 0:
+                    logger.warning('"etckeeper %s" died (signal %d)' % (command, -ret))
+        except OSError as err:
+            logger.warning('Failed to run "etckeeper %s": %s' % (command, err))
 
     def resolved(self):
-        self._out('pre transaction commit')
-        command = '%s %s' % ('etckeeper', " pre-install")
-        ret = os.system(command)
-        if ret != 0:
-            raise dnf.exceptions.Error('etckeeper returned %d' % (ret >> 8))
+        self._run_command("pre-install")
 
     def transaction(self):
-        self._out('post transaction commit')
-        command = '%s %s > /dev/null' % ('etckeeper', "post-install")
-        os.system(command)
+        self._run_command("post-install")
 
 if __name__ == "__main__":
     from distutils.core import setup
-- 
2.23.0


From 7cda9678b1e60c0495a2a522721b319843d5fae0 Mon Sep 17 00:00:00 2001
From: Alan Jenkins <alan.christopher.jenkins@gmail.com>
Date: Tue, 23 Apr 2019 20:15:01 +0100
Subject: [PATCH 2/2] Do not use dnfpluginscore.logger

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).
---
 etckeeper-dnf/etckeeper.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/etckeeper-dnf/etckeeper.py b/etckeeper-dnf/etckeeper.py
index 69edd88..d9dd2c3 100644
--- a/etckeeper-dnf/etckeeper.py
+++ b/etckeeper-dnf/etckeeper.py
@@ -7,11 +7,12 @@
 # Distutils code below was copied from etckeeper-bzr distributed with v1.15
 #
 
-from dnfpluginscore import logger
-
+import logging
 import subprocess
 import dnf
 
+logger = logging.getLogger('dnf.plugin')
+
 
 class Etckeeper(dnf.Plugin):
 
-- 
2.23.0