[16:56] <teward> i hate crash bugs, can someone remind me what we have to do before making crash bugs public?
[16:56] <teward> i haven't touched one in an eon
[17:09] <rbasak> teward: just check it has no confidential information. AFAIK, that's it.
[17:20] <teward> rbasak: confidential information such as possible passcode strings in the stack trace, etc.  And deleting the coredump if it exists?


[00:05] <nhaines> In case you're wondering, it's a 1,874,040-byte MP4.
[00:06] <pleia2> haha
[00:06] <pleia2> very familiar with that scenario
[00:10] <nhaines> We've recently gotten our cats into chicken, but mostly unless it's some kind of dairy they're completely uninterested in human food once they've smelled it.
[00:10] <pleia2> mine like turkey
[00:12] <nhaines> Ours seem to almost humor us when it comes to the chicken.  But at least we don't have to guard our food constantly.  I've played that dance before.
[00:13] <pleia2> Simcoe has renal failure, so she's always thirsty and we have to keep our glasses covered or guarded
[00:13] <nhaines> I don't remember seeing a chart lately.  How's she doing?
[00:15] <pleia2> not great, but I think she's still happy
[00:15] <nhaines> Happy is good to hear.


 weird issue about ogg, I kinda understand about m4a though.
 is Kubuntu 24.04 planning to use Plasma 6? or waiting due to LTS?
 anyone here using whatsapp from snap ?
 the UI broken on kubuntu wayland
 the UI broken (weirdo) on kubuntu wayland, not sure either its scaling related or not but its working fine in Gnome
 previously its working find in kubuntu wayland
 Almost certainly waiting (re @MichaelTunnell: is Kubuntu 24.04 planning to use Plasma 6? or waiting due to LTS?)
 waiting...
[10:22] <Tm_T> holla
[10:34] <Tm_T> I can reproduce repeatedly some already known bugs with kubuntu installer, is it worth poking more or just use gtk-based installers instead?
[12:20] <BluesKaj> Hi all
 Almost certainly waiting (re @MichaelTunnell: is Kubuntu 24.04 planning to use Plasma 6? or waiting due to LTS?)
[19:49] <RikMills> plasma 5.27.9 in backports for mantic and backports-extra for jammy


[04:21] <mterry> mzanetti, you're just writing reminders-app tests early on Saturday morning?  :)
[04:22] <mzanetti> :D
[15:11] <conmute> Hi1


 Ignorant people don't.
[14:09] <Mandem0110> Polite*
[14:09] <Mandem0110> So yes. Whatever.
[14:13] <leftyfb> Mandem0110: that's enough
[14:14] <PeGaSuS> sorry for feeding the troll, though. but got a bit upset. :x
[14:33] <lotuspsychje> merry xmas to all who celebrate tonight/tomorrow
[14:35] <PeGaSuS> thanks! you too!
[14:35] <lotuspsychje> tnx PeGaSuS


[00:28] <zkriesse> mdke: are you available?
[03:56] <zkriesse> HAPPY FOURTH!
[09:23] <epic93> Hello.
[21:09] <tyarusso> Can anyone recommend a good book for learning DocBook?
[21:10] <j1mc> tyarusso: http://www.docbook.org/tdg5/
[21:11] <tyarusso> ah, excellent
[21:11] <j1mc> tyarusso: that book covers docbook v.5, where ubuntu docs are still on docbook v.4, but *most* of the syntax carries over.
[21:13] <j1mc> tyarusso: this one covers docbook 4, which is what ubuntu uses: http://www.docbook.org/tdg/en/html/docbook.html
[21:14] <j1mc> the schema for docbook was completely rewritten from docbook 4 to docbook 5, but much of the basic syntax remains the same.
[21:14] <j1mc> let us know if you have questions
[21:19] <ddecator> so i was going to ask philbull, but since he's not here maybe someone else can help. i want to apply the "headers" used on https://wiki.ubuntu.com/BugSquad to the other bugsquad pages since they look nicer. however, since they aren't real headers, that messes up the TOB. someone in #moin suggested i change the theme's css so headers appear that way. are we able/allowed to change the theme for ubuntu pages?
[21:22] <j1mc> ddecator: what is a TOB?
[21:23] <ddecator> j1mc: Table of Contents
[21:26] <j1mc> ddecator: i'm a bit unclear on what you mean by the headers.  do you mean the "bugsquad" "todo list"... items toward the top?
[21:27] <ddecator> j1mc: no, the "What is the Bug Squad?" "Contact Us!" "Activities" "Want to Join?"
[21:29] <tyarusso> j1mc: It appears that the tools for working with it are still for DocBook 4 in Lucid as well.
[21:30] <j1mc> ddecator: ok, i think i understand what you're looking to do now. i don't know if we can do it.  matthew east would probably know best.
[21:32] <ddecator> j1mc: ok. i could probably find a way to manually create a table of contents, but then it'd have to be updated each time an area is added or removed. what's matthew east's nick?
[21:32] <j1mc> tyarusso: yeah - ubuntu docs aren't really set up for docbook5 right now.  docbook5 is in the repositories, though.
[21:32] <j1mc> ddecator: it is mdke
[21:32] <ddecator> j1mc: thanks!
[21:34] <tyarusso> j1mc: ah, so it is.


