18:02:42 <Stskeeps> #startmeeting Platform SDK brainstorm meeting 13/1/2012
18:02:42 <MerBot> Meeting started Fri Jan 13 18:02:42 2012 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
18:02:42 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:03:13 <Stskeeps> hi, welcome to platform SDK brainstorm meeting - the general idea of a brainstorm meeting is that we try to create 'task' bugs related to the topic to be entered into the Mer bugzilla at bugs.merproject.org
18:04:23 <Stskeeps> to avoid any confusion, there is two types of SDKs: Application SDKs and Platform SDKs. Application SDK's are the ones that deal with Qt applications and libraries, HTML5, etc, while Platform SDK's are for developing the platform, compiling native code and other things revolving around the platform a developer/hacker needs
18:04:33 <Stskeeps> here we are discussing platform SDKs :)
18:04:53 <Stskeeps> if you have an idea of something that needs to be done, state it with prefix #info and it'll end in meeting log, to be turned into a task
18:06:36 <Stskeeps> so, i'd like to start with my idea of a platform SDK that can kickstart people working with Mer. My idea is a installable disk image that can run on virtual machines (typically) or actual hardware, which contains tools like Scratchbox2, MIC (image creator), spectacle, osc, qemu, etc preinstalled, to make it easier for a developer to work with Mer
18:07:04 <timoph> o/
18:07:06 <phaeron> I was just going to ask , does our obs already have the ability to deliver qemu as part of a build
18:07:06 <Stskeeps> .. is there any objections that we take this initial direction - we cannot reasonably support every linux distribution out there
18:07:21 <Stskeeps> by building for each of them individually
18:07:23 <Stskeeps> phaeron: yes, it does that now
18:07:32 <phaeron> ok cool :)
18:07:39 <lbt> I'd start with a rootfs rather than a disk image
18:07:53 <Stskeeps> either one works, -f fs vs -f liveusb
18:07:56 <lbt> makes integration much easier and allows growth to a standalone
18:08:42 <timoph> lbt: scratchboxy chroot thing?
18:08:43 <Stskeeps> so that we can chroot into it, right
18:08:48 <lbt> yes
18:08:53 <lbt> and mount --bind
18:09:10 <kulve> I would also emphasize documentation. Clearly document the two different SDKs (unlike meego did). And clearly document the tools; people can add support for their linux distro if the tools are known and the source code wide open.
18:09:21 <phaeron> there's a way to boot off a rootfs :)
18:09:38 <timoph> you can do that pretty easily with obs
18:09:41 <Stskeeps> #info lbt: chroot aproach at first, evolve into disk image
18:10:08 <Stskeeps> #info kulve: emphasis on documentation: document difference between SDKs (unlike meego did), document the individual tools/sources to let people port/package for distros
18:10:17 <zumbi> what you mean by disk image? an image bootable by virtualbox?
18:10:22 <Stskeeps> zumbi: for example
18:10:45 <timoph> lbt: http://wiki.meego.com/User:Timoph
18:10:49 <Stskeeps> just a root file system containing needed things
18:11:13 <Stskeeps> this is just "overall" platform SDK - i'll get to the package build part in a little bit
18:11:19 * timoph should move that page somewhere else
18:12:26 <Stskeeps> so, what do we need to do to accomplish this?
18:12:41 <lbt> eun osc chroot
18:12:43 <lbt> run
18:12:57 <Stskeeps> platform sdk needs to be able to function without access to a obs, at least
18:13:03 <Stskeeps> #info platform sdk needs to be able to function without access to a obs
18:13:08 <lbt> :)
18:13:26 <timoph> you can create it with the instructions on my meego wiki user page
18:13:40 <timoph> it isn't tied to obs after the creation
18:13:50 <kulve> I did a chrootable environment based on the "osc build" (or something like that) and it was convenient to use and easy (although big) to distribute. I would still like more to have native tools but chroot is a good alternative
18:14:18 <Stskeeps> #info Make Mer:PlatformSDK OBS project for what goes into the 'image'
18:14:18 <timoph> I'm basically interested in experimenting with sb2
18:14:49 <lbt> kulve: you can add additional tools in .oscrc or by running -X
18:14:52 <Stskeeps> #info package spectacle, mic, qemu, osc, .. what else? for Mer and dependancies
18:15:07 <Stskeeps> #info platform SDK needs to be able to function without an account on obs
18:15:37 * lbt looks at the last 2 requirements
18:15:39 <Stskeeps> kulve: got a link to that? you did a blog post right?
18:15:42 <lbt> osc + no account ?
18:15:51 <kulve> lbt: one goal of my chroot was to be able to build without OBS dependency (for hacking, closed source, quick testing, etc)
18:16:03 <kulve> Stskeeps: http://tuomas.kulve.fi/blog/2011/07/09/meego-1-2-armv7-chroot-beta/
18:16:05 <lbt> kulve: yes, exactly
18:16:16 <Stskeeps> lbt: basically, we need to be able to do package builds without one, osc can of course work when you have one
18:16:25 <lbt> I think 'dependency resolution and provision' is important
18:16:27 <Stskeeps> #link http://tuomas.kulve.fi/blog/2011/07/09/meego-1-2-armv7-chroot-beta/
18:17:22 <Stskeeps> slaine: http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-01-13-18.02.log.txt for catchup
18:17:31 <slaine> ta
18:18:32 <Stskeeps> so, i'd like to talk a bit about SB2 as well - basically, with a x86 tools directory containing cross compiler and other useful binaries, you can cross compile easily against a target
18:18:52 <Sage> o/
18:19:19 <Stskeeps> i'd like to offer support in platform SDK to generate target and tools directories using mic
18:19:21 <kulve> I think (assuming SB2 works well) the SB2 would be my first choice. A chrootable environment would be a choice when my distro isn't in the list of supported ones
18:20:19 <Stskeeps> :nod:
18:20:19 <lbt> Stskeeps: ideally this chroot would provide/replace the mic bootstrap
18:20:27 <Stskeeps> right
18:20:36 <Stskeeps> no need for bootstrap inside anything mer based
18:20:42 <Stskeeps> except for tools available
18:21:09 <lbt> I would suggest that the creation mechanism for the chroot is osc
18:21:36 <Stskeeps> i'd suggest to build it with mic
18:21:38 <kulve> that might not be a big task and based on my chroot experiments it would be quite useful
18:21:38 <lbt> as it lets you work with the OBS project resolution
18:21:44 <slaine> I would guess that there's just a -devel kickstart of the basic image ?
18:22:29 <lbt> Stskeeps: if you build it with mic you may get a different package install to that provided in an OBS build
18:22:40 <lbt> both essentially make a rootfs
18:22:48 <Stskeeps> lbt: that is true, but it's in your own hands to zypper in and remove packages
18:22:59 <lbt> I'd add that
18:23:03 <lbt> essential
18:23:15 <lbt> I'm not suggesting a basic osc chroot
18:23:45 <lbt> just using the OBS to resolve package provision/resolution
18:24:02 <lbt> I assume we'd make the rootfs distributable
18:24:22 <Stskeeps> ideally rootfs would be generatable locally instead
18:24:29 <lbt> both
18:24:41 <lbt> initial download and hack needs a big tgz
18:25:03 <lbt> customisation needs easy regeneration for vendor team use
18:25:45 <zumbi> would it make sense for another tool for chroot handling
18:25:46 <lbt> anyhow... using osc vs mic is not the main point
18:25:59 <lbt> zumbi: why?
18:26:09 <Stskeeps> right, so, for general setup, it'd be better for us to use mic, for package building, it may be a different sceario
18:26:11 <Stskeeps> scenario
18:26:23 <Stskeeps> ie, for general setup == tools available to do mer work, spectacle, mic, osc
18:26:25 <zumbi> lbt: so you can use from different scenarios
18:28:46 <kulve> tizen seems to use repo tool for android style source code "managing". We did someting similar some years ago but I don't see that really relevant when OBS is used in the background
18:29:07 <Stskeeps> timoph: have you done any thoughts on how you'd like to develop software?
18:29:26 <Stskeeps> ie, using the currently fictional sdk
18:29:38 <timoph> Stskeeps: ideally sb2
18:29:41 <zuh> kulve: no it doesn't, that was just someone from community who made it (unless I understood it incorrectly)
18:29:46 <lbt> #agreed the mer SDK rootfs needs a certain subset of build tools including spectacle, mic, osc, etc Provision mechanism is not critical. Isolated usage is essential.
18:29:56 <kulve> zuh: ah, ok.
18:30:26 <Stskeeps> #link https://source.tizen.org/platform_sbs_install.html
18:30:32 <Stskeeps> #link http://maemo-sdk.garage.maemo.org/user-guide.html
18:30:51 <Stskeeps> that's existing SB2 approaches for general development (not only package building)
18:31:22 <Stskeeps> i agree that we need to be syncing with what packages OBS would give us in a build scenario, but traditional sw development is more all over the place
18:31:40 <lbt> need to be able to sync... not mandate it
18:31:45 <Stskeeps> :nod:
18:31:55 <slaine> dev would be all over the place, but there should be something concrete for final building to hand over to qa
18:31:56 <Stskeeps> ie, "create this target based on my dependancies"
18:33:11 <lbt> are these disposable SDKs
18:33:25 <lbt> or are they expected to be kept for months/years
18:33:27 <zuh> A note from experiences with linaro tools and lousy net connection: offering an offline (cached) way to create rootfs's etc is a Good Thing(tm)
18:33:28 <timoph> sounds like what one's doing with osc/obs
18:33:58 <Stskeeps> lbt: i think they're meant to be updated as it goes, with changing targets and mer versions, and mer deriatives/products
18:34:12 <Stskeeps> #info offline cache needed/mirror of mer release (experience from linaro tools)
18:34:19 <lbt> ah, I think we should explicitly not support "upgrade"
18:34:36 <Stskeeps> lbt: reasoning?
18:34:44 <lbt> that is... we should not forbid it
18:34:58 <lbt> cost of QA'ing the tool is too high
18:35:15 <lbt> you could update any package at any time from any repo
18:35:36 <lbt> it's a complex mess - the idea is to make it trivial to "make clean" my dev env
18:35:43 <Stskeeps> #info seperation of user /home and 'sdk'
18:35:47 <lbt> oh yes
18:35:57 <lbt> hence the bind mount (and no rm -rf)
18:36:04 <slaine> Here's my story, My embedded x86 stuff is based of Fedora. I've a local mirror of Fedora at a particular point in time, I've a script that turns a liveCD install into a development environment, pointing to that local mirror. Code is checked out and turned into rpms and a local repository is created. Then I use appliance-creator from appliance-tools (mic like) to parse a kickstart file and generate a filesystem image. This is then either used to create a
18:36:04 <slaine> installable image or uploaded to a server to net boot client devices
18:37:06 <Stskeeps> #info slaine's story: local mirror of fedora. script turning livecd install into devel env, pointing to local mirror, code checked out, turned into rpms, local repo is created. image creator used, parse kickstart file, make a filesystem image for installation/boot
18:37:30 <Stskeeps> one thought could be to have a http server ability within the sdk for publishing built rpms
18:38:00 <Stskeeps> ie, for image creation
18:38:04 <Stskeeps> (or local repository creation)
18:38:10 <lbt> makes sense
18:38:32 <lbt> #info add minimal http server to SDK for built rpm repo serving
18:39:09 <slaine> having the ability to build my own local repo is ideal, but not something I'd intended to do very often. so long as there where source packages available with the prebuilt ones
18:39:10 <Stskeeps> #info need short path from: code, build, deploy, boot
18:40:22 <timoph> for me it's something I'd use for offline compilations, etc.
18:40:30 <phaeron> one annoying thing with osc is it's slow make clean / unpack again / config again / build again
18:40:39 <timoph> true
18:40:52 <phaeron> there should be a way to change one line in say QT and make
18:40:52 <Stskeeps> #info phaeron: one annoying thing with osc is it's slow make clean / unpack again / config again / build again
18:41:05 <lbt> phaeron: I hate that part of it
18:41:06 <Stskeeps> and often you just want to deploy a binary, not a whole rpm
18:41:17 <lbt> ?
18:41:22 <Stskeeps> as a developer
18:41:37 <Stskeeps> assume i patch one line in foo.c, i just want to make, deploy to a target for testing
18:41:49 <Stskeeps> without rpm packaging
18:41:50 <lbt> OK - I mixed that up with phaeron's comment
18:41:51 <phaeron> yes so some kind of make install
18:41:58 <timoph> exactly
18:42:02 <lbt> that's part of the "why we need an SDK"
18:42:39 <slaine> Hmmm, for that situation, I'm typically ssh'd into my own devel env (usually a vm) where I just run standard ./autogen && make
18:42:48 <Stskeeps> :nod:
18:42:48 <lbt> ok ... question.... what -devel is installed in the sdk by default then ... if it isn't building from a .spec BRs ?
18:43:06 <slaine> lbt, Very good question
18:43:08 <lbt> or do we want a meta package for mer-all-devel
18:43:16 <lbt> which would be acceptable
18:43:18 <slaine> You can run into problems there
18:43:20 <Stskeeps> lbt: i think we should distinguish between 'sdk' and 'target'
18:43:25 <lbt> OK
18:43:30 <Stskeeps> 'target' is variable build dependancies, contents
18:43:45 <slaine> Moblin/MeeGo wouldn't build packages for itself if you install build deps for all the packages
18:43:53 <Stskeeps> right
18:44:09 <slaine> it was used to only a subset being there from the obs
18:44:12 <Stskeeps> #info provide correct prjconf (with OBS added value macros) so offline 'build' is possible
18:44:41 <lbt> so the SDK has build-essential
18:44:46 <zuh> I like Android platform build idea in that you get the build output in a dir which you can 'adb sync' to device
18:45:12 <zuh> Without installing packages separately etc
18:45:13 <Stskeeps> #info zuh: Android puts build output in a dir which you can 'adb sync' to device.  stskeeps: Tizen has 'sdb'
18:45:17 * slaine hasn't made complete sense of the android build env, seems overly convoluted.
18:45:35 <Stskeeps> lbt: target has build-essential, effectively
18:45:37 <lbt> mer has scp
18:45:47 <lbt> yes, and we consider mic/osc to be part of our b-e (or build-suggested-minimal)
18:46:06 <lbt> Stskeeps: target?
18:46:07 <kulve> android has "adb push" but "adb sync" is more thorough
18:46:24 <lbt> b-e is only tools isn't it ?
18:46:58 <Stskeeps> lbt: OK, definitions: SDK == our chroot with tools and tools to start a build or enter a target and do building within it, target = your build target file system, libraries, development headers
18:47:15 <lbt> yep
18:47:49 <lbt> so 1 SDK has 1 target
18:48:07 <Stskeeps> no, 1 SDK has multiple targets/versions
18:48:19 <lbt> so nested chroots?
18:48:43 <lbt> I meant 1 instance of the SDK has target A
18:48:49 <lbt> another could have target B
18:49:05 <lbt> since /usr/include/XXX may differ
18:49:06 <Stskeeps> nah, we can handle multiple targets/versions with one SDK (mic, sb2, spectacle, etc)
18:49:11 <Stskeeps> chroot is a strong word, nested filesystems rather
18:49:17 <Stskeeps> ie, /target/mer-armv7l-0.2011/
18:49:47 <lbt> this is the "simple solution" ?
18:49:50 <lbt> :P
18:50:09 <Stskeeps> it's the only way to really do it, id like you to read how maemo sdk+ worked for instance
18:50:29 <lbt> Or do we forget the outside desktop other than for providing /home/user ?
18:51:04 <slaine> and proc sys dev etc
18:52:24 <lbt> also means the outside (for chroot) needs to be kernel compliant
18:52:32 <Stskeeps> lbt: hence the vm ;)
18:52:44 <lbt> which is not always a big deal as long as we check
18:52:48 <lbt> yeah
18:52:53 <Stskeeps> so, 10 minutes left.. so, who's interested in helping making this reality? i'd suggest to start out with a file system image of Mer + mic + spectacle + osc for X86 (we can do non-Atom Mer, in fact, we should)?
18:53:32 <Stskeeps> it should give you ample opportunity to understand the challenges in current development, to make this
18:54:41 <kulve> I'm planning to start playing with Mer as soon as I get a Raspberry Pi -board but I cannot really promise any work time.. I will test and can provide bug fixes. Or add Debian Squeeze support by compiling/testing tools
18:55:25 <timoph> I'll do something. not able to specify what yet :)
18:55:30 <Stskeeps> :nod:
18:55:32 <timoph> a bit of a new area for me
18:55:52 <lbt> this is an area I'm looking at ... but I have things to finish first
18:56:06 <Stskeeps> #info kulve: will start with Mer as soon as getting a Raspberry Pi, test/bugfixes, debian squeeze support by compiling/testing tools
18:56:13 <Stskeeps> #info timoph's in, new area
18:56:23 <Stskeeps> #info lbt's looking at it, but things to finish first
18:56:31 <Stskeeps> #info stskeeps can help mentor
18:56:37 <timoph> cool
18:56:56 <slaine> sorry, away from keyboard
18:56:58 <phaeron> as part of mint I can help with packaging mic and spectacle and osc
18:57:12 <lbt> phaeron: yes please!
18:57:15 <phaeron> and testing
18:57:24 <Stskeeps> #info phaeron will pacakge mic, spectacle, osc
18:57:26 <slaine> I'd love to help too. can't guarantee lots of time due to work being busy, but I'd be actively involved
18:57:32 <Stskeeps> #info slaine'd love to help
18:58:47 <Stskeeps> timoph: i can help mentoring, but would you be able do take lead, ie, chair meetings, monitoring progress?
18:59:04 <timoph> I can
18:59:08 <Stskeeps> alright
18:59:21 <Stskeeps> #info timoph takes lead, chair meetings, monitoring progress
19:00:06 <Stskeeps> okay, thank you all for coming - it has been a nice brainstorm :)
19:00:17 <Stskeeps> a lot of experience and ideas poured into the meeting
19:00:48 <timoph> yeah.
19:00:48 <slaine> yeah, thanks everyone, great to see the same consistent motivated individuals
19:00:58 <Stskeeps> #endmeeting