Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #258253 > unrolled thread

How to download source package using only console?

Back to article view | Back to linux.debian.user

Contents

  How to download source package using only console? "Alexander V. Makartsev" <avbetev@gmail.com> - 2023-05-13 21:20 +0200
    Re: How to download source package using only console? Vincent Lefevre <vincent@vinc17.net> - 2023-05-14 07:10 +0200
      Re: How to download source package using only console? "Alexander V. Makartsev" <avbetev@gmail.com> - 2023-05-14 11:20 +0200
        Re: How to download source package using only console? Greg Wooledge <greg@wooledge.org> - 2023-05-14 15:20 +0200
        Re: How to download source package using only console? Vincent Lefevre <vincent@vinc17.net> - 2023-05-15 02:50 +0200
          Re: How to download source package using only console? "Alexander V. Makartsev" <avbetev@gmail.com> - 2023-05-15 07:30 +0200
            Re: How to download source package using only console? Vincent Lefevre <vincent@vinc17.net> - 2023-05-15 12:30 +0200
              Re: How to download source package using only console? "Alexander V. Makartsev" <avbetev@gmail.com> - 2023-05-15 21:50 +0200

#258253 — How to download source package using only console?

[Multipart message — attachments visible in raw view] — view raw

Hello, fellow Debian users.

When I need to build a backport of a package, I sometimes find it 
difficult to obtain actual source package(-s) from Debian repos using 
console.
Following advice from a wiki page [1], after "apt update", doesn't do it:

    $ 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

Any other seemingly intended ways also fail in a similar fashion:

    $ dget lego=4.9.1-1
    dget: no hostnames in apt-cache policy lego for version 4.9.1-1 found

    $ apt-get source lego -t testing
    Reading package lists... Done
    E: The value 'testing' is invalid for APT::Default-Release as such a
    release is not available in the sources
    E: Unable to find a source package for

Trying to do the same for another package seems to work:

    $ apt source ipcalc/testing
    Reading package lists... Done
    Selected version '0.42-2' (testing) for ipcalc
    Need to get 33,7 kB of source archives.
    Get:1 https://mirror.yandex.ru/debian testing/main ipcalc 0.42-2
    (dsc) [1 692 B]
    Get:2 https://mirror.yandex.ru/debian testing/main ipcalc 0.42-2
    (tar) [25,9 kB]
    Get:3 https://mirror.yandex.ru/debian testing/main ipcalc 0.42-2
    (diff) [6 144 B]
    Fetched 33,7 kB in 1s (52,5 kB/s)
    dpkg-source: info: extracting ipcalc in ipcalc-0.42
    dpkg-source: info: unpacking ipcalc_0.42.orig.tar.gz
    dpkg-source: info: unpacking ipcalc_0.42-2.debian.tar.xz
    dpkg-source: info: using patch list from debian/patches/series
    dpkg-source: info: applying 01-paths.patch


So why those fail for a "lego" package and is there a way to solve this 
once and for all?
I know I can go to a packages website [2] and manually download ".dsc" 
file and feed it to "dget" utility, or download source files directly 
from said website, but there has to be a better way.

Some useful info:

    $ cat /etc/apt/sources.list | grep -iE "testing"
    #deb https://mirror.yandex.ru/debian/ testing main contrib non-free
    deb-src https://mirror.yandex.ru/debian/ testing main contrib non-free

    $ 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

    $ uname -a
    Linux host0 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22)
    x86_64 GNU/Linux



[1] https://wiki.debian.org/SimpleBackportCreation
[2] https://packages.debian.org/bookworm/lego

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [next] | [standalone]

#258276

On 2023-05-14 00:15:39 +0500, Alexander V. Makartsev wrote:
> Hello, fellow Debian users.
> 
> When I need to build a backport of a package, I sometimes find it difficult
> to obtain actual source package(-s) from Debian repos using console.
> Following advice from a wiki page [1], after "apt update", doesn't do it:
> 
>    $ 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

zira:~> apt-show-versions -a lego
lego:amd64 3.2.0-3.1+b5 stable   ftp.debian.org
No stable-updates version
lego:amd64 4.9.1-1      testing  ftp.debian.org
lego:amd64 4.9.1-1      unstable ftp.debian.org
No experimental version
lego:amd64 not installed