[19:59] <lbt> Hello from Mer
[20:00] <NCommander> lbt, hello from Ubuntu!
[20:00] <YokoZar> hello thar
[20:00] <Stskeeps> <- here too
[20: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 text
[20:01] <NCommander> Oh, right, we have that meeting!
[20:01] <persia> Ah, looks like YokoZar already pasted :)
[20:02] <YokoZar> hello hello
[20:03] <Stskeeps> and we have maemo.org council chair (jaffa) listening in as well
[20:03] <persia> Hey Jaffa
[20:04] <Jaffa> Hiya
[20:04] <Jaffa> At JavaOne, so mostly just reading :)
[20:04] <YokoZar> All right
[20:04] <YokoZar> Let's do introductions.  Who's here for the meeting then?
[20:05]  * YokoZar is Scott Ritchie, an Ubuntu Developer
[20:05]  * persia is Emmet Hikory, an Ubuntu Developer
[20:05]  * lbt is the build/sdk/process/packaging/docs non-expert for Mer
[20: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) :P
[20:05]  * lbt is David Greaves
[20:05]  * NCommander is MIchael Casadevall, an Ubuntu Developer, and a Mer user
[20:06]  * ian_brasil me
[20:06] <YokoZar> :)
[20:06] <NCommander> ;-)
[20:06] <GrueMaster> GrueMaster - Ubuntu Mobile QA testing.
[20:06]  * Jaffa is Andrew Flegg, Maemo Community Council chair
[20: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:07] <GrueMaster> Oh, Tobin Davis.  (oops).
[20:07] <luke-jr> (is the meeting open, or restricted?)
[20:07] <YokoZar> open
[20:07] <NCommander> (the meeting is open)
[20:07] <YokoZar> All Ubuntu meetings are, generally (except security issues)
[20:07]  * luke-jr is Luke Dashjr, a developer for the unofficial Gentoo N8x0 port
[20:07]  * lcuk is Gary Birkett, author of liqbase (n8x0 device ui)
[20:08]  * rgreening is lurking, but has $WORK in the way. need to restore broken network...
[20:08] <YokoZar> Ok, nice, we have quite a few people here
[20:09] <YokoZar> The 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:10] <lbt> I got this as an outline http://pastebin.com/d7c524616
[20:10] <YokoZar> lbt: yup, that's the agenda more or less
[20:11] <YokoZar> Everyone, please feel free to ask any questions you have as we bring things up, this meeting is about all of us learning
[20:11] <Stskeeps> *nod*
[20:12] <NCommander> I 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 Ubuntu
[20:12] <YokoZar> At 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] <YokoZar> NCommander: I agree
[20:12] <YokoZar> Mer, as I understand, won't be a typical upstream like I just mentioned ;)
[20:12] <YokoZar> Instead we want to work a bit closer
[20:12] <NCommander> I did a look over in an advance of the packaging of Mer, so I'll bring that up after the general upstream status :-)
[20:13] <lbt> YokoZar: process makes sense and aligns
[20:13] <lbt> but layered diffs is an interesting area...
[20:13] <Stskeeps> our 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:14] <Stskeeps> ideally ubuntu packaging would be == mer packaging
[20:14] <Stskeeps> as in, the cleaned up ubuntu packaging ;)
[20:15] <YokoZar> In 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 quilt
[20:15] <lbt> yes
[20:15] <lbt> we'd like that
[20:15] <lbt> although the maemo packages include /debian
[20:16] <persia> lbt, Would having the packaging outside the Mer repos block your builds for the Mer cycles?
[20:16] <lbt> and that may need .... tweaking
[20:16] <persia> (e.g. stripping the Maemo debian/)
[20:16] <Stskeeps> stripping maemo debian/ should be possible
[20:16] <NCommander> Stskeeps, well, OBS will build any package that Ubuntu can, so once the packaging is brought up to scratch, that will work fine
[20:16] <persia> I'm just concerned about not blocking Mer test cycles by doing so.
[20:16] <lbt> I am looking at introducing a (git) VC system to do this
[20:16] <Stskeeps> basically: we are in the midst of cleaning up our act, so we are -very- open to changes
[20:17] <lbt> and managing the seperation of src,diff,/debian
[20:17] <YokoZar> lbt: Yes, it's also possible to have the debian/ folder live inside a branch
[20:17] <lbt> indeed
[20:17] <Stskeeps> we would also like to find a good way to deal with upstream (and we discussed this a bit with nokia)
[20:17] <lbt> http://wiki.maemo.org/Mer/Documentation/Mer_Package_Patch_Handling
[20:17] <YokoZar> lbt: indeed this is what much of the "use bzr for more things" push is about in Ubuntu
[20:19] <lbt> in principle the 1 branch per patch approach works for me
[20:19] <Stskeeps> well, or simple quilt patch management
[20:19] <lbt> and 1 branch per packaging flavour
[20:19] <lbt> then export that into quilt
[20:19] <YokoZar> Quilt is very nice for this sort of thing
[20:19] <k-s> well, most top level packages should rely on the same dependencies and all, so the diff would be just about changelogs, no?
[20:20] <k-s> lower level packages have (or used to) different dependencies as maemo used different names
[20:20] <lbt> i'm open... was looking to setup VC for developers and take branches into quilt for /debian/patches
[20:20] <lbt> we have quite a few code and build patches
[20:21] <NCommander> Stskeeps, YokoZar I'm not sure if your aware, but quilt can be intergrated into the package build process
[20:21] <YokoZar> NCommander: yes, in fact this is where I thought it most powerful
[20:21] <YokoZar> NCommander: the build script just applies the quilt patches at build time
[20: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] <NCommander> YokoZar, yup :-)
[20:21] <lbt> yes
[20:22] <lbt> and for me .... each /debian/patches/ file comes from a VCS branch
[20:22] <persia> NCommander, Except we're dealing with stacked trees, because Mer itself is, in part, a set of patches against Maemo
[20:23] <NCommander> persia, VCS import the Maemo trees, and then stack off that
[20:23] <NCommander> If possible
[20:23] <lbt> yes...
[20:23] <lbt> master branch is .orig
[20:23] <Stskeeps> we'd really really want to base on tar.gz's, you can't rely on the vcs
[20:23] <persia> I 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] <persia> Stskeeps, pristine-tar can help with coordination between tar.gz and VCS repos.
[20:24] <NCommander> persia, 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] <Stskeeps> persia: interesting, didn't know that (per upload)
[20:24] <persia> NCommander, Yes, but we don't prefer it.
[20:24] <NCommander> persia, this is a unqiue case ...
[20:25] <Stskeeps> basically we are going to be doing a lot of fast-paced development where we will need to be doing within-mer package upgrades often
[20:25] <YokoZar> It's not too hard to have one changelog entry with a bunch of bits to it
[20:25] <Stskeeps> we can however also work on a way to merge multiple versions into one upload for instance
[20:25] <lbt> big changelogs though...
[20:26] <lbt> we may need to manually summarise
[20:26] <Stskeeps> we can however be happy we're at a stage where we aren't patching much anymore.
[20:26] <persia> Indeed.  That's supported, but I think a manual summary would be preferred.
[20:26] <YokoZar> Do you give version summaries already?
[20:26] <YokoZar> Or are your release changelogs just big lists of commits?
[20:26] <lbt> commit list
[20:26] <lbt> if anything :)
[20:26] <Stskeeps> currently our packaging is occasionally a mess, and the changelog reflects the changes
[20:27] <persia> My 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] <Stskeeps> well. we can always abuse that mer < ubuntu lexically..
[20:27] <Stskeeps> so ubuntu4 would wrap certain mer versions
[20:27] <YokoZar> This 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:28] <YokoZar> (I mention this because it's exactly how I package Wine, and it comes out every 2 weeks)
[20:28] <lbt> we could do that
[20:28] <lbt> hmmm
[20:28] <lbt> we should do that
[20:28] <YokoZar> If 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:29] <lbt> we are still building processe and supporting scripts
[20:29] <Stskeeps> when dealing with the maemo packages we are mostly doing patches and not so much our own development (yet - it's getting there)
[20:29] <lbt> we only just transitioned to OBS
[20:29] <lbt> and I'm in the process of setting us up to handle logging these changes.
[20:29] <lbt> we don't use (AFAIK) the OBS commit messages
[20:30] <lbt> which are (in my case) cut'n'paste from local git repos
[20:30] <lbt> so we (I) need target specifications
[20:30] <YokoZar> Stskeeps: that's cool, there's no requirement that changelog entries be interesting ;)
[20:31] <qwerty12_N800> Is swearing frowned upon in changelogs?
[20:31] <Stskeeps> ah, yeah, we might want to filter some. :P spending too much time with maemo packages makes you do stupid things.
[20:31] <YokoZar> qwerty12_N800: heh -- probably not wise in the summary, but ok in commit messages ;)
[20:32] <lbt> persia you said : I suspect we only want one or two Ubuntu uploads per Mer cycle....
[20:32]  * lcuk sighs with relief
[20:32] <lbt> did you mean 1 or 2 Mer cycles between uploads?
[20:32] <persia> lbt, Just a loose guess.  One right before the testing phase, and one at cycle completion.
[20:32] <YokoZar> Just 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:33] <persia> Mind 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] <lbt> OK ... so upload when we promote our first :Testing
[20:33] <persia> lbt, That was my thought, but I'm open to alternate suggestions.
[20:33] <qwerty12_N800> YokoZar: yeah, I allowed my frustration to get the better of me. I'll try and find those changelogs...
[20:33] <lbt> persia.... why?
[20:33] <Stskeeps> basically, what we hope to start with is simply to slowly start moving packages to "new" workflow. beginning with libosso and libhildon
[20:34] <NCommander> THat's actually something I wanted to bring up
[20:34] <Stskeeps> and getting also upstream relations going (libhildon is open to different packaging based off their git trees, and is open now.)
[20:34] <NCommander> We 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] <persia> lbt, Why which?  Why two uploads, or why am I looking for alternate suggestions?
[20:34] <lbt> our :Testing can be quite... raw
[20:35] <lbt> so if you intend to publish to end users then it may be good to go for :Testing2
[20:35] <NCommander> We'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] <persia> NCommander, current MID upstream doesn't support the current codebase anymore.  I don't think we need to worry about it much.
[20:35] <NCommander> persia, I'm more worried about libhildon's rdepends.
[20:35] <Stskeeps> NCommander: our libhildon is mostly pure
[20:35] <NCommander> StevenK, our libhildon is ancient
[20:35] <lbt> persia... l8r
[20:35] <persia> I 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] <persia> lbt, Catch me anytime :)
[20:36] <NCommander> persia, 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:37] <Stskeeps> if you're wondering if dates-hildon still work, it does :P
[20:37] <Stskeeps> we have a transformational package to help support your naming, but it's not that nice
[20:37] <persia> NCommander, Hrm.  Probably worth a review of rdepends then, indeed.  I suspect we'll want to keep some of them.
[20:37] <NCommander> persia, agreed, but I can think a few we can toss as well
[20:37] <k-s> NCommander: wonder tha same
[20:38] <NCommander> persia, 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-packages
[20:38] <k-s> packages like gnumeric and other hildonized... what todo? two versions that conflicts?
[20:38] <lbt> are these hildonisations not from Nokia?
[20:38] <Stskeeps> nah, ubuntu mid ones
[20:38] <Stskeeps>  / moblin
[20:38] <persia> NCommander, 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] <lbt> OK, so if you want to push these into Mer then they'd need maintainers I guess
[20:39] <NCommander> persia, 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] <persia> lbt, 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... pointless
[20:39] <NCommander> k-s, +1
[20:39] <persia> NCommander, I do believe I'm actioned to do just that on https://wiki.ubuntu.com/Specs/MobileMidKarmicUseMer :)
[20:39] <Jaffa> A lot of the Hildonised apps from Ubuntu MID old would be good to go -> Mer, and maybe -> Maemo
[20:39] <YokoZar> So 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-s> it's just there because Nokia used to want hildon as closed source extension
[20:39] <NCommander> What 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 without
[20:40] <Stskeeps> hildonization 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] <lbt> I think that is no longer a problem?
[20:40] <k-s> proper engineer would be to patch gtk to provide better widgets for finger use
[20:40] <NCommander> brb, battery flashing signs of death
[20:40] <persia> I think I like autohildonisation better.
[20:40] <Jaffa> k-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] <Stskeeps> we encourage hildonization because there's a little more to it than just UI
[20:40] <k-s> Jaffa: ok, but then it's not hildonization as change toolbar or menu, but *new* ui
[20:40] <Stskeeps> such as the libosso stuff
[20:40] <lbt> yes
[20:40] <persia> Jaffa, Trick is in maintenance: we don't really want to have to carry two versions of e.g. the gnumeric codebase.
[20:40] <k-s> Stskeeps: libosso is also bs
[20:41] <lbt> very few apps are hildonised
[20:41] <lbt> Nb... Qt is trying to hildonise the framework
[20:41] <k-s> Stskeeps: yet-another NIH
[20:41] <k-s> lbt: yes, andthat is transparent to users
[20:41] <lbt> yes
[20:41] <Stskeeps> k-s: admittedly things could have been better
[20:41] <Stskeeps> but some of the signals that it gets are useful for mobile usage
[20:41] <k-s> anyway, most (or all) of this will be dead soon
[20:42] <Stskeeps> care to elaborate on that?
[20:43] <NCommander> BTW, I think another point worth bringing up is what architectures do we care about w.r.t to Mer
[20:43] <NCommander> (side note but important)
[20:43] <k-s> Stskeeps: i see this going away, I have inside info on the topic, but cannot disclose much :-P
[20:43] <YokoZar> NCommander: agreed
[20:43] <lbt> (nb k-s  I didn't catch your introduction)
[20:43] <Stskeeps> k-s: ah, harmattan probably
[20:43] <Stskeeps> NCommander: we're agnostic to architecture as such (if we see it on package level)
[20:43] <k-s> lbt: I'm Gustavo Barbieri, used to work at INdT, architect and lead developer of canola 1/2
[20:44] <NCommander> Well, this case is kinda special because of the way ubuntu-mid was handled
[20:44] <lbt> :) ta
[20:44] <GrueMaster> Arch wise, we should focus on the two mid architectures (x86 & arm).
[20:44] <NCommander> As 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, arm
[20:44] <k-s> lbt: now owner of ProFUSION embedded systems, which do contract for Canonical and couple of other companies on embedded/mobile field
[20:44] <persia> GrueMaster, i386 & armel ?
[20:44] <GrueMaster> In otherwords, no IA64 ports for NCommander.
[20:44] <NCommander> Right, I agree, but we're also going to get amd64, sparc, and ia64 for no added cost :-)
[20:44] <NCommander> and powerpc
[20:45] <Stskeeps> our wii port would be happy for powerpc ;p
[20:45] <NCommander> \o/!
[20:45] <YokoZar> mobile wii?
[20:45]  * NCommander tried to run Ubuntu MID a long time ago on his wii
[20:45] <Stskeeps> mer on wii: http://smg.photobucket.com/albums/v119/JohnX/?action=view&current=CIMG5444.jpg
[20:45] <Stskeeps> (missing background)
[20:45] <YokoZar> My Wii got mobile when my brother threw it against the wall in frustration.  Anyway...
[20:45] <k-s> YokoZar: lol
[20:45] <Stskeeps> but anyway, we are in no way restricting what archs to build on - all that stuff is in our HW support repos
[20:46] <NCommander> (it should be noted for the record that there is an Ubuntu PS3 port so ....)
[20:46] <persia> So, I think we covered 1.1 and 1.2 on the agenda.  Shall we go to 1.3?
[20:46] <NCommander> That's sexy :-)
[20:46] <GrueMaster> For testing purposes, I am limited to i386/lpia, and arm.
[20:46] <YokoZar> persia: That was my thought.  Any more questions on work flow?
[20:46] <NCommander> GrueMaster, I thought you had an amd64
[20:46] <NCommander> (not that we really care but)
[20:46] <Stskeeps> regarding Mer and work flow, lbt is the guy to talk to from us, he's in charge of developer tools etc :)
[20:46] <lbt> persia http://wiki.maemo.org/Mer/
[20:46] <GrueMaster> NCommander: It is dedicated to LSB testing.
[20:47] <lbt> that is the root for our info sources
[20:47] <Stskeeps> so he'll gladly sit down with some of you and get a workflow worked out that suits us all
[20:47] <NCommander> persia, where's the agenda? I don't see it on the wiki
[20:47] <lbt> yes indeed
[20:47] <YokoZar> I think the consensus seems to be (1: small changelog improvements, 2: use quilt whenever we can
[20:47] <lbt> agenda : http://pastebin.com/d7c524616
[20:47] <Stskeeps> NCommander: http://pastebin.com/d7c524616
[20:47]  * lbt scores
[20:48] <lbt> YokoZar: I would like to work a git->quilt process too
[20:48] <YokoZar> lbt: Ok, that shouldn't be too hard (takes only a few commands when done manually I think)
[20:49] <Stskeeps> regarding upstream libhildon info: https://garage.maemo.org/projects/hildon
[20:49] <lbt> I'm not sure we sorted the stacking issue
[20:49] <YokoZar> lbt: 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] <lbt> yes
[20:49] <lbt> heck.... you could share gitorious
[20:49] <Stskeeps> yes, the question is how to handle orig.tar.gz .. would they be the maemo source with debian/ stripped? :P
[20:49] <YokoZar> lbt: Are there scripts out there for that already?  Because that sounds really cool
[20:49] <lbt> or setup a gateway
[20:50] <YokoZar> True
[20:50] <lbt> Stskeeps .... implementation..... but handled in master
[20:50] <Stskeeps> (for their native packags)
[20:50] <lbt> and probably stripped to master-debian
[20:50] <lbt> and maybe branched from there
[20:50] <lbt> or forked
[20:51] <lbt> make sense?
[20:51] <YokoZar> Yeah
[20:51] <lbt> OK... does that handle stacking?
[20:51] <lbt> I worry about patches being patched
[20:51] <lbt> I do this
[20:51] <lbt> it hurts
[20:52] <Stskeeps> okay, so, what do you mean about sources of information?
[20:52] <Stskeeps> about/with
[20:52] <persia> I think we can avoid the patching-patches issue by restricting Ubuntu delta to debian/changelog
[20:53] <lbt> OK
[20:53] <YokoZar> If git handles the merging of the stacked patches, then whatever git spits out should be handled by quilt I think
[20:53] <persia> Except post-feature-freeze, when we use patching-patches *intentionally* to backport specific targeted bugfixes.
[20:53] <YokoZar> Yeah persia is right there
[20:53] <lbt> OK... I need to learn this....
[20:53] <lbt> I see gtk2.0
[20:53] <lbt> nm... l8r
[20:54] <Stskeeps> l8r meaning that we'll look at it later, i presume, and not that you're leaving ;)
[20:54] <lbt> correct .. sorry
[20:55] <YokoZar> so... "sources of information"
[20:55] <persia> For 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:56] <Stskeeps> the question that keeps bugging me is simple: we're going to have really interesting times with maemo gtk vs no maemo gtk
[20:56] <YokoZar> I'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] <Stskeeps> YokoZar: we have our wiki, irc channel, and we microblog to mer-chatter mailing list
[20:57] <Stskeeps> microblogging when we move on something and people recieve in digests
[20:57] <Jaffa> persia: Roadmaps/blueprints/use-cases for karmic vs. Mer would be an obvious one
[20:57] <persia> Stskeeps, 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] <Stskeeps> persia: you have other flavors? maemo gtk is sometimes considered an abdomination by some :)
[20:58] <lbt> yeah ... the maemo-ised 'upstream' packages tend to freeze
[20:58] <persia> Jaffa, 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:59] <lbt> On the Mer side everything should be reachable from http://wiki.maemo.org/Mer/   .... is there a similar UbuntuMID root?
[20:59] <Jaffa> persiia: I suppose I mean how strategic is UMID in karmic? Or is working in Mer and reshipping it going to be "OK"?
[20:59] <Jaffa> lbt: http://wiki.maemo.org/Mer is the canonical URL, btw. But I put in a redirect on "Mer/", IIRC
[20:59] <ian_brasil> https://wiki.ubuntu.com/MobileAndEmbedded maybe
[21:00] <YokoZar> Jaffa: We like to avoid use of the adjective canonical to avoid confusion ;)
[21:00] <lbt> (oops ... paste-o)
[21:00] <NCommander> YokoZar, rofl :-)
[21:00] <persia> Jaffa, 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] <Jaffa> persia: fair enough
[21:00] <Jaffa> YokoZar: point taken ;-)
[21:01] <lbt> clarification.... do you intend to
[21:01] <persia> ian_brasil, I should take that URL down at some point :)
[21:01] <lbt> apply all the Mer patches to Ubuntu,
[21:01] <lbt> or take Mer code and patch it
[21:01] <Stskeeps>  / branding?
[21:01] <persia> lbt, apply all the Mer patches to Ubuntu
[21:02] <persia> Stskeeps, 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] <Stskeeps> fair, themes
[21:02] <Stskeeps> err, fairly, - themes
[21:02] <Stskeeps> we don't brand beyond themes so
[21:02] <persia> lbt, 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_brasil> it should be quite easy to apply themes from what i have seen
[21:03] <lbt> I'm worried about us not keeping up with newer versions than Maemo
[21:04] <persia> Stskeeps, 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-s> how do you plan to work with subsystems that are not present in ubuntu and AFAIK have no non-nokia backends
[21:04] <k-s> like the battery subsystem
[21:04] <Stskeeps> mce;dsme we have; battery is hal
[21:05] <k-s> mce/dsme supports non nokia tablets?
[21:05] <YokoZar> By 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] <Jaffa> lbt: post fremantle release, rate of change upstream in Maemo should slow down (from Nokia, anyway)
[21:05] <lbt> that is my concern....
[21:05] <lbt> so Ubuntu gtk will progress
[21:05] <Stskeeps> k-s: powerlaunch yeah; dsme does non nokia hw with some changes
[21:05] <lbt> and we will slow
[21:05] <Jaffa> lbt: ah, I see
[21:06] <lbt> and then dependency hell bites
[21:06] <Stskeeps> persia: atm maemo gtk is at 0.14 but 0.16 is in progress
[21:06] <ian_brasil> YokoZar: i would like to build a web interface for that :)
[21:06] <lbt> and those patch sets are not small
[21:06] <persia> Stskeeps, 2.16?
[21:07] <Stskeeps> er, yeah
[21:07] <Stskeeps> on n810 atm so
[21:07] <k-s> Stskeeps: is bme dead in favor of HAL (which is also dead...)?
[21:08] <Stskeeps> k-s: no, but this doesnt relate much to ubuntu. we had meeting with nokia on hw support this weekend
[21:08] <Stskeeps> with good results
[21:08] <k-s> good
[21:08] <persia> lbt, I think we'll just have to carry/port patches anyway, especially if Nokia's Maemo updates slow post fremantle.
[21:09] <k-s> I'm asking just because hildonized/maemo/mer apps will try to use these systems and will not find them if they are not there
[21:09] <lbt> persia: I suggested to Nokia that we become 'upstream' for their hildon...
[21:09] <lbt> they may be able to help us port forward
[21:09] <lbt> so that the next release is easier
[21:09] <persia> That works.
[21:10] <qwerty12_N800> k-s: apps using libosso to listen to battery low events, etc?
[21:10] <lbt> 'suggested'
[21:10] <k-s> qwerty12_N800: yes, or directly talking to bme et al
[21:10] <persia> lbt, So Mer would end up generating tarballs, which Maemo or Ubuntu could use as a basis for packages?
[21:10] <Stskeeps> k-s, we plan to support mce etc in a cross platform manner
[21:10] <lbt> yes
[21:10] <persia> I like that plan.  Very sustainable.
[21:11] <lbt> and they want to open their development
[21:11] <lbt> cf Trolltech/Qt
[21:11] <lbt> on gitorious
[21:11] <k-s> qwerty12_N800: not that I like bme/mce/... they're mostly NIH stuff
[21:11] <lbt> so internally they point and say "like that"
[21:11] <qwerty12_N800> k-s: mmm, same
[21:11] <Stskeeps> noone speaks directly to bme-but thats a discussion for later.
[21:12] <k-s> Stskeeps: i'd not assume that, Canola for example do that (but we have plugin to talk to hal as well)
[21:12] <Stskeeps> another place to look  for bme info; nice
[21:13] <k-s> just looked at canola sources, we use icd (networking) as well
[21:14] <Stskeeps> dbus wrapper, also taken care of
[21:14] <k-s> good
[21:15] <Stskeeps> YokoZar: yeah, sounds like a good idea (branding package)
[21:15] <YokoZar> Stskeeps: 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:16] <lbt> YokoZar: are you going to do that in Mer?
[21:16] <ian_brasil> YokoZar: that sounds nice
[21:16]  * lbt wasn't paying attention
[21:17] <lbt> anyhow.... 2) Implementation outline  ??
[21:17] <lbt> was that 2.1 done?
[21:17] <YokoZar> lbt: 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 package
[21:18] <persia> I'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] <lbt> yeah.... so I'm not aware we have multi-branding code atm
[21:19] <lbt> maybe this is a task?
[21:19] <persia> Yeah, a task sounds good.
[21:19] <Stskeeps> i 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 ubuntu
[21:19] <Stskeeps> which should give a hint of how much should go upstream ubuntu or whatever
[21:20] <YokoZar> Good point St
[21:20] <YokoZar> Stskeeps
[21:21] <lbt> OBS root  is  https://build.opensuse.org/project/show?project=Maemo%3AMer
[21:21] <Stskeeps> (apologies for the novell login, they're doing openid too. :P)
[21:22] <Stskeeps> and the interesting parts are in :Devel:Base, :UI, :MaemoCommon, etc
[21:24] <lbt> I am putting together a table that will describe each package's functionality, summarise Mer-isation and link to key places
[21:24] <persia> lbt, That would be great!
[21:24] <Stskeeps> we have spent some time making diffs in Maemo:Mer:Devel:MaemoCommon , so we can see what the Mer-specific package changes are
[21:24] <lbt> it'll appear on the wiki in the re-written Mer/Build area
[21:25] <lbt> anything else on this ....? or 2.2) Review of Mer cycles against Karmic schedule to define milestones   ???
[21:27] <persia> https://wiki.ubuntu.com/KarmicReleaseSchedule
[21:28] <persia> http://wiki.maemo.org/Mer/Sprints has the past: I don't know where to find the future.
[21:28] <lbt> http://wiki.maemo.org/Mer/Releases
[21:28] <Stskeeps> yeah, we were discussing the future this weekend, just haven't been put online just yet. biggest hurdle atm: ui quirks, cross-platform consistent behaviour
[21:29] <Stskeeps> and associated applications to make it a full desktop
[21:29] <persia> Sprint ending 15 June matches well to preparation for Alpha 3 on 23 June.
[21:29] <Stskeeps> http://bsd.tspre.org/~stskeeps/DSC00331.JPG is somewhat spec for 1.0
[21:29] <Stskeeps> (.. whiteboard picture)
[21:29] <persia> Next interesting dates for Ubuntu are 13th August (Alpha 4) and 27th August (FeatureFreeze).  I'm not sure how those should align.
[21:30] <lbt> and I have a higher res piccy to clear up arguments
[21:30] <persia> Err.  Oops.  There's space for one more sprint between the current one and Alpha 3
[21:30] <Stskeeps> maybe we should talk about what you'd like to have in your karmic MID.
[21:30] <Stskeeps> stable desktop is reachable - ui and such, and some apps and such
[21:30] <persia> Stskeeps, That's simple: something that doesn't crash when one runs cat.
[21:30] <lbt> Stskeeps I'm also writing that whiteboard up
[21:31] <lbt> Frankly Mer is stable
[21:31] <Stskeeps> mer is stable with some quirks.
[21:31] <lbt> it's just not that useful
[21:31] <persia> lbt, Why isn't it useful?
[21:31] <lbt> applications by default
[21:31] <Stskeeps> not many of the useful extras just yet :)
[21:31] <Stskeeps> we do have entire ubuntu so it helps
[21:31] <lbt> and stability/functionality of them
[21:31] <lbt> and prettiness (missing translations)
[21:31] <Stskeeps> ah, yes, translations
[21:32] <lbt> but it's not *bad* at crashing at all
[21:32] <Stskeeps> our quirks are GTK quirks really and some theme things
[21:32] <lbt> we also have gpe
[21:32] <persia> So, 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] <persia> Rather, desired package list.
[21:32] <lbt> sure
[21:32] <persia> We'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:33] <lbt> but on small screen with fingers, not a mouse
[21:33] <Stskeeps> browser: 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 interesting
[21:33] <lbt> gpe-cal is working
[21:34] <lbt> so is gpe-contacts and file mgr
[21:34] <lbt> xchat too
[21:34] <lbt> we have no cron
[21:34]  * ian_brasil +1 canola
[21:34] <Stskeeps> yeah.. alarm wakeups are interesting at the moment but it'll be better
[21:34] <lbt> meh... it'll never catch on
[21:34] <lbt> ;)
[21:34] <persia> Well, 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:35] <lbt> that may not be good for powersaving
[21:35] <persia> We have a hildonised alarm clock, but it's a bit buggy.
[21:35] <Stskeeps> lbt, which is where mer may differentiate a bit
[21:35] <Stskeeps> since we can wreck more in our own variant of ubuntu
[21:35] <NCommander> persia, Stskeeps we have fbreader
[21:35] <persia> lbt, 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:36] <lbt> see here for things we almost have : https://build.opensuse.org/project/show?project=Maemo%3AMer%3AExtras%3ADevel
[21:36] <lbt> overview : https://build.opensuse.org/project/monitor?project=Maemo%3AMer%3AExtras%3ADevel
[21:36] <Stskeeps> noone 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 discussion
[21:37] <Stskeeps> (regarding alarm wakeups and so on)
[21:37] <Stskeeps> in mer (dist) we'd have alarmd instead of cron, no log files, etc for instance :P
[21:38] <Stskeeps> but we would like to have same application API across the board (hildon, etc)
[21:38] <persia> Right.  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:39] <lbt> :Apps may be Mer (dist)
[21:39] <Stskeeps> our hope is that we can take the same app and ideally compile it towards Maemo(Fremantle), Mer(dist), Ubuntu MID
[21:39] <persia> From my biased viewpoint, I'll hope you won't need Mer(dist) in the future, but that's separable :)
[21:39] <Stskeeps> we'll see where we end up, i can sometimes in my darkest dreams hope Mer would be Maemo6 eventually, but hey ;)
[21:39] <lbt> I was thinking about Mer (dist) being a default install
[21:40] <lbt> indeed... Mer is what you get when you install Harmattan+n and only get the open SW
[21:40] <persia> Anyway, I think we're drifting again.
[21:40] <lbt> s/is/should/
[21:40] <lbt> we are
[21:41] <persia> So, cycle dates.
[21:41] <lbt> I'll do a list of apps
[21:41] <lbt> and allow us to track them
[21:41] <persia> This Mer cycle ends soon.
[21:41] <Stskeeps> reasonably we'll have some more apps and some work, and stable fremantle beta1 packages
[21:41] <persia> I think Next Mer cycle would do well to try to end ~ 16th July to give time to push everything for Ubuntu Alpha 3.
[21:42] <YokoZar> Yes, 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 process
[21:42] <Stskeeps> yeah, we had some discussions on that at the meeting :)
[21:42] <persia> cycle+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] <persia> s/31/13/
[21:43] <persia> Alternately, perhaps have a testing release around the 13th, and the cycle end around the 20th.
[21:43] <Stskeeps> let me just see the sprint calendar, sec
[21:43] <persia> After that, we'll diverge, and Ubuntu will only be able to accept backported bugfixes except in very special cases.
[21:44] <Stskeeps> right, 13th july would be our release date
[21:44] <Stskeeps> of 0.15
[21:44] <persia> OK.  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:45] <Stskeeps> if we work together to clean up packages, minor GTK fixes and such, we should be able to get a decent result in
[21:45] <persia> We can pull the polish for 0.16 post FF.
[21:45] <lbt> persia: I'd expect those 2 weeks to be polishing 0.15
[21:45] <persia> Err, 0.17
[21:45] <Stskeeps> i'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:46] <Stskeeps> so that should be one of the first priorities as well
[21:46] <persia> Hrm?  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] <lbt> seconded
[21:46] <Stskeeps> persia: yeah, 15th june
[21:46] <persia> Rght.  So 0.17 will be what ends up in 9.10.
[21:46] <Stskeeps> keep in mind that this is dist release. individual packages may reach stable releases quite often
[21:47] <persia> Unless the goals for 0.18 can be bugfixes (no new features), in which case we can probably pull that
[21:47] <Stskeeps> *nod*
[21:48] <Stskeeps> so it looks like we sync pretty nicely
[21:48] <persia> I 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] <Stskeeps> 0.14 i think
[21:48] <persia> OK.  Let me try this again.
[21:49] <persia> 0.14 should release RSN, and will probably roughly match the initial uploads to Ubuntu.
[21:49] <persia> 0.15 should release in July, and ought to be the basis of the Alpha 3 images.
[21:49] <persia> 0.16 should release in August, and ought to roughly match the Alpha 4 images.
[21:50] <persia> 0.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.10
[21:50] <Stskeeps> sounds good to me
[21:50] <persia> If 0.18 (releasing in September) focuses on bugwork, and doesn't include new features, we can probably pull it entire.
[21:51] <persia> If there are new features, we'll have to backport the bugfixes, which is more work for all of us.
[21:51] <lbt> ah... pushing 0.17:Testing pre-FF then? OK
[21:51] <lbt> and it will make sense by then to have a bugfix cycle I'm sure!
[21:51] <persia> 0.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:52] <persia> lbt, Right.  Bit of scheduling coordination needed, but I think we can do it.
[21:52] <Stskeeps> we're not tightly locked to months, we change once in a while, so if need be, we adjust
[21:52] <persia> Then, 0.20 should release in November, and we can pull that as the first import of Ubuntu 10.04.
[21:52] <GrueMaster> That actually sounds like a great cycle.  Odd, Experimental, Even Stable.

