[pkg-gnupg-maint] gpg-error, assuan, gpgme, gnupg
Andreas Metzler
ametzler at bebt.de
Thu Aug 1 18:40:49 BST 2024
On 2024-08-01 Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> On Tue 2024-07-09 17:24:01 +0200, Andreas Metzler wrote:
> > I have been so bold as to upload libgpg-error 1.50 to experimental.
> thank you for this work. I think we should move libgpg-error 1.50 to
> unstable. Would you like to do that, or would you like me to do it?
> > I have also prepared libassuan 3.0.1 and gpgme 1.23.2 using separate
> > fast-forwardable branches (tmp-ametz-debian/experimental
> > tmp-ametz-upstream) and would appreciate review/comments.
> I have taken a look at both of these now, thanks.
> I think we should upload both of these packages into debian/experimental.
> I can do that, if you want me to take the final publication steps, or if
> you want to go ahead and do it that's also fine with me.
Hello Daniel,
I can probably do the three uploads on Saturday on Sunday but feel free
to upload if you have some time to spare. I have done the
(fast-forward)-merges.
> Before the upload to experimental, i'd modify debian/gbp.conf and
> debian/control's Vcs-Git entries to refer to the debian/experimental
> branch.
Done that.
> once they've landed in experimental, it should be pretty straightforward
> to move gpgme into unstable if we hear no complaints.
We will need small a transition here, too:
| Splitting of the qt devel
| packages (#863149) will require an intermediate upload to unstable with
| just adding a Provides: libqgpgme-dev to libgpgmepp-dev, followed by
| changing all packagages (build)-depending on QT gpgme to add a
| (build)-dep on the new package name. Only once that is finished gpgme
| with qt5/6-dev as separate packages could be uploaded to unstable.
I am not sure about the new package name "libqgpgme-dev" perhaps
"libqgpgmeqt5-dev" would be better?
[...]
> > All of these are predepedencies for gnupg 2.5.
> I think considering gnupg 2.5 (or 2.6) for debian would be a serious
> mistake, as it will further extend the wire format schism as compared to
> other OpenPGP implementations, without resolving the cryptographic
> updates that we know the standard needs.
I am not pushing for gnupg 2.5, but being able to build/develop for it
in Debian is something that would be nice to offer.
> (i also don't understand the cme-style work you've done on d/copyright in
> libassuan; i think we might also want to update d/copyright in gpgme
> before the upload).
I can add some info to README.source. It is just that copyright info was
not up to date and cme seems to the thing that to my knowledge works
best.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20240801/56b154c7/attachment.sig>
More information about the pkg-gnupg-maint
mailing list