#ubuntu-mobile 2007-06-04
<alienseer23> hello, I was looking for a linux flavor to install on my palm TX (or to just find out more info on this concept) when I ran across this here Ubuntu project. Q: is this going to be an Ubuntu flavor that will install onto devices such as my Palm TX???? I really hope so, ad if so, what is the best way I can keep tabs on this project as it develops?
<Mithrandir> alienseer23: it might eventually be, but I don't think we are targetting whatever cpu architecture your palm has as an initial goal.
<lucasr> hi
<lool> Mithrandir: I wonder about the -dbg package name for hildon-thumbnail: shouldn't it use something more generic than libhildon-thumbnail0-dbg, perhaps hildon-thumbnail-dbg?
<Mithrandir> I prefer to change it as little as possible from what upstream uses, but otherwise agreed.
* Starting logfile irclogs/ubuntu-mobile.log
<Mithrandir> agoliveira: you're working on -l10n-mr, right?
<agoliveira> -mr? I saw this -mr package. I was checking out hildon-fm-l10n to see if this package is part of it. Is there a -mr somewhere else?
<agoliveira> Mithrandir: and the actual strings seens to match.
<Mithrandir> hildon-fm-l10n-mr is what I meant
<agoliveira> Mithrandir: Yes, I tought you meant that but I didn't find something named like this on maemo svn so I tought it was the name of one package inside hildon-fm-l10n or hildon-fm-l10n-2.0
<Mithrandir> it's a binary package name, yes.
<agoliveira> Mithrandir: or that someone messed up with the dependency name as the strings seens to match.
<Mithrandir> are you comitting the fixes needed to make -fm-l10n build or should I?
<agoliveira> It will biuld right out of the box but the binary package names do not match the hildon-fm dependency so I'm checking if there is somehting that I missed or if someone just messed with the names as I said before.
<Mithrandir> no, it won't.
<Mithrandir> are you building on gutsy?
<agoliveira> Oh, sorry.
<agoliveira> No, it really won't. I did some changes on friday.
<agoliveira> Mithrandir: Ok, it will compile now but the binary packages does not match the dependency as I said. Give me a few minutes to try to understand what's happening.
<Mithrandir> if you did any changes on Friday, you forgot to push them to the bzr branch.
<Mithrandir> make sure what you have is a checkout and not a separate branch
<agoliveira> Mithrandir: No, the matter was that there was no import on LP so I had to wait it to be imported before branch it.
<Mithrandir> ah, ok.
<agoliveira> It happens late friday so I only had it done today. The branch I creted there now is fresh.
<agoliveira> Mithrandir: I just commited the change so it compiles nicelly now. I'll now figure out what's the deal with the dependency name. I'll just grab a coffee (it's cold in here today :) ).
<Mithrandir> cheers.
<agoliveira> Mithrandir:Found it. It's actually comming from somehting called haf-marketing-release which is a metapackage that agregates all the l10n stuff. Great isn't it?
<Mithrandir> indeed
<Mithrandir> I need to go soonish, but if you can manage to have -fm installable by tomorrow, that'd be excellent.  Please do tell me what stuff you need uploaded, or just update the TODO list with them
<agoliveira> Mithrandir: Don't worry. I believe I can handle it. The only matter is that I'll need to import the rest of the l10n stuff a bit later.
<agoliveira> Mithrandir: as soon this is done, hildon-fm should be ok and we can go for hildon-desktop. Yeay! :)
<Mithrandir> exactly. :-)
<agoliveira> Mithrandir: Going lunch now. Later.
<lucasr> hei
<tko> lucasr: how far did we get with our hildon roadmap? migrate to gnome.org, make a stable release, do something about l10n
<lucasr> tko, someting like this :-)
<tko> no betas or rcs? :)
<lucasr> tko, rcs?
<tko> release candidates
<lucasr> tko, I think the gnome release is good example of how we would organize our releases
<lucasr> tko, so, yes, there will probably be rcs
<lucasr> :-)
<agoliveira> Mithrandir: IIRC, a few days ago you got a bzr push stuck, right? How did you fix it?
<Mithrandir> bzr break-lock
<agoliveira> Nope. No deal :(
<Mithrandir> you need to give it an URL too
<agoliveira> oops :P
<agoliveira> Worked. Thanks.
#ubuntu-mobile 2007-06-05
* Starting logfile irclogs/ubuntu-mobile.log
<Mithrandir> tko: who would be a good person to talk with about hildon and translations?
<Mithrandir> osso-gwcompat should be in now.
<Mithrandir> agoliveira: do you have any idea how much work it'd be to move to the official bluez interfaces?
<agoliveira> Mithrandir: I'ts hard to say as I don't have experience on this but for the looks I would say that won't easy. Bluetooth is quite a messy stuff.
<Mithrandir> hmm
<agoliveira> Mithrandir: and there is some things there, related to proprietary part I guess, that won't make much sense to me but, as I said, I don't have experience with bluez.
<Mithrandir> me neither. :-)
<agoliveira> Mithrandir:This is something needed, no doubt, but we should check with Nokia to see if they have something already in place, maybe even Intel has something but they didn't say anything about it also.
<Mithrandir> nokia seemed to want to transition, but nothing firm yet.
<agoliveira> Mithrandir:BTW, after the small "anouncement" I did yesterday, I was contacted by Bob Sinclair (Intel) asking me if he could already use the packages, if he could help, etc. I didn't say anything yet but I believe he can access LP if he wants grab the sources right?
<Mithrandir> yes, the branches are publically available.
<agoliveira> Fine, I'll tell him that he can jump in from there then.
<Mithrandir> as for helping out, I would prefer if people started by contributing by either sending patches to the mailing list or branching off into their own space on launchpad before we give them commit access
<Mithrandir> I'm happy being easy on the requirements, but just giving it out completely freely is something I would like to avoid.
<agoliveira> Understood.
<agoliveira> And it's Bob Spencer. Bob Sinclair is a musician :)
<Mithrandir> oh, Bob Spencer is a member of the team, I thought
<agoliveira> Yes, he is already.
<daniels> Mithrandir: so, you guys doing anything interesting with x?
<Mithrandir> daniels: not yet at least.
<Mithrandir> we're so far basically just working on getting hildon into ubuntu.
<Mithrandir> fixing all kinds of minor and major stuff, like.. completely wrong debian/copyrights and such
<daniels> Mithrandir: no surprise there.
<daniels> the package quality is ... variable.
<Mithrandir> yes, some bits are quite good, some not so much.
<Mithrandir> you don't happe to know who'd be the right person to chat with about l10n infrastructure?
<daniels> i have no idea, tbh
<daniels> i'd probably have to ask the same people you would
<Mithrandir> ok, I'll just mail maemo-developers and see what comes of it.
<daniels> they don't lurk on m-d; you'd have to talk to nokians directly
<daniels> they're sort of part of the corporate machinery
<Mithrandir> hm, ok.
<Mithrandir> we're open, but not really, and not always, and not all bits.
<agoliveira> Mithrandir: got it now? ;)
<agoliveira> That's *the* single major complain the maemo developpers have.
<Mithrandir> the openness, or lack thereof?
<agoliveira> the lack of it.
* Mithrandir nods
<Mithrandir> in that respect, we have a much better job
<daniels> not a discussion i'm really keen to get into, but yeah, talk to your nokia contacts to find the l10n people.
<agoliveira> indeed
<Mithrandir> s/better/easier/, sorry.
<tko_> Mithrandir, I know something about l10n..
<tko_> Mithrandir, as I mentioned yesterday, our roadmap is something along the lines of 1) migrate to gnome.org, 2) make stable release, 3) fix po
<Mithrandir> ok
<Mithrandir> what's blocking those and how can I/we help?
<Mithrandir> we're basically trying to answer the question whether we can use malone to translate hildon for gutsy or if that's not feasible.
<daniels> hopefully we can move off logical strings soon, too
<tko_> well, migration is currently blocking on accounts, then on svn repositories, then on us penetrating the firewall for commit access.. stable release is just blocking on fixing all bugs :)
<Mithrandir> daniels: logical strings, as in msgid "sfil_li_folder_root"
<Mithrandir> I presume
<tko_> and we can't really touch the l10n during this development cycle
<daniels> Mithrandir: right
<Mithrandir> ok.
<tko_> Mithrandir, if malone could display the en_GB string instead of the logical id, it should be simple to use
<Mithrandir> gutsy is October, so not feasible for then.
<Mithrandir> sorry, not malone, but rather rosetta
<tko_> I was wondering about that...
<Mithrandir> I'm making a mess of all words today.
<Mithrandir> I can ask the rosetta people if that's feasible.
<tko_> but figured you must know better :-P
<daniels> tko_: well, you have irc now, which is an improvement, so surely svn can't be too far off ;)
<Mithrandir> svn-over-irc.
<Mithrandir> :-P
<tko_> daniels, well, I'm abusing jabber irc transport, which is a bad argument as I really shouldn't be running jabber either :-P
<tko_> svn over dns
<Mithrandir> ip-over-dns is working quite well, but I suspect you'll get angry employers that way.
<daniels> Mithrandir: there are ways to bust tunnels out
<Mithrandir> it sounds like rosetta should be able to handle this way of doing translations, so we can use it for gutsy.
<lool> Hmm some bzr branches are in an old format and bzr complains about it
<lool> Working tree format 3 is deprecated and a better format is available.
<lool> e.g. hildon-thumbnail
<Mithrandir> just run bzr upgrade and you should be fine
<Mithrandir> ideally, hildon-thumbnail shouldn't ship the .bzr directory in the tar.gz at all
<lool> Mithrandir: I mean on bazaar.launchpad.net
<lool> At least when I bzr co all branches, only some display the "obsolete format" error
<Mithrandir> hm
<lool> Do you want a list?
<Mithrandir> weird.
<Mithrandir> that's just your working tree.
<Mithrandir> hildon-thumbnail is that way?
<lool> I doubt it's local, otherwise I would get the warning on all checkouts
<lool> BTW, I'm bootstrapping a pkg-maemo on alioth
<lool> And wrote a script to checkout all bzr branches of the ubuntu-mobile team as "/ubuntu"
<Mithrandir> bzr co sftp://bazaar.launchpad.net/~ubuntu-mobile/hildon-thumbnail/ubuntu/ hildon-thumbnail ; cd hildon-thumbnail ; bzr status doesn't make it whine here
<lool> http://paste.debian.net/29679
<lool> Mithrandir: It's with a bzr tarball from upstream installed in my home
<lool> Mithrandir: Ah, it might have been interrupted in a previous run
<haary> What browser will Ubuntu mobile use?
<Mithrandir> haary: custom gecko/xulrunner-based, most likely.
<lool> Mithrandir: Right; I wiped everything, and now it's fixed; sorry for the noise
<Mithrandir> lool: ah, ok.  Good. :-)
<Mithrandir> you had me confused for a bit
<lool> Yeah, I was confused too
<haary> Oh, I thought it would be something based on Gtk Webcore, since gecko is pretty bloated
<lool> Is there some kind of mailing list for tarball releases in maemo?
<tko_> lool, we don't do tarball releases... :-] 
<tko_> lool, we've requested one for hildon on gnome.org but it'll take time
<lool> I'll use http://repository.maemo.org/pool/sardine/main/source/libo/libosso/ as download URL for libosso then
<lool> I can't help but smile as I cross Johan Bilien in the ChangeLog mouarf
<tko_> mmm?
<lool> tko_: We were in the same school and even association
<lool> via.ecp.fr
<lool> http://via.ecp.fr/via/historique/index.html
<tko_> ah
<lool> Hmm the maemo version numbers conflict with the Debian ones
<lool> I wonder whether Debian packages should use -1ubuntu3debian1 now :)
<lool> mdz: Hmm, I think you uploaded mce-dev, but I can't find anything in the ubuntu branch of "mce-dummy"; is this on purpose?
<mdz> lool: I just synced it unmodified from the maemo repository, since it didn't require any changes (it's trivial)
<lool> Ok, thanks
<mdz> I've added it to TODO by way of documentation
<bobux> agoliveira, what time zone are you in?  Is it the same as east coast US?
<agoliveira> bobux: I don't know, what's US timezone? :) Seriously, I'm at gmt -3.
<bobux> I'm pdt, 9:38am now
<bobux> you just back from lunch, so 12:38pm?
<agoliveira> 13:43 actually.
<bobux> I was thinking we were the same but you are working at my 4am
<bobux> good to know. thx
<bobux> I saw your comment above on LP access and am doing that today
<agoliveira> In Brazil it's mostly GMT -3 but some parts are -2 and even -1 IIRC.
<agoliveira> Nice to know :)
<lool> I cleaned mce-dummy a little; would someone be so kind to have a look at the changes, tell me whether they are not too intrusive, and perhaps merge some in the ubuntu branch?  bzr.debian.org/bzr/pkg-maemo/mce-dummy/debian/
<daniels> a diff might be nice, being somewhat easier to review than a bzr branch.
<tko> daniels: you wouldn't mind a git branch though, would you? :)
* lool tried bzr diff on two remote branches just for fnu
<daniels> tko: it would be easier than bzr (given that git lets you clone new repositories with 'old' versions; i couldn't clone postr with edgy's bzr, which sucks horribly), but would still definitely prefer a diff.
<lool> http://people.dooz.org/~lool/debian/mce-dummy-diff.patch
<tko> diff is easier, true.. shouldn't the bzr web thingamagic be able to produce a diff between arbitrary revisions?
<lool> Who should I talk to to get such cleanups in the upstream SVN?
<lool> Individual maintainers?
<tko> lool: bug in bugzilla and individual maintainers I'd say, at least until we get the hildon mailing list running
<tko> lool: IIRC we don't have debhelper 5 yet so that part might become annoying to us if we can't apply the whole patch
<lool> tko: Oh yeah; but not bumping debhelper is going to be a pain for all packages, especially those providing -dbg packages :-/
<lool> tko: Is there a chance to get an updated debhelper
<daniels> yeah, debhelper 5 is an enormous pain, and not solved anytime soon.
<lool> aha
<daniels> lool: no, and you're still stuck with dpkg 1.13.19 in the devkits.
<tko> and as you may have noticed we're not too good at the finer details of packaging either so chances of us tweaking the necessary bits to fit for debhelper 4 are bitty slim
<lool> I wonder whether we should refrain from updating debian/compat in this case
<tko> daniels: fer was saying something that sdk guys were quick to agree on getting debhelper 5 as it's apparently needed for python bindings
<daniels> lool: thanks for the diff.  looks fine, modulo dh5.
<lool> The thing is, debhelper 4 is out of my memories; I don't know what expectations I have which would be broken in v4 mode
<tko> :)
<daniels> tko: ah, nice.  i argued with them about that and dpkg for a while, got nowhere.
<lool> For example, I don't recall whether it's ok to wrap build-deps in DH 4
<tko> daniels: sdk != si
<daniels> lool: no --print-missing (or whatever), --dbg-package semantics reversed (i.e. use --dbg-package=libfoo1 to get libfoo1-dbg)
<daniels> tko: yes, both teams. :)
<lool> daniels: Yeah, that kind of stuff
<lool> Hmm daniels, you said it's unlikely to be very soon, and tko you mentionned is a requirement for python
<tko> I'm still sort of wondering if we could get canonical maintain our build environment and tools and such :)
<lool> Until when can you get debhelper 5, and how to help?
<daniels> tko: if only
<lool> tko: hehe
<daniels> lool: we don't know, and there's nothing you can do to help, sadly
<daniels> dinnertime, bbl
<tko> lool: I meant currently the python packaging requires debhelper 5, we need to either get it, or make it work with v4
<lool> tko: I don't know whether it's for sale, but I suppose it could help Nokia save money on that part of the maintenance
<lool> tko: Python stuff has changed a lot recently; I am not sure what you mean with "python packaging", but restraining your python packages to the old mode of dh_python sounds awful
<tko> I've gone through the pain of downgrading some packaging, so yes, I know
<tko> but still, in cases, if you want something to happen this year...
<lool> tko: Is it discussed internally in Nokia?
<lool> Or are there people one can talk to, to explain that upgrading debhelper should be self thanks to its concept of compat modes?
<tko> lool: not actively that I know of (would require some higher level business decision) individuals complain occasionally but eventually resign
<tko> on debhelper specifically I believe daniels has most recent experience
<lool> Hmm where's mce-dev in SVN?
<lool> I see mce-dummy Provides mce-dev, but it's not the good mce-dev it seems
* lool goes offline this evening &
<tko> lool: it probably isn't in svn (not all teams use stage)
<mdz> lool: I don't think I found it in svn
<mdz> I only noticed it by accident
<mdz> it's essentially a stripped-down version of the proprietary mce package
<agoliveira> Indeed. mce-dev is not there, just mce-dummy because of the dependency IIRC.
<mdz> agoliveira: no, there are three MCE packages
<mdz> mce (the proprietary one), mce-dummy (in svn) and mce-dev (in the archive)
<tko> IIRC mce-dummy is historical because it was needed to satisfy mce dependency, but it was later superseded by the real thing
<mdz> I pulled in the latter
<agoliveira> I meant in the stage svn.
<agoliveira> Weird, I don't recall to have other one.
<agoliveira> not at all.
<happycube> -mtune=pentium seems wrong... the A100 series are pentium-m which is k6
<happycube> *P6/ppro
<tko> hmm, I just realized I'll be in SF at the same time as apple is organizing their conference. I wonder if I could somehow sneak that into my visit and get nokia pay for it :-P
<tfheen> tko: debhelper 4 is acceptable to us if that makes it easier for you guys to merge our changes.
<happycube> ubuntu mid can work on something trackpad-based like the asus eee right?
<happycube> that looks like a *very cheap* laptopized MID
<happycube> also there needs to be provision for not wearing holes in the SSD's that all this gear uses ;)
<tko> tfheen: at the moment it would, but fer was trying to get debhelper updated. hard to say how/when that'll go
#ubuntu-mobile 2007-06-06
<PepperDog> Hi! I'd like to compile a kernel module for Ubuntu Mobile. Can anyone guide me ?
<PepperDog> Anyone compiled a kernel module on Ubuntu ?
<PepperDog> any kernel developers here?
<lool> tko_, mdz: Ack, thanks
<lool> tfheen: So, keeping DH 4 suggests to postpone the "cleanup" spec, or at least to filter heavily the cleanups we allow; what do you think?
<lool> Mithrandir: ^^^
<lool> I suppose we can mail fer who I understand has a clue about whether DH 5 is likely or not
<Mithrandir> well debhelper < 4 is deprecated, debhelper 4 is fine.
<daniels> if dh5 does happen, it's almost certainly not going to be soon enough anyway.
<lool> Mithrandir: We're close to 6 from what I've seen in Debian's DH changelog entries
<lool> daniels: Do you have a time estimate in case there would be some motivation for DH5?  Would it be at least weeks, at least months?
<lool> Plus, there's the question of Python and dbg packages  :-/
<Mithrandir> indeed.
<daniels> lool: months.
<lool> That's a pity; I don't think it makes sense to restrain to DH 4 stuff for months; what do other think?
<Mithrandir> on one hand it would be good to be able to push bits back into maemo, on the other hand it'll be easier for maemo to grab our changes if we make the transitions now
<lool> (I would usually stand in favor of spending time to push things upstream, but I find the DH 4 burden a bit too heavy to carry for months)
<daniels> no-one enjoys carrying it.  i didn't enjoy changing every single x package to use dh4 instead of 5.
<lool> mdz: Was outo also taken verbatim?
<mdz> lool: I believe so, yes
<mdz> daniels: oh, hello
<daniels> mdz: good afternoon
<daniels> (i'm here more or less out of curiousity, rather than official capacity, fwiw.)
<lool> mdz: Added to the wiki; thanks
<tko_> oh, we've been trying to kick outo out.. was it needed somewhere?
<lool> Perhaps someone can check the changes at bzr.debian.org/bzr/pkg-maemo/libosso/debian and merge some for Ubuntu?  There are a couple of upstream things, and not too much Debian specificities; I think you just want to revert the "Do not ship *.la files" change
<lool> tko_: It's in the deps of libosso-test
<mdz> lool: might be a good thing to add to TODO
<tko_> I wonder if libosso-test is up to date
<lool> Is there a wiki page documenting the deprecated modules in the Ubuntu Wiki?
<mdz> lool: deprecated modules?
<lool> The upstream deprecated stuff such as hildon-libs, outo...
<Mithrandir> lool: we don't like .la files either, so we'd be happy to take that.
<Mithrandir> lool: I am planning to make a status page too and merge TODO into that, but I just haven't had time yet.
<lool> mdz: Added the review of the bzr branch to TODO
<lool> Mithrandir: Good for *.la files; the other *.la files might already refer to it though
<lool> tko_: Should I best mail the maintainer to merge upstream changes into maemo (e.g. AM_MAINTAINER_MODE, EXTRA_DIST = debian/*, ...), a maemo list, or ping you?
<tko_> lool, bug + mailing the maintainers would be nice. it depends on the individual how quickly he might react. and the bugs make it easier to track from outside
<lool> Oh right, bugzilla, that was the thing
<lool> Super slow though
<daniels> lool: you've just got to make sure it's assigned to a real developer, rather than to maemo qa.
<lool> daniels: Thanks; I filed a tracker bug, bug #1516, and a libosso bug with an overview of all changes as bug #1517; I hope the maintainer will suggest a nice way to exchange fixes
<daniels> lool: cool, thanks
<daniels> lool: ditching .la files is definitely on the agenda
<daniels> lool: we've already done it with some parts of the distro
<lool> Cool; did you so by stripping dependency_libs?
<lool> This is what I use in gtk+2.0 and similar GNOME packages: sed -i "/dependency_libs/ s/'.*'/''/" debian/$(DEV_PKG)/usr/lib/*.la
<lool> Hmm that's not anchored; bad me
<daniels> er, no, we just did the iterative process of rebuilding from the bottom up, as we did in ubuntu as well.
<lool> The idea is that you can strip dependency_libs in all packages at once, it wont break anything (except static linking), and when that's over, you can remove all *.la files
<lool> So it's a too step approach, but you don't have to start by the leaf libs
<daniels> right
<lool> s/too/two
<lool> Weird, why does libosso have all the autotools generated files in SVN
<lool> 29 modules have a configure out of 43 modules with configure.ac
<tko_> we require that dpkg-buildpackage on svn export works, and people couldn't be bothered to run autogen or similar in debian/rules
<lool> I see; thanks
<Mithrandir> is that a policy decision or would you take patches to run autogen.sh if configure doesn't exist?
<tko_> depends on maintainer
<tko_> it was their decision originally
<Mithrandir> ok
<Mithrandir> and you don't have / want to use sticks to make them adjust to a common policy?
<daniels> Mithrandir: that process is incredibly heavyweight
<Mithrandir> ugh, ok.
<Mithrandir> this is part of why you guys want to move onto gnome.org or is that something else?
<lool> gnome.org does not have many policies either; mostly some release policies TTBOMK
<lool> But at least all GNOME modules do not have autotools files in SVN :)
<Mithrandir> they don't have a policy against generated files in revision control?
<lool> Mithrandir: I'd say nobody would have had this idea just because no other module does os
<lool> so
<daniels> i'm not part of the sardine stuff: i have git repos with no generated files at all in them.  so i'm perhaps not the best person to ask. :)
<lool> Hehe
<Mithrandir> agoliveira_lunch: can you make sure hildon-fm and hildon-fm-l10n are good to upload?  I think they are and would like to get them in today so I was planning on uploading tonight.
<Mithrandir> agoliveira_lunch: also, if you know of anything that needs fixing in hildon-desktop, please fix or tell me so we can get it too in.
<Knowledge> So does this mean that the n770 and N800 might get ubuntu?
<Knowledge> and while I'm at it...should I keep my hx4700?
<happycube> right now i think this is targeted for x86-based ultramobiles
<agoliveira> Mithrandir: hildon-fm* should be fine as well as hildon-desktop itself. Just a warning that it does not have much pratical use so far without hildon-theme-plankton which I'm working on.
<lool> Hmm should osso-af-settings really be Arch: all?
<lool> It ships files in /usr/lib/pkg-config
<lool> bzr.debian.org/bzr/pkg-maemo/hildon-1/debian and bzr.debian.org/bzr/pkg-maemo/osso-af-settings/debian are up for review too; added to the TODO page
<mvo> hi. I'm just adding a lpia architecture to apt, could someone please paste the output of config.guess for a lpia system here?
<horaceli> lool, could you please share with me what GTK+ base are you use right now?
<bspencer> agoliveira  -- want to introduce you to horaceli 
<lool> horaceli: Right now I don't need Gtk
<lool> horaceli: The first modules _I_ have touched until now build with stock Gtk from Debian/Ubuntu
<bspencer> horaceli, what problems are you seeing.  what version of gtk do you have?
<horaceli> wait for a moment, I am searching the build log.
<mdz> bspencer: good morning!
<agoliveira> bspencer: Hi Bob. We are alreayd in touch.
<bspencer> agoliveira, ah, ok.
<mdz> bspencer: good to see you on the channel
<agoliveira> bspencer: I told him already that he needs to use Gutsy repositories.
<agoliveira> mdz: He's being around already ;)
<bspencer> yes, he was building hildon-1 but had conflict with gtk.  
<horaceli> look, I tried to build up hildon-1 today, getting the source from launchpad.net.
<horaceli> and got the error message that HILDON_GTK_INPUT_MODE_NUMERIC is not defined in src/hildon-date-editor.c
<agoliveira> horaceli: I understood that you tried to build it on Feisty, right? The stock gtk there will not work.
<horaceli> hi, agoliveria, this is horace who sent you email yesterday
<horaceli> yes
<agoliveira> Don't you prefer to install Gutsy and grab the packges directly from there? It will be easier.
<horaceli> s/look/lool
<agoliveira> As a matter of fact, I'll take a few CDs with me next week and I'll be glad to prepare an envioroment for the intel guys.
<horaceli> I would like to, just currently our pdk is currently based on Feisty and have no Gusty in my hand right now. :-)
<bspencer> mdz, does henrik omma come around ubuntu-mobile?
<lool> horaceli: Hmm I could build hildon-1 fine here
<lool> I'm on Debian/sid
<agoliveira> horaceli: We are going to change this as all our work is based on Gutsy.
<lool> horaceli: How did you get and build the source, and when did you get it?
<horaceli> agoliveira, that is good. i will try to get Gusty installed on my workstation and have a try tomorrow
<agoliveira> horaceli: As I told you, you can install a Feisty CD and just change the apt sources and update. I sugest you do it in a separate enviromment like chroot or vmware. I prefer vmware actually.
<horaceli> lool, check out the source by bazaar from launchpad.net, 
<horaceli> and I did this 14 hours ago
<lool> horaceli: How did you build it?  dpkg-buildpackage?
<horaceli> lool, did you build up hildon-1 with 'MAEMO_GTK' defined?
<lool> horaceli: Can you run "dpkg-checkbuilddeps" from your checkout?
<lool> horaceli: I just build using the regular process, either debuild or dpkg-buildpackage
<mdz> bspencer: I haven't seen him around, but he's certainly on #ubuntu-devel and would come over if you asked him
<mdz> bspencer: his nick is 'heno'
<bspencer> thx
<mdz> bspencer: I'm not sure how late he usually works, but I was on a conference call with him less than 30 minutes ago
<horaceli> lool, I guess I might use the different way. what I did is to do './autogen.sh --prefix=/usr ...' and then 'make'
<horaceli> lool, HILDON_GTK_INPUT_MODE_NUMERIC is defined by maemo guys in gtkenums.h and switched on/off by MAEMO_CHANGES.
<horaceli> and hildon-date-editor.c used it
<lool> horaceli: Basically, you shouldn't worry about the way the package is built internally
<lool> horaceli: You should build packages, and this involves dpkg-buildpackage or debuild as interfaces
<lool> horaceli: For example in your case, I suspect debian/rules passes adapted configure flags, such as --without-maemo-gtk
<horaceli> lool, i am checking the rules. thank you for the advice
<mvo> tfheen: could you please paste the output of config.guess on a lpia system for me? support in apt is ready, I just want to be sure that I got it right 
<horaceli> it just reminded me.
<horaceli> 'cause I built it up successfully by running './debian/rules binary'
<agoliveira> horaceli: Unless you have a very good reason to try to compile the packages yourself, I strongly suggest that you work the same way we do, using Gutsy and debian tools or we are risking duplicate efforts and raise conflicts between the results.
<lool> horaceli: Actually, it depends on what you want to do with the package; if it is to verify you can build it, debian/rules binary is fine, if you're planning to develop some feature in this source, you might want to call lower level commands manually I suppose
<horaceli> agoliveira, I agree
<horaceli> lool, yes. what I wanted to do is to get all the hildon components installed in feisty first ( I will move to Gusty tomorrow) and get hildon desktop running
<lool> horaceli: You can install them from the archive directly then; no need to build them I suppose
<lool> Ah soryr, feisty nm
<bspencer> lool, agoliveira, can't we build a gutsy chroot environment inside feisty?
<lool> bspencer: Sure, I think so
<bspencer> I thikn I was shown how to do this already
<bspencer> by tollef
<lool> bspencer: If you really want a _chroot_, you can use debootstrap to create a feisty chroot and then dist-upgrade to gutsy
<agoliveira> bspencer: Yes you can. Personally, I prefer vmware.
<bspencer> horaceli, you should use project builder to get you a build environment.  It builds the gutsy stack for you. 
<bspencer> or you can update your system to gutsy
* lool . o O ( Hmm what's project builder )
<horaceli> bspencer, i am not sure gusty has already in our project builder or not
<horaceli> so i preferred to install it and have a try
<bspencer> horaceli, I'll check with rusty.  That is the purpose of it anyway.  I'll chat with you tomorrow when you get in.
<horaceli> I can install it to a UMPC
<horaceli> ok
<bspencer> lool, project builder is a simple tool to create an ubuntu-mobile stack in a chroot environment and then allow a user to easily create a USB or ISO image for their device
<horaceli> bspencer, so you have already got the gusty source?
<lool> bspencer: Ah, is this from maemo or from Intel?
<horaceli> lool, from Intel
<bspencer> horaceli, we've been using the ubuntu packages.
<lool> Internal use only?
<bspencer> lool, just until we can get legal stamp
<bspencer> big company, long delays
<bspencer> but that is in the works.
<horaceli> bspencer, yes, I know, just we are based on feisty now, right?
<lool> So I suppose it'll end up in Ubuntu too! :)
<bspencer> lool, we would like that, if it is acceptable or something better.
<bspencer> doesn't show up
<lool> It permits some cool "Mise en abme" situations, where you install ubuntu where you install project builder where you install ubuntu
<bspencer> :)
<bspencer> lool, debootstrap was the tool tollef showed me.  thanks for the reminder
<lool> If you _just_ want to build packages, then I suggest you go for pbuilder though
<lool> It provides a high level interface to "just build" packages and maintain your chroot, basically "pbuilder create" the first time, "pbuilder update" regularly and "pdebuild" to build packages
<lool> It's not suited to launch commands under a gutsy environment and display them on feisty though
<bspencer> lool, ok.  that sounds like what "mock" does in FC (our previous life)
<lool> hehe
<lool> Kind of
<bspencer> lool,  but it will create a clean environment (gutsy) and then build your package
<lool> mock is a pbuilder + debootstrap kind of think
<lool> But yeah, that's the spirit
<bspencer> "pbuilder create" doesn't create a full chroot environment?
<bspencer> meaning, a chroot with all the dependent packages
<lool> It does, but it's different in that it will either 1) create a tarball of the chroot and unpack it each time you need to build something (you can build multiple things in parallel though) or 2) use a special hack called cowdancer which will intercept writes below a tree and create copy on write of files
<lool> I'm using the later mode which permits building multiple packages at once and is very fast to setup clean chroots
<lool> mock will not really restore a clean chroot each time, it installs and uninstalls packages
<lool> Anyway, mock does not handle Debian packages and pbuilder does not handle rpm packages, so... :)
<bspencer> got it.  thanks.
<lool> bzr.debian.org/bzr/pkg-maemo/hildon-thumbnail/debian/ available for review
<mdz> lool: where did these debian branches come from?
<lool> Hmm I created these
<mdz> is someone working on packaging maemo natively for Debian?
<mdz> lool: oh
<mdz> why not put them on launchpad then?
<lool> To be able to grant commit access to Debian Developers  :-)
<mdz> you can grant commit access to anyone with an email address and an ssh key on Launchpad
<mdz> so both Debian developers and Ubuntu developers
<lool> Ok, let's say it was symetry and independence
<mdz> I don't think non-DDs can have access to bzr.d.o
<lool> Sure, they simply need to create an account on alioth
<lool> And http:// is anonymous
<mdz> as you like. it would be nice to at least register the branches in launchpad so that we can get email notifications etc.
<lool> Ah that would be nice indeed
<tfheen> mvo: that's hard for me, given that I don't have such a system
<tfheen> bspencer: hiya
<bspencer> howdy
<tfheen> good to see you guys around here
<lool> tfheen: Did you take a look at some of the branches I published already?  Perhaps if they contain fixes of interest for Ubuntu, I can push some of these changes directly to ubuntu-mobile in the future?
<tfheen> lool: no, sorry, I have been utterly swamped.  I'd be fine trusting your judgement on what's appropriate for ubuntu and what's not
<tfheen> agoliveira: ok, good.  Prod me when -plankton is there?
<bspencer> tfheen, thx.  Well done on the "making us feel welcome" effort
<lool> tfheen: Ok; do you think I should push to ubuntu-mobile branches directly then? (I'm not an Ubuntu dev BTW)
<tfheen> bspencer: good to hear, if there's anything more you need from us, please tell us.
<tfheen> bspencer: I'm working with mdz on getting a set of goals for next week's sprint ready, I'll send it to you guys once it's ready.
<tfheen> lool: I'd like to just review the branches first, and assuming they're fine I'm happy to accept you into the ubuntu-mobile team on launchpad.  Sounds good?
<lool> tfheen: Oh that's exactly what I wanted; perfect
<bspencer> great. I know charlie is working on schedule and stuff to get to you.  We can discuss tomorrow.
<tfheen> lool: and then you can later make calls as to whether something is suitable for ubuntu or not.  If you're unsure, I or somebody else is around and happy to help you out.
<tfheen> bspencer: excellent
<lool> tfheen: The changes which would not be suitable for Ubuntu are basically setting the Maintainer and the version number; I don't expect much more to differ, we discussed *.la files already
<agoliveira> tfheen: No problem. Right now I'm having a weird coredump caused by hildon-theme-slicer related to a invalid pointer when it tries to parse some files to build -plankton but I'm on it.
<mdz> bspencer: I've received the schedule from Charlie and glanced at it, but haven't digested it yet
<lool> Grrr the symlinks in the osso-gwconnect tarball are not nice
<lool> http://paste.debian.net/29785
<agoliveira> tfheen: Are we ok with the conference tomorrow?
<agoliveira> lool: I saw a lot of links to specific versions of autotools over hildon files. Just replace for the default ones looks fine.
<lool> agoliveira: Yeah; but these files are currently not kept in bzr, and I'm trying to build as non-native, so it made the build rules think the files were available, but these were dangling pointers
<lool> s/pointers/links
<tfheen> agoliveira: thanks, yes the conference tomorrow is still on, I would have sent a mail to the mobile list if my email wasn't stuff ATM
<tfheen> lool: I think we just have done an automake --copy --force -a to get rid of those
<tfheen> bspencer: also, we're having a sprint downtown london in July; you (as in, your team) is welcome.  Again, I'll send an invite as soon as my email is back.
<bspencer> tfheen, ok, let us know and we'll see if we can come
<lool> tfheen: The thing is, if I try to build even the ubuntu bzr branch in non-native, it will get upstream's "configure" script and hence decide not to run autogen
<tfheen> lool: hmm, ok.
<tfheen> lool: wonder why our packages built fine, then
<lool> tfheen: You're in native mode I think
<tfheen> bspencer: July 9th through 13th are the dates.
<tfheen> lool: point, we are.
<bspencer> when is guadec?
<tfheen> week after
<tfheen> I'm going to guadec for the first couple of days at least.
<bspencer> good -- maybe we could come the last couple of days of the sprint.
<tfheen> that'd be good.
<lool> Hmm and osso-gwconnect is missing build-deps too; I think it misses the whole autotools saga as it runs autogen
<tfheen> hm, I thought I taught it not to do that
<lool> tfheen: Perhaps the files were not bzr added after your bootstrap then?
<tfheen> maybe, and that machine is behind said horrible network so I can't check until tomorrow
<lool> (Proposed bzr.debian.org/bzr/pkg-maemo/osso-gwconnect/debian/ for merge on the wiki / TODO)
<tfheen> cheers
<lool> Weird, libhildonmime is newer in SVN than in the archive
<lool> (at maemo.org)
<tko> it's strange that trunk is more recent than latest release?
<lool> tko: Well there are two versions with "unstable" instead of UNRELEASED in the changelog; so I would have expected to see at least one in the archive
<tko> well, we're not so picky about what we put in changelogs... :)
<lool> Heh
<lool> (TODO += bzr.debian.org/bzr/pkg-maemo/libhildonmime/debian/ )
<tfheen> yay. :-)
<lool> I'm at hildon-fm now; then I'll attach the hildonhelp tree
<lool> s/attach/attack
<lool> BTW, is there a bzr command to wipe all files in a checkout which are not versionned?
<tfheen> rm $(bzr unknowns) ?
<lool> (For some reason, even maintainer-clean doesn't get rid of files in my libhildonmime)
<lool> tfheen: Looks good; thanks!
<lool> aha, hildon-file-chooser-dialog.c:38:37: error: gtk/gtkfilechooserutils.h: No such file or directory
<lool> So I have to upload Debian's Gtk now :-P
<tfheen> yup, it unfortunate.
* lool goes for dinner &
<mvo> tfheen: ok, thanks. I added it as "i.86-.*-linux-gnulp     lpia" I hope that is appropriate. easy enough to fix (buildlib/systemtable)
<tfheen> mvo: yup, thanks.
<mvo> its in my bzr tree, I plan a upload for a new apt for friday or monday
<tfheen> cheers.
<tfheen> having it Friday would be great.
<agoliveira> Yes, should be fine. Use the build tools as I said.
<lool> Cool, maemo folks started merging the patch I sent against libosso with the upstream fixes
<lool> All *.c, *.h, and Makefile.am changes tfheen, agoliveira, and I did were merged! :)
<agoliveira> lool: Nice :)
<agoliveira> lool: That's the spirit of free software!
<lool> jonnylamb: Heya
<lool> jonnylamb: So, as a starter, there's some info on the Ubuntu Wiki pages
<lool> https://wiki.ubuntu.com/MobileAndEmbedded/TODO for example is the TODO
<lool> (Well, see topic)
<lool> Most packages but not all are bzr based; you can find them on https://code.launchpad.net/~ubuntu-mobile/
<jonnylamb> Indeed :)
<lool> The Debian branches are on bzr.debian.org and have a mirror of the ubuntu branches
<jonnylamb> I was looking around on stage.maemo.org even today, amd noted how the packaging could be cleaned up!
<jonnylamb> Oh, is pkg-maemo using bzr?
<lool> I was suggested to file bugs in the maemo bugzilla to send packaging and other fixes
<lool> jonnylamb: Nope, but the SVN is imported in BZR and the packages use BZR
<lool> It seems plenty of upstream folks use git too
<jonnylamb> Okay, let me get this straight: we're getting the upstream stuff from maemo. They currently have debian/ directories. We're aiming to clean up the packaging and send the packaging (and of course any bug fixes) back upstream?
<lool> Something like that
<lool> Except sending back packaging fixes is probably not top priority versus getting things working
<jonnylamb> Have maemo requested packaging goes back upstream?
<lool> No
<lool> One big problem is that they are currently stuck with Debhelper 4
<jonnylamb> Oh, this same code is being used by them to create their ARM debs for the actual devices, right?
<lool> Upstream, yes
<lool> But the bzr branches is for Ubuntu / Debian
<lool> s/is/are
<jonnylamb> Of course, sorry I missed the point for a second there!
<lool> Time to go to bed it seems
<jonnylamb> Okay, so current _debian_ branches are on bzr.debian.org ?
<lool> Correct
<jonnylamb> And follow the TODO list on the Ubuntu wiki?
<lool> Debian branches are catching up on the progress of the Ubuntu branches :)
<lool> And I'm listing them on the TODO of the Ubuntu wiki because I basically do some cleanups which are cleanups for Ubuntu as well
<jonnylamb> Haha, I see!
<jonnylamb> Okay, I'm going to have to have a bit scout about this and then if I have any other questions, may I just ping you?
<jonnylamb> s/bit/big/
<lool> But currently the flow is 1) maemo works upsteam 2) ubuntu branched the maemo svn to try to boostrap maemo and will send its fixes at some point 3) debian (well, me) branched the ubuntu branches to also bootstrap maemo and sends its fixes to both ubuntu and maemo
<jonnylamb> Ah okay.
<lool> jonnylamb: Sure, just ask around; people should be nice here :)
<jonnylamb> Where would *you* like me to start poking around in the Debian branch?
<lool> jonnylamb: What do you run, Debian or Ubuntu?
<jonnylamb> Debian! You met me on #gnome-debian, after all!
<lool> Hehe, there are plenty of Ubuntu-runners on #gnome-debian :)
<lool> jonnylamb: Ok, so currently binary packages are available in gutsy, which makes it easier to get some maemo bits; on the Debian side of things, I didn't upload anything yet as I wanted to go a bit further in the bootstrap
<lool> If you like, you can try building packages locally from the Debian branches and/or review the existing packages
<lool> You should start in the order mce-dev, libosso, libhildon (hildon-1), osso-af-settings, hildon-thumbnail, libhildonmime
<lool> You should be able to build all this by bzr co + debuild -i
#ubuntu-mobile 2007-06-07
<Mithrandir> the relationship between https://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuide and https://wiki.ubuntu.com/MobileAndEmbedded/UserInterface is the former is for all apps, while the latter is for the system as a whole, right?
<ian_brasil> https://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuide is just the guideline i think
<ian_brasil> and https://wiki.ubuntu.com/MobileAndEmbedded/UserInterface are some mock ups 
<ian_brasil> I wonder why the top menu cannot be like Applications,Places,System on a vanilla gnome install...i wonder why the clock is in the middle for example
<ian_brasil> on https://wiki.ubuntu.com/MobileAndEmbedded/UIStyleGuide
<ian_brasil> seems like a lot of space for a clock
<ian_brasil> which could be used for something else (like IM messages and so on)
<agoliveira> marciom: Grande Marcio Macedo! Adilson aqui.
<marciom> agoliveira, hi :)
<Mithrandir> ian_brasil: you're the Ian that mailed me earlier today?
<ian_brasil> don't think so
<Mithrandir> about developer docs
<ian_brasil_> ah, pk...yes that is me
<Mithrandir> great; I just sent you a reply.
<Mithrandir> I have been told the developer docs for maemo are not good enough, but I'm not sure exactly where they are missing bits, so help in both figuring out where the holes are as well as filling them in is most appreciated.
<ian_brasil_> the biggest problem has been the testing of the docs...somethings are tested on bora ..some on sardine and so on
<Mithrandir> is that some sort of automated testing?
<Mithrandir> maybe I'm slow, but I don't see how you really test developer docs.
<ian_brasil_> i would think not but i am not familiar with the doc process inside nokia...there has also been the problem with the move to midgard chewing up some docs
<Mithrandir> yeah, that's quite unfortunate.
<ian_brasil_> there was the suggestion of using the wiki as some sort of doc incoming 
<Mithrandir> it seems like there's an active effort to move the repos to gnome, so once that works out we should be able to put the maemo docs somewhere on gnome.org
<Mithrandir> when you're talking about docs, are you talking about doxygen-like docs or higher level development guides?
<ian_brasil_> things like http://maemo.org/development/documentation/how-tos/2-x/howto_customization.html with missing code  and http://maemo.org/community/wiki/HildonDesktopPortability which does not compile
<Mithrandir> ah, so higher-level docs.
<ian_brasil_> bugs have been submitted to bugzilla but i think nokia are still looking for a doc manager to bring it all together
* Mithrandir nods
<Mithrandir> a wiki looks a bit like the wrong place for structured docs like that..
<lool> Mithrandir: Doh, you're going to both the desktop architects meeting and debconf!
<Mithrandir> lool: no, I'm not going to the DAM, I can't make it due to vacation next week
<Mithrandir> I'd have loved to, but I can't tell my wife "no, we're not going to scotland after all"
<agoliveira> Mithrandir: The last phrase tells me that you're married for some time already ;)
<agoliveir1> Jeez... finally found the error with hildon-theme-slicer! Expect a hildon-theme-plankton package soon :)
<tko> agoliveira: bugs in our code? unpossible :-P
<agoliveira> tko: I'll save the sarcarsm for later ; ) but actually it's not a bug. The memory allocation changed on gtk recently (2.10 IIRC) so the template parser was trying to do some nasty things with slices alocated.
<agoliveira> I think I nailed it (it actually ran alredy) but I have to be sure if there's more leaks than usual ;)
<tko> agoliveira: well, we should've noticed since we are running 2.10, even including some stuff from trunk
<tko> I was glancing through some of the code and couldn't spot anything obvious
<agoliveira> tko: Well, I also found it weird but the problem happens in common.c. That g_free (key_file) crashes the slicer badly.
<tko> note to self: slap MDK in the head with G_SLICE=debug-blocks :)
<agoliveira> If you just comment it out it runs. God only knows what happens to the memory so far, of course as I didn't check it's state yet but at least I found the freacking spot.
<tko> I did see a logical or vs. bitwise or bug in g_file_test in slicer
<tko> good catch
<agoliveira> I was starting to think the bug was on Gtk itself which send shivers down my spine :)
<tko> having been the maintainer for our gtk I know what you mean...
<lucasr> meeting in 5 minutes?
<lucasr> oops 15 min.
<tko> 1h 15min I think.. too lazy to check the world clock :)
<agoliveira> Well, I'll grab a coffee, go to our weekly meeting and return to that later but a food for tought: none of the few examples I found using g_key_file_new() actually freed the pointer later so either it's bad examples or soething fishy is going on :)
<agoliveira> lucasr: 1:15
<tko> it's like /* error handling omitted for brevity */
<tko> lucasr: at least I got ebassi to include the convenient world time link in gtk team meeting announcement :)
<lucasr> hmm, I always get confused
<lucasr> tko, it was ery useful actually :-)
<ian_brasil_> ola lucasr...i had some problem installing maemo gtk following your tutorial :(
<lucasr> ian_brasil, blame tko!
<ian_brasil_> ha ha
<lucasr> ian_brasil, what was it?
<ian_brasil_> https://bugs.maemo.org/show_bug.cgi?id=1519
<tko> lucasr: hey, no fair, I haven't touched your tutorial.. :)
<ian_brasil_> i think it has to do with trying to make C become an OO language
<tko> oh, it needs maemo glib
<lucasr> tko, hmmm, I forgot to add the glib bits to the tutorial
<tko> lucasr: grrrr
<tko> the 'constructed' thing is something backported from gtk/glib trunk
<lucasr> ian_brasil, install https://stage.maemo.org/svn/maemo/projects/haf/trunk/glib
<agoliveira> ian_brasil_: Why do that to such a beautifull language. Let C++ spoil it! :)
<ian_brasil_> can I add the glib bits to the tutorial and do a rewrite ?
<lucasr> ian_brasil, yes, please
<lucasr> ian_brasil, add a note like "Shame on tko!"
<ian_brasil_> ha ha...my pleasure
<lucasr> ian_brasil_, brasileiro ou morando no Brasil?
<ian_brasil_> morou em Manaus mas sou ingles
<lucasr> ian_brasil_, do indt?
<agoliveira> ian_brasil_: From england to Manaus. That's a hell of a change!
<lucasr> agoliveira, from Bahia to Helsinki is much worse
<lucasr> :-)
<ian_brasil_> ainda nao mas logo vou trampar la eu acho
<vivijim> lucasr: e voc?
<lucasr> ian_brasil_, :-)
<lucasr> vivijim, eu o que?
<ian_brasil_> agoliveira: its a bit warmer, thank god
<agoliveira> lucasr: I guess so. My parents came from Bahia and I still have many relatives there.
<lucasr> agoliveira, :-)
<vivijim> lucasr: brazileiro? trabalha onde? canonical? 
<agoliveira> Oops.. meeting time
<lucasr> vivijim, brasileiro. Nokia.
<lucasr> jobi!
<jobi> lucas!
<jobi> hope you are not concepting ;)
<vivijim> lucasr: nice. I'm from INdT working in mamona project...
<lucasr> jobi, who won in that Wii match?
<lucasr> jobi, of course I am
<lucasr> :-)
<lucasr> vivijim, cool. How is Mamona going btw?
<jobi> lucasr: we had France vs Spain tonight and we won
<lucasr> jobi, did you use your head to hit the oponent's chest?
<lucasr> jobi, oh, that was against Italy
<lucasr> :-P
<lucasr> jobi, never mind
<jobi> didn't have to use this trick
<vivijim> lucasr: we already have some base packages. It is already possible to use a debootstrap script to install and run a chroot all over a qemu user mode emulation... At this time I'm trying to build a lot of packages including the osso's one...
<lucasr> vivijim, cool
<lucasr> vivijim, nice to know that Mamona is going forward
<lucasr> vivijim, you should communicate your progress more often
<ian_brasil_> Mamona is cool...my deb installed fine in it
<lucasr> vivijim, at least in planet.maemo.org
<jonnylamb> Or on the mailing list too :)
<vivijim> lucasr: thanks. yes, I need to include my blog at planet maemo.. I always forget...
<lucasr> vivijim, please do :-)
<vivijim> I'm following this ubuntu-mobile community because I believe that the idea of this project is so close to mamona's idea... and I believe that we can join efforts...
<vivijim> lucasr: I will :)
<lucasr> vivijim, well, I guess mamona seems to be more Maemo specific
<lucasr> vivijim, but of course there are some overlaps
<lucasr> vivijim, specialy in the part of providing free alternatives to the some proprietary UI components and applications
<vivijim> yes, these parts that I'm talking about...
<lucasr> mdz_!
<lucasr> :-)
<mdz_> hello
<Mithrandir> hiya mdz
<ian_brasil_> lucasr: how do install glib then?..checkout the svn and then what?
<lucasr> ian_brasil, the good&old "./configure --prefix=YOUR_PREFIX && make && make install"
<ian_brasil_> mm, thats what i thought..but there is no configure only configure.in which needs root permissions
<tko> autogen.sh
<jobi> tko!
<tko> !
<ian_brasil_> tkp: thx
<tko> jobi: now that you're around... what's the deal with 'nocomposite' revisions?
<jobi> tko: they have the build-dep on libxcomposite-dev and libxdamage-dev removed
<tko> (cia is nice...)
<Mithrandir> why do you do that?  To save space on the rootfs?
<tko> jobi: and why?
<jobi> tko: waiting for the X with composite to go in
<tko> nngh.. should've guessed
<jobi> tko: anyway it would work even with the composite stuff compiled in, but if you use an out of the shelf Xephyr the composite is too old, and the applets are clipped
<tko> so the usual story.. fixed dozens of bugs, but now the colors are a bit off -> rejected
<jobi> tko: well in that case, the new X breaks video playback :)
<tko> you can't make an omelet without breaking something :)
<jobi> that's what i always tell them :)
<ian_brasil_> lucasr: I installed glib from svn but the maemo gtk gave an error configure: error:
<ian_brasil_> *** GLIB 2.12.0 or better is required. The latest version of
<ian_brasil_> *** GLIB is always available from ftp://ftp.gtk.org/pub/gtk/.
<tim__> good evening
<bastian> good afternoon :-)
<tim__> at least in germany : )
<tko> ian_brasil: which url you used to check out glib?
<lucasr> ian_brasil_, probably something with your PKGCONFIG_PATH
<bastian> oregon, US :-)
<Mithrandir> PKG_CONFIG_PATH, not PKGCONFIG_PATH
<tko> lucasr: doesn't jhbuild update it automagically?
<tim__> I guess this is the room where the 2100UTC meeting will happen?
* Mithrandir is trying to purge the world of pkgconfig and leave it with pkg-config.
<Mithrandir> tim__: yes
<lucasr> tko, what do you mean?
<tim__> cool, thanks
<lucasr> Mithrandir, yes, yes
<tko> lucasr: I mean that with jhbuild you shouldn't need to update it manually provided that you've installed the dependencies in the same prefix
<ian_brasil_> tko:https://stage.maemo.org/svn/maemo/projects/haf/trunk/glib
<tko> ian_brasil_: must be pkgconfig then.. config.log should have more details
<jobi> ian_brasil_: did you specify a --prefix when installing glib? if not it will get installed in /usr/local and you will need to run something like PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure
<Mithrandir> pkg-config in ubuntu looks in /usr/local/lib/pkgconfig by default, btw.
<ian_brasil_> i installed to /opt/maemo
<lucasr> ian_brasil_, see the first steps in "Manual process" section
<lucasr> ian_brasil_, "export PKG_CONFIG_PATH=/opt/maemo/lib/pkgconfig:/usr/lib/pkgconfig"
<ian_brasil_> i ran both commands before building
<lucasr> ian_brasil_, "export PKG_CONFIG_PATH=/opt/maemo/lib/pkgconfig:$PKG_CONFIG_PATH" would be better :-)
<Mithrandir> lucasr: no need to include /usr/lib/pkgconfig there; _PATH adds to the list, PKG_CONFIG_LIBDIR overrides it
<lucasr> Mithrandir, good catch
<ian_brasil_> still no joy... 'pkg-config --modversion glib-2.0' returned 2.12.12, but GLIB (2.12.11)
<ian_brasil_> *** was found! 
<tko> ian_brasil_: you also need to update LD_LIBRARY_PATH
<Mithrandir> lucasr: I maintain it, I should know it. :-P
<lucasr> Mithrandir, :-)
<ian_brasil_> like this? export LD_LIBRARY_PATH=/opt/maemo:$LD_LIBRARY_PATH  ??
<jonnylamb> Or one can add the lib path to /etc/ld.so.conf, and run ldconfig.
<jobi> LD_LIBRARY_PATH=/opt/maemo/lib:$LD_LIBRARY_PATH
<Mithrandir> ian_brasil_: might be better to override PKG_CONFIG_LIBDIR instead.
<ian_brasil_> cool...maemo gtk buils...thx and i will write this up soon
<Mithrandir> ian_brasil_: great; feel free to add links to a howto or similar to https://wiki.ubuntu.com/MobileAndEmbedded
<ian_brasil> ok i will do that
<mubelacker> thanks too i had the same problem no HildonDesktop outside the scratchbox and now it works 
<Mithrandir> good afternoon, ladies and gentlemen
<Mithrandir> agoliveira: you're here, right?
<agoliveira> Yep
<Mithrandir> great.
<Mithrandir> bspencer_: do you know of anybody missing from your side?
<bspencer_> checking...
<bspencer_> rusty -- ?
<agoliveira> just in
<Mithrandir> tata. :-) ; a successful summoning.
<rusty_> hello all
<bspencer_> :)
<bspencer_> waldo bastian
<tim__> hi
<bastian> hi :-)
<bspencer_> ah, we are good then,.
<tshureih> Hola everyone
* agoliveira waves all
<robr> hi
<Mithrandir> should we start with a small presentation of who everybody is?  I believe there are community members here who have no idea who everybody is. :-)
<bspencer_> I can introduce intel guys together
* Mithrandir is Tollef Fog Heen, leading the mobile effort from Ubuntu's / Canonical's side.
<bspencer_> rusty_,   Intel architect lead,   bspencer, Bob spencer -- Apps / UI arch.    robr  -- Intel kernel
<bspencer_> waldo bastian -- Intel graphics guy
<bspencer_> tshureih -- Intel engineering / power guy
<bspencer_> <done>
<bastian> video, not graphics :-)
<agoliveira> Hi all. Adilson Oliveira here, with Tollef working on the Ubuntu Mobile and Embedded project for Canonical
<Mithrandir> any community people who want to tell who they are too?
<agoliveira> There's some Nokia dudes here as well ;)
<chippy> Hi All. Steve / Chippy from UMPCportal. Watching like a hawk! 
<tim__> Hi All. Tim Lawrenz, currently developing for plazes.com, hoping to be able to contribute somehow
<Mithrandir> it seemed like nobody had anything to add to the agenda; any late additions?
* ian_brasil maemo community developer and helped setup the Ubuntu Brazil community 
* stgraber is just listening, interested in the project
<robr> what was the agenda?
<Mithrandir> great to see a community interest here; we want you to feel welcome so if there's anything we can help you out with, tell us.
<Mithrandir> * Current status - Hildon in Ubuntu proper - Specs
<Mithrandir> * Plans for the Desktop Architechts Meeting in Mountain View next week.
<tim__> * Current status
<tim__>  - Hildon in Ubuntu proper
<tim__>  - Specs
<tim__> * Plans for the Desktop Architechts Meeting in Mountain View next
<tim__>  week.
<Mithrandir> irssi mangled that, but tim__'s paste came well through.
<Mithrandir> so, first item, Hildon in Ubuntu proper, which is mine.
<robr> thanks
<Mithrandir> we are proceeding at a good pace, bzr contains the bits needed to build hildon-desktop, but uploads have been blocked on me having entirely too much to do with coordinating everything.
<Mithrandir> I'm hoping we can have the bits in by the time western US wakes up tomorrow.
<rusty_> sweet
<bspencer_>  rusty_  gets up at 4am
<Mithrandir> agoliveira has been working on getting the theme bits done; there was some "interesting" memory problems there, but he has worked around them, I believe.
<Mithrandir> agoliveira: can you confirm that I'm correct in the above?
<agoliveira> I have being working on the support files like themes and stomp into a nasty bug on theme-tools. I found the problem, looking how to fix it the right way.
<bspencer_> agoliveira, have you seen the desktop, or is that pending the theme bugs?
<bspencer_> meaning, can we boot to a desktop UI?
<agoliveira> It's pending the themes yet.
<agoliveira> Booting the desktop will come only after I fix it all upb ut it won't take long I guess.
<agoliveira> I hope we can do that together next week ;)
<bspencer_> looking forward to that.
<Mithrandir> so getting there, but not there yet.
<agoliveira> BTW, the plankton theme should be working. The problem is in the theme-tools that are used to build the themes.
<agoliveira> After a Q&D hack I was able to build the theme just fine
<Mithrandir> agoliveira: good work
<agoliveira> Bitte!
<rusty_> does getting the desktop up depend on osso-gwconnect?
<Mithrandir> rusty_: osso-gwconnect is in gutsy.
<agoliveira> rusty_: not really.
<Mithrandir> we're going to get rid of it, I really, really hope, but for now it's there.
<bspencer_> osso-gwconnect was the bluez stuff?
<agoliveira> Yep.
<agoliveira> Actually we need to replace it for bluez interface
<Mithrandir> but bluez now ships its own dbus interface.
<rusty_> agoliveira, by saying "it's in gutsy", you mean the package is in the universe repository?
<Mithrandir> rusty_: yes.
<agoliveira> yes
<rusty_> hmm... maybe i need to update
<Mithrandir> as of yesterday, iirc
<Mithrandir> osso-gwconnect | 1.0.10ubuntu3 | gutsy/universe | source, amd64, i386, ia64, powerpc, sparc
<agoliveira> Next week I'll have a few CDs with gutsy so we can prepare an enviromment for you.
<agoliveira> Actually, they are right here in front of me ;)
<Mithrandir> anybody got any more questions about hildon in Ubuntu?
<bspencer_> agoliveira, we (Intel) also have a couple of PRC engineers who are eager to help.  If there is something hildon-related you have put on the side they would be pleased to chew at it.
<Mithrandir> PRC = ?
<bspencer_> China
<bspencer_> People's Republic :)
<Mithrandir> yup, just wondering if it meant something else in intel-lingo. :-)
<bspencer_> horace is there, he introduced himself yesterday
<agoliveira> bspencer_: Certanly there will be a zillion things to work out as soon as we start to boot the beast.
<lucasr> hmm, has the meeting started?
<bspencer_> yes, just fyi.
<Mithrandir> lucasr: 16 minutes ago
<agoliveira> bspencer_: Yes, I've being in contact with him already.
<bspencer_> agoliveira, I know.  
<bastian> mith: bob didn't send you the Intel acronym dictionary? :-)
<Mithrandir> bastian: I think the postal service refused to deliver it due to excessive weight. ;-)
<lucasr> Mithrandir, k
<bspencer_> nothing else wrt hildon from my end.
<Mithrandir> ok, so next item is specs.
<bspencer_> (but I thought of another agenda item for the end...  gnome mobile stuff.)
<Mithrandir> bspencer_: happy to tag it on.
<Mithrandir> we are currently a fair bit behind with specs and getting them written and approved.
<Mithrandir> I'm not sure if it makes any kind of sense to go through them one by one?
<bspencer_> how fast can you list them all?
<bspencer_> or the url
<Mithrandir> https://blueprints.launchpad.net/~ubuntu-mobile/
<bspencer_> the goal is to get to "approved" ?  Or more?
<Mithrandir> approved for the design, implemented for the delivery.
<Mithrandir> I'm happy to help with review and such if you're unsure about what should go into the specs.
<bspencer_> not that
<bspencer_> just priorities.  
<bspencer_> I'll work on those I own before Monday
<bspencer_> is the "Drafter" the creator ?
<bspencer_> some don't have "Assignees"
<bastian> what's still missing for the hw-decode one?
<Mithrandir> so, whoever registered it is listed in the "Lifecycle" portlet on the left
<Mithrandir> let's take https://blueprints.launchpad.net/ubuntu/+spec/mobile-hw-decode as an example.
<Mithrandir> so Charlie Johnson registered mobile-hw-decode.  He is the assignee, who is responsible for implementing it.
<Mithrandir> he is also the drafter, who is responsible for actually writing the specification and getting it approved.  Once it's approved, his job is done.
<Mithrandir> the approver is the person (or group) who says "this is what we want and this spec is complete".  That person or group moves it from "Pending approval" to "Approved"
<Mithrandir> once it's approved, it can be implemented.
<bastian> so Charlie is also the approver? :-)
<rusty_> in this case, who does Charlie request to approve the spec?
<Mithrandir> it would probably be best to ask me, since I've been through the process a few times.
<Mithrandir> if it's not complete or has inconsistencies or other problems, it gets dumped back to drafting.
<Mithrandir> it's normal for specs to go through a couple of rounds before they are approved, so don't get disappointed if something is pointed out as "this needs more work", "this is unclear", etc.
<Mithrandir> bastian: as for hw-decode, it lacks use-cases, which should be trivial to add.  What assumptions are it based on?  (That hardware will support HW decode, maybe something in the software stack or another spec)  The API definition should probably be moved to the implementation section.
<rusty_> well... i need to just sit down tonight and fill out the imagecreation blueprint
<Mithrandir> bastian: also, it has unused sections like UI changes, code changes which should either be filled in, or removed.
<Mithrandir> the idea is for an approved spec that "anybody", as in, a technically competent person who knows the surrounding bits should be able to implement it.
<rusty_> is there a template or minimal list of categories that need to be filled out?
<Mithrandir> in some cases, this is provably not true (my build-infrastructure spec is a good example, it ends with "Tell Adam to bootstrap") which can be fine.
<bastian> once we think it's ok, how do we request approval review?
<Mithrandir> change the status to "pending approval"
<Mithrandir> (at developer summits, we have reviewers who check specs for consistency and language, but we'll skip that step now and hope my command of the English language is good enough)
<Mithrandir> https://blueprints.launchpad.net/ubuntu/+spec/mobile-hw-decode -> Actions portlet -> Change status, then change it there.
<Mithrandir> if people understand the process, I have a small question about the relationship of two of the specs.
<Mithrandir> mobile-ui and mobile-ui-style-guide; what's the relationship there?
<bspencer_> mobile-ui is the actual MID desktop UI implementation
<bspencer_> the other was a guide for applications and look-n-feel stuff.  
<bspencer_> maybe that isn't a spec
<Mithrandir> it might be an informational one, which does not have an implementation.
<bspencer_> right.  that is the intent.
<Mithrandir> and it's marked as one, which makes sense.
<bspencer_> there is no implementation for the guide.  Let me know if it should be placed elsewhere
<Mithrandir> no, that's fine, I was just wondering since I thought that was the distinction between them, but wasn't sure.
<bspencer_> If others started creating applications for MIDs I wanted a single place that helped describe the general user interface  (this is dependent on the implementation of the desktop UI of course)
<Mithrandir> of course, but having specs depending on other specs is fine
<Mithrandir> and you can mark them as such in LP too
<bspencer_> well, it doesn't depend on the implementation being finished, but if the desktop UI changed something big in the style or navigation, then I would update this.  
<Mithrandir> makes sense.
<Mithrandir> anybody else got any questions about specs?
<rusty_> yea
<rusty_> if we have a mostly empty spec and need to fill it out...
<rusty_> where to we go for guidance on what is expected?
<rusty_> like a template or something?
<Mithrandir> there's a SpecTemplate on the wiki
<rusty_> ok
<Mithrandir> http://wiki.ubuntu.com/SpecTemplate
<rusty_> ok, i'm good
<Mithrandir> also, looking at other approved specs might work, though be a bit critical and try to look at more than just one to get a feel for the style.
<agoliveira> rusty_: "no, you're not", says a little female voice in the back :)
<rusty_> :->
<Mithrandir> ok, let's move on to plans for the DAM next week.
<agoliveira> Ok
<Mithrandir> my absolute main goal for the sprint is enabling you (intel guys) to be move productive and have the tools you need to develop your bits.
<bspencer_> that sounds great
<Mithrandir> this, combined with having something showing at least a basic hildon desktop should make it possible for you to actually do your work.
<kwwii> has the themeing part already been packaged and put on launchpad?
<agoliveira> Despite I'm still quite crude on that yet, I'll be there to help in any way I can.
<agoliveira> kwwii: Not yet;
<robr> i'm actually looking to meet up w/ your kernel developer Kyle McMartin and go over the details of what you need for the kernel patches to enable Menlow hw
<agoliveira> kwwii: but it's almost there.
<Mithrandir> Kyle McMartin from our kernel team is also going to be there, he knows packaging well too.
<kwwii> agoliveira: cool, I'll watch out for that then
<Mithrandir> I'm sorry I can't be there, but I had scheduled vacation long before.
<Mithrandir> my second goal for the sprint is having more specs completed.  Ideally, all of them, but I doubt that is feasible.  mdz is going to be there and help with specs (in addition to anything else that pops up); he knows the process very well and has been doing this for a long time.
<lucasr> Mithrandir, agoliveira, have you got to run Hildon Desktop nicely?
<rusty_> beyond Monday and Tues, who will be sticking around for the linux foundation stuff?
<agoliveira> lucasr: Not yet, we are first putting everything into gutsy. We should try this next week.
<lucasr> agoliveira, k
<bspencer_> I'm there Mon-Thursday.  Leave Thu night.
<agoliveira> rusty_: I will be there all week. Just a warning: due to my flight schedule, I won't be there for the openning at 8:30am monday. I should arrive there about 10:30am.
<Mithrandir> rusty_: I believe all of our staff is, but I'm not sure.
<kwwii> I'll be there all week as well
<rusty_> will you guys be pretty busy with non-mobile stuff?
<Mithrandir> no, the idea is for our guys to concentrate on mobile
<agoliveira> Not me. mobile is my priority.
<rusty_> for the entire week then
<kwwii> yepp
<Mithrandir> I suspect mdz might be busy with non-mobile stuff too, so you should grab him as much as possible for the first two days.
<agoliveira> Yep
<agoliveira> mzd will do a talk IIRC
<Mithrandir> but he would be a better person to ask than I guessing what he is going to do or not.
* agoliveira thinks that "do a talk" sounds nasty...
<rusty_> having spent a way too much time doing OSDL activities in the past... i really only wanted to work on mobile related stuff.  I could care less about attending the actual desktop summit 
<Mithrandir> yes, I think you should be able to just sneak off a room somewhere and sit there and work quietly.
<bspencer_> I'm just there for the food
<Mithrandir> haha :-)
<kwwii> lol
<agoliveira> :D
<Mithrandir> I gained a couple of kgs from a week at google's last autumn..
<rusty_> BTW, you guys want to go out for dinner on Monday?
<Mithrandir> which is fairly insane
<agoliveira> rusty_: I'm all for it.
<kwwii> rusty_:  sounds good
<bspencer_> quick question about gnome-mobile stuff :)
<agoliveira> If I can stay awake after drop directly from the plane, of course.
<rusty_> we should pick something good... my boss just gave me the ok to pick up the tab :->
<bspencer_> there are a few components in the stack and I'm not sure who is in charge of them
<bspencer_> for example:  gconf w/dbus, gtk version that owrks, etc.
<bspencer_> is that my job, or where is this being tracked?
<Mithrandir> bspencer_: in general, the Ubuntu desktop team.
<Mithrandir> or kernel team or whoever is responsible for the piece of infrastructure.
<bspencer_> ok -- is there a ubuntu mobile desktop guy?
<bspencer_> let's say, gconf w/dbus
* agoliveira raises the hand
<Mithrandir> to the largest extent possible, we want the patches to work in the normal distro too.
<bspencer_> right, so I want to look at each piece and make sure that happens
<bspencer_> and who needs to add a patch or rework a patch to get it upstream
<bspencer_> etc.
<Mithrandir> so talking to dholbach and seb128 (Daniel Holbach, Sebastien Bastier, with lots of accents) would be good start.
<Mithrandir> ubuntu-desktop@lists.ubuntu.com or those two people on IRC would be good.
<Mithrandir> I'll be happy to introduce you so they don't get confused about why you are requesting what you are.
<bspencer_> ok.  I'll add the list of issues I know of to https://wiki.ubuntu.com/MobileAndEmbedded/GnomeComponents 
<Mithrandir> sounds good.
<tim__> I have to leave! thanks to everybody...
<Mithrandir> see you, tim__ 
<bspencer_> is this a weekly meeting?
<agoliveira> seb128 have being doing some work on gtk for us already
<Mithrandir> I was planning on it being a weekly meeting, yes.
<Mithrandir> good to keep in touch, since the time zone difference makes that hard.
<Mithrandir> I guess we'll skip it next week since you'll then be in MTV and I'll be on vacation, but in two week's time?
<agoliveira> I can help doing the bridge if necessary as I'm mor or less in the middle;
<bastian> bob: who owns the ubuntu mediaplayer spec, cathy?
<bspencer_> two weeks is good.  We can post our status next Thursday to the mailing list for those not in CA
<Mithrandir> bspencer_: unless you think weekly is too often?  I was thinking of having them a bit earlier most of the time, since it's now midnight for me.
<agoliveira> Mithrandir: Aren't you going to be in some event in 2 weeks?
<Mithrandir> agoliveira: I'm going to be at debconf => lots of connectivity.
<bspencer_> bastian, me
<agoliveira> Ok
<bspencer_> bastian, cathy's team is implementing it, but I'll help with the specs, if that is what you are asking.
<bspencer_> Mithrandir, I'm open to either 
<rusty_> i'm open to moving around this meeting time to accommodate people in various locations
<Mithrandir> we have taken to moving the distro team meetings between 1500 UTC and 2000 UTC (with adjustment for northern-hemisphere DST), so always having this meeting afterwards should work for me.
<bastian> bspencer: ah, ok, i was thinking about hw decode testing, that will need the media player & associated codecs, since it's unlikely that we have any other (test)player that we can release
* rusty_ reconfigures his cal applet to show UTC time
<bspencer_> Mithrandir, let's do one in two weeks, then decide if it should be weekly.
<Mithrandir> bspencer_: sounds like a plan.
<Mithrandir> does anybody have any other business?
<agoliveira> Just one question:
<agoliveira> How's the hardware doing?
<rusty_> not me... and i'll be hanging around (off an on with connectivity)
<rusty_> fine
<rusty_> :->
<bspencer_> agoliveira, things are moving along at variable rates but I've seen some cool looking prototype systems.
<ian_brasil> there will be an agenda page for the next meeting?
<agoliveira> Cool.
<Mithrandir> ian_brasil: yes, and a bit more warning than six hours.
<robr> more or less the normal HW development cycle
<rusty_> so... the current production hardware that we plan on using (before Menlow) is now shipping
<bspencer_> i'm encouraged that /some ODM/ will create a very nifty device.
<bspencer_> We are planning to use the Q1 ultra as a sample device internally for getting things running
<bastian> http://techreport.com/onearticle.x/12624
<bspencer_> s/Q1 ultra/Samsung Q1 ultra/
<robr> i saw a cool ODM prototype menlow system today in the lab
* agoliveira wants one :)
<Mithrandir> feel free to send any cute hardware in my direction. ;-)
<bspencer_> just need a little bigger pant pockets 
<agoliveira> I have a N770 and a Palm TX. Can't be worse.
<bspencer_> are they rubber-banded together?  
<bspencer_> ;)
<agoliveira> :)
<Mithrandir> ok, any more business, then?
<agoliveira> Nope.
<bspencer_> I'm good
<bspencer_> (no comment needed)
<agoliveira> :-D
<Mithrandir> see you around later, then; meeting adjourned.
<bastian> thanks Mit
<lucasr> Mithrandir, just a note: you will probably need to write plugins
<Mithrandir> I'll send minutes to the mobile list after eight hours or so of sleep.
<Mithrandir> lucasr: ECONTEXT?
<Mithrandir> as in, plugins for what?
<ian_brasil> well hosted Mithrandir
<Mithrandir> cheers. :-)
<agoliveira> Bye all and thanks for attending. I *reallY need a break.
* kwwii is off to bed, night all
<mubelacker> thanks, and have a good night 
<lucasr> Mithrandir, :-)
<lucasr> Mithrandir, a good reference: http://maemo.org/community/wiki/hildondesktoppluginhowto
<Mithrandir> lucasr: ah, great.  I'll read that after some sleep.
<Mithrandir> see you guys around tomorrow.
<lucasr> night all
<ian_brasil> tchau
#ubuntu-mobile 2007-06-08
<jonnylamb> There are two branches for each maemo module on Launchpad, "ubuntu" and "trunk". Am I right in thinking that trunk is automatically merged with each svn commit on the maemo.org end; and the ubuntu branch is simply a branch of trunk, for the purpose of cleaning up the package for Ubuntu?
<Mithrandir> jonnylamb: that is correct.
<Mithrandir> the trunk is an import of svn to bzr
<jonnylamb> Mithrandir: Thanks.
<jonnylamb> Why do you do that though?
<jonnylamb> Why are you taking each commit?
<jonnylamb> Why not just use the releases?
<Mithrandir> because preserving history is important
<Mithrandir> and working without the support from a revision control system is horrible
<jonnylamb> Oh I think I understand now. You're merging in changes only when a release comes out? Only this way, the bzr history is lovely and full of changes made to maemo svn?
<jonnylamb> I was "worried" you were packaging and _releasing_ stuff that was trunk material, i.e. not necesserily stable.
<mdz> jonnylamb: we are packaging trunk in many cases, yes
<mdz> jonnylamb: but we are not releasing until October
<jonnylamb> Is the reason of using this vcs-imports method to keep history even on the stage.maemo.org side? As in keeping track of all their commits?
<mdz> jonnylamb: it's so that we can maintain our own distributed branches
<mdz> it's like being able to work inside svn, but without requiring accounts etc.
<mdz> so we have all the benefits of revision control but the flexibility of decentralization
<lool> Hi there
<lool> I'm sorry I couldn't attend the meeting, I would have loved offering my help on a couple of things such as Gtk bits
<lool> I discussed some implementation details with seb128 and other folks
<lool> Hmm I see agoliveira already found about g_key_file_free() instead of g_free()
<Mithrandir> yeah, he did
<Mithrandir> according to a mail he sent me yesterday, the theme builder now works
* Mithrandir pulls out his hair over hildon-fm.
<Mithrandir> oh, docs, why do you hate me so?
<tko_> gtk-doc problems?
<Mithrandir> make run in the top level directory doesn't run make docs
<Mithrandir> which makes dh_install quite unhappy.
<tko_> I thought I hacked my way around that
<tko_> hmm, no, I did the hack in hildon-1
<lool> Mithrandir: I simply passed --disable-gtk-doc here  O:-)
<Mithrandir> lool: I made debian/rules call make doc too
<Mithrandir> hm, why is the --disable-gtk-doc there?  That might explain it
<tko_> because we don't have recent enough gtk-doc
<Mithrandir> but we do
<lool> --disable-gtk-doc instructs to not build doc at make time, but disted tarball should use --enable-gtk-doc and ship the pre-built docs
<lool> You don't want to build the doc on each build, except if you're running autogen
<Mithrandir> hmm
<Mithrandir> shouldn't just the normal make rules govern that?
<lool> Not sure what you mean
<lool> Hmm where's the gtkdocize call in autogen?
<Mithrandir> why is this a configure flag rather than just having a rule in the Makefile that rebuilds the docs if the sources have changed?
<Mithrandir> no gtkdocize call there
<lool> Mithrandir: There's such a rule _if_ you pass --enable-gtk-doc I think
<Mithrandir> oh, ok.
<Mithrandir> then I think passing --enable-gtk-doc should be fine.
<lool> Well, only if you autogen
<Mithrandir> -fm does that automatically at first.
<lool> If you don't want to autogen, you should prebuild the docs oo
<Mithrandir> why shouldn't they be built as part of the package?
<lool> The gtk-doc rules are using autotools convention which suggest that they should be make disted
<lool> For example, dist-hook, maintainer-clean-local, etc.
<Mithrandir> we can change it later if we think that makes sense; I'll just pass --enable-gtk-doc for now.
<lool> It's a choice the gtk-doc developers made that their gtk-doc.make will help you _produce tarballs_ with doc, but not produce tarballs which build doc
<lool> Mithrandir: Ok, but be aware that it wont possibly clean properly
<Mithrandir> true, make distclean doesn't clean it.
<lool> Exactly
<Mithrandir> but the package builds that way, which I think is more important.
<lool> I would personally call autogen.sh in this case
<lool> But right, the important thing is to get forward :)
<Mithrandir> I'm tempted to say "this wouldn't be a problem if we had proper upstream releases", something I'm confident will happen sometime soonish.
<lool> I concur fully
<lool> Exactly like striping the debian/ out is currently a pain because I'm using non-native mode; this will disappear with upstream tarball releases
<lool> I wonder why it build for me here though
<lool> Haha, I passed --enabled-gtk-doc :)
<lool> Do like I say, not like I do
<Mithrandir> haha. :-)
<lool> Ah I recall why now; this debian/rules did not have a special autogen.sh section
<Mithrandir> config.status: if [ ! -x configure ] ; then ./autogen.sh; fi
<Mithrandir> with a newline after the first :
<lool> Yeah, but no "configure" rule lke some others
<lool> with flags passed to autogen.sh
<Mithrandir> ah, point.
* Mithrandir sighs over hildon-fm-l10n-mr and friends.
<Mithrandir> tko_: is there any reason not to let hildon-fm depend on hildon-fm-l10n with a specific version number rather than using the mr / mr0 /mrX approach?
<tko_> I don't recall the details why the packaging was done the way it was. presumably because depending on virtual package doesn't install any concrete one
<Mithrandir> which is why you'd have something like Depends: hildon-fm-l10n-english | hildon-fm-l10n and have all the different hildon-fm-l10n-XX packages provide the former.
<Mithrandir> the former = hildon-fm-l10n in this case
<Mithrandir> dpkg-deb: Bygger pakken libhildondesktop0 i ../libhildondesktop0_0.0.14-2ubuntu2_i386.deb.
<Mithrandir> \o/
<mdz> Mithrandir: !
<Mithrandir> no idea if it installs yet, but we're getting there.
<bintut> what filesystem do you use for the upcoming ubuntu-mobile?
<tko> btw, I just realized I've been doing tarball releases of sapwood since the beginning..
<tko> it is causing me some extra pain :)
<lool> tko: Do you know how the move to gnome.org is going?
<tko> http://live.gnome.org/Hildon/MigrationToGnome
<lool> Great; looks good
<tko> basically the order was 1) accounts, 2) svn, 3) bugzilla
<lool> I see
<tko> once we have svn enabled on gnome side, we still need to get svn dump from our side and also get a hole in the firewall
<lool> I wonder how the vcs-import switch will happen; promises some fun :)
<lool> tko: Ah for SSH I suppose
<tko> oh right, and then we're waiting for jdub to set up hildon mailing list
<tko> yep
<tko> our firewall is a bit paranoid
<inz> slight understatement ;)
<jonnylamb> May I ask /why/ you're moving to gnome.org?
<tko> we want to make hildon less strongly tied with nokia and run it as a true upstream project
<tko> btw, who's coming to CA next week? me and moises could use a ride
<lool> tko: Is there an IRC chan where mdk is around?
<lool> tko: Or perhaps you can fix the weird "AC_ARG_ENABLE " alone on line 117 of libhildon/hildon-1?
<tko> lool: I suppose he'd be here or #maemo when he's online, but I'll try fixing it (don't have a checkout here)
<lool> tko: Ok, I've fired bugzilla now; want a bug?
<tko> lool: give me a minute to finish the checkout..
<lool> tko: Right, I see him in the backlog now; thanks
<lool> Is there a way to tell the SVN rev from the bzr rev?
<lool> This is how bzr log looks: http://paste.debian.net/29986
<tko> lool: that would be r11820 but I don't know how you'd get it
<tko> bzr-svn maybe?
<lool> bzr-svn hung for me when I tried importing haf's SVN; after taking some 1.5 GB RAM + swap, it encountered some incomprehensible error
<lool> So I've given up there :-/
<lool> tko: I wish it would be visible in the log just like in git-svn
<tko> git-svn had no problems with gtk :)
<lool> hehe
<tko> (our gtk.. I didn't feel like waiting to mirror the whole upstream)
<lool> bzr-svn is supposedly transparently integrated, and I have it installed and didn't see anything in the log
<lool> (You're supposed to use bzr "normally", for example "bzr branch svn://...")
<lool> bzr viz is quite nice
<jonnylamb> Certainly is!
<jonnylamb> Is there anything like this for git?! :D
<lool> gitk I guess
<lool> It's cute too; too bad it's not in Gtk
<inz> How can they name it gitk, if it's not Gtk?-)
<lool> It's in tk :)
<tko> lool: committed
<jonnylamb> gitk looks damn ugly, but it does the job.
<inz> lool, uh, then I guess it's acceptible ;)
<lool> tko: thanks!
<lool> tko: I'll file a bug directly next time; it's WE after all :)  I was mostly curious as to whether you were using a private IRC channel, but seems not
<tko> lool: if we were it would be somewhere in the intranet :)
<tko> remember, we're only moving towards being an upstream project :)
<Knowledge_> Ubutu Mobile + n800 = dream machine...
<Knowledge_> if the mobile version is anything like the desktop version...
<tko> Knowledge_: what is lacking in the software shipped with n800 ?
<Knowledge_> tko: honestly nothing, I love it...I just like modding stuff....
<tko> :)
<Knowledge_> I'm not one of those "ohhh the 770/n800 are so terrible because I can't run apache on it"....yadda yadda...I bought it because of what it was advertised to do...and it does that flawlessly....
<tko> there's always hex editor.. :-P
<tko> I thought someone already ported apache.. or some other web server atleast (forgot the name)
<Knowledge_> oh...well you get what I mean...there's people on the iTt forums that whine and whine cause the device doesn't suck their....well, I'm pretty sure you know what I'm getting at
<tko> yeah, I know
<Knowledge_> I love the device...
<Knowledge_> barely use it and it's still the best $400 I've ever spent
<lool> tko: lighthttpd perhaps
<lool> or lighttpd either
<tko> lool: no, it was some other indian IIRC
<tko> cherokee
<lool> Ah right
<lool> I was thinking about a project hosted in India
<jonnylamb> What does "mce" stand for?
<jonnylamb> Forgive me, "Mode Control Entity". However, I'm a little unsure on what it is/it does ?
<jonnylamb> It seems to be mentioned, but not documented here: https://lists.ubuntu.com/archives/ubuntu-mobile/2007-May/000098.html
#ubuntu-mobile 2007-06-09
<tko> who's coming to google this monday? I'd like to hitch a ride for two from wild palms if possible
<admin_> Anyone have any idea how much the UME will cost?
<admin___> Anyone have any idea how much the UME will cost?
#ubuntu-mobile 2007-06-10
<alienseer23> Hello, can anyone tell me a good place to go for installing Linux onto a Palm TX??
#ubuntu-mobile 2008-06-02
<persia> good morning
<davidm> good morning
<emgent> morning
<dholbach> good morning
<emgent> morning dholbach :)
<dholbach> hi emgent
<asac> bah, moblin admins dont like my new ssh keys :(
<persia> mterry: On the other hand, having an update so cheese didn't crash in hardy for the PPA would be great :)
<mterry> persia: The UME PPA?
<persia> mterry: I believe so, unless someone says that it's frozen for release.
<persia> My understanding is that it's still collecting fixes for the Ubuntu-Mobile Hardy release.
<persia> So, for Ubuntu-Desktop, there's no need to push an update, as it's hard to break.
<persia> For Ubuntu-Mobile it always crashes, which isn't ideal.
<persia> Of course, I may be mistaken, and would welcome correction in that case :)
<lool> persia: He can probably push via hardy-updates anyway
<lool> Which would benefit everybody, not just UME
<persia> lool: Do you think the SRU team will approve?  I'm good if you do, I just think it might be harder.
<lool> Just like that libsdl-mixer1.2 dep fix I prepared
<lool> persia: I know SRU requirements have been relaxed for GNOME 2.22.2
<lool> And it's part of GNOME 2.22.2
<persia> lool: OK.
<lool> So the additional patch to fix the crash seems fine to push at the same time, even if it's not in 2.22.2
<persia> mterry: My apologies.  lool is very likely more correct.
<mterry> lool, persia: OK, so I provided a debdiff against hardy.  Do I now add the appropriate ubuntu-main-sponsor?
<lool> persia: BTW I discussed relaxed SRU rules for mobile stuff too, and the conclusion was that we're welcome to push UME stuff via SRUs of hardy packages /if/ there's already a regular SRU in the pipe for them: this ensures that we get double testing for such updates
 * mterry reads https://wiki.ubuntu.com/StableReleaseUpdates