[21:53] <YokoZar> ?
[21:53] <YokoZar> lbt: were you concerned by that?
[21:53] <lbt> not really :)
[21:53] <lbt> amusedf
[21:54] <lbt> old kernel numbering ....
[21:55] <GrueMaster> Actually, 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] <lbt> persia... are you going to update the schedule as per comments
[21:56] <lbt> I'll do the Mer sprints page
[21:56] <lbt> and crosslink
[21:56] <persia> lbt, I don't think the Ubuntu Release Team cares what schedule we use, but I'll update the spec to detail the correspondance.
[21:57] <Stskeeps> ok, so where are we in outline?
[21:57] <lbt> OK
[21:57] <YokoZar> Stskeeps: we're at testing now I believe
[21:57] <lbt> 2.3) Image creation
[21:57] <persia> Right.  So, we've this big complex environment to create images.
[21:57] <persia> It's easy for us to create .isos for i386.
[21:58] <persia> It'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] <persia> So, 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:59] <Stskeeps> might work
[21:59] <lbt> can we auto-extract?
[21:59] <persia> Saves thought, and probably scales better to the wide variety of armel devices that need kernels not included in Ubuntu.
[21:59] <lbt> should be easy enough
[22:00] <persia> lbt, 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] <lbt> OK, shall we leave that as an Ubuntu problem then?
[22:01] <lbt> I'll note as an issue
[22:01] <persia> Sure.  Just something to be aware of for the future.
[22:01] <persia> I suspect that users will probably cross-post bugs and support requests, etc.
[22:01] <lbt> do you have a target list of machines?
[22:02] <lbt> like we have N8x0, Freerunner, SmartQ etc
[22:02] <lbt> auto-extract doesn't have to happen on the server
[22:03] <persia> Theoretically, 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] <Stskeeps> k
[22:03] <persia> For Karmic everything is compiled for ARMv6+vfp, so the freerunner won't work.
[22:04] <Stskeeps> yeah, it already doesnt
[22:04] <persia> Anyway, if nobody objects to my suggestion about images, let's do it that way and move on.
[22:04] <Stskeeps> k
[22:04] <lbt> and again for testing does it make sense to pick a few targets to understand their needs
[22:05] <lbt> anyhow... we'll get to that I guess
[22:05] <persia> Sure, although we've the kernel issues, which makes it tricky.
[22:05] <persia> I think I'd rather focus on application and environment testing for now.  We can get into the deep stuff once that's working.
[22:06] <YokoZar> Agreed (hardware wise, I'll be doing testing on the two pandoras I've ordered)
[22:06] <lbt> I don't think Meirziki is around
[22:07] <GrueMaster> I also plan on ordering a Pandora, as soon as I get my replacement credit cards.
[22:07] <Stskeeps> regarding devel and testing we will have 0 smartq5/7 rebates too
[22:07] <lbt> that many?
[22:08] <Stskeeps> er
[22:08] <Stskeeps> 10
[22:08] <persia> I've an i386 MID which I can use for testing.
[22:08] <lbt> GrueMaster: are you going to put up a target list of 'tested' hardware?
[22:08] <Stskeeps> ubuntu mid developers will fit under this too
[22:08] <lbt> and are we going to pool test resources?
[22:08] <lbt> we'll test yours if you test ours
[22:08] <GrueMaster> I only have limited hardware to test with, but I can.
[22:09] <persia> lbt, Depends on how much testing you want for 0.20.  If you're happy to pool, we certainly are.
[22:09] <persia> Err, 0.19 :)
[22:09] <lbt> I think we need to start testing early unless you're up to speed
[22:09] <lbt> we're not!
[22:10] <lbt> do you have test processes for Ubuntu that work for MID ?
[22:10] <GrueMaster> Some, but not much at the moment.
[22:10] <persia> That comes to 3.2: we need some test plans.
[22:11] <lbt> OK... should you/we aim to start testing Mer 0.15 ?
[22:11] <persia> I think we have some for installation, but nothing for any applications.
[22:11] <GrueMaster> It really depends on the application.  If it supports ATK, we can automate.
[22:11] <persia> 0.15 / Alpha3 sounds like a good place to start integrated testing.
[22:12] <Stskeeps> agreed
[22:13] <persia> But we'll need test plans beforehand.  Anyone up for writing some?
[22:13] <lbt> hmm I was going to say : GrueMaster are you the guy who's going to write the plans....
[22:13] <lbt> ;)
[22:14] <GrueMaster> I 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] <Stskeeps> well its hard when not knowing what intended collection of components would be
[22:14] <lbt> OK... atm are we focusing on app plans?
[22:14] <GrueMaster> More like basic functionality.
[22:14] <Stskeeps> GrueMaster: was johnx presentingÂ:)
[22:14] <persia> lbt, Do you think we should focus on something else?
[22:14] <lbt> and things like desktop/menu/statusbar
[22:14] <GrueMaster> Might have been.  I can't remember.
[22:15] <lbt> well, we have limited resource... the foundations should be stable
[22:15] <lbt> we need to focus on the areas we touch most
[22:15] <lbt> like keyboard integration things
[22:17] <Stskeeps> we will definately know more when hildon desktop runs in mid
[22:17] <lbt> on the Mer side we have Merziki... but I really don't feel comfortable knowing how much time he has
[22:17] <persia> lbt, 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:18] <lbt> are you also interested in Mer/Ubuntu integration testing (whatever that means)
[22:18] <lbt> hmm
[22:18] <lbt> like package mgr
[22:19] <lbt> that's an interesting one :)
[22:20] <GrueMaster> That would be part of the testing.  Make sure the default apps sit well with the UI.
[22:20] <lbt> actually our application manager is a bit special AFAIK
[22:20] <persia> lbt, Indeed.  I know we have a hildonised update-manager, but I'm not sure we have a good package management UI.
[22:20] <lbt> Stskeeps will it even work on a normal repo?
[22:21] <Stskeeps> yeah
[22:21] <lbt> and the categories etc
[22:21] <lbt> and what apps it shows?
[22:21] <Stskeeps> hackable
[22:21] <lbt> it is very cut down
[22:21] <lbt> OK
[22:23] <lbt> so that's just an Ubuntu task then... hack the appmgr...
[22:23] <lbt> It feels a little like we've stalled on 3) Testing Review
[22:24] <lbt> do we defer to next time?
[22:24] <lbt> or will someone volunteer to have some testing answers by then?
[22:24] <GrueMaster> Sorry, 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:25] <persia> I think we can safely defer: I believe we've covered most of the essentials, and at least know what needs doing.
[22:25] <lbt> well, if you want to volunteer GrueMaster then I can help... and maybe talk to MZ too
[22:26] <GrueMaster> That'll work.
[22:26] <persia> The 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:27] <GrueMaster> I think plars has that angle.
[22:28] <lbt> OK... I have a list of some actions and issues I can cut'n'paste...
[22:28] <persia> OK.  Anyone have anything else we *need* to cover?  I think it's getting quite late in Denmark :)
[22:28] <persia> lbt, Please do.
[22:28] <lbt> ISSUE: version tracking. Eg Maemo/hildon gtk will freeze
[22:28] <lbt> ISSUE: How should Ubuntu best produce images (eg ISOs are easy but may need rootfs or extractor script)
[22:28] <lbt> ACTION: Support/provide release commits like this : http://www.winehq.org/announce/1.1.22
[22:28] <lbt> ACTION: Review objectves of Mer->Ubuntu upload and determine timing (:Testing2 or just :Stable) with persia
[22:28] <lbt> ACTION: Produce workflow to be quilt and git-branch based
[22:28] <lbt> ACTION: Contact Nokia re making Mer upstream for open development of Gtk (via gitorious cf Trolltech/Qt)
[22:29] <lbt> ACTION: Page listing apps for featureful release and status/links
[22:29] <lbt> ACTION: Update Mer Sprints page to show schedule sync and crosslink to KarmicReleaseSchedule
[22:29] <lbt> ACTION: GrueMaster to put up a target list of 'tested' hardware
[22:29] <lbt> TASK : Ubuntu code needs to poke /usr/share/branding/(some to be defined hierarchy standard) then filled with a branding-ubuntu package
[22:29] <lbt> TASK : Ubuntu taskto hack the appmgr to work as needed
[22:30] <lbt> nb... the tasks are mine for Mer unless there's a name
[22:30] <lbt> s/tasks/actions/
[22:31] <persia> branding is probably YokoZar
[22:31] <YokoZar> Yes
[22:31] <persia> I'm happy to help with the package manager.
[22:31] <Stskeeps> also work out workflow, git, packaging, mid people access to mer trees etc
[22:32] <lbt> Stskeeps that's already on my sprint page
[22:32] <Stskeeps> k
[22:32] <lbt> (apart from mid people access)
[22:32] <lbt> I'll add that
[22:32] <NCommander> I'll also help w/ package managerment
[22:32] <NCommander> Wait, did we cover how we want to handle uploads into Ubuntu itself? To my knowledge, no one in Mer is MOTU
[22:33] <NCommander> or, wait, nm, I see it
[22:33] <persia> Right.  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:34] <YokoZar> I'm MOTU ;)
[22:34] <Stskeeps> yep
[22:34] <lbt> actually we have an action to talk to persia about becoming devs
[22:35] <Stskeeps> we will see if its even needed i guess
[22:35] <persia> Stskeeps, 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:36] <lbt> yeah, I suspect the workflow will be pull but people may well have 2 hats :)
[22:37] <Stskeeps> k
[22:37] <lbt> schedule timing for next meeting ?
[22:37] <lbt> whilst people digest
[22:38] <persia> Well, do we need another big comprehensive meeting soon?
[22:39] <lbt> well.... I'm more thinking that we may need nagging
[22:39] <persia> Personally, I'd rather chase the open TASKS, with discussion here, in #mer, on ubuntu-mobile@ and with mer-chatter@
[22:39] <Stskeeps> one on ones maybe; lbt and someone on workflow and packaging
[22:40] <persia> If we bog down, we can schedule something.  Otherwise, I think we're in good shape for three weeks or so.
[22:40] <persia> Stskeeps, Absolutely: I suspect we'll need a bunch of those.
[22:40] <lbt> ok 3 weeks then... how does that fit to release cycle?
[22:40] <lbt> Stskeeps?
[22:41] <NCommander> persia, commit rights to Mer's git trees?
[22:41] <Stskeeps> NCommander: easily
[22:41] <lbt> NCommander: help me figure out the workflow and you're there...
[22:41] <Stskeeps> we are open so
[22:41] <persia> NCommander, for those that are doing enough that it becomes easier to grant commit than to review, why not?  Same for uploads to Ubuntu.
[22:42] <NCommander> persia, 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:43] <persia> I thought we were doing separate branches for packaging, but I could be mistaken.
[22:43] <lbt> NCommander: I'm working on that...
[22:43] <lbt> I would like to do branches for packaging and patches
[22:43] <NCommander> Well, LP is getting the ability this(?) or next week to do git imports
[22:43] <persia> That'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:44] <lbt> yes
[22:44] <lbt> NCommander: do you have opinions?
[22:44] <lbt> if so then I'll work with you
[22:45] <NCommander> lbt, I can think of a few good ways we could do this.
[22:45] <lbt> OK... you're named in my action ;)
[22:46] <NCommander> woo!
[22:49] <Stskeeps> k, anything else im needed for? else im off to bed
[22:49] <persia> YokoZar, Are we done?
[22:49] <YokoZar> I believe so
[22:49] <lbt> 23rd June?
[22:49] <YokoZar> Someone should log this
[22:49] <YokoZar> and save it somewhere
[22:49] <YokoZar> (especially the action items)
[22:50] <GrueMaster> I've got logging enabled.  Let me know where to post.
[22:50] <YokoZar> your wiki I guess
[22:50] <persia> I think it's already logged.
[22:50] <lbt> The action items will go on the Mer wiki somewhere
[22:50]  * persia double-checks
[22:50] <persia> http://irclogs.ubuntu.com/2009/06/02/%23ubuntu-mobile.html
[22:51] <Stskeeps> bbl, thanks for the meeting, gf wants me to sleep nowÂ:P
[22:51] <GrueMaster> good enough.
[22:51] <lbt> night Stskeeps
[22:56] <YokoZar> Cheers, thank you everyone
[22:58] <lbt> yep... g'night all and thanks


