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

--

() ascii ribbon campaign - against html e-mail
/ www.asciiribbon.org - against proprietary attachments

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

i suggest to read about devtools, it has helpers for that,
extra-i686-build, extra-x86_64-build


--
IonuÈ›

On Thursday 21 October 2010 23:07:18 Norbert Zeh wrote:
> 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.
IMHO the best way is to use the same scripts that we developers use to build
official packages. You should install the 'devtools' package and read something
about makechrootpkg on the wiki.

--
Andrea Scarpino
Arch Linux Developer

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.

N.

>
> i suggest to read about devtools, it has helpers for that,
> extra-i686-build, extra-x86_64-build
>
> --
> IonuÈ›


--

() ascii ribbon campaign - against html e-mail
/ www.asciiribbon.org - against proprietary attachments

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.

Cheers,
Norbert

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.

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

Allan McRae [2010.10.22 1028 +1000]:
> 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...

Fair enough. In particular, I can see why printing an error message may
cause a mess, for example, in how makepkg uses pacman -T to list unmet
dependencies. Nevertheless, if I'm a user (not a developer) who wonders
why pacman isn't doing the right thing, the copious output produced by
--debug isn't that helpful, especially because I have to infer from

"warning: pkgcache is NULL for db 'local'"

that pacman in fact cannot read the contents of /var/lib/pacman/local.
So, I still think that an informative error message such as

"warning: cannot access /var/lib/pacman/local"

would be immensely helpful from a user's perspective. As I said, I see
why having such an error message produced by pacman -T is a bad idea,
but pacman -Qs, instead of outputting nothing, should produce a warning.

Cheers,
Norbert