#ubuntu-mobile 2008-02-01 <dholbach> good morning <StevenK> HappyCamp_laptop: https://wiki.ubuntu.com/PackagingGuide <HappyCamp_laptop> StevenK: Thanks! <smagoun> Hi all, I'm looking for a sponsor to get an update to the moblin-applets package into universe: https://bugs.edge.launchpad.net/ubuntu/+source/moblin-applets/+bug/187181 <ubotu> Launchpad bug 187181 in moblin-applets "Upgrade to moblin-applets 0.27" [Undecided,In progress] <sabotage> kyleN_: apt-get install gtk-theme-switch <kyleN_> sabotage: excellent. thx <sabotage> Its a start (someone elses) and does not yet handle icons that I can see yet...still looking at the source <sabotage> but it does what you wanted <kyleN_> sabotage_afk: that's a big leg up for us. much appreciated #ubuntu-mobile 2008-02-02 <sabotage> kyleN_: after reading through the code for gtk-theme-switch, it seems to only update gtk rc settings and not in a system wide way, but only by users ~/.gtk-2.0/gtkrc file <kyleN_> sabotage: does it do it system wide for the current user? <sabotage> so its assuming a desktop env with multiple users, not quite what we're trying to address, but could be adapted to our needs <sabotage> yes/no... <kyleN_> sabotage: not sure the multiple users assumption is relevant for a MID though <sabotage> settings in users home dir take precedence over system wide, so it *looks* system wide <sabotage> agreed <sabotage> also, it's missing some key subsystem settings <kyleN_> looking sys wide may be good enough <kyleN_> what's missing? <sabotage> like matchbox, icons, gconf settings and backgrounds <kyleN_> matchbox and backgrounds strike me as critical <sabotage> not if we don't have a "user" (we do now, but not sure if that will stay the case) <sabotage> background is actually quite /interesting/ <sabotage> ;) <sabotage> setting the X background does nothing for us <kyleN_> why, on one ever sees that? <sabotage> the background is HomeArea dependant <sabotage> so if the UI is flash based, then we need to get the flash plugin to change its bg image <sabotage> if it's HTML/Xul based, then we need to effect the DOM settings via CSS or some Javascript interface <kyleN_> well, the home plugin flash shows sometimes, then it reverts to the normal marquee + app when an app launches <sabotage> and if we use Clutter, well, I've no idea yet how that gets changed yet ;) <kyleN_> right, those are good points. our specific need is flash home ui, user changes it, then the rest of the UI gets the same fonts/colors/gtk theme <sabotage> but when the app goes away, then the flash ui shows again and I assume you want the bg changes to be persistant, right? <kyleN_> the flash ui is full screen <kyleN_> so there is no bg <sabotage> most of the rest is very doable...just not 100% sure how we'll tackle the background <kyleN_> where's the background if the flash ui is full screen? <StevenK> Behind the flash ui, I'm guessing <sabotage> that's a misnomer...the HTML ui and the Clutter ui are also "fjull screen", but all of them have "background" like properties that users will want to alter <kyleN_> right - invisible, right? <sabotage> no, embedded in the flash SWF <kyleN_> ah, our short term need does not involve the user changing it <kyleN_> say, two flash movies, with two equivalent themes. not user configurables <sabotage> does your idea of changing the theme involve sending a message to the flash ui to change its colors. etc...? <kyleN_> actually, there are multiple flash movies, i believe <kyleN_> the user can switch between them <kyleN_> they have a different look and feel <kyleN_> when the user switches, we want all the rest to switch too <sabotage> ok for now I suppose, but most users will expect to be able to set an image in their photo viewer/library to the screen background <kyleN_> that is, they switch, then launch an app, flash goes away <sabotage> right? <kyleN_> marquee and app are themes to match the flash move <kyleN_> yes, that will be nice but it is not a deliverable for the custom team right now <kyleN_> the other is <sabotage> ah, you're switching the HomeArea applet then...that's a bit different, not really "theme" related <kyleN_> we switch, then the REST switches accordingly <kyleN_> automatically <kyleN_> where the REST is colors fonts and gtk theme <sabotage> ok <kyleN_> you think that is likely to be doable without too much mountain climbing? <sabotage> so then the "REST" you are refering to should be doable <kyleN_> excellent! <sabotage> the current tool is a bit insufficient but adaptable. <kyleN_> i figure when the flash switches, it uses out javasscript api to make the appropriate calls, whatever they turn out to be <sabotage> I've a running list of thing it needs to be adapted to do <kyleN_> this will be a big help <sabotage> I'm not promising to *DO <sabotage> * the changes ;) <sabotage> though I'll probably take a stab at it as it relates to the rest of the theme work I am doing <kyleN_> right. whatever you can do, even if it is just invistigate and report, that will be a help <sabotage> it's just not on our POR to provide a theme switcher <sabotage> yep <kyleN_> cool. I'd like to stay in touch on this <kyleN_> but for now, our week in Hillsboro is just about OVER! <sabotage> I'll send my notes to the mail list once I get back on the Intel network <kyleN_> back to soggy massachusetts <kyleN_> cool <sabotage> soggy or snowy? <kyleN_> soggy, i hear. <kyleN_> was snowy though. we had three snowfalls of 10-12 inches each earlier <feng_> ;d <feng_> ;dls <feng_> sorry for the mis-input, just tried a new BT keyboard <Termy2007> hi.. i want to ged rid of windows mobile 2003 se on my t-mobile pda... will ubuntu mobile be available for this device? <Termy2007> can anyone help me? <ComradeHaz> Evening gent's. Pretty sure I know the answer, and pretty sure it's no - but has ubuntu mobile made it onto any HTC Kaisers yet? #ubuntu-mobile 2008-02-03 <rzr> hi <rzr> look for this device : http://linuxdevices.com/news/NS9710143183.html #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 gregory37@example.net. <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 gregory37@example.net. <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 gregory37@example.net. 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 "(930)970-5854 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 gregory37@example.net or 0.7? <StevenK> Ugh. The dix/getevents.c differ too much between git and
{'channel': 'ubuntu-mobile', 'month': 2}