#ubuntu-mobile 2008-02-04
<dholbach> good morning
<smagoun> moblin-applets in hardy depends on libhildon1>=2.0.1, which isn't in hardy (hardy instead has libhildon-1-0. That dependency isn't explicit in the debian/control file, so presumably a builder did the wrong thing? What's the right way to fix?
<patm> Fenario, let me know if you get my swap day request, it complained when I submitted it
<smagoun> StevenK: ^^^^^^ it's only 0300 there, why aren't you still at work?? :P
<smagoun> Mithrandir: ^^^^ re: moblin-applets
<ComradeHaz> Hi gents. I trust I'm right in my belief ubuntu-mobiles not made it onto the HTC tytn II aka Kaiser aka AT&T Tilt
<ComradeHaz> ??
<amitk> ComradeHaz: you are correct
<ComradeHaz> ta
<ComradeHaz> sucks to be right ;)
<amitk> heh
<d4ri0> does a phone stack mostly use AT commands over a serial port?
<Mithrandir> smagoun: file a bug; we need to adjust the shlibs and rebuild moblin-applets.
<smagoun> Mithrandir: thanks, I'll file a bug. The problem's actually in libhildon's rules file, I guess that's worth a bug too.
<ChickenCutlass> Mithrandir, Do you think it is ok to add an entry in NetworkManager's dbus config to allow the user ume access?
<ChickenCutlass> Mithrandir,  By doing so it fixes the nm-applet bug we talked about last week
<raji> tonyespy, you there?
<raji> tonyespy_, you there?
<tonyespy_> raji: yes
<raji> tonyespy_, how did the testing go with marvel v9 driver?
<tonyespy_> raji: I didn't get much further...  right now I'm trying to get our modified network-manager and nm-applet into the mobile ppa for hardy
<raji> tonyespy_, I see , then I will test that today..
<tonyespy_> raji: test the v9 driver?
<tonyespy_> raji: on gutsy?
<raji> tonyespy_,yes
<raji> tonyespy_, yes
<tonyespy_> raji: OK...  
<tonyespy_> raji: FYI, we're trying to switch to Hardy this week and it appears the v9 drivers aren't in Hardy.  I just cc'd you on an email to robr and  crew...
<raji> tonyespy_, Another question, while rootcausing the 'create new network', I see that iw_set_ext in nm_device_802_11_wireless_set_mode is returning error, I used wext driver option for wpa_supplicant, 
<raji> tonyespy_,ok
<tonyespy_> raji: with v8 or v9?
<raji> tonyespy_ with ath_pci
<tonyespy_> raji: that's the name of the module, not the version
<tonyespy_> if you're using v8, you have to use the marvell-specific driver module in wpa_supplicant
<tonyespy_> I'm not sure it's worh testing with v8
<raji> tonyespy_, I am testing with ath_pci on my samsung q1 ,not on our release hardware menlow...
<raji> tonyesp_, it is ath_pci 0.9
<tonyespy_> raji: Oh...  ath_pci is the low-level module of the madwifi stack.  madwifi has very poor support for adhoc, so you probably won't get too far.
<tonyespy_> raji: you have to manually switch the mode of the driver from infrastructure to adhoc-demo
<tonyespy_> raji: even then it may not play with other non-Atheros wifi cards
<raji> tonyespy_, I changed the wireless interface to use adhoc mode and changed the code to use 'wext' instead of madwifi
<tonyespy_> raji: you would be *much* better off trying to test using the v9 driver on a crown beach...
<tonyespy_> raji: I'm pretty sure "adhoc" mode doesn't work, however the separate "adhoc-demo" mode does....
<raji> tonyespy_, I am not aware of that 'adhoc_demo', is it a mode
<tonyespy_> raji: I haven't worked with madwifi for awhile... so most of this is from what I recall on the madwifi mailing list.
<raji> tonyespy_ will try that on crown beach.. 
<tonyespy_> raji: again, I think you're better off working with the Marvell / Crown beach combination cause that's what our customers will be using.  adhoc is tied very tightly to the driver being used.
<tonyespy_> raji: keep me posted
<raji> tonyespy_, another question , networkmanager 0.6.5 dont have ability to configure static ip , is it worth trying to root cause this as it anyway fails in the stage 5
<tonyespy_> raji: right now, there's no plan to do anymore work on nm 0.6.5.  If I were testing adhoc, I'd do so first without NM or wpa_supplicant and just try and use iwconfig/iwpriv, etc...
<tonyespy_> raji: I'm not even sure adhoc works for *any* drivers in 0.6.5.
<raji> tonyespy_, 0.6.5 doesnt support adhoc with 'any' driver, then I can just make sure if driver supports it or not .  
<raji> tonyespy_, ok , I will try it on crownbeach and see what happens..I will let you know..
<tonyespy_> raji: correct.  If the driver doesn't support it, then it's pointless to try it with NM and wpa_supplicant.   Good luck!
<d4ri0> raji: 'ahdemo' mode is not 802.11 standard so it won't work with other cards unless they support it
<d4ri0> raji: people like ahdemo (as opposed to ad-hoc) because there are no beacons, and the stations do not need to be associated in order to receive
<smagoun_> bfiller__: I pushed a fix to bzr, but it doesn't show up on launchpad yet. Do you know if there's supposed to be a delay before my revision shows up on LP? 
<smagoun_> StevenK: Please rebuild libhildon for Hardy to fix LP: 189041
<bfiller__> smagoun_: yes, there will be a slight delay
<bfiller__> StevenK: please build hildon-desktop as well as the patches are done
<smagoun_> StevenK: Please rebuild moblin-applets too (LP: 189058)
<StevenK> smagoun, bfiller__: The simplest way is to either push the changes to bzr, and then ping me a lot to upload it, or just tell me what I screwed up and let me fix it. I'll fix libhildon, and wait for it to get published, and then rebuild moblin-applets, and then I'll look at hildon-desktop.
<smagoun> StevenK: I pushed the libhildon change to bzr already, it just needs uploading
<StevenK> smagoun: I saw that, thanks so much.
<StevenK> smagoun: And to answer your implied question about your push not showing up on Launchpad, it does take a little while to appear.
<smagoun> StevenK: I can give you a .dsc or a debdiff for the moblin-applets rebuild. I wasn't sure whether it's easier for you to use one of those or just do the rebuild yourself.
<smagoun> StevenK: thanks. I figured it out after a couple minutes of F5F5F5F5 :)
<StevenK> smagoun: To be completly honest, it's very easy to trigger a rebuild (it's only a new changelog entry), so I'll just fix it.
<smagoun> ok, that's what I figured
<StevenK> smagoun: Maybe we want to think about putting moblin-applets into bzr?
<smagoun> StevenK: we could do that, sure.
<StevenK> smagoun: Right, libhildon uploaded. It will take until :04 or so to show up as published, and then another publisher cycle for the binaries. I have to wait until that publisher run is done before uploading moblin-applets or hildon-desktop.
<smagoun> StevenK: thanks much. Our nightly build will pick up the changes automatically at about 0800UTC
<StevenK> smagoun: About moblin-applets, let's play wait and see -- see how much stuff we need to change in it, and how much work we have to do together on it.
<StevenK> smagoun: At 0800UTC I should have all three (and *hopefully* libosso) sorted out.
<smagoun> ok, that works too. We're fine working with patches for now.
 * StevenK kicks tomboy.
