=== jldugger-tablet is now known as pwnguin === pwnguin is now known as jldugger-tablet [16:18] hi ubuntu-mobile maniacs ! [16:18] is there yet a channel for Remix ? === djp_ is now known as djp [16:21] or is this the place ? [16:42] djp: We don't have a channel for remix [16:42] djp: I suspect remix people are around [16:43] At least njpatel is :) [16:57] a couple of things I wodering; [16:58] will it be available for non-Atom CPUs ? [16:58] when the anndouncement mentiones "optimized for retail" what do they mean ? [16:59] to put on machines to sell ? or to put on machines for sales (I want the latter) [16:59] Meeting in one minute [16:59] when will it be ready ? [16:59] ok [17:00] #startmeeting [17:00] Meeting started at 11:02. The chair is lool. [17:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:00] Hi everybody; thanks for attending this week's meeting [17:00] The agenda is at https://wiki.ubuntu.com/MobileAndEmbedded/Meeting/20080612 [17:00] I love this week's agenda [17:00] As I read it, we have no items to revisit from last week [17:01] Nor for this week [17:01] So it's open agenda season! [17:01] I'll hang around for 5 minutes or so in case anybody would like to add an agenda item [17:01] should we discuss RC3? [17:01] [topic] RC3 discussion [17:01] New Topic: RC3 discussion [17:01] cgregan: Sure, go ahead! [17:02] * persia likes RC3: works better than any previous images [17:02] I just wanted to say that is was built and is working great [17:02] Passed all smoke tests [17:02] where's rc2? [17:02] Cool; same here, it works great for me [17:02] Not bug free....but I'd agree with lool and persia [17:03] RC2 is still up in the release area on cdimage Gruemaster [17:03] No one notified us that it was ready. [17:03] GrueMaster: I still see rc2 http://cdimage.ubuntu.com/moblin/releases/hardy/ [17:03] Yea, I see it now too. [17:03] However StevenK plans some cleanup of at least the beta images soonish [17:03] no problem there. [17:03] RC3 is much better GrueMaster [17:04] We believe this will become Final soon [17:04] Will get and start testing it. [17:04] There are some great VM image building instructions over with the cases on the wiki [17:05] https://wiki.ubuntu.com/Testing/Cases/UMEinstall [17:06] That's all I had on RC3 [17:06] Ok [17:06] I'm currently spending my time on misc small bug fixes and on virtual-mobile-builder [17:06] We should develop some method of alerting the community to new builds [17:07] Can we have an action item for me? [17:07] cgregan: I think it will make more sense when we actually spend the time to build more generic images; e.g. targetted at eepc [17:07] cgregan: Also, marketing announces releases here [17:07] Ahh [17:07] cgregan: That said, I think you can happily take an action to talk to marketing to send announces about RC-N releases or betas [17:08] In fact, these should be announced along the regular Ubuntu releases in the next cycle IMO [17:08] (alpha 1, 2, 3, etc.) [17:08] Will do [17:08] [action] cgregan to talk to marketing about announcing pre-releases of UME [17:08] ACTION received: cgregan to talk to marketing about announcing pre-releases of UME [17:08] Ok; if we're done with rc3, any other topic for today? [17:09] cgregan: Might be worth also working with stgraber to get these as part of the ISO tracker (although these are not ISO images). [17:09] Yes...there is already discussion on moving testing to ISO tracker [17:09] * persia likes alignment of effort [17:10] Ok; I see no new topic on the wiki page, so I'll just take this occasion to warn people that they should be very very careful about uploads to the ppa [17:10] The ppa is now our stable-updates testing area; once an update is tested, it will be promoted to the release archive [17:11] lool: That's now for SRU candidates only, right? New stuff should go into intrepid? [17:11] persia: Exactly [17:11] No new development or releases should happen in the hardy ppa; unless needed to fix a grave stable bug, but that's unlikely [17:11] * persia is willing to be a contact point for anyone having issues getting updates into intrepid (not always as uploader, but for process questions, etc.) [17:11] Get in touch with me if you want to prepare such uploads and need guidance [17:11] Or ask persia :) [17:11] lool: there is also risk when image-creator changes. I assume that can affect you too, tru? [17:11] e [17:12] bspencer: Where would it change? [17:12] bspencer: We currently use the packaged image-creator which is in our ppa [17:12] for example, it just changed to use autogen.sh [17:12] ah, ok. [17:12] no risk then [17:12] Which has the new platforms for the release archive [17:12] That new MIC should be targetted at intrepid now [17:12] Not sure it was released though [17:12] I haven'tused a packaged image-creator for over a yar [17:12] year [17:13] bspencer: That explains :) [17:13] all our docs say to pull from the source and build/install [17:13] and that the packaged one is out of date and uncertain [17:13] :-\ [17:13] bspencer: All our docs say to install the package ;) [17:13] cool. glad it works actually [17:14] I wasn't sure you were updating and testing with it. Good news [17:14] I can only use the packaged one [17:14] It has many fixes we rely on [17:14] are the platforms in the packaged version highly customizes? [17:14] d [17:14] bspencer: "highly" not really [17:14] We add a couple of platforms [17:14] bspencer: Sounds like a focus thing: it's likely best for upstream types to use VCS trunk directly, and for Ubuntu Mobile hackers to use the package, and push candidate changes in bug reports. [17:14] well, I mean have you eliminated unused ones. [17:14] One for mccaslin, one for menlow [17:14] hardy+ppa [17:14] and a new one for eeepc ? [17:14] We didn't eliminated uneeded ones [17:14] There's no platform for eeepc yet [17:15] ok. thx. [17:15] persia: true, although we're all Ubuntu Mobile hackers (IMO) [17:15] Another thing we change in the platforms we build against is that we drop most packages in fsets and use the ubuntu-mobile metapackage to pull things instead [17:15] lool: right [17:16] bspencer: Excellent :), although I suspect we won't all also be upstream as we grow. [17:16] bspencer: I'm happy to work on making the packages better [17:16] bspencer: In fact I've prepared a non-negligible number of patches for MIC [17:16] lool: great [17:16] Half of them aren't merged yet, so I wouldn't be able to move to a new MIC without rebasing them [17:16] ok. We'll do that after your UME release [17:17] meaning -- we can focus on getting those things in [17:17] That said, I would recommend you to publish packages of any app you tell users to use; that is, if you're unhappy about the age of our packages, we could of course try to fix that, or you could publish newer MIC packages in other repos [17:17] because manually installed apps tend to break subtly with old files not being removed and generally mess up one's system [17:18] How many times have I received bugs about crashes resulting from libs installed by the end user in /usr/local/lib :-/ [17:18] Anyway, sorry, I'm getting offtopic :) [17:18] got it [17:18] I wish everybody a happy week then [17:18] thanks for attending! [17:18] #endmeeting [17:18] Meeting finished at 11:21. [17:18] djp: Back to you now [17:19] djp: Concerning readyness, and availability; I would guess your questions are partly covered in the FAQ [17:19] djp: Regarding architecture: the majority of code isn't actually architecture specific, although you may have some testing to do in order to verify it works on an alternate architecture (not that there are that many SPARC or PPC mobiles about) [17:19] djp: if not, I'd be happy to complete it [17:20] persia: technically, many bits are only enabled if arch == lpia though [17:20] lool: True, but some of those cases are bugs [17:21] persia: Yeah; it was a shortcut to do things like this [17:21] And a nice shortcut, cause it is indeed much harder to do properly :) [17:21] Very much so. [17:22] What do you people use to push .debs to your kvm? you publish them over http and then wget them? push to a ppa? [17:23] scp? [17:23] I like being able to simply scp them, but I'm not sure I can reach my kvm [17:23] at least I can't ping its ipv4 from my desktop [17:23] I guess a different network backend would help [17:23] Heh. What are you using? bridged? [17:24] I think not; I'm using whatever is the default [17:24] Let's try bridged [17:24] i think it didn't work on my laptop, but wifi is too special [17:24] Ah. usermode. You want to add iface br0 to /etc/network/interfaces [17:25] persia: What do you pass kvm for bridged mode? [17:27] lool: https://help.ubuntu.com/community/KVM will probably answer your next couple questions as well. [17:31] persia: So I'm not too familiar with libvirt, but it seems either you create VMs without it and then configure each VM manually, or you create VMs with it, and then you need to use it [17:32] Does that mean we should be using libvirt in virtual-mobile-builder by default and generate a libvirt command-line? [17:34] * lool needs to run out for a while [17:34] lool: thanks for the info and the support, I'm trying to get an exiting new point of sales system built for my caffe (all FOSS, of course) and Remix looks like it might be perfect for the 800*600 touchscreens [17:34] lool: I'm not sure. I read that too, but am not awake enough to test much (having gotten up from a nap, and planning to sleep again in 85 minutes precludes coffee). [17:36] djp: If you're looking at it from a PoS perspective, you'll have a bit of customisation to do anyway. I'd recommend starting with matchbox, and seeing how much you want from the remix, from Ubuntu Mobile, and from other sources. [17:36] lool: s/exiting/exciting [17:37] persia: interesting.. matchbox, eh ? [17:37] the PoS app in question is a java/swing thing [17:37] guess that wouldn't precluse matchbox [17:37] s/precluse/preclude [17:38] but I don't see it as a pure appliance, as there are several other apps usefull from the register [17:41] djp: Sure. It's a matter of what you want to install. Matchbox is just a window manager. [17:41] I've only limited experience working with PoS installations, but I suspect that except for the touchscreen interface, most of the use cases are quite different. [17:42] There's no reason you can't have a panel of some sort, perhaps with launchers for your kiosk tasks, etc. (but this gets quite off topic) [18:00] bspencer, hey, what is the issue with having shared use of xulrunner between browser and home plugin? [18:05] persia: I guess the page you sent me encourages moving to libvirt which will just do its things; I was happy to start vms with ./kvm-wrapper though; I also would like to keep network manager working on my ubuntu boxes, but I guess this conflicts with using bridges etc. [18:05] vmwares manages to do it [18:06] lool: Yeah, well, it's a matter of software maturity. You can still configure the bridged networking without libvert. I'll dig you up another page. [18:10] Basically no perfect solution on http://kvm.qumranet.com/kvmwiki/Networking [18:10] There's vde [18:22] lool: Are you on wireless? [18:23] persia: On the laptop, yes [18:23] On the desktop, no; would still prefer keeping NM though [18:23] lool: For the desktop, 3. public bridge from that page ought work, although it requires a bit of fiddling. [18:23] The slirpvde thing allows to do basically the same thing tahn kvm hmm [18:24] persia: Yeah, I'm used to such fiddling, but I know it's pretty much incompatible with NM then :-/ [18:24] For the laptop, you can create a fake eth0:1, and assign it some IP address, and use that (avahi-autoipd will do that for you: it's a bug for most people, but might be a feature for you) [18:24] It looks like we don't have a transparent solution like vmware's in opensource [18:25] Well, that's largely because we don't preload everything on the host. [18:25] persia: Hmm you can use an alias in place of a tap?! [18:25] vmware installs a mess of special interfaces on the host [18:25] The kernel drivers behave differently [18:25] Well, yes, but there are ways around that. [18:26] For example the bridge will simply, well, be a bridge, but leave the IP address and all to your phys intf [18:26] If we by default created 10 extra interfaces on the host for use by KVM, it would be easy. [18:26] and the nat doesn't rely on iptables AFAIK [18:26] You don't use the alias in place of the tap, just in the brctl line. [18:26] Well you still wouldn't get NM support if you had a bridge [18:27] brctl doesn't check link status, so as long as you can route, it works, and the kernel will shortcut rather than sending over the interface for localhost. [18:27] Uh you're really adding an alias interface to a bridge [18:27] It doesn't check it, it enforces it :) [18:27] What? You don't get nm support on the bridged interface, but that may not matter (hence using an alias) [18:27] Not link status, but interface up/down-ess for sure [18:28] Right, it only verifies the interface is up. You don't need to connect a cable. [18:28] It will bring the interface up if it's taken up and vice-versa [18:28] This is frustrating for many people because they want behaviour to be controlled by link status, rather than interface status, but in your use case it's convenient. [18:28] Bridges are cool when they work, but so ugly most of the time :-/ [18:29] Well, I guess. I think they are always ugly, and prefer to have internal routing on virtual interfaces, but that's even messier to configure. [18:29] (as you need an internal router, etc.) [18:32] Oh well, I guess I'll go the full blown way, use libvirt, create a tap each time I start a VM, and route and NAT them === asac_ is now known as asac [18:41] lool: That's ideal, but annoying to set up. [18:42] Definitely :-( === mawhalen_ is now known as mawhalen [19:32] davidm: ping - I'm looking at RC3, and the psb driver versions are all over the place. [19:34] dri modules are 0016, xorg module is 0014, kernel module is 0010. [21:22] davidm: ping - I'm looking at RC3, and the psb driver versions are all over the place. [21:22] dri modules are 0016, xorg module is 0014, kernel module is 0010. [21:22] what happened? [21:25] It is not any different then RC-2 [21:26] Unfortunately, RC2 slipped in under the radar. I didn't know about it or RC3 until this morning's meeting. [21:26] But RC1 had all 0014 builds of the psb driver set. That's why my concern. [21:48] GrueMaster, the next kernel update release will have the latest drivers, we had to go out this way to get into the hardy upgrade tree which is a huge win long term for updates and upgrades. [21:49] Unless you find some critical issue we are going to go final on this and go with the upgrade later, as I told Don last night. [21:49] As far as I am concerned it's a release. [22:42] amitk: I'm downloading the -19 kernel now. Do you know what version of the psb kernel module is in this? [23:31] GrueMaster: 0016 [23:32] I see that now, thanks. Looks ok so far. I sent you an email.