2011/10/13 Eero Tamminen <eero.tammi...@nokia.com>:
> Hi,
>
> On 10/13/2011 01:30 PM, ext Carsten Munk wrote:
>>
>> 2011/10/12 Eero Tamminen<eero.tammi...@nokia.com>:
>>>
>>> On 10/12/2011 10:56 AM, ext Carsten Munk wrote:
> And such extra packages don't need to be installed / end up in
> the target package database, they can be either bind mounted (SB1)
> or path mapped (SB2).
>
> First one is bit of purity thing (I don't know has / will it create
> problems), second one may slowdown build speed slightly.
Right, they have to be in target package database (but are basically
just overlaying on top, not being same names as the original packages)
>> This is the 'file' binary - exactly same as in the "file" package's
>> x86 counterpart rpath'd to be using /emul/ia32-linux instead.
>
> Ok, so this directory contains also the libs needed by these
> binaries...
Right.
> Yes, I meant that you have separate acceleration packages.
> With SB2 those aren't needed, you can use your normal x86
> packages, they don't need to be modified.
That's true. In practice we don't modify the packages, we take their
compiled output and transfer parts - I guess theoretically you could
automate the accelerometer somehow, but fits in fairly nicely with OBS
the way things are right now and allows us to pick where it matters.
>
>
>>> - your x86 binaries are in different path so that they don't
>>> conflict with target ones
>>
>> That's partly true - we have both ARM and accelerated binaries in the
>> resulting chroot, but as said before, they overlay.
>>
>> Let me drag out the %post of such a resulting package:
>>
> I assume:
> - above postinstall/preuninstall stuff is done only for binaries,
> not for libraries needed by them (RPATH should handle that)
Correct, rpath handles that.
> - before building a release image, you remove the packages
> (small release image build slowdown) which reverts the changes.
You never include the -x86 packages in an image, simple as that. The
-x86 packages are practically only installed during package builds.
We use another tool than scratchbox for image creation -
meego-image-creator. What this does, is to dump qemu-arm into a chroot
and then use host/x86 rpm to install the packages
as-should-be-on-image into it. As the majority of installation time is
spent in rpm (which is host native) instead of in the %post scripts of
each package (which are typically small, and emulated with qemu), it's
fairly fast to build images with. After chroot creation it removes
qemu-arm again.
>
>
>>> -> you can leak wrong paths to generated scripts like SB1 does
>
>>
>>
>> I think this one is a bit misunderstood, we don't actually use PATH
>> tricks or similar, we replace the ARM binaries with their X86
>> counterparts, compiled to exactly same
>
> With symlinks you can still get wrong paths if something uses
> readlink(). Postinstall moving the file would be a bit safer than
> symlink.
Correct, I think most scripts utilize mv/cp these days if i'm not
wrong. Probably something for improvement but I haven't run into it
yet.
> Another, much earlier SB2 feature is preventing packages from writing
> to files outside of their build directory. Some packages modify
> on install files in the root file system...
>
> Does OBS already have something for that?
Generally, OBS builds run in a written-from-scratch chroot (except
when doing it locally and telling it not to) or even in a KVM machine,
as a non-root user (abuild) and packages make install'ed into
%{buildroot} (under /home/abuild), so any attempt to write in the root
filesystem will fail. %files section in .spec files allows you to set
proper permissions for the resulting packages.
For those that need to make packages that has typical root-only
things, like device nodes, fakeroot can be used (we do this in N900
initrd)
>>> If latest SB2 gets proper RPM support, would there be interest to
>>> try that with OBS?
>
>>
>>
>> Of course, we're trying to avoid NIH and if there's better
>> technologies that is of course of interest - getting them evaluated in
>> an open manner.
>
> What you have sounds actually much better than I though. About
> minimal I can think of for getting builds accelerated.
>
>
> 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, 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.
> Maybe the main SB2 benefit would come from its debugging features.
>
> You can get much better information about what happens in your
> builds. For example:
> - what's the call hierarchy,
> - what takes time (actual names of scripts & ARM binaries, not just
> names of Qemu and Perl like you would get with profiler),
> - is something trying to write outside the build directory
> etc.
>
> It would be nice if OBS would have "pluggable" cross-compilation
> support for things like that.
I think you can do some interesting things if you properly overlay
with extra things into build filesystem. The prjconf is fairly
flexible to do things with.
>
> 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.
> If your build host has enough RAM, you could have the target rootfs
> (where build dependency packages are installed) on ramfs, this way there
> would be no disk writes for build deps and the data copied there would
> in best case come from the kernel file cache.
>
> Or are you already doing that?
I do that on my personal builder machine (4 workers, 12gb ram), tmpfs
though, able to build things extremely fast. The biggest sinner in
MeeGo-derived things is the fact that many packages rebuild
unneccesarily. In OBS, when a package rebuilds and is not the same
result as the previous one (due to timestamps in binaries, etc), it
will trigger a rebuild of all the packages that depend on it, to
ensure consistency. I've spent a lot of time in Mer to reduce those
and I'm able to build 4 ports of Mer in 1 1/2 day on what I'd call a
crap machine compared to what sits around in the meego.com racks :)
BR
Carsten Munk
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