<smagoun> StevenK: BTW I filed bug 189058 for the moblin-applets rebuild
<ubotu> Launchpad bug 189058 in moblin-applets "Rebuild moblin-applets to fix bad libhildon dependency" [Undecided,New] https://launchpad.net/bugs/189058
<bfiller__> StevenK: for some reason, debuild still fails even after fetching fresh hildon-desktop unless I use -i.bzr. What can I do to fix this?
<bfiller__> StevenK: did I forget to commit something?
<StevenK> bfiller__: No, the reason it fails is because it can't represent the changes to the files under .bzr
<bfiller__> StevenK: how do I fix that?
<StevenK> bfiller__: Export it from bzr as opposed to pulling -- you won't be able to push things into bzr from that one, but you won't have to add -i.bzr
<bfiller__> StevenK: ok, thanks
<Mithrandir> ChickenCutlass_: no, we should fix it so that when the desktop session starts, pam_foreground knows you're on the console.
<StevenK> smagoun: Still around?
<smagoun> StevenK: yup
<StevenK> smagoun: Can you check git for m-i-c and see if fsets for m{ccaslin,enlow}-hardy-whatever still mention moblin-chat?
<smagoun> StevenK: Only the mccaslin-lpia and menlow-lpia fsets mention moblin-chat. I think this is correct.
<StevenK> Sounds good to me.
<StevenK> smagoun: When did you want to get the new m-i-c into Hardy?
<StevenK> smagoun: I have to upload it to fix mccaslin (since I'm a bozo), but if you're ready for the new shiny upstream, we can push that in.
<smagoun> StevenK: anytime. I expect it might need to be coordinated with Mithrandir; I don't know how the nightly build gets its MIC, and the configs changed incompatibly at some point recently.
<smagoun> nightly build=the Ubuntu nightly; we have our MIC built for gutsy here
<smagoun> StevenK: If you want to push your fix now we can deal with shiny upstream later on. I don't want to lose out on MOTU points though! :)
<StevenK> smagoun: Right, I've pushed my fix.
<smagoun> StevenK: OK. What was your fix? do I need to redo the 0.40 package?
<StevenK> smagoun: My fix was to take the changes I made for menlow's fsets to the mccaslin fset.
<StevenK> smagoun: Which was in the diff I sent you
<smagoun> ok, I think I pushed those into all the fsets save the moblin ones for 0.40, so we should be all set.
<StevenK> Yay!
<smagoun> StevenK: I'm heading home, send me email if you need anything
#ubuntu-mobile 2008-02-05
<dholbach> good morning
<dholbach> Mithrandir, StevenK: you're aware of bug 188130, bug 186817, bug 185669, bug 188828, bug 186843?
<ubotu> Launchpad bug 188130 in moblin-image-creator "Update moblin-image-creator to 0.39" [Undecided,In progress] https://launchpad.net/bugs/188130
<ubotu> Launchpad bug 186817 in osso-af-settings "incorrect value defined for desktopentrydir in osso-af-settings.pc.in" [Undecided,Fix released] https://launchpad.net/bugs/186817
<ubotu> Launchpad bug 185669 in cheese "Update hildon UI patch for cheese 2.21.5" [Undecided,In progress] https://launchpad.net/bugs/185669
<ubotu> Launchpad bug 186843 in moblin-ui-framework "drag events not being propagated to home applets correctly" [Undecided,Confirmed] https://launchpad.net/bugs/186843
<Mithrandir> dholbach: I wasn't, but thanks.
<smagoun> Has anyone looked at the latest version of liferea in hardy (1.4.11-1ubuntu2)? Does it completely obsolete frothing?
<smagoun> tremolux: ^^^^
<tremolux_> smagoun: We should check with StevenK .  My understanding is that he packaged Ian's Frothing and that is what is in Hardy.
<tremolux_> smagoun: I tested the earlier version that StevenK sent to me, not the one in Hardy
<smagoun> tremolux_: the latest version of liferea conflicts with frothing (overlapping files) so I'd like to shoot frothing
<smagoun> ...but only if it makes sense
<tremolux_> smagoun: Hmm, Frothing is the hildonized Liferea.
<smagoun> yes, I know...
<tremolux_> We need to move the hildon code into Liferea
<smagoun> yes, I'm asking if anyone knows whether that's happened.
<tremolux_> smagoun: I don't know for sure.  I'll check it
<smagoun> thanks
<smagoun_> Mithrandir: I have a new Moblin Image Creator (0.40) to push to Hardy. Will that cause trouble for the UME nightly build?
<Mithrandir> smagoun_: assuming it works, it shouldn't be a problem.
<smagoun_> Mithrandir: ok, thanks. I ask because the fsets changed at some point - we need mccaslin-lpia-hardy-ppa instead of mccaslin-lpia, for example.
<Mithrandir> uh-hu.  That needs updating, then.
<smagoun_> Is that something I can do?
<GrueMaster> Question:  Why are we removing fsets that are still being updated (gutsy-PPA)?
<smagoun_> GrueMaster: the gutsy PPA is no longer being updated. The most recent update was 2008-01-24, and to my knowledge everyone's concentrating on Hardy now.
<GrueMaster> Funny, openoffice was updated on there today.
<GrueMaster> Still, there are users/customers that are stuck on gutsy, and gutsy itsself is frozen for the most part.
<smagoun_> GrueMaster: That PPA is used for both Gutsy and Hardy builds; OpenOffice was pushed to the Hardy part of the PPA
<GrueMaster> Ok, what about the linux-modules for 2.6.22?
<smagoun_> I see a linux-ubuntu-modules pushed on 2008-01-21: https://edge.launchpad.net/~ubuntu-mobile/+archive
<GrueMaster> Do I need to do a complete file search and list the latest updates?  The point is, we have customers still using this, so why is support being dropped from image creator?
<GrueMaster> All it does is keep image creator from running if you have projects open that use these platforms.
<agoliveira> GrueMaster: I was the guilty for pushing OO there :)
<smagoun_> GrueMaster: check the moblin-dev list - HappyCamp just responded to your mail.
<GrueMaster> agoliveira:  Missing the point.  I'm trying to find out why support for gutsy-ppa was summarily dropped from image-creator.
<HappyCamp> GrueMaster, I explained in the email
<HappyCamp> The only reason I added it was for flash support.  And we only had PPA support for less than two weeks.
<agoliveira> GrueMaster: Oh, sorry. My conection dropped a few minutes ago and I guess I missed a part of the discussion.
<GrueMaster> So, ubuntu-gutsy main is getting the psb driver updates?
<HappyCamp> GrueMaster, no idea, though doubtful
<GrueMaster> Well, they're in ppa.
<HappyCamp> Well we (moblin.org) aren't using the gutsy PPA.  We do have Hardy PPA platforms.
<smagoun_> GrueMaster: no, main won't get driver updates. If you want gusty+PSB you can get the drivers from moblin
<HappyCamp> If you really want it then you need to convince rustyl 
<GrueMaster> So, how are you building the latest gutsy images with psb support?
<HappyCamp> I am assuming we use menlow-lpia or mccaslin-lpia
<GrueMaster> I think my main frustration is that I have to maintain daily snapshots for various developers, and when several snapshot projects that are in use are based on a platform that is summarily dropped, image creator should not fail to continue working.  I understand if no more gutsy updates are going into ppa, but does that mean that image creator should break as a result of that?
<GrueMaster> As part of my daily snapshot maintenance, I also have to update image-creator via git.  Otherwise I would have left it static.
<HappyCamp> GrueMaster, at the moment I don't have any plans to put it back in.  But you can look back in the version and restore what was taken out.
<GrueMaster> So you're saying I should fork image-creator?
<HappyCamp> I am surprised that you started using it so quickly and in such a short time became dependent on that platform to be there.  For Gutsy we want people to use moblin.org
<HappyCamp> The hardy targets are Ubuntu only and do NOT pull from moblin.org
<HappyCamp> GrueMaster, You can fork it if you desire, but at the moment I don't plan to put it back in.  From what I know we don't need PPA, since we have the stuff on Moblin.org
<HappyCamp> So gutsy ppa seems to be redundant/unneccesary, at least that is the impression I have gotten from robr and rustyl 
<robr> HappyCamp / GrueMaster : it was decided at the sprint last week that we would use moblin and hardy ppa only . Moblin is still gutsty based for the immediate future.
<GrueMaster> I just checked, and the daily ubuntu-gutsy images from http://cdimage.ubuntu.com/moblin/gutsy/menlow_full use the ppa repository.  Since they do not provide project files with these images, I need to recreate build environments here using menlow-lpia-ubuntu-gutsy-ppa.  This is where my problem lies.  If the menlow-lpia platform were to include um-ppa-gutsy.list then my problem would be solved.  Until then, I am stuck with either maintaining a f
<GrueMaster> This is based on today's image at the above location.
<tremolux> smagoun: the latest version of liferea in hardy (1.4.11-1ubuntu2) does indeed have all of the Frothing hildon patches, done by StevenK.  This obsoletes Frothing.
<smagoun> tremolux: great, thanks
<amitk> GrueMaster: I am guessing you aren't looking for driver updates on gutsy, only for a fset to be restored. In which case HappyCamp is in control.
<amitk> GrueMaster: For my part, I _don't_ intend to push any driver updates for 2.6.22 from moblin into the Gutsy PPA
#ubuntu-mobile 2008-02-06
<dholbach> good morning
<jussi01> Hello all, which browser does ubuntu mobile use, and is flash lite available for it?
<agoliveira> jussi01: UME uses basically firefox with a simplified interface so flash can run on it. I don't know what "flash lite" is though.
<jussi01> agoliveira: flash lite is the version of flash made for mbile phones...
<jussi01> ie: http://www.adobe.com/products/flashlite/
<agoliveira> jussi01: UME's target hardware has more than enough power to run the regular flash plugin so, unless there's some specific need, I don't see a reason to use the lite version.
<jussi01> agoliveira: ok, great. thanks :)
<agoliveira> jussi01: No problem!
<mdz_> agoliveira,jussi01: if it uses less CPU (and therefore battery power), that would certainly be a good reason to use it
<agoliveira> mdz_: For what I've quickly gathered, I don't think we can use it. I've seen references to symbian, brew and arm processors only but, anyway, I didn't go much deeper.
<agoliveira> I found a FAQ that says: Does Flash Lite 2.1 support Linux? Flash Lite 2.1 can be ported to many realÂ­time operating systems including LinuxÂ®. We are not 
<agoliveira> offering a downloadable version of Flash Lite 2.1 on Linux at this time. 
<tonyespy> amitk: ping
<Jay-laptop> #launchpad-meeting 
<amitk> tonyespy: pong
<tonyespy> amitk: i'm just putting together an email re: kernel sync, the ppa, and git trees...  right now i'm not able to build against the version of the hardy kernel in the ppa cause i can't match it to a corresponding tagged git tree...
<tonyespy> amitk:  i'm mid-way thru composing the email... so give me a minute or two and i'll send it
<amitk> tonyespy: I will answer the email in a bit then.. dinner time
<tonyespy> amitk: cool, thanks
<smagoun> bfiller_: Mithrandir the epoch has crept back into the hildon-desktop version number. Is that intentional? It happened at 1:0.0.43-1ubuntu1, so it's been that way for awhile. 
<bfiller_> smagoun: what is the epoch?
<smagoun> the 1: at the front of the version number
<bfiller_> smagoun: right
<smagoun> looks like horace li put it there, the h-d changelog suggests that Mithrandir's removed it once already
<bfiller_> anyone know the best way to fix an amd64 build problem - compiler doesn't like a cast from gboolean to gpointer
<agoliveira> bfiller_: Don't bother. We are not using it on amd64 platform anyway.
<agoliveira> bfiller_: I mean, unless you want to fix it for the sake of fixing :)
<bfiller_> agoliveira: just to have good form :)
<bfiller_> agoliveira: so I don't get yelled at by anybody:)
<smagoun> agoliveira: we need all the motu points we can get
<agoliveira> smagoun: Can I give you mine? (If I actually have any, of course :) )
<suihkulokki> bfiller_: libhildonhelp?
<bfiller_> suihkulokki: what about libhildonhelp?
<suihkulokki> bfiller_: is that where you have the gboolean issue?
<bfiller_> suihkulokki: no, it's in a patch that I recently created (04_container_visibility.patch). I think I have a fix though, as I was doing something pretty dumb
<suihkulokki> bfiller_: ok, I just fixed there a similar problem using GINT_TO_POINTER
<bfiller_> suihkulokki: cool, I think I can use that macro as well. Thanks for the tip.
 * agoliveira sometimes makes some stupid english errors and notices just *after* send the email. Frustrating...
