Hi, Scratchbox2 can now be found in debian, unstable and testing carry frequently updated releases of it. I've been going over a number of packages trying to test it. I think it's pretty good considering the limited amount of people using it, and the fact that the public maemo rootstraps are an insult to all root filesystems.
Most problems arise from maemo being totally geared towards SB1, which is terribly unfortunate. It has resulted in rootstraps being stripped of many essential packages to make them even marginally useful, all because SB1 has kindly provided those and even pretended that its versions satisfy build-dependencies for them. Target images are quite a bit more useful, but require special tools to extract files out of jffs2 images, I'm not even sure if these tools are available outside Nokia? I know that internally Nokia has rootfs tarballs that are very close to what's needed by SB2, so not much needs to be done to improve the situation. I hope the right people read this. Continuing on the topic of build dependencies, SB2 has an open design issue regarding them. Since SB2 is using the host system to provide most (all) of the build tools, build dependencies of packages need to be checked against the host. But then again build dependencies contain -dev packages (libraries and headers) which need to be in the target buildroot, so the build dependencies need to be checked against the target as well. Obviously the easy solution would be to require all build deps on both host and the target, but this is not very practical. Therefore I would need some way of reliably identifying what should be checked from where. Any ideas are welcome. The raw mechanism is already in place to call dpkg-checkbuilddeps for both transparently, but now we'd need to figure out the logic. Now a little bit about target emulation, since that's always popping up when scratchbox is discussed. SB2 is *seriously* not going to do it in the default mode of operation. Instead there is so called "emulation mode", used through the -e switch to sb2. That's still using user-mode emulation with qemu, but effectively does a pseudo chroot. It's not as good as system-mode qemu, but useful for running apt, dpkg and related tools to maintain the target root. It also shouldn't be considered as a real target emulation environment to be used for application or system development. So people would normally do something like this when using sb2: sb2 -e apt-get update sb2 -e apt-get dist-upgrade cd ~/src/my_package sb2 dpkg-buildpackage -rfakeroot It might be a good idea to try to automate the use of emu mode for apt and dpkg, might save some headaches down the line. Shouldn't be too hard to detect normal invocations of them. Nokia and Maemo community really need to figure out an easy way for developers to use the real hardware and system-mode qemu. Those are the only adequate solutions for testing and debugging of software. Also note that SB2 is totally not interested in doing x86->x86 development, like what many people are doing today with SB1. People need to wake up, smell the coffee, integrate with debian proper and get with the program. It's stupid to maintain a lame x86 port of maemo which nobody wants when all the components should be pushed to debian and ubuntu and get those bigger communities involved in their development. One day we will anyway be running debian/stable with a few custom components on the tablets. That was the aim with this whole debian thing in the first place, remember? regards, Lauri _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
