[03:17] any thoughts on how to detect whether an app is running inside of UME or not? [03:31] i'm guessing it'd be possible to run ubuntu-mobile under a vm? [03:36] sure [03:36] run it well? eh [03:36] lol [03:36] you can run it in a window on your desktop [06:36] good morning === asac_ is now known as asac [07:48] Hi [08:24] hi [08:26] I installed the UME stuff on my Ubuntu 7.10 laptop, and the mobile gui looks great. However, the standard Gnome has become ugly and almost unusable as it is missing checkboxes etc. Is there any way to run both the UME gui and standard gnome side-by-side (as different users)? [08:27] I am running this on my Everex Cloudbook, a C7-M powered device with a 7" display with the resolution of 800x480 pixels [14:13] davidm__: hey, just a note, when you get back from CELF, TinCanTools will ship you a clear tube case for your Nail_Board [14:14] I installed the UME stuff on my Ubuntu 7.10 laptop, and the mobile gui looks great. However, the standard Gnome has become ugly and almost unusable as it is missing checkboxes etc. Is there any way to run both the UME gui and standard gnome side-by-side (as different users)? I am running this on my Everex Cloudbook, a C7-M powered device with a 7" display with the resolution of 800x480 pixels, and want to be able to [14:30] mboman: The problem is that the window manager used on UME (matchbox) assumes a few different things like the applications will run fullscreen for instance and the applications are not usually designed to work on such different resolution so running a standard Gnome/GTK application on UME mostly works but you will encounter problems with useability. [14:32] i mean that I have 2 different system accounts [14:32] one for the UME stuff [14:32] one for Gnome stuff [14:32] UME stuff gets a 'mobile' user that auto-login to the system etc.. [14:32] then the other one is for more personalized usage [14:33] mboman: Ah, never tried this but you may indeed encounter problems as they share a few gconf keys IIRC. They weren't designed to work together. [14:34] ok [14:34] I'll try it out when I get back home === agoliveir1 is now known as agoliveira [14:54] Has anyone put Ubuntu Mobile on an eeePC? I'm googleing, but haven't found anything conclusive [15:01] * Hobbsee wonders what the case is with realplayer [15:02] inkynoob: It should work out of box except for a few things like the wifi. You will probably be able to use a kernel from ubuntu-eee project on it. [15:02] inkynoob: But I wouldn't recomend due the lack of touchscreen. [15:03] There's touchscreen kits, if Ubuntu Mobile looks like it'll work, I'd be very happy to install one :-) [15:04] I installed ubuntu-mobile from the gutsy repositories, should I be running Hardy insteady? [15:05] oh, headdesk. [15:06] is Brian Thomason here? [15:09] * Hobbsee ponders giving a comprehensive list of why this package appears to be E, B & W, or just rejecting it outright. [15:10] inkynoob: Yes and remember that UME is currently a moving target. Lot's of things are changing and fast. [15:10] inkynoob: and, BTW, we apreciate any bug reports you may add, thank you very much :) [15:16] * Hobbsee is told it's a partner thing. never mind [15:21] Thanks agoliveira, I'll try it out. I don't need stable, I just need something almost stable :-) I'll report any bugs I find [15:22] inkynoob: UME is mostly stable, there's no big crashes around as it's mostly based on already stable software. You may find more things like applications that don't start due some missing configuration file, weird interface glitches, etc. [15:23] cool === doko_ is now known as doko [16:46] lool: any idea why alsa-base and alsa-utils aren't installed in your team's builds? Were they deliberately removed? [16:58] smagoun: I don't think they were, let me check [16:59] smagoun: They were not excluded in the seeds at least [16:59] Meeting in one minute [17:00] smagoun: if you discover how they are pulled on your side, I'm happy to mirror that otherwise i'll pull them via the seeds with a comment on why they are needed [17:00] #startmeeting [17:00] Meeting started at 18:00. The chair is lool. [17:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:00] Hi everybody; hope you're warm for the meeting! [17:00] Allow me to start with last weeks actions [17:00] It's just 20°C right now but warm enough :) [17:01] agoliveira: Good enough :) [17:01] [topic] # [17:01] [topic] rustyl_ to assign ppa packages updates for the new tarball based release process [cted as blocked by lool last week and the week before that...][cted][cted] [17:01] New Topic: # [17:01] New Topic: rustyl_ to assign ppa packages updates for the new tarball based release process [cted as blocked by lool last week and the week before that...][cted][cted] [17:01] rustyl__: So I think yoy assigned remaining updates to inuka_desk, is that correct? [17:01] On that front, I have to send you the minutes from yesterday's meeting [17:01] lool, yes [17:01] Cool, so closing this [17:02] (NB: The target date for the updates would be 20th / 22th the latest to be in the 24th build) [17:02] Moving on to next topic then [17:02] [topic] bspencer to list i18n status for Moblin project[cted][cted] [17:02] New Topic: bspencer to list i18n status for Moblin project[cted][cted] [17:02] I've worked on that [17:02] polled all parties [17:02] :) [17:02] there are still 2-3 projects needing attention [17:02] Cool; could you report on your findings? :) [17:02] bspencer: Could you list them on a wiki page? What's the plan for these modules? [17:02] namely: mobile-basic-flash. Minimal dialogs (e.g. "Starting X app") [17:03] Ack [17:03] marquee also (clock?) [17:03] yes. I'll put them on a wiki page [17:03] Ok; anything else on the top of your head? [17:03] applets, FF, and moblin-media should be done (per their owners) [17:03] one note about FF [17:04] carl explained to me how l10n pkgs would need to be tweaked [17:04] basically, MIDbrowser is i18n, but the existing FF l10n pkgs won't work as-is [17:04] asac probably has a very good idea of this [17:04] they need to have a wrapper installer pkg [17:04] that unpacks the originally, tweaks the ID, then installs them. [17:04] bspencer: Could you discuss this topic with asac and cwong? [17:05] I think this is asac's idea. Yes. I'll talk to them. [17:05] asac has been recently working on the langpacks for firefox with the help of davidm, and I'm sure it wont be too hard to reuse this work for midbrowser [17:05] yes, right. Reuse, just not completely free. [17:06] bspencer: Thanks; I guess this will all go to the wiki page; perhaps the one with the langpacks info is the one that makes sense, otherwise a moblin i18n status page is nice [17:06] bspencer: Do you want an action on it? [17:06] lool, ok. I love action items [17:06] I guess you can easy do that immediately after the meeting, so not sure you need an explicit action [17:06] lool, doesn't hurt [17:06] But then it would be the occasion to strike it in two minutes [17:07] [action] (bspencer) document status of i18n of moblin modules on Ubuntu wiki; needs discussion with asac and cwong for FF [17:07] ACTION received: (bspencer) document status of i18n of moblin modules on Ubuntu wiki; needs discussion with asac and cwong for FF [17:07] [topic] GrueMaster file a bug on helix build missing alsa support [17:07] New Topic: GrueMaster file a bug on helix build missing alsa support [17:07] GrueMaster: What's the bug id? [17:07] Filed [17:07] lool: what's the latest version of nm-applet in hardy? We have a few emergency bugs to fix in it and I need to pull the latest [17:07] I'll have to look it up [17:07] * ToddBrandt oops, didn't know the meeting started already [17:08] ToddBrandt, lool is on fire. Lookout. [17:08] GrueMaster: Just open the list of bugs you filed on launchpad [17:09] Ok, the bug is 215242 [17:09] Sorry, had browser issues. [17:09]