<GrueMaster> So, can someone explain why a fresh install of MIC only installs the 2.6.22 kernel when building an Ubuntu-Hardy image when using menlow-lpia-ubuntu-hardy-ppa platform?
<smagoun> GrueMaster: It installs a 2.6.24 kernel when using that platform, I just made one. When you installed from the USB drive to the target, did the boot prompt give you an option of which kernel to pick?
<amitk> GrueMaster: fresh install of MIC from where? Hardy or git tree?
<GrueMaster> Sorry.  Had my back turned.  I do a daily git pull of MIC from moblin.org as part of my support work.
<GrueMaster> smagoun:  I have a script that does my project builds, basically feeding MIC with cmdline options.  It makes the project first, then the target, then adds the fsets.  I also tried this all manually using the GUI.  What I end up with is the 2.6.22-14-lpia kernel in the target/<target>/fs/boot directory.  No 2.6.24 kernel.
#ubuntu-mobile 2008-02-07
<dholbach> good morning
<HappyCamp_laptop> Hello?
<HappyCamp_laptop> Is there a meeting this morning???
<HappyCamp_laptop> davidm: ?
<agoliveira> HappyCamp_laptop: Hello!
<HappyCamp_laptop> agoliveira: hello!  How's it going?
<davidm> HappyCamp, hi
<amitk> it was announced on email
 * HappyCamp_laptop should read his email
<davidm> #startmeeting
<Don_Johnson> Hello, Don J is on
<davidm> Hello
<agoliveira> HappyCamp_laptop: Still trying to put by butt back in shape after the 16+ hours in airplanes back here :)
<HappyCamp_laptop> Hello, John Villalovos is here
 * agoliveira waves all
<davidm> I'll start the meetint in a moment
<davidm> #startmeeting
<Mithrandir> mootbot's not here
<Mithrandir> apparently.
<davidm> Yep
<davidm> OK I'll copy the log into the meeting notes.
<rusty_> morning
 * agoliveira saw on TV mootbot watching the Carnaval parede in Rio.
