[Dev] [PATCH] libretools: fix i686 gpg signature failures

Luke Shumaker lukeshu at lukeshu.com
Wed Mar 21 22:53:23 GMT 2018

On Wed, 21 Mar 2018 17:36:52 -0400,
Josh Branning wrote:
> The current state (without the patch) is to keep package caches
> separate when using librechroot.

No, the current state (without the patch) is for librechroot to keep
the package caches separate if building ARM-on-x86 or x86-on-ARM, but
to share them if building x86-on-x86 or ARM-on-ARM.

> The patch makes it so they are not separate when the host is the same
> as the build.

It does that with or without the patch, that behavior isn't being

Of Parabola's supported architectures, i686-on-x86_64 is the only case
that this patch changes.

> >> For the first, bare in mind there is a possibility that you would want
> >> to cross-compile to the same architecture for some reason
> >> (e.g. reproducible builds).
> > 
> > We (libretools) don't cross-compile the way some other projects
> > cross-compile; ...
> Yes, I shouldn't have said cross-compile, rather I should have said
> "compile in a chroot". Even so, there is a possibility that you would
> want to compile the same architecture in a chroot with qemu, for
> instance, because of reproducible builds.

librechroot/libremakepkg always build in a chroot.

db-update on the server rejects packages that aren't built in a

We _always_ build in a chroot.  Even when building for the host

(In fact, it's relatively recent that libremakepkg--which has always
built packages in a chroot--gained the ability to compile packages for
architectures other than the host architecture.)

> >>                For the first, packages will not be mixed if the CARCH
> >> is different from the host.
> > 
> > Right, that's why it's what was used; that's what this patch is
> > accomplishing.
> But they will be mixed when CARCH is the same as the host.

Right.  The goal of the patch is to split the cache between
architectures.  An x86_64 host and all x86_64 chroots can share the
same cache with eachother, but not with armv7h chroots or i686

> >> 2) Any better than this:
> >>> if ! setarch $setarch /bin/true 2>/dev/null; then
> >> 
> >> For the second, I guess you want to know if you are compiling in a
> >> chroot or not, which makes sense, but I'm not 100% convinced that code
> >> works correctly just from reading.
> > 
> > This will always be compiling in a chroot (this is code in
> > libreCHROOT, after all).  That isn't the question.  The question is
> > "is the architecture of the chroot one that the host kernel can run
> > natively, or one that requires an interpreter?"  `setarch $target`
> > will fail if the kernel can't run $target binaries natively.
> That is not what the code does in it's present state.

Yes it is.

> Try the following in a terminal:
> if ! setarch i686 /bin/true; then echo "do the business"; fi
> (change i686 to your architecture, or the architecture of the chroot)

In this example, `echo "do the business"` is the code that only needs
to run if we will be using an interpreter.

My x86_64 kernel can run x86_64 and i686 binaries without an
interpreter, so that snippet keeps quiet when I type "x86_64" or
"i686".  But it does need an interpreter to run armv7l binaries, so it
prints the message when I type "armv7l".

> May I further suggest you remove the exclamation mark from that line.

No, because that would be wrong.

> > For the second, packages will not be mixed if we need an
> > interpreter to run target binaries.  That seems a little silly--the
> > interpreter has nothing to do with the package cache.  It's a
> > hack--right now, for Parabola's supported architectures (x86_64, i686,
> > and armv7l), that means it splits the caches between x86 and ARM,
> > which was the correct thing when I first wrote the code.
> I tend to agree this is perhaps the correct thing to do, but the code
> accomplish that in it's present state.

Yes, it does.

> > Andreas is saying that since the archlinux/archlinux32 split, it is no
> > longer correct to lump the package caches for i686 and x86_64
> > together.  I disagree, and am saying that since migrating to
> > db-import-pkg, it is no longer necessary to keep any of the package
> > caches separate.
> I don't know what you'd be gaining by not keeping them separate.

Disk space, download time; you know, the reasons you use a cache at

The reason to keep them separate is that the way db-import-alarm-pkg
used to work meant that sharing a cache between architectures would
result in package signature errors for arch=(any) packages.  It was a
hack to work around something that db-import-alarm-pkg did wrong.  Now
that we have a correct unified db-import-pkg, I no longer think that
we should have the package cache hack at all.

Happy hacking,
~ Luke Shumaker

More information about the Dev mailing list