On 8/15/07, Lauri Leukkunen <[EMAIL PROTECTED]> wrote: > On 8/15/07, Rodrigo Vivi <[EMAIL PROTECTED]> wrote: > > Hi there, > > first of all forget that sb2_libtool compile error... It was related > > to codesourcery toolchain. Using another toolchain I could compile > > that. > > I'll have to give that codesourcery toolchain a try one of these days > myself and try to see what's going on. > > > But when I tried to run using sb2 I got this strange behavior: > > # > > bash-3.2$ sb2 apt-get -f install > > Reading package lists... Done > > Building dependency tree... Done > > Correcting dependencies... Done > > The following packages will be REMOVED: > > update-alternatives-dpkg > > 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. > > Need to get 0B of archives. > > After unpacking 0B of additional disk space will be used. > > Do you want to continue [Y/n]? > > > > I took a look at sb2_mapping.log file (that is attached) but I > > couldn't verify anything strange. > > > > Does anybody have an idea about it? > > It's possible that sb2 is mixing your target and host dpkg or apt > config files from /etc, resulting in what you see. Or then the host > apt/dpkg is not really fond of the target config > files/architecture/something. The idea is to use the emulation mode > for this kind of operation, sb2 -e apt-get -f install, could you try > that?
Oh, this was another strange behavior that I completely forgot when writing the last email: # bash-3.2$ sb2 -e apt-get -f install Reading package lists... Error! E: Read error - read (21 Is a directory) E: The package lists or status file could not be parsed or opened. btw, I'm sure that it is not a matter of permission because I changed the permission for all files of my buildroot and inside it (chrooting) I can use apt-get -f install as a common user. > The default mapping mode is not really suited for installing packages, > emulation is much better. Installation requires that essentially all > paths are mapped to the buildroot, which is completely opposite of > what sb2 tries to do, emulation mode differs in that it tries to give > you as pure virtual chroot into buildroot as practical, only /dev, > /proc, /sys, /tmp and qemu itself are taken from the host. don't you think that a real chroot is better for this kind of operation that requires root permission? because using the real chroot you don't have to change all permissions of the buildroot. Thinking about this I tried to do sb2 -e sudo but I got another error: bash-3.2$ sb2 -e sudo /bin/sh: sudo: not found This is happening because buildroot/usr/bin/sudo is a symbolic link to /etc/alternatives/sudo but the sb2 is not redirecting this link to buildroot/etc/alternatives/sudo. shouldn't sb2 do this kind of redirection? Now I'm starting to believe that it is what is causing all problems that I'm having even with dpkg/apt, since I have a lot of symbolic links on my buildroot. Thanks, Regards, vivijim. > > /lauri > _______________________________________________ > Scratchbox-devel mailing list > [email protected] > http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-devel > -- Rodrigo Vivi INdT - Instituto Nokia de Tecnologia Blog: http://blog.vivi.eng.br GPG: 0x905BE242 @ wwwkeys.pgp.net _______________________________________________ Scratchbox-devel mailing list [email protected] http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-devel