<agoliveira> rusty_: Hi Rusty.
<davidm> OK first topic:
<davidm> smagoun, to talk to cjwatson about getting ckbcomp and such to not be run on each boot?
<smagoun> this is fixed
<davidm> OK thanks
<davidm> Second topic: ChickenCutlass to to produce boot charts for squashfs vs ext3 for hardy and boot charts for gutsy ext3 on CB
<ChickenCutlass> will post bootcharts to the list once I get a working Hardy image (just got one this morning)
<davidm> OK
<davidm> Next topic:   Bob Spencer (bspencer) to continue checking that projects are tagged when they release and report back on whether this is the case.
<bspencer> checked
<davidm> bspencer, is it happing now or does it still need monitoring?
<bspencer> after sprint we are getting into the habit of build, tag, upload to PPA
<davidm> Great
<bspencer> every maintainer knows this 
<davidm> Then I'll close this issue.
<davidm> Next topic: Moblin plans on implementing gettext for i18n in apps and applets (kyleN)
<kyleN> any such plans?
<bspencer> I'm working on that for media player now
<bspencer> we have bugs for the apps in our db
<kyleN> so you plan to implement in midbrowser too?
<bspencer> bugs = "moblin-media needs i18n support"  for example
<bspencer> midbrowser should already have this, no?
<bspencer> whatever firefox does is already part of the browser solution
<kyleN> i checked today and didn't find it, but I may have missunderstood
<bspencer> but I'm not familiar with it.  I haven't looked into it
<kyleN> i switched the locale to german and browser did not display in german whereaas other apps do
<bspencer> cwong1: do you know about i18n for browser?
<cwong1> I am not sure but I will look into this.
<rusty_> well, mozilla is definitly internationalized
<kyleN> cwong1: thx. 
<rusty_> it might night use gettext
<bspencer> might night 
<davidm> cwong1, I'll list an action that you are looking into i18n for midbrowser, OK?
<cwong1> ok
<cwong1> accept
<kyleN> moblin control panel applets?
<davidm> Thanks
<bspencer> todd isn't in this meeting I see
<bspencer> I'll ask him about it
<kyleN> can we make that an action, just be be official please
<bspencer> I think we already have an action for Moblin i18n
<bspencer> we can leave it open for another week
<davidm> bspencer, I'll list an action that you are following up with todd to check on i18n for moblin control panel applets,
<kyleN> cool
<davidm> Actually I've not carried that forward so I'll start to do so.
<bspencer> davidm: sure.  I think the current action item covers the whole project.
<davidm> OK, good enough.
<davidm> This may be a VERY short meeting since I have no more open items on the agenda
<kyleN> i'd like to raise a related issue if I may
<agoliveira> davidm: The best kind.
<davidm> kyleN, go ahead
<kyleN> language packs. do we know what we are doing here?
<ToddBrandt> i'M HERE
<ToddBrandt> JUST ON A LAG
<ToddBrandt> oops, sry for caps
<bspencer> ToddBrandt: maybe you were on mute
<davidm> But kyleN please add it to the agenda too.
<bspencer> ToddBrandt: the question was just to check into i18n for applets
<kyleN> hardy language packs seem to inlcude all packages with UI strings, we want subset
<ToddBrandt> I'll send out an update with all the bug fixes, I've been head down in them and there are dozens of changes
<bspencer> ToddBrandt: rusty  did we decide to add an i18n switching applet inside control panel?
<kyleN> in fact, we probably want the ability to make different subsets to support products/releases with different apps
<kyleN> I'd like to touch base with someone in this area to see if we have a plan that will work
<rusty_> all code needs to internationalized.... we are not localizing it for anything then english... but if the applets are not internationalized then it's a valid bug
<davidm> kyleN, that would seem to be controlled by the MID team and it's customer(s) at the time. Not likely to want all sets at once.
<Mithrandir> kyleN: I don't believe anybody has looked into how we are going to make langpacks.  If you could investigate, it would be much appreciated.
<ToddBrandt> the applets have internationalization support but since we've changed so much of the text we need to retranslate all the strings
<kyleN> Mithrandir: I am looking at it. I will talk to Arne and maybe martin pitt
<ToddBrandt> the original gnome-control-center had a team of translators
<kyleN> ToddBrandt: so, if the apps and source packages are in main, then we can expose in launchpad for translation, I presume.
<kyleN> does the PPA = main? 
<bspencer> kyleN: no.
<bspencer> kyleN: PPA is things not in main
<kyleN> so therefore the code can't be translated now with launchpad, right?
<bfiller> kyleN: moblin-applets will not be in main
<bspencer> assuming you mean main = hardy
<bfiller> or will it?
<kyleN> bspencer: yes, I meant hardy
<rusty_> eventually all the stuff in the hardy PPA will be finding it's way into main (on way or the other)
<ToddBrandt> I checked moblin applets and moblin keyboard manager into ppa hardy, so they're there if that's what your asking
<kyleN> in other words, i'd like to expose as much as possible in launchpad for translation
<rusty_> does launchpad provide it's translation capabilities for PPA's?
<Mithrandir> rusty_: I don't believe so.
<rusty_> too bad
<Mithrandir> but I volunteer kyleN to investigate that.
<davidm> As we merge the PPA into main the problem would seem to go away
<rusty_> yea, it's more of a short term problem
<kyleN> davidm: do we know what will end up in main and what won't? 
<Mithrandir> kyleN: at some point, we should be able to remove universe from the list of sources we pull from.  So, everything.
<davidm> Mithrandir, comments?
<Mithrandir> unless something blows up.
<kyleN> is there a rough 9or not so rough) time frame for everything being in main?
<agoliveira> Mithrandir: Your optimism is so refreshing :P
<rusty_> definitly anything that needs a translation
<rusty_> i.e. the apps
<Mithrandir> we want security support for the bits that compromise UME, and to get that, it must be in main.
<kyleN> the apps, hildon desktop, mobline applets etc
<rusty_> yeap
<bfiller> Mithrandir: I would think everything would need to be in main by Hardy code freeze, correct?
<Mithrandir> kyleN: takes a while, so hard to tell.  It's very much an ongoing process.
<Mithrandir> bfiller: there is no freeze by the name of "code freeze" for hardy, but it should hopefully be in main for Hardy Beta and must be for Hardy RC.
<davidm> We are pushing hard to get this done, taking care of any security issues as they arrive.
<bfiller> Mithrandir: yeah, that's what I was referring to..
<kyleN> ok, so it should all be exposed for translation via launchpad, expect project specific stuff
<bspencer> when is the next hardy milestone?
<bspencer> isn't it soon?
<Mithrandir> bspencer: http://wiki.ubuntu.com/HardyReleaseSchedule
<bspencer> thx
<Mithrandir> kyleN: what do you mean by "project specific stuff" in this context?
<davidm> bspencer, look on the internal intel.canonical wiki 
<davidm> it's more up to date
<kyleN> I'd like to be able to product language packs for subsets of hardy (namely mobile plus arbitrary apps/packages)
<davidm> though the Hardy dates are correct.
<kyleN> Mithrandir: there may be parts of a product that are custom
<davidm> bspencer, that is more up to date in terms of mobile releases to hardy schedule
<kyleN> typo: I meant to say, "produce lang packs"
<davidm> kyleN, the custom work falls under MID team does it not?
<kyleN> yes
<bspencer> davidm: ok.  I'm looking for the link
<kyleN> I'm done with this for now: everything that can go into main will. I need to work on lang pack issues. intel to investigate i18n of their code.
<davidm> the shared wiki URL and /Mobile/RevisedSchedule01012008
<davidm> bspencer, I can send you the shared wiki URL off line if you need it.
<GrueMaster> Should I inquire about current MIC and Ubuntu-hardy daily images issues here, email them, or report them in some bug database?
<mawhalen> bspencer: I sent you the login info
<davidm> GrueMaster, feel free to inquire
<mawhalen> We should also figure out how bugs flow if inputted into the UME launchpad back to someone on our team if it's in components we work on
<bspencer> mawhalen: thanks.  I got it and got in
<davidm> GrueMaster, our daily builds are working at the moment.
<GrueMaster> Ok, I do a daily git-pull of MIC (make uninstall && make install to clean up the environment).  I have tried building an ubuntu-hardy project with PLATFORM="menlow-lpia-ubuntu-hardy-ppa", but it only pulls from Gutsy.
<bfiller> mawhalen: this already occurs by assigning the bugs in launchpad to one of the moblin teams..
<GrueMaster> That's the current MIC issue I'm hitting against.
<mawhalen> bfiller: thx
<bfiller> mawhalen: sure
<GrueMaster> On the Ubuntu-daily, the system won't allow root access via sudo.  It errors with "can not resolve ume hostname".  I can get around it by adding "127.0.0.1 ume.localdomain ume" to the hosts file if I boot into single user mode first.
<Mithrandir> what's the reason for people using m-i-c from git rather than an actual release?
<GrueMaster> It is part of my daily testing mandate.
<Mithrandir> GrueMaster: as for "menlow-lpia-ubuntu-hardy-ppa" pulling from the wrong place, it sounds like a moblin/mic bug so probably talk to HappyCamp 
<bfiller> smagoun: can you comment on the MIC that is in the PPA and if that fixes the problems GrueMaster is having?
<HappyCamp_laptop> I will check it out, I thought it was working but will verify.  Myself or prajwal
<smagoun> bfiller: The MIC in the PPA is the most recent released version (0.40). It works properly, to the best of my knowledge.
<HappyCamp_laptop> And the MIC in the PPA came from Moblin.org not too long ago, I believe.
<GrueMaster> Just to clarify, make uninstall should clean up 'most" of the older stuff in case of config changes, right?
<HappyCamp_laptop> Unknown
<smagoun> GrueMaster: I'm not sure I'd trust make uninstall, but sudo rm -rf /usr/share/pdk && sudo rm -rf /var/lib/moblin-image-creator do pretty well
<HappyCamp_laptop> +1  Will wipe out most of image-creator
<HappyCamp_laptop> Except binary and a few other files
<GrueMaster> I have a unique requirement to do both daily snapshots and maintain older snapshots.  Lately, these two processes have been in conflict if I have them on the same system.
<smagoun> Also, you might clobber ~/.image-creator
<davidm> GrueMaster, tarballs?
<HappyCamp_laptop> GrueMaster: if you have a patch to make "make uninstall" work better, please let me know.  Or if what isn't working right in "make uninstall".  We can try to make it better.
<GrueMaster> Tarballs for what?  Projects?
<davidm> entire paths?
<HappyCamp_laptop> GrueMaster: he maybe talking about the fact you can save and load projects with MIC
<GrueMaster> HappyCamp_laptop:  I'll check into it in my "spare" time.  :P
<HappyCamp_laptop> GrueMaster: okay.  If you have specifics we can look into the code, I will add this to our list of things for prajwal and I to work on.
<GrueMaster> I do save the older projects > 1 month.  But some of them are based on platform definitions that no longer are supported, which causes issues with MIC.
<GrueMaster> On a good note, I have the Beta 6 video drivers semi-working with the 20080205 Ubuntu-hardy daily snapshot.
<agoliveira> GrueMaster: Define "semi-working", please?
<GrueMaster> I say semi-working because I haven't been able to rebuild the kernel modules without a build environment, and I had to replace ume-start-gui with twm.
<agoliveira> oh, ok.
<GrueMaster> The drivers I have were built with a build image from 1/22
<GrueMaster> I have to force them into the kernel to load.
<davidm> mawhalen, Mithrandir is having issues with Customs for the C0 board
<GrueMaster> Everything works great on a Hardy image from 20080122.
<davidm> mawhalen, can you work with him off line to fix?
<mawhalen> davidm: Yes
<davidm> mawhalen, thanks
<davidm> OK is there more to cover?
<GrueMaster> Minor note.  Alsa 1.0.16 works great on D0 with no "special" patches.
<GrueMaster> THought I'd throw that in.
<davidm> GrueMaster, good to hear, thanks
<davidm> OK, going once................
<amitk> GrueMaster: Ubuntu will be syncing to 1.0.16 'soon'
<davidm> OK, going twice........
<jayc> amitk: when can I expect the lum package?
<agoliveira> jayc: 'soon' :-D
<amitk> jayc: -7?
<jayc> amitK:yes, 7
<jayc> amitk:thanks
<amitk> jayc: it needs build tests, so probably end of today or early tomorrow
<davidm> amitk, jayc any more stuff?
<jayc> no
<davidm> going once................
<davidm> going twice........
<davidm> meeting closed
<smagoun> Is a busted touchscreen on the Q1 a known hardy issue?
<Mithrandir> smagoun: yes.
<Mithrandir> I've asked mjg59 to look at it and I've asked for a status earlier today, but no response yet.
<smagoun> Mithrandir: thanks
<davidm> smagoun, I also asked patm to look into it, he said he would have someone in Lexington take a look
<smagoun> davidm: he did? oh. First we've heard of it..
<davidm> You all have someone that knows that area pretty good on staff (from what patm said)
<davidm> I asked him a couple of weeks ago about this.
<smagoun> I just checked with ChickenCutlass. He says Pat never talked to him, but he suspects that the evtouch driver needs to be updated for an input subsystem change in X
<davidm> smagoun, with the sprint and all perhaps patm forgot.
<patm> davidm, hi, I heard my name
<patm> davidm, I now remember that conversation
<davidm> patm, can you still have someone look into it?
<smagoun> rusty_: The new moblin-media in the PPA is a bit busted - it depends on new versions of moko, hildon-theme-mobile-basic, and gstreamer-gbus-media-service that aren't in hardy or the PPA. Is someone from your team going to push those new versions to the PPA today?
<patm> davidm, michael is going to look into it, evtouch needs to be updated to the new X api
<smagoun> ChickenCutlass: potential evtouch patch: http://www.postnuklear.de/xorg-patches/files/xf86-input-evtouch-0.8.7-misc.patch
<ChickenCutlass> smagoun, I will loook into it
<davidm> patm, ChickenCutlass thanks.
<inuka_desk> ChickenCutlass, I just heard the word evtouch...... where you able to get the calibration utility to work? I am trying to get it to work for a crownbeach screen and seems to be stuck
<ChickenCutlass> inuka_desk, just got the patch for the new Xorg version , I will try it soon
<rusty_> smagoun, we are slowly working our way through uploading all dependencies
<inuka_desk> ChickenCutlass, I am running it on gutsy
<ChickenCutlass> inuka_desk, it break under Hardy because of a input ABI change
<ChickenCutlass> inuka_desk, it should work under gutsy
<smagoun> ChickenCutlass: inuka_desk looks like debian-unstable might have a new, functional version of the driver 
<inuka_desk> smagoun, thanks I will check it out.
<smagoun> http://packages.debian.org/sid/xserver-xorg-input-evtouch
<smagoun> inuka_desk: ^^ 0.8.7-3 works somewhat on my Q1. The mouse moves in discreet (20px) steps, but at least it moves :)
<inuka_desk> smagoun, I am trying to get it to work on a crownbeach....   the mouse moves for me smoothly but the pointer is following my finger :)
<smagoun> inuka_desk: I'm confused. Isn't the pointer supposed to follow your finger?
<inuka_desk> smagoun, my bad it does not 
<smagoun> ah ok
<smagoun> inuka_desk: try opening a shell then running the touchscreen calibration tool using the 'controlpanel' program
<inuka_desk> smagoun, thanks I will chek that out
<cjwatson> smagoun: did you have any luck with the suite-diff.py program I sent over?
<smagoun> cjwatson: I had to abandon that for the time being - we decided to rebase on hardy during our recent sprint, so I've been fulltime on that task.
<cjwatson> smagoun: ok, let me know if we can do anything else. I think the thing I blocked on to start with was that I wasn't sure whether you needed a list of things that failed on lpia but not on i386 (fiddly because it requires talking to Launchpad to query build statuses) or just a straight list of what was newer on i386 than on lpia
<cjwatson> obviously the latter will have some noise due to packages that just haven't built yet, but that (a) might be OK or (b) might not even be noise
<cjwatson> so eventually I decided to just punt and give you the tools :)
<smagoun> cjwatson: I think ideally it's the former, but a simple list of what's newer is fine in practice. We (lexington folk) have had really bad luck with the hardy transition so far, so it's been slow going. I hope to return to the arch sync problem by the end of the month
<smagoun> cjwatson: I really appreciate your help on the problem. I'll let you know what ultimately works best.
<cjwatson> ok, in that case 'suite-diff.py <URL to i386 Packages> <URL to lpia Packages> gt' should be good enough
<cjwatson> oh, but you might also have to figure out something for packages that have *never* built on lpia, some of which will be bugs and some of which will be deliberate
<cjwatson> so you'll probably need to use 'gt-ne', and get a slew of output that you have to filter for known don't-cares
<tremolux> agoliveira: I have noticed that the version of galculator that's in the UME PPE is quite a few patches behind the version at in the moblin repo
<tremolux> agoliveira: including a patch for osso support, some bug fixes, etc.
<agoliveira> tremolux: Well, I didn't even know there was yet a galculator there and I thought we agreed that those patches would be sent over to be integrated.
<agoliveira> I took the latest upstream version we had (1.3.1 IIRC) and added my patches. I'll gladly integrate their patches too of course.
<tremolux> agoliveira: yep, ok, I believe that's true
<agoliveira> tremolux: I just hope there *is* a patch, not just the modified tarball.
<tremolux> agoliveira: yep, it's a series of patch files, four or so beyond the two that are in the version in our PPA
<smagoun> agoliveira: there's even a git tree if you want: http://moblin.org/repos/projects/galculator.git/
<agoliveira> tremolux: Crap. Well, if you feel it's important I can check those out.
<tremolux> smagoun: agoliveira , right, that's where I got the version that I'm comparing
 * agoliveira would *love* if Intel just used our tools instead of keep this damn git tree for everything...
