Johannes Schauer writes ("Re: Does anybody plan to keep using sbuild with 
Squeeze or older chroots?"):
> Old sbuild will not help you. The problem is mainly, that older
> chroots contain an apt installation that has no support for the
> [trusted=yes] option in sources.list. This in turn means that it is
> required of subild to sign the internal dummy repository. This
> signing happens with a private/public key pair that is generated by
> the host running sbuild. The challenge is, to make it such that the
> keys generated by gnupg on the host can be consumed by older gnupg
> inside the chroot. I did lots of work in this direction already by
> for example changing the export format for the keys generated by
> $(sbuild-update --keygen) but apparently there are still bugs around
> as recently reported by weasel via IRC.

Urgh.

(Would it not be possible to generate the key inside the chroot?  I
guess there are probably other problems with that.)

> Since I sank lots of time into this issue of
> cross-gpg-version-compatibility already I was wondering if it is
> worth to spend more time on it than I already have or whether I can
> just rip out the whole key generation and consumption part. It is
> not needed anymore for any Debian release after squeeze (thanks to
> newer apt).

Right.

> If there are still users who plan to build for squeeze on sbuild
> from stretch, help to keep compatibility for squeeze would be very
> much appreciated.

My use cases for this are not sufficiently essential to me for me to
want to wrestle (or for me to want you to wrestle) the problems you
describe above.  But perhaps someone else will volunteer.

Anyway, thanks.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply via email to