What is the best approach to fix that? Keep in mind, I only need a source package(-s) from "testing".On 2023-05-14 14:17:05 +0500, Alexander V. Makartsev wrote:[...]
I think you haven't noticed that I requested for "4.9.1-1" version from "testing" specifically,You can't. You can either request some given version, e.g. 4.9.1-1 (but this will work only if it can be found from your local database), or the version from some given distribution, e.g. "testing". But my point is that your database is obsolete, because if you ask the version from testing, apt thinks that it is 3.2.0-3.1, while it should be 4.9.1-1. You need to fix that.
$ cat /etc/apt/sources.list | grep -iE "testing"
#deb https://deb.debian.org/debian/ testing main contrib non-free
deb-src https://deb.debian.org/debian/ testing main contrib non-free
Of course, I always do "$ sudo apt update" after changing apt config files and before any package manipulation.hence why the command was "$ apt source lego/testing" not just "$ apt source lego". There is no reason for building a backport package for "stable" using a source package from "stable"... I've changed all my repo mirrors to "deb.debian.org" suspecting the previous mirror I used was somehow out-of-date. Why is my output differ from yours? $ apt-show-versions -a lego lego:amd64 3.2.0-3.1+b5 bullseye deb.debian.org No proposed-updates version No stable-updates version No testing version No unstable version lego:amd64 not installed lego:i386 3.2.0-3.1+b5 bullseye deb.debian.org No proposed-updates version No stable-updates version No testing version No unstable version lego:i386 not installedAfter changing your sources.list, you need an "apt update" again.
I see. "rmadison" utility is checking out repos directly, where as "apt-show-versions" rely on local database information.Yet "rmadison" reports there is a version "4.9.1-1" available in "testing": $ rmadison lego lego | 0.3.1-5+b13 | oldstable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x lego | 3.2.0-3.1+b5 | stable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x lego | 4.9.1-1 | testing | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x lego | 4.9.1-1 | unstable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x I suspect "apt-show-versions" output is inconsistent because I only request "deb-src" from "testing" in "sources.list", as I've shown before.Probably. "apt-show-versions" considers only the binary packages (but "lego" is only a binary package).
I see. That explains why I can request source package "golang-github-xenolf-lego/testing" directly and get the right one.[...]I did some additional research and I think I got it. "lego" package is special because its source package is named differently:Yes, as said by apt above: Picking 'golang-github-xenolf-lego' as source package instead of 'lego' [...]But why "apt" doesn't play along, since it knows the source package for "lego" has different name, but ignores the "testing" part of the request? $ apt source lego/testing Reading package lists... Done Picking 'golang-github-xenolf-lego' as source package instead of 'lego' E: Can not find version '3.2.0-3.1' of package 'lego' E: Unable to find a source package for golang-github-xenolf-lego Looks like an "apt" bug to me.Probably not. You are doing a request on a binary package (since "lego" is not a source package). The translation from the binary package to the source package depends on the particular version of the binary package. So lego/testing will correspond to the binary package from testing, which is 3.2.0-3.1+b5 in your case (because of your obsolete database due to the missing "deb" for testing in sources.list). Then apt translates this to the source package (of the same version) golang-github-xenolf-lego 3.2.0-3.1, which is unknown on your machine because the deb-src database is up-to-date (contrary to the deb database). Something like that.