Indeed, 3.2.0-3.1 is no longer the testing version. Your database
seems to be out-of-date.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#258285

[Multipart message — attachments visible in raw view] — view raw

On 14.05.2023 10:06, Vincent Lefevre wrote:
> On 2023-05-14 00:15:39 +0500, Alexander V. Makartsev wrote:
>> Hello, fellow Debian users.
>>
>> When I need to build a backport of a package, I sometimes find it difficult
>> to obtain actual source package(-s) from Debian repos using console.
>> Following advice from a wiki page [1], after "apt update", doesn't do it:
>>
>>     $ 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
> zira:~> apt-show-versions -a lego
> lego:amd64 3.2.0-3.1+b5 stableftp.debian.org
> No stable-updates version
> lego:amd64 4.9.1-1      testingftp.debian.org
> lego:amd64 4.9.1-1      unstableftp.debian.org
> No experimental version
> lego:amd64 not installed
>
> Indeed, 3.2.0-3.1 is no longer the testing version. Your database
> seems to be out-of-date.
>
I think you haven't noticed that I requested for "4.9.1-1" version from 
"testing" specifically,
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 installed

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.

Here is another example package that works as expected:

    $ rmadison roundcube
    roundcube  | 1.3.17+dfsg.1-1~deb10u2         | oldstable        |
    source, all
    roundcube  | 1.4.13+dfsg.1-1~deb11u1~bpo10+1 | buster-backports |
    source, all
    roundcube  | 1.4.13+dfsg.1-1~deb11u1         | stable           |
    source, all
    roundcube  | 1.6.1+dfsg-1                    | testing          |
    source, all
    roundcube  | 1.6.1+dfsg-1                    | unstable         |
    source, all

    $ apt-show-versions -a roundcube
    roundcube:all 1.4.13+dfsg.1-1~deb11u1 bullseye          deb.debian.org
    roundcube:all 1.4.13+dfsg.1-1~deb11u1 bullseye-security deb.debian.org
    No proposed-updates version
    No stable-updates version
    No testing version
    No unstable version
    roundcube:all not installed

    $ apt source roundcube/testing
    Reading package lists... Done
    Selected version '1.6.1+dfsg-1' (testing) for roundcube
    ...


I did some additional research and I think I got it.
"lego" package is special because its source package is named differently:

    $ rmadison golang-github-xenolf-lego
    golang-github-xenolf-lego | 0.3.1-5       | oldstable      | source
    golang-github-xenolf-lego | 3.2.0-3.1     | stable         | source
    golang-github-xenolf-lego | 4.9.1-1       | testing        | source
    golang-github-xenolf-lego | 4.9.1-1       | unstable       | source
    golang-github-xenolf-lego | 4.9.1-1       | unstable-debug | source

    $ apt source golang-github-xenolf-lego/testing
    Reading package lists... Done
    Selected version '4.9.1-1' (testing) for golang-github-xenolf-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.


-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#258291

On Sun, May 14, 2023 at 02:17:05PM +0500, Alexander V. Makartsev wrote:
> 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"...

If you're trying to build a backport, you add "deb-src" lines for
testing, then "apt-get update", and then simply use
"apt-get source pkgname".  Or their "apt" equivalents, I guess.

[toc] | [prev] | [next] | [standalone]

#258317

On 2023-05-14 14:17:05 +0500, Alexander V. Makartsev wrote:
> On 14.05.2023 10:06, Vincent Lefevre wrote:
> > On 2023-05-14 00:15:39 +0500, Alexander V. Makartsev wrote:
> > > Hello, fellow Debian users.
> > > 
> > > When I need to build a backport of a package, I sometimes find it difficult
> > > to obtain actual source package(-s) from Debian repos using console.
> > > Following advice from a wiki page [1], after "apt update", doesn't do it:
> > > 
> > >     $ 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
> > zira:~> apt-show-versions -a lego
> > lego:amd64 3.2.0-3.1+b5 stableftp.debian.org
> > No stable-updates version
> > lego:amd64 4.9.1-1      testingftp.debian.org
> > lego:amd64 4.9.1-1      unstableftp.debian.org
> > No experimental version
> > lego:amd64 not installed
> > 
> > Indeed, 3.2.0-3.1 is no longer the testing version. Your database
> > seems to be out-of-date.
> > 
> 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.