<smagoun> agoliveira: version control is a *good thing* :)
<agoliveira> smagoun: bzr does that as well :)
<tremolux> agoliveira: there was a discussion last week of bspencer planning to upload the latest galculator to the PPA (see wiki from last week)
<tremolux> agoliveira: (unless I misunderstand)
<bspencer> true
<agoliveira> tremolux: Oh, correct.
<agoliveira> Maybe we should touch again the issue of having the same source base aways with one responsible thus avoiding duplicity.
<agoliveira> bspencer: Anyway, upload yours and I'll try to come up with a merged version and promisse me you will stick with that and make patches over it only :)
<bspencer> agoliveira: where is your galculator source?
<bspencer> I can make patches to that if it is part of ubuntu-mobile in launchpad
<agoliveira> bspencer: You can pull it from the PPA
<tremolux> bspencer: thanks
<bspencer> agoliveira: got it
<agoliveira> bspencer: Thanks a lot.
<tremolux> agoliveira, bspencer cool, thanks guys
<agoliveira> tremolux: My pleasure!
<ian_brasil> i am building google gears on lpia and noticed there are no add-ons for the midbrowser ..is this likely to change?
<bspencer> ian_brasil: there is support for addons, but each one has to be tweaked a little to work.  There is no menu item for addons now that I know.  cwong1 or asac could tell you more.
<ian_brasil> bspencer: thx..i'll ping one of them
<HappyCamp> bspencer, are you in the office today?
<bspencer> HappyCamp  yes... my home office
<bspencer> going to lunch now though
<HappyCamp> Oh okay then.  Did you see my "git rm" helpful hint?
<agoliveira> HappyCamp: Like in "git rm -rf /"? :)
<HappyCamp> not exactly ;)
<patm> cwong1, ping
<smagoun> rusty_: any idea what the ETA is for getting the moblin-media dependencies into the PPA? You can't create a full image from the PPA without lots of tinkering as long as the dependencies are broken.
<rusty_> smagoun, then let's just remove it for now
<rusty_> i assume that's possible?
<smagoun> rusty_: it's possible - click the "delete packages" link listed under "actions" on the left side of the PPA webpage
 * rusty_ waits for launchpad to serve up a page
<smagoun> rusty_: for some fun, look at the last line of the source when the page comes up. It'll say something like <!-- at least 3382 queries issued in 15.27 seconds -->
<smagoun> 3k queries/page is not how you build a scalable system...
<rusty_> smagoun, ok, it's deleted... i'll at it back later after i work through the deps
<smagoun> rusty_: thanks!
<smagoun> davidm: I submitted a merge request for the latest evtouch driver from debian unstable, which includes a patch for the touchscreen on the Q1: https://bugs.edge.launchpad.net/ubuntu/+source/xf86-input-evtouch/+bug/190004
<ubotu> Launchpad bug 190004 in xf86-input-evtouch "Please merge xf86-input-evdev 0.8.7-3 (universe) from debian unstable (main)" [Undecided,Confirmed] 
<smagoun> On my Q1 the TS is still a bit jumpy and the calibrate tool doesn't work, but a jumpy TS is better than no TS for now
<davidm> smagoun, sounds good
<davidm> Mithrandir, Q1 TS issue getting better.
<Mithrandir> smagoun: does that include the patch from http://lists.freedesktop.org/archives/xorg-commit/2008-February/014648.html
<Mithrandir> ?
<agoliveira> davidm: Already listening the anoying song...
<smagoun> Mithrandir: that looks like a patch to the xserver itself, not evtouch?
<mjg59> Yes, the inherent issue is in the server rather than the driver
<smagoun> mjg59: So the driver update isn't necessary? Or we need both the driver and server patches?
<mjg59> I believe the server update should be adequate
<smagoun> mjg59: Are you testing the xserver patch? Any idea for an ETA into Hardy?
<mjg59> smagoun: I'm blocked on not having access to an x86 build machine at the moment, but this is what upstream have given us
<StevenK> mjg59: Anything I can do to help?
<mjg59> StevenK: Testing the code from that patch would be great
<smagoun> StevenK: a warning, the patch doesn't apply cleanly to the xserver in hardy
<StevenK> smagoun: If you've already tried, I'm happy to base off your work
<smagoun> StevenK: I'm afraid I don't have anything useful. I spent about 2 minutes on it, and much of that was browsing gitweb.fd.o.
 * StevenK tries to figure out where to stuff this patch in xserver-xorg
<smagoun> StevenK: apt-get source xorg-server-core, then it applies (or not) to xorg-server-1.4.1.../dix
<smagoun> or did you mean where in the patch series should it go?
<StevenK> Yeah
<smagoun> I think I decided that it didn't really matter, since none of the patches in debian/patches affect dix/getevents.c, which is where the changes go
 * StevenK tries to get this patch to apply
