Hi Nilesh :) Nilesh Patra wrote:
Peymaneh Nejad wrote:If you are using sbuild, you can build locally with a --extra-package optionIt depends on a newer version of golang-github-klauspost-cpuid-dev than is in the repos. I did a fork of the package (https://salsa.debian.org/peymaneh/golang-github-klauspost-cpuid) for testing until the issue is resolved (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989624) Changelogs have set distribution=experimental.Consider doing similar changes for this one (with d/experimental branch along with a mail to maintainer) as I suggested to do it for golang-github-masterminds-semver-dev in my other mailOkay.Quick comment here: wouldn't it be more straight-forward to simply ping the maintainer(s) of the packages in question first and ask for permission to upload a newer upstream release? That way, an extra upload to experimental could be avoided.By "upload a newer upstream release" do you mean an "upload to unstable"? If that is what you mean, then: Sure, but at the moment we are in deep freeze so new versions of existing packages should be avoided right? Upload from 1.3.1 -> 2.0.6 is a major bump. I'd want to avoid such changes at the moment. One option is that we upload to unstable and it gets blocked by the freeze team, but suppose some package depending on golang-github-klauspost-cpuid has a bug, and new upload is done for it, it'll rebuild with new version of klauspost-cpuid. Something similar happened in the med-team with orthanc package recently, and it became a bit of a mess to fix it.
Sure, you're right about the release process. I totally forgot about that. So indeed let's go with uploading packages to experimental for now and push the packages to unstable as soon as Bullseye is released :)
Kind regards, jonas
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature