Hi,
On 10/17/2011 03:05 PM, ext Carsten Munk wrote:
Another issue that chroot based things have, is /etc contents.
For target you need it to correspond to what's on target, for
accessing host device files, doing networking etc, it needs to
correspond to what your host setup has. How OBS handles that?
>
I need you to elaborate a bit on that,
Especially SB1 was used by also as a testing environment, although
it's primarily meant for cross-building[1]. Then network needs to
work too, which means that network settings need to be inherited
from the host etc.
[1] Note: SB isn't particularly good test environment due to
*user-space* qemu limitations; No guarantees of threading &
atomicity, now and then lacking/requiring implementation for
new kernel syscalls, self-modifying (=bad) ARM code crashes etc.
but if you mean that /etc
contents of the build chroot should match, then the 'build' script
sets up those things correctly when creating chroot. KVM builds makes
it a lot more isolated and probably more secure.
Does developer need to do something extra for every new release
to get the acceleration working in his local build environment,
or is there a way to enable it "permanently"?
(Sorry, I'm an OBS newbie...)
Btw. Does OBS support sbrsh in addition to Qemu, in case one would
want to do a port to an architecture not yet supported by Qemu?
>
Good point with sbrsh, there's a gap there - what typically has been
done is to install the OBS worker software on the actual device - it's
a perl script after all. I presume it is -somehow- possible to utilize
binfmt_misc and something sbrsh-like instead of qemu inside OBS, but I
don't think anyone has tried. Sounds like a good research project.
I was involved in SB1 creation and even presented the sbrsh pre-cursor
in FOSDEM (in 2003 I think), so I'm interested on the subject, but as
in practice about all the devices seem to be now either ARM or x86,
this was more of an academic question. :-)
Btw. Has MeeGo/Mer now thought of basing the distro on some mainstream
RPM distribution like Fedora or OpenSUSE, e.g. after those complete
their own transitions to Armv7/hard-fp/GCC 6.1:
http://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap
https://build.opensuse.org/project/monitor?project=Base:build:arm
?
I've always found it a bit strange that MeeGo had no clear upstream
and I've understood that it lead MeeGo to have somewhat random mix
of packages from both of above distros.
Maemo used Debian as the main upstream and defined its packaging
policy based on the Debian one although the things most important
to users were either written by Nokia or were taken directly from
upstream so that their versions were newer than in Debian.
-> This way there was a clear upstream for packages and their
dependencies, examples & rules for package naming, how files
are split into packages and rules for packaging in general.
- Eero
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