<mjg59> asac: I've got a plan for dealing with automatically bringing the wireless up and down on network activity, so I'm looking at adding that to n-m
<mjg59> asac: Should I look at 0.6 or 0.7?
<StevenK> Ugh. The dix/getevents.c differ too much between git and what is in Ubuntu.
<mjg59> StevenK: Hang on, I have some older code that might work
<mjg59> StevenK: www.codon.org.uk/~mjg59/tmp/145_fdo_10324_add_scaling.diff
<StevenK> mjg59: That applies fine. Along with a .orig file :-)
<mjg59> StevenK: Hahaoops.
<mjg59> Let me know if it actually works
<StevenK> mjg59: Will do, I'll be test building it in a few
<mjg59> asac: Unf. Your ppa n-m package contains the libtool wrapper for nm-tool, not the actual binary
<smagoun> StevenK: I have to head home now, would you let me know how that touchscreen fix works? If you don't have a Q1 point me at a .deb + I'll test in the morning.
<StevenK> smagoun: I shall. I'm going to brutalise my Q1 in a bit
<StevenK> mjg59: The patch looks to work
<mjg59> StevenK: Excellent. Want to upload that?
<mjg59> Should also fix wacom
<StevenK> mjg59: I've had to apply the patch to the package, and I'm talking to Bryce about it, so I can handle it
<mjg59> Cool
<cjwatson> Mithrandir: (or indeed anyone else) Do you know if you make use of the mobile seeds in any place other than the ubuntu-meta source package?
<davidm> StevenK, do you know the answer to cjwatson's question?
<cjwatson> I ask since I'm going to land a seed restructuring tomorrow once a Launchpad change I've requested lands
<cjwatson> and in the process it seems like it'd be convenient for you guys to take the opportunity to split the mobile seeds out into something that's owned by the ubuntu-mobile team
<cjwatson> (shout if this is a false assumption)
<StevenK> cjwatson: From what I can recall, only ubuntu-meta makes use of the mobile seeds.
<cjwatson> cool; is my other assumption correct (that this would be a useful permissions relaxation?)
<cjwatson> I think it might become sensible to build the ubuntu-mobile binary from a separate source package, but I can organise that
<StevenK> With the caveat that ubuntu-meta still needs to be sponsored by a core-dev?
<StevenK> cjwatson: I think the permissions relaxation would help, then people don't have to get blocked on Mithrandir or I
<cjwatson> 23:29 <StevenK> With the caveat that ubuntu-meta still needs to be sponsored by a core-dev?
<cjwatson> 23:29 <cjwatson> ubuntu-mobile's in universe anyway, so if we split the source out that could be relaxed to ubuntu-dev if you'd like
<StevenK> Ah.
<StevenK> cjwatson: But will probably get promoted to main ...
<cjwatson> sure
<StevenK> mjg59: xserver-xorg uploaded, thanks for your help.
<cjwatson> I'm not fussed really, it's your (plural) call, just indicating that it will shortly be technically possible and might be more flexible
<StevenK> cjwatson: Shall we leave the status quo alone and revisit it if it's needed?
<cjwatson> if we split the mobile seeds out into a separate branch, though, which I do think we should do as they're a separate product, then that will either require splitting the ubuntu-meta source package or some work in germinate-update-metapackage
<cjwatson> what I'm trying to do is establish each product we ship as a separate seed branch, and have them actually include a central seed branch (or branches) rather than having to merge back and forward all the time
<mjg59> StevenK: No problem
<cjwatson> this probably hasn't been so much of a problem for you directly, but it is noticeable at the moment that any time you try to merge the Kubuntu seeds you have to resolve conflicts because mobile is missing there
<cjwatson> this is among the problems I'm trying to fix
 * StevenK nods
<cjwatson> but we can just as well leave the split-out mobile seeds owned by ubuntu-core-dev if you prefer
<StevenK> I think it makes sense to have them owned by ubuntu-mobile
<StevenK> I'm curious who will own the kubuntu seeds
<cjwatson> they're ubuntu-core-dev at the moment
<cjwatson> (they've always been split)
<cjwatson> the new seed branches will be platform, server, and mobile
<cjwatson> I'll have the same conversation with server, and make platform be ubuntu-core-dev by personal fiat ;-)
<StevenK> Heh
<StevenK> "I declare the world is shaped like this."
<StevenK> At this point, either of ubuntu-core-dev or ubuntu-mobile is okay. Since ubuntu-meta requires ubuntu-core-dev, maybe the seeds should still remain as owned by core-dev
#ubuntu-mobile 2008-02-08
<cjwatson> StevenK: mkay, no problem
<Mithrandir> cjwatson: TTBOMK, we don't.
 * Hobbsee stomps on Mithrandir's feet in greeting
<dholbach> good morning
<asac> mjg59: depends. the only point for looking at 0.6 would be that 0.7 will most likely not ship in hardy.
<mjg59> asac: And that's the plan for UME as well, right?
<dholbach> Mithrandir, StevenK: if you look at http://people.ubuntu.com/~dholbach/sponsoring you'll see that there are a bunch of hildon-desktop patches that need sponsoring - you might just roll them all into one upload
<asac> mjg59: most likely. we could treat mobile different if there is a use-case i guess
<asac> mjg59: will hardy be a LTS for mobile too?
<asac> e.g. i would instantly go for 0.7 if hardy wouldn't be LTS
<mjg59> asac: I don't think it's counted as an LTS, but it is the first version that's likely to be pushed to vendors
<mjg59> I think you'd need to speak to Tollef or David for a better idea what's going on there, though
<amitk> asac: No, it won't be an LTS in the traditional sense, since development will continue later
<asac> if development can continue later we should definitly cosider to go for NM 0.7
<Person1873> is ubuntu mobile intended for PDA's or smartphones?
<amitk> The plan is to continue in the PPA later
<asac> the features are there ... my only concern for not switching in LTS is that code base will still evolve significantly till final 0.7 and then we might have issues backporting security fixes
<amitk> Person1873: not yet. The first target is the Intel Menlow platform. https://wiki.ubuntu.com/MobileAndEmbedded/FAQ
<asac> amitk: but we could go ppa directly if we decide to use 0.7 for mobile and 0.6.6 other archs
<asac> ?
<Person1873> do you know of any linux distro's that might be able to replace windows mobile?
<amitk> asac: yes you could
<amitk> Person1873: you will need to know the underlying hardware that needs to be supported first, openembedded, maemo, have support for pdas, etc.
<Person1873> ok, i'm not sure about my new PDA its HP
<Person1873> i think i might be i the wrong place
<GrueMaster> HappyCamp:  I think I figured out the MIC issue.  There is a bug in it that reads the regular expression defines in ~/.image-creator/sources_cfg even though they are commented out.  Deleting this file and reinstalling has fixed the issue (I think - project is building now).
<Java-Jim> hi
<Java-Jim> Can anyone tell me, if it is possible to have 3d acceleration on on crown-beach board at the moment? I read about a proprietary driver in the mailing list archives. Is it available somewhere?
<sodarock_home> GrueMaster: good to hear
 * sodarock_home is also known as HappyCamp
<GrueMaster> If I get some spare time, I'll look over your config parsing routine and see about patching it.  Of course, I don't know python yet...
<sodarock_home> GrueMaster: well the parsing of sources_cfg is just execing it as python code.
<Praj> GrueMaster: will investigate the MIC issue with sources_cfg - can you give me context when it fails?
<GrueMaster> Apparently, I had an older version in ~/.image-creator (as root).  When I ran image-creator --command=create-project --platform=menlow-lpia-ubuntu-hardy-ppa --project-name=ubuntu-hardy-20080208-1 --project-path=/root/ubuntu/hardy/ubuntu-hardy-20080208-1 it would pull the gutsy sources.list only.
<ToddBrandt> Hi all: I have an OS architecture question for you wrt moblin-applets
<ToddBrandt> I want to get rid of the need for the user to have to log in as root in order to execute the moblin touchscreen and date&time applets
<ToddBrandt> So my solution is to turn both of them into little daemons with the same functionality, but that are instantiated by the DBUS daemon when their one DBUS function is called
<ToddBrandt> so moblin-touchscreen is instantiated via a connection to its system DBUS connection and a call to "calibrate_touschreen", it then kicks off the daemon, it runs the calibration as root, then exist when it's done
<ToddBrandt> basically the same things for moblin-time, which is the time applet
<ToddBrandt> does this sound like a good ubuntu friendly approach?
<inuka_desk> ping amitk, awake?
<inuka_desk> ping, bryce
<GrueMaster> Anyone know how to get root access on the latest ubuntu-hardy images?
<inuka_desk> GrueMaster, login as ume and do sudo su (all password are blank).... does this not work anymore?
<GrueMaster> Nope.  Hasn't worked for several weeks now.
<GrueMaster> Error message is that it can't resolve host ume.
<GrueMaster> I've been working around it by booting single, then editing /etc/hosts.
<inuka_desk> oh, I had the same issue before, I think I booted into single and changed the password I am not sure if that works
<inuka_desk> :) yeah
<GrueMaster> I'm not sure if the problem exists with Moblin or not.
<GrueMaster> I have just this morning been able to build images again.
<inuka_desk> GrueMaster, thats good I kept on installing the fsets by hand  so far
<bryce> inuka_desk: heya
<inuka_desk> bryce, I got a PPA related question, if I ulpad a package to the PPA to build, it will first look at the packages in my PPA when it installs the dependencies right?
<bryce> inuka_desk: it will look in the same PPA that it's in, but not any other PPA's
<bryce> inuka_desk: so you need to get dependencies (e.g. libdrm) uploaded there first
<inuka_desk> bryce, I have libdrm uploaded, when I specified the exact version of the libdrm I uploaded to the ppa it failed saying dependency not found , I took the exact version string out for libdrm-dev from the control file it built but it looked like it was building against a different version of libdrm when I looked in the log
<bryce> hmm, yeah I also ran into problems getting the libdrm to be recognized in the ppa
<bryce> it's probably a question for Mithrandir or StevenK
<inuka_desk> bryce, ok thanks hope one of them is awake
<inuka_desk> ping, Mithrandir
#ubuntu-mobile 2008-02-10
<crevette> hello there
<crevette> I'm coming to know if someone will update the bluetooth stack before Tuesday 
<crevette> I've starting on my own side, but I'm not really experienced
<HighNo> are there motus around to look at  http://revu.tauware.de/details.py?package=blueproximity ?
<HighNo> (everybody else is of course invited to look at it too, or here: http://blueproximity.sourceforge.net)
<crevette> StevenK: around
<crevette> vuntz: are you MOTU ?
<vuntz> crevette: no
#ubuntu-mobile 2009-02-03
<OdyX> Hi. I am running Debian i386 on my Acer Aspire One and I am considering a switch to Ubuntu lpia. What do you thinkÂ ? Is the change worth itÂ ?
<OdyX> Can I run lpia packages over an i386 kernel + userspace (e.g i386 libc6)Â ?
<ogra> persia, !
<ogra> where do you hang around ? 
<toddie1> hi, which devices are supported by ubuntu mobile, is the samsung sgh-i900 omnia supported?
<toddie1> does nobody know or are u just too stupid to understand what i wrote
<playya> nice guy ^^
#ubuntu-mobile 2009-02-04
<mchelen> are there any particular devices recommended for MID?
<ian_brasil> mchelen: most of the original work was done on a Samsung Q1 ultra...however i do not think there are recommended devices as such 
<mchelen> ian_brasil, okay thanks, is the situation different for UMPC?
<ian_brasil> well i have used an acer aspire...eeepc and proview 
<ian_brasil> on the aspire it runs great (apart from a wifi problem)
<ian_brasil> it is also easy to switch to unr..have a look at https://wiki.ubuntu.com/MobileTeam/Mobile/HowTo/TurnUMPCDesktopIntoNetbook
<chafka> clear
<chafka> can i install ubuntu mobile on my t-mobile mda?
<maszlo> anyone active?
<tomodachi> im here
<tomodachi> if that counts
<tomodachi> but this chan is very silent 
<tomodachi> and i dont really have any experience to share i just lurq
<maszlo> I am looking for a good starting point on testing this edition
<maszlo> eee pc 904ha + galax touchscreen (currently using TouchKit)
<maszlo> so what it looked like to me the system boots from image and software needs to be added to that image to be run.. can not be installed?  is this correct
<maszlo> tomodachi: do you have this system running?
<tomodachi> maszlo: nope
<tomodachi> i have a olpc
<tomodachi> but i went for a modified lightweight ubuntu with a custom olpc kernel instead
<maszlo> similar to what im doing currently.. I have a modified kernel from array.org for the eee pc I am running
#ubuntu-mobile 2009-02-05
<Zic> does somebody own a Samsung Q1 ultra here?
<cgregan> Zic: I do
<cgregan> Zic: a little late I guess :-)
#ubuntu-mobile 2009-02-07
<RzR> there is a debian nas conf video stream now : http://www.newlc.com/en/2009-events-fosdem-now-wmc-next
#ubuntu-mobile 2009-02-08
<juliux> hi
<juliux> does somebody has a link for me how to get a tablet pc working on jaunty? my xorg configuration from intrepid is not longer working
<playya_> mom
<juliux> i have copied the 10-wacom.fdi file allready into /etc/hal/policy/
<playya_> can't find one either :(
<playya_> juliux, maybe they're all in belgium?
<juliux> or are sleeping after the platform sprint;)
<juliux> if i run xxd /dev/ttyS0 and then move the stylus i see some output;9
<playya_> and what about xev?
<juliux> no reaction if i use the pen
<playya_> mom. should i write a short prog which shows what is happening on /dev/ttyS0?
<juliux> if you have time;)
<playya_> ok. install gcc ;)
<juliux> done;)
<playya_> your connection 1: me 0
<juliux> 16mbit;)
<juliux> playya_: with my old xorg conf from my backup the tablet pc is working
<playya_> ok
<playya_> gcc gives me some strange errors
#ubuntu-mobile 2010-02-08
<m_fulder> hello
<m_fulder> is it possible (while haveing a server on a ubuntu machine) to connect a mobile phone to my server (so I can use the internet from the server instead of paying for it...to connect to 3G server etc. ?)
<persia> I *think* so, but I'm not 100% sure.
<persia> But you'd need basestation hardware to do it, which gets expensive quickly.
<persia> Most people looking at that use case seem to select handhelds with 802.11* and do something that way.
<m_fulder> hm ok..but how does it work with mobiles and network actually? Doesn't just a mobile connect to a server through 3G ? What does a user pay for? To download the files/webpages to the server or to be connected to the "network" ?
<persia> Depends on the arrangement.  "3G" is jsut a marketing term that covers a number of networking technologies.
<m_fulder> right
<m_fulder> and what's this handhelds with 802.11 ?
<m_fulder> isn't 802.11 just a IEEE cable?
<persia> In most cases, the base stations are owned by some provider, who may charge in various ways, depending on the local regulatory and competitive environments.
<persia> For some defintion of "cable" :)
<persia> 802.3 is the more common wired ethernet standard.
<m_fulder> wired?
<persia> 802.11 is a set of common wireless ethernet standards.
<m_fulder> but I want to connect to my server (internet) wireless from my mobile isn't this possible?
<m_fulder> aha wireless ok
<persia> Sure.
<m_fulder> so what would I need except the server? .. the base station? what exactly does it do? 
<persia> But you want to do it without using any external carrier, which means you need a base station that supports some wireless technology also supported by your handheld.
<persia> A base station usually converts some wireless signal into some wired signal.  There are a few devices that convert between two different wireless signals.
<m_fulder> aha..but then say I'm some km from my base station..will it still catch my mobile signal? :S
<persia> Depends on your signal strength and other signals on the same band, etc.
<m_fulder> aha
<m_fulder> but wait isn't "3G" (f.ex.) a wireless mobile netwrok that makes it possible to connect from anywhere to anywhere? can't I use this network to connect? 
<persia> multi-km wireless links (usually called "Microwave Relay") are a common solution where undersea cables are expensive or troublesome.
<m_fulder> but don't I then need a large antenna in my house?
<persia> As I said before, "3G" is just a marketing term for a variety of wireless networking standards.  If you're looking for ubiquitous networking, you'd do better to use some existing provider, as the cost of a distributed set of base stations over all places you are likely to go is typically expensive enough to require a large userbase, rather than a single person.
<m_fulder> aha ok then I get it
<persia> Depending on your provider and your handheld, you may or may not be able to send any number of protocols over the network.  Depending on your server connectivity, and network security policies, you may or may not be able to access your server using one of these protocols.
<persia> So, the answer is "Sure, you can do it", but it depends on enough factors than a detailed explanation is complicated.
<m_fulder> aha ok
#ubuntu-mobile 2010-02-09
<NCommander> asac: AR added
<NCommander> ogra: https://bugs.edge.launchpad.net/ubuntu/+source/likewise-open/+bug/517300
<ubottu> Ubuntu bug 517300 in likewise-open "[armel] likewise-open needs porting to armel" [High,In progress]
<ogra> merci 
 * ogra hugs NCommander 
<NCommander> ogra: no patch attached >.<; I think it fell off :-/
 * NCommander was sure there was an in-progress patch I put on that bug
<ogra> meh, can you do that asap ? 
<NCommander> ogra: I can try
<NCommander> LP is going VERY slow
<ogra> just what you have now
<NCommander> ogra: attached
<NCommander> ogra: sorry about that. I didn't notice the patch failed to stick to the bug until just now
<NCommander> asac: ogra: need anything else before I go Mobile only?
<persia> This is clearly a call for more sophisticated handsets :)
<persia> (well, and more robust ubiquitous networking)
<NCommander> persia: my handset making a hotspot to connect my laptop. It can only do so much when all it can see is a GPRS tower
<NCommander> (LP over GPRS is PAINFUL)
<persia> Right.  Not tethering requires more sophisticated handhelds.  Not having the network break requires more robust ubiquitous networking.  See above.
<NCommander> persia: I don't think I would want to run the meeting on any keyboard short of my laptop :-P
<NCommander> Ok, now I go poof
<persia> Just get a http://www.tekgear.ca/index.cfm?pageID=90&prodid=22&section=99 : some people get up to 60WPM, although I'll admit I only get about 15-20.
<NCommander> if anyone needs me ASAP, hit the cell and I'll pop back on
<NCommander> else I'll be back ths afternoon
#ubuntu-mobile 2010-02-11
<eggonlea> hi mobile team, as we knew, Karmic gave up clutter and netbook-launcher on ARM because of lacking powerful OpenGL (ES) support on ARM platforms. While this has improved much now, will we have any fancy GUI on Lucid ARM port?
<eggonlea> 1) clutter based netbook-launcher
<eggonlea> 2) OpenGL ES based compiz
<eggonlea> 3) EFI based 2D launcher
<eggonlea> which one would be chosen in Lucid? Or just keep gnome based ubuntu-desktop?
<lool> eggonlea: I can't speak for the mobile team, but I understand the focus is to produce an EFL Ubuntu Netbook image
<lool> so 2D acceleration only
<eggonlea> lool: thanks. but till now we didn't see this EFI 2D GUI in livecd.
<eggonlea> maybe I miss something, or it should be there already since alpha3 is coming.
<lool> eggonlea: I didn't try the images at http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/
<lool> eggonlea: But the manifest lists the packages in there
<lool> netbook-launcher-efl 0.2.2-0ubuntu2
<eggonlea> I mean, the default GUI is still gnome desktop after installation.
<lool> Is it?  odd
<lool> asac: ^ Is it a known bug perhaps?   Or perhaps there's an easy work around?
<eggonlea> y. let me double check the latest livecd.
 * eggonlea is reinstalling the latest livecd on the board.