<lool> mterry: Yes; did you also prepare 2.22.2 at the same time, or just added the patch?
<persia> mterry: You'll also need to provide a Test Case in the bug description for verification.  Personally, I'd suggest subscribing ubuntu-sru first to get an ack before you seek a sponsor.
<mterry> lool: I just added the patch
<persia> mterry: You might want to batch it up with other stuff if we're trying to mask it under the general 2.22.2 update :)
<lool> mterry: I think it's safest to ask seb128 for guidance; he has been doing the GNOME 2.22.2 uploads, and is likely to ultimately tell you how to best proceed
<lool> He'll probably push cheese back at me as I sponsored the latest uploads
<mterry> persia: :)
<lool> mterry: Would be best to prepare a 2.22.2 + patch SRU instead of preparing two SRUs
<mterry> lool: k
<lool> A SRU just for the about dialog in hildon is a bit much perhaps
<lool> Oh like persia just said; ignore me
<persia> That was why I was thinking it was a PPA candidate fix :)
<lool> Indeed
<ogra> yay, another channel :)
<asac> welcome ogra :)
<ogra> :)
<lool> GrueMaster: Could you enable hardy-proposed on a target device and verify you're happy with the libsdl-mixer1.2 update which adds the libvorvisfile3 dep?
<lool> GrueMaster: If you're happy, comment on the bug as to allow the proposed update to enter official updates
<GrueMaster> Ok.  How should I do this?  I have RC1 installed, should I do an update?
<GrueMaster> Or build a new image?
<lool> mterry: Concerning LP #223697: this is technically a bug in UME; your proposed fix to add a package to a fset is not the way we usually add packages to UME: instead we prefer listing them in so called seeds
<mterry> lool: seeds, ok.  How is that controlled?
<lool> mterry: At this point of the release cycle, I'm not sure we should take the risk to add too much to the seed, but if you're confident with the fix, we could do it
<mterry> lool: I'm confident
<lool> mterry: The seed we used is in bzr, lp:~ubunt-mobile/ubuntu-seeds/mobile.hardy; you technically have write access there if you're in the u-m team, but you might want to touch base with StevenK if this might end up pulling many packages
<lool> mterry: I'm confident that this will fix the bug too, what I'm less confortable with is: by how much will the images increase?  and is yelp nice enough to run in UME?
<lool> GrueMaster: You may simply enable the repo, apt-get update, apt-get upgrade
<mterry> lool: apt-get said 15M more
<lool> GrueMaster: or use update-manager
<GrueMaster> ok
<lool> mterry: 15 MB is significant, it might be a problem for your customer as well
<mterry> lool: Regarding if yelp is nice enough to run in UME, anything is arguably better than Help->Contents silently failing or giving an error message
<mterry> I suppose we could take out the Help buttons  :)
<lool> Well we could remove the help link too :)
<lool> Yes :)
<GrueMaster> lool:  where's the update manager?  I don't think it was in the RC.
<lool> GrueMaster: It might have been added just after RC indeed; you should get it by updating too then
<GrueMaster> hmmm.  No results from apt-get update;apt-get upgrade on RC1.
<GrueMaster> Let me clean install.
<lool> Oh hold on, RC1 is against snapshots, not snapshots+ppa
<lool> GrueMaster: Add the hardy-proposed repo to your sources.list from ports.ubuntu.com and you should get the libsdl-mixer1.2 update
<lool> For update-manager, add the ppa to your sources.list
<mterry> kyleN: Do we have a plan for translating application help files for acton?
<kyleN> mterry: no
<mterry> kyleN: Is it something we need to do, or did we want to disable Help buttons in the UI?
<GrueMaster> ok.  hold a sec.  Refreshing base image (reformatting sda2).
<kyleN> mterry: shall we discuss acton elsewhere?
<mterry> kyleN: OK :)
<StevenK> GrueMaster: You don't need to clean install
<StevenK> GrueMaster: RC1 is built against the snapshot, so it won't see new packages. Change the sources.list and related files, and upgrade
<GrueMaster> Actually, I do, as I had other stuff (including libvorbisfile) installed.
<GrueMaster> Doing that now.
<StevenK> Well, okay
<StevenK> In any case, I really need sleep.
<lool> StevenK: 'night
<GrueMaster> night, StevenK.  Thanks.
<asac> anyone can test that mobile-basic flash still works with latest hardy-proposed packages? need that to verify the libnss update bug
<asac> (i doubt that its broken, but mobile-basic-flash is rdepends of libxul0d which is rdepends of libnss3-1d
<asac> )
<asac> thanks!
<GrueMaster> lool: ping - not sure how best to test the sdl-mixer fix.  I've tried replacing the /etc/apt/sources.list* files with a daily ppa build set and running apt-get update;apt-get upgrade, but nothing shows up.  I also added hardy-proposed, and now I get libsdl-mixer1.2 is held back.
<lool> GrueMaster: apt-cache policy libsdl-mixer1.2?
<lool> (paste.ubuntu.com)
<lool> GrueMaster: What you want is adding something like this somewhere in your sources.list:
<lool> # hardy-proposed
<lool> Then apt-get update
<lool> deb http://archive.ubuntu.com/ubuntu/ hardy-proposed main restricted
<lool> apt-cache policy libsdl-mixer1.2 should then list a 1.2.8-1ubuntu0.1 version
<GrueMaster> yes, I have that.
<lool> Ok "apt-get install libsdl-mixer1.2"
<lool> Should install this new package and only that
<lool> (well and it should pull libvorbisfile)
<GrueMaster> http://paste.ubuntu.com/16435
<lool> What happens with the apt-get install libsdl-mixer1.2?
<GrueMaster> yes, that works.
<GrueMaster> It pulls libvorbisfile3.
<lool> GrueMaster: So I think this should be enough to consider your bug fixed; do you agree?  Could you comment that the package in -proposed fixed the bug for you?
<GrueMaster> Question:  Is there a way to find out what else depends on libvorbisfile3?  It is installed on my Hardy desktop system.
<lool> GrueMaster: apt-cache rdepends libvorbisfile3
<GrueMaster> ok
<GrueMaster> I think I'm starting to understand.  We're just adding another dependency listing.
<GrueMaster> Launchpad updated.  Thanks.
<lool> GrueMaster: Will migrade from -proposed to -updates after 10 days in -proposed now that you confirmed it
<GrueMaster> ok.  That will miss the RC2 target, though (I think).
<lool> Yes
<lool> But will appear as a stable update
<GrueMaster> ok
<mterry> tremolux: What do you use to edit the gtkbuilder files in cheese?  some version of glade-3?
<lool> asac: I see you uploaded a lanpack to the ppa; how do these work?  I only see one of them, but I guess we need one per language?
<tremolux> mterry: I didn't need to edit the gtkbuilder files actually
<asac> lool: that was a urgency langpack
<asac> lool: we should integrate it in langpack-o-matic so every locale available gets shipped in -gnome
<mterry> asac: I have a change for midbrowser I'd like you to look at.  Can you check out LP #223891?
<emgent> heya
<GrueMaster> Just out of curiosity, is googleearth available in any of the ubuntu repositories?
#ubuntu-mobile 2008-06-03
<asac> lool: how can we roll -updates for diverged packages to hardy PPA?
<asac> do we need some official staging area to get some QA first?
<persia> good morning
<dholbach> good morning
<lool> asac: The staging area is going to be the ppa
<lool> asac: And we will then promote updates to the mobile archive
<persia> lool: I'm looking at bugs 215842 and 218251.  In the latter, you recommend against my solution for the former.
<persia> Are you sure we don't want a conffile for that?  I prefer conffiles as they can be purged, whereas maintainer-script generated files tend to stick around...
<lool> persia: hahaha, I was a good guy one month ago
<lool> persia: That comment was just to make sure that /etc/default/locale shouldn't be in a package
<lool> And I was bitten by this no longer than two days ago, because it's shipped in ume-config-common
<persia> Is it now?  Then why is the bug with my patch still open?  If that patch was applied, it ought be closed.
<lool> persia: if you run simple-vm-builder, it will hand waiting for a merge during the vm creation
<lool> dpkg -L ume-config-common| grep locale
<lool> /etc/default/locale
<lool>   * Add a default locale for builds to support UTF8, etc. Patch by Emmet
<lool>     Hikory.
<lool>  -- Steve Kowalik <stevenk@ubuntu.com>  Thu, 29 May 2008 18:20:32 +1000
<persia> That's why I don't understand why 215842 is still open.  That's from where the patch comes.
<lool> Probably an omission
<lool> persia: Would you like to fix shipping of /etc/default/locale?
<lool> What should happen is more something in the postinst like: if /etc/default/locale exists and sets a locale, leave it alone, otherwise create or set the locale
<persia> lool: Actually, I prefer it as a conffile: I just encountered your recommendation against it being a conffile, and thought it might be worth discussing in case we want to change it before we ship.
<persia> OK.  How do we unset the locale later then?
<persia> (on package removal)?
<lool> persia: It can't be handled like a conffile in UME and not anywhere else
<lool> persia: Not sure whether we want to unset the locale
<persia> OK.  I can see the case for not unsetting it.  I'll push a fresh config with maintainer-script handling then.
<lool> thanks
<lool> persia: And if you like, you can verify that it breaks e.g. simple-vm-builder if you're not convinced about not shipping it as a conffile?
<lool> It would also break if you'd install ume-config-common on e.g. a regular system
<persia> It oughtn't break, just cause conffile-collision handling.
<lool> Yes; but it's supposed to provide either defaults or overrides, not change the way a file is handled  :-/
<persia> lool: Right.  I'll fix it in the next hours :)
<lool> Ultimately, I suppose we're missing an "install" step where such a file would be created, just like /etc/hosts; this could be done with the current install.sh hacks
<persia> Do you think that is better than in ume-config-common?
<StevenK> Personally, I think ume-config-common is a bad idea, and stuff it does should be handled on install
<persia> (You say "ultimately", but I read it as "before this upcoming release")
<persia> Let's do it on install then.  Where do we need to stuff the hook?
<lool> persia: I meant in a future cycle / world
<lool> persia: Doing it on install would mean rerolling a MIC; we could do it as it's still planned to move to the new sources.list
<persia> lool: Right.  My worry is that if we do it wrong now, we're somewhat stuck.  There's no purge part during the upgrade, and unmarking conffiles is an ugly hack.
<persia> StevenK: How are we on rerolling a MIC?
<lool> Yes, I agree it's ugly to fix this later on
<lool> persia: If you do it in install.sh, be careful that it might busybox sh
<lool> I think u-v-b has a good shell snippet of what's needed, but it might need to happen at the end of install
 * persia needs guidance on where to put stuff for install.sh, but isn't worried about busybox vs. bash
