10:04:30 <lbt> #startmeeting
10:04:30 <MerBot`> Meeting started Sat Jan 28 10:04:30 2012 UTC.  The chair is lbt. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
10:04:30 <MerBot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
10:05:16 <lbt> #topic SDK brainstorming as per https://bugs.merproject.org/show_bug.cgi?id=104
10:06:06 <phaeron> yawn
10:06:20 <Stskeeps> o/
10:06:37 <timoph> o/
10:06:38 <lbt> So the main objective is to create a task list for the SDK and share some ideas about structure
10:07:30 <timoph> the current state of it is basically mer core rootfs + a simple script to mount it
10:07:39 <timoph> missing everything else :p
10:07:46 <lbt> and the bug has some blocking bugs
10:07:51 <Stskeeps> plus some tools
10:08:27 <lbt> so I think we need an OBS 'final' location for the Tools
10:08:34 <lbt> ie where they get released from
10:08:47 <lbt> a list of tools
10:08:52 <lbt> entries for them in BZ
10:09:03 <lbt> wiki page for the SDK
10:09:13 <lbt> anything else?
10:09:17 <Stskeeps> i'd propose to release them alongside mer releases and work in same review model and git repos
10:09:31 <Stskeeps> ie, a tools/ dir in releases
10:09:36 <timoph> sounds sane
10:09:56 <lbt> sure .. so that release process and information in the wiki page
10:10:30 <lbt> do we have a cobs area for collaboration and pre-release then?
10:10:35 <Stskeeps> with mer-tools/ instead of mer-core
10:10:54 <Stskeeps> we can make that, i have beginnings of it in home:stskeeps:tools
10:11:01 <Stskeeps> based off phaerons work
10:11:15 <Stskeeps> been using those myself for footprint experiments
10:11:35 <lbt> OK, so phaeron do we have a MINT like progression into Tools:Testing or something?
10:12:08 <phaeron> sure
10:12:20 <phaeron> we have some stuff in mint I'd like to move out
10:12:37 <lbt> yes
10:12:39 <phaeron> spectacle , mic isobla etc ..
10:13:53 <Stskeeps> so, release model, x86 tar.gz alongside mer release reference images?
10:14:21 <lbt> yes
10:14:27 <lbt> what's in it though?
10:14:36 <lbt> the tools used to build that reference?
10:14:56 <lbt> or those used to build next weeks?
10:15:08 <phaeron> basic things , but wihch should be be setup to easily install/update *-devel *-debug *-debugsources
10:15:28 <phaeron> I am not sure if they are already preinstalled , that would make it quite big
10:15:32 <timoph> sb2+cross compilers,devel libs, etc
10:15:35 * timoph slow
10:15:59 <phaeron> does sb2 provide a shell for target selection and such ?
10:16:01 <lbt> I do favour a minimal image with install afterwards
10:16:11 <lbt> at least as an option
10:16:13 <phaeron> me too , saves on bandwidth and initial download time
10:16:22 <lbt> and makes iteration for testing easier
10:16:45 <timoph> true. one can't use zypper inside chroot to get extra things
10:16:53 <timoph> s/can't/can/
10:16:54 <phaeron> timoph: why
10:16:55 <lbt> yeah, we can
10:16:58 <lbt> a
10:16:59 <phaeron> ah
10:17:01 <lbt> h
10:17:02 <phaeron> :D
10:17:02 <timoph> :D
10:17:13 <phaeron> we need that coffee
10:17:27 <lbt> only halfway down the mug...
10:17:35 <lbt> OK .. so the chroot
10:17:46 <lbt> ks based
10:17:52 <timoph> so do we need a separate sdk tools repo pre-enabled in the chroot?
10:17:58 <lbt> yes
10:18:02 <lbt> of some sort
10:18:27 <lbt> we also expect the chroot to be build only - no vim/emacs
10:18:35 <lbt> mount --bind for that
10:18:49 <phaeron> hmm I think the minimal sdk download would have bare minimum at least to reproduce self
10:18:53 <Stskeeps> editors are essential..
10:19:02 <timoph> yeah
10:19:03 <phaeron> yeah I at least vim or nano
10:19:24 <timoph> vi-minimal and nano
10:19:34 <lbt> mmm, I guess for VM installations
10:19:39 <timoph> vim is a bit big
10:19:50 <Stskeeps> the workflow gets disturbed else
10:19:51 <phaeron> zypper would be pre setup (--save in ks) to allow installing *-devel etc ..
10:21:24 <lbt> phaeron: not really reproduce self ... eg no mic installed ... but would have zypper
10:21:39 <lbt> so zypper in mic; mic-create-self
10:22:01 <lbt> anyhow... that's scoping
10:22:10 <lbt> what needs to be delivered
10:23:00 <phaeron> I disagree , but we can discuss details later
10:23:18 <Stskeeps> let's not be pedantic, include what you need to develop with
10:23:46 <Stskeeps> else we might just ship bash and call it a day
10:24:04 <Stskeeps> ie, mic, spectacle, osc, etc
10:24:08 <phaeron> so does sb2 provide a convenience wrapper to download and select targets etc ..
10:24:41 <Stskeeps> with mic there, we can even generate them ourselves
10:24:42 <phaeron> Stskeeps: I was thinking of making it easy to automate ex : downloading latest sdk , rebuilding with vendor special sauce
10:24:56 <lbt> Stskeeps: I was actually thinking we just ship a working zypper chroot
10:25:15 <lbt> preconfigured to work
10:25:19 <phaeron> mm
10:25:33 <phaeron> second usecase would be automated test case : make hello.c
10:25:34 <Stskeeps> lbt, i tried that as a user for a bit and it's frustrating to work with
10:25:37 <lbt> the minimal tarball, not the fully loaded
10:26:05 <lbt> Stskeeps: yeah, but with a minimal tarball we can easily ship bigger ones, vice-versa is harder
10:26:15 <lbt> and it makes phase 1 much easier
10:26:53 <timoph> chroot+zypper already works
10:27:07 <lbt> good, so now we need patterns
10:27:28 <lbt> for sdk, mic-bootstrap, builder etc
10:27:40 <Stskeeps> we need a base point that our guides base off that doesnt start with 'zypper in'
10:28:01 <lbt> "download the SDK rootfs"
10:28:04 <Stskeeps> and can use on a palane without wiifi
10:28:20 <timoph> I'd have something like build essentials in it at least
10:28:20 <lbt> yes
10:28:31 <lbt> maybe I'm not being clear
10:28:37 <timoph> could be
10:28:39 <Stskeeps> so, we already have a .ks with tools
10:28:39 <timoph> :)
10:28:44 <lbt> nm
10:28:49 <Stskeeps> as least sketch
10:29:32 <Stskeeps> so lets expand and productize that
10:30:24 <timoph> lets
10:31:21 <lbt> just because we have something that works doesn't mean it's the right thing to ship as a minimal ... it's bad design.
10:32:35 <Stskeeps> nor is a minimal zypper chroot
10:32:46 <lbt> and no, I don't think we should ship the minimal zypper chroot.. that's silly
10:33:05 <lbt> we should create a minimal chroot that we internally use to produce an SDK
10:33:18 <lbt> and we also use it to make a mic-bootstrap
10:33:20 <phaeron> brb , need to make that coffee
10:33:30 <lbt> and maybe an OBS worker rootfs
10:33:38 <Stskeeps> we need to provide a sane, easily dlable sdk, with basic tools needed to do mer platform devel
10:33:42 <lbt> no
10:33:58 <lbt> we need to make a way to support the ongoing delivery of that beast
10:34:11 <lbt> it's not just build+ship
10:34:15 <lbt> it's maintain
10:34:26 <Stskeeps> yes, of course
10:35:06 <lbt> and we may well need to maintain a variety of these ... so having a common core is important IMHO
10:35:32 <Stskeeps> so, i'm saying we have a starting point, that minimal chroot use to produce a sdk
10:35:32 <lbt> so I'd like to see the clear common core and then the patterns on top to produce shipable SDK rootfs
10:36:15 <lbt> I guess I'm only arguing that that minimal common thing has as little as possilble in it to enable the creation of sdks
10:36:24 <lbt> so making a new one is a light task
10:36:25 <Stskeeps> yes, we are not disagreeing, will you go look at the damn .ks?
10:36:38 <timoph> :D
10:36:40 <lbt> no url in here...
10:37:00 <Stskeeps> it's on the platform sdk page
10:37:30 <timoph> http://releases.merproject.org/~carsten/mer-core-i586-sdk.ks
10:37:53 <lbt> so it has mic and osc in it
10:38:02 <lbt> why do I need osc in a mic-bootstrap?
10:38:33 <lbt> and it has no zypper config in it
10:38:37 <Stskeeps> because you need it as a developer
10:38:57 <lbt> agreed ... so the SDK should have that as part of a developer pattern
10:38:57 <phaeron> it has --save and --source
10:39:00 <phaeron> that's good
10:39:07 <timoph> yep
10:39:09 <phaeron> Stskeeps: do you need to add --debug as well ?
10:39:21 <phaeron> or how does it get enabled ?
10:39:28 <timoph> it has --debuginfo?
10:39:36 <phaeron> ah missed it
10:39:41 <phaeron> getting coffee
10:40:16 <Stskeeps> i'm getting rsi from this conversation: platform sdk needs to contain basic tools to do most of the development tasks that a mer developer or mer using platform developer needs to have
10:40:46 <Stskeeps> is that so difficult?
10:40:55 <lbt> you know how you want to take Qt out of Mer Core...
10:41:03 <lbt> same thing
10:41:08 * timoph nods
10:41:19 <phaeron> didn't see that one coming :D
10:41:19 <lbt> overall objective... ship Qt
10:41:20 <Stskeeps> i don't want to put this into the damn core
10:41:26 <lbt> no
10:41:49 <phaeron> we can discuss the impl. details face to face at fosdem :)
10:41:57 <lbt> yep
10:42:19 <timoph> how about we first just do something that you can use to compile stuff, etc. against Mer core and move from there
10:42:41 <timoph> if there are additional bonuses, etc. good
10:43:12 <phaeron> yeah I would want to add @Build Essentials there
10:43:27 <Stskeeps> we need a way to deliver a sdk, yes, specify what it contains, and allow flexibility to add more targets
10:43:48 <phaeron> but it could be deferred if sb2 provides convenience to download the latest one
10:44:06 <phaeron> or does @Mer Core contain that
10:44:08 <lbt> we need a way to deliver an extensible and useable Mer chroot, yes, specify what it contains, and allow flexibility to add more targets such as SDK
10:44:34 <lbt> I'm trying to agree and just explain where I see the gap
10:44:57 <Stskeeps> lbt, ok,so our biggest problem is that it is way too big effort for people to start making mer images, building software, even retrieving tools
10:45:07 <timoph> I get that but feel we're getting a bit side tracked
10:45:17 <lbt> yes... I'll shut up
10:45:25 <timoph> no need
10:45:38 <lbt> about that issue
10:46:27 <Stskeeps> lbt: so that's why i'm saying we need to have a sdk that's a little more than a shell -- we need zpatterns specifying that content, and a release model
10:46:33 <Stskeeps> and the content itself
10:46:43 <lbt> totally agree
10:46:53 <Stskeeps> i'm not sure we are actually disagreeing
10:47:04 <lbt> :D
10:47:16 <lbt> so... we need patterns
10:47:16 <Stskeeps> so for sure:
10:47:26 <Stskeeps> * builds of content
10:47:42 <Stskeeps> * patterns / package groups for content
10:48:03 <Stskeeps> * image builds of sdk
10:48:39 <lbt> * documentation
10:48:42 <Stskeeps> yes
10:48:56 <lbt> * acceptance/QA tests
10:49:17 <Stskeeps> and i'm saying my .ks is a starting point for us to experiment with, as i had those in mind when doing it
10:49:28 <Stskeeps> and initial contentg
10:49:38 <lbt> * Versioning (of some sort - somehow tied to a Mer release)
10:49:48 * smoku quite likes Nokia SDK approach when python installer sets up SB2 and pulls the rest from repos.
10:49:54 <Stskeeps> yes
10:50:01 <lbt> *nod*
10:50:12 <timoph> yep
10:50:26 <timoph> was just about to mention easy way to set it up
10:50:46 <Stskeeps> so, what kind of content can we offer right now and after that, what can we offer in future
10:50:48 <timoph> (but the the network dropped for me again)
10:50:59 <lbt> one thing that kinda worries me ...
10:51:00 <phaeron> I've asked that 3 times now :D
10:51:25 <lbt> what's going to run inside the chroot that may interfere with the external system
10:51:42 <Stskeeps> yes
10:51:46 <Stskeeps> hence the vm ability
10:51:56 <Stskeeps> but that isn't a problem atm
10:52:04 <lbt> true
10:52:37 <Stskeeps> content right now: mic, osc, spectacle, ability to chroot in and use those, soon: sb2, cross compilers
10:52:44 <Stskeeps> what we can offer
10:53:21 <phaeron> you missed zypper in the first lot
10:53:29 <phaeron> but I guess it is implicit
10:53:34 <Stskeeps> that's implicit yes
10:54:24 <Stskeeps> i have to go soon
10:54:30 <lbt> hmmm ... uid matching
10:54:46 <Stskeeps> yes, that is in chroot in ability
10:54:46 <lbt> and osc uses things like gnome-keyring
10:55:01 <Stskeeps> it doesn't have to
10:55:37 <lbt> so import of credentials and user preferences
10:55:40 <timoph> yep. afaik it simply asks for the pw if it doesn't find a keychain
10:55:41 <lbt> or something
10:56:06 <Stskeeps> lbt: yeah.. that's where things get hairy
10:56:21 <Stskeeps> anyway, gtg
10:56:30 <lbt> l8r - ta
10:56:49 <lbt> I'm interested in bind mount of /home/user
10:57:14 <timoph> that's in the scipt already :)
10:57:17 <lbt> but rather concerned about rm -rf of /my/chroot
10:57:28 <timoph> along with host root bind
10:57:37 <timoph> true
10:57:56 <lbt> what script ?
10:58:04 <lbt> oops .... bbias
10:58:39 <timoph> https://gitorious.org/random-timoph/scripts/blobs/master/mer/enter-chroot.sh
10:59:10 <timoph> anyway I have to go in a minute or two..
11:01:00 <timoph> ok. need to go. I'll catch the logs later.
11:02:00 <lbt> back
11:03:20 <phaeron> everybody left :D
11:03:29 <lbt> :)
11:03:54 <lbt> so, lets see if we can pull a list of bite-sized tasks out of that
11:04:44 <lbt> so I think the big one from my PoV is setup a Tools area
11:04:59 <lbt> Stskeeps wanted it in mer-tools/ alongside core
11:05:29 <lbt> but I don't know if this is quite the same
11:06:07 <phaeron> I think he meant as part of release
11:06:19 <lbt> or at least it depends on the relation between mer-tools/ doing a build and me installing a new minimal root and doing a zypper in
11:06:21 <phaeron> we can build them in COBS and QA them etc ..
11:06:25 <lbt> yeah
11:06:31 <lbt> that's my concern
11:07:18 <lbt> so they should be QA'ed and then sent to mer-tools/
11:07:20 <lbt> ?
11:07:25 <phaeron> yes
11:07:32 <phaeron> snapshotted to mer-tools
11:07:44 <phaeron> or released to mer-tools
11:12:23 <lbt> git repos too
11:13:50 <lbt> how do we handle dependencies?
11:14:41 <lbt> anyway ... since we're all done, lets close the meeting and I'll get some notes up to the wiki page
11:14:46 <lbt> #endmeeting