Bug#911189: gpgme-json packaging
On 2024-05-17 Detlef Eppers wrote: [...] > So I'm throwing my hat in the ring for gpgme-json :) [...] Given that iirc Ubuntu has gone with gpgme-json we will probably go this avenue, when we package it. 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'
Bug#911189: gpgme-json packaging
On Fri, 17 May 2024 11:36:00 + Detlef Eppers wrote: > That said: naming is important and naming is hard, but three years > have passed, and it is my impression that this is getting somewhat > out of proportion. +1 i have been building my own gpgme packages for the last 5+ years because of all the indecision & nitpicking. If it helps, here is an updated branch: https://salsa.debian.org/twolife/gpgme/-/commits/gpgmejson details: - i put the gpgme-json binary in a new 'gpgme-bin' package and not 'libgpgme-dev' as this is not a dev/debug/test utilitie - the browser manifests are shipped in the same package, a 5 lines json file doesn't justify the overhead of splitting it in another package - thanks to Sascha Wilde for the manpage i stoled in the previous MR i have the feeling i'm sending this email to /dev/null :'( graybeards blocking progress because "this is my sacred garden that young fools will not taint" is unfortunately pretty common in debian land :'(
Bug#911189: gpgme-json packaging
On Fri, 11 Aug 2023 18:16:13 +0200 Norbert Lange wrote: On Mon, 16 Jan 2023 02:01:37 +0100 =?ISO-8859-1?Q?=C1ngel?= wrote: > I have tested https://salsa.debian.org/debian/gpgme/-/merge_requests/1 > and it works fine. > I would however name the new package gpgme-json, not libgpgme-bin > > The package is only providing gpgme-json(1). If it is going to ship > more binaries in the future, it can always be replaced. If someone is > told they need gpgme-json the expected package name is 'gpgme-json', > not libgpgme-bin. Plus, that lib prefix is even more confusing. > > Even the description (“This package contains the gpgme-json binary to > access GPGME...”) seem to ask for that name. > > That is the only nitpick I have. It "just works". :-) > > The debian/changelog would need updating, and rebased on top of gpgme > 1.18 (bookworm/sid) from the current 1.14. How about just playing the binary into a package name "gpgme", like Fedora does https://packages.fedoraproject.org/pkgs/gpgme/gpgme/fedora-rawhide.html#files gpgme as package name is potentially confusing, because it could convey the impression of a meta package. Regarding libgpgme-bin, there is maybe a little inconsistency in that libgpgme-dev already contains another executable. So I'm throwing my hat in the ring for gpgme-json :) That said: naming is important and naming is hard, but three years have passed, and it is my impression that this is getting somewhat out of proportion. -- PGP: 84F59CAFB6618B1D01C992A6D0462C2C9FB57726
Bug#911189: gpgme-json packaging
On Mon, 16 Jan 2023 02:01:37 +0100 =?ISO-8859-1?Q?=C1ngel?= wrote: > I have tested https://salsa.debian.org/debian/gpgme/-/merge_requests/1 > and it works fine. > I would however name the new package gpgme-json, not libgpgme-bin > > The package is only providing gpgme-json(1). If it is going to ship > more binaries in the future, it can always be replaced. If someone is > told they need gpgme-json the expected package name is 'gpgme-json', > not libgpgme-bin. Plus, that lib prefix is even more confusing. > > Even the description (“This package contains the gpgme-json binary to > access GPGME...”) seem to ask for that name. > > That is the only nitpick I have. It "just works". :-) > > The debian/changelog would need updating, and rebased on top of gpgme > 1.18 (bookworm/sid) from the current 1.14. How about just playing the binary into a package name "gpgme", like Fedora does https://packages.fedoraproject.org/pkgs/gpgme/gpgme/fedora-rawhide.html#files
Bug#911189: gpgme-json packaging
I have tested https://salsa.debian.org/debian/gpgme/-/merge_requests/1 and it works fine. I would however name the new package gpgme-json, not libgpgme-bin The package is only providing gpgme-json(1). If it is going to ship more binaries in the future, it can always be replaced. If someone is told they need gpgme-json the expected package name is 'gpgme-json', not libgpgme-bin. Plus, that lib prefix is even more confusing. Even the description (“This package contains the gpgme-json binary to access GPGME...”) seem to ask for that name. That is the only nitpick I have. It "just works". :-) The debian/changelog would need updating, and rebased on top of gpgme 1.18 (bookworm/sid) from the current 1.14.
Bug#911189: gpgme-json packaging
On Thu 2020-10-01 14:05:59 +0200, Sascha Wilde wrote: > so far I haven't received any reply to either my pull request or my > questions in the bug report issue from Fri, 11 Sep 2020 15:38:13 +0200. > > I would still appreciate input on my work, especially if there is > anything I need to do to make the changes acceptable for the Debian > package. Hi Sascha-- thanks for this, and sorry for my delay in responding to you. It's on my queue, and i'll try to look at it soon. If anyone else on the debian GnuPG packaging team wants to take a look and give feedback, i'd appreciate it too! --dkg
Bug#911189: gpgme-json packaging
Hello, so far I haven't received any reply to either my pull request or my questions in the bug report issue from Fri, 11 Sep 2020 15:38:13 +0200. I would still appreciate input on my work, especially if there is anything I need to do to make the changes acceptable for the Debian package. Thank you for your support, sascha -- Sascha Wilde OpenPGP key: 4365844304077279 http://www.intevation.de/ http://www.intevation.de/~wilde/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Bug#911189: gpgme-json packaging
Sascha Wilde writes: > As a first step I created a merge request to deploy gpgme-json together > with the library: > https://salsa.debian.org/debian/gpgme/-/merge_requests/1 After realizing that the current MR breaks multi arch compatibility for the library I revised it and added a new -bin package, which for now only provides gpgme-json. I also added a rudimentary man page for gpgme-json. > Next I will look into creating specific packages with browser > manifests... I have implemented that and created a new merge request: https://salsa.debian.org/debian/gpgme/-/merge_requests/2 In addition to the new -bin package two more new packages are created: - libgpgme-chromium-native-messaging - libgpgme-firefox-native-messaging Each of the packages provides a native messaging manifest for the respective browser which allows using GPGME via gpgme-json for a set of well known extensions. For now the only supported extension is mailvelope but more could be easily added later on. Upstream encourages distributors to create manifest packages for their distributions, therefor I think adding these packages here is The Right Thing To Do™. Some remarks/requests for comment: 1. Currently the manifest installed for chromium is installed as: /etc/chromium/native-messaging-hosts/gpgmejson.json Upstream recommends a slightly different file name schema[0]: /etc/chromium/native-messaging-hosts/com.my_company.my_application.json As you can see, following this recommendation would mean adding a domain. I'm not sure whether to follow this scheme, and if so, which domain to add: org.debian, org.gnupg or ..? 2. The manifest for chromium is automatically marked configuration file, as it resides under /etc, which IMO is correct. A sysadmin might want to edit the manifest, e.g. to add the IDs of further extensions. However: the manifest for firefox is installed as /usr/lib/mozilla/native-messaging-hosts/gpgmejson.json (This is dictated by firefox searching for global manifests in that place). So it is not automatically marked as configuration. And as of compatibility level 12 of debhelper it seems to be no longer possible to mark the file as configuration manually (dh_installdeb simply ignores any debian/package.conffiles. Is there a way to work around this? For the reason given above I think the manifest should be marked as a conffile for firefox, too... cheers, sascha [0] https://developer.chrome.com/apps/nativeMessaging -- Sascha Wilde OpenPGP key: 4365844304077279 http://www.intevation.de/ http://www.intevation.de/~wilde/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: PGP signature
Bug#911189: gpgme-json packaging
Hello, as promised by Bernhard in his mail we stated to work on this again. As a first step I created a merge request to deploy gpgme-json together with the library: https://salsa.debian.org/debian/gpgme/-/merge_requests/1 Next I will look into creating specific packages with browser manifests... Cheers sascha -- Sascha Wilde OpenPGP key: 4365844304077279 http://www.intevation.de/ http://www.intevation.de/~wilde/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Bug#911189: gpgme-json packaging
Hello, sorry the work from our side got stuck. We (from Intevation) will be looking into it. Timeframe: first look next week, fix can take a few more days. From my rough understanding: The extension ID would need to go into the personal configuration of the webbrowsers and cannot be configured globally, could it? What is the standard solution for such a situation in Debian? (Hints for this point may help us to get this solved faster.) Best Regards, Bernhard signature.asc Description: This is a digitally signed message part.
Bug#911189: gpgme-json packaging
Has there been any progress with this bug? gpgme-json is already built in the Debian sources, so adding it to a (possibly separate) binary package should not be a big problem. Are there tests failing or missing? Best, Teemu