<lool> persia: Grab MIC
<lool> platforms/common-apt has the initramfs stuff
<persia> Right.  MIC.  Thanks.
<lool> install.sh is called from platforms/common-apt/initramfs/usb and /cd if present in the initramfs
<ogra> persia, /etc/default/locale gets rewritten by gui tools on locale changes
<ogra> a conffile wouldnt be clever here
<persia> ogra: Right, which is why it is being removed :)  On the other hand, those GUI tools aren't in UME right now (see bug 218251)
<ogra> but they might be in the future 
<persia> -ENOBUGBOT https://bugs.launchpad.net/ubuntu-mobile/+bug/218251
<persia> ogra: Right.
<ogra> i.e. in a netbook image there should be as many desktop tolls from the defaut install as possible imho ... else we have to maintain everything twice
<ogra> *tools
<persia> ogra: Which reminds me, have you put together a meta for your netbook interface idea?
<ogra> i.e. we should at least use the same backends ....
<lool> persia: The GUI tool is in customer builds though
 * persia wants to test on the Kohjinsha, as neither Mobile nor Ubuntu is a good fit
<ogra> well, the meta is ubuntu-desktop ... i need to put together a theme and gconf settings 
<ogra> the app selection is 100% ubuntu-desktop yet
<persia> ogra: Just gconf settings?  That's enough to change the interface?  Nothing new is required?
<ogra> ah, well, devilspie to make metacity behave like matchbox ... and a two line devilspie config 
<ogra> and one little script hack to get the close button in the panel 
<ogra> ut the rest is gnome ui changes
<ogra> *but
 * persia imagines a seed depending on Ubuntu-Desktop and containing a single -settings package
<ogra> well, -sessings and -theme 
<ogra> nd yes, that was exctly the idea :)
<ogra> find the apps in ubuntu that misbehave and add proper gconf keys .... and have the world fixed in one go :)
<davmor2> Guys just to let you know the KVM version of RC1 is more reliable than the mic version
<persia> Does anyone have a ume-config-common-0.12-1-0ubuntu0 source package?
<ogra> no desktop app maintenance apart from the fixes and patches which might even be able to go upstream
<persia> Upstream is good :)
<ogra> :)
<StevenK> persia: I have it locally, I think
<persia> StevenK: Did it exist anywhere else?  Can we get it back, or do we need to push -2?  (Assuming that few people are expecting continuous upgrade to work at this point)
<lool> persia: -0ubuntu0?
<persia> lool: The PPA gave me a diff file exactly matching that which I want to revert against -0ubuntu0
<lool> persia: The PPA has indeed
<lool> https://launchpad.net/~ubuntu-mobile/+archive?field.name_filter=ume-config-common&field.status_filter=any
<lool> (0.12-1-0ubuntu0)
<persia> Aha!  Now, to delete the new one (and save uploading a paper bag)...
<StevenK> Hah
<StevenK> persia: So you don't need me to find it?
<persia> StevenK: Nope.  lool knows LP well enough to save us both the effort :)
<StevenK> persia: Heh, fine
<persia> The PPA archive-admin stuff isn't so bad, really.
<cprov-lunch> persia: ehe, I will take it as a compliment ;)
 * dholbach hugs cprov-lunch
