0

I'm trying to backport nanomsg from jessie to squeeze. But when I run:

dget http://http.debian.net/debian/pool/main/n/nanomsg/nanomsg_0.4~beta+dfsg-3.dsc

It says:

dscverify: nanomsg_0.4~beta+dfsg-3.dsc failed signature check:
gpg: Signature made Fri 29 Aug 2014 09:49:58 PM EEST using RSA key ID 864CC8BF
gpg: Can't check signature: public key not found
Validation FAILED!!

I saw people suggesting installing debian-keyring from that particular release by adding corresponding line to sources.list and APT::Default-Release "stable"; to apt.conf. But I'm concerned about it polluting my system with packages from the other release.

And if we're talking about squeeze here. I can't put stable in apt.conf, can I? Since stable is jessie now. And if I put squeeze there, it's one more thing to not forget when upgrading debian.

I'd like it if I could just safely download debian-keyring from jessie and add keyring /path/to/debian-keyring.gpg to ~/.gnupg/gpg.conf (or setting DSCVERIFY_KEYRINGS?) to make it work. Is it possible? How should I go about the issue?

1

You can easily download the debian-keyring package from jessie, and install it with dpkg -i debian-keyring*deb. Downsides to that method, however:

  • No automatic updates
  • No gpg verification

If you want those, you need to use apt to install the packages. Using APT::Default-Release is indeed one option; another is apt pinning. Create the file /etc/apt/preferences.d/99-keyring with the following contents:

Package: debian-keyring
Pin: release n=jessie
Pin-Priority: 600

Package: *
Pin: release n=jessie
Pin-Priority: 50

This will tell your system that you want to pull the debian-keyring package from jessie, but everything else from your normal distribution. If you don't want to use the code name but want to use the symbolic name instead, change Pin: release n=jessie to Pin: release a=stable.

See man apt_preferences for the full story, including how APT::Default-Release ties into all that.

Warning: when used incorrectly, apt pinning may result in a system halfway upgraded between two releases. The above examples should be safe, but don't use it to architecture-specific packages.

  • Could you elaborate on avoiding halfway upgraded system, and what architecture-specific packages has to do with it? By architecture-specific you mean architecture-dependent packages? – x-yuri Jun 9 '15 at 6:14
  • Look what I've found. Why don't we add just deb-src line to sources.list, download source package, build it and use the keyring as I stated in the question? – x-yuri Jun 9 '15 at 6:37
  • because you don't need to, at least not for _all.deb files :-) but yeah, that's also a way that should work. – Wouter Verhelst Jun 9 '15 at 16:16
  • Because I don't need to what? – x-yuri Jun 10 '15 at 7:11
  • 1
    If it's a _all.deb package, you don't need to rebuild it to be able to install it on older releases of Debian (unless it has a dependency that can't be resolved in that older distribution, but that's unusual). You can, sure, but there's usually no need; the result will be the same. – Wouter Verhelst Jun 10 '15 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.