/srv/irclogs.ubuntu.com/2009/06/02/#ubuntu-mobile.txt

=== mcasadevall is now known as NCommander
=== asac_ is now known as asac
lbtHello from Mer19:59
NCommanderlbt, hello from Ubuntu!20:00
YokoZarhello thar20:00
Stskeeps<- here too20:00
YokoZar*bangs gavel, announces we'll probably wait a few minutes while everyone gets here*20:00
* persia waves and rushes to paste some text20:00
NCommanderOh, right, we have that meeting!20:01
persiaAh, looks like YokoZar already pasted :)20:01
YokoZarhello hello20:02
Stskeepsand we have maemo.org council chair (jaffa) listening in as well20:03
persiaHey Jaffa 20:03
JaffaHiya20:04
JaffaAt JavaOne, so mostly just reading :)20:04
YokoZarAll right20:04
YokoZarLet's do introductions.  Who's here for the meeting then?20:04
* YokoZar is Scott Ritchie, an Ubuntu Developer20:05
* persia is Emmet Hikory, an Ubuntu Developer20:05
* lbt is the build/sdk/process/packaging/docs non-expert for Mer20:05
* Stskeeps is Carsten Munk, Mer lead developer/faciliator/whatever (if you read my slides at the UDS meeting, twitter.com/stskeeps has the video + final slides) :P20:05
* lbt is David Greaves20:05
* NCommander is MIchael Casadevall, an Ubuntu Developer, and a Mer user20:05
* ian_brasil me20:06
YokoZar:)20:06
NCommander;-)20:06
GrueMasterGrueMaster - Ubuntu Mobile QA testing.20:06
* Jaffa is Andrew Flegg, Maemo Community Council chair20:06
* qwerty12_N800 is Faheem Pervez, a packager and hacker of code (my knowledge isn't extensive enough to say I'm a programmer)20:06
GrueMasterOh, Tobin Davis.  (oops).20:07
luke-jr(is the meeting open, or restricted?)20:07
YokoZaropen20:07
NCommander(the meeting is open)20:07
YokoZarAll Ubuntu meetings are, generally (except security issues)20:07
* luke-jr is Luke Dashjr, a developer for the unofficial Gentoo N8x0 port20:07
* lcuk is Gary Birkett, author of liqbase (n8x0 device ui)20:07
* rgreening is lurking, but has $WORK in the way. need to restore broken network...20:08
YokoZarOk, nice, we have quite a few people here20:08
YokoZarThe great thing about IRC meetings, unlike real life meetings, is that work doesn't get too in the way (or vice versa).  So, let's move on and talk a little bit about how we're going to be working together.20:09
lbtI got this as an outline http://pastebin.com/d7c52461620:10
YokoZarlbt: yup, that's the agenda more or less20:10
YokoZarEveryone, please feel free to ask any questions you have as we bring things up, this meeting is about all of us learning20:11
Stskeeps*nod*20:11
NCommanderI think a good first step is a review of the current Mer and Ubuntu MID projects, and what is needed to bring the former into Ubuntu20:12
YokoZarAt Ubuntu, the typical workflow for a generic package is something like this: Upstream makes a tarball release (say, Wine 1.1.22 last Friday), Packager (me) downloads it and updates the package we already have (if only the source code has changed and not the build instructions, this is very easy to do).  Then I upload it to the development release, and it gets out to the masses.20:12
YokoZarNCommander: I agree20:12
YokoZarMer, as I understand, won't be a typical upstream like I just mentioned ;)20:12
YokoZarInstead we want to work a bit closer20:12
NCommanderI did a look over in an advance of the packaging of Mer, so I'll bring that up after the general upstream status :-)20:12
lbtYokoZar: process makes sense and aligns20:13
lbtbut layered diffs is an interesting area...20:13
Stskeepsour view is that we want to act in similar way, but we also have interesting issues like maemo's extended use of native packages :)20:13
Stskeepsideally ubuntu packaging would be == mer packaging20:14
Stskeepsas in, the cleaned up ubuntu packaging ;)20:14
YokoZarIn the typical workflow, the packaging (/debian) folder is kept entirely in Ubuntu while the source remains pristine; optional distro-level patches are put inside the debian folder itself and applied at build-time using a patching system like quilt20:15
lbtyes20:15
lbtwe'd like that20:15
lbtalthough the maemo packages include /debian20:15
persialbt, Would having the packaging outside the Mer repos block your builds for the Mer cycles?20:16
lbtand that may need .... tweaking20:16
persia(e.g. stripping the Maemo debian/)20:16
Stskeepsstripping maemo debian/ should be possible20:16
NCommanderStskeeps, well, OBS will build any package that Ubuntu can, so once the packaging is brought up to scratch, that will work fine20:16
persiaI'm just concerned about not blocking Mer test cycles by doing so.20:16
lbtI am looking at introducing a (git) VC system to do this20:16
Stskeepsbasically: we are in the midst of cleaning up our act, so we are -very- open to changes20:16
lbtand managing the seperation of src,diff,/debian20:17
YokoZarlbt: Yes, it's also possible to have the debian/ folder live inside a branch20:17
lbtindeed20:17
Stskeepswe would also like to find a good way to deal with upstream (and we discussed this a bit with nokia)20:17
lbthttp://wiki.maemo.org/Mer/Documentation/Mer_Package_Patch_Handling20:17
YokoZarlbt: indeed this is what much of the "use bzr for more things" push is about in Ubuntu20:17
lbtin principle the 1 branch per patch approach works for me20:19
Stskeepswell, or simple quilt patch management20:19
lbtand 1 branch per packaging flavour20:19
lbtthen export that into quilt20:19
YokoZarQuilt is very nice for this sort of thing20:19
k-swell, most top level packages should rely on the same dependencies and all, so the diff would be just about changelogs, no?20:19
k-slower level packages have (or used to) different dependencies as maemo used different names20:20
lbti'm open... was looking to setup VC for developers and take branches into quilt for /debian/patches20:20
lbtwe have quite a few code and build patches20:20
NCommanderStskeeps, YokoZar I'm not sure if your aware, but quilt can be intergrated into the package build process20:21
YokoZarNCommander: yes, in fact this is where I thought it most powerful20:21
YokoZarNCommander: the build script just applies the quilt patches at build time20:21
NCommander(and then all the patches live in the debian/patches folder to allow a single bazaar tree for the Debian packaging, and bazaar stuff, and have a watch file so bazaar can auto-reconstruct a source package without any fiddling)20:21
YokoZar(and unapplies them at package cleanup time)20:21
NCommanderYokoZar, yup :-)20:21
lbtyes20:21
lbtand for me .... each /debian/patches/ file comes from a VCS branch20:22
persiaNCommander, Except we're dealing with stacked trees, because Mer itself is, in part, a set of patches against Maemo20:22
NCommanderpersia, VCS import the Maemo trees, and then stack off that20:23
NCommanderIf possible20:23
lbtyes...20:23
lbtmaster branch is .orig20:23
Stskeepswe'd really really want to base on tar.gz's, you can't rely on the vcs20:23
persiaI think k-s's point is probably most interesting: in Ubuntu we really only want one debian/changelog entry per upload, but that doesn't necessarily meet Mer changelog requirements.  Would VCS logs be sufficient for Mer developers?20:23
persiaStskeeps, pristine-tar can help with coordination between tar.gz and VCS repos.20:23
NCommanderpersia, we allow for debian/changelog to have non-relevant entries for Debian and other distributions as long as their series name does not conflict w/ Ubuntu ones to my knowledge.20:24
Stskeepspersia: interesting, didn't know that (per upload)20:24
persiaNCommander, Yes, but we don't prefer it.20:24
NCommanderpersia, this is a unqiue case ...20:24
Stskeepsbasically we are going to be doing a lot of fast-paced development where we will need to be doing within-mer package upgrades often20:25
YokoZarIt's not too hard to have one changelog entry with a bunch of bits to it20:25
Stskeepswe can however also work on a way to merge multiple versions into one upload for instance20:25
lbtbig changelogs though...20:25
lbtwe may need to manually summarise20:26
Stskeepswe can however be happy we're at a stage where we aren't patching much anymore.20:26
persiaIndeed.  That's supported, but I think a manual summary would be preferred.20:26
YokoZarDo you give version summaries already?20:26
YokoZarOr are your release changelogs just big lists of commits?20:26
lbtcommit list20:26
lbtif anything :)20:26
Stskeepscurrently our packaging is occasionally a mess, and the changelog reflects the changes20:26
persiaMy worry is for Mer developers to be able to effectively test changes per-Mer-cycle, which may require several builds, but I suspect we only want one or two Ubuntu uploads per Mer cycle.20:27
Stskeepswell. we can always abuse that mer < ubuntu lexically..20:27
Stskeepsso ubuntu4 would wrap certain mer versions20:27
YokoZarThis kind of release announcement could work for you very well: http://www.winehq.org/announce/1.1.22  (manual list at top, commits at bottom, the top goes into our package changelog the bottom doesn't)20:27
YokoZar(I mention this because it's exactly how I package Wine, and it comes out every 2 weeks)20:28
lbtwe could do that20:28
lbthmmm20:28
lbtwe should do that20:28
YokoZarIf I had to guess, I'd say the manual changelogs at the top are written by Julliard in about 5 minutes from memory, so shouldn't be much of a burden ;)20:28
lbtwe are still building processe and supporting scripts20:29
Stskeepswhen dealing with the maemo packages we are mostly doing patches and not so much our own development (yet - it's getting there)20:29
lbtwe only just transitioned to OBS20:29
lbtand I'm in the process of setting us up to handle logging these changes.20:29
lbtwe don't use (AFAIK) the OBS commit messages20:29
lbtwhich are (in my case) cut'n'paste from local git repos20:30
lbtso we (I) need target specifications20:30
YokoZarStskeeps: that's cool, there's no requirement that changelog entries be interesting ;)20:30
qwerty12_N800Is swearing frowned upon in changelogs?20:31
Stskeepsah, yeah, we might want to filter some. :P spending too much time with maemo packages makes you do stupid things.20:31
YokoZarqwerty12_N800: heh -- probably not wise in the summary, but ok in commit messages ;)20:31
lbtpersia you said : I suspect we only want one or two Ubuntu uploads per Mer cycle.... 20:32
* lcuk sighs with relief20:32
lbtdid you mean 1 or 2 Mer cycles between uploads?20:32
persialbt, Just a loose guess.  One right before the testing phase, and one at cycle completion.20:32
YokoZarJust remember that the eventual user-visible thing is the package changelog entry (which is why it can't be a giant list of commits or a bunch of profanity)20:32
YokoZar(they see this in update-manager)20:32
persiaMind you, this changes at FeatureFreeze, but I thought it would be a good way to get the Mer code out to users for testing, and the final fixes pushed.20:33
lbtOK ... so upload when we promote our first :Testing20:33
persialbt, That was my thought, but I'm open to alternate suggestions.20:33
qwerty12_N800YokoZar: yeah, I allowed my frustration to get the better of me. I'll try and find those changelogs...20:33
lbtpersia.... why?20:33
Stskeepsbasically, what we hope to start with is simply to slowly start moving packages to "new" workflow. beginning with libosso and libhildon20:33
NCommanderTHat's actually something I wanted to bring up20:34
Stskeepsand getting also upstream relations going (libhildon is open to different packaging based off their git trees, and is open now.)20:34
NCommanderWe do have libhildon in Ubuntu at the moment which is used as a base for the current Ubuntu MID (not sure on other rdepends)20:34
persialbt, Why which?  Why two uploads, or why am I looking for alternate suggestions?20:34
lbtour :Testing can be quite... raw20:34
lbtso if you intend to publish to end users then it may be good to go for :Testing220:35
NCommanderWe'll need to standardize the Ubuntu libhildon and what your currently working on, as well as remove all the hildonized packages that Mer doesn't want to help reduce workloads at transition times.20:35
persiaNCommander, current MID upstream doesn't support the current codebase anymore.  I don't think we need to worry about it much.20:35
NCommanderpersia, I'm more worried about libhildon's rdepends.20:35
StskeepsNCommander: our libhildon is mostly pure20:35
NCommanderStevenK, our libhildon is ancient20:35
lbtpersia... l8r20:35
persiaI also don't think we want to *remove* the other packages, except where they either have no upstream, or can't be fixed.20:35
persialbt, Catch me anytime :)20:35
NCommanderpersia, no, but we have hildonization patches on a *lot* of packages that I'm not sure we want to continue maintaining (and this also brings us to the question of packages that Mer and Ubuntu change that have been hildonized in the former)20:36
Stskeepsif you're wondering if dates-hildon still work, it does :P20:37
Stskeepswe have a transformational package to help support your naming, but it's not that nice20:37
persiaNCommander, Hrm.  Probably worth a review of rdepends then, indeed.  I suspect we'll want to keep some of them.20:37
NCommanderpersia, agreed, but I can think a few we can toss as well20:37
k-sNCommander: wonder tha same20:37
NCommanderpersia, Stskeeps, I think what we need to do as a first step is scrap all the Ubuntu MID stuff we don't want anymore (the current launcher being one), as well as the current meta-packages20:38
k-spackages like gnumeric and other hildonized... what todo? two versions that conflicts?20:38
lbtare these hildonisations not from Nokia?20:38
Stskeepsnah, ubuntu mid ones20:38
Stskeeps / moblin20:38
persiaNCommander, I'd rather get the Mer packages in, and then just change the metapackages and tasks.  Saves going back to the TB for reapproval.20:38
lbtOK, so if you want to push these into Mer then they'd need maintainers I guess20:38
NCommanderpersia, fair enough. We still have those packages to remove though, we need to go through the current seed list and prune it all out.20:39
persialbt, I think it's on a per-package basis: not all of them are useful, but some are nice.20:39
* k-s hates the hildonization, it's the worst thing ever... pointless20:39
NCommanderk-s, +120:39
persiaNCommander, I do believe I'm actioned to do just that on https://wiki.ubuntu.com/Specs/MobileMidKarmicUseMer :)20:39
JaffaA lot of the Hildonised apps from Ubuntu MID old would be good to go -> Mer, and maybe -> Maemo20:39
YokoZarSo basically we're going to get a few orphaned packages that may conflict with the hildon we want from mer and we're not sure what to do with them?  That sounds like Ubuntu's problem ;)  (unless mer wants to take over them)20:39
k-sit's just there because Nokia used to want hildon as closed source extension20:39
NCommanderWhat we did for packages that we had to hildonize, we attached the hildon code to a pre-processor flag, and then built it twice, once with and once without20:39
Stskeepshildonization has it's plusses, but we are also interested in auto-hildonization. we spent a lot of time making normal GTK apps look nice in Mer too.20:40
lbtI think that is no longer a problem?20:40
k-sproper engineer would be to patch gtk to provide better widgets for finger use20:40
NCommanderbrb, battery flashing signs of death20:40
persiaI think I like autohildonisation better.20:40
Jaffak-s: The semi-sensible rationalisation is that a mobile UI needs to be rethought, so an incompatible API forces that. Not how I'd've done it tho :-/20:40
Stskeepswe encourage hildonization because there's a little more to it than just UI20:40
k-sJaffa: ok, but then it's not hildonization as change toolbar or menu, but *new* ui20:40
Stskeepssuch as the libosso stuff20:40
lbtyes20:40
persiaJaffa, Trick is in maintenance: we don't really want to have to carry two versions of e.g. the gnumeric codebase.20:40
k-sStskeeps: libosso is also bs20:40
lbtvery few apps are hildonised20:41
lbtNb... Qt is trying to hildonise the framework20:41
k-sStskeeps: yet-another NIH20:41
k-slbt: yes, andthat is transparent to users20:41
lbtyes20:41
Stskeepsk-s: admittedly things could have been better20:41
Stskeepsbut some of the signals that it gets are useful for mobile usage20:41
k-sanyway, most (or all) of this will be dead soon20:41
Stskeepscare to elaborate on that?20:42
NCommanderBTW, I think another point worth bringing up is what architectures do we care about w.r.t to Mer20:43
NCommander(side note but important)20:43
k-sStskeeps: i see this going away, I have inside info on the topic, but cannot disclose much :-P20:43
YokoZarNCommander: agreed20:43
lbt(nb k-s  I didn't catch your introduction)20:43
Stskeepsk-s: ah, harmattan probably20:43
StskeepsNCommander: we're agnostic to architecture as such (if we see it on package level)20:43
k-slbt: I'm Gustavo Barbieri, used to work at INdT, architect and lead developer of canola 1/220:43
NCommanderWell, this case is kinda special because of the way ubuntu-mid was handled20:44
lbt:) ta20:44
GrueMasterArch wise, we should focus on the two mid architectures (x86 & arm).20:44
NCommanderAs it stands, the ubuntu-mid build has a hard coded assumption its going to be built on lpia, but lpia is officially un-maintained as of karmic. I think i386, arm20:44
k-slbt: now owner of ProFUSION embedded systems, which do contract for Canonical and couple of other companies on embedded/mobile field20:44
persiaGrueMaster, i386 & armel ?20:44
GrueMasterIn otherwords, no IA64 ports for NCommander.20:44
NCommanderRight, I agree, but we're also going to get amd64, sparc, and ia64 for no added cost :-)20:44
NCommanderand powerpc20:44
Stskeepsour wii port would be happy for powerpc ;p20:45
NCommander\o/!20:45
YokoZarmobile wii?20:45
* NCommander tried to run Ubuntu MID a long time ago on his wii20:45
Stskeepsmer on wii: http://smg.photobucket.com/albums/v119/JohnX/?action=view&current=CIMG5444.jpg20:45
Stskeeps(missing background)20:45
YokoZarMy Wii got mobile when my brother threw it against the wall in frustration.  Anyway...20:45
k-sYokoZar: lol20:45
Stskeepsbut anyway, we are in no way restricting what archs to build on - all that stuff is in our HW support repos20:45
NCommander(it should be noted for the record that there is an Ubuntu PS3 port so ....)20:46
persiaSo, I think we covered 1.1 and 1.2 on the agenda.  Shall we go to 1.3?20:46
NCommanderThat's sexy :-)20:46
GrueMasterFor testing purposes, I am limited to i386/lpia, and arm.20:46
YokoZarpersia: That was my thought.  Any more questions on work flow?20:46
NCommanderGrueMaster, I thought you had an amd6420:46
NCommander(not that we really care but)20:46
Stskeepsregarding Mer and work flow, lbt is the guy to talk to from us, he's in charge of developer tools etc :)20:46
lbtpersia http://wiki.maemo.org/Mer/20:46
GrueMasterNCommander: It is dedicated to LSB testing.20:46
lbtthat is the root for our info sources20:47
Stskeepsso he'll gladly sit down with some of you and get a workflow worked out that suits us all20:47
NCommanderpersia, where's the agenda? I don't see it on the wiki20:47
lbtyes indeed20:47
YokoZarI think the consensus seems to be (1: small changelog improvements, 2: use quilt whenever we can20:47
lbtagenda : http://pastebin.com/d7c52461620:47
StskeepsNCommander: http://pastebin.com/d7c52461620:47
* lbt scores20:47
lbtYokoZar: I would like to work a git->quilt process too20:48
YokoZarlbt: Ok, that shouldn't be too hard (takes only a few commands when done manually I think)20:48
Stskeepsregarding upstream libhildon info: https://garage.maemo.org/projects/hildon20:49
lbtI'm not sure we sorted the stacking issue20:49
YokoZarlbt: that way we could have a -ubuntu-karmic branch where we pull in specific bits and then move them into package quilt automatically?20:49
lbtyes20:49
lbtheck.... you could share gitorious 20:49
Stskeepsyes, the question is how to handle orig.tar.gz .. would they be the maemo source with debian/ stripped? :P20:49
YokoZarlbt: Are there scripts out there for that already?  Because that sounds really cool20:49
lbtor setup a gateway20:49
YokoZarTrue20:50
lbtStskeeps .... implementation..... but handled in master20:50
Stskeeps(for their native packags)20:50
lbtand probably stripped to master-debian20:50
lbtand maybe branched from there20:50
lbtor forked20:50
lbtmake sense?20:51
YokoZarYeah20:51
lbtOK... does that handle stacking?20:51
lbtI worry about patches being patched20:51
lbtI do this20:51
lbtit hurts20:51
Stskeepsokay, so, what do you mean about sources of information?20:52
Stskeepsabout/with20:52
persiaI think we can avoid the patching-patches issue by restricting Ubuntu delta to debian/changelog20:52
lbtOK20:53
YokoZarIf git handles the merging of the stacked patches, then whatever git spits out should be handled by quilt I think20:53
persiaExcept post-feature-freeze, when we use patching-patches *intentionally* to backport specific targeted bugfixes.20:53
YokoZarYeah persia is right there20:53
lbtOK... I need to learn this....20:53
lbtI see gtk2.020:53
lbtnm... l8r20:53
Stskeepsl8r meaning that we'll look at it later, i presume, and not that you're leaving ;)20:54
lbtcorrect .. sorry20:54
YokoZarso... "sources of information"20:55
persiaFor sources of information, I think Ubuntu folk are most curious about Mer outlines (link already posted) and Mer code repo.  What information about Ubuntu would be interesting to Mer folk?20:55
Stskeepsthe question that keeps bugging me is simple: we're going to have really interesting times with maemo gtk vs no maemo gtk20:56
YokoZarI'm interested in how information flows between the projects too (eg we have a wiki and this IRC channel, which isn't the mer wiki or the mer IRC channel)20:56
StskeepsYokoZar: we have our wiki, irc channel, and we microblog to mer-chatter mailing list20:56
Stskeepsmicroblogging when we move on something and people recieve in digests20:57
Jaffapersia: Roadmaps/blueprints/use-cases for karmic vs. Mer would be an obvious one20:57
persiaStskeeps, If it's just patches against gtk, we might be able to create another flavour of gtk as part of the gtk package build process.20:57
Stskeepspersia: you have other flavors? maemo gtk is sometimes considered an abdomination by some :)20:57
lbtyeah ... the maemo-ised 'upstream' packages tend to freeze20:58
persiaJaffa, Well, at this point there's just the one blueprint (https://wiki.ubuntu.com/Specs/MobileMidKarmicUseMer) which will get fleshed out as we get detail.20:58
lbtOn the Mer side everything should be reachable from http://wiki.maemo.org/Mer/   .... is there a similar UbuntuMID root?20:59
Jaffapersiia: I suppose I mean how strategic is UMID in karmic? Or is working in Mer and reshipping it going to be "OK"?20:59
Jaffalbt: http://wiki.maemo.org/Mer is the canonical URL, btw. But I put in a redirect on "Mer/", IIRC20:59
ian_brasilhttps://wiki.ubuntu.com/MobileAndEmbedded maybe20:59
YokoZarJaffa: We like to avoid use of the adjective canonical to avoid confusion ;)21:00
lbt(oops ... paste-o)21:00
NCommanderYokoZar, rofl :-)21:00
persiaJaffa, I don't think I can answer that question.  Those of us here from Ubuntu are interested in adopting Mer for MID.  I haven't heard anyone say this wasn't a good idea.  That said, we're bound by all the freezes, etc. and if it's not good enough, we won't be able to release.21:00
Jaffapersia: fair enough21:00
JaffaYokoZar: point taken ;-)21:00
lbtclarification.... do you intend to 21:01
persiaian_brasil, I should take that URL down at some point :)21:01
lbtapply all the Mer patches to Ubuntu,21:01
lbtor take Mer code and patch it21:01
Stskeeps / branding?21:01
persialbt, apply all the Mer patches to Ubuntu21:01
persiaStskeeps, Good point.  I suspect we'll want at least some Ubuntu branding, and you may not want us to use Mer branding.  Is branding abstracted in such a way that this can be easy?21:02
Stskeepsfair, themes21:02
Stskeepserr, fairly, - themes21:02
Stskeepswe don't brand beyond themes so21:02
persialbt, To extend on that, there may be limits to which patches we may apply: MID comes fairly low in the stack of flavours, so we can't e.g. break Desktop.21:02
ian_brasilit should be quite easy to apply themes from what i have seen21:02
lbtI'm worried about us not keeping up with newer versions than Maemo21:03
persiaStskeeps, re: libgtk flavours: current flavours are directfb, shared, static, and (for armel) vfp.  Obviously someone would have to investigate the build scripts, but I suspect it's possible to do something without duplication of the base code.21:04
k-show do you plan to work with subsystems that are not present in ubuntu and AFAIK have no non-nokia backends21:04
k-slike the battery subsystem21:04
Stskeepsmce;dsme we have; battery is hal21:04
k-smce/dsme supports non nokia tablets?21:05
YokoZarBy the way, for karmic I am making a branding-ubuntu (and branding-foo) type packages to contain arbitrary branding for particular apps.  So if we want branding inside something that's not part of a theme (say, card backs on solitaire), it can be contained in that kind of package.21:05
Jaffalbt: post fremantle release, rate of change upstream in Maemo should slow down (from Nokia, anyway)21:05
lbtthat is my concern....21:05
lbtso Ubuntu gtk will progress21:05
Stskeepsk-s: powerlaunch yeah; dsme does non nokia hw with some changes21:05
lbtand we will slow21:05
Jaffalbt: ah, I see21:05
lbtand then dependency hell bites21:06
Stskeepspersia: atm maemo gtk is at 0.14 but 0.16 is in progress21:06
ian_brasilYokoZar: i would like to build a web interface for that :)21:06
lbtand those patch sets are not small21:06
persiaStskeeps, 2.16?21:06
Stskeepser, yeah21:07
Stskeepson n810 atm so21:07
k-sStskeeps: is bme dead in favor of HAL (which is also dead...)?21:07
Stskeepsk-s: no, but this doesnt relate much to ubuntu. we had meeting with nokia on hw support this weekend21:08
Stskeepswith good results21:08
k-sgood21:08
persialbt, I think we'll just have to carry/port patches anyway, especially if Nokia's Maemo updates slow post fremantle.21:08
k-sI'm asking just because hildonized/maemo/mer apps will try to use these systems and will not find them if they are not there21:09
lbtpersia: I suggested to Nokia that we become 'upstream' for their hildon...21:09
lbtthey may be able to help us port forward21:09
lbtso that the next release is easier21:09
persiaThat works.21:09
qwerty12_N800k-s: apps using libosso to listen to battery low events, etc?21:10
lbt'suggested'21:10
k-sqwerty12_N800: yes, or directly talking to bme et al21:10
persialbt, So Mer would end up generating tarballs, which Maemo or Ubuntu could use as a basis for packages?21:10
Stskeepsk-s, we plan to support mce etc in a cross platform manner21:10
lbtyes21:10
persiaI like that plan.  Very sustainable.21:10
lbtand they want to open their development21:11
lbtcf Trolltech/Qt21:11
lbton gitorious21:11
k-sqwerty12_N800: not that I like bme/mce/... they're mostly NIH stuff21:11
lbtso internally they point and say "like that"21:11
qwerty12_N800k-s: mmm, same21:11
Stskeepsnoone speaks directly to bme-but thats a discussion for later.21:11
k-sStskeeps: i'd not assume that, Canola for example do that (but we have plugin to talk to hal as well)21:12
Stskeepsanother place to look  for bme info; nice21:12
k-sjust looked at canola sources, we use icd (networking) as well21:13
Stskeepsdbus wrapper, also taken care of21:14
k-sgood21:14
StskeepsYokoZar: yeah, sounds like a good idea (branding package)21:15
YokoZarStskeeps: all upstreams will need to do is just have images and such look for /usr/share/branding/whatever and then fallback to their own artwork  21:15
Stskeeps*nod*21:15
lbtYokoZar: are you going to do that in Mer?21:16
ian_brasilYokoZar: that sounds nice21:16
* lbt wasn't paying attention21:16
lbtanyhow.... 2) Implementation outline  ??21:17
lbtwas that 2.1 done?21:17
YokoZarlbt: This can be done distribution level for whatever non-theme elements can be branded.  All your code needs to do is poke /usr/share/branding/(some to be defined hierarchy standard) for its replacement image, then we just fill that image with a branding-ubuntu package21:17
persiaI'm not sure I understand how to generate the list of packages not already in Ubuntu (2.1), and I think that's a good place for Ubuntu folk to start on packaging.21:18
lbtyeah.... so I'm not aware we have multi-branding code atm21:18
lbtmaybe this is a task?21:19
persiaYeah, a task sounds good.21:19
Stskeepsi would honestly start with libosso, libhildon and go from there - and integrate it with the cleanup process :) we have lists of packages on OBS that we override in ubuntu21:19
Stskeepswhich should give a hint of how much should go upstream ubuntu or whatever21:19
YokoZarGood point St21:20
YokoZarStskeeps21:20
lbtOBS root  is  https://build.opensuse.org/project/show?project=Maemo%3AMer21:21
Stskeeps(apologies for the novell login, they're doing openid too. :P)21:21
Stskeepsand the interesting parts are in :Devel:Base, :UI, :MaemoCommon, etc21:22
lbtI am putting together a table that will describe each package's functionality, summarise Mer-isation and link to key places21:24
persialbt, That would be great!21:24
Stskeepswe have spent some time making diffs in Maemo:Mer:Devel:MaemoCommon , so we can see what the Mer-specific package changes are21:24
lbtit'll appear on the wiki in the re-written Mer/Build area21:24
lbtanything else on this ....? or 2.2) Review of Mer cycles against Karmic schedule to define milestones   ???21:25
persiahttps://wiki.ubuntu.com/KarmicReleaseSchedule21:27
persiahttp://wiki.maemo.org/Mer/Sprints has the past: I don't know where to find the future.21:28
lbthttp://wiki.maemo.org/Mer/Releases21:28
Stskeepsyeah, we were discussing the future this weekend, just haven't been put online just yet. biggest hurdle atm: ui quirks, cross-platform consistent behaviour21:28
Stskeepsand associated applications to make it a full desktop21:29
persiaSprint ending 15 June matches well to preparation for Alpha 3 on 23 June.21:29
Stskeepshttp://bsd.tspre.org/~stskeeps/DSC00331.JPG is somewhat spec for 1.0 21:29
Stskeeps(.. whiteboard picture)21:29
persiaNext interesting dates for Ubuntu are 13th August (Alpha 4) and 27th August (FeatureFreeze).  I'm not sure how those should align.21:29
lbtand I have a higher res piccy to clear up arguments21:30
persiaErr.  Oops.  There's space for one more sprint between the current one and Alpha 321:30
Stskeepsmaybe we should talk about what you'd like to have in your karmic MID.21:30
Stskeepsstable desktop is reachable - ui and such, and some apps and such21:30
persiaStskeeps, That's simple: something that doesn't crash when one runs cat.21:30
lbtStskeeps I'm also writing that whiteboard up21:30
lbtFrankly Mer is stable21:31
Stskeepsmer is stable with some quirks.21:31
lbtit's just not that useful 21:31
persialbt, Why isn't it useful?21:31
lbtapplications by default21:31
Stskeepsnot many of the useful extras just yet :)21:31
Stskeepswe do have entire ubuntu so it helps21:31
lbtand stability/functionality of them21:31
lbtand prettiness (missing translations)21:31
Stskeepsah, yes, translations21:31
lbtbut it's not *bad* at crashing at all21:32
Stskeepsour quirks are GTK quirks really and some theme things21:32
lbtwe also have gpe21:32
persiaSo, package list is (roughly): browser, email client, book reader, media player, text editor, photo viewer, calendar, address book, file manager, instant messenger, feed reader, alarm clock.21:32
persiaRather, desired package list.21:32
lbtsure21:32
persiaWe've bunches of apps in Ubuntu (it's what we do best), so I'm sure we can find something to meet most of these requirements.21:32
lbtbut on small screen with fingers, not a mouse21:33
Stskeepsbrowser: Tear (probably), email client (claws or modest if anyone ports it), book reader (fbreader), media player (gpodder or canola), text editor (maemopad+ etc), photo viewer (mirage), calendar (not sure), address book (not sure), file manager: finefm but it needs improvement. instant messenger (pidgin), feed reader (rss-reader), alarm clock is interesting21:33
lbtgpe-cal is working21:33
lbtso is gpe-contacts and file mgr21:34
lbtxchat too21:34
lbtwe have no cron21:34
* ian_brasil +1 canola21:34
Stskeepsyeah.. alarm wakeups are interesting at the moment but it'll be better21:34
lbtmeh... it'll never catch on21:34
lbt;)21:34
persiaWell, we'll end up with cron, just as part of the Ubuntu base.  I don't think we can safely omit it with the way germinate works.21:34
lbtthat may not be good for powersaving21:35
persiaWe have a hildonised alarm clock, but it's a bit buggy.21:35
Stskeepslbt, which is where mer may differentiate a bit21:35
Stskeepssince we can wreck more in our own variant of ubuntu21:35
NCommanderpersia, Stskeeps we have fbreader21:35
persialbt, anacron (or similar) can help with that.  We don't *have* to do wakeups, but we do want to do things like log rotation.21:35
lbtsee here for things we almost have : https://build.opensuse.org/project/show?project=Maemo%3AMer%3AExtras%3ADevel21:36
lbtoverview : https://build.opensuse.org/project/monitor?project=Maemo%3AMer%3AExtras%3ADevel21:36
Stskeepsnoone said ubuntu mid should be 100% = mer, mer is closer to maemo in terms of power saving methods, and ubuntu mid usually target devices that can stand a little more beating than a arm processor :P but that's a different discussion21:36
Stskeeps(regarding alarm wakeups and so on)21:37
Stskeepsin mer (dist) we'd have alarmd instead of cron, no log files, etc for instance :P21:37
Stskeepsbut we would like to have same application API across the board (hildon, etc)21:38
persiaRight.  I think there's some rationale for separating Mer(dist) from Mer(code).  We'll want to align on code, but may make different dist choices.21:38
Stskeeps*nod*21:38
lbt:Apps may be Mer (dist)21:39
Stskeepsour hope is that we can take the same app and ideally compile it towards Maemo(Fremantle), Mer(dist), Ubuntu MID21:39
persiaFrom my biased viewpoint, I'll hope you won't need Mer(dist) in the future, but that's separable :)21:39
Stskeepswe'll see where we end up, i can sometimes in my darkest dreams hope Mer would be Maemo6 eventually, but hey ;)21:39
lbtI was thinking about Mer (dist) being a default install21:39
lbtindeed... Mer is what you get when you install Harmattan+n and only get the open SW21:40
persiaAnyway, I think we're drifting again.21:40
lbts/is/should/21:40
lbtwe are21:40
persiaSo, cycle dates.21:41
lbtI'll do a list of apps21:41
lbtand allow us to track them21:41
persiaThis Mer cycle ends soon.21:41
Stskeepsreasonably we'll have some more apps and some work, and stable fremantle beta1 packages21:41
persiaI think Next Mer cycle would do well to try to end ~ 16th July to give time to push everything for Ubuntu Alpha 3.21:41
YokoZarYes, the Ubuntu cycles are important to keep in mind -- they're surprisingly stricter than many upstreams are used to because of the time based release process21:42
Stskeepsyeah, we had some discussions on that at the meeting :)21:42
persiacycle+2 has a couple sensible targets: either a bit before the 31th (for Alpha 4) or a bit before the 27th (for FeatureFreeze).21:42
persias/31/13/21:42
persiaAlternately, perhaps have a testing release around the 13th, and the cycle end around the 20th.21:43
Stskeepslet me just see the sprint calendar, sec21:43
persiaAfter that, we'll diverge, and Ubuntu will only be able to accept backported bugfixes except in very special cases.21:43
Stskeepsright, 13th july would be our release date21:44
Stskeepsof 0.1521:44
persiaOK.  That works.  Then we have two weeks to chase any features from 0.16 we *really* want for 9.10, even if they aren't quite polished.21:44
Stskeepsif we work together to clean up packages, minor GTK fixes and such, we should be able to get a decent result in21:45
persiaWe can pull the polish for 0.16 post FF.21:45
lbtpersia: I'd expect those 2 weeks to be polishing 0.1521:45
persiaErr, 0.1721:45
Stskeepsi'll say this again though: we need to really look at maemo gtk - it's one of those annoying things about Mer/Maemo code. a lot of apps rely on maemo gtk :)21:45
Stskeepsso that should be one of the first priorities as well21:46
persiaHrm?  0.14 comes out RSN, right?  0.15 in July (for Alpha 3), 0.16 in August (near Alpha 4), and 0.17 won't finish before FF, right?21:46
lbtseconded21:46
Stskeepspersia: yeah, 15th june21:46
persiaRght.  So 0.17 will be what ends up in 9.10.21:46
Stskeepskeep in mind that this is dist release. individual packages may reach stable releases quite often21:46
persiaUnless the goals for 0.18 can be bugfixes (no new features), in which case we can probably pull that21:47
Stskeeps*nod*21:47
Stskeepsso it looks like we sync pretty nicely21:48
persiaI wouldn't expect to be able to get 0.19 into Ubuntu, so that might be a good opportunity to catch up on feature development missed in 0.18, and we can resync with 0.20 in November.21:48
* lbt is confused ... "0.17 won't finish before FF" "0.17 will be what ends up in 9.10"21:48
Stskeeps0.14 i think21:48
persiaOK.  Let me try this again.21:48
persia0.14 should release RSN, and will probably roughly match the initial uploads to Ubuntu.21:49
persia0.15 should release in July, and ought to be the basis of the Alpha 3 images.21:49
persia0.16 should release in August, and ought to roughly match the Alpha 4 images.21:49
persia0.17 crosses feature freeze: with luck we can push affected bits of that in time, and so have that be the feature basis for 9.1021:50
Stskeepssounds good to me21:50
persiaIf 0.18 (releasing in September) focuses on bugwork, and doesn't include new features, we can probably pull it entire.21:50
persiaIf there are new features, we'll have to backport the bugfixes, which is more work for all of us.21:51
lbtah... pushing 0.17:Testing pre-FF then? OK21:51
lbtand it will make sense by then to have a bugfix cycle I'm sure!21:51
persia0.19 (releasing in October) is too late to get into Ubuntu, so it's a good time to work on experimental features skipped in 0.18.21:51
persialbt, Right.  Bit of scheduling coordination needed, but I think we can do it.21:52
Stskeepswe're not tightly locked to months, we change once in a while, so if need be, we adjust21:52
persiaThen, 0.20 should release in November, and we can pull that as the first import of Ubuntu 10.04.21:52
GrueMasterThat actually sounds like a great cycle.  Odd, Experimental, Even Stable.21:52
lbt<groan>21:53
YokoZar?21:53
YokoZarlbt: were you concerned by that?21:53
lbtnot really :)21:53
lbtamusedf21:53
lbtold kernel numbering ....21:54
GrueMasterActually, it is still used in the kernel community, along with a lot of other development areas.21:55
* persia notes that it's now 6am locally, and hopes to chase the agenda to *finish* the meeting.21:55
lbtpersia... are you going to update the schedule as per comments21:55
lbtI'll do the Mer sprints page21:56
lbtand crosslink21:56
persialbt, I don't think the Ubuntu Release Team cares what schedule we use, but I'll update the spec to detail the correspondance.21:56
Stskeepsok, so where are we in outline?21:57
lbtOK21:57
YokoZarStskeeps: we're at testing now I believe21:57
lbt2.3) Image creation21:57
persiaRight.  So, we've this big complex environment to create images.21:57
persiaIt's easy for us to create .isos for i386.21:57
persiaIt's perhaps less clear what (if any) images to create for armel.21:58
lbt(Mer has one too... we call it Stskeeps)21:58
persiaSo, I thought we might just create .isos for armel as well, expecting the rootfs to be extracted by anyone wanting to do an install.21:58
Stskeepsmight work21:59
lbtcan we auto-extract?21:59
persiaSaves thought, and probably scales better to the wide variety of armel devices that need kernels not included in Ubuntu.21:59
lbtshould be easy enough21:59
persialbt, It's possible to write scripts that extract, but I'm not sure we can have autoextraction happen on the Ubuntu cdimage server.22:00
lbtOK, shall we leave that as an Ubuntu problem then?22:00
lbtI'll note as an issue22:01
persiaSure.  Just something to be aware of for the future.22:01
persiaI suspect that users will probably cross-post bugs and support requests, etc.22:01
lbtdo you have a target list of machines?22:01
lbtlike we have N8x0, Freerunner, SmartQ etc22:02
lbtauto-extract doesn't have to happen on the server22:02
persiaTheoretically, we'll support anything.  In today's kernel meeting, it was indicated that there was an expectation for support for only one or two SoCs for karmic, which restricts the list.22:03
Stskeepsk22:03
persiaFor Karmic everything is compiled for ARMv6+vfp, so the freerunner won't work.22:03
Stskeepsyeah, it already doesnt22:04
persiaAnyway, if nobody objects to my suggestion about images, let's do it that way and move on.22:04
Stskeepsk22:04
lbtand again for testing does it make sense to pick a few targets to understand their needs22:04
lbtanyhow... we'll get to that I guess22:05
persiaSure, although we've the kernel issues, which makes it tricky.22:05
persiaI think I'd rather focus on application and environment testing for now.  We can get into the deep stuff once that's working.22:05
YokoZarAgreed (hardware wise, I'll be doing testing on the two pandoras I've ordered)22:06
lbtI don't think Meirziki is around22:06
GrueMasterI also plan on ordering a Pandora, as soon as I get my replacement credit cards.22:07
Stskeepsregarding devel and testing we will have 0 smartq5/7 rebates too22:07
lbtthat many?22:07
Stskeepser22:08
Stskeeps1022:08
persiaI've an i386 MID which I can use for testing.22:08
lbtGrueMaster: are you going to put up a target list of 'tested' hardware?22:08
Stskeepsubuntu mid developers will fit under this too22:08
lbtand are we going to pool test resources?22:08
lbtwe'll test yours if you test ours22:08
GrueMasterI only have limited hardware to test with, but I can.22:08
persialbt, Depends on how much testing you want for 0.20.  If you're happy to pool, we certainly are.22:09
persiaErr, 0.19 :)22:09
lbtI think we need to start testing early unless you're up to speed22:09
lbtwe're not!22:09
lbtdo you have test processes for Ubuntu that work for MID ?22:10
GrueMasterSome, but not much at the moment. 22:10
persiaThat comes to 3.2: we need some test plans.22:10
lbtOK... should you/we aim to start testing Mer 0.15 ?22:11
persiaI think we have some for installation, but nothing for any applications.22:11
GrueMasterIt really depends on the application.  If it supports ATK, we can automate.22:11
persia0.15 / Alpha3 sounds like a good place to start integrated testing.22:11
Stskeepsagreed22:12
persiaBut we'll need test plans beforehand.  Anyone up for writing some?22:13
lbthmm I was going to say : GrueMaster are you the guy who's going to write the plans....22:13
lbt;)22:13
GrueMasterI really have little experience with MER at the moment.  I saw it in action at LinuxFest NW, but only briefly.  If I can get it working here, I can start writing something up.22:14
Stskeepswell its hard when not knowing what intended collection of components would be22:14
lbtOK... atm are we focusing on app plans?22:14
GrueMasterMore like basic functionality.22:14
StskeepsGrueMaster: was johnx presentingÂ:)22:14
persialbt, Do you think we should focus on something else?22:14
lbtand things like desktop/menu/statusbar22:14
GrueMasterMight have been.  I can't remember.22:14
lbtwell, we have limited resource... the foundations should be stable22:15
lbtwe need to focus on the areas we touch most22:15
lbtlike keyboard integration things22:15
Stskeepswe will definately know more when hildon desktop runs in mid22:17
lbton the Mer side we have Merziki... but I really don't feel comfortable knowing how much time he has22:17
persialbt, Right.  I don't think we need to touch much of the base Ubuntu stuff: just some basic tests to make sure that Mer works.22:17
lbtare you also interested in Mer/Ubuntu integration testing (whatever that means)22:18
lbthmm22:18
lbtlike package mgr22:18
lbtthat's an interesting one :)22:19
GrueMasterThat would be part of the testing.  Make sure the default apps sit well with the UI.22:20
lbtactually our application manager is a bit special AFAIK22:20
persialbt, Indeed.  I know we have a hildonised update-manager, but I'm not sure we have a good package management UI.22:20
lbtStskeeps will it even work on a normal repo?22:20
Stskeepsyeah22:21
lbtand the categories etc22:21
lbtand what apps it shows?22:21
Stskeepshackable22:21
lbtit is very cut down22:21
lbtOK22:21
lbtso that's just an Ubuntu task then... hack the appmgr...22:23
lbtIt feels a little like we've stalled on 3) Testing Review22:23
lbtdo we defer to next time?22:24
lbtor will someone volunteer to have some testing answers by then?22:24
GrueMasterSorry, most of my previous testing experience has been automated hardware testing.  I'm still shifting to software testing ATM, but coming up to speed fast.22:24
persiaI think we can safely defer: I believe we've covered most of the essentials, and at least know what needs doing.22:25
lbtwell, if you want to volunteer GrueMaster then I can help... and maybe talk to MZ too22:25
=== dyfet__ is now known as dyfet
GrueMasterThat'll work.22:26
persiaThe only last point is 3.3: once we get the test cases defined, we'll need to make sure we get full test coverage for all the published images for each milestore in Ubuntu (e.g. Alpha 3, Alpha 4, etc.) or we won't be able to be included in the release.22:26
GrueMasterI think plars has that angle.22:27
lbtOK... I have a list of some actions and issues I can cut'n'paste...22:28
persiaOK.  Anyone have anything else we *need* to cover?  I think it's getting quite late in Denmark :)22:28
persialbt, Please do.22:28
lbtISSUE: version tracking. Eg Maemo/hildon gtk will freeze22:28
lbtISSUE: How should Ubuntu best produce images (eg ISOs are easy but may need rootfs or extractor script)22:28
lbtACTION: Support/provide release commits like this : http://www.winehq.org/announce/1.1.2222:28
lbtACTION: Review objectves of Mer->Ubuntu upload and determine timing (:Testing2 or just :Stable) with persia22:28
lbtACTION: Produce workflow to be quilt and git-branch based22:28
lbtACTION: Contact Nokia re making Mer upstream for open development of Gtk (via gitorious cf Trolltech/Qt)22:28
lbtACTION: Page listing apps for featureful release and status/links22:29
lbtACTION: Update Mer Sprints page to show schedule sync and crosslink to KarmicReleaseSchedule22:29
lbtACTION: GrueMaster to put up a target list of 'tested' hardware22:29
lbtTASK : Ubuntu code needs to poke /usr/share/branding/(some to be defined hierarchy standard) then filled with a branding-ubuntu package22:29
lbtTASK : Ubuntu taskto hack the appmgr to work as needed22:29
lbtnb... the tasks are mine for Mer unless there's a name22:30
lbts/tasks/actions/22:30
persiabranding is probably YokoZar22:31
YokoZarYes22:31
persiaI'm happy to help with the package manager.22:31
Stskeepsalso work out workflow, git, packaging, mid people access to mer trees etc22:31
lbtStskeeps that's already on my sprint page22:32
Stskeepsk22:32
lbt(apart from mid people access)22:32
lbtI'll add that22:32
NCommanderI'll also help w/ package managerment22:32
NCommanderWait, did we cover how we want to handle uploads into Ubuntu itself? To my knowledge, no one in Mer is MOTU22:32
NCommanderor, wait, nm, I see it22:33
persiaRight.  Getting Mer folk upload rights is my task from the UDS session.  I think it's best left until we've sorted some of the basics, and have a good workflow established.22:33
YokoZarI'm MOTU ;)22:34
Stskeepsyep22:34
lbtactually we have an action to talk to persia about becoming devs22:34
Stskeepswe will see if its even needed i guess22:35
persiaStskeeps, I think it will be convenient, much as I suspect it would be useful for a few Ubuntu folk to have commit rights (once we sort out who is actually doing enough to use them)22:35
lbtyeah, I suspect the workflow will be pull but people may well have 2 hats :)22:36
Stskeepsk22:37
lbtschedule timing for next meeting ?22:37
lbtwhilst people digest22:37
persiaWell, do we need another big comprehensive meeting soon?22:38
lbtwell.... I'm more thinking that we may need nagging22:39
persiaPersonally, I'd rather chase the open TASKS, with discussion here, in #mer, on ubuntu-mobile@ and with mer-chatter@22:39
Stskeepsone on ones maybe; lbt and someone on workflow and packaging22:39
persiaIf we bog down, we can schedule something.  Otherwise, I think we're in good shape for three weeks or so.22:40
persiaStskeeps, Absolutely: I suspect we'll need a bunch of those.22:40
lbtok 3 weeks then... how does that fit to release cycle?22:40
lbtStskeeps?22:40
NCommanderpersia, commit rights to Mer's git trees?22:41
StskeepsNCommander: easily22:41
lbtNCommander: help me figure out the workflow and you're there...22:41
Stskeepswe are open so22:41
persiaNCommander, for those that are doing enough that it becomes easier to grant commit than to review, why not?  Same for uploads to Ubuntu.22:41
NCommanderpersia, I was just asking for clarification; I missed a bit of the meeting, but it was my impression that everything was going to be in upstream git w.r.t to packaging unless I'm mistaken.22:42
persiaI thought we were doing separate branches for packaging, but I could be mistaken.22:43
lbtNCommander: I'm working on that...22:43
lbtI would like to do branches for packaging and patches22:43
NCommanderWell, LP is getting the ability this(?) or next week to do git imports22:43
persiaThat's the workflow bit that needs to be sorted (but at a time that's more convenient to those of us not in negative timezones)22:43
lbtyes22:44
lbtNCommander: do you have opinions? 22:44
lbtif so then I'll work with you22:44
NCommanderlbt, I can think of a few good ways we could do this.22:45
lbtOK... you're named in my action ;)22:45
NCommanderwoo!22:46
Stskeepsk, anything else im needed for? else im off to bed22:49
persiaYokoZar, Are we done?22:49
YokoZarI believe so22:49
lbt23rd June?22:49
YokoZarSomeone should log this22:49
YokoZarand save it somewhere22:49
YokoZar(especially the action items)22:49
GrueMasterI've got logging enabled.  Let me know where to post.22:50
YokoZaryour wiki I guess22:50
persiaI think it's already logged.22:50
lbtThe action items will go on the Mer wiki somewhere22:50
* persia double-checks22:50
persiahttp://irclogs.ubuntu.com/2009/06/02/%23ubuntu-mobile.html22:50
Stskeepsbbl, thanks for the meeting, gf wants me to sleep nowÂ:P22:51
GrueMastergood enough.22:51
lbtnight Stskeeps22:51
YokoZarCheers, thank you everyone22:56
lbtyep... g'night all and thanks22:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!