ToddBrandt: dpkg -S nm-applet => network-manager-gnome => rmadison network-manager-gnome [17:09] GrueMaster: Thanks [17:09] * ToddBrandt thanks [17:09] GrueMaster: I'm not exactly sure this is what we really want to fix [17:10] Ok. What's your reasoning? [17:10] GrueMaster: I guess our toplevel target is "getting sound working in helix", and the ideal way would be to use its alsa support -- do you agree? [17:10] GrueMaster: In this case, I think we should change the way we build helix to enable alsa [17:10] This is true, but there are still other applications that use OSS. [17:10] if this fails, we should consider OSS, or if we have other requirements [17:11] GrueMaster: In our builds? If they do, they should depend on it, and we shouldn't have to pull it manually [17:11] For example, say an end user wants wine support. [17:11] GrueMaster: helix could also be changed to pull it (depend on it) [17:11] Is OSS is a good idea? Could introduce a series of blockings on the sound device [17:11] GrueMaster: wine depends on libasound2; that lets me think it would suppor talsa [17:12] There are a lot of applications that depend on oss outside of ume. [17:12] GrueMaster: And that we don't package and care about? [17:12] * agoliveira thinks those should die and quick! [17:12] As to wine, it must be fairly new. [17:12] Yes [17:13] GrueMaster: Perhaps we should list a couple in some place and set this an explicit goal for UME then firs [17:13] t [17:13] "Support OSS for non packaged random apps that users will install" [17:13] The point is that we should be providing a stable base, and alsa-base doesn't take much room for the support it provides. [17:14] But just starting with the fact that these aren't packaged (or improperly) and not distributed by us lets me think we shouldn't care as our top priority [17:14] Also, I think the alsa power management tools are in alsa-base. [17:14] That's a much more motivating rationale for using more space in the builds :) [17:15] More space? We're now kuibbling over a few K. [17:15] GrueMaster: So could you either change the bug report into two bug reports; one asking for alsa support in helix builds and one asking for alsa-base to be directly included for $rationale? [17:15] alsa-base has mainly a modprobe.conf file. [17:16] -either [17:17] GrueMaster: Do you agree that the two things are good and useful and that we can prioritize / discuss / implement them separately? [17:17] GrueMaster: Do you mind if I task you with the filing of the second bug and the update of the first? :) [17:18] So, what you're asking me to do is file a separate bug for helix, then conjure up a justification for alsa-base, which is only a few K? Is this correct? [17:18] GrueMaster: That's about it; concerning alsa what matters is that we have some good understanding of why we pull it so that anyone can look it up [17:19] If it helps save power, I'm all for it [17:19] That would be nice to know. Why was it pulled in the first place? [17:19] GrueMaster: Probably as a dependency of something which moved to alsa now [17:19] But I don't really know, I would have to dig in old stuff to find out [17:20] GrueMaster: If that makes sense to you, I propose a couple of action items for this (IMO fast) bug work; fine with you? [17:20] I'm still fuzzy on the whole debian/ubuntu packaging dependancy thing. [17:20] Sure [17:20] GrueMaster: Well I think packages which only work with OSS and not alsa should depend on OSS, that's clear === davmor2 is now known as davmor2_away [17:21] Concerning support of non-packaged software, that's not something I know are in our current goals, but if it's something desirable we could discuss this [17:21] But trying to guess what might be useful is a slippery slope, so it needs discussion, motivations etc. [17:21] Ok, let's go for the actions then [17:22] lool: as in now (for imediate release) or for next release? [17:22] [action] (GrueMaster) update #215242 to request enabling of alsa in helix builds (or a dependency on oss support in alsa) [17:22] ACTION received: (GrueMaster) update #215242 to request enabling of alsa in helix builds (or a dependency on oss support in alsa) [17:22] * agoliveira means discussing at UDS as in "next". [17:23] [action] (GrueMaster) file new bug requesting addition of alsa-base to the seeds with the rationale of the power management features it provides [17:23] ACTION received: (GrueMaster) file new bug requesting addition of alsa-base to the seeds with the rationale of the power management features it provides [17:23] GrueMaster: TIA [17:23] TIA? [17:24] agoliveira: I think we should try having such discussions with "high level goals" for the images at UDSes, but then easy topics/goals/features not eating up too much time and consensual in nature can be added in the middle of our dev / release cycles IMO [17:24] GrueMaster: Thanks in advance :) [17:24] ah === robr___ is now known as robr [17:24] Ok; I don't any additional action from last week [17:24] I'm moving to the current items now [17:25] [topic] Plans for Intel regarding UDS. agoliveira. [17:25] New Topic: Plans for Intel regarding UDS. agoliveira. [17:25] I think this says it all [17:25] Well, self explanatory: is there any yet? [17:25] Who from Intel is scheduled to come yet? :) [17:26] bspencer, GrueMaster, rustyl__, ToddBrandt, inuka_desk [17:26] i don't have an answer yet... a request is going through managment [17:26] rustyl__: Cool; do you have an idea when we can expect to know who will come? [17:26] It's also a good time to submit topics if you didn't already [17:27] the sooner the better [17:27] i really don't know [17:27] i'm not the decision maker on this [17:27] rustyl__: Ok; please tell us as soon as you know so that we can plan beer t-shirts and the like [17:27] the Canonical/Intel rep is working this [17:27] rustyl__: But you can post your ideas anyway, just in case. [17:27] Oh and action items naturally [17:27] ok [17:27] Everyone loves action items [17:28] * agoliveira usually runs from them :) [17:28] Ok; anything else to discuss in today's meeting? [17:28] * agoliveira is ok [17:28] loo: one thing [17:28] the hardy ppa and the dependency problems [17:28] ToddBrandt: Go ahead [17:28] ToddBrandt: Oh right [17:29] ToddBrandt: I was on leave when your message arrived, I resumed work yesterday and saw that this was fixed, but kept it in my TODO to discuss it with you [17:29] There seem to be alot of conflicts with hildon-desktop and telepathy, can we make sure everyone knows that when they upload to the PPA to upload all the dependecy upgrades first [17:29] I sincerely doubt I'll be going anywhere. [17:29] ToddBrandt: I'm happy to have a one to one to tell you the secret technique we share to fix these issues [17:29] sweet [17:29] Just don't tell anyone [17:29] heh, ok [17:30] GrueMaster: Prague! In May! If management doesn't allow it, take some holidays and join! [17:30] Need $$$ [17:30] Otherwise I'd love to. [17:31] Hmm starting a night job wont work I guess [17:31] ToddBrandt: Let's have this next week together; on IRC or phone as you like [17:31] * agoliveira whishes it was a little closer and not in wedding's aniversary :( [17:31] I already have one. Plus I'm working on getting my degree. [17:31] sounds good, let's do IRC next week around wednesday ish [17:31] [action] (ToddBrandt and lool) workshop on solving dependency issues in ppa [17:31] ACTION received: (ToddBrandt and lool) workshop on solving dependency issues in ppa [17:31] GrueMaster: Ah, poor you [17:32] GrueMaster: Join us over the phone then; there should be some setup for remote attendance [17:32] Lesser quality, but doable [17:32] Ok; I'm about to close the meeting [17:32] Yea, but the beer isn't as good. :P [17:32] Anything else needing attention? [17:32] GrueMaster: We can aways get some from Belgium :) [17:33] Still outside of my commute range. [17:33] Okely, then I'll close the meeting; I wish you all a nice day [17:33] #endmeeting [17:33] Meeting finished at 18:33. [17:33] ToddBrandt: Could you send me an email with your preferred dates for next week? I /think/ sometime Tuesday would be good; I'm going to be on the east coast [17:34] lool: will do, thanks [17:34] * lool & [17:42] lool: I lost my link to the minutes and never can find the darn things off UME launchpad, can you please send me the link === davmor2_away is now known as davmor2 [17:57] asac: do you have the bandwidth to accept some patches to the 0.6.6 network-manager-applet package for hardy? [18:16] lool: re: alsa. We noticed alsa-base and alsa-utils are no longer included in our builds after we resynced with hardy+ppa. We thought you or StevenK might have removed it from the seed for some reason. [18:36] smagoun: From a quick look at the log, I don't see any message mentionning alsa [18:36] smagoun: http://bazaar.launchpad.net/%7Eubuntu-core-dev/ubuntu-seeds/ubuntu.hardy/ [18:36] bzr log mobile | grep -i alsa [18:37] lool: right, but StevenK deployed a new seed for the PPA [18:37] smagoun: Oh [18:38] smagoun: Don't see recently modified seeds at https://code.launchpad.net/~ubuntu-mobile nor https://code.launchpad.net/~stevenk [18:39] https://edge.launchpad.net/~ubuntu-mobile/+archive?field.name_filter=ubuntu-meta&field.status_filter=published says some stuff was added [18:39] lool: I think the seed is here for some reason: http://people.ubuntu.com/~stevenk/mobile/seeds/ [18:39] It must be pulling from somewhere, I wonder where [18:40] smagoun: Anyway, it wouldn't be a removal from your pov, would it? [18:40] Hmm unless it was dropped somewhere else than mobile [18:41] desktop: * gstreamer0.10-alsa [18:41] mobile: * gstreamer0.10-alsa [18:41] Is all I see in the normal seeds, so it doesn't look like it was pulled until now [18:41] smagoun: I suspect $random_package was pulling it indirectly; if you have an old image, you could check the rdeps of the package perhaps? [18:41] lool: yes, it is a removal. We had alsa-base and alsa-utils in our image until we synced with hardy+ppa on 14April. I'm trying to figure out where it wend [18:41] s/wend/went [18:46] smagoun: Tell me if you find out more :) [18:48] ToddBrandt: what kind of patch is that? [18:48] asac: three bug fixes [18:48] one to asdd a moko scroller to the AP list, and two to fix some behavioral issues [18:49] my bandwidth is fully utilized ;) for today and probably tomorrow. ... if those issues are really important and the patches are not that intrusive i can take a look if we can get an exception for that [18:49] asac: ok, thanks [18:49] ToddBrandt: how intrusive are those patches? [18:50] doesn't really sound like its a single line patch [18:50] asac: one other question, I have created a hardy project root with the latest hardy ppa snapshot and the network-manager-applet package has a couple errors in it. Have you seen that? [18:50] asac: yea, the moko will be an added library and include and about a paragraph of moko insertion [18:50] asac: the other two should be just a few lines hopefully [18:51] ToddBrandt: can't we push those changes to hardy ppa and intrepid? [18:51] i plan to do that for the risky changes i have for xulrunner+midbrowser as well [18:51] asac: well, my plan is to build from the 0.6.6 latest, then push a version to the hardy ppa temporarily, then send you the patches for inclusion [19:30] bspencer, thanks for the response [19:30] hope it helps [19:30] bspencer, is there a possibility of enabling and disabling moko scrolling on a per application basis? [19:31] per application? or within an application? [19:31] I /wish/ that it was the default for all apps, that would be cool. [19:31] but actually each app has to do extra work to get it. So yes to your question. [19:32] I see, so in photo viewer I could not enable it [19:32] or only enable when zoomed [19:32] right. that is how we would want it to work. To disable moko when not zoomed somehow. [19:32] but you think that is tricky [19:33] just unknown. The window gets added to a moko parent widget. You probably don't want to reparent the window every time the user zooms in/out [19:33] seems cleaner to have moko understand the gesture itself, since it is already interpreting the mousemove events. [19:34] although that is overloading moko, which is designed for scrolling [19:35] hmmm, thinking [19:35] one option is add a patch to moko that forwards moues events when it isn't using them for panning (width/height of content <= width/height of screen). Then have another component do the gestures. [19:36] right then we could just set a mode somehow? [19:36] yes, or moko just auto-knows [19:36] if no scroll bars needed, it switches [19:36] right [19:37] no scrolling to do, pass it through [19:37] then there is the question of bouncing on the edge. [19:37] ? [19:37] when you get to the edge of content currently, it kind of bounces it back [19:37] but when I recall, I don't think that bouncing works if there are no scroll bars. Only when there is -- like at the end of a list. [19:38] but it knows there is more content than fits the window [19:38] yes. So I think that strategy we just mentioned would work. [19:39] ok, so when can you bang that out :-) [19:39] as soon as mawhalen gives me the nod [19:39] darn, was just on the phone with her [19:39] bspencer: pmcgowan ? [19:40] ha! well she's been running the feature request through many meetings here. [19:40] I haven't read the thread [19:40] bspencer, has it all worked out [19:40] mawhalen, np. Just read pmcgowan's last few lines. [19:40] starting with "ok, so when can you bang that out" [19:40] bspencer: do I need to talk to Terence? 8) [19:40] no - really - do I need to do something here? [19:41] mawhalen, we were trying to scope what the work would be for gestures [19:41] your favorite subject [19:41] bspencer: I just saw the word gestures... [19:41] that's the extent of the discussion. [19:41] bspencer: you can always scope it [19:42] pmcgowan, just throw bfiller on it. We accept patches [19:42] bspencer, given we have the old code, seems like we could restore it in a resaonably short time? [19:42] bfiller took 4 days off, the nerve [19:42] pmcgowan, not so easy. The old code conflicts with moko. And it has no rotate support [19:43] it did have rotate support? [19:44] I don't think so. Just left/right. Maybe I'm wrong, I didn't spend much time on it -- just found the place we removed it. [19:44] no, I used it, worked great [19:44] thats why customers liked it [19:44] well seems like a change to photoviewer to restore the code, and a change to moko to pass through events if no scrolling is needed [19:45] yep. [19:45] is it easy to identify the old code in the tree, or can you extract and send the relevant file to me? [19:46] mawhalen, or can you assign an engineer to do what I just wrote? [19:48] pmcgowan, I can point you to the date when the code was removed. anyone can pull the code from the git repository [19:48] praj, [19:49] bspencer, mawhalen is not answering my staffing request [19:50] pmcgowan, she's a talented program manager [19:50] indeed [19:50] I can get you the info you need to get the gesture code from git, Yes. [19:50] via praj. [19:50] praj-laptop, [19:51] bspencer, who works on the moko stuff for you? [19:51] frank li has done all that work. PRC guy [19:52] so can he make the change to conditionally not consume the events? [19:54] pmcgowan, you still need to work with mawhalen. Everyone is working on other things. :-\ But he /could/ do that, if he were given that to do, yes. [19:54] bspencer: pmcgowan talking to folks in my cube - [19:54] we do not have por to do gestures [19:55] that darn por again [19:55] who do I have to bribe? [19:55] pmcgowan: i've had many an internal conversation [19:55] bribe craig [19:55] he doesnt code [19:56] mawhalen, so are you saying its out of your hands, is there someone I should escalate to? [19:56] mawhalen, I think its less than a day of work [19:56] yes, that is what I was trying to say [19:56] pmcgowan: not what I hear, don't always trust Bob [19:57] we just simplified the design :-) [19:57] actually - a really good starting point would be for someone to make use cases [19:57] i don't want any ambigious requirements [19:58] mawhalen, what it used to do is the use case, it was fine [19:58] really - out of my hands and I have a meeting in 2 minutes in another building, so must take off... [19:58] ok, later [19:58] you'll have to keep talking to bspencer === doko_ is now known as doko