<persia> cprov-lunch: If you're responsible, you ought :)
<lool> persia: cprov-lunch beeps on "ppa", guess how responsible he is :)
 * persia ponders the difference for being responsible for a thing and being responsible for creating a thing
 * persia seeks peer review of http://paste.ubuntu.com/16558/ as a solution for /etc/default/locale before committing
<ogra> persia, does that check if the file exists and is pre-set somewhere already ? 
<ogra> (your patch doesnt seem to)
<asac> lool: are you on amd64?
<persia> ogra: Nope.  This is run on the initialisation of the filesystem, prior to any packages.
<ogra> ah
<persia> Is that safe?
<ogra> looks fine imho 
<ogra> well, thats what i do in all my chroots as well ... does it run locale-gen soewhere with the matchng value ? 
<ogra> (it wont be pregenerated nowadays)
<persia> Hrm.  I'll have to look for that.  In previous testing, the mere existence of /etc/default/locale was enough to make most applications behave (as in use UTF8 rather than POSIX)
<ogra> i'm not sure which package does the locale-gen today ... it used t be done in the locale package, then moved to language packs but might be in language-support now which you likely dont want in default mobile as it pulls in tons of extra stuff you dont need
<persia> ogra: Yeah.  I think I'll just stuff in this file for now, as I believe pushing it at filesystem-creation time is better than pushing it at ume-common-config time, and has fewer negative implications.
<persia> Tracking down locale-gen can be done another day.
<ogra> yeah
<cprov-lunch> persia: thanks (and yes, I try to be responsible in both sense)
<lool> asac: I have an amd64 box
<asac> lool: ok, then the libflashsupport problem is not that bad (referring to mail)
<lool> asac: ogra questionned by 64-bits use as well
<ogra> asac, what makes me curious is that lool says it works fine on debian with the debian version
<ogra> (32 bit here)
<asac> no pulse?
<asac> debian version of what?
<ogra> libflashsupport withour pulse ? would that make sense ? 
<ogra> libflashsupport
<ogra> <lool> ogra: I'm using a custom install of libflashsupport on Debian/i386 (1.0~2219-1) and 1.9-0ubuntu1 on Ubuntu/amd64
<ogra> from -devel ^^^
<asac> lool: a custom install?
<asac> can you post the build config for that please?
<asac> lool: what kind of system spec does the debian system you test on have?
<lool> (hold on, phone)
<ian_brasil> i am trying to add an icon to the grid desktop and the info on https://help.ubuntu.com/community/UMEGuide/ApplicationDevelopment/AddingIconToDesktop does not seem to work
<ian_brasil> any ideas?
<persia> ian_brasil: Did you add OnlyShowIn=GNOME;Mobile; ?
<ian_brasil> no...where do i add this?
<StevenK> In the .desktop file
<persia> In the ,desktop file.
<ian_brasil> ah ok
<persia> Also, I'd recommend just putting it in /usr/share/applications, unless you have a good reason to do otherwise.
<persia> Ubuntu Mobile no longer only looks in /usr/share/mobile-basic-flash/applications/
<ian_brasil> ok..i will update the wiki 
<persia> ian_brasil: Thanks.
<ian_brasil> so it looks in /usr/share/application first ..then /usr/share/mobile-basic-flash/applications ...then anywaher else?
<StevenK> It looks in /usr/share/applications only
<persia> (and subdirectories thereof)
<lool> asac: I'm using the universe flashsupport on Ubuntu/amd64
<lool> The custom install probably comes from the website of flashsupport for the Debian install
<asac> lool: ok. we should figure their build config then. what version?
<lool> 1.0~2219-1
<ogra> is that packaged already ? 
<ogra> (in the archive i mean)
<lool> Yes, not the smae version
<ogra> it wasnt even in experimental and not clear if it would go in when i looked last time
<lool> On Ubuntu, I have 1.9-0ubuntu1
<ogra> and it ships a hard openssl dep iirc
<lool> libflashsupport | 1.9-0ubuntu2 | intrepid/universe | source, amd64, i386
<ogra> right
<ogra> the code should be identical though ... both pulled from pulse git which didnt change since a year or so
<asac> lool: where did you get that custom package from?
<ogra> there is an alioth repo
<lool> However there's also a new flashplugin-nonfree-extrasound
<lool> Sorry, I mean flashplugin-nonfree-pulse for pulse
<ogra> yeah, seems they renamed it
<lool> It's split actually
<lool> I can't find flashplugin-nonfree-pulse though; only flashplugin-nonfree-extrasound which refers to it
<asac> lool: how do you test?
<ogra> http://git.debian.org/?p=pkg-pulseaudio/flashplugin-nonfree-pulse.git
<asac> lool: the test case is going back and forward on youtube until flash/firefox crashes (if you dont have nspluginwrapper)
<lool> asac: Nothing in particular, I open flash videos
<asac> lool: well. try the case above
<asac> go to youtube video, wait for movie to start, go to new youtube video, wait for start, go back + wait, go forward + wait
<asac> if you dont have nspluginwrapper in between + you are sure libflashsupport is loaded (e.g. strace) and you are sure that pulse is actually used by flash, then we might have a fix :)
<ogra> i wonder how that should have magically appeared though
<lool> asac: how many times?
<asac> remember that crimsum uploaded some workaround/fixes to intrepid. maybe those are already in debian now.
<ogra> lookig at that git repo there are no changes to lennarts code at all
<ogra> asac, that was to get rid of the fixed openssl dep ....
<asac> lool: no idea. i never made it to 10 retries
<ogra> nothing that would affect non encrypted playback
<lool> I see flashplayer in pavucontrol
<asac> lool: but the slower your sytem is the less likely you will hit the deadlock
<asac> ogra: well ... crimsun also claims that he fixed the crashes in his upload
<lool> I certainly crash my system from time to time on flash videos
<ogra> asac, oh
<lool> my browser I mean
<asac> ogra: i pinged him multiple times for the last two week to get input on what he did, but he closed all bugs
<asac> never got a reply though
<ogra> hmm
<asac> lool: try the testcase above ... if that doesnt crash your browser then its a good sign
<asac> ogra: remember that crimsun had a fix for it in hardy on also side, however that wasn't regression free.
<asac> maybe he uploaded to intrepid in the hope that those can be fixed during cycle
<ogra> the upload i see in intrepid only changes one dep
<asac> s/also side/alsa side/
<ogra> * debian/control:  Conflict with flashplugin-nonfree versions older
<ogra>      than intrepid's while allowing for backports (LP: #192888).
<asac> ogra: yes, but i think that he uploaded other packages in that batch
<ogra>    * New upstream beta fixes many crashers (most significantly
<ogra>      LP: #192888).
<ogra> flash itself
<asac> yeah ... i could reproduce the crashes with flash 10 ... the version i tried at UDS
<asac> so that alone cant be it ... unless the current upload is more recent and indeed fixes things
<asac> lool: using flash 10 from intrepid?
<lool> No
<asac> and zero crashes?
<lool> 9.0.124.0ubuntu2
<asac> (when doing the test?)
<lool> Certainly not zero crashes in general, but I've hit a least 8 times back/forward in youtube now
<lool> On the same video
<asac> not that bad
<lool> Note: one of my CPU is at 100%; it's a fast system, but could behave like a slow system in this case
<asac> lool: can you reproduce the crashes on ubuntu? maybe respin the debian libflashsupport on ubuntu?
<asac> lool: building?
<lool> Not building, just playing the video
<lool> It's the same on both computers since forever with flash
<asac> sure you are using flashplugin nonfree?
<asac> strnage
<lool> I got a crash the very first time I connected to youtube today, but since that...
<ian_brasil> is there some way to turn icons on or off?...like i want cheese icon to appear in gnome but not in hildon
<persia> ian_brasil: The OnlyShowIn key is the best mechanism to control that.
<ogra> but will switch the item on/off completely
<persia> ogra: Selectively, so you can show or not show in e.g. GNOME or Hildon
<ogra> the xdg spec could need an addition
<lool> asac: [pid 21542] open("/usr/lib/flashplugin-nonfree/libflashplayer.so", O_RDONLY) = 3
<lool> [pid 21542] open("/usr/lib32/libflashsupport.so", O_RDONLY) = 35
<ogra> persia, yes, but ian_brasil wants to switch visibility of the icon without losing the entry i guess
<ian_brasil> right
<asac> lool: looks like nspluginwrapper?
<ogra> the xdg spec doesnt provde such a feature
<persia> Hrm?  How is a menu supposed to show an invisible icon?
<asac> that will guard you from crashes
<asac> lool: check whether npviewer is running while playing flash
<ogra> it will falll back to the default icon in gnome 
<ogra> not sure hildon has such stuff
<persia> ian_brasil: Could you summarise this use case?  I'm fairly familiar with the specs, but a little tired now...
<ian_brasil> ok...i will mail the list
<lool> asac: Hmm pavucontrol is failing on the amd64 box; probably due to old pa env vars, but new pa running
<lool> asac: Oh you mean I should remove nspluginwrapper?
<asac> lool: well ... if nspluginwrapper is used you wont see the crashes ;)
<asac> so on 64-bit its not an issue for us
<asac> not sure about debian, but if you ar e on 64-bit there too then you wont see the bug
<ogra> and on i386 we'll catch it the same way in intrepid :)
<lool> I'm on i386 on Debian
<asac> hopefully
<asac> lool: maybe debian has nspluginwrapper on i386?
<lool> So I'm sorry guys, I'm a bit lost in what you wanted me to test
<ogra> flash without nspluginwrapper on a ubuntu system using pulse :)
<lool> I just know I have been using libflashsupport (heck, I even hacked it for my previous job to make flash decode audio for us :-) but what crashes other people I don't know
<ogra> preferably i386
<lool> Ok; I tested that on Debian only
<ogra> right, if debian doesnt use nspluginwrapper that sounds  like a fix for us ...
<asac> lool: i just wanted to know whether you have nspluginwrapper on your debian install
<ogra> but we dont seem to differ in code at all
<ogra> which is weird
<lool> I don't have nspluginwrapper on my Debian install
<asac> because its strange that you dont see the crash
<asac> lool: but you installed flashplugin-nonfree from somewhere ... maybe that includes nspluginwrapper?
<asac> if no npviewer is running then you probably dont use it. and we should see why you dont get issues
<lool> On Debian [pid 27823] open("/usr/lib/flashplugin-nonfree/libflashplayer.so", O_RDONLY) = 60
<lool> [pid 27823] open("/usr/lib/libflashsupport.so", O_RDONLY) = 50
<asac> lool: you have a link to the debian source package you use?
<lool> I don't see any process with np
<asac> k
<lool> I use libflashsupport (1.0~2219-1) unstable; urgency=low
<lool>  -- CJ van den Berg <cj@vdbonline.com>  Tue, 28 Nov 2006 12:29:54 +0100
<lool> I think I got it there http://pulseaudio.revolutionlinux.com/PulseAudio
<lool> Ah http://pulseaudio.vdbonline.net/libflashsupport/ dropped
<lool> http://pulseaudio.vdbonline.net/ has flashplugin-nonfree-pulse_0.1~000.dsc
<asac> hmm
<asac> i think i am too tired ;)
<lool> I think the pulse impl was rewritten at some point, but IMBW
<ogra> it was
<ogra> by lennart -... back when he still was DD 
<ogra> but he didnt touch it since
<lool> He isn't DD anymore?
<ogra> and now he works for RH keeping him busy with other stuff 
<ogra> he still is, but makes no use of it
<davmor2> pulse and avahi if I remember correctly isn't it ogra
<ogra> thats what he did in debian, yes
<ogra> now he works for RH, does rpm's and doesnt care much about debian packaging anymore
<ogra> we talked a bunch in prague 
<davmor2> :(
<ian_brasil> this is intersting -> cheese does not have OnlyShowIn but it appears in hildon ...others also do not have OnlyShowIn and do not appear..seems like some default list
<ogra> ian_brasil, its always more than just the .desktop files, the .menu files have impact as well on what is shown and what not
<persia> ogra: There's a bit of a specialty implementation for Ubuntu Mobile...
<ogra> i.e. if you disable an item in alacrate in ubuntus normal desktop it wont change the NoDisplay value of the .,desktop file but add a ~/.local/menus/*.menu file ecluding it
<ogra> well, and then there are mobile hacks as well apparently :)
<emgent> heya
<ogra> err, sorry, its ~.config/menus/
<ian_brasil> another queston..i want to write a status panel plugin in python to shutdown the system..this is possible right
<ogra> tricky if you dont use the default desktop ... i.e. dont have a gdm socket to send the signals to
<persia> ian_brasil: For what conceivable reason would you ever want to shut down a MID?  Aside from system crashes, I've never turned off any of mine for the past several years.
<persia> Hibernate is the key, and setting a short sleep timer.
<ogra> or suspend :)
<ogra> have a look at pm-utils for that 
<ogra> pm-hibernate and pm-suspend specifically
<ian_brasil> it is not a MID i am developing for!
<persia> Aha!  In that case, yes, just hook into pm-utils :)
<ogra> well, for shutdown/reboot you either need a DM to do it proper or add evil hacks to sudores or so
<ogra> pm-utils doesnt provide hooks for shutdown/reboot iirc
<ian_brasil> ok thx
<ogra> for gdm you would want: gdm-signal -h or -r
<ogra> assuming you have gdm running with autologin
<ian_brasil> i want to do something like gnome with turn off reboot, suspend, hibernate
<ogra> why not use the gnome one then ? ... 
<ogra> oh, wait you dont use gnome-panel/-session i guess
<ogra> where the dislog is implemented
<ogra> *dialog
<ian_brasil> i am using gdm :)
<ogra> its easy to en/disable features in that dialog through gconf keys andchanges to gdm.conf
<ogra> well, thats a start, try with the gdm-signal command
<ian_brasil> ok
<ogra> it also offers interfaces to suspend/resume i think (calling pm-utils in the backend)
<ian_brasil> gdm-signal does not work..not even with sudo
<ian_brasil> i will reboot and try again
<ian_brasil> gdm-signal does not seem to work...does not return anything
<ogra> hmm
<ogra> i know thats what gnome-session uses internally
<ogra> gnome-session/gdm-logout-action.c and gnome-session/logout.c use it extensively
<ogra> (directly though, not through the gdm-signal binary)
<ian_brasil> i tried with xfce too and that does not work either
<ogra> hmm
<ogra> looks like it doesnt work here either 
<ogra> it comes from powermanagement-interface which isnt really maintained anymore (just as compatibility layer for pm-utils)
<ogra> hmm, strace shows its using wrong strings to send to gdm 
<ogra> http://paste.ubuntu.com/16599/
<ogra> ian_brasil, hey, the trick is to end your session, gdm-signal only queues your comand until the session has ended, then gdm executes it
<ian_brasil> ogra: cool..i'll try that
<ogra> i just found that out by accident when my system suspended while i had only logged out :)
<ailean> guys, can anyone help me choose an ubuntu-friendly smartphone/pda? I'm not overly concerned about running ubuntu/linux ON it (although that would be nice), just to be able to use it with my ubuntu laptop well.
<bspencer> anyone tried to use yelp in UME?
#ubuntu-mobile 2008-06-04
<persia> good morning
<persia> Right.  Native packages should not be versioned as packagename_upstreamversion-placeholder-0ubuntu0
<dholbach> good morning
<lool> Hmm upon kernel upgrade to -18, I had to turn off the device as the graphics wouldn't come up on reboot
<lool> I wonder whether it's specific to this upgrade, or whether it's after a bunch of reboots
<ogra> which graphics exactly ? usplash ? the HW itself ? X after usplash ?
<ogra> (note that the -intel X driver was updates as well very recently, might be related)
<persia> lool: I had that on Tuesday, but today's image brought up graphics fine.
<ogra> the -intel change in -proposed was uploaded on monday
<lool> Could be the -intel update
<rbelem> hi all, I would like write a statusbar plugin in python for ume, but python-hildondesktop is not in ubuntu repositories and ume ppa. Should I use another module or compile python-hildondesktop?
<persia> rbelem: Up to you, really.  If you find python-hildondesktop easier, that might be the way to go.
<rbelem> persia, Is there another way to write statusbar plugins?
<persia> rbelem: Off the top of my head, I'll say there's also bindings for C.  I'm also booting my latest image to see how the current set is doing it.
<ogra> egg.trayicon
<rbelem> nice!
<rbelem> will python-hildondesktop package be added do repository?
<persia> Bah.  The working mouse changed.
<rbelem> :-)
<persia> rbelem: It seems all the statusbar applets in my build are done in C.
<ogra> but if you want python, have a look at that example: http://paste.ubuntu.com/16874/
<rbelem> persia, I saw that in my ume image too :-/
<ogra> (needs egg.trayicon from python-gnome2-extras)
 * persia likes ogra's example, for less hildon and more upstream integration with GNOME
<ogra> its quite trivial to do such icons if they are not applets
<rbelem> ogra, cool!
<rbelem> very simple
<ogra> (but even applets are not that hard if you understand bonobo)
<rbelem> I was seeking for something like that
<suihkulokki> It's perfectly possible to make hildon run without orbit/bonobo
<suihkulokki> That's one of the space savings nokia did
<rbelem> this do not restrict my plugins to hildon
<rbelem> thanks ogra persia 
<ian_brasil> ogra:  [ian_brasil, hey, the trick is to end your session] ...how do i do this in ume?
<ogra> killall x-session-manager would be the evil variant i guess 
 * persia uses Ctrl-Alt-Backspace
<ogra> or pkill better
<ogra> persia, from a script :)
<persia> ogra: Ah.  Right. :)
<asac> lool: so just to confirm: ~ubuntu-mobile PPA is staging, so i can just upload there (hardy) ?
<lool> asac: ATM, it's not yet staging, but if it's release material you should upload there
<lool> asac: It's going to be staging when we move to archive.mobile.ubuntu.com
<asac> lool: i am asking for this xulrunner + midbrowser translations update
<asac> i have to upload there now
<asac> i guess i should upload midbrowser there too (while the other upload goes to -proposed) to not break things
<asac> can you confirm?
<lool> Yes; you can also upload to your ppa if you want to test before releaseing
<ian_brasil> ogra: thx...this works -> pkill -9 hildon-desktop
<ogra> well, it might skip the "save yourself" signal if the session manager sends one 
<ogra> meaning that i.e. midbrowser will start with the restore session dialog since it will think it crashed
<ogra> not sure hildon-desktop has any external switch for that to trigger apps for doing a proper shutdown though
<asac> lool: i dont wnat yet another step
<asac> :)
<asac> ill upload to mobile ... unlikely that it will break much more than the current -proposed upload
<ogra> (in gnome your would do "gnome-session-save --kill --silent" to overcome that btw)
<rbelem> ogra, in the nokia 770 whe the power button is pressed a menu is displayed
<rbelem> and one of options is turn off
<ogra> right, like the gnome-session dialog (if you omit the --silent switch in the above line)
<rbelem> yep, something similar
<rbelem> s/pressed/under pressure/
<rbelem> :-)
<ogra> heh
<bpsew> is there a difference between "ubuntu mobile and embedded" and "ubuntu netbook remix"?
<persia> bpsew: Yes.  They have different selections of software.
<persia> The naming is perhaps confusing, and this is the right place to discuss both.
<persia> "Mobile" is about 4-6" screens, and "Netbook" is about 7-9" screens (some people say 10", but I've seen too many 10" laptops to believe that)
<bpsew> can you name some of the different software?
<persia> bpsew: I'd have to compare the seeds to be sure: I don't have a Netbook install around.  Netbook tends to have more screen area, and so more complicated apps.
<bpsew> ok
<bpsew> i'm asking myself...
<bpsew> will there be three versions of each program (think of pidgin e.g.), one for ubuntu desktop, one for netbook and one for ume?
<dantalizing> hey guys....was trying to install ubuntu-mobile, but xulrunner version is blocking the midbrowser install
<dantalizing> xulrunner-1.9 (1.9~rc1+nobinonly-0ubuntu1~8.04.2) breaks midbrowser (<< 0.3.0rc1) and is installed
<dantalizing> i cant find midbrowser 0.3.0rc1 anywhere
<GrueMaster> StevenK: ping - what's this about an abi change?
<davidm> GrueMaster, -17 -18 and -19 all have ABI changes
<GrueMaster> Is it in any of the repositories yet?
<GrueMaster> And what should I build the psb-kmd modules against for testing and release?
<davidm> GrueMaster, I'm sorting this out now.
<davidm> More soon
<GrueMaster> ok
<ogra> -18 should be in hardy-security already
<ogra> -19 was just approved for building 
<GrueMaster> davidm:  I have -18, and will build for that.  
<davidm> GrueMaster, yes, please build for the -18 release.
<GrueMaster> Done.
<davidm> GrueMaster, thanks
<persia> lool: What else does Software Update need?
<lool> persia: ?
<trip0> what is ubuntu-mobile going to use as it's media player?
#ubuntu-mobile 2008-06-05
<tripzero> what is UME going to do for a gps app?
<dholbach> good morning
<lool> morning
<dholbach> hi lool
<bpsew> morning
<mvo> lool: for ubuntu-mobile image, should I use more than "http://ppa.lp.net/ubuntu-mobile/ubuntu hardy main" and the regular hardy archive on ports.u.c?
<lool> mvo: Hmm theoritically this is pulled if you use a MIC platform
<lool> mvo: If you don't, then you should probably include the ppa; yes
<lool> mvo: Also, we'll move to a different archive soon
<lool> mvo: Technically, the releases we have been doing were not based on ports + ppa, but on a snapshot of these hosted on snapshot.u.c
<theseinfeld> lool when is the plan to move to the new archives?
<mvo> lool:  ok, thanks - I was playing with simple-mobile-builder today again and with davmor2 we fixed some issue, it should be pretty good now. did the release include virtual images too?
 * mvo wonders if it is worth building new ones based on the snapshot.u.c sources.list entries
<davmor2> might be for RC2
 * theseinfeld wonders on davmor2
<lool> theseinfeld: when it's in place :)
<theseinfeld> any ~ deadline?
<lool> mvo: We didn't release vm images until now
<theseinfeld> I actually made some vm images
<davmor2> :)
<theseinfeld> you need to do some hacking with the initram to get it working based on the project chrooted directory, other than that, it is quite straight forward
<lool> mvo: I'd suggest you only care about a single config in smb, or use the MIC provided configs -- all supported MIC configs could be made available with the config copying machinery I added
<lool> mvo: For the single default config, I'd recommend hardy+ppa for now and mobile archive afterwards
<theseinfeld> you mean s/hardy/ports/ right?
<lool> mvo: BTW I chatted with persia on the topic, and he was tempted to hack on MIC to add vm creation support from it
<lool> mvo: he mentionned concerns of bug-to-bug compatibility between MIC and u-v-b
<persia> I've since been convinced that this wouldn't be beneficial.
<lool> theseinfeld: It's the same thing
<davmor2> lool that would be cool :)
<lool> theseinfeld: hardy is a dist/suite; ports.u.c is where we host binaries for non-official architectures
<persia> As much as getting exactly the right set of packages together is desired, we can probably do that by abusing --add-pkg in u-v-m
<lool> theseinfeld: archive.ubuntu.com where we host source in all cases and binaries for supported arches
<lool> persia: This is implemented already :)
<persia> lool: Completely?  Last time I has slightly different results, but I've not tried the latest simple-mobile-builder.
<lool> mvo: Is your goal to spend time on it so that it's ready for release?  Otherwise, I'd suggest we work together after the release
<lool> persia: Well it's fully implemented, but some things differ
<lool> persia: There are currently some bugs and also s-m-b adds a fixed set of packages to the list of pkgs to isntall
<lool> persia: Also, config is copied manually instead of being provided by an ume-config-vm package
<mvo> lool: after release is fine for me, I just tweaked it a bit for davmor2 (he found some bugs)
<persia> lool: It's the differences that worried me.  The argument that convinced me not to make a VM platform for MIC was that we weren't likely to do lots of VM testing of the final release, and should look at how we want to VM-test for intrepid instead.
<lool> mvo: Ok; cool
<lool> mvo: I have a bunch of bugs/changes I'd like to fix, I mentionned them to you shortly, but generally speaking I think it's quite good already; I just didn't have much time since UDS to work on it
<mvo> and I found that neverball starts :) its just painfully slow, but other stuff like frozen-bubbles or gnash seems to be pretty usable
<davmor2> mvo: rev10 is much better menu is correct etc.  I'll play around with it and make up a quick wiki page on the testing section
<mvo> sure, I understand that, there is a rleease to make :)
<lool> persia: Apart of squashfs and initramfs, I think the differences were globally minimal with this approach
<persia> lool: Yes, although I find that the way the filesystems work for the MIC images can be part of some of the differences we see with our testing.  Depends on the test goal.
<persia> I'll take another look at simple-mobile-builder with the new updates: maybe my opinion is outdated.
<lool> persia: Exactly, it depends on what you want to test
<persia> That's true too :)
<davmor2> persia: lool:  As a tester using MIC I spent most of the day confirming if it was a bug or an issue with MIC.  Using the kvm image I lose the majority of that.
<lool> persia: Arguably we could as well use released images for cdrom or USB in vms, but these wouldn't work
<lool> (and we could make these work too IMO)
<persia> lool: Let's make the daily images work for VM for intrepid, for wider (safe) testing.  For now, the small differences are probably acceptable.
<lool> davmor2: Certainly we need to fix MIC issues for this release, but do we want to spend time creating vms which allow us to diagnose MIC bugs if they are only 10% of the bugs and we wont mainly use MIC in intrepid?
<lool> Or do we want vms which reproduce 90% of the bugs by allowing us to run the same packaged apps?
<lool> persia: I think I could argue that there are hardware bugs which you can't reproduce in vms anyway, so we wont ever reproduce it in full
<persia> lool: You don't have to argue.  I've already ceased efforts to make MIC do VMs :)
<lool> persia: Perhaps if we had a more layered approach (probably non-MIC) we could try reproducing more of the current build layout (squashfs and initramfs)
<lool> For example, if MIC initramfs was properly packaged, such as casper, it would be trivial to include it in vms
<davmor2> lool: true but then most of the apps don't run in mic which is the issue.  They are running in kvm version and finally it enables me to test UME again which then helps confirm issues with cgregan.  I have noticed issues that he hadn't and visa versa.  That currently isn't workable in MIC
<lool> davmor2: I understand your point, but I don't understand what you're arguing for/against
<persia> davmor2: There's two separate issues: one is VM vs. Xephyr.  I think we all agree VM is the solution.  The other is MIC vs. something else.  I think we ought use the same tool for everything, but can wait for intrepid.
<davmor2> Okay cool :) Just making the point rather than arguing though.
<lool> The only thing I'm arguing against is spending too much times on vms (for example by spinning them from MIC) at this point; simple vm builds are a good start already :)
<persia> Four people.  Four different goals.  None at odds.  Discussion is good :)
 * lool would just like to avoid waste of efforts; who am I to prevent people to work on something they'd like to do?  :-)
<theseinfeld> so, in the future there might be no MIC?
<theseinfeld> long time future :)
<jussi01> persia: happy now? :D
<persia> jussi01: Thanks.  I can now point at things like bug #217838 and get a response :)
<ubottu> Launchpad bug 217838 in ubuntu-mobile "sd8686 and sd8688 SDIO WLAN adapter cannot be detected WLAN adapter does not show up on the  network manager." [High,Confirmed] https://launchpad.net/bugs/217838
<jussi01> :)
<davmor2> Guys on date and time if you change manual to ntp are you able to install the ntp packages?
<davmor2> manual to automatic sorry
<persia> Installing packages is a little tricky: there's no GUI for this by default.
<ogra> what do you do with the default action then ? time-admin tries to pop up the installation dialog
<davmor2> and then crashes :)
<ogra> hmm, it surely shouldnt crash blindly
 * persia tests to try to find a way to not crash
<ogra> probably linking the app its trying to call to /bin/true or so might help 
<davmor2> ogra: it does throw up a polite message
<ogra> ah, k
<persia> davmor2: I can't get a crash, although it's not currently useful.
<davmor2> persia: might be an issue with vm
<persia> davmor2: Maybe, but that's not the sort of thing I'd expect for VM vs MIC images.
<davmor2> sorry not a crash it just flashes like it has crashed and then puts up a you can't do this message
<persia> davmor2: Ah.  Yes.  That's exactly my experience.
<persia> I'm glad to know we see the same thing: it makes it easier to be sure of any fix :)
<davmor2> that's why I assumed it had crashed
<persia> davmor2: I define "crash" as when the tool goes away completely (or worse, the windowing system goes away).
<persia> And "hang" as when it stops accepting any input.
<davmor2> okay we'll all get on the same page :)
<dns53> can anyone tell me what the differences will be between ubuntu-mobile created by the image creator vs a normal install on a computer with the ubuntu-mobile pakcage
<persia> dns53: There are some setup differences, and differences in how the initial base files are created.
<persia> Also, if you previously installed a different sort of Ubuntu, you may end up with a different set of applications.
<persia> Further, ubuntu-mobile wasn't quite ready for hardy, so there are some packages that are a little different.
<persia> I seem to remember a couple outstanding bugs on the meta-package as well, perhaps masked because we tend to use MIC.
<lool> Yes, for example the terminal.desktop file is shipped by mobile-basic-flash
<dns53> well there is no entry in gdm, i created one and runs the script in the wiki
<lool> dns53: We don't use gdm in UME
<persia> dns53: This would be one of the cases where your package selection was different :)
<persia> dns53: If you want to test, https://wiki.ubuntu.com/Testing/Cases/UMEinstall-kvm was recently published, if that helps.  It may change over time (it's new), so be warned.
<dns53> i've tried the image-creator a few times but nothing has booted of my eeepc yet
<persia> dns53: Which platform did you select in MIC?
<dns53> micassin is suppose to work but the images created when booting of a usb drive fail on boot, not sure if it is the kernel, init, mounting the root file system
<persia> dns53: Hrm.  I'm not sure then.  The McCaslin images work for me, but I have different hardware.
<ogra> dns53, you could try if the classmate image works for you ... its pretty HW specific though, you likely need additional stuff 
<ogra> http://people.ubuntu.com/~ogra/classmate/images/hardy/
<ogra> (and not (yet) based on mobile)
<davmor2> I'm still having issues with midbrowser open oo-trig.xls in OO.o.  But on a plus side ODR does open it now although it does look hideous.
<persia> davmor2: Having Time&Date install the NTP software depends on having a working synaptic, which isn't in -mobile.  We could likely hack something more directly using libapt, but it wouldn't be quick.  I think I'd rather it didn't work than possibly crashing without the nice user message, etc.
<mvo> I would suggest using the update-manager backend code, it should be trivial to extend for this purpose
<mvo> (probably not hardy though)
<persia> mvo: Calling python from C?
<mvo> IIRC time-admin just does a system() or exec() so that should be ok
<mvo> it does not link against libapt
<persia> Or calling some special update-manager call that allows for arbitrary new package installation?
<mvo> yes, that is what I was thinking
<persia> mvo: Could be.  How about a call into gnome-app-install?  Is UpdateManager much better?
 * persia hasn't looked at gnome-app-install other than the .desktop files
<davmor2> persia: A simpler fix for now might be to put a warning in place and then add at the bottom open terminal and type sudo apt-get install ntp
<ogra> persia, note that unionfs tears down the performance massively for g-a-i
<davmor2> and put in a better fix for intrepid
<persia> ogra: True.
<ogra> how about gdebi ? 
<ogra> you could just mae a call to gdebi-gtk
<ogra> *make
<persia> Doesn't gdebi expect a local .deb?
<ogra> (and pull the package in advance somehow)
<ogra> righ
<ogra> t
<persia> Could seed the ntp package, but it's a very, very ugly hack.
<persia> (where "seed" means putting in place in advance: not adding to the seed)
<mvo> if you have apturl installed, just system("apturl apt:ntp")
<ogra> apt-get -d ntp && gdebi-gtk /var/cache/apt/archives/ntp*.deb or so
<mvo> but iirc it uses synaptic as its backend too, so please ignore that last suggestion
<persia> ogra: Right.  That's still dirty for both gst-package and gst-time
<ogra> right
<mvo> I'm happy to make a mode for gdebi (if you instal lthat) and/or update-manager, that is trivial
<mvo> do you need it for hardy-final-lipa?
<persia> lool?
<persia> mvo: Really, it's not that I dislike synaptic, it's just that it's not there, and it wanted hildonmm :)
<ogra> it would help me on the classmate as well
<ogra> (to have a gdebi mode that pulls from the archive)
<mvo> it does not need hildonmm
<mvo> the gui uses plain gtk
<mvo> no gtkmm 
<ogra> even though on the cmpc g-a-i is a requirement anyway
<ogra> so i have to keep /var on a separate partition anyway and dont run into the performance probs here
<davmor2> dinner time talk to you latter
<persia> synaptic is 25MB on-disk, including additional dependencies.
<persia> Unfortunately, a simple install didn't fix Time&Date.
<ogra> do you really have ot care fo diskspace in UME = 
<ogra> ?
<ogra> *to care for
<persia> ogra: There's talk of 2GB devices.
<persia> My MID is 4GB, but the sales people try to sell at 512MB (but that's not linux)
<ogra> ah, well, dont let them do that ... i know how painful it is :)
<persia> It needs a bit of time.
<ogra> 2G are mean, not fish nor meat 
<ogra> 4G are just perfect
<persia> I think once storage gets a little cheaper, and more people use these things, it won't matter so much.
<persia> Currently, to get to a price point where people != me want to buy them, they need to cut features.  In six months/a year it won't matter so much.
<ogra> yeah
<ogra> sadly we need to solve todays probs today :)
<ogra> my minimal spec for cmpc *is* 2G 256M
<ogra> which makes me cry every time i type it
<persia> ogra: Wow!  My 3.5" is bigger than that.  I'm guessing the 256 is harder than the 2?
<ogra> yeah
<persia> Is the 2G at least fast-access, or filtered through a low-speed channel?
<ogra> the 2G is fine with the new ATA devices ... the former cmpc model had the dusk on usb ... combined with no L2 cache and 256M thats just pain
<ogra> *disk
<stgraber> ogra: fortunately you didn't have to use FF2 with that :)
<ogra> i did
<ogra> for the gutsy image :)
<ogra> which was a PITA
<stgraber> did you put a mention "do not try to open a second tab as it'd likely crash your system (or make it so slow that you think it crashed)"
<ogra> nah, gutsy was proof of concept
 * stgraber still remembers of the localapps try we did with scottie :) we opened youtube, it went fine for a while and then ... no firefox :)
<ogra> nobody expected it to actually work properly
<stgraber> cmpc 2g + intrepid should rock with that swap-in-ram thing and other improvments (and fast I/O too :))
<ogra> well, lets see ... i need to build on the netbook image in the future 
<ogra> thats likely less highly optimized for the HW than my personal image was
<persia> ogra: I thought you had a plan to base on -desktop?
<ogra> well, netbook will be based on -desktop anyway
<ogra> at least thats what i was told yet
<ogra> i hope the meeting today can clearify a bit more
<persia> ogra: Are you basing on netbook-remix, or a different netbook?
 * ogra doesnt even know who produces the current image 
<ogra> netbook-remix afaik
<persia> ogra: There's a hardy remix with code at https://launchpad.net/~netbook-remix-team/+archive
<ogra> persia, i was suggesting to use gnome for ume :) netbook will be -desktop anyway with a different launcher/desktop
<persia> I hear it might not be getting updated for intrepid.
<ogra> right, that means i need a lot of ppa stuff :/
<persia> ogra: Why PPA stuff?  Can't it be done as a flavour?
<ogra> well, i will still be bound to hardy as releasename 
<ogra> i.e. my patches have to be against the hardy kernel ... my apps have o be synced with hardy instead of intrepid etc
<ogra> i cant create a flavour in the hardy archive :)
<persia> ogra: Ah.  Retrospective images.  I see.
<ogra> :(
<ogra> and that at least until january for four different classmate arches :/
<ogra> urgh
<ogra> netbook remix uses gpl3 ? 
<lool> mvo, persia: while playing with in on menlow, I noticed update-manager will say "all updates" installed when there's no network
<persia> Yes, and it doesn't keep track of the last update.
<tripzero> ï»¿ what is UME going to do for a gps app?
<persia> tripzero: No selection has been made.  Have you had success with any of the various GPS apps in Ubuntu?
<tripzero> have you looked into navit?
<tripzero> http://navit-project.org
<persia> My hardware doesn't have GPS.
<tripzero> it's a little rough, but it's gtk, and it's maturing a lot
<persia> Is it in Ubuntu?
<tripzero> no
<ogra> someone should packge it then :)
<tripzero> the only one that is in ubuntu is gpsdrive, and it's not very good
<persia> tripzero: That's likely a first requirement to get stuff into Ubuntu-Mobile.  You might want to try to get the app packaged first.
<tripzero> persia, i've got an older version of it packaged
<tripzero> i'll see if I can get it updated
<persia> tripzero: That's probably a good first step.  You might work with the team in #ubuntu-motu to get the latest version packaged and on REVU for review.
<persia> They likely won't do the packaging, but they can provide advice and help (as many people in that channel are also packaging things)
<tripzero> persia: i'll get with the navit folks and get it packaged up then
<tripzero> do you know if UME has selected a media player interface yet?
<persia> tripzero: Thanks.  Having it in Ubuntu, and some reports on how well it works with the Ubuntu-Mobile environment would be the cleanest path to getting it in by default.
<DNis> hi, anybody  as a detailed roadmap for ubuntu mobile please ?
<DNis> i'm interested for an htc shift
<persia> DNis: How do you mean?  There's some test images available.
<persia> More than that is really what gets put into Ubuntu for the target architectures for the next release, and what is in the seeds.
<persia> For the most part, we're likely to have something based on GNOME to some degree.
<DNis>  persia : i mean a release date for an release candidate for example and release, and if there is test images for this device.
<persia> DNis: There are no special test-images for that device.  Do you know what chip it runs?
<DNis> htc shift run on an intel maccaslin platform, like teh samsung q1 ultra
<DNis> with intel a110 processor
<tripzero> persia: ï»¿do you know if UME has selected a media player interface yet?
<persia> DNis: There are some McCaslin images for testing, which might work for that.  They aren't quite perfect for my McCaslin (SR8), but they work.
<DNis> persia: it's in the roadmap for first ubuntu mobile release but i wished i could test it :-)
<persia> DNis: Take a look at cdimages.ubuntu.com
<DNis> persia: thx i will take a look at it
<persia> http://cdimages.ubuntu.com/moblin/releases/hardy/rc/
<DNis> persia: is it simple to install ?
<persia> DNis: Burn the image to USB, and boot off USB
<DNis> persia: it install a grub boot loader ? we can make multi-boot ?
<persia> DNis: I think so, but I've not tried a dual-boot configuration.
<DNis> persia: ok thx for your answers
<DNis> persia: it's in rc state so the release is very soon ?
<persia> DNis: As soon as possible.  Still a few things to fix.
<DNis> persia: ok thx a lot again
<persia> DNis: Does it work?  Please share your experience, so we can update the wiki if the HTC Shift supported.
<DNis> persia: mine is not already in my hand but shipping. but i will do if you want as soon as i have it
<persia> DNis: Excellent.  Thanks.
<DNis> persia: you are a developer on the project ?
<persia> DNis: Yes, although that doesn't necessarily mean I'm right about everything :)
<DNis> persia: ok ;-)
<persia> mvo: No need to build a special mode for UpdateManager in a hurry.  synaptic will be fine (although thanks for all your help not using synaptic for update-manager)
<lool> mvo: I don't think we need any changes from you right now; we'll just call as a backend
<lool> (like persia just said)
<lool> (sorry just got to the backlog of this afternoon)
<persia> :)
<mvo> ok
<persia> Does anyone know where the path is getting set in the UME session?
<ogra> if its like in desktop it should come from /etc/environment
<persia> ogra: That's what I thought, but it doesn't.  There's a hack somewhere, which needs elimination.
<ogra> yeah, sounds like
<ogra> any ~/.*rc files
<ogra> ?
<persia> That's why time-admin can't install even when it has it's dependencies.
<persia> Nope.  Not in ~/.?*
<ogra> gnomerc is a typical desktop ENV mangling file 
<ogra> /etc/bash.bashrc ?
<persia> ogra: It's not in one of the standard places.  This is a hack :)
<ogra> meh
<persia> Unfortunately, unlike many hacks, `grep PATH $(dpkg -L ume-config-common)` doesn't help :(
<ogra> grep -r PATH /etc/*
<ogra> ?
<persia> ogra: Thanks for pushing me to the simple, instead of my chasing the complex for hours :)
<ogra> :)
<lool> cgregan: What's the boot time constraint again?
<ub511> is it possible to run ubuntu-mobile on via epia ?
<cgregan> lool: https://blueprints.launchpad.net/astoria/+spec/3.3.7-performance
<lool> cgregan: So we're slightly above with -18
<lool> http://people.ubuntu.com/~lool/bootcharts/crownbeach/hardy-20080605-1.png
<lool> Let me grab -19
<lool> amitk: No meta for -19 yet?
<stgraber> lool: in the new queue
<lool> stgraber: thanks
<lool> cgregan: NB this is with HT
<lool> cgregan: It's probably worse without
<lool> cgregan: Check the -3 png, it's with -19
<cgregan> 32 seconds.
<cgregan> that's pretty good
<persia> mvo: I tracked down the larger issue with gst-package and synaptic.
<persia> When the user is logged in normally, they get ENV_PATH from /etc/login.defs.
<persia> This becomes ENV_SUPATH when they use sudo or gksu.
<persia> Since moving to policyKit for g-s-t, /usr/sbin isn't in the path, so it doesn't find synaptic.
<persia> I suspect other synaptic-callers might have the same issue, although I've not looked at them all.
<ogra>  /usr/sbin should always be in the path ... thats not polkit specific 
<persia> ogra: It's not defined in ENV_PATH in login.defs even on a standard Ubuntu Desktop install.
<persia> Only for ENV_SUPATH.
<persia> I thought the path came from /etc/environment, but appaprently that's not always so.
<ogra> $PATH will override that
<ogra> and its usually in environment ... 
<ogra> just add the proper one there and it should work
<ogra> else you have deeper probs
<persia> ogra: At what point?  PATH isn't force defined anywhere in the login sequence, and login assigns either ENV_PATH or ENV_SUPATH depending on the login.
<persia> I think there are deeper issues, as I can replicate the confusion on my desktop
<ogra> well, just add the ubuntu standard value to /etc/environment
<persia> ogra: It's already there
<ogra> (note also that /etc/environment only gets read at boot)
<ogra> re-login wont help
<persia> Yeah, but it was there from image-creation time.
<ogra> hmm
<ogra> weird
<persia> You're sure it's not with the switch to polkit?  With sudo and gksu I get the right path.
<persia> s/with/related to/
<ogra> well, i can call all apps with gksu here 
<persia> I can call all apps with gksu on my image, just not as the default user.
<persia> (not using gksu).
<persia> When the app doesn't use policyKit, that works great.
<ogra> do you have polkit installed ? 
<persia> When the app does use PolicyKit, policyKit can't get the session, and so doesn't authenticat.
<ogra> i remember you guys adding suport for consolekit
<persia> Hmm.  I thought so.  I can at least authenticate properly.
<ogra> do you see an active session with ck-list-sessions ? 
<persia> Yep.  libpolkit2 & friends are installed, and ck-list-sessions shows a session.
<ogra> active = TRUE
<ogra> ?
<persia> Yes.
<ogra> and a proper x11-display-device pointing to a tty ? 
<ogra> else polkit wont accept it as authenticated
<persia> /dev/tty7
<ogra> hmm, looks ok
<ogra> http://paste.ubuntu.com/17252/
<ogra> my session for coparison
<persia> polkit seems to work, except that I don't get switched to ENV_SUPATH
<persia> Only differences are that I don't have a real name, and I've been logged in 11 hours less.
<ogra> are you in the admin group with that user ? 
<ogra> (i would assume so since gksu works)
<persia> Yep.
<ogra> grep polkituser /etc/passwd ? 
<ogra> (should be created by the postinst ... pulling straws here)
<persia> polkituser:x:105:109:PolicyKit,,,:/var/tun/PolicyKit:/bin/false
<lool> /var/*tun*?
<StevenK> So typed out by hand
<persia> /var/run (I'm not using IRC from that device, and copy&paste doesn't work there very well anyway)
<lool> Nah, it's correct onmy desktop
<ogra> looks right to me
<ogra> ogra@osiris:~$ /usr/bin/polkit-auth|grep systemtools
<ogra> org.freedesktop.systemtoolsbackends.set
<ogra> do you get that value ? 
<persia> Everything looks fine.  stracing time-admin shows it to be only checking ENV_PATH and not ENV_SUPATH before reporting that it can't find synaptic, and telling the user it can't install the packages.
<persia> No!  It's empty.  That's likely it.
<persia> What's supposed to set that, and how?
<ogra_> so strace time-admin wasnt a good idea :P
<persia> Ah.  It does show with --show-obtainable though :(
<persia> And once obtained, it shows in the grep.
<persia> ogra: strace told me why it couldn't run synaptic (shortened PATH), but not why the PATH was only ENV_PATH.
<persia> I blame policykit, but that might be unfair.
<ogra> right, sicne it works here 
<lool> #startmeeting
<MootBot> Meeting started at 11:02. The chair is lool.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<ogra> it might be that gdm sets up something you dont have
<persia> ogra: Later, and I'll look at it.
<ogra> right
<lool> No items from last week, moving to this week
<lool> [topic]     *
<lool> [topic]           netbook image classmate PC relation (who is resonsible for what, who builds which parts etc) OliverGrawert
<MootBot> New Topic:      * 
<MootBot> New Topic:            netbook image classmate PC relation (who is resonsible for what, who builds which parts etc) OliverGrawert 
<lool> ogra: floor is yours :)
<ogra> well, intel constantly asks me about specs etc in the conf calls 
<ogra> i tried to actually find out which team is responsible over the last days and seem to run in circles
<lool> Which specs?
<agoliveira> ogra: You aways look like that :)
<ogra> been pointed to ume first ... then to lexington and they pointed me to -desktop
<lool> who pointed you for what at where? :)
<ogra> lool, i.e. they were told at computex that the netbook iage will only exist for LTS not for later releases
<ogra> adam le from intel was told that, dont ask me by whom 
<ogra> so he forwarded that to me 
<persia> The netbook-remix-image being worked on by that team is only targeted at LTS.
<ogra> imho it would be really unfortunate to stick with hardy here
<persia> No reason someone can't leverage that and track it for other releases.
<ogra> well, that gets me into maitaining half of the cmpc software stack for 3 years in a ppa
<lool> ogra: Well that's what we do so far; if however we have room for a customer interesting in intrepid support, I guess this could be discussed
<ogra> persia, my prob is that i need to start development now ...
<ogra> but need to know my build target
<ogra> and i actually need an image and hardware to run it on ... but thats another story :)
<lool> Aha
<ogra> HW shoudl come next week ... one atom cmpc reserved for you guys
<lool> ogra: Shouldn't this question be resolved by your management or canonical management in general rather than Ubuntu specs assignments?
<ogra> (currently tareted to go to david, not sure thats the best though)
<ogra> lool, well, i want to have a direct connection to my counterpart doing the lowlevel netbook stuff 
<ogra> for tech work
<ogra> but i cant find that counterpart anywhere 
<ogra> thats the point of my agenda item :)
<lool> Ok; I don't have the answer
<ogra> well, that got clear to me when i ran through the supposedly involved teams :)
<ogra> nobody seems to have an answer
<lool> ogra: Raise it to management would be my personal recommendation
<ogra> i.e. i dont even know if the actual netbook HW spec we agree on matches the minimal cmpc spec
<lool> Dunno, I have seen neither :)
<ogra> right, i was hoping rich would be here as well
<ogra> well, cmpc is 2G disk, 256M ram
<ogra> so you know 50% :)
<lool> I'd be happy to discuss a technical decision, but I feel like you're the only one in touch with the problem at hand
<ogra> but well, the topic cant go anywhere ... 
<lool> Perhaps it's too early for other UME people to understand the questions at hand?
<ogra> well, the question is simple
<ogra> will UME build the netbook base image ? 
<ogra> or rather "the mobile team" 
<lool> The information I have so far allow me to tell you:
<lool> I don't know
<ogra> heh
<ogra> great :)
<lool> ogra: However, there are strategic meetings this week which might get us an answer
<ogra> ah
<ogra> thats a small ray of light on my horizon then :)
<ogra> well, since we cant get more info up i think i'm done with my topic :)
<lool> Ok; I don't think we have enough info to discuss this here and now, so I'm tempted to adjourn the topic and meeting
<lool> I can raise it to davidm and ask for more info this week
<ogra> yeah
<lool> But we're busy with release
<ogra> i thought he would be here 
<lool> Thanks everybody
<lool> #endmeeting
<MootBot> Meeting finished at 11:15.
<ogra> else i wouldnt have put it on the agenda ... i can ping you guys personally all the time :) david is harder to catch
<bspencer__> short meeting today
<agoliveira> bspencer__: Best type.
<bspencer__> for me it was over before it began
<TomaszD> hi
<TomaszD> Invalid architecture: "lpia". Valid choices are: i386 amd64
<TomaszD> I'm using this https://wiki.ubuntu.com/Testing/Cases/UMEinstall
<TomaszD> can anyone help?
<TomaszD> this appears after issuing sudo ./simple-mobile-builder kvm hardy --sources /usr/share/pdk/platforms/menlow-lpia-ubuntu-hardy-ppa/sources/hardy.list --sources /usr/share/pdk/platforms/menlow-lpia-ubuntu-hardy-ppa/sources/um-ppa-hardy.list --sources hardy-full.list
<persia> TomaszD: Sorry about that.  You need the updated ubuntu-vm-builder in hardy-proposed.  Which arch do you have?
<TomaszD> I'm using ubuntu amd64
<TomaszD> ok I'll enable hardy-proposed
<persia> NO need.  I'll get you a URL for the .dsb
<persia> https://launchpad.net/ubuntu/hardy/i386/ubuntu-vm-builder/0.4-0ubuntu0.3
<persia> Just download that, and you should be all set.
<TomaszD> thanks persia !
<persia> TomaszD: Thanks for helping to test the images.
<TomaszD> no problem, got really curious
<TomaszD> btw, it would be reasonable to update the instructions to include the link to this new package
<persia> TomaszD: You could, but it ought drop into -updates in a couple days.
<TomaszD> ahh, then it's ok
<persia> TomaszD: Well, mostly.  Please share the URL to the deb with anyone else who has the problem.
<TomaszD> yeah I will
* persia changed the topic of #ubuntu-mobile to: This channel is for conversations around the Ubuntu UME development version | Info: https://wiki.ubuntu.com/MobileAndEmbedded. Please read the FAQ https://wiki.ubuntu.com/MobileAndEmbedded/FAQ | VM builder for UME VM builds is http://launchpadlibrarian.net/15004078/ubuntu-vm-builder_0.4-0ubuntu0.3_all.deb
<mthaddon> hey guys, I just tried running the setup script as per https://wiki.ubuntu.com/Testing/Cases/UMEinstall and got "lpia invalid architecture" - I went into the simple-mobile-builder and changed lpia to i386 and it now seems to be building okay...
<davmor2> mthaddon: did you follow all the steps
<persia> mthaddon: You might not get everything you expect that way.  Try the updated VM builder from http://launchpadlibrarian.net/15004078/ubuntu-vm-builder_0.4-0ubuntu0.3_all.deb
<mthaddon> ok, will give that a try, thx
<persia> ogra: Looking at the GDM code, it doesn't seem to insert /usr/sbin in the PATH.  There's even a workaround in the gdmsetup .desktop file just in case /usr/sbin isn't in the path.  Any other ideas?
<vadi2> Hi... the 'simple-mobile-builder' script fails for me (from https://wiki.ubuntu.com/Testing/Cases/UMEinstall). It says 'Invalid architecture: "lpia". Valid choices are: i386 amd64'.
<persia> vadi2: Try the updated VM builder from http://launchpadlibrarian.net/15004078/ubuntu-vm-builder_0.4-0ubuntu0.3_all.deb
 * persia updates the wiki page already
<davmor2> vadi2: did you install ubuntu-vm-builder?
<vadi2> I'm following https://wiki.ubuntu.com/Testing/Cases/UMEinstall, and it uses a simple-image-builder
<vadi2> I installed this vm builder though. Now what?
<davmor2> now run the script again
<vadi2> Oh that worked, thanks
<lool> persia: hardy-updates doesn't have lpia support I think
<lool> persia: (for ubuntu-vm-builder)
<lool> Unless it was added recently
<ogra> persia, hmm, not really, i'll dig a bit
<persia> lool: No, it doesn't, but that LP link does (hardy-proposed)
<persia> ogra: Thanks.  I'm currently digging in policykit itself.
<lool> persia: Ok; I was told it wouldn't be included, glad it was :)
<persia> lool: Mind you, my bug changed from not working in -updates to working in the PPA to taking my system down hard with the current -proposed, but I've a special setup.
<lool> How come so many people heard about simple-mobile-builder here? :)
<lool> Oh https://wiki.ubuntu.com/Testing/Cases/UMEinstall
<persia> lool: http://blog.qa.ubuntu.com/
<persia> This is the call for testers for the RC, so we can get lots of eyes.
<persia> Given that the RC won't work for most people, they will use simple-mobile-builder
<persia> This isn't bad, because they get up-to-the-minute fixes, although the UI for creating the second test image is a little odd.
<davmor2> lool: my fault :)
<lool> eh
<davmor2> check out planet ubuntu
<ogra> sweet :)
<davmor2> lool: hopefully get lots of eyes looking at the rc pinpointing issues and confirming :)
<davmor2> was the plan
<davmor2> maybe even patching too :)
<davmor2> ogra: you like it?
<ogra> yep
<TomaszD> persia, now when I want to run ubuntu.kvm I'm getting:
<TomaszD> tom@tom-pc:~/simple-image-builder/ubuntu-vm-hardy-lpia$ ./ubuntu.kvm 
<TomaszD> open /dev/kvm: Permission denied
<TomaszD> Could not initialize KVM, will disable KVM support
<TomaszD> Ubuntu does not support running KVM without hardware acceleration. Sorry.
<lool> TomaszD: adduser $you kvm; logout and login
<lool> Or sg kvm
<lool> Or you don't have hardware support
<TomaszD> no,  I have a Core 2 Duo 2.2GHz
<TomaszD> ok added myself , brb
<davmor2> lool: I'll add that to the wiki page
<TomaszD> ok, runs now, eats one core of my processor and nothing happens, just says "Booting from Hard Disk..."
 * lool &
<persia> TomaszD: That's different.
<davmor2> it is different
<persia> It's supposed to bring up a GUI
<persia> TomaszD: Maybe try with qemu ?  It will be much slower, but it has a better chance of working.
<TomaszD> wonder why it doesn't work :(
<TomaszD> with kvm I mean
<TomaszD> kvm should work fine
<persia> Did it work with qemu?
<vadi2> Where can I report issues? The ISO tracker doesn't list mobile
<TomaszD> where do I change that
<davmor2> it's on the wiki page TomaszD
<davmor2> vadi2: it's on the blog third here down :)
<vadi2> ops, thanks
<TomaszD> same thing happens, the GUI doesn't come up
<TomaszD> such a shame, I really wanted to try this out
<davmor2> TomaszD: I'm going to guess that something has gone wrong then.  Try removing the folder called ubuntu-vm..... and run the script again and see if the second build works right.
<TomaszD> davmor2, I'm going to repeat the whole procedure from the start
<davmor2> TomaszD: good luck
<TomaszD> davmor2, I think I know what the problem might be
<TomaszD> the script 404s on hildon packages
<TomaszD> Nie udaÅo siÄ pobraÄ http://ports.ubuntu.com/ubuntu-ports/pool/universe/h/hildon-desktop/libhildonwm0_2.0.11-1~svn15367-0ubuntu1_lpia.deb  403 Forbidden
<TomaszD> Nie udaÅo siÄ pobraÄ http://ports.ubuntu.com/ubuntu-ports/pool/universe/h/hildon-desktop/libhildondesktop0_2.0.11-1~svn15367-0ubuntu1_lpia.deb  403 Forbidden
<TomaszD> Nie udaÅo siÄ pobraÄ http://ports.ubuntu.com/ubuntu-ports/pool/universe/h/hildon-desktop/hildon-desktop_2.0.11-1~svn15367-0ubuntu1_lpia.deb  403 Forbidden
<TomaszD> Nie udaÅo siÄ pobraÄ http://ports.ubuntu.com/ubuntu-ports/pool/universe/m/marquee-plugins/marquee-plugins_0.22-0ubuntu1_lpia.deb  404 Not Found
<TomaszD> or 403s even
<TomaszD> "Nie udaÅo siÄ pobraÄ" = couldn't download
<TomaszD> hmm well the packages are there, I can download them via my web browser
<davmor2> TomaszD: they maybe updating the packages
<TomaszD> ok
<TomaszD> davmor2, how would I go on by downloading these by hand and installing them inside the lpia image?
<ogra> persia, hmm, did you ever try to build an image for vbox ? that just crashed strangely here
<ogra> /usr/bin/ubuntu-vm-builder: line 1054: vm_target_conversion: command not found
<TomaszD> ha, it starts! grub found the drive!
<davmor2> TomaszD: if you can start kvm and get into shell you can try running sudo apt-get install packages that are missing 
<TomaszD> davmor2, I'm almost there, I just don't know the login and password :]
<davmor2> ume login pass is ubuntu
<TomaszD> ok
<TomaszD> omg, hildon-desktop is a metapackage, this will take a while
<TomaszD> but it sure looks promising
<TomaszD> how do I run the GUI from the console? startx doesn't exist
<ogra> it should
<persia> Now I'm really confused.  policykit explicitly sets PATH to "/usr/sbin:/usr/bin:/sbin:/bin" in several places to avoid various sorts of privilege escalation attacks.  Why would something running under policykit search the user path?
<TomaszD> then I'm probably still missing a large piece of the install
<persia> TomaszD: neither ubuntu-mobile nor hildon-desktop depend on an X server.  Try installing xserver-xorg
<ogra> persia, hmm, i wonder how the env of that upstart script looks like before it does su ume
<TomaszD> ok I will, there's a new kernel coming atm
<ogra> persia, might be that there are some initscripts missing that need to be run before anyone logs in
<ogra> hum, i wonder if its necessary that polkit runs *before* you catually log in :)
<ogra> *actually
<TomaszD> persia, installed xserver-xorg, rebooted for the new kernel, startx command not found
<persia> ogra: You might have it.  Important services like hal and dbus aren't running when /etc/event.d/session is allowed to kick off.
<ogra> in the desktop install it is S01policykit in rc2.d ... probably the upstart login thingie runs before 01
<persia> policykit starts beforehand though, so I'm not sure.
<persia> Hmm.  Right.  Maybe I need to ask somewhere else then.
<ogra> pitti would probably know
<ogra> he did a lot on polkit
<TomaszD> ok nevermind, I'm still missing a chunk of -mobile..
<persia> ogra: I need some more background on upstart first.
<ogra> Keybuk then
<persia> Docs first.  Then People.
<TomaszD> sigh..
<TomaszD> hildon-desktop, ubuntu-mobile, xorg-server...
<TomaszD> startx doesn't bring up the GUI
<persia> Right.  The docs explain how to set dependencies in upstrart events.  I set /etc/events.d/session to "start on started rc2", and it retains the behaviour.  Not upstart then.
<persia> TomaszD: ume-config-common
<TomaszD> same issue
<persia> TomaszD: What does startx give you?
<TomaszD> No valid fontpath could be found
 * persia waits for bzr
<TomaszD> I think I'll just go with the procedure for the third time, wipe everything... maybe this time it'll pull all the packages automatically
<persia> TomaszD: Try `sudo aptitude install ubuntu-mobile ume-config-common gnome-icon-theme gnome-menus xserver-xorg-video-cirrus xfonts-base`
 * ogra just boots a qemu image built 10mins ago
<ogra> eeek
<persia> You probably have most of those, but that's the PKGS hint in simple-mobile-builder that ought get you a minimal system.
<ogra> persia, can you add -br to the startx call ? 
<ogra> the grid hurts :)
<ogra> trivial fix, big outcome :)
<TomaszD> ok gnome-* and xfonts were missing
<TomaszD> holy cow, it works!
<ogra> gah, qemu indeed doesnt properly translate my laptop touchscreen
<persia> ogra: What was -br supposed to do?  It didn't make a difference for me.
<ogra> black background
<davmor2> TomaszD: cool :)
<ogra> its an Xorg parameter
<TomaszD> thanks for all the help, will test this now
<persia> ogra: Even with -br, I still get the grey grid.
<ogra> persia, i think it needs to go behind the --dpi option
<persia> TomaszD: Excellent.  Sorry for all the trouble getting it set up.
<persia> ogra: I don't have a --dpi option in /etc/event.d/session
<ogra> oh
<TomaszD> goodness me the icons look atrocious, I bet it's the number one complaint :] they need to be svg or bigger 
<ogra> i have it in the upstat-session script that got copied over in simple-image-builder
<persia> ogra: Try fiddling with /etc/event.d/session  It's set to respawn, so killing X will get you a fresh login.
<ogra> ok
<ogra> god, qemu is slooow ...
 * ogra wishes vbox would have worked
<TomaszD> no kvm love?
<persia> ogra: It's just a debootstrap and some package installs.  Surely you can do that in vbox, although maybe not with the same shell script.
<ogra> TomaszD, sadly no ... 
<persia> TomaszD: no login manager at all.
<ogra> vbox is usually fine for me 
<persia> OpenEmbedded has a QT-based environment stack, which it might be possible to port, if someone felt like doing it.
 * persia has clearly mistaken "kvm" for "kdm".
<persia> ogra: Have you tried kqemu-source?
<TomaszD> persia, yeah I was about to ask what you mean
<ogra> yeah, had that before but i decided to go back to the convenient vbox ... i mainly did ltsp stuff in vbox yet, for that the internal network functions there are just awesome
<TomaszD> nice, my favourite game neverball is preinstalled, slideshow speed but nice to know it'll be there
<ogra> no special config or setup needed ... just works and i'm lazy
<ogra> hmm, if the terminal would open that would help
<TomaszD> yeah, it doesn't
<TomaszD> notepad app doesn't work as well, but that may be due to my incomplete install
<TomaszD> and Galculator? Please, it's a Calculator :P
<ogra> same for me with notepad
<ogra> Starting Notepad .... is sitting in front of me
<TomaszD> ok should photos and videos show a scary black screen with no content, no "Hello there, import photos" or anything like that?
 * persia finds this odd, as this image has "Calculator" and "Mousepad", rather than "Galculator" and "Notepad"
<ogra> i wonder if we're missing packages
<TomaszD> I don't have a preferences menu item
<ogra> and indeed i didnt keep a log :(
<TomaszD> only "All"
<davmor2> Guys quick query on file manager why are there two bars at the bottom (1 with GO and the one below with the rest of the buttons)
<davmor2> the top bar cuts the bottom bars icon up
<persia> TomaszD: If you pull down the menu from the top left, you ought to be able to select categories.  One of these ought be preferences.
<persia> ogra: You can get a list from dpkg --get-selections, no?
<ogra> if i could get a shell :P
<TomaszD> persia, heh I know there should be more, the pulldown list only includes the All category
<persia> Well, running stuff from a VT won't get you the environment benefits, but it will let you run CLI stuff.
<TomaszD> my install is borked
<ogra> well, i thought about an xterm :)
<persia> TomaszD: Yes, your install is broken.  I'm not sure why it didn't work for you, especially twice.  It seems to work for some people.
<TomaszD> I'll let install again while go away and do something else
<TomaszD> *+it
<ogra> mumble
<ogra> meh, recovery mode doent work :/
<ogra> *doesnt
<persia> ogra: Right.  I'll go chase that now.
 * persia gives up on policykit
<TomaszD> ha, still downloading, looks like it'll be ok this time
<ogra> persia, sulogin not installed i'D guess
<ogra> hmm, no, its there
<davmor2> TomaszD: I hope so, that way you'll see what we're all so happy about.
<TomaszD> a general question though. How do you guys plan handling i18n ?
<persia> TomaszD: Most of the applications are translated (inherited from GNOME).
<persia> Just changing the locale ought do it.
<TomaszD> (I'm ubuntu-l10n-pl admin)
<TomaszD> what about hildon though
<davmor2> ignoring it and make everyone speak english :D
<persia> Check the contents of /etc/default/locale
<TomaszD> and is there going to be an applet or preference for the language?
<persia> davmor2: No, really we do have multilingual support, just not any way to select the language except from the command line.
<TomaszD> hmm the script pulls kernel -16, but -17 is available for some time now
<davmor2> persia: the big laughing face should of been somewhat of a give away ;)
 * persia often misinterprets smilies
<TomaszD> well it installed fine, I got straight into the gui
<TomaszD> but no sign of Preferences
<TomaszD> oh and I forgot to mention, the Chat button is missing an icon
<TomaszD> which I presume is Pidgin
<TomaszD> but it just sits there
<davmor2> TomaszD: works here :-/
<TomaszD> blimey, is my computer special, is my net connection special, what the hell is wrong
<davmor2> TomaszD: your computer is in the wrong corner of the room ;)
<TomaszD> I can move it, it's a laptop... :P
<TomaszD> ok, bbl
<ogra> persia, -br works fine for me appending it after the 96
<ogra> exec su -l ume -c "/usr/bin/startx -- -dpi 96 -br"
<persia> ogra: You had a --dpi to start?
<ogra> yeah
<persia> I'm nowhere near 96 DPI, so not at all tempted to use that.
<persia> (and don't have the --dpi 96 in my image)
<ogra> well, thats whats in my session script
 * persia has a significantly stronger suspicion that the VM images do not match the MIC images.
<ogra> yeah
<ogra> how does your session script look like ? 
<ogra> "/usr/bin/startx --" ?
<persia> exec su -l ume -c "/usr/bin/startx -- -config xorg-samsungq1ultra,conf"
<persia> Note that this isn't a Q1U, so using that xorg.conf breaks a couple things.
<persia> My touchscreen works if I don't have the -config
<persia> (well, calibration is broken, but that's a different issue)
<ogra> put it in front of -config
<ogra> exec su -l ume -c "/usr/bin/startx -- -br -config xorg-samsungq1ultra,conf"
<persia> I did that.  No change.
<ogra> thast pretty weird
<persia> Yep.
<ogra> startx definately hands over verything after -- to xinit
<persia> Lots of things about the MIC build are weird.  Some of these weirrd things are also good.
<ogra> which then appends it to X/Xorg as parameter 
<ogra> works fine here ... it probably doesnt like the -config option
<ogra> did you try adding it behind ? 
<ogra> xec su -l ume -c "/usr/bin/startx -- -config xorg-samsungq1ultra,conf -br"
<persia> After -config?  No.  I'll try that.
<ogra> i doubt you use ppa X packages :)
<ogra> so it must work one way or the other
<persia> Nope.  Still gives the standard X screen for a bit.
<ogra> hmm
<persia> I'm using *lots* of PPA packages.
 * persia is currently waiting for the PPA build of grub
<persia> Oh.  PPA X packages?  No.  Only ubuntu-mobile PPA.
<ogra> right
<ogra> why the heck do you actually have to use the -config option ? 
 * ogra doesnt see the benefit
<persia> It has the special hacks for the Q1U, and is part of the standard MIC build for McCaslin.
<ogra> yeah
<ogra> but why not in the standard place
<persia> For my hardware, it's actually a detriment, but I don't want to hack it out just to break someone else.
<persia> I think the idea was that one would be able to set up lots of different hardware configurations in MIC.
<ogra> right, just copy the right filein place or link it
<persia> This might be fine for some person sitting in an office building images for all the toys on the workbench, but is less ideal for having a standard test build.
<persia> Oh, sure, I could do that, but it'd just break again when I built the next image (I run a couple images a day).
<persia> Same for all the other improvements you suggested a couple weeks ago ;)
<ogra> ooooh
<ogra> found the issue with the image builder :)
<ogra> /usr/share/pdk/platforms/menlow-lpia-ubuntu-hardy-ppa/sources/hardy.list doesnt actually exist 
<ogra> so the wikipage is wrong
<persia> heh.  Try using the mccaslin lists.
<ogra> /usr/share/pdk doesnt exist
<ogra> wher is it supposed to come from  
<ogra> ?
<persia> It's in moblin-image-creator
<ogra> ah
<ogra> thats the issing bit 
<ogra> *missin
<ogra> bah
<ogra> the wikipage doesnt talk about MIC at all
<ogra> davmor2,^^^
<davmor2> ogra the bit below does
<hp2133> A friend just pointed me to here.  Any packages available yet?
<davmor2> https://wiki.ubuntu.com/Testing/Cases/UMEinstall
<davmor2> ogra: ^
<ogra> davmor2, well it should tell you to install MIC at the top 
<persia> davmor2: Right, but the point is that apparently MIC needs to be installed in order for the simple-vm-builder to pull the right feature sets
<ogra> sudo ./simple-mobile-builder kvm hardy --sources /usr/share/pdk/platforms/menlow-lpia-ubuntu-hardy-ppa/sources/hardy.list --sources /usr/share/pdk/platforms/menlow-lpia-ubuntu-hardy-ppa/sources/um-ppa-hardy.list --sources hardy-full.list 
<ogra> all the --sources files are missing without it installed
<davmor2> hang on then 
<davmor2> damn no mvo
<ogra> and hardy-full.list should become ./hardy-full.list
<persia> I know a bit about that code.  What did you want to ask?
<davmor2> persia: if it could be pulled in or added to the app save having to pull in another app just for the repo list
<persia> davmor2: Duplication of data is bad because it causes extra merge work.
<persia> Also, I don't like feature sets anyway.
<persia> And, given the bzr branch being pulled, that change would require mvo
<davmor2> I guess the big problem here is that everyone who has tried it has mic installed already :(
<persia> davmor2: Yep.  That's why we call for more testers.  We get to find out our missed assumptions.
<davmor2> :) indeed :)
<persia> Everyone also had ubuntu-vm-builder already installed, and we caught that quickly.
<persia> We got the hint about /usr/share/pdk early, but failed to investigate it soon enough.
<ogra> Get:1 http://ppa.launchpad.net hardy/main libdrm2 2.3.0.16-0ubuntu1~804um2 
<ogra> yay
<ogra> that looks better 
<ogra> hmm
<ogra> cp: cannot stat `./hardy-full.list': No such file or directory
<ogra> seems it needs the full path :/
<ogra> likely because it builds in TMPDIR instead of $(pwd)
 * ogra starts another build with $(pwd)/hardy-full.list instead of ./hardy-full.list lets see if that helps
<ogra> oooh
<ogra> and there is a typo in hardy-full.list
<ogra> W: Failed to fetch http://ports.ubuntu.com/ubuntu/dists/hardy/main/binary-lpia/Packages.gz  404 Not Found
<ogra> must be http://ports.ubuntu.com/dists not http://ports.ubuntu.com/ubuntu
<persia> So, update-manager has this nifty feature by which it downloads package changelogs from changelogs.ubuntu.com, which gets updated about every 4 hours.  Anyone have any good ideas how to display snapshot changelogs where the packages are newer than the default changelogs.ubuntu.com?
<ogra> mvo would 
<ogra> geez, now thats what i call an image
<ogra> that looks way better and wuite different
<ogra> *quite
<persia> Right.  Did you already update the wiki?  Shall I?
<ogra> doing now
<persia> ogra: Thank you :)
<ogra> persia, btw, my current image has -dpi 96 as well
<ogra> but -.br doesnt work either
<ogra> -br
<persia> ogra: Hrm.  I'm knee-deep in update-manager-hildon right now, but I'll roll another image when I finish to see if I can get that.  Might be a mccaslin vs. menlow thing (I run mccaslin fsets)
<ogra> ah
<ogra> well, seems to have the same issue though
<persia> -br not working means you're closer to me.  If you can figure out how to make it work, you'll make everyone happy :)
<ogra> trying to find that 
<ogra> probably someone added xressources files or soething differently weird
<persia> Likely, or something odd in the selected X configuration.
<persia> For the extra hacky bits, look at the ume-config-foo packages
<ogra> xorg.conf looks ok
<ogra> uuuuh
 * persia translates "uuuuh" to "There's something mysteriously hackish going on"
<ogra> nah
<ogra> i just had a look at the session script 
<ogra> that released an uuuh ... not specific to any special line or so :)
<persia> You might want to change it to trigger on started rc2, rather than running in parallel with the rest of the rc2 startup.
<ogra> just rebooting
<persia> It makes it take longer to get to the desktop, but it guarantees dbus, hal, etc. beforehand.
<ogra> ha
<ogra> the grid comes from the framebuffer before the card gets initialized
<ogra> its actually black with -br
<ogra> the driver doesnt init properly
<persia> Which driver?  -psb?
<ogra> cirrus i think
<ogra> whatever qemu uses by default
<persia> cirrus
<ogra> might as well just be vm slowness
<ogra> but it definately turns black if the crosshair pointer is shown
<persia> Strange.  On my hardware I get the gray screen anyway on boot.
 * ogra tries a proper shutdown
<ogra> do you have a movable mousepointer while you see that ? 
<persia> Yes, the standard X pointer.
<ogra> hmm
<persia> (even with -br in various places)
<persia> It only lasts about a second or two, but it's noticable.
<ogra> i get a white screen without pointer now ... and that turns black as soon as the pointer shows up
<persia> That sounds like the right solution.  What's your call in /etc/event.d/session?
<ogra> so poering off the vm cleaned the videoram i assume
<ogra> exec su -l ume -c "/usr/bin/startx -- -dpi 96 -br"
<persia> Ah.  I've only tested reboots.  Testing a full shutdown now...
<ogra> Ãq
<ogra> whoops
<persia> Nah.  Oeq is a good way to put it :)
<ogra> (that was a misfocused :q on a german keyboard in us kbd environment :) )
<persia> : is bound to Oe?
<persia> Or is it compound, so that O: generates Oe?
<ogra> : is Ã¶ with us mapping on german kbd
<persia> With a full power-down I get the black screen.  Definitely cached video-ram.  Sorry for the confusion.
<ogra> well, i could have guessed that one earlier :)
<persia> If I only provided enough information...
<ogra> the photos app doesnt start apparently 
<ogra> oh, no locale 
<ogra> setting LANG makes it start
<ogra> oh, funny
<ogra> env had LANG="de_DE.UTF-8"
<persia> ogra: Locale is now being set by MIC.  Just put something in /etc/default/locale, and you ought be fine.
<ogra> seems simple-mobile-builder sets it to the build env locale
<ogra> ah
<persia> ogra: Where does it set it?
<ogra> no idea but how else should LANG="de_DE.UTF-8" get in there
<persia> Not sure.  Do you have an /etc/default/locale?
<ogra> one of the tools involved must have set it unless qemu hands it over from the host
<persia> How about a LANG entry in /etc/environment?
<ogra> i have /etc/default/locale
<ogra> with de_DE
<persia> Interesting.  I'm glad it's there, but a little surprised.
<ogra> well, tricky
<ogra> de_DE isnt generated
<persia> Must be set based on the build locale.  Nice touch to test multi-lingual.
<ogra> it sets it but doesnt run locale-gen
<ogra> which makes all the moblin apps fail
<ogra> at least all moblin-media ones
<persia> Ah.  That ought be fixed.  I'm not sure when/how MIC runs localegen, but it seems to work without running it manually.
<ogra> # Keep perl inside the chroot quiet
<ogra> HOSTLANG=$LANG
<ogra> LANG=C
<ogra> ha
<ogra> /usr/bin/ubuntu-vm-builder
<ogra> hmm
<persia> heh
<ogra> it seems to run locale-gen later
<ogra> but it didnt for my image ... hmm
<ogra> intresting, i see it generating them in the build log
<ogra> ah i know why :)
<ogra> my fault
<ogra> i ran the command with LANG=C in front to get proper error messages ... the builder script copies /etc/default/locale /etc/default/console-setup and /etc/timezone from the build machine and runs locale-gen $LANG afterwards
<ogra> bug !
<ogra> (it should read /etc/default/locale to get the value)
<ogra> oh, the terminal somehow sits on top of all windows now ... no way for me to get the menu open in front of it
<persia> ogra: Click in the upper left hand corner
<ogra> yeah, the show desktop button works 
<ogra> but the behavior persists if the terminal win is back
<vadi2> How can I uninstall the test enviroment?
<persia> vadi2: How do you mean?  Just clean up from building the image?
<persia> Or do you also want to purge all the packages you installed to make it work?
<vadi2> ï»¿persia: no, like, remove completely. I rebooted and got a kernel panic, and decided I'm not knowledgeable enough to participate in the testing if something goes wrong...
<ogra> ah, the issue might be caused by the fact that xterm has no app menu :)
<vadi2> ï»¿persia: I'll be testing out the final thing when they ship a device with this though :)
<persia> vadi2: OK.  Given that, I'd probably do the following.
<persia> rm -r simple-image-builder
<vadi2> ok, got that
<persia> sudo aptitude purge ubuntu-vm-builder moblin-image-creator
<persia> The rest is probably safer to leave, and you might want it later.
<vadi2> Ok cool, thanks
#ubuntu-mobile 2008-06-06
<idefine> has anyone actually deployed this on a phone yet?
<persia> idefine: It's not really targeted to phones.
<persia> More handhelds
<persia> Think 4-6" laptops, tablets, etc.
<vadi2> How can I dsiable the "VMX root mode"?
<persia> vadi2: Hmm.  Maybe that came with kvm.  You might be able to aptitude purge bridge-utils vgabios kvm qemu, but I'm not 100% sure.
<persia> And waiting 5 minutes for an answer gives me time to check the rdepends :)
<idefine> persia: ah, thanks!
<dholbach> good morning
<lool> ogra: Funny, I didn't get the bug this way, perhaps it's different in the intrepid branch of u-v-b
<ogra> well, i did get it following the wikipage but utting LANG=C infront of the simple builder command
<ogra> my build system had de_DE though
<ogra> its not really critical and a corner cae anyway
<ogra> *case
<ogra> in case of MID it just makes the moblin-media stack fail which doesnt seem to be a good idea 
<ogra> (that might be better to fix in moblin-media itself probably)
<ogra> oh, and i dont use intrepid, its all hardy 
<shakara1> hi
<shakara1> i got a error in Ubuntu Mobile when i install
<ogra> lool, more important is that mvo fixes hardy-full.list to get the right url in
<lool> davmor2: I'm not sure we want to change font sizes at this point
<shakara1> $ ./ubuntu.kvm 
<shakara1> open /dev/kvm: No such file or directory
<shakara1> Could not initialize KVM, will disable KVM support
<shakara1> Ubuntu does not support running KVM without hardware acceleration. Sorry.
<shakara1> $ glxinfo | grep direct
<shakara1> direct rendering: Yes
<lool> davmor2: It would require retesting of everything I would guess
<lool> shakara1: This is not the same type of hardware acceleration
<lool> shakara1: glxinfo reports about your graphics card
<lool> shakara1: KVM is based on CPU level instructions
<shakara1> @lool then how to fix it?
<lool> ogra: Where's this fix?
<lool> shakara1: You could try with qemu instead of kvm
<shakara1> @lool: ok i will try
<ogra> lool, https://wiki.ubuntu.com/Testing/Cases/UMEinstall i added it to the instructions for now
<lool> ogra: thanks
<ogra> sed -s -i 's/ubuntu /ubuntu-ports /' hardy-full.list 
<ogra> shakara1, kvm is essentially something your CPU needs to have HW support for, you can test if your CPU does with:
<ogra> egrep '(vmx|svm)' /proc/cpuinfo
<ogra> if that return nothing, you cant use kvm and need to go with qemu
<ogra> *returns
<shakara1> ogra: umn, return nothing
<ogra> lool, that should probably be on the wiki as well
<suihkulokki> you might need to do modprobe kvm-intel / modprobe kvm-amd
<shakara1> where put qemu? exits a how to?
<lool> ogra: where does that hardy-full come from?
<ogra> lool, lp:~mvo/ubuntu-mobile/simple-image-builder ships it
<lool> ah..
<ogra> so we need mvo for fixing i guess
<shakara1> $ sudo modprobe kvm-intel
<shakara1> [sudo] password for shakaran: 
<shakara1> FATAL: Error inserting kvm_intel (/lib/modules/2.6.24-16-generic/kernel/arch/x86/kvm/kvm-intel.ko): Operation not supported
<ogra> shakara1, well, if the egrep command didnt return anything you CPU cant do kvm
<ogra> no need to try it further
<ogra> (unles you start soldering around in your CPU core :) )
<lool> shakara1: Just pass it as argument to simple-mobile-builder
<lool> simple-mobile-builder qemu hardy
<shakara1> $ ./ubuntu.kvm simple-mobile-builder qemu hardy ??
<ogra> lool, the .list files should go into a bzr branch btw, currently you need to install MIC just for getting the sources.list files from it
<lool> ogra: I think I made that optional
<ogra> shakara1, copy and paste: sudo ./simple-mobile-builder qemu hardy --sources /usr/share/pdk/platforms/menlow-lpia-ubuntu-hardy-ppa/sources/hardy.list --sources /usr/share/pdk/platforms/menlow-lpia-ubuntu-hardy-ppa/sources/um-ppa-hardy.list --sources $(pwd)/hardy-full.list
<lool> if [ -n "$PLATFORM" ] || [ -n "$FSET" ]; then
<lool>     if ! which image-creator >/dev/null; then
<lool>         log_c "You need moblin-image-creator for --platform and --fsets"
<lool> It's only required if you want to use these concepts
<shakara1> mkdir: cannot create directory `/home/shakaran/simple-image-builder/ubuntu-vm-hardy-lpia': File exists
<shakara1> Error creating directory /home/shakaran/simple-image-builder/ubuntu-vm-hardy-lpia. Unable to proceed.
<shakara1> `PKGS' borrado
<shakara1> `SOURCES' borrado
<ogra> ah, i might have missed the massage, it doesnt stop if it doesnt find the lists but just goes on and builds a broken image
<lool> ogra: But I don't like adding that hardy-full; I don't think it should be there
<ogra> shakara1, delete the dir (ubuntu-vm-hardy-lpia)
<ogra> oh, it was in the instructions before
<ogra> i think davmor2 added it
<lool> ogra: It doesn't stop?
<ogra> nope
<lool> log_c() { log "C:" "$@" exit 1
<ogra> it just went on and left me with an image 100% built from the standard archive
<lool> But you passed --platform or --fset?
<ogra> which was an odd image indeed
<ogra> i used https://wiki.ubuntu.com/Testing/Cases/UMEinstall
<ogra> it only adds --sources
<lool> Argh
<lool> It should simply set --platform instead of looking up MIC files
<ogra> i fixed that site along the way trying to get a usable image
<shakara1> @ogra: downloading...
<lool> I spend half a day implementing the dump functionality in MIC
<ogra> gah
<lool> There are bugs in this mode though, and I didn't have time to fix htem
<ogra> the simple-mobile-builder comand was like that since the begining of the page though, i just added the $(pwd) to the hardy-full.list in the end
<lool> I'm sorry, I don't have time to look at this today
<shakara1> There is a chance to try Ubuntu Mobile on a PDA HTC P3600?
<shakara1> or only in PC?
<ogra> well, i can make a testbuild with --platform, if that works i'll update the wiki
<ogra> lool, what are valid values for platform ? 
<davmor2> sorry guys been racing around like a headless chicken.
<davmor2> lool: currently most of the stuff in the kvm image and on the jax10 don't work because the small font size is too large.
<davmor2> orga: thanks for adding that to the wiki I must of missed your request for it sorry
<ogra> persia pushed for it so people dont get broken images :)
<lool> ogra: see mic --list-platforms
<davmor2> lool: on the bigger size machines like the q1 the font in use is the large fonts anyway
<ogra> lool, thanks
<lool> image-creator -c list-platforms
<ogra> +sudo :)
<lool> No
<lool> At least, not if you have a fixed image-creator
<lool> I fixed that requirement for root in an Ubuntu pach
<lool> *patch
<lool> It's in the ppa version and intrepid version
<shakara1> ï»¿@loll: There is a chance to try Ubuntu Mobile on a PDA HTC P3600?
<shakara1> any help?
<davmor2> lool: did you get the thing about gpe-filemanager?
<shakara1> how install Ubuntu Mobile on a PDA?
<lool> davmor2: the thing?
<davmor2> shakara1: it's not ready for pda yet
<davmor2> lool: hang on I'll get the bug
<davmor2> https://bugs.edge.launchpad.net/ubuntu-mobile/+bug/235338
<lool> davmor2: Switching to pcmanfm?
<ubottu> Launchpad bug 235338 in ubuntu-mobile "File manager is cutting through the icons" [Medium,Confirmed] 
<davmor2> lool: that was cgregan suggestion to the issue mine was to remove the top bar with go in.
<ogra> lool, ++
<shakara1> davmor2: ok, Some approximate date when Ubuntu Mobile will be ready for PDA?
<davmor2> No idea
<ogra> <-- big fan of pcmanfm
<shakara1> QEMU is slow
<shakara1> $ ./ubuntu.qemu 
<shakara1> Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory
<davmor2> shakara1: it isn't designed for pda it is designed for mids someone might port it at some point though.
<davmor2> shakara1: daft question but what are you running this on?
<ogra> hum
 * ogra doesnt get s-m-b to do anything at all 
<ogra> not even with a new MIC from intrepid
<davmor2> ogra: big hammer time you know it makes sense :)
<shakara1> davmor2: I am running Music Player in Ubuntu Mobile
<ogra> well, setting set -ex in the script i see it doesnt get beyond setting TEMP ... thats very weird
<lool> " the zephyr xserver" arf
<lool> http://linuxdevices.com/news/NS8446435808.html
<davmor2> shakara1: no sorry what hardware are you trying to run kvm on
<ogra> heh
<shakara1> Mi computer is a laptop with ATI and processor of 1.86 GHZ 
<davmor2> what processor
<shakara1> In Ubuntu Mobile if you press in Battery Icon, then it restart Ubuntu Mobile???
<ogra> your vm has no battery ... it might crash
<davmor2> shakara1: that's because there is no battery on the virtual machine it's know
<davmor2> shakara1: what processor is it?
<shakara1> davmor2:Intel Pentium M processor 1.86 GHz
<davmor2> shakara1: and you've tried installing kvm and become a group member of kvm?
<shakara1> Should detected that my KVM has no battery and display a message not to crash. That would be more useful.
<shakara1> Yes, I add in Groups an User, my user in kvm group
<shakara1> because the wiki said
<davmor2> shakara1: it's designed for really hardware though and not vms on the hardware it is powered by batteries
<davmor2> shakara1: right and did you restart your machine at that point?
<shakara1> no, i not restart my machine
<shakara1> it should be restart?
<davmor2> that will enable the settings to change so yes
<shakara1> oks, i will restart
<davmor2> shakara1: I just realised it's not on the wiki so I've added it
<shakara1> it is normal that keyboard it shift to right in the last row?
<shakara1> The keys left, right and below are displaced.
<Celph_Titled> Hi
<Bert_2> Hi, what's the default password of a standard KVM UME system ?
<ogra> ubuntu
<ogra> indeed :)
<Bert_2> ogra: okey, thanks :D
<Bert_2> BTW, to all contributors and developers: UME is very very nice, when I buy my eeepc I'm surely going to install it ;)
<Celph_Titled> Little question, UME is the base project for NBR, right ?
<Celph_Titled> Will NBR be available for devices such as eeepc 4G ?
<tripzero> Celph_Titled: i would think so (eeepc question)
<tripzero> NBR uses some of the base tech from UME
<tripzero> i believe it uses matchbox, and a similar panel
<tripzero> I don't think it uses hildon, but I could be wrong
<Celph_Titled> Newbie here. Matchbox ? hildon ?
<tripzero> matchbox window manager
<tripzero> hildon is the toolkit that the gui elements use
<tripzero> matchbox wm is what makes the apps always fullscreen
<Celph_Titled> Ok
<Celph_Titled> Thanks.
<Celph_Titled> I think I'll install Ubuntu (currently I'm running Xubuntu on the eee) and then install the GUI components of netbook remix
<Celph_Titled> Last question, UME could run on the eepc or is it made "only" for atom based machines ?
<tripzero> many of the builds have drivers specific to the target devices
<tripzero> other than that, it should run... in theory
<Celph_Titled> M'kay
<ogra-ume> oof, not easy to type on that screen kbd
<davmor2> ogra-ume: it would be on a touch screen :)
<ogra> well, my lappie has one :)
<ogra> took me half the day to get the vbox guest drivers running on lpia though ... but now the touchscreen gets reached through directly
<ogra> so in fullscreen mode i have an MID with a 10cm frame :)
<ogra-ume> trying two fingers isnt rea;ly bettwer
<ogra-ume> lool: i cant open urls in pidgin, is that known ? 
<lool> ogra-ume: Not to me; there was a recent change for gnome-www-browser support, could you check how it's setup ATM?
<ogra-ume> manual and nothing in the command field
<lool> ogra-ume: Sounds like a broken upgrade / removal
<lool> ogra-ume: grep the maintainer scripts perhaps
<ogra-ume> well, its a fresh image, i didnt play with any settings yet
<ogra-ume> will do
<persia> lool: No, it's been that way for a while, at least since UDS.  I just forgot about it.
<lool> gnome-www-browser - status is auto.
<lool> here
<lool>  link currently points to /usr/bin/epiphany-gecko
<lool> /usr/bin/firefox - priority 70
<lool> (doh)
<ogra-ume> i wonder why midbrowser doesnt just register www-browser though
<ogra-ume> err
<ogra-ume> x-www-browser
<lool> It's hard to tell where the limit is between gnome-ish and not gnome-ish stuff
<ogra-ume> well, its one line in postinst and guarantees that non gnome apps have a system browser
<lool> Oh it should do all of them, I agree
<ogra-ume> right
<lool> You said "just register" these, so I thought you wanted to exclude gnome-w-b
<ogra-ume> nah :)
<ogra-ume> hmm, the matchbox-keyboard in extended mode has way bigger and easier to press buttons
<mterry> lool, ogra-ume: LP #223891 for the x-www-browser stuff
<ubottu> Launchpad bug 223891 in ubuntu-mobile "Claws Mail - Help apps are non-functional" [Medium,Confirmed] https://launchpad.net/bugs/223891
<ogra> great :)
<mterry> I'm trying to figure out why a file got lost in a package, but can't find when it happened...  moblin-settings-daemon in git has (and has had for a long time) the file moblin-settings-sound.c.  But the file isn't in UME builds (it was in .61 but not in .66).  But I can't see a changelog entry referencing it
<ogra> doesnt the git history show it ? 
<probono> hi all, how is ubuntu-netbook-remix related to ubuntu-mobile?
<probono> hildon seems not to be in the ubuntu-netbook-remix
<persia> probono: ubuntu-netbook-remix is a remix of Ubuntu, containing some commonality with each of Ubuntu Desktop and Ubuntu Mobile.
<probono> so ubuntu mobile and netbook are somewhat like parallel projects?
<persia> probono: Something like that.  It's not quite that well defined.
<persia> Ubuntu Mobile is a flavour of Ubuntu, like Ubuntu Desktop or Kubuntu Desktop
<persia> Ubuntu-Netbook-Remix is a Remix of Ubuntu, something like Mint or Fluxbuntu
<probono> ah, thanks. that clears it up
<persia> There's been talk of creating a NetBook flavour, but nothing committed to the repos yet.
<m-c> Why does the project wiki say the N800/N810 has proprietary parts?  Does it refer to hardware parts?  If so, what is a proprietary part, and how does it differ from most other undocumented computer parts?
<m-c> To my knowledge, the N800/N810 uses open source software, except for the graphics and wifi, which is also the case for the majority of personal computers.  It is an otherwise very open system.
<persia> m-c: Fairly open, but not as open as required for inclusion in Ubuntu main.  the graphics and some of the drivers (e.g. wifi) are some of the parts that aren't.
<m-c> You are going to find closed drivers for all usa-produced wifi devices.  The FCC mandates manufactures take measures to prevent the radio devices from being used outside the specifications.
<suihkulokki> graphics is open on N800/N810, wifi is closed
<persia> Even better.
<m-c> The Maemo (distro running on those devices) has a very strong developer community.  It would be wise to try and build bridges there.
<m-c> Would anyone here be upset if I removed the "proprietary parts" statement on that page?
<m-c> thanks
<ian_brasil> m-c: have a look at http://lists.maemo.org/pipermail/maemo-developers/2008-May/033234.html
<ian_brasil> dsme & mce, and the battery management are all closed
<ian_brasil> and the  WLAN module and FW too are closed
<ian_brasil> there is some discussion that Nokia provides one person whose sole task is to support the
<ian_brasil> community by mantaining the closed code and providing new binaries that
<ian_brasil> link against recent libraries.
<m-c> How are you using the term 'closed' when you are talking about these devices?  Do you mean the hardware does not have an open specification?  Or do you mean Maemo requires a closed binary driver?
<ian_brasil> closed binary drivers but also that in order to do proper low level kernel development, one
<ian_brasil> needs also measuring tool and special boards that allow for precise
<ian_brasil> measuring of what the sw is doing. Nobody in the community has such
<ian_brasil> setup,
<ian_brasil> so there is a dependency on some Nokia support
<ian_brasil> having said this there are projects such as Mamona 
<ian_brasil> which are creating a totally open system based on OE
<m-c> Well, I have no disagreement that nokia keeps maemo under close ties, like sun's linux projects, however, slighting another mobile distribution on the primary wiki over open / closed software does not seem friendly for potential developers.  Especially when the wifi drivers here will also likely be closed, because of the same restrictions.
<ian_brasil> i don't think it is a case of this...there is a lot of synergy between maemo and ubuntu communities [Full Disclosure: I work for Nokia]
<ian_brasil> and the guy who wrote that i am certain did not intend it to be seen in this way
<m-c> Well, feel free to revert the changes, if I am incorrect about my facts or you think the information was otherwise helpful.
<ian_brasil> m-c: OK, lets keep working on the synergies between the communities as well :)
<persia> m-c: Looking at the wiki edit, I think the previous state was more about the N800 HW being proprietary, rather than the software.
<ogra-ume> hrm ... midbrowser about dialog doesnt close
<m-c> That's how it seemed to me, too, and proprietary hardware is an ambiguous term.  Are there any open hardware solutions?
<persia> ogra-ume: There's a close button at about 540 vertical pixels.
<ogra-ume> well, how do i get there on a 480px screen ? 
<persia> ogra-ume: Well, that's the tricky bit.  Try pressing Enter or Escape.
<ogra-ume> lets see
<ogra-ume> yeah, that helped
<persia> It closes, but the mechanism is decidedly non-obvious.
<ogra-ume> th eodd bit is that i instinctively pushed the WM closebutton
<ogra-ume> which applied to the browser automatically
<ogra-ume> so i was left with the about win only
<ogra-ume> hmm
<ogra-ume> thats intresting, if i pull my power on teh laptop, i get a gnome-power-manager icon additionally to the battery thats already there in the panel
<ogra-ume> (virtualbox hands the unplug through to the ume VM it seems...)
 * ogra-ume checks the powermanager config
<ogra-ume> oh, you cant disable the icon completely
<ogra-ume> hmm, thats bad
<persia> On the other hand, plugging and unplugging didn't do that at UDS: at that point it was just the battery icon.
<ogra-ume> yeah, thats what its doing actually
<ogra-ume> but it results in two batteries
<persia> Except that I just replicated the extra icon appearance on my HW.  It now hides the brightness and volume tools when it is unplugged (which is odd, as this ought be the default state)
<ogra-ume> th elowest level you can set g-p-m to is critical, but that means it will still show on critical battery
<persia> Ah.  I don't think I ever got to critical battery.
<ogra-ume> ah, there is a gconf key called never that isnt exposed in the UI
<ogra-ume>  /apps/gnome-power-manager/ui/icon_policy never
<ogra-ume> that will avoid it
 * ogra-ume wonders how he's supposed to get rid of the alarmclock once that hogs the panel
#ubuntu-mobile 2008-06-07
<kidfoo> foo has an Asus EeePC, can foo use ubuntu mobile on it ?
<kidfoo> sorry
<ogra> persia, i think i got the PATH issue
<persia> lool: What was it?
<ogra> its tricky to solve though
<persia> ogra^^ 
<persia> (oops)
<persia> What's the cause?
<ogra> there is no session dbus running in your env 
<ogra> we need something like the script in this patch http://launchpadlibrarian.net/7170382/dbus_1.0.2-1ubuntu34.patch
<ogra> ++# GNOME gets it right: the session bus has to be started by the session
<ogra> ++# manager. Otherwise programs started by dbus do not get environment variables
<persia> Erm.  That's kinda tricky.
<lool> ogra: dbus-launch should be included by Xsession.d again
<ogra> i need to verify that first though, but i noticed you have no DBUS_SESSION_BUS_ADDRESS at all
<ogra> lool, right, but that needs some wrapping, remember se use ck-launch-session 
<lool> ogra: It's egg and chicken unfortunately
<ogra> yeah
<lool> ogra: ck-launch-session probably needs session bus as well
<ogra> yeah, dbus-launch should execute it
<lool> The underlying root cause is programs relying on env vars which are not guaranteed to be present
<lool> Instead, they should use some API e.g. dbus to retrieve the info they want
<lool> What GNOME does for e.g. keyring is that the keyring env vars are seeded into gnome-session via the g-k API
<persia> Yes, but that's hard! :)
<ogra> well, many of them do, thats why installing ntp fails
<lool> That's awful IMO, but it's needed if you want compatibility with programs which want keyring env vars or e.g. SSH_AGENT
<ogra> the installer seems to rely on getting PATH from dbus
<lool> What is the failing use case again?
<ogra> ntp
<lool> You install ntp, that calls synaptic?
<lool> Which programs needs which env var?
<ogra> set time-admin to automatic and it cant frind the deb installer
<lool> We could make sure it's started as part of the STARTUP
<ogra> not sure, is it synaptic ? 
<persia> lool: Start time-admin.  Authenticate.  Try to switch to NTP.  NTP isn't there, so it wants to install.  gst-package can't find synaptic because polkit-grant-helper doesn't reset the path.
<lool> Who triggers the installatoin?
<ogra> yes, STARTUP would be the quick hack
<persia> time-admin calls gst-package for the installation.
<eichi> hello
<lool> Is time-admin running as root?
<persia> No, time-admin can't run as root.
<persia> time-admin gets root powers through policykit
<eichi> when the n800 will be supportet by u-mobile?
<ogra> lool, the prob with STARTUP will be that we dont have a system bus yet
<lool> so time-admin talks to PK, does time-admin see the dbus session bus?
<ogra> the upstart script executes everything before rc2.d has run
<lool> ogra: Uh *system*?
<persia> eichi: There are two issues.  One is that some of the HW is ill understood.  No idea for that.  The other is that it is ARM architecture.  This has been discussed, but no timeline established.
<lool> I thought that was long solved
<ogra> lool, the session bus needs to connect to it
<eichi> okay, thanks
<lool> ogra: So at some point, Tollef added a delay to ensure startx is only called when sys bus is ready IIRC
<ogra> not sure what exactly happens if there is no systembus it can use
<persia> lool: It's not solved.  We'd have to change /etc/event.d/session to start on started rc2 to make sure the system dbus was there.
<persia> lool: The delay is gone.
<lool> Okayyy
<ogra> that will massively cost bootime
<lool> So we need a dependency, shuffling init scripts around, or a delay again
<ogra> :(
<persia> It used to be that ume-config-common started from rc2.d, and that worked, because it has a high value.
<persia> Now, we use /etc/event.d/session, and we don't wait for rc2 to complete.
<ogra> idealy we'd run dbus from upstart 
<ogra> i wonder if scott added the code to intrepid already so we could steal from there
<lool> ume-config-$platform ships this file
<persia> ogra: There's a bunch else we'd want to move to upstart if we're going to rely on upstart events.  I'd be a lot more comfortable with start on started rc2 for now.
<lool> How does one express a dependency in upstart?
<ogra> persia, any measures how much that time eats ? 
<lool> Upstart 0.5: Relationships uhoh
<persia> lool: You depend on an event.  "start on started rc2" expresses that the event should be processed once the "rc2" event has started completely.
<persia> ogra: I haven't run bootchart on it, but I'd say 15 seconds or so.
<ogra> it seems a) that scott is actively working on upstart dbis integration but far from being done and b) that the old Xsession script is still in the dbus source
<ogra> phew
<ogra> 15secs
<lool> persia: I have start on runlevel 2
<persia> lool: Some relationships work in upstart 0.3.9
<ogra> lool, right you need "start on started"
<persia> lool: Right.  So, upstart is the system init daemon: there is no "runlevel 2".
<ogra> that will delay it
<lool> We could have start on started dbus
<ogra> then upstart would need to handle dbus first
<persia> We pretend there is a runlevel 2 by having an rc2 event that maps to sysV style runlevel 2, called "rc2".
<persia> We can choose to either start on the trigger that starts this event, or start when this event is completed.  I favour the latter, but it costs us time.
<persia> For comparison, my Zaurus takes about 5 minutes to boot, but I almost never actually shut down.
<lool> If session dbus needs system dbus, then I think starting after system dbus is not later than the earliest we can start
<persia> lool: Right, but we can't determine when that happens with that level of granularity with the current model.
<ogra> other way round :)
<ogra> err
<ogra> sorry
<ogra> misread
<persia> We can either migrate /etc/event.d/session back into /etc/rc2.d/ or we can start on started rc2
<ogra> and we need the Xsession script back
<persia> If we migrate it back in, we're depending on the other calls in rc2.d to get the timing right.  If we use upstart, we wait for all the calls in rc2.
<lool> persia: So you're saying we can't say "started dbus" with upstart 0.3?
<persia> lool: We could say it, except that there's no dbus event defined by default, so it would never start.
<ogra> i dont think upstart knows about dbus without handlig it itself
<lool> Oh ok; I thought it had emulation
<ogra> thats the work scott is just doing in intrepid
<persia> We'd have to migrate dbus to upstart.  As I understand it, not enough of the precursors are done for this to be the case even in intrepid.
<lool> ogra: right, that's what I was fearing initially
<lool> ogra: Well we could invoke-rc.d dbus start before startx
<ogra> yeah
<lool> -ogra
<persia> The emulation is one-way.  upstart emulates sysV init, but our sysV init scripts aren't emulating upstart
<ogra> thats what i thought as well this moment :)
<persia> Why do we want to invoke-rc.d dbus in /etc/event.d/session?
<ogra> no
<ogra> in the ume-config-common script
<persia> Won't that cause resource contention with the /etc/rc.2/S??dbus ?
<persia> ogra: Right.  Same result though.
<lool> It looks like it would be a bit racy, but would probably work
<ogra> right, we need to mv it from S to K
 * persia advocates start on started rc2 more forcefully
<ogra> 15 secs ? 
<lool> persia: If there's enough delay, it would simply notice that it's already started
<persia> Sure.  How often do these things get shut down anyway?
<persia> We don't provide any interface to shut down: it has to be done manually from the command line.
<lool> I'm not at shutdown yet
<persia> OK, boot time only matters if one shuts down, otherwise it's a one-time event.
<lool> But we're going to be benched on boot time, not on shutdown time
<lool> And the measure is "UI fully functional"
<persia> Paying 15 seconds for a one-time event to do it in a way that is correct, and allows us to just s/rc2/dbus/ to keep it correct for hardy isn't so bad.
<persia> lool: My argument is that boot time is meaningless.  Users will only boot when they get the device, when we give them a new kernel, when they upgrade to a new release, or when they install a new battery.  Everything else is hibernate.
<ogra> argh, meh
<ogra> we cant do it from ume-gui-start
<ogra> that would be executed by dbus-launch from the Xsession script 
<persia> No, it has to be from the init daemon.
<ogra> i dont think dbuslaunch can run the system bus
<ogra> right
<lool> What were the arguments against the invoke-rc.d dbus start in the event session start script?
<ogra> i dont think upstart can interpret that
<persia> Race condition with /etc/rc2.d/S??dbus
<persia> ogra: in the event script, not as an upstart directive.
<ogra> well, thats eaily solved by mv /etc/rc2.d/S??dbus /etc/rc2.d/K??dbus
<lool> Or by adding a lock file
<lool> Anyway, I'm fine to move this to "rc2" started if it doesn't degrade boot time
<lool> We're at 32 seconds ATM, quite close to the limit
<ogra> another option would be to move half the world to rcS.d
<persia> ogra: That's a really ugly hack though
<lool> Or move dbus to upstart :)
<ogra> lool, which isnt ready yet :)
<persia> Doesn't dbus have dependencies that need to also move to upstart?  That's a lot of work for a short timeframe.
<persia> Definitely an intrepid target
<lool> We could also busywait in the session event start script until runlevel is high enough
<ogra> ask Keybuk, i may be wrong, but the changelogs in intrepid look like he's in the middle of it
<ogra> but not done ...
 * persia wants lool's hardware.  Boot time is 1min by default with the SR8
 * ogra wants HW at all :P
<ogra> but i'll get my atom cmpc next week ...
<lool> persia: You don't really want a menlow/crownbeach
<persia> lool: Right, I just want the chipsets, but in a sexy form-factor :)  One more week, if I can get in line early enough.
<persia> Right.  It's impossible to install bootchart.  Time for a new image...
<ogra> hmm
<lool> persia: if you have the occasion, test an USB install image created with a recent MIC
<lool> I'd like to confirm /boot is properly mounted and usable
<ogra> just adding the Xsession script seems to suffice
<persia> ogra: I just tested with start on started rc2 anyway, rather than building new images, and policykit still doesn't change the path.
<lool> persia: Also, that's probably what blocks you from installing bootchart I'd guess
<ogra> i got a session bus variable now
<persia> It's not just about dbus not being available.  I think we need to also start a session dbus somewhere.
<lool> persia: dbus-launch should be appended in Xsession.d; it might not be if Ubuntu drops that
<lool> Also, dbus session busses are autospawned
<persia> lool: The issue with installing bootchart is that initrd.img isn't in /boot, but in /
<ogra> i just copied the Xsession script from the dbus source to 75dbus_dbus-launch
<persia> lool: What autospawns it?
<ogra> seems to be enough to get a proper session bus
<ogra> persia, the upstart script if it is in Xsession.d
<persia> ogra: Then the lack of a session bus, while possibly an issue, isn't the reason policykit doesn't work.
<ogra> upstart respawns startx
<ogra> startx executed Xsession.d every time
<ogra> persia, yes, i just noticed, the PATH is still wrong :/
<persia> 90-console-kit?
<ogra> as i said in the beginning i didnt verify yet
<persia> heh :)
<ogra> so my next hunt goes one level deeper .... 
<ogra> lets look what pam and su do 
<ogra> especially pam_env.so
<ogra> if nothing helps we can just source /etc/environment at the top of the ume gui script but thats extremely ugly and does hide the actual cause
<persia> ogra: Let's reserve that as a hammer if other things don't work.
<ogra> yeah, its ok as emergency fallback
<ogra> and works fine, just tested that
<ogra> the pam setup looks identical to my laptop ...
<ogra> :(
<persia> I suspect it's something gdm-ish, but investigation of gdm didn't get me anywhere.
<ogra> it should be set by su
<ogra> or rather by pam if su is executed
<persia> Except we're not using su, so it should be set by one of the polkit-grant helpers
<ogra> sure we use su
<persia> (which annoyingly hardcode it, rather than using ENV_SUPATH like they ought)
<ogra> in the event.d/session script
<ogra> exec su -l ume -c "/usr/bin/startx -- -dpi 96 -br"
<ogra> thats what mine has
<persia> ogra: Right, but we su to a uid != 0, so pam gives us ENV_PATH rather than ENV_SUPATH
<ogra> and /etc/pam.d/su has "session       required   pam_env.so readenv=1"
<ogra> which tells pam_env to read the default file ... which is /etc/environment
<ogra> afterwards it does "session       required   pam_env.so readenv=1 envfile=/etc/default/locale"
<ogra> which works properly here in my german setup
<persia> Hrm.  That ought work :/
<ogra> hmm, no, wait
<ogra> /etc/default/locale is used in several initscripts as well
 * ogra inspects
<persia> /etc/default/locale ought be used all over the place.
<ogra> AHA !!!
<ogra> gdm sources /etc/environment in its initscrip2
<ogra> *script
<persia> Oho!  In that case hacking it into /etc/event.d/session isn't such a big club after all...
 * persia tests
<ogra> yeah
<ogra> well, put it in the ume script
<ogra> i just did that before, works perfect
<persia> You mean /etc/X11/Xsession.d/25-ubuntu-config-common_startup?
<persia> Or ume-gui-start?
<ogra> ume-gui-start
<ogra> right at the top
<ogra> hmm, k, next prob, after instlling ntp time-admin switches back to manual in the gui
<persia> Right.  Testing again, and will commit.
<ogra> bah, it doesnt set a default server either
<persia> default server?
<ogra> on next start time-admin *has* auto selected but has no default server
<ogra> well, ntp needs to pull from anywhere
<persia> Right.  That's a long outstanding bug in g-s-t
<ogra> well, i'D blame ntp rather
<persia> No, it's g-s-t.
<ogra> sudo ntpdate doesnt work either
<ogra> it should use a default
<persia> NTP has servers by default, unless you run time-admin, and don't set servers.  time-admin clears the server list.
<ogra> then the time-admin case ismoot
<ogra> gah
<ogra> evil
<ogra> we also really should set polkit to accept time-admin chages by default without authentication
<ogra> seems silly that you have to give your pw every time
<persia> Makes the standard MIC password handy.
<ogra> (especially if you have to type on the onscreen kbd)
<ogra> well, polkit has a setting to just allow it per app
<persia> Bah.  I can't find the time-admin/ntp bug right now.  I was looking at it a couple days ago.
<ogra> its not that we have massively many users on such systems :)
<persia> No, but the use case is such that it's easy for someone else to hold it for a few minutes.
<persia> I regularly pass my Zaurus to someone to show them something, or let them type something.
<ogra> and ? 
<ogra> he can set your time 
<persia> Might be different if everyone had one, but...
<persia> Ah, yes.  Per-app.
<ogra> right
<ogra> and synaptic will still ask
<persia> (and on the Zaurus, it never asks for those things, just runs them as root if required, anyway)
<ogra> its just that you dont have to be asked every time if you want to adjust to a new TZ or so
<persia> synaptic doesn't ask.  gst-package asks.
<ogra> g-s-t is a pile of crap anyway, i know seb makes some attempt to get rid of them in intrepid
<ogra> (adding a default group to users-admin to be shown in the gui makes your eyes bleed ... its really evil, hardcoding all options teh user sees there)
<persia> ogra: gst-package caches the password.  You have to enter it every time to set the time, but only once in a while to install/update/change packages.
<persia> Maybe this isn't the ideal model?
<ogra> thats polkit
<ogra> gksu is what caches it, polkit doesnt deliberately
<ogra> or rather sudo caches it, gksu just inherits
<persia> Ah, so gst-package is calling gksu, which does the caching.
<persia> Right.  That makes sense.
<persia> Still non-ideal, but...
<ogra> polkit is crap isf you ask me
<ogra> but i'm not upstream
<persia> Why do we use *kit again?
<ogra> and they decided to go with it
<ogra> the apps start to require it
<persia> I'm really not sure GNOME is very UNIXy, but that's a different issue.
<ogra> more and more upstream gnome apps switch to that model
<persia> Anyway, E isn't much these days, so...
<ogra> yeah
<ogra> its surely still not properly multiuser
<persia> Not multiuser.
<ogra> you would runs away screaming if you would see all the hacks we did for early ltsp5 implementations to even make i work :)
<ogra> its gotten better over time
<ogra> but is still not there
<persia> Each app has lots of features, instead of there being lots of features that can be exposed in apps (this is slowly improving, but in an odd way)
<ogra> yeah
<persia> I did look at early ltsp stuff.  I haven't looked at it since, perhaps because of that :)
<ogra> ltsp5 != ltsp :)
<persia> There are lots of different communication buses, rather than following the "everything is a file" rule.
<persia> Anyway, enough GNOME bashing: I've been a GNOME user for years, and I'll likely stay that way for a while more...
<ogra> well, i for one would be happy if it could work on a per session base and if every app had a proper distinction between front and backend
<persia> ogra: Where's your initrd.img?
<ogra> ?
<ogra> which one now ? 
<persia> In your ume install?
<persia> Mine is in /, which means NTP can't install.  I wonder if I'm special.
<ogra> in /boot
<ogra> the one in /should only be a link
<ogra> update-initramfs expects it in boot
<ogra> and i guess u-a is run from ntp postinst
<persia> Yeah.  I'll check a different image: this one mignt not be right.
<ogra> err
<ogra> u-i
<ogra> :)
<persia> Yep :)
<ogra> ah, wonderful, alarmclock has a quit button now
<ogra> but lost the settings entry so i cant switch back to analog :/
<ogra> hmm, and the notification window doesnt go away
<ogra> just sits in the middle
<persia> Yeah, well.  The notification goes away if you start the app.
<persia> s/app/settings window/
<ogra> well, there is no settings wi anymore
<ogra> it only goes away if i start aother app
<ogra> *another
<ogra-ume> the same happens if i start pidgin while already having it open
<ogra-ume> i guess sapwood doesnt get the right info here
<ogra-ume> where the heck is that thing documented ... hrm
<ogra-ume> hmm, no ..
<ogra-ume> i thought sapwood was responsible for apps to only be launched once 
<ogra> geez
<ogra> closing pidgin crashed my desktop
<persia> How?
<ogra> gah, its reproducable
<ogra> only happens if i'm looged in to any IRC channel though, not if you just open/close the app
<persia> Can you get a backtrace?
<ogra> strace first ... http://people.ubuntu.com/~ogra/pidgin.log
<ogra> write(2, "pidgin: Fatal IO error 104 (Conn"..., 72) = -1 EIO (Input/output error) looks suspicious
<persia> That doesn't look so bad for closing an app.  There's an error, but it's relatively minor, as the app is shutting down anyway.
<ogra> eek
<ogra> there is no bonobo server running at all ? 
<ogra> that wont work
<persia> It's a low-resource machine.  See my previous comments about GNOME :)
<ogra> yeah, but pidgin uses boobo for internal communication iirc
<persia> Right.  That might explain the previous existence of moblin chat.
<persia> On the other hand, I suspect a backtrace will show you that the Hildon libraries aren't very robust.
<ogra> hmm, even with bonobo in place it crashes
<persia> The whole desktop, or just pidgin
<persia> ?
<ogra> the whole desktop
<ogra> X restarts
<persia> Right.  Blame the hildon libraries.  They ought trap the segfault, and not die.
<ogra> but we shouldnt have a segfault first place
<persia> The issue is that when hildon-desktop crashes, it takes down X, because of startx and the session scripts.
<ogra> i surely dont get one with pidgin in a normal desktop
<persia> No, but lots of apps segfault.  Dropping back to the regular desktop is the least painful way to handle it.  A segfault oughtn't kill X.
<ogra> no, works just fine on my laptop
<ogra> bonobo is installed but not runing
<ogra> (in ume)
<ogra> hmm, getting a backtrace is pretty hard without being able to get pidgin-dbg 
<ogra> (it uninstalls half the desktop)
<ogra> and indeed it tears down gdb with it if i start it from xterm
<ogra> intrestingly it doesnt respawn with gdb running
<ogra> uuuh, i'm blind
<ogra>  /usr/share/autostart/xhost.desktop ??
<ogra> hmm. seems thats needed but appaears quite odd not to properly use xauth for that
<lool> So hmm
<lool> I have a small issue
<lool> ogra: Can I discuss keyring stuff with you?
<ogra> sure, if i can help
<lool> Basically, ubuntu-keyring ships a keyring file at a special place and then calls apt-key update in postinst
<lool> apt-key only checks this special place
<lool> I am creating a keyring for UME
<lool> The package is named differently and names the keyring differently
<lool> But the keyring file isn't picked up
<lool> Option 1), apt-key add the new keyring manually
<lool> opens: do we want to apt-key remove <key id> on removal? not sure
<lool> It's also weird because you don't get a real "main archive keyring"
<lool> option 2), use the same package name and the same file name, call apt-key update
<ogra> just call apt-key add in the postinst ? 
<lool> cons: prevents installing the main keyring, generally mixes package names for the different things
<lool> pluses: works fast and easily
<lool> ogra: So option 1?
<lool> That's also my preferred for now
<lool> But I wonder whether that's sensible
<ogra> yeah, thats what i'd go with
<lool> I also tried looking into other options, such as adding the keyring to the list of places apt looks at, but I couldn't find any config item for it
<ogra> well, i'D do it for now and ask mvo then, nobody knows more about apt and keys i guess
<lool> Ok, that was my plan, will have to wait until monday then
<ogra> but the apt-key add method seems cean if we cant get it into the main keyring
<lool> ogra: Also, do you have any idea why I'd get W: Failed to fetch http://archive.mobile.ubuntu.com/dists/um-ppa-hardy/Release  Unable to find expected entry  main/binary-lpia/Packages in Meta-index file (malformed Release file?)
<lool> Hmm perhaps it strictly needs Packages
<lool> Oh, I copied the list of files from the ppa example, but there's no Package there
<lool> ogra: nm, fixed
<lool> Cool, everything works
<lool> Now copying packages
<ogra> the keynames are hardcode in the /usr/bin/apt-key script btw
 * ogra beats pidgin over the head
<lool> ogra: Yeah, hardcoding is *baaad*
<ogra> well, in case of gpg i can understad that :)
<ogra> what i dont understand is why pidgin crashes my ume desktop :/
<ogra> i guess i need to build a dbg packae myself, sigh
<lool> ogra: apport should work BTW
<ogra> oh, right
<lool> ogra: I see a pidgin-dbg
<ogra> yes, with wrong deps 
<lool> Now I only need to find the latest version of the report script
<ogra> i would need a pidgin-maemo-dbg i guess
<ogra> hmm, apport doesnt start
<ogra> hmm, cant work, the kernel doesnt know about crashdump-size it seems
 * ogra goes to do some lawn mowing ... to probably have an idea
<lool> ogra: /etc/init.d/apport start should DTRT
<lool> unless our kernel dropped this support
<ogra> looks like it did
<ogra> no crash reports in /var/crash
<lool> ogra: Try with -18
<lool> ogra: The only one which doesn't have this support can only be -17 from the ppa
<lool> -19 might miss it as well though
<lool> Ok, so I think I finished the archive
<lool> Wow MIC still defaults to ... gutsy
<emgent> heya
#ubuntu-mobile 2009-06-01
<persia> Nifty product: http://www.dynamism.com/#Product=umid
<erdbeere> Text hier eingeben...
<erdbeere> hallo
<persia> erdbeere, Hello.
<erdbeere> kissssssssssss
<erdbeere> hallo bin esmina
<erdbeere> hello
<erdbeere> ist niemand da
<erdbeere> schade
<persia> !de
<ubottu> In den meisten ubuntu-KanÃ¤len wird nur Englisch gesprochen. FÃ¼r deutschsprachige Hilfe besuchen Sie bitte #ubuntu-de, #kubuntu-de, #edubuntu-de oder #ubuntu-at. Geben Sie einfach /join #ubuntu-de ein! Danke fÃ¼r Ihr VerstÃ¤ndnis.
<persia> GrueMaster, Main reasons to have the meeting here: 1) it's not very busy, and 2) it's more of a working meeting than anything else: I have *no* idea how long it will last.
<YokoZar> When I switch between UNR and Classic desktop mode on my girlfriend's EeePC it spews out some errors and maximus never manages to relaunch (serious bug)...what do I file this against?
<chaos2fu> do u loose your panels?
<YokoZar> chaos2fu: yeah it seems to be this bug: https://bugs.launchpad.net/ubuntu/+source/maximus/+bug/373696
<ubottu> Ubuntu bug 373696 in maximus "After using desktop switcher, maximus stops working" [High,Triaged]
<chaos2fu> yeah exactly...its a well-known bug, and thats only the small bug-report, theres a bigger one...
<chaos2fu> there is one solution i have read about, its a fault in the gnome-login-manager...
<chaos2fu> and it could be fixed quite easy, search for google cause i dont have it here right know...
<YokoZar> hmm I can't find a bigger bug report atm
<chaos2fu> https://bugs.launchpad.net/netbook-remix/+bug/335730
<ubottu> Ubuntu bug 335730 in netbook-remix "panel disapears with Maximus activated (Jaunty + Metacity with compositor)" [Undecided,Triaged]
<chaos2fu> here u are, the bigger one...!;-)
<chaos2fu> https://bugs.launchpad.net/netbook-remix-launcher/+bug/326341
<ubottu> Ubuntu bug 326341 in desktop-switcher "Jaunty - Switch Desktop does not function properly (dup-of: 349519)" [Undecided,Fix committed]
<ubottu> Ubuntu bug 349519 in desktop-switcher "Switch Desktop Mode corrupted settings" [Undecided,Fix committed]
<chaos2fu> and it twins....
#ubuntu-mobile 2009-06-02
<lbt> Hello from Mer
<NCommander> lbt, hello from Ubuntu!
<YokoZar> hello thar
<Stskeeps> <- here too
<YokoZar> *bangs gavel, announces we'll probably wait a few minutes while everyone gets here*
 * persia waves and rushes to paste some text
<NCommander> Oh, right, we have that meeting!
<persia> Ah, looks like YokoZar already pasted :)
<YokoZar> hello hello
<Stskeeps> and we have maemo.org council chair (jaffa) listening in as well
<persia> Hey Jaffa 
<Jaffa> Hiya
<Jaffa> At JavaOne, so mostly just reading :)
<YokoZar> All right
<YokoZar> Let's do introductions.  Who's here for the meeting then?
 * YokoZar is Scott Ritchie, an Ubuntu Developer
 * persia is Emmet Hikory, an Ubuntu Developer
 * lbt is the build/sdk/process/packaging/docs non-expert for Mer
 * 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
 * lbt is David Greaves
 * NCommander is MIchael Casadevall, an Ubuntu Developer, and a Mer user
 * ian_brasil me
<YokoZar> :)
<NCommander> ;-)
<GrueMaster> GrueMaster - Ubuntu Mobile QA testing.
 * Jaffa is Andrew Flegg, Maemo Community Council chair
 * qwerty12_N800 is Faheem Pervez, a packager and hacker of code (my knowledge isn't extensive enough to say I'm a programmer)
<GrueMaster> Oh, Tobin Davis.  (oops).
<luke-jr> (is the meeting open, or restricted?)
<YokoZar> open
<NCommander> (the meeting is open)
<YokoZar> All Ubuntu meetings are, generally (except security issues)
 * luke-jr is Luke Dashjr, a developer for the unofficial Gentoo N8x0 port
 * lcuk is Gary Birkett, author of liqbase (n8x0 device ui)
 * rgreening is lurking, but has $WORK in the way. need to restore broken network...
<YokoZar> Ok, nice, we have quite a few people here
<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.
<lbt> I got this as an outline http://pastebin.com/d7c524616
<YokoZar> lbt: yup, that's the agenda more or less
<YokoZar> Everyone, please feel free to ask any questions you have as we bring things up, this meeting is about all of us learning
<Stskeeps> *nod*
<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
<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.
<YokoZar> NCommander: I agree
<YokoZar> Mer, as I understand, won't be a typical upstream like I just mentioned ;)
<YokoZar> Instead we want to work a bit closer
<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 :-)
<lbt> YokoZar: process makes sense and aligns
<lbt> but layered diffs is an interesting area...
<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 :)
<Stskeeps> ideally ubuntu packaging would be == mer packaging
<Stskeeps> as in, the cleaned up ubuntu packaging ;)
<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
<lbt> yes
<lbt> we'd like that
<lbt> although the maemo packages include /debian
<persia> lbt, Would having the packaging outside the Mer repos block your builds for the Mer cycles?
<lbt> and that may need .... tweaking
<persia> (e.g. stripping the Maemo debian/)
<Stskeeps> stripping maemo debian/ should be possible
<NCommander> Stskeeps, well, OBS will build any package that Ubuntu can, so once the packaging is brought up to scratch, that will work fine
<persia> I'm just concerned about not blocking Mer test cycles by doing so.
<lbt> I am looking at introducing a (git) VC system to do this
<Stskeeps> basically: we are in the midst of cleaning up our act, so we are -very- open to changes
<lbt> and managing the seperation of src,diff,/debian
<YokoZar> lbt: Yes, it's also possible to have the debian/ folder live inside a branch
<lbt> indeed
<Stskeeps> we would also like to find a good way to deal with upstream (and we discussed this a bit with nokia)
<lbt> http://wiki.maemo.org/Mer/Documentation/Mer_Package_Patch_Handling
<YokoZar> lbt: indeed this is what much of the "use bzr for more things" push is about in Ubuntu
<lbt> in principle the 1 branch per patch approach works for me
<Stskeeps> well, or simple quilt patch management
<lbt> and 1 branch per packaging flavour
<lbt> then export that into quilt
<YokoZar> Quilt is very nice for this sort of thing
<k-s> well, most top level packages should rely on the same dependencies and all, so the diff would be just about changelogs, no?
<k-s> lower level packages have (or used to) different dependencies as maemo used different names
<lbt> i'm open... was looking to setup VC for developers and take branches into quilt for /debian/patches
<lbt> we have quite a few code and build patches
<NCommander> Stskeeps, YokoZar I'm not sure if your aware, but quilt can be intergrated into the package build process
<YokoZar> NCommander: yes, in fact this is where I thought it most powerful
<YokoZar> NCommander: the build script just applies the quilt patches at build time
<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)
<YokoZar> (and unapplies them at package cleanup time)
<NCommander> YokoZar, yup :-)
<lbt> yes
<lbt> and for me .... each /debian/patches/ file comes from a VCS branch
<persia> NCommander, Except we're dealing with stacked trees, because Mer itself is, in part, a set of patches against Maemo
<NCommander> persia, VCS import the Maemo trees, and then stack off that
<NCommander> If possible
<lbt> yes...
<lbt> master branch is .orig
<Stskeeps> we'd really really want to base on tar.gz's, you can't rely on the vcs
<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?
<persia> Stskeeps, pristine-tar can help with coordination between tar.gz and VCS repos.
<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.
<Stskeeps> persia: interesting, didn't know that (per upload)
<persia> NCommander, Yes, but we don't prefer it.
<NCommander> persia, this is a unqiue case ...
<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
<YokoZar> It's not too hard to have one changelog entry with a bunch of bits to it
<Stskeeps> we can however also work on a way to merge multiple versions into one upload for instance
<lbt> big changelogs though...
<lbt> we may need to manually summarise
<Stskeeps> we can however be happy we're at a stage where we aren't patching much anymore.
<persia> Indeed.  That's supported, but I think a manual summary would be preferred.
<YokoZar> Do you give version summaries already?
<YokoZar> Or are your release changelogs just big lists of commits?
<lbt> commit list
<lbt> if anything :)
<Stskeeps> currently our packaging is occasionally a mess, and the changelog reflects the changes
<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.
<Stskeeps> well. we can always abuse that mer < ubuntu lexically..
<Stskeeps> so ubuntu4 would wrap certain mer versions
<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)
<YokoZar> (I mention this because it's exactly how I package Wine, and it comes out every 2 weeks)
<lbt> we could do that
<lbt> hmmm
<lbt> we should do that
<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 ;)
<lbt> we are still building processe and supporting scripts
<Stskeeps> when dealing with the maemo packages we are mostly doing patches and not so much our own development (yet - it's getting there)
<lbt> we only just transitioned to OBS
<lbt> and I'm in the process of setting us up to handle logging these changes.
<lbt> we don't use (AFAIK) the OBS commit messages
<lbt> which are (in my case) cut'n'paste from local git repos
<lbt> so we (I) need target specifications
<YokoZar> Stskeeps: that's cool, there's no requirement that changelog entries be interesting ;)
<qwerty12_N800> Is swearing frowned upon in changelogs?
<Stskeeps> ah, yeah, we might want to filter some. :P spending too much time with maemo packages makes you do stupid things.
<YokoZar> qwerty12_N800: heh -- probably not wise in the summary, but ok in commit messages ;)
<lbt> persia you said : I suspect we only want one or two Ubuntu uploads per Mer cycle.... 
 * lcuk sighs with relief
<lbt> did you mean 1 or 2 Mer cycles between uploads?
<persia> lbt, Just a loose guess.  One right before the testing phase, and one at cycle completion.
<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)
<YokoZar> (they see this in update-manager)
<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.
<lbt> OK ... so upload when we promote our first :Testing
<persia> lbt, That was my thought, but I'm open to alternate suggestions.
<qwerty12_N800> YokoZar: yeah, I allowed my frustration to get the better of me. I'll try and find those changelogs...
<lbt> persia.... why?
<Stskeeps> basically, what we hope to start with is simply to slowly start moving packages to "new" workflow. beginning with libosso and libhildon
<NCommander> THat's actually something I wanted to bring up
<Stskeeps> and getting also upstream relations going (libhildon is open to different packaging based off their git trees, and is open now.)
<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)
<persia> lbt, Why which?  Why two uploads, or why am I looking for alternate suggestions?
<lbt> our :Testing can be quite... raw
<lbt> so if you intend to publish to end users then it may be good to go for :Testing2
<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.
<persia> NCommander, current MID upstream doesn't support the current codebase anymore.  I don't think we need to worry about it much.
<NCommander> persia, I'm more worried about libhildon's rdepends.
<Stskeeps> NCommander: our libhildon is mostly pure
<NCommander> StevenK, our libhildon is ancient
<lbt> persia... l8r
<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.
<persia> lbt, Catch me anytime :)
<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)
<Stskeeps> if you're wondering if dates-hildon still work, it does :P
<Stskeeps> we have a transformational package to help support your naming, but it's not that nice
<persia> NCommander, Hrm.  Probably worth a review of rdepends then, indeed.  I suspect we'll want to keep some of them.
<NCommander> persia, agreed, but I can think a few we can toss as well
<k-s> NCommander: wonder tha same
<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
<k-s> packages like gnumeric and other hildonized... what todo? two versions that conflicts?
<lbt> are these hildonisations not from Nokia?
<Stskeeps> nah, ubuntu mid ones
<Stskeeps>  / moblin
<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.
<lbt> OK, so if you want to push these into Mer then they'd need maintainers I guess
<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.
<persia> lbt, I think it's on a per-package basis: not all of them are useful, but some are nice.
 * k-s hates the hildonization, it's the worst thing ever... pointless
<NCommander> k-s, +1
<persia> NCommander, I do believe I'm actioned to do just that on https://wiki.ubuntu.com/Specs/MobileMidKarmicUseMer :)
<Jaffa> A lot of the Hildonised apps from Ubuntu MID old would be good to go -> Mer, and maybe -> Maemo
<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)
<k-s> it's just there because Nokia used to want hildon as closed source extension
<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
<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.
<lbt> I think that is no longer a problem?
<k-s> proper engineer would be to patch gtk to provide better widgets for finger use
<NCommander> brb, battery flashing signs of death
<persia> I think I like autohildonisation better.
<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 :-/
<Stskeeps> we encourage hildonization because there's a little more to it than just UI
<k-s> Jaffa: ok, but then it's not hildonization as change toolbar or menu, but *new* ui
<Stskeeps> such as the libosso stuff
<lbt> yes
<persia> Jaffa, Trick is in maintenance: we don't really want to have to carry two versions of e.g. the gnumeric codebase.
<k-s> Stskeeps: libosso is also bs
<lbt> very few apps are hildonised
<lbt> Nb... Qt is trying to hildonise the framework
<k-s> Stskeeps: yet-another NIH
<k-s> lbt: yes, andthat is transparent to users
<lbt> yes
<Stskeeps> k-s: admittedly things could have been better
<Stskeeps> but some of the signals that it gets are useful for mobile usage
<k-s> anyway, most (or all) of this will be dead soon
<Stskeeps> care to elaborate on that?
<NCommander> BTW, I think another point worth bringing up is what architectures do we care about w.r.t to Mer
<NCommander> (side note but important)
<k-s> Stskeeps: i see this going away, I have inside info on the topic, but cannot disclose much :-P
<YokoZar> NCommander: agreed
<lbt> (nb k-s  I didn't catch your introduction)
<Stskeeps> k-s: ah, harmattan probably
<Stskeeps> NCommander: we're agnostic to architecture as such (if we see it on package level)
<k-s> lbt: I'm Gustavo Barbieri, used to work at INdT, architect and lead developer of canola 1/2
<NCommander> Well, this case is kinda special because of the way ubuntu-mid was handled
<lbt> :) ta
<GrueMaster> Arch wise, we should focus on the two mid architectures (x86 & arm).
<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
<k-s> lbt: now owner of ProFUSION embedded systems, which do contract for Canonical and couple of other companies on embedded/mobile field
<persia> GrueMaster, i386 & armel ?
<GrueMaster> In otherwords, no IA64 ports for NCommander.
<NCommander> Right, I agree, but we're also going to get amd64, sparc, and ia64 for no added cost :-)
<NCommander> and powerpc
<Stskeeps> our wii port would be happy for powerpc ;p
<NCommander> \o/!
<YokoZar> mobile wii?
 * NCommander tried to run Ubuntu MID a long time ago on his wii
<Stskeeps> mer on wii: http://smg.photobucket.com/albums/v119/JohnX/?action=view&current=CIMG5444.jpg
<Stskeeps> (missing background)
<YokoZar> My Wii got mobile when my brother threw it against the wall in frustration.  Anyway...
<k-s> YokoZar: lol
<Stskeeps> but anyway, we are in no way restricting what archs to build on - all that stuff is in our HW support repos
<NCommander> (it should be noted for the record that there is an Ubuntu PS3 port so ....)
<persia> So, I think we covered 1.1 and 1.2 on the agenda.  Shall we go to 1.3?
<NCommander> That's sexy :-)
<GrueMaster> For testing purposes, I am limited to i386/lpia, and arm.
<YokoZar> persia: That was my thought.  Any more questions on work flow?
<NCommander> GrueMaster, I thought you had an amd64
<NCommander> (not that we really care but)
<Stskeeps> regarding Mer and work flow, lbt is the guy to talk to from us, he's in charge of developer tools etc :)
<lbt> persia http://wiki.maemo.org/Mer/
<GrueMaster> NCommander: It is dedicated to LSB testing.
<lbt> that is the root for our info sources
<Stskeeps> so he'll gladly sit down with some of you and get a workflow worked out that suits us all
<NCommander> persia, where's the agenda? I don't see it on the wiki
<lbt> yes indeed
<YokoZar> I think the consensus seems to be (1: small changelog improvements, 2: use quilt whenever we can
<lbt> agenda : http://pastebin.com/d7c524616
<Stskeeps> NCommander: http://pastebin.com/d7c524616
 * lbt scores
<lbt> YokoZar: I would like to work a git->quilt process too
<YokoZar> lbt: Ok, that shouldn't be too hard (takes only a few commands when done manually I think)
<Stskeeps> regarding upstream libhildon info: https://garage.maemo.org/projects/hildon
<lbt> I'm not sure we sorted the stacking issue
<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?
<lbt> yes
<lbt> heck.... you could share gitorious 
<Stskeeps> yes, the question is how to handle orig.tar.gz .. would they be the maemo source with debian/ stripped? :P
<YokoZar> lbt: Are there scripts out there for that already?  Because that sounds really cool
<lbt> or setup a gateway
<YokoZar> True
<lbt> Stskeeps .... implementation..... but handled in master
<Stskeeps> (for their native packags)
<lbt> and probably stripped to master-debian
<lbt> and maybe branched from there
<lbt> or forked
<lbt> make sense?
<YokoZar> Yeah
<lbt> OK... does that handle stacking?
<lbt> I worry about patches being patched
<lbt> I do this
<lbt> it hurts
<Stskeeps> okay, so, what do you mean about sources of information?
<Stskeeps> about/with
<persia> I think we can avoid the patching-patches issue by restricting Ubuntu delta to debian/changelog
<lbt> OK
<YokoZar> If git handles the merging of the stacked patches, then whatever git spits out should be handled by quilt I think
<persia> Except post-feature-freeze, when we use patching-patches *intentionally* to backport specific targeted bugfixes.
<YokoZar> Yeah persia is right there
<lbt> OK... I need to learn this....
<lbt> I see gtk2.0
<lbt> nm... l8r
<Stskeeps> l8r meaning that we'll look at it later, i presume, and not that you're leaving ;)
<lbt> correct .. sorry
<YokoZar> so... "sources of information"
<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?
<Stskeeps> the question that keeps bugging me is simple: we're going to have really interesting times with maemo gtk vs no maemo gtk
<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)
<Stskeeps> YokoZar: we have our wiki, irc channel, and we microblog to mer-chatter mailing list
<Stskeeps> microblogging when we move on something and people recieve in digests
<Jaffa> persia: Roadmaps/blueprints/use-cases for karmic vs. Mer would be an obvious one
<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.
<Stskeeps> persia: you have other flavors? maemo gtk is sometimes considered an abdomination by some :)
<lbt> yeah ... the maemo-ised 'upstream' packages tend to freeze
<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.
<lbt> On the Mer side everything should be reachable from http://wiki.maemo.org/Mer/   .... is there a similar UbuntuMID root?
<Jaffa> persiia: I suppose I mean how strategic is UMID in karmic? Or is working in Mer and reshipping it going to be "OK"?
<Jaffa> lbt: http://wiki.maemo.org/Mer is the canonical URL, btw. But I put in a redirect on "Mer/", IIRC
<ian_brasil> https://wiki.ubuntu.com/MobileAndEmbedded maybe
<YokoZar> Jaffa: We like to avoid use of the adjective canonical to avoid confusion ;)
<lbt> (oops ... paste-o)
<NCommander> YokoZar, rofl :-)
<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.
<Jaffa> persia: fair enough
<Jaffa> YokoZar: point taken ;-)
<lbt> clarification.... do you intend to 
<persia> ian_brasil, I should take that URL down at some point :)
<lbt> apply all the Mer patches to Ubuntu,
<lbt> or take Mer code and patch it
<Stskeeps>  / branding?
<persia> lbt, apply all the Mer patches to Ubuntu
<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?
<Stskeeps> fair, themes
<Stskeeps> err, fairly, - themes
<Stskeeps> we don't brand beyond themes so
<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.
<ian_brasil> it should be quite easy to apply themes from what i have seen
<lbt> I'm worried about us not keeping up with newer versions than Maemo
<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.
<k-s> how do you plan to work with subsystems that are not present in ubuntu and AFAIK have no non-nokia backends
<k-s> like the battery subsystem
<Stskeeps> mce;dsme we have; battery is hal
<k-s> mce/dsme supports non nokia tablets?
<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.
<Jaffa> lbt: post fremantle release, rate of change upstream in Maemo should slow down (from Nokia, anyway)
<lbt> that is my concern....
<lbt> so Ubuntu gtk will progress
<Stskeeps> k-s: powerlaunch yeah; dsme does non nokia hw with some changes
<lbt> and we will slow
<Jaffa> lbt: ah, I see
<lbt> and then dependency hell bites
<Stskeeps> persia: atm maemo gtk is at 0.14 but 0.16 is in progress
<ian_brasil> YokoZar: i would like to build a web interface for that :)
<lbt> and those patch sets are not small
<persia> Stskeeps, 2.16?
<Stskeeps> er, yeah
<Stskeeps> on n810 atm so
<k-s> Stskeeps: is bme dead in favor of HAL (which is also dead...)?
<Stskeeps> k-s: no, but this doesnt relate much to ubuntu. we had meeting with nokia on hw support this weekend
<Stskeeps> with good results
<k-s> good
<persia> lbt, I think we'll just have to carry/port patches anyway, especially if Nokia's Maemo updates slow post fremantle.
<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
<lbt> persia: I suggested to Nokia that we become 'upstream' for their hildon...
<lbt> they may be able to help us port forward
<lbt> so that the next release is easier
<persia> That works.
<qwerty12_N800> k-s: apps using libosso to listen to battery low events, etc?
<lbt> 'suggested'
<k-s> qwerty12_N800: yes, or directly talking to bme et al
<persia> lbt, So Mer would end up generating tarballs, which Maemo or Ubuntu could use as a basis for packages?
<Stskeeps> k-s, we plan to support mce etc in a cross platform manner
<lbt> yes
<persia> I like that plan.  Very sustainable.
<lbt> and they want to open their development
<lbt> cf Trolltech/Qt
<lbt> on gitorious
<k-s> qwerty12_N800: not that I like bme/mce/... they're mostly NIH stuff
<lbt> so internally they point and say "like that"
<qwerty12_N800> k-s: mmm, same
<Stskeeps> noone speaks directly to bme-but thats a discussion for later.
<k-s> Stskeeps: i'd not assume that, Canola for example do that (but we have plugin to talk to hal as well)
<Stskeeps> another place to look  for bme info; nice
<k-s> just looked at canola sources, we use icd (networking) as well
<Stskeeps> dbus wrapper, also taken care of
<k-s> good
<Stskeeps> YokoZar: yeah, sounds like a good idea (branding package)
<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  
<Stskeeps> *nod*
<lbt> YokoZar: are you going to do that in Mer?
<ian_brasil> YokoZar: that sounds nice
 * lbt wasn't paying attention
<lbt> anyhow.... 2) Implementation outline  ??
<lbt> was that 2.1 done?
<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
<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.
<lbt> yeah.... so I'm not aware we have multi-branding code atm
<lbt> maybe this is a task?
<persia> Yeah, a task sounds good.
<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
<Stskeeps> which should give a hint of how much should go upstream ubuntu or whatever
<YokoZar> Good point St
<YokoZar> Stskeeps
<lbt> OBS root  is  https://build.opensuse.org/project/show?project=Maemo%3AMer
<Stskeeps> (apologies for the novell login, they're doing openid too. :P)
<Stskeeps> and the interesting parts are in :Devel:Base, :UI, :MaemoCommon, etc
<lbt> I am putting together a table that will describe each package's functionality, summarise Mer-isation and link to key places
<persia> lbt, That would be great!
<Stskeeps> we have spent some time making diffs in Maemo:Mer:Devel:MaemoCommon , so we can see what the Mer-specific package changes are
<lbt> it'll appear on the wiki in the re-written Mer/Build area
<lbt> anything else on this ....? or 2.2) Review of Mer cycles against Karmic schedule to define milestones   ???
<persia> https://wiki.ubuntu.com/KarmicReleaseSchedule
<persia> http://wiki.maemo.org/Mer/Sprints has the past: I don't know where to find the future.
<lbt> http://wiki.maemo.org/Mer/Releases
<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
<Stskeeps> and associated applications to make it a full desktop
<persia> Sprint ending 15 June matches well to preparation for Alpha 3 on 23 June.
<Stskeeps> http://bsd.tspre.org/~stskeeps/DSC00331.JPG is somewhat spec for 1.0 
<Stskeeps> (.. whiteboard picture)
<persia> Next interesting dates for Ubuntu are 13th August (Alpha 4) and 27th August (FeatureFreeze).  I'm not sure how those should align.
<lbt> and I have a higher res piccy to clear up arguments
<persia> Err.  Oops.  There's space for one more sprint between the current one and Alpha 3
<Stskeeps> maybe we should talk about what you'd like to have in your karmic MID.
<Stskeeps> stable desktop is reachable - ui and such, and some apps and such
<persia> Stskeeps, That's simple: something that doesn't crash when one runs cat.
<lbt> Stskeeps I'm also writing that whiteboard up
<lbt> Frankly Mer is stable
<Stskeeps> mer is stable with some quirks.
<lbt> it's just not that useful 
<persia> lbt, Why isn't it useful?
<lbt> applications by default
<Stskeeps> not many of the useful extras just yet :)
<Stskeeps> we do have entire ubuntu so it helps
<lbt> and stability/functionality of them
<lbt> and prettiness (missing translations)
<Stskeeps> ah, yes, translations
<lbt> but it's not *bad* at crashing at all
<Stskeeps> our quirks are GTK quirks really and some theme things
<lbt> we also have gpe
<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.
<persia> Rather, desired package list.
<lbt> sure
<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.
<lbt> but on small screen with fingers, not a mouse
<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
<lbt> gpe-cal is working
<lbt> so is gpe-contacts and file mgr
<lbt> xchat too
<lbt> we have no cron
 * ian_brasil +1 canola
<Stskeeps> yeah.. alarm wakeups are interesting at the moment but it'll be better
<lbt> meh... it'll never catch on
<lbt> ;)
<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.
<lbt> that may not be good for powersaving
<persia> We have a hildonised alarm clock, but it's a bit buggy.
<Stskeeps> lbt, which is where mer may differentiate a bit
<Stskeeps> since we can wreck more in our own variant of ubuntu
<NCommander> persia, Stskeeps we have fbreader
<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.
<lbt> see here for things we almost have : https://build.opensuse.org/project/show?project=Maemo%3AMer%3AExtras%3ADevel
<lbt> overview : https://build.opensuse.org/project/monitor?project=Maemo%3AMer%3AExtras%3ADevel
<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
<Stskeeps> (regarding alarm wakeups and so on)
<Stskeeps> in mer (dist) we'd have alarmd instead of cron, no log files, etc for instance :P
<Stskeeps> but we would like to have same application API across the board (hildon, etc)
<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.
<Stskeeps> *nod*
<lbt> :Apps may be Mer (dist)
<Stskeeps> our hope is that we can take the same app and ideally compile it towards Maemo(Fremantle), Mer(dist), Ubuntu MID
<persia> From my biased viewpoint, I'll hope you won't need Mer(dist) in the future, but that's separable :)
<Stskeeps> we'll see where we end up, i can sometimes in my darkest dreams hope Mer would be Maemo6 eventually, but hey ;)
<lbt> I was thinking about Mer (dist) being a default install
<lbt> indeed... Mer is what you get when you install Harmattan+n and only get the open SW
<persia> Anyway, I think we're drifting again.
<lbt> s/is/should/
<lbt> we are
<persia> So, cycle dates.
<lbt> I'll do a list of apps
<lbt> and allow us to track them
<persia> This Mer cycle ends soon.
<Stskeeps> reasonably we'll have some more apps and some work, and stable fremantle beta1 packages
<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.
<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
<Stskeeps> yeah, we had some discussions on that at the meeting :)
<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).
<persia> s/31/13/
<persia> Alternately, perhaps have a testing release around the 13th, and the cycle end around the 20th.
<Stskeeps> let me just see the sprint calendar, sec
<persia> After that, we'll diverge, and Ubuntu will only be able to accept backported bugfixes except in very special cases.
<Stskeeps> right, 13th july would be our release date
<Stskeeps> of 0.15
<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.
<Stskeeps> if we work together to clean up packages, minor GTK fixes and such, we should be able to get a decent result in
<persia> We can pull the polish for 0.16 post FF.
<lbt> persia: I'd expect those 2 weeks to be polishing 0.15
<persia> Err, 0.17
<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 :)
<Stskeeps> so that should be one of the first priorities as well
<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?
<lbt> seconded
<Stskeeps> persia: yeah, 15th june
<persia> Rght.  So 0.17 will be what ends up in 9.10.
<Stskeeps> keep in mind that this is dist release. individual packages may reach stable releases quite often
<persia> Unless the goals for 0.18 can be bugfixes (no new features), in which case we can probably pull that
<Stskeeps> *nod*
<Stskeeps> so it looks like we sync pretty nicely
<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.
 * lbt is confused ... "0.17 won't finish before FF"  "0.17 will be what ends up in 9.10"
<Stskeeps> 0.14 i think
<persia> OK.  Let me try this again.
<persia> 0.14 should release RSN, and will probably roughly match the initial uploads to Ubuntu.
<persia> 0.15 should release in July, and ought to be the basis of the Alpha 3 images.
<persia> 0.16 should release in August, and ought to roughly match the Alpha 4 images.
<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
<Stskeeps> sounds good to me
<persia> If 0.18 (releasing in September) focuses on bugwork, and doesn't include new features, we can probably pull it entire.
<persia> If there are new features, we'll have to backport the bugfixes, which is more work for all of us.
<lbt> ah... pushing 0.17:Testing pre-FF then? OK
<lbt> and it will make sense by then to have a bugfix cycle I'm sure!
<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.
<persia> lbt, Right.  Bit of scheduling coordination needed, but I think we can do it.
<Stskeeps> we're not tightly locked to months, we change once in a while, so if need be, we adjust
<persia> Then, 0.20 should release in November, and we can pull that as the first import of Ubuntu 10.04.
<GrueMaster> That actually sounds like a great cycle.  Odd, Experimental, Even Stable.
<lbt> <groan>
<YokoZar> ?
<YokoZar> lbt: were you concerned by that?
<lbt> not really :)
<lbt> amusedf
<lbt> old kernel numbering ....
<GrueMaster> Actually, it is still used in the kernel community, along with a lot of other development areas.
 * persia notes that it's now 6am locally, and hopes to chase the agenda to *finish* the meeting.
<lbt> persia... are you going to update the schedule as per comments
<lbt> I'll do the Mer sprints page
<lbt> and crosslink
<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.
<Stskeeps> ok, so where are we in outline?
<lbt> OK
<YokoZar> Stskeeps: we're at testing now I believe
<lbt> 2.3) Image creation
<persia> Right.  So, we've this big complex environment to create images.
<persia> It's easy for us to create .isos for i386.
<persia> It's perhaps less clear what (if any) images to create for armel.
<lbt> (Mer has one too... we call it Stskeeps)
<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.
<Stskeeps> might work
<lbt> can we auto-extract?
<persia> Saves thought, and probably scales better to the wide variety of armel devices that need kernels not included in Ubuntu.
<lbt> should be easy enough
<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.
<lbt> OK, shall we leave that as an Ubuntu problem then?
<lbt> I'll note as an issue
<persia> Sure.  Just something to be aware of for the future.
<persia> I suspect that users will probably cross-post bugs and support requests, etc.
<lbt> do you have a target list of machines?
<lbt> like we have N8x0, Freerunner, SmartQ etc
<lbt> auto-extract doesn't have to happen on the server
<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.
<Stskeeps> k
<persia> For Karmic everything is compiled for ARMv6+vfp, so the freerunner won't work.
<Stskeeps> yeah, it already doesnt
<persia> Anyway, if nobody objects to my suggestion about images, let's do it that way and move on.
<Stskeeps> k
<lbt> and again for testing does it make sense to pick a few targets to understand their needs
<lbt> anyhow... we'll get to that I guess
<persia> Sure, although we've the kernel issues, which makes it tricky.
<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.
<YokoZar> Agreed (hardware wise, I'll be doing testing on the two pandoras I've ordered)
<lbt> I don't think Meirziki is around
<GrueMaster> I also plan on ordering a Pandora, as soon as I get my replacement credit cards.
<Stskeeps> regarding devel and testing we will have 0 smartq5/7 rebates too
<lbt> that many?
<Stskeeps> er
<Stskeeps> 10
<persia> I've an i386 MID which I can use for testing.
<lbt> GrueMaster: are you going to put up a target list of 'tested' hardware?
<Stskeeps> ubuntu mid developers will fit under this too
<lbt> and are we going to pool test resources?
<lbt> we'll test yours if you test ours
<GrueMaster> I only have limited hardware to test with, but I can.
<persia> lbt, Depends on how much testing you want for 0.20.  If you're happy to pool, we certainly are.
<persia> Err, 0.19 :)
<lbt> I think we need to start testing early unless you're up to speed
<lbt> we're not!
<lbt> do you have test processes for Ubuntu that work for MID ?
<GrueMaster> Some, but not much at the moment. 
<persia> That comes to 3.2: we need some test plans.
<lbt> OK... should you/we aim to start testing Mer 0.15 ?
<persia> I think we have some for installation, but nothing for any applications.
<GrueMaster> It really depends on the application.  If it supports ATK, we can automate.
<persia> 0.15 / Alpha3 sounds like a good place to start integrated testing.
<Stskeeps> agreed
<persia> But we'll need test plans beforehand.  Anyone up for writing some?
<lbt> hmm I was going to say : GrueMaster are you the guy who's going to write the plans....
<lbt> ;)
<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.
<Stskeeps> well its hard when not knowing what intended collection of components would be
<lbt> OK... atm are we focusing on app plans?
<GrueMaster> More like basic functionality.
<Stskeeps> GrueMaster: was johnx presentingÃ:)
<persia> lbt, Do you think we should focus on something else?
<lbt> and things like desktop/menu/statusbar
<GrueMaster> Might have been.  I can't remember.
<lbt> well, we have limited resource... the foundations should be stable
<lbt> we need to focus on the areas we touch most
<lbt> like keyboard integration things
<Stskeeps> we will definately know more when hildon desktop runs in mid
<lbt> on the Mer side we have Merziki... but I really don't feel comfortable knowing how much time he has
<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.
<lbt> are you also interested in Mer/Ubuntu integration testing (whatever that means)
<lbt> hmm
<lbt> like package mgr
<lbt> that's an interesting one :)
<GrueMaster> That would be part of the testing.  Make sure the default apps sit well with the UI.
<lbt> actually our application manager is a bit special AFAIK
<persia> lbt, Indeed.  I know we have a hildonised update-manager, but I'm not sure we have a good package management UI.
<lbt> Stskeeps will it even work on a normal repo?
<Stskeeps> yeah
<lbt> and the categories etc
<lbt> and what apps it shows?
<Stskeeps> hackable
<lbt> it is very cut down
<lbt> OK
<lbt> so that's just an Ubuntu task then... hack the appmgr...
<lbt> It feels a little like we've stalled on 3) Testing Review
<lbt> do we defer to next time?
<lbt> or will someone volunteer to have some testing answers by then?
<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.
<persia> I think we can safely defer: I believe we've covered most of the essentials, and at least know what needs doing.
<lbt> well, if you want to volunteer GrueMaster then I can help... and maybe talk to MZ too
<GrueMaster> That'll work.
<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.
<GrueMaster> I think plars has that angle.
<lbt> OK... I have a list of some actions and issues I can cut'n'paste...
<persia> OK.  Anyone have anything else we *need* to cover?  I think it's getting quite late in Denmark :)
<persia> lbt, Please do.
<lbt> ISSUE: version tracking. Eg Maemo/hildon gtk will freeze
<lbt> ISSUE: How should Ubuntu best produce images (eg ISOs are easy but may need rootfs or extractor script)
<lbt> ACTION: Support/provide release commits like this : http://www.winehq.org/announce/1.1.22
<lbt> ACTION: Review objectves of Mer->Ubuntu upload and determine timing (:Testing2 or just :Stable) with persia
<lbt> ACTION: Produce workflow to be quilt and git-branch based
<lbt> ACTION: Contact Nokia re making Mer upstream for open development of Gtk (via gitorious cf Trolltech/Qt)
<lbt> ACTION: Page listing apps for featureful release and status/links
<lbt> ACTION: Update Mer Sprints page to show schedule sync and crosslink to KarmicReleaseSchedule
<lbt> ACTION: GrueMaster to put up a target list of 'tested' hardware
<lbt> TASK : Ubuntu code needs to poke /usr/share/branding/(some to be defined hierarchy standard) then filled with a branding-ubuntu package
<lbt> TASK : Ubuntu taskto hack the appmgr to work as needed
<lbt> nb... the tasks are mine for Mer unless there's a name
<lbt> s/tasks/actions/
<persia> branding is probably YokoZar
<YokoZar> Yes
<persia> I'm happy to help with the package manager.
<Stskeeps> also work out workflow, git, packaging, mid people access to mer trees etc
<lbt> Stskeeps that's already on my sprint page
<Stskeeps> k
<lbt> (apart from mid people access)
<lbt> I'll add that
<NCommander> I'll also help w/ package managerment
<NCommander> Wait, did we cover how we want to handle uploads into Ubuntu itself? To my knowledge, no one in Mer is MOTU
<NCommander> or, wait, nm, I see it
<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.
<YokoZar> I'm MOTU ;)
<Stskeeps> yep
<lbt> actually we have an action to talk to persia about becoming devs
<Stskeeps> we will see if its even needed i guess
<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)
<lbt> yeah, I suspect the workflow will be pull but people may well have 2 hats :)
<Stskeeps> k
<lbt> schedule timing for next meeting ?
<lbt> whilst people digest
<persia> Well, do we need another big comprehensive meeting soon?
<lbt> well.... I'm more thinking that we may need nagging
<persia> Personally, I'd rather chase the open TASKS, with discussion here, in #mer, on ubuntu-mobile@ and with mer-chatter@
<Stskeeps> one on ones maybe; lbt and someone on workflow and packaging
<persia> If we bog down, we can schedule something.  Otherwise, I think we're in good shape for three weeks or so.
<persia> Stskeeps, Absolutely: I suspect we'll need a bunch of those.
<lbt> ok 3 weeks then... how does that fit to release cycle?
<lbt> Stskeeps?
<NCommander> persia, commit rights to Mer's git trees?
<Stskeeps> NCommander: easily
<lbt> NCommander: help me figure out the workflow and you're there...
<Stskeeps> we are open so
<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.
<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.
<persia> I thought we were doing separate branches for packaging, but I could be mistaken.
<lbt> NCommander: I'm working on that...
<lbt> I would like to do branches for packaging and patches
<NCommander> Well, LP is getting the ability this(?) or next week to do git imports
<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)
<lbt> yes
<lbt> NCommander: do you have opinions? 
<lbt> if so then I'll work with you
<NCommander> lbt, I can think of a few good ways we could do this.
<lbt> OK... you're named in my action ;)
<NCommander> woo!
<Stskeeps> k, anything else im needed for? else im off to bed
<persia> YokoZar, Are we done?
<YokoZar> I believe so
<lbt> 23rd June?
<YokoZar> Someone should log this
<YokoZar> and save it somewhere
<YokoZar> (especially the action items)
<GrueMaster> I've got logging enabled.  Let me know where to post.
<YokoZar> your wiki I guess
<persia> I think it's already logged.
<lbt> The action items will go on the Mer wiki somewhere
 * persia double-checks
<persia> http://irclogs.ubuntu.com/2009/06/02/%23ubuntu-mobile.html
<Stskeeps> bbl, thanks for the meeting, gf wants me to sleep nowÃ:P
<GrueMaster> good enough.
<lbt> night Stskeeps
<YokoZar> Cheers, thank you everyone
<lbt> yep... g'night all and thanks
#ubuntu-mobile 2009-06-03
<ian_brasil> is there some way to enable OpenGL on a dell mini 10
<ian_brasil> it has an Intel GMA 500
<dyfet_> ian_brasil: Hmm...intel gma stuff is usually hw compatible for that
<ian_brasil> hi dyfet_
<dyfet> just had some connectivity issues yesterday...
<ian_brasil> ok...i installed UNR 9.04 on the dell mini 10
<ian_brasil> but need to run google earth and slick screensavers
<ian_brasil> which need OpenGL
<ogra> gma500 is poulsbo, isnt it ? there is no public and working 3D support for them 
<ogra> there is 2D accel, but thats about it (StevenK could tell you more)
<ian_brasil> ogra: thanks
#ubuntu-mobile 2009-06-04
<pan1nx> isn't there supposed to be an ubuntu-meeting today?
<pan1nx> Ok, so it seems that the meeting is for 21:00 UTC but the http://fridge.ubuntu.com/calendar said something else. Can someone change it there? THe right time?
<pan1nx> persia...do you have the rights to change that? Thanks...
<persia> pan1nx, I don't know.  I'll check.
<pan1nx> thanks persia
<persia> Hrm.  I can't figure out who invited the calendar to that meeting :(
<persia> https://wiki.ubuntu.com/Fridge/Calendar seems to indicate it's just an event in someone's calendar, and they invited the fridge.
<persia> Does anyone here remember setting up this invitation?
<lool> There's a meeting, but it's later today
<lool> It's 9pm UTC
<persia> Right, but the fridge is wrong, and that ought be fixed.  The trick is determining who created the fridge entry.
<pan1nx> oh man...
<pan1nx> can't we delete the old entry and fire up a new one
<persia> The entry was fixed.  Revisionist history is good for you :)
<persia> The meeting is at 21:00.  The meeting has always been at 21:00. :)
<pan1nx> persia I just placed the fridge to my sync calendar
<pan1nx> persia: just for the record, how did you change it?
<persia> I didn't.  One of the members of the team that maintains the fridge calendar changed it.
<persia> See -meeting for details
<pan1nx> ok...master cody :D
<rzr__> new nokia tablet  : Video about  N900 and maemo5 http://talk.maemo.org/showthread.php?p=293687&posted=1#post293687
<v29a> hi there. anyone of you got mid 9.10 running in virtualbox?
<ian_brasil> v29a: yes
<v29a> ian_brasil: did you configure anything specific?
<v29a> i can get 8.10 to run flawlessly ... 9.10 wont start an xserver
<v29a> virtualbox version is the current stable
<ian_brasil> you converted an .img right
<ian_brasil> vboxmanage convertdd ubuntu-9.04-beta-mid-lpia.img ubuntu-9.04-beta-mid-lpia.vdi
<v29a> yes i did
<v29a> i followed http://www.greenhughes.com/content/installing-ubuntu-mid-virtualbox ... worked for 8.10 but not for 9.10
<ian_brasil> and then you installed to a hard drive
<v29a> the image i used was http://cdimage.ubuntu.com/ubuntu-mid/daily-live/current/
<ian_brasil> sounds like you got a bust x
<ian_brasil> why are you using current?
<ian_brasil> why not get the 9.04 release?
<v29a> ?
<persia> Yeah.  Using that which will become 9.10 is subject to the "When it breaks, you get to keep the pieces" rule.
<v29a> well i did just find dl links for 8.10 and 9.10 ;-)
<persia> Right.  UNR 9.04 can be found at http://www.ubuntu.com/getubuntu/
<v29a> persia: i still cant seem to find links for the mid on that page ..
<persia> Sorry.  I thought you were looking for UNR.  MID is somewhere else.
<persia> http://cdimage.ubuntu.com/releases/9.04/release/
<v29a> lol just found it too
<v29a> thanks for your help
<v29a> ill try it
<v29a> does anyone know about ui changes to ubuntu mid?
<persia> v29a, Which sort of UI changes?
<v29a> doesnt look like they changed anything from 8.10 -> 9.04
<v29a> persia: well changes that make it more look like the screens there http://www.ubuntu.com/products/mobile
<persia> That's the interface the MID effort has been moving from, not towards.  At this point, that page is pointlessly out of date.
<v29a> ?
<v29a> where are they moving towards then?
<persia> I'll probably get this updated more this weekend, but https://wiki.ubuntu.com/Specs/MobileMidKarmicUseMer
<v29a> ok, so i should go for the mer project then?
<persia> v29a, Towards which goal?
<v29a> well ... intended usage ;-) 
<v29a> i want a distribution to run a car pc with a touchscreen
<v29a> 7-10"
<persia> OK.  Does Ubuntu MID 9.04 not work for you?
<v29a> it does
<v29a> oh sorry ... i meant it is running
<v29a> but the interface doesnt really look ready to use yet ...
<persia> Ah.  You liked the interfaces from that web page better?
<v29a> jep :)
<v29a> i hoped they were integrated in a more recent version
<persia> No.  Those were flash demos.  The free flash players are only so-so.
<persia> And a flash demo is only so powerful when it comes to being the default interface to an OS.
<lool> ogra: How long does it take you to run --second-stage in qemu usually?
<ogra> quite long
<v29a> i dont get it yet ... so the version providing those screens does not really exist? or is it just too slow?
<ogra> it sits at the configuring and unpacking stages andlessly, give it 10-15min
<ogra> or even 20
<lool> Oh great, thanks; I was wondering whether that was normal
<persia> v29a, It never really existed.
<ogra> the bad thing is that you dont get any output 
<v29a> persia: i see ..
<lool> ogra: What's odd is that I get no disk activity during this time; I suspect something is very slow on arm and not expected to be slow in debootstrap
<lool> Perhaps some perl
<ogra> yeah
<ogra> how do you measure disk activity on an image ? :)
<ogra> it might all happen in ram
#ubuntu-mobile 2009-06-05
<Daskreech> sebas: ping
 * persia suspects it to be *very* late there.
<asac> quick question: is flash on lpia not working?
<asac> (adobe flash)
<rzr> it does nt even work on x86 :)
<rzr> asac: btw i think i have to update FB again
<asac>  heh
<asac> rzr: sure. let me know when you have the merge
<asac> rzr: just in karmic or ar ethere severe issues that need to be addressed in jaunty?
<rzr> will do, once firefox freeze for karmic
<asac> rzr: huh?
<asac> firefox freeze?
<asac> that will happen not soonish ;)
<rzr> i meant you'll keep a version at least
<rzr> and fix bugs on it
<asac> ah
<asac> k
<rzr> just tell me when
<asac> yeah thats normal life i would say ;) ... update until we reach feature freeze and then check for bug fixes
<asac> rzr: whenever you have something let me know
<rzr> is it based iceweasel  or upstream version ?
<rzr> asac: so what is the expected version ? firefox-3.5 or firefox-3.6 or later ?
<asac> rzr: at best firebug would support firefox-3.5 and firefox-3.0
#ubuntu-mobile 2009-06-06
<lbt> hi persia, guys... you were going to give me some suggestions on becoming an Ubuntu dev (not sure of exact term) ... thought I might start the process  :)
<metalfan_> hi
<metalfan_> im trying to get the poulsbo xorg driver running, installed it from:  https://launchpad.net/~ubuntu-mobile/+archive/ppa?field.series_filter=jaunty      but xorg errors with: missing Xpsb.so    how do i know which of the packages contains that file?
<metalfan_> there are quite a lot
<metalfan_> ok, ive downloaded all *i386* packages and did:  for i in *.deb; do dpkg --contents $i|grep -i Xpsb; done         no output...what now?
<rzr> persia: hi
<rzr> persia: is there an irc place for android integration ?
<rzr> #ubuntu-android is empty
#ubuntu-mobile 2009-06-07
<goldrake> hallo
<goldrake> can someone help me with a wireless connection?
<darkjackaho> hi there, can i install ubuntu mid on a gps??
<aroedl> I'm not sure which image I should download for my Samsung Q1 Ultra -> https://wiki.ubuntu.com/MobileTeam/Mobile?action=show&redirect=MobileAndEmbedded
<aroedl> Is it the "karmic" image?
#ubuntu-mobile 2010-06-08
<yillkid> Hi all.
<yillkid> I have a question, dows Ubuntu Mobile can install on AMD platform ?
<yillkid>  I have a question, does Ubuntu Mobile can install on AMD platform ?
