golang-github-kelindar-simd and golang-github-kelindar-bitmap: - decide whether to use pristine-tar or not: gbp.conf says it is used, but there is no pristine-tar branches on Salsa
- for golang-github-kelindar-simd, push the upstream/1.2.0 tag - Add to d/copyright 'Roman Atachiants and contributors' since that's what the copyright header in several files says. - The *.go file seems auto-generated, shouldn't they be re-generated by the codegen/ tooling? - I would drop debian/.gitignore for tag2upload --quilt=unapplied compatibility. - consider if using the go team debian/gitlab-ci.yml pipeline is wortwhile (I never found any use for it, but it is standard practice for go team packages). Otherwise ready for upload, and I could sponsor these nobody else does it before me. I could look at 'siso' too later, if needed, but the above two packages needs to be in the archive first. /Simon Juan <[email protected]> writes: > Hi Simon, thanks for the quick reply! > > Regarding your vendoring question: > I have moved 80 dependencies to use debian packages instead. From the > 6 remaining, I created 2 new packages and also provided a rationale in > the vendors subfolder defending why not to package the remaining ones. > > I would need a sponsor yes, I was intending to look for one after the > projects were transferred. Happy to coordinate the new ownership and > the RFS if needed as soon someone volunteers :) > > Cheers, > > Juan > > > Sent from Proton Mail for Android. > > -------- Original Message -------- > On Monday, 05/04/26 at 18:02 Simon Josefsson <[email protected]> wrote: > Juan <[email protected]> writes: > >> Hi team, >> >> siso (RFP #1051557, Chromium's Ninja replacement) is ready for review: >> https://salsa.debian.org/mendezr/siso >> >> It uses dh-golang with 80 Build-Depends, partial vendoring of 6 >> Chromium/Bazel-internal modules in debian/vendor/ (documentedin >> debian/vendor/README.md following the usql pattern), and one patch >> removing the Google Cloud metrics subsystem (84 now not needed >> unpackaged modules). > > Sounds good! > > Did you consider packaging dependencies instead of vendoring? At least > consider asking upstream to properly make public releases of those > modules. > >> I'd like to transfer the following repos to go-team/packages before >> uploading to mentors: >> https://salsa.debian.org/mendezr/siso >> https://salsa.debian.org/mendezr/golang-github-kelindar-simd(ITP#1135383) >> https://salsa.debian.org/mendezr/golang-github-kelindar-bitmap (ITP #1135384) >> If this is appropriate, could someone grant me access to create >> projects under go-team/packages, or fork them from my namespace? > > The best process that I've learned is that you grant someone in the go > team 'Owner' rights to your project, and ask that person to move into > the go-team namespace. Then you will have permissions to the new > project, and there is no unnecessary forking or duplicate copies of the > project, and your old URLs will be redirected. I'm happy to move it > this way if you add 'jas' as owner to that project. And could make some > lightweight review of the packaging as well. Do you need a sponsor for > the upload? > > /Simon >
signature.asc
Description: PGP signature