[05:42] <ubuntu-studio> Hi, can someone answer a couple of questions about partitioning in ubuntu installer?
[05:44] <CarlFK> ubuntu-studio: best to just ask
[05:45] <CarlFK> I am headed off soon, so if i don't respond, that's why.
[05:46] <ubuntu-studio> I have computer already dual booting win7/mint, and want to replace mint. Do I have to choose the manual partition option, and where do I change the bootloader to stay dual boot?
[05:49] <ubuntu-studio> I don't plan to make any other changes to partitions. Currently have a windows 7 partition, recovery, mint, and swap partitions.
[05:50] <CarlFK> yes, and the installer will detect the windows partition and offer to add it to the grub boot menu
[05:51] <ubuntu-studio> So I pick manual partition, select mint partition and make it /, and format it. Then the installer will offer the option after to make it dual boot?
[05:51] <CarlFK> yep
[05:52] <ubuntu-studio> Ok, thank you.


[12:35] <moosebag> hi there. Please can anyone suggest why I can get Audacity to record my SB0100's line input, but I can't get this input into Jack?
[13:16] <moosebag> some days i wish i'd never abandoned microsoft products
[13:38] <zequence> You're probably using alsa or pulseaudio with audacity
[13:38] <zequence> moosebag: If Audacity works with your sound card, you are doing something wrong with jack
[13:38] <zequence> moosebag: How have you determined that jack does not work?
[13:39] <zequence> moosebag: Which application are you trying to use with it?
[13:52] <moosebag> hi again zequence. yes it could well all be my own stupidity :) IIRC, I should select Line In as a record source, and it should appear at the "capture" stereo pair on the left hand side of Jack's patchbay. Am I wrong?
[13:53] <zequence> moosebag: I thought you said you saw two capture ports in your jack connections?
[13:53] <moosebag> yes, that's the stereo pair of capture sources
[13:53] <zequence> So, what are you connecting those to?
[13:53] <moosebag> All I want to achieve is to get Line In audio registering on a meterbridge window
[13:54] <moosebag> then i know it will be available for Ardour
[13:54] <moosebag> I've tried connecting the capture port pair to meterbridge, no luck so far.
[13:54] <zequence> Let me try meterbridge
[13:54] <moosebag> thankyou
[13:55] <zequence> moosebag: I would just try  ardour though.
[13:55] <moosebag> and a SB0100 if you have one! :)
[13:55] <moosebag> Ardour was recording the mic input, but I want it to record Line In because I don't want an unnecessary gain stage in the audio chain.
[13:57] <moosebag> thanks for your interest; I'm at work so forgive any delays replying :)
[13:59] <zequence> moosebag: meterbridge works, but it doesn't move easily for me (the VU mode).
[13:59] <zequence> moosebag: I need a very high input volume for that
[14:00] <moosebag> oh! are you sure it's not crosstalk getting through? Meterbridge can be (used to be) invoked by command line to give different meter types, maybe there's a more sensitive one? PPM for example...
[14:01] <zequence> moosebag: I connected the pulseaudio jack sink to it, and put a youtube video on with maximum volume
[14:01] <moosebag> ok thanks
[14:01] <zequence> The vu meter would only go to half
[14:01] <moosebag> hmmmm. what soundcard do you have?
[14:02] <zequence> I wasn't using a sound card at all right now
[14:02] <zequence> Just pulseaudio connected to jack, and from there to the vu
[14:02] <moosebag> oh ok. hmm
[14:02] <zequence> When you make pulseaudio use jack as the output, it becomes a jack client
[14:03] <moosebag> ok. well i struggle to understand how alsa and/or pulseaudio are supposed to interact with Jack
[14:03] <zequence> !proaudio
[14:03] <zequence> pulseaudio uses alsa, as does jack
[14:03] <zequence> the drivers are actually alsa drivers
[14:03] <moosebag> ah the plot thickens!
[14:04] <moosebag> ok well i'll keep trying things when I get home, maybe see you here again, in any case I'll write up what eventually works. thanks all
[14:04] <zequence> jack presents the card more as it is, the chip itself
[14:05] <moosebag> ok let's hope so. haven't tried the jack sink/source stuff yet, that's new to me since I last used Jack
[14:06] <zequence> pulseaudio creates inputs and outputs as stereo pair, 5.1, etc. These are also represented in the alsa card interface instructions, but jack doesn't worry about those
[14:06] <zequence> jack only shows the channels as they are, from 1-?
[14:06] <moosebag> ok, interesting.
[14:07] <zequence> The likelihood for pulseaudio working, but not jack is very slim
[14:07] <zequence> Since they basically use the same drivers, where pulseaudio is the one that does more advanced things and where things can go wrong
[14:08] <moosebag> thanks. so do you think I need to do anything with a separate mixer app to configure my SB0100, or does Jack even take care of that?
[14:09] <zequence> moosebag: jack doesn't handle leveling or any other hw controls at all
[14:10] <zequence> moosebag: you use alsa mixers for that
[14:10] <zequence> moosebag: you can try the command line tool alsamixer
[14:11] <moosebag> ok, thought so. Right, so I still need to find where the line input signal is appearing in Jack, then try for a level in Ardour, assuming that meterbridge is a bit deaf!
[14:11] <zequence> moosebag: It will show you all controls that exist for that card
[14:11] <moosebag> yes, been there a lot.
[14:12] <moosebag> do you think the AC97 controls need setting for this purpose?
[14:13] <zequence> moosebag: Sure you are not setting levels for you integrated card now?
[14:13] <zequence> moosebag: You choose the card with the F6 key
[14:14] <zequence> I wouldn't worry about it, anyway
[14:15] <moosebag> i don't think there 's any onboard sound system, but good point. one of the supplied mixer apps thought I was dealing with a totally different chip. The SB uses the Emu 10K1 or something like that. And cheers for the F6 suggestion.
[14:33] <moosebag> when I crack this problem, expect massive credits on the next album :)
[15:30] <moosebag> thanks again and bye, keep up the great work
[16:59] <Guest95969> I am using Ubuntu Studio on my desktop.  I have a Sony Xperia SP.  I want to backup the information onto the desktop so I can do a factory reset on my Xperia without losing data.
[16:59] <Guest95969> How do I do that?


[14:00] <mamarley> ricotz: I have fixed the bug the guy reported with the "modeprobe" typo.  Since it is such a simple change and since my staging PPA already contains the drivers I modified for EGL support, I am going to upload these straight to the main PPA.
[14:18] <jcastro> mamarley: ok, I added a warning on top
[14:18] <jcastro> are you on 358 or 355?
[14:18] <mamarley> jcastro: I am running 358.  Did the Valve guy say what the problem was?
[14:18] <jcastro> he just said it caused crashes in the steam client
[14:19] <mamarley> Hmm, OK.
[14:19] <jcastro> but I am not sure if they got that from the client reporting home, or their own internal testing, or what.
[15:16] <ricotz> mamarley, alright


[06:42] <knightwise> morning peepz
[07:38] <brobostigon> morning boys and girls.
[12:36] <mgdm> afternoon
[12:38] <penguin42> and a warm sunny afternoon it is
[13:00] <knightwise> on the edge of a thunderstorm here in  .be
[13:00] <diddledan> yey
[13:00] <diddledan> thunder and lightning
[13:01] <knightwise> very very frightening
[13:01] <diddledan> very very
[13:01] <diddledan> pretty
[13:09] <mgdm> http://en.blitzortung.org/live_lightning_maps.php?map=10 So I see :-)
[14:23] <diddledan> https://t.co/sF4VZwjiP4