Mailinglist Archive: opensuse-buildservice (199 mails)

< Previous Next >
Re: [opensuse-buildservice] Specification for OBS light project concept

I apologize for top- and in-between posting, and perhaps somewhat naive thinking, but I just couldn't stop for my brains for making stupid question(s):

Since most developer hardware are capable of running virtual appliances (using Vmware's player, KVM, or other such software) would it be out-of-reach of obs/osc developers to implement osc as VM client node, which would register itself to OBS service as a build node.

If a local OBS would be used, then the full build environment could be part of the VM appliance and the build process would be executed in local workstation. All required configurations, repository settings and such would be included to the project by local system admin. Perhaps all developer tools [editors etc], which are required in that project, should be included in appliance which would allow really "standard desktop implmentation"; if such is needed. After development cycle, the cleanup of development desktop would require just the deletion of local VM appliance. All other VM benefits would also be included, such as distributed build process, platform independent development, load balancing etc.

06/19/2011 09:07 PM, David Greaves kirjoitti:
On 14/06/11 13:44, Dominig ar Foll (Intel OTC) wrote:
I had a brief look and I did not understand if you plan to use just
the "build" script directly or if you are about to invent something
For the build part we plan to reuse the build script. No need to
reinvent the wheel.

I'm also looking at making OBS fit more easily with the developer
workflow in a sizeable MeeGo/OBS project in Teleca/LGE. (And by
developer I don't mean just the elite code hackers who inhabit lkml etc;
I need to cover junior devs too).

Could the developers in this project use "standard" environment, which would actually exist as a virtual desktop, or virtual appliance? Would it be plausible in resource wise?

My initial thoughts had been to prepare something like:
* osc chroot : to prepare a clean build area, probably with gdb etc too
* mount -bind /path/to/vcs-managed-src /path/inside/chroot/src
* developer hacks and saves in their 'desktop' environment
* osc 'rebuild' : runs rpmbuild with hacks but without cleaning chroot.
(since I did something like this a couple of years ago)

Issues include:
* support multiple packages in one mega-chroot?
* updating chroot efficiently?
* not rm -rf'ing a build chroot with a mount -bind .git tree (!)
* create a project or team specific meta-package which depends on
various useful rpms to allow osc build -x my_dev_env to be easy.

How much of this could be achieved with implementing more modular installation setup of the packages or just in coding process of developers? [this was not a real question, just thinkin aloud :]

I really haven't had time to properly analyse my requirements or the
possible solutions so this is very much a hand-waving and a "me too" email.

I will say that I'm in favour of a solution using a real OBS - an
appliance VM would be fine.

The build script can be used complete standalone at least or embeeded
in osc
local builds or obs service side builds.
Yes osc can do that. What osc does not do easily is to re-extract the
change done in the chroot to create a patch to apply to the original

This seems too hard to support in any meaningful general case. How do I
know if the Makefile that just appeared is because I made it or because
I ran autoconf?
OK, you could just support modifications but then you risk losing real
work in new files.

I was going to allow access to git inside the chroot and probably
looking at some git/quilt workflow for those who like the patch
approach. There is a very nice policy in a supporting tool in debian's
git-buildpackage which I'm in the process of 'porting' to rpm over the
next week (I hope).
see :

Some plugin like "osc trialbuild" would use that policy to extract
patches from the git tree and update the spec; send them to the OBS and
build there.

In embedded we are targeting a developer population which works in the
chroot directly.

Agreed. One of my first patches to OBS was to make the UID of the chroot
user match the real user so you could use the 'desktop' editor against
the chroot path.

Or would it be find to do a local build via "osc build" in chroot
using the
resources from a remote OBS server ?
If you look at the UI in the Spec you will notice that we are planing to
allow the dual mode (local or remote OBS repo as reference).
Our goal is to help embedded project to move to OBS.

Whilst this isn't precisely my goal, I know that a reasonably large
subset of devs (especially in the hardware adaptation layers) will have
come from that area so I'm also interested in making their environment
seamless as they move into a production use of the OBS in their
integration workflow.

Some part OBS light will be created as plug-ins to osc (e.g. the patch
creation tool) and that could be of a general value for all OBS users.

I wonder if we can start by providing some useful wrappers, workflows
and the like around osc and the current system?

NB. If there's not much interest on the obs list then I'm happy to
continue discussions on the meego-distribution-tools list.


If this sounds even slightly interesting, I can explain more deeper.
If this has been said earlier allready, I apoplogize, but I haven't noticed that.



WasaLab Oy, P.O.Box 365, FIN-65101 Vaasa
t2r@xxxxxxxxxxx, tel +358-44-767 7770
helpdesk@xxxxxxxxxxx, tel +358-45-130 4000
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >