Just catching up on this thread.. 2011/10/17 Eero Tamminen <[email protected]>: > Hi, > > On 10/17/2011 03:05 PM, ext Carsten Munk wrote: > 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. Ah, no, OBS doesn't in any way try to be a testing environment - it's a builder, deep down. My own thoughts on a different post was in one of the other posts, that frankly, you should be able to run system on X86 port without issues. > 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"? It comes down when the chroot is being constructed - you may need to set up binfmt_misc locally for qemu-arm and install qemu, not sure if the 'build' script (what osc uses to do builds) does this automatically these days.
> (Sorry, I'm an OBS newbie...) Best thing is to give it a try some day and ask if there's any questions :) >>> 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. :-) I think there could be an interest to put Mer on MIPS and SH4 possibly, at least. > 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 > ? A very good question - in practice, you can mostly import Fedora specs as-is, but there is some stricter rules in MeeGo / minor differences. And we actually have a better ARM story than those at the moment. I think we'll be getting the same problem of 'too many dependancies that are non-mobile' if we indicate anyone as an upstream. The packages I've had to cut dependancies in were mostly directly copied from Fedora and had no consideration whatsoever towards typical mobile use. In practice, I would like to recommend you to look into the tool spectacle - it really makes packaging a joy and really really easy. Many people balk at it at first until they start working with it, makes maintaining packages much easier. > 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. > > Couple of other features from SB2: > * uname syscall gives target info, even if it's called > by "accelerated" x86 package. > Catching accesses to /proc files that have processor specific information. Agreed - those two have a bit of gap in the current solution. Practically I think qemu handles the /proc/cpuinfo thing - if you access anything else in there during build process, you're in for a world of harm anyway - and you're not really cross compile friendly :) > > > >We're already replacing binaries on fine-grained level of filesystem, > > I'd say (see above) > This helps accelerating things like gcc, rpm, qmake, shell and m4, > but you cannot safely accelerate Perl, Python or other interpreted > scripting languages than can have extensions. That is true, but it is also one of the biggest source of problems that these were accelerated, that I personally had in Scratchbox1. That you couldn't install this or this perl extension. Personally I think (even given the performance benefits) that it's just not worth it in bug fixing and mysterious behaviour to wander there. If you see how fast packages build these days, on tmpfs, the delay is noticable, but not terribly important in the big picture. BTW, for everyone: if you have a OBS, make absolutely sure that your BSConfig.pm $obsname is -NOT- set to $hostname. This will cause significant delays as OBS won't recognise a same package with same build-deps as the same, if they are built on two seperate OBS workers. In practice, SB2 would have to install every single package build-dep on x86 side for perl etc that the ARM side packages would need and keep them updated. While I don't have any data on that, my initial reaction is that this might just cause more trouble than worth. Mika Laitio wrote: > I believe significant speed up could be gained if the worker could have a > some kind of repository specific cache where the worked could save the > previously created chroot image. I think part of the problem with now is that some packages don't un-install properly. We should have QA tests that verify this in Mer. In a builder, the root -should be pristine- or all sorts of bugs can come in. Locally, less important. I don't see any reason why we can't somehow implement that in 'build' - of course, you'd have to know perl to do so. And the cached images may be fairly large in size. BR Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
