Re: RFS: golang-github-muesli-cancelreader and golang-github-mattn-go-localereader
Dear Nilesh, thank you for your feedback. On 31.10.2022 19:42, Nilesh Patra wrote: Is it worth inclduign in debian? Or could target package simply be patched for the functionalities? I wanted to include it, as it is a build dependency of newer golang-github-charmbracelet-bubbletea versions. But I can also have a look if I can patch the package. Best regards, Martin signature.asc Description: PGP signature
Re: RFS: golang-github-muesli-cancelreader and golang-github-mattn-go-localereader
Dear all, I managed to get this patched into bubbletea [0] and once cancelreader [1] hits sid bubbletea could be uploaded if the patching is alright. [0] https://salsa.debian.org/go-team/packages/golang-github-charmbracelet-bubbletea [1] https://salsa.debian.org/go-team/packages/golang-github-muesli-cancelreader Best regards, Martin signature.asc Description: PGP signature
Re: RFS: golang-github-caarlos0-sshmarshal
Dear Nilesh, On 31.10.2022 19:57, Nilesh Patra wrote: Since this has just one patch applied, it'd be better to try to integrate that patch into x-crypto. I applied the patch to golang-go.crypto but I am reluctant to push it as it fails to build and therefore I can't run ratt. But this might be a local problem as it also doesn't build successfully without the patch applied. Best regards, Martin signature.asc Description: PGP signature
Re: RFS: golang-github-caarlos0-sshmarshal
On Wed, Nov 2, 2022 at 3:01 AM Martin Dosch wrote: > > Dear Nilesh, > > On 31.10.2022 19:57, Nilesh Patra wrote: > >Since this has just one patch applied, it'd be better to try to > >integrate that patch > >into x-crypto. > > I applied the patch to golang-go.crypto but I am reluctant to push it as > it fails to build and therefore I can't run ratt. But this might be a > local problem as it also doesn't build successfully without the patch > applied. > Let's not carry a local patch in golang-go.crypto. Please work with upstream to include that. golang-github-caarlos0-sshmarshal refers https://github.com/golang/go/issues/37132. The issue says it's "Proposal-Accepted". So upstream won't reject the patch as long as it is in good shape. The patch is stalled for 2 years, because the author doesn't address the reviewer's comments. We should not include local patches for such a reason. -- Shengjing Zhu
Re: RFS: golang-github-caarlos0-sshmarshal
On Tue, Nov 01, 2022 at 08:00:47PM +0100, Martin Dosch wrote: > On 31.10.2022 19:57, Nilesh Patra wrote: > > Since this has just one patch applied, it'd be better to try to > > integrate that patch > > into x-crypto. > > I applied the patch to golang-go.crypto but I am reluctant to push it as it > fails to build and therefore I can't run ratt. But this might be a local > problem as it also doesn't build successfully without the patch applied. When I said integrate the patch, I meant it needs to be integrated "upstream" In general, changes that can be applied upstream, should be applied upstream. We should never carry such a baggage on our packages unless there is a strong reason to do so. Please consider to work with upstream to get the changes pulled. Meanwhile you could consider to embed this package if you are in some hurry, but given that we are close to freeze, this could be a bad idea. -- Best, Nilesh signature.asc Description: PGP signature
Re: RFS: golang-github-caarlos0-sshmarshal
Dear Shengjing, On 02.11.2022 03:12, Shengjing Zhu wrote: Let's not carry a local patch in golang-go.crypto. Please work with upstream to include that. There is already someone working to bring it upstream: https://go-review.googlesource.com/c/crypto/+/218620 As you can see the latest changes were done end of September. We should not include local patches for such a reason. So, do you think it makes sense to package golang-github-caarlos0-sshmarshal until upstream merges the patch? Best regards, Martin signature.asc Description: PGP signature
Re: RFS: golang-github-caarlos0-sshmarshal
Dear Nilesh, When I said integrate the patch, I meant it needs to be integrated "upstream" In general, changes that can be applied upstream, should be applied upstream. Sorry, seems I got this wrong. Meanwhile you could consider to embed this package if you are in some hurry, but given that we are close to freeze, this could be a bad idea. Actually all this work to get the charmbracelet packages into shape is only necessary as a new version of golang-github-protonmail-go-crypto is breaking golang-github-charmbracelet-wish and updating golang-github-charmbracelet-wish fixes this. I'd like to have a recent version golang-github-protonmail-go-crypto in bookworm as two of my packages depend on it and I was thinking it might be helpful to have tho most recent versions in bookworm, just in case I have to do some backports after the release. Best regards, Martin signature.asc Description: PGP signature
Bug#1023287: ITP: golang-github-github-smimesign -- An S/MIME signing utility for use with Git
Package: wnpp Severity: wishlist Owner: Leo Antunes * Package name: golang-github-github-smimesign Version : 0.2.0-1 Upstream Author : GitHub * URL : https://github.com/github/smimesign * License : Expat Programming Lang: Go Description : An S/MIME signing utility for use with Git Smimesign is an S/MIME signing utility that is compatible with Git. This allows developers to sign their Git commits and tags using X.509 certificates issued by public certificate authorities or their organization's internal certificate authority.
Re: RFS: golang-github-caarlos0-sshmarshal
Hi Martin, On Tue, Nov 01, 2022 at 08:25:25PM +0100, Martin Dosch wrote: > > Meanwhile you could consider to embed this package if you are in some > > hurry, but > > given that we are close to freeze, this could be a bad idea. > Actually all this work to get the charmbracelet packages into shape is only > necessary as a new version of golang-github-protonmail-go-crypto is breaking > golang-github-charmbracelet-wish and updating > golang-github-charmbracelet-wish fixes this. I don't have time to dig into this, but is there a patch there which could fix the breaking change, and which does not use golang-github-caarlos0-sshmarshal? Or is there a way to circumvent the build failure w/o updates? > I'd like to have a recent > version golang-github-protonmail-go-crypto in bookworm as two of my packages > depend on it and I was thinking it might be helpful to have tho most recent > versions in bookworm, just in case I have to do some backports after the > release. If this is SUPER-urgent/important, embed that package into the target package with a vendor/ directory. You will need to use a multi-orig tarball for this, here is how to do so[1] and I wrote a smaller version it sometime back here[2], and here is a go package that actually does that[3] Please number the upstream version as version-1~vendor so that version-1 can superseed it - if you happen to choose this option. [1]: https://wiki.debian.org/Javascript/GroupSourcesTutorial [2]: https://med-team.pages.debian.net/policy/#embedding-large-test-data [3]: https://salsa.debian.org/go-team/packages/gitaly/-/tree/master/ -- Best, Nilesh signature.asc Description: PGP signature
Bug#1023288: ITP: golang-github-certifi-gocertifi -- curated collection of Root Certificates
Package: wnpp Severity: wishlist Owner: Leo Antunes * Package name: golang-github-certifi-gocertifi Version : 2021.04.29-1 Upstream Author : Certifi * URL : https://github.com/certifi/gocertifi * License : MPL-2.0 Programming Lang: Go Description : curated collection of Root Certificates This Go package contains a CA bundle that you can reference in your Go code. This is useful for systems that do not have CA bundles that Golang can find itself, or where a uniform set of CAs is valuable. . This is the same CA bundle that ships with the Python Requests (https://github.com/kennethreitz/requests) library, and is a Golang specific port of certifi (https://github.com/kennethreitz/certifi). The CA bundle is derived from Mozilla's canonical set.
Re: RFS: golang-github-caarlos0-sshmarshal
Dear Nilesh, On 02.11.2022 01:08, Nilesh Patra wrote: If this is SUPER-urgent/important, embed that package into the target package with a vendor/ directory. You will need to use a multi-orig tarball for this, here is how to do so[1] and I wrote a smaller version it sometime back here[2], and here is a go package that actually does that[3] Thank you for the info. I'll also have little time for packaging over the next week and will let it rest for now. Later I'll decide whether it's important to get those updates into bookworm or whether I'll just wait till upstream imported the patch. :) Please number the upstream version as version-1~vendor so that version-1 can superseed it - if you happen to choose this option. I will do this if I choose this option. Best regards, Martin signature.asc Description: PGP signature
