[arch-general] makepkg not working in chrooted environment
allan at archlinux.org
Thu Oct 21 20:28:46 EDT 2010
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.
>>>> 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...
More information about the arch-general