> 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 installed

After changing your sources.list, you need an "apt update" again.

> 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 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.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#258330

[Multipart message — attachments visible in raw view] — view raw

On 15.05.2023 05:43, Vincent Lefevre wrote:
> 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.
What is the best approach to fix that? Keep in mind, I only need a 
source package(-s) from "testing".
So, just to be safe, "deb" source for "testing" was commented out:

    $ 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


>> 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 installed
> After changing your sources.list, you need an "apt update" again.
Of course, I always do "$ sudo apt update" after changing apt config 
files and before any package manipulation.

>> 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. "rmadison" utility is checking out repos directly, where as 
"apt-show-versions" rely on local database information.

> [...]
>> 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.
>
I see. That explains why I can request source package 
"golang-github-xenolf-lego/testing" directly and get the right one.
So, in my case, I won't be able to reliably get a source package(-s) 
from "testing" if I don't add "deb" part of "testing" to "sources.list", 
which could be a different can of worms...
Is this something for me to just be aware of and leave it as is now, or 
is there more elegant solution?

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#258340

On 2023-05-15 10:25:45 +0500, Alexander V. Makartsev wrote:
> On 15.05.2023 05:43, Vincent Lefevre wrote:
> > 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.
> What is the best approach to fix that? [...]

That:

[...]
> I see. That explains why I can request source package
> "golang-github-xenolf-lego/testing" directly and get the right one.
> So, in my case, I won't be able to reliably get a source package(-s) from
> "testing" if I don't add "deb" part of "testing" to "sources.list", which
> could be a different can of worms...
> Is this something for me to just be aware of and leave it as is now, or is
> there more elegant solution?

Well, if you don't want the "deb" part, you need to provide the
name of the source package directly to "apt source". If you do that
frequently, you can write a script. There are 2 solutions:
* A remote request, e.g. with rmadison.
* Something based of "apt cache show". From that, you can get the
  source package, then call "apt source" with the source package.
  But note that this is only a heuristic; if the name of the source
  package has changed from stable to testing, this won't work.

Note that adding the "deb" part shouldn't be much an issue (except
noise, e.g. with "apt cache show", which would give output for both
stable and testing). If you want to make sure that a package from
testing won't be installed by mistake (by apt), I suppose that you
can use apt preferences with a negative priority for testing to
prevent such an installation:

Package: *
Pin: release a=testing
Pin-Priority: -1

(not tried). See the apt_preferences(5) man page for details.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#258387

[Multipart message — attachments visible in raw view] — view raw

On 15.05.2023 15:19, Vincent Lefevre wrote:
> On 2023-05-15 10:25:45 +0500, Alexander V. Makartsev wrote:
>
>> I see. That explains why I can request source package
>> "golang-github-xenolf-lego/testing" directly and get the right one.
>> So, in my case, I won't be able to reliably get a source package(-s) from
>> "testing" if I don't add "deb" part of "testing" to "sources.list", which
>> could be a different can of worms...
>> Is this something for me to just be aware of and leave it as is now, or is
>> there more elegant solution?
> Well, if you don't want the "deb" part, you need to provide the
> name of the source package directly to "apt source". If you do that
> frequently, you can write a script. There are 2 solutions:
> * A remote request, e.g. with rmadison.
> * Something based of "apt cache show". From that, you can get the
>    source package, then call "apt source" with the source package.
>    But note that this is only a heuristic; if the name of the source
>    package has changed from stable to testing, this won't work.
>
> Note that adding the "deb" part shouldn't be much an issue (except
> noise, e.g. with "apt cache show", which would give output for both
> stable and testing). If you want to make sure that a package from
> testing won't be installed by mistake (by apt), I suppose that you
> can use apt preferences with a negative priority for testing to
> prevent such an installation:
>
> Package: *
> Pin: release a=testing
> Pin-Priority: -1
>
> (not tried). See the apt_preferences(5) man page for details.
It looks like adding the "deb" part with apt pinning is the best option.
Even with pinning in effect, packages from "testing" still could be 
installed, but only if they were manually requested.
Now the command "$ apt source lego/testing" is working properly.
Thanks for suggestions, Vincent.

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web