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