Re: General Questions about Translations and what a package maintainer has to do
Hi,
On Wed, Mar 12, 2025 at 01:06:11PM +0800, Maytham Alsudany wrote:
It might also be worthwhile to forward your message to
debian-i18n@l.d.o, since translators and i18n people are more likely to
be subscribed there and less likely to be subscribed here.
I didn't do that on purpose because the documentation of i18n shows that
the people who are currently writing those docs don't care too much
about actually building packages. I might ask them to review my wiki
page once it is finished.
xgettext comes with a ton of options to help you. Have a look at the
diff I've attached for what I've been able to do.
Will do and take your suggestions. But it is still a wrapper needed.
Note that you shouldn't define the plural stuff in the POT file, that's
something that's set on a per-language basis. There should also be a
newline between the header and first message block.
Noted.
I have seen this being done in debian/rules' clean target which, in
in-tree builds, causes the POT file to be changed as well and I don't
understand at which step of the packaging process it would be a good
idea to commit that POT file. If I build my package out of tree (like I
do out of tradition of svn-buildpackage, I have gbp configured to use
../build-area), the POT file ends up newly generated in the source
package but never gets updated in git. Adduser had POT files from 2022
in git until just recently because I just never noticed. There is no
lintian check and no check inside tracker.d.o for this.
In other packages, there is a dedicated m4 macro to call xgettext which
doesn't make things easier to understand.
Usually, all this stuff with generating and updating POT & PO files is
upstream's responsibility to deal with, hence why you'll find little
documentation for translating anything other than debconf templates.
The mechanism and the pain seems similar to identical. Text => POT =>
PO.
Since this
is a native package, it's up to you to do what you want. My suggestion is to
run this script before release; the most important thing is that it is run
after the program's messages are updated and _finalised_, and before sending it
to translators.
Is it really the right thing to do that in debian/rules clean target? I
don't expect anything to change during that step that I am supposed to
commit, and it does it step in a place that is discarded after build
when doing an out of tree build.
I think that _this_ philosophy belongs in debian-devel, and I am quite
surprised that noone has an opinion about that.
(4)
Then,
msgmerge --update --backup=none --no-fuzzy-matching "${PO_FILE}" "${POT_FILE}"
is called for every existing PO file. This doesn't move the header from
the POT file to the existing PO file so stupidities like "# COPYRIGHT
THE PACKAGE CREATOR" just never get fixed because the translators don't
seem to care.
The header is only touched when the translation is initially created.
I am not sure whether this is good.
I've rarely seen anyone being condemned for fuzzy translations (but then
again, I work in a language team that has virtually no members).
That was an exaggeration. But I have experienced an instance where
somebody helping me called it "unfriendly" to not manually unfuzzy all
translations after fixing a punctuation issue.
In which stage of package build do I do
msgmerge? Do I commit the merged po files, when do I commit them, what
do I do with them during git merge when a feature branch is merged?
In your position, I would leave the translations and the POT file
untouched on the feature branch, and only ever update them on the main
branch after merging.
That doesn't happen when you work on a feature branch and do in-tree
builds. One would have to be careful to NOT commit those changed files,
and people routinely using git add -a (not me) are going to have commits
of relevant changes to their code/packaging and irrelevant changes to
POT/PO files in the same commit.
Yes, in theory, but it's still helpful to attach it for a variety of
reasons e.g. the existing translation is an old garbled mess and
starting new is the best option.
So podebconf-report-po should have an option to include the POT file
even when asking for individual translations?
(6)
Depending on the age of the existing translations, about half of the
messages I send to individual translators are going to bounce. Am I
supposed to report that to debian-i18n@l.d.o as a followup to the
general translation request so that new translators can take up the
outdated translatorless translations? Or am I supposed to send the
general translation request to debian-i18n last so that I can explicitly
mention the translatorless languages there?
According to the manual page (and from what I've seen on
debian-l10n-ar@l.d.o), the language team listed in the PO file (which
should _always_ be debian-l10n-LANG@l.d.o) is Cc'ed by default, so they
will deal with inactive translators. Anyone working on translations
should
Re: keybindings (was: dh-shell-completions: ...)
Quoting Blair Noctis (2025-03-18 11:35:21)
> On 16/03/2025 19:10, M. Zhou wrote:
> > Do you think it is useful to define some flags for
> > dh_shell_completions, like --enable-by-default, --disable-by-default
> > to decide whether a completion file should be enabled by default.
I agree with Blair that shell-completions need no enablement mechanism.
Changing subject accordingly for this subtread.
> > I'm raising this question because I find it somewhat confusing
> > because different shells do the completions and keybindings in very
> > different ways. For instance, fzf:
> > https://salsa.debian.org/go-team/packages/fzf/-/blob/master/debian/README.Debian
> >
> > As you can see, key-binding scripts are similar to completion scripts.
> > Maybe they can be dealt by the same dh module as well. Generally
> > key-binding scripts should not be enabled by default due to potential
> > conflicts.
>
> At a glance yes.
>
> But install keybindings where?
> Shells have standard locations in which completions are immediately enabled.
> Keybindings obviously shouldn't be immediately enabled.
> But are there such standard locations for "disabled" keybindings?
> Your example didn't show existence of such.
> If not, where should we install them to?
> Maybe we can install them as docs or examples,
> but then a debian/$package.{docs/examples} would do.
Regardless of whether keybindings get covered by dh-shell-completions
or end in an independent dh-keybndings package or whatever, I agree that
first some common pattern of how such assets might be organised in the
filesystem needs to be established first - either from current praxis
(which keybindings already get installed today in existing packages?)
or from committee.
I am not even sure what "keybindings" cover, and doubt that any of the
700+ packages I am involved in provides any, so I will leave the details
to those actually involved in needing infrastructure for such assets.
One more general remark, though: Do *not* rely on assets located below
/usr/share/doc - e.g. don't package some asset there and instruct users
to symlink that asset to somewhere "inside" the core system, because
the system must not rely on that path existing on a system at all
(I think it is covered in Debian Policy somewhere, just too lazy to look
right now). Instead, place assets e.g. below /usr/share// - or if
you really must put it as part of the documentation then make sure to
only ever instruct to *copy* the asset elsewhere (which is most likely a
bad idea for maintenance of such system).
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
Bug#1100761: ITP: golang-github-tink-crypto-tink-go-gcpkms -- Extension to Tink Go that provides Google Cloud KMS integration
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-tink-crypto-tink-go-gcpkms Version : 2.2.0-1 Upstream Author : Tink Cryptography Library * URL : https://github.com/tink-crypto/tink-go-gcpkms * License : Apache-2.0 Programming Lang: Go Description : Extension to Tink Go that provides Google Cloud KMS integration Tink Go Google Cloud KMS extension . This is an extension to the Tink Go (https://github.com/tink-crypto/tink- go) library that provides support for Google Cloud KMS. https://salsa.debian.org/go-team/packages/golang-github-tink-crypto-tink-go-gcpkms https://salsa.debian.org/jas/golang-github-tink-crypto-tink-go-gcpkms/-/pipelines /Simon signature.asc Description: PGP signature
Re: General Questions about Translations and what a package maintainer has to do
On Tue, Mar 11, 2025 at 10:10:51PM +0900, Simon Richter wrote: I'm on mobile, so only a quick reply: merging should be done with msgmerge as well — you need to call it twice, once with the po files from both branches, and once again with the pot file to fix all the location comments and fuzzy flags. That sounds really interesting. Did anybody include this in git like for the excellent dpkg-mergechangelogs, so that it can be done automatically? If doing that automatically doesn't work, I would love to see a complete usecase. Alternatively, you can define a filter in git to remove(!) locations on checkout and restore them from the pot file on commit, that solves the majority of conflicts. How would that look like? git filters are a mystery for those wizards. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Can anyone help with telegram-desktop?
On Tue, Mar 18, 2025 at 07:23:33AM +0100, Salvo Tomaselli wrote: > > I was also curious if somebody cares about it enough to fix those. > > I only found out very recently that it's not in good state, because I was > installing debian 13 on a new device and couldn't find the package, so I > figured > it must have been removed. For what is worth, I am in contact with the original maintainer, who had some health problems last year. I contacted him just yesterday, but unfortunately he said that despite his interest he is unlikely to start working until mid-April :( -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Re: dh-shell-completions: simple debhelper addon to install shell completions
On 16/03/2025 19:10, M. Zhou wrote:
On Sun, 2025-03-16 at 18:47 +, Blair Noctis wrote:
Kind of a shameless plug, but enough people said it's useful so I thought might
as well let more know.
I'll not go into great details, because there isn't any. Just check its man
page and source code:
https://manpages.debian.org/unstable/dh-shell-completions/dh_shell_completions.1.en.html
https://salsa.debian.org/debian/dh-shell-completions
Thank you for this dh module! After browsing the examples, I came up with
an old problem about these completion scripts -- whether the completions
should be loaded by default, and whether that behavior should be synced
among shells.
Completions are static (relative to a specific version of the program).
There seems no need to modify them.
There seems no need to disable them.
They don't seem to cause harm.
So I don't think enabling them by default would cause any trouble.
Different shells could have different conventions.
But the status quo is, to my knowledge,
most packages just install completions as immediately enabled.
I don't think such differences, even if they exist, matter anymore.
Do you think it is useful to define some flags for
dh_shell_completions, like --enable-by-default, --disable-by-default
to decide whether a completion file should be enabled by default.
I'm raising this question because I find it somewhat confusing
because different shells do the completions and keybindings in very
different ways. For instance, fzf:
https://salsa.debian.org/go-team/packages/fzf/-/blob/master/debian/README.Debian
As you can see, key-binding scripts are similar to completion scripts.
Maybe they can be dealt by the same dh module as well. Generally
key-binding scripts should not be enabled by default due to potential
conflicts.
At a glance yes.
But install keybindings where?
Shells have standard locations in which completions are immediately enabled.
Keybindings obviously shouldn't be immediately enabled.
But are there such standard locations for "disabled" keybindings?
Your example didn't show existence of such.
If not, where should we install them to?
Maybe we can install them as docs or examples,
but then a debian/$package.{docs/examples} would do.
Also, the package name is already there.
I'd rather something named "shell-completions",
not handle things other than, well, shell completions.
A quick search suggests that both policy and devref do not cover
the shell integration topic.
An example that resembles what I'm talking about is dh_installsystemd.
It has --no-enable, --restart-after-upgrade, --no-restart-after-upgrade,
etc flags to control the systemd unit behavior upon dpkg actions.
There are also packages with service definitions that can't be used as is.
Or even unwanted by the user.
They can at most be installed as docs or examples.
IMO this situation is akin to keybinding scripts.
--
Sdrager,
Blair Noctis
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Call for participation in tag2upload closed beta
Hello, On Wed 19 Mar 2025 at 12:25am +01, Simon Josefsson wrote: > Sean Whitton writes: > >> That should be enough! If you were able to do at least one upload using >> 'dgit push-source' for each package to confirm everything is okay, that >> would be great. > > I'll try. I got a SSH push warning on first use -- how would I verify > this host SSH key? What's the risk uploaders getting MITM'ed here? > > The authenticity of host 'push.dgit.debian.org (2001:41b8:202:deb::311:78)' > can't be established. > ED25519 key fingerprint is SHA256:O4i2PPFELuj49wYZSwLt+a2r356sB19KMCFhrUKkYiM. > This key is not known by any other names. > Are you sure you want to continue connecting (yes/no/[fingerprint])? I would suggest grabbing /etc/ssh/known_hosts from a Debian host for which you already have the host key cached. -- Sean Whitton
Re: General Questions about Translations and what a package maintainer has to do
On Wed, Mar 12, 2025 at 11:36:27AM +0100, Julien Plissonneau Duquène wrote:
Le 2025-03-11 12:03, Marc Haber a écrit :
(2)
There is some point in the development process when it is time to ask
for translations. Translators need a POT file which contains all the
translatable strings, and they make a PO file from that which contains
the actual translation.
That's for the initial translation. Once there is a .po they will
update it directly and don't need or use the .pot anymore.
So all love I put into the POTs header will go unnoticed and I'll need
to pay attention to individual translations' header until somebody else
cares.
(4)
Then,
msgmerge --update --backup=none --no-fuzzy-matching "${PO_FILE}"
"${POT_FILE}"
is called for every existing PO file. This doesn't move the header from
the POT file to the existing PO file so stupidities like "# COPYRIGHT
THE PACKAGE CREATOR" just never get fixed because the translators don't
seem to care.
I'm not sure the --no-fuzzy-matching helps here (see below).
Since --no-fuzzy-matching is just superficially documented, ...
Also I
note that msgmerge is not used at all in devscripts packaging, which
only uses po4a instead. Maybe you could look there if it could help
your case.
po4a seems to try to do those things automatically, using msgmerge as a
subprocess.
In a few cases there is spurious "fuzzing", e.g. when the source
message uses `...' for quoting where it shoud have been using \"...\".
In some of these cases it may be possible to fix the issue in the
source message, but I believe other cases are actually bugs in
msgmerge. Are these what your translators are asking you to deal with?
Not directly the translators, but many years ago somebody who helped me
with making a package fit for translation mentioned that such changes
are unfriendly to translators and that one should handle those manually
and unfuzz things (in a manual process that seemed clumsy and
error-prone to me even back then).
On a merge request I would just post comments to ask the translator to
fix the headers metadata and licensing, but may still deal with
normalizing/rewrapping myself (e.g. by adding a commit to the MR where
possible). If this were exchanged over e-mail I would probably fix
most trivial things myself.
So you're saying that as package maintainer I can freely edit headers
and metadata for translations, putting the PO file into a mixed domain
between package maintainer and the respective translator?
² adduser has strings that get used in both translated and untranslated
form, making sure that messages written to the console are translated
and messages written to syslog are written in English to make handling
bug repors easier
The "industrial" way to deal with in other (usually large) projects is
to pre/postfix all source log messages with a unique identifier e.g.
"(ADDUSER-1234)". This makes it possible to have tech-support-friendly
and end-user-friendly translated log messages, and as an added benefit
it has excellent SEO characteristics when it comes to searching for
workarounds on the web or in a knowledge base.
Yes, I'd rather not do that because my inner monk would first cause me
spending a few days to catalogize and abstract adduser's messages. Time
that I'd rahter not spend at the moment.
³ I have received translations that were obviously done against the POT
file from stable.
That's a start, I guess. Maybe in these cases you can keep the .po
file as submitted for proposed updates, merge it in unstable and
nicely ask the translator to also please work on the upcoming version.
But translating a stable package does show a blatant non-understanding
of Debian's development mechanisms! How am I supposed to trust people
who care THIS little about the project they're contributing to?
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Can anyone help with telegram-desktop?
> There is a chance that the fix can be extracted from the current upstream > version. True, I'll have a look next Sunday I guess if there's something > Ideally, of course, the new upstream version should just be > packaged, but I don't see this happening without the original maintainer > unless someone spends a really large amount of time learning the package > and updating it. I tried, but other things needs to be packaged as well. > And there is that problem with ARM symbols, which happens in some I've seen failures on 32 bit architectures after the t64 transition. I'm inclined to just drop the architecture if the fix is not trivial. I don't think telegram-desktop has any 32 bit ARM user. Best -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei https://ltworf.codeberg.page/ signature.asc Description: This is a digitally signed message part.
Re: Call for participation in tag2upload closed beta
Sean Whitton writes: >> Packages (for example): libntlm, cppi, git2cl, guile-fibers > > That should be enough! If you were able to do at least one upload using > 'dgit push-source' for each package to confirm everything is okay, that > would be great. Should be done for libntlm, git2cl and guile-fibers now. Dgit didn't like cppi, doesn't it handle bare-debian/-style packaging? See: https://salsa.debian.org/debian/cppi I used this command: dgit --gbp push-source --deliberately-not-fast-forward Based on my understanding of: https://manpages.debian.org/testing/dgit/dgit-maint-gbp.7.en.html#UPLOADING I'm doing this on a laptop running Trisquel aramo (Ubuntu 22.04 clone) with plenty of packages installed from Guix, including GnuPG, git and even dpkg. I was positively surprised dgit didn't blow up, good job! /Simon signature.asc Description: PGP signature
Re: Call for participation in tag2upload closed beta
Hello, On Sat 15 Mar 2025 at 01:03pm +01, Johannes Schauer Marin Rodrigues wrote: > Hi Sean, > > Quoting Sean Whitton (2025-03-15 02:49:58) >> - (At least some of) the packages are uploaded relatively often. > > with the upcoming freeze, I do not expect too many uploads to be necessary > (but > can be done if needed). But is that a problem? No, no problem, should be okay. We just wanted to point out that if it something you upload once per release cycle, there is probably not much point in signing up for that package. >> - You already use dgit to upload. > > The wiki page says to use git-debpush from src:dgit. Which version of > git-debpush is new enough? Does the version from Bookworm work? As of last weekend's point release, yes, it does :) >> If you'd like to sign up, write to us at , specifying >> a list of your packages for which we should enable tag2upload processing, and >> confirming you have your co-maintainers agreement. > > No co-maintainers and happy to try out tag2upload for: box64, > ldraw-parts-free, > pico-sdk, picotool, vcmi, img2pdf, plakativ > > Co-maintainer (Jochen) agrees: sbuild Thanks, that's great. -- Sean Whitton
Re: Call for participation in tag2upload closed beta
Hello, On Sat 15 Mar 2025 at 11:40am +01, Simon Josefsson wrote: > Yay! > > I'm happy to beta-test this. Exactly what features are required from > dgit to be able to use tag2upload? Maybe I can offer myself to vet the > process as a package maintainer that only minimally uses dgit, assuming > that I can manage to install and get dgit to work on my machine. A > simple 'dpkg -i' of 12.9 worked now, and I was able to run 'dgit build' > in my existing libntlm git clone. I haven't been using dgit before > this, but maybe this is sufficient to count me as a dgit user. > > Packages (for example): libntlm, cppi, git2cl, guile-fibers That should be enough! If you were able to do at least one upload using 'dgit push-source' for each package to confirm everything is okay, that would be great. -- Sean Whitton
Re: Call for participation in tag2upload closed beta
Sean Whitton writes: > That should be enough! If you were able to do at least one upload using > 'dgit push-source' for each package to confirm everything is okay, that > would be great. I'll try. I got a SSH push warning on first use -- how would I verify this host SSH key? What's the risk uploaders getting MITM'ed here? The authenticity of host 'push.dgit.debian.org (2001:41b8:202:deb::311:78)' can't be established. ED25519 key fingerprint is SHA256:O4i2PPFELuj49wYZSwLt+a2r356sB19KMCFhrUKkYiM. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? /Simon signature.asc Description: PGP signature
Re: Growing new FTP-masters (Re: Bits from DPL)
Hello, On Sun 09 Mar 2025 at 01:57pm GMT, Simon McVittie wrote: > Do I assume correctly that this principle can be weakened for > experimental-NEW? > > As a general principle I think uploads to NEW that are more complicated than a > completely new leaf package should usually be to experimental, unless there is > a reason why this specific package can't (for example if foo_2.0 is already in > experimental and now the maintainer needs a package-split or a new SONAME for > foo_1.2 in unstable). A lot of the time the NEW package will need a new > sourceful upload after it's been accepted *anyway*, to get a source-only > upload that can migrate to testing - and if the package is in binary-NEW > because it has a new SONAME, it's better to have the maintainer and not the > ftp team be in control of the point at which it hits unstable and starts a > transition. > > Does the ftp team agree with that as a general idea? And if a largeish > dependency graph needs uploading together, is it OK to upload them all to > experimental-NEW, with the idea that if the ftp team accepts them in the wrong > order they'll just sit in BD-Uninstallable status until the whole batch has > been processed, with no real harm done? Yes, I think that is fine. -- Sean Whitton
Re: Call for participation in tag2upload closed beta
Hello, On Wed 19 Mar 2025 at 12:58am +01, Simon Josefsson wrote: > Sean Whitton writes: > >>> Packages (for example): libntlm, cppi, git2cl, guile-fibers >> >> That should be enough! If you were able to do at least one upload using >> 'dgit push-source' for each package to confirm everything is okay, that >> would be great. > > Should be done for libntlm, git2cl and guile-fibers now. Dgit didn't > like cppi, doesn't it handle bare-debian/-style packaging? See: > https://salsa.debian.org/debian/cppi It has --quilt=baredebian+git and --quilt=baredebian+tarball for this -- please give one of those a try. > I used this command: > > dgit --gbp push-source --deliberately-not-fast-forward > > Based on my understanding of: > > https://manpages.debian.org/testing/dgit/dgit-maint-gbp.7.en.html#UPLOADING Great, thank you for reporting back! > I'm doing this on a laptop running Trisquel aramo (Ubuntu 22.04 clone) > with plenty of packages installed from Guix, including GnuPG, git and > even dpkg. I was positively surprised dgit didn't blow up, good job! We run CI based on installing the latest git HEAD all the way back to buster :) Glad it is proving itself worthwhile. -- Sean Whitton
Re: Call for participation in tag2upload closed beta
Sean Whitton writes: >> Should be done for libntlm, git2cl and guile-fibers now. Dgit didn't >> like cppi, doesn't it handle bare-debian/-style packaging? See: >> https://salsa.debian.org/debian/cppi > > It has --quilt=baredebian+git and --quilt=baredebian+tarball for this > -- please give one of those a try. It worked, thank you! For reference: dgit --gbp push-source --quilt=baredebian+tarball --deliberately-not-fast-forward How do I make the next upload using tag2upload? /Simon signature.asc Description: PGP signature
Bug#1100812: ITP: golang-github-smallstep-scep -- Go SCEP server
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-smallstep-scep Version : 0.0~git20250221.171a5fa-1 Upstream Author : Smallstep * URL : https://github.com/smallstep/scep * License : Expat Programming Lang: Go Description : Go SCEP server scep is a Golang implementation of the Simple Certificate Enrollment Protocol (SCEP). . This package started its life as part of micromdm/scep (https://github.com/micromdm/scep). The core SCEP protocol was extracted from it and is now being maintained by smallstep (https://smallstep.com). https://salsa.debian.org/go-team/packages/golang-github-smallstep-scep https://salsa.debian.org/jas/golang-github-smallstep-scep/-/pipelines/ /Simon signature.asc Description: PGP signature
Bug#1100752: ITP: golang-github-tink-crypto-tink-go -- Go implementation of Tink
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-tink-crypto-tink-go Version : 2.3.0-1 Upstream Author : Tink Cryptography Library * URL : https://github.com/tink-crypto/tink-go * License : Apache-2.0 Programming Lang: Go Description : crypto library Tink in Go Using crypto in your application shouldn't have to (https://www.usenix.org/sites/default/files/conference/protected- files/hotsec15_slides_green.pdf) feel like juggling chainsaws in the dark. Tink is a crypto library written by a group of cryptographers and security engineers at Google. It was born out of our extensive experience working with Google's product teams, fixing weaknesses in implementations (https://github.com/google/wycheproof), and providing simple APIs that can be used safely without needing a crypto background. . Tink provides secure APIs that are easy to use correctly and hard(er) to misuse. It reduces common crypto pitfalls with user-centered design, careful implementation and code reviews, and extensive testing. At Google, Tink is one of the standard crypto libraries, and has been deployed in hundreds of products and systems. . To get a quick overview of Tink's design please take a look at Tink's goals (https://developers.google.com/tink/design/goals_of_tink). . The official documentation is available at (https://developers.google.com/tink). https://salsa.debian.org/go-team/packages/golang-github-tink-crypto-tink-go https://salsa.debian.org/jas/golang-github-tink-crypto-tink-go/-/pipelines /Simon signature.asc Description: PGP signature
Bug#1100754: ITP: golang-github-tink-crypto-tink-go-awskms -- Extension to Tink Go that provides AWS KMS integration
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-tink-crypto-tink-go-awskms Version : 2.1.0-1 Upstream Author : Tink Cryptography Library * URL : https://github.com/tink-crypto/tink-go-awskms * License : Apache-2.0 Programming Lang: Go Description : Extension to Tink Go that provides AWS KMS integration Tink Go Amazon Web Services (AWS) Key Management Service (KMS) extension. https://salsa.debian.org/go-team/packages/golang-github-tink-crypto-tink-go-awskms https://salsa.debian.org/jas/golang-github-tink-crypto-tink-go-awskms/-/pipelines /Simon signature.asc Description: PGP signature