<asac> latest live images should have the netbook launcher
<asac> problem is that shortly after we switched to ue images mono breakage killed our images
<asac> so for a week or so there were no images at all afaict
<asac> eggonlea: ^^
<eggonlea> aha, I see
<eggonlea> I was wondering why the daily zsync did nothing.
<asac> yeah. but seems we have images today again \o/
<asac> seems we recovered from mono probs ;)
<lool> asac: Well done on mono
<lool> I wonder whether it actually works
<eggonlea> good news indeed. congratulations~. but I'm unlucky to try it for some days because of our LONG Chinese new year holiday.
<asac> lool: i would think its similar flaky
<asac> as in karmic
<asac> in karmic 40 tests failed
<eggonlea> Hopefully I can catch it tonight. Do you know how long I should wait for it?
<asac> now 36
<eggonlea> I mean, how many hours does it take to generate the coming livecd?
<asac> you mean the next run?
<asac> hmm good question
<asac> ogra: persia: when is the image run?
<asac> so looking at the timestamp it will be in 18hours or so
<asac> assuming its done once in 24h
<asac> eggonlea: todays image isnt good enough?
<asac> imo that would be ok
<asac> if not let me know whats broken
<lool> ARCHES='armel+dove' buildlive ubuntu-netbook && ARCHES='armel+dove' for-project ubuntu-netbook cron.ports_daily-live
<lool> That's at 1:55 am london time, but after the imx51 build
<lool> Whoever wrote this line for it wrong though
<eggonlea> asac: installing... some minutes left.
<lool> StevenK, ogra: You might want to run a single cron.ports_daily-live; at least that's what I was told should be done back when I added the first desktop armel images
<lool> StevenK, ogra: see e.g. kubuntu-netbook
<ogra> lool, i thought StevenK discussed it with slangasek at the sprint when he changed ti 
<ogra> *it
<ogra> effectively it doesnt do any harm atm though, we dropped a lot of flavours
<ogra> (and still hope for an additional livefs builder)
<lool> I think it will cause two revs of the ubuntu-netbook/ports dir
<ogra> oh, right, i see what you mean
<ogra> for-project ubuntu-netbook cron.ports_daily-live shouldnt be there twice, i'll talk to StevenK 
<lool> There should be a single for-project ubuntu-netbook cron.ports_daily-live in the whole crontab basically
<ogra> yeah, that would make sense
<ogra> but getting the timing right might be problematic 
<ogra> especially for ports 
<ogra> will require some measuring
<lool> It shouldn't be
<ogra> well, i have no idea how long a livefs build for sparc, ppc or ia64 takes 
<lool> There currently is only one line whether this occurs
<ogra> i know hard numbers for armel only 
<lool> It doesn't matter
<lool> Just change ARCHES='armel+imx51' buildlive ubuntu-netbook && ARCHES='armel+imx51' for-project ubuntu-netbook cron.ports_daily-live ; ARCHES='armel+dove' buildlive ubuntu-netbook && ARCHES='armel+dove' for-project ubuntu-netbook cron.ports_daily-live to ARCHES='armel+imx51' buildlive ubuntu-netbook; ARCHES='armel+dove' buildlive ubuntu-netbook && ARCHES='armel+imx51 armel+dove' for-project ubuntu-netbook cron.ports_daily-live
<lool> Well actually s/&&/;/ in the new version
<ogra> no
<ogra> then dove wont build if imx fails
<ogra> the && was explicitly added 
<ogra> we had some runs where there were kernel package issues which then teared down all builds
<lool> You're confused, there's no && between imx51 and dove
<ogra> there should be :)
<lool> I disagree
<ogra> between the two buildlive runs
<lool> No
<ogra> but then the second one wont be attempted if the first one fails
<lool> It's not what we ever did and it's not what buildlive does
<ogra> it was changed a while ago
<lool> Precisely, the point is that you do want to try dove even if buildlive imx51 failed
<ogra> after i had a long discussion with slangasek how to make dove still build if imx51 fails
<lool> This is currently the case
<ogra> we want to
<lool> and would still be after my changes
<ogra> the ; between the commands makes cron stop the process if the first one exits non zero
<lool> No
<ogra> well, thats what happened several times
<ogra> ; is fine between the buildlive runs and for-project ... since we dont want the latter if the first failed but we want bot buildlive runs to happen inependently so one subarch doesnt block the other
<StevenK> lool: I've thought about all this
<StevenK> lool: I can't come up with a shell snippet to do what I want
<StevenK> lool: I don't like your suggestion either
<ogra> StevenK, ARCHES='armel+imx51' buildlive ubuntu-netbook && ARCHES='armel+dove' buildlive ubuntu-netbook ; ARCHES='armel+imx51 armel+dove' for-project ubuntu-netbook cron.ports_daily-live
<ogra> that should be a good start
<StevenK> ogra: And then imx51 fails and dove doesn't build
<ogra> he is right in saying we dont want cron.ports_daily-live twice
<ogra> no
<ogra> the && should avoid that
<StevenK> ogra: If imx51 fails buildlive, dove's buildlive won't get attempted
<ogra> if you use ; it wont, if you use && it will
<ogra> at least thats what slangasek worked out 
<StevenK> Yes, and read your shell snippet. imx51 buildlive && dove buildlive ; imx51 dove publish
<ogra> oh, you mean we need another &&
<ogra> right, that might be
<persia> Um, No.  We *don't* want && because that means "only do this if the previous succeeded"
<StevenK> Yes, we don't want "imx51 buildlive && dove buildlive && imx51 dove publish"
<persia> Right.
<persia> If we trusted things to work, we could do that, but we don't.
<ogra> well we dont want "imx51 buildlive; dove buildlive; imx51 dove publish" either
<ogra> that has proven to not work often enough
<StevenK> "I wonder if (imx51 buildlive ; dove buildlive) && imx51 dove publish" would work
<StevenK> Moving the " to the right place, of course
<ogra> hmm
<persia> No.
<persia> Or at least `(true; false) && echo works` doesn't do what I'd like.
<persia> Seems () returns the last return code from the series of commands in the subshell.
<StevenK> Bah
<persia> What we need is something like || that isn't optimised
<ogra> StevenK, how about doing all three of them in separate entries at different times ? 
<ogra> (with the necessary gaps indeed)
<persia> Why is that better than using ;; to do them sequentially?
<persia> Putting in gaps creates a race condition
<ogra> not if the gaps are big enough ... putting in ; obviously generates probelms
<persia> StevenK: `export DRESS="frumpy"; do-this && export DRESS="success"; do-that && export DRESS="success"; [ "$DRESS" == "success" ] && do-it-all`
<persia> (and yes, this is incredibly ugly
<StevenK> Hah
<persia> But now that I've typed that, I've actually started to process backscroll, and realise I'm kinda slow and that better solutions exist.
<persia> (like just fixing buildlive to not fail on first failure if it does)
<lool> StevenK: I see that got resolved on #ubuntu-devel since (shell snippet)
<persia> I think "resolved" isn't quite the right word, but here is no longer the right forum :)
<lool> Well cjwatson shared a shell snippet to the effect of what StevenK was asking
<StevenK> Which is ugly as sin
<lool> You could put that in a script
<lool> That might even be in moreutils  ;-)
 * StevenK waves his arms
<lool> "either_of_do"
<StevenK> I don't care, I did slangasek suggested, and I'm going to bed
<persia> lool: It's a rare enough case not to matter.
<lool> I'm just replying to uglyness in crontab
<lool> (I agree crontabs are not a proper place to write this kind of shell snippet)
<persia> heh.  context leak :)
<lamalex> hi everyone, is there a list of windows that dont fit on netbooks that need fixing/have been fixed?
<persia> lamalex: I don't know of any list of these, but there's been lots of fixes in that area.
<persia> Some of the 576 veritical pixel machines seem to still have lots of issues, but those aren't getting much sympathy from most deelopers.
<persia> But there's still some stuff that doesn't fit in 600 pixels, although I don't think anything left in the default images.
<lamalex> thanks
#ubuntu-mobile 2010-02-12
<lool> Folks, netbook-launcher-efl FTBFS since it expects liblauncher-0.1 and we have 0.3
<ogra> yes, its being worked on by Jamie
<persia> rbelem: Rumour had it that you had finished an ubuntu-liquid-default-settings package.  Can you confirm?
<rbelem> eheheh
<rbelem> persia, it is almost done :-)
<rbelem> i did not work the last weekend, so i did not make much progress :-(
<persia> rbelem: OK.  No huge rush.  I'm planning to try to put together the -meta this weekend.
<persia> I'll put it as a "recommend" for now, and we can adjust later, once it's available.
<rbelem> i was a little bit chocked yet, so i decided to take the weekend off to relax
<rbelem> :-)
<rbelem> persia, cool
<rbelem> persia, are you in which timezone?
<persia> UTC+9
<rbelem> persia, ah! next week is carnaval here, so i will have more time to work on liquid :-)
<persia> Well, at least that's what is claimed, but I often feel more like http://xkcd.com/448/
 * persia is amused at the idea of hacking for carnaval
<rbelem> persia, uaheuaheua
<rbelem> persia, following this routine is nice when you travel. you do not feel the timezone change 
<rbelem> eheheheh
 * persia wishes
<rbelem> eheheh
<rbelem> :-D
<asac> hi rbelem ... how are things going?
<rbelem> hi asac :-)
<asac> i guess that means you feel great. good to hear
<rbelem> i will get back to work this weekend
<asac> work is always good ;)
<rbelem> eheheh
<rbelem> :-)
