From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH 0/5] gnupg: Update to 2.2.27 Date: Tue, 06 Apr 2021 14:40:19 +0100 Message-ID: <8C446075-6701-4A5C-85AF-B3C5D8CFC899@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7377473689636333923==" List-Id: --===============7377473689636333923== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 6 Apr 2021, at 13:09, Adolf Belka wrote: >=20 > Hi Michael, >=20 >=20 > On 06/04/2021 12:38, Michael Tremer wrote: >> Hello, >> Thank you for working on this. >>> On 4 Apr 2021, at 12:10, Adolf Belka wrote: >>>=20 >>> This is the patch series for the update of gnupg from the legacy 1.4 >>> branch to the LTS 2.2 branch. >>>=20 >>> Required for build and use are >>> libassuan New requirement for 2.2 branch - change from addon to Core pro= gram >>> libksba New requirement for 2.2 branch - new install >>> npth New requirement for 2.2 branch - new install >>>=20 >>> pinentry not required for build. Is required for some uses of gnupg such >>> as when providing passwords. This does not apply the the IPFire use cases. >>>=20 >>> Trying to update gpgme with the old 1.4 branch gnupg resulted in various >>> fails. Was looking for files that were not present. >>> Updating gpgme with 2.2 branch of gnupg was successful. >>>=20 >>> The iso created from the build of all the changes from this patch series >>> was installed in my vm testbed. Keys successfully imported. Package lists >>> successfully read and put into pakfire wui page. Several addons installed >>> successfully. Packages had signatures successfully verified. >>> My testing indicates that gnupg 2.2 branch is successfully working in >>> IPFire in place of the 1.4 branch >> That sounds very good. > I was surprised how well it went after I had sorted out all the additional = dependency programs. >> What is the migration path? Can the new version read the old key store or = do we have to do something about this first? > My testing was only for installing from scratch using the iso. That seemed = to work fine and successfully imported the keys, created the list of availabl= e packages and then successfully verified the addons I installed. > As this is a big change it definitely would be good to have other people te= st out that what I found is generally applicable. >=20 > For migration with the Core Update, I don't know what might be needed. I wa= s not able to test this out on my vm testbed. > If the changes are merged then I, and others, could do an upgrade to unstab= le which should highlight if there are any problems with the migration for a = Core Update. > I don't have any other ideas beyond that for testing out the migration path= required. Basically to install these packages on a system that has been installed with = the older version. I would like to avoid doing this in the next tree, because= if things go wrong, we will break systems of all testers. -Michael >=20 > Regards, > Adolf. >> -Michael >>>=20 >>>=20 >>> Adolf Belka (5): >>> gnupg: Update to 2.2.27 >>> libassuan: Convert from addon to core program >>> libksba: required for gnupg 2.2 series >>> npth: required for gnupg 2.2 series >>> gpgme: Update to 1.15.1 >>>=20 >>> config/rootfiles/common/gnupg | 107 ++++++++++-- >>> .../rootfiles/{packages =3D> common}/libassuan | 0 >>> config/rootfiles/common/libksba | 9 + >>> config/rootfiles/common/npth | 7 + >>> config/rootfiles/packages/gpgme | 162 +++++++++++++++++- >>> lfs/gnupg | 4 +- >>> lfs/gpgme | 6 +- >>> lfs/libassuan | 6 - >>> lfs/libksba | 79 +++++++++ >>> lfs/npth | 79 +++++++++ >>> make.sh | 2 + >>> 11 files changed, 434 insertions(+), 27 deletions(-) >>> rename config/rootfiles/{packages =3D> common}/libassuan (100%) >>> create mode 100644 config/rootfiles/common/libksba >>> create mode 100644 config/rootfiles/common/npth >>> create mode 100644 lfs/libksba >>> create mode 100644 lfs/npth >>>=20 >>> --=20 >>> 2.31.1 --===============7377473689636333923==--