On 22/10/10 10:12, Norbert Zeh wrote:
Norbert Zeh [2010.10.21 1946 -0300]:
Norbert Zeh [2010.10.21 1857 -0300]:
Ionuț Bîru [2010.10.22 0017 +0300]:
On 10/22/2010 12:07 AM, Norbert Zeh wrote:
Hi folks,

I am running a 32-bit chroot on my 64-bit system, and I'm trying to
build a few packages from AUR inside the 32-bit chroot.  When I run
makepkg inside the chroot, it complains about dependencies not being
satisfied, even though the dependencies are installed inside the chroot
(and in the 64-bit environment, as well).  So I'm wondering why it
doesn't find the dependencies.  I'd love to get this to work and also
wouldn't mind helping with debugging this.  I just need a few pointers
what I would have to look for.

Cheers,
Norbert


linux32 chroot /path/to/bla

This I did do, and it fails in the chroot, but I'll certainly follow the
pointers below and the one Andrea gave.  Thanks for the response.

Before trying to go down the path of using a separate chroot just for
building packages from AUR (as suggested by the wiki references you and
Andrea gave), I dug a little deeper into where my problem came from.  It
turns out that pacman would find the installed packages if run inside
the chroot as root but not if run as an unprivileged users (such as the
one I normally use to build packages).  The culprit was too restrictive
restrictions on /var/lib/pacman and the files therein.  Changed the
permissions, and all worked beautifully by just running makepkg inside
the chroot.

As a follow-up to this one, I'm wondering whether this is worth a bug
report on pacman.  After all, if pacman cannot access its DBPath,
shouldn't it issue an informative error message rather than silently
claiming that a package that's in fact installed is not?

makepkg uses pacman with the -T flag to test whether a package installed. That is supposed to be dead quiet. Of course if you used the --debug flag you would see the message you are after...

Allan

Reply via email to