Introducing Lorry
by Lars Wirzenius
The mailing list has been silent: most discussion seems to be happening
on IRC (see #baserock on the irc.freenode.org network). There's also
edits on the wiki. Both of these are difficult to follow afterwards.
Therefore, I'll try to make sure we announce new stuff on the list. If
it isn't on the list, it didn't happen.
Yesterday, I wrote a tool to take code from upstream version control
repositories and push it into Gitorious (the baserock-morphs project) in
git repositories. This is necessary, because we will be using only git
for Baserock development, for various reasons.
The new tool is called Lorry.
* Wiki: http://wiki.baserock.org/Lorry/
* Gitorious: https://gitorious.org/baserock/lorry
It's built on top of git-svn, bzr-fastimport, and git-cvsimport. Those
take care of the actual conversions. Lorry will grow support for more
version control systems later on, as we need it. I'd quite welcome
patches for that, of course.
Lorry is by no means a core tool for Baserock, but it's something we
need, and we need it now, and I couldn't find something suitable to use,
so I hacked it together quickly.
Code review and other comments welcome!
11 years, 7 months
- 1
- 0
Intersting post on OBS approach to native and cross (was Fwd: [MeeGo-dev] Cross compilation tools (Was: MeeGo Reconstructed))
by Rob Taylor
-------- Original Message --------
Subject: [MeeGo-dev] Cross compilation tools (Was: MeeGo Reconstructed)
Date: Wed, 12 Oct 2011 09:56:52 +0200
From: Carsten Munk <carsten(a)maemo.org>
To: meego-dev <meego-dev(a)meego.com>
Hi,
2011/10/11 Eero Tamminen<eero.tamminen(a)nokia.com>:
> As to cross-building in OBS, I would recommend it to adopt SB2 as
> what I've understood of its current cross-compilation solution looks
> like an incomplete re-implementation of SB1 i.e. either much slower
> or causing much more issues with builds.
Just pitching in with some information on the OBS cross building, just
to clear up the differences - I've used both SB1& SB2 including the
deepest hells of both and know the weaknesses / strengths of those vs
our current way of doing those in OBS. I also did a blog piece ages
ago on the same topic[2] - Marius Vollmer's thoughts in [3] also
reflects our way of thinking. I slightly disagree that this approach
breaks more packages than SB1 did :) If there is packages that do
break with this method, let us know, those of us who were/are in MeeGo
ARM are still around in #meego-arm and in #mer on freenode IRC.
So, as you know, OBS is a package builder tool, when it wants to build
a package, it dumps in packages that are build dependencies for the
source package into the chroot, including packages that are needed to
build packages in general (as specified in project configuration, see
[1]) and installs them into the chroot, first setting up a base system
that can install RPM packages (Preinstall/Runscripts) and then the
rest (Required:)
For ARM (or other archs), it can either build straight on a ARM build
worker, or, as we prefer, to run it like SB1 and SB2 does, by dumping
in a qemu-arm (qemu binary emulation) into the chroot, running it on
top of x86 and setting up binfmt_misc to utilize the qemu-arm static
binary when an ARM binary is encountered by the kernel.
When this was working, statistics were done to identify where there
could be a benefit of accelerating certain binaries by making them X86
specific. The approach was simple: to make a 'fast' ARM build machine
without the disadvantages of Scratchbox1 (fairly static toolset,
difficult to maintain). - as well as not touching so much that would
cause things to differ too much as if the build was native, such as
emulating perl. And 'scratchbox done right' ;)
To avoid the trap of the static toolset, it was chosen to take the
existing x86-built binaries in OBS, build-dep on them and simply
(through OBS methods) export them from the X86 build to the ARM build
scheduler, replacing the ARM binaries in place with X86 binaries,
which had been rewritten to use a different rpath [4, also documents
cross toolchain method]. This meant that we were always sure, that the
accelerated X86 binary on ARM side would match the original ARM
binary's source version. It also meant, that when you did a local OBS
build, you would gain same accelerated binaries as part of the chroot
generated locally without having to install a seperate SDK/cross
compilers.
This approach showed an immense speedup in package build speed.
Through additional methods, it was possible to export sysroots/glibc
from ARM to X86 and hence we were able to create cross compilers that
exactly matched the source code of the gcc package. See [4] for more
information on that as well as [5].
The plan is to continue evolving and developing this approach in the
open as part of Mer, we have a seperate small project called
Crosshelpers that contain these bits and pieces. Hopefully it'll be
useful for Tizen ARM too. We feel it's given us quite some strength
and it's being less maintaining than doing it with SB2 seems to have
been, except for minor improvements cross our setup has been stable.
Some of us in "old" Mer explored SB2 as an approach back in 2008 but
didn't find it working properly enough at that time - it may have
stablized a lot since. With regards to a SDK point of view, the idea
was originally in "old" Mer that you could actually utilize your X86
install of Mer as a working development development area as it worked
fine in a virtual machine. And then only build for ARM when you have
the 'fast' machine working, using a oneliner to build using OBS. That
approach didn't work in MeeGo because of slow VM/non-working VM
solutions and well, the fact that most people didn't have SSSE3.
Even with OBS's 'build' package, it's possible to do non-OBS builds
against a repository, though. I feel that this part was
undermaintained and underresourced in MeeGo SDK.
If you want more information, feel free to ask in this thread or in
#meego-arm or #mer on irc.freenode.net
[1] http://monster.tspre.org:2080/project/prjconf?project=Core%3Ai586
[2] http://mer-project.blogspot.com/2009/08/debconf-thoughts-part-two-on-cros...
[3] http://mariusv.wordpress.com/2008/12/07/the-cardinal-sin-of-scratchbox-a-...
[4] http://wiki.meego.com/Build_Infrastructure/Sysadmin_Distro/CrossToolchain...
[5] http://wiki.meego.com/Build_Infrastructure/Sysadmin_Distro/CrossToolchain...
BR
Carsten Munk
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev(a)meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
11 years, 7 months
- 1
- 0
- ← Newer
- 1
- Older →