[06:25] <dholbach> good morning
[06:25] <dholbach> you have an enthusiastic tester at your command: http://dthomasdigital.wordpress.com/2008/06/26/would-ubuntu-mid-edition-be-perfect-for-my-latitude-x1/ :)
[06:35] <persia> Hmm.  He's offline now.  Thanks for the pointer: I'll try to poke him when he comes around next.
[12:05] <jpt9> hey.
[12:05] <jpt9> just heard about the version of Ubuntu for MIDs.
[12:06] <jpt9> I'm running Windows (I know... I've been meaning to install Ubuntu for a while); is there anything (a CD or hard drive image) I could run in Qemu to try it?
[13:55] <lool> Hmm I thought grew a rebase command, but I can't find it
[14:00] <lool> +bzr
[14:00]  * lool needs obviously more coffee
[15:38] <seeitcoming_> what's the default user on the ume kvm image called?
[15:43] <fedefede> hi guys!!
[15:43] <persia> seeitcoming_: ume
[15:44] <fedefede> may i ask somethingabout ubuntu ubuntu-ume??
[15:44] <fedefede> is it possible to use ubuntu MID distro on asus eee pc 701??
[15:44] <persia> fedefede: You can certainly ask questions about Ubuntu on Mobile and Embedded devices.
[15:44] <seeitcoming_> persia: and the password?
[15:45] <persia> seeitcoming_: I think it's "ubuntu".
[15:45] <persia> I might have those backwards.
[15:45] <seeitcoming_> no, those are right. Could that possibly go on a wiki somewhere? :D
[15:45] <persia> fedefede: You can try installing it.  I haven't heard of any successful tests on that device.  It might need an Ubuntu Deskop kernel.
[15:46] <persia> seeitcoming_: Sure.  Please feel free to add it.
[15:46] <fedefede> uh...right!!
[15:46] <fedefede> tanks verymuch!!!
[15:46] <fedefede> bye bye!!!!
[16:58] <davidm> Good day all, almost time for the MID meeting
[16:59] <lool> Yup
[17:00] <davidm> #startmeeting
[17:00] <MootBot> Meeting started at 11:00. The chair is davidm.
[17:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:00] <davidm> Hi everyone, the meeting has started, the agenda is on https://wiki.ubuntu.com/MobileAndEmbedded/Meeting/20080626
[17:00]  * GrueMaster wakes up for the meeting
[17:00] <davidm> and it's quite empty at the moment
[17:01] <davidm> I missed last weeks meeting and I don't have access to the mootbot logs as yet 
[17:01] <davidm> I don't think there were any actions from last week however.
[17:02] <davidm> Does anyone have any topics for this week?  The agenda is still empty.
[17:03] <lool> Nope
[17:03] <lool> We didn't have particular actions for today
[17:03] <lool> Last weeks' meetings were relatively quiet as well
[17:03] <lool> We discussed virtual machines and release
[17:04] <davidm> Yes, they have been quiet for almost a month now.
[17:04] <cgregan> In light of the breakage in the updates...should we discuss best practices for pushing things to archive? 
[17:04] <GrueMaster> Question:  Status of S3/S4 issues?
[17:05] <davidm> [topic] discuss best practices for pushing things to archive
[17:05] <MootBot> New Topic:  discuss best practices for pushing things to archive 
[17:05] <davidm> lool, can you address this as we see it now?
[17:05] <persia> o/
[17:06] <davidm> hi persia you are up late
[17:06] <lool> Yes
[17:06] <persia> It's Thursday.  I like the meeting.
[17:07] <lool> What we have it the UME release archive, archive.mobile.ubuntu.com
[17:07] <lool> the ubuntu-mobile ppa
[17:07] <lool> and the hardy repositories (hardy, hardy-updates, hardy-security, hardy-proposed)
[17:07] <lool> The hardy suite wont ever change, since hardy is released
[17:08] <lool> updates will go either via security if they are security issues
[17:08] <lool> Or via proposed then promoted to hardy-updates for SRUs
[17:08] <lool> Concerning UME, we use the ppa for all packages which differ from the hardy version
[17:08] <lool> So if we ever forked a package for UME in our ppa, this is where it needs to be fixed
[17:09] <lool> So if a SRU comes out for say xulruner-1.9 which is in the ppa, we have to prepare a new xulrunner-1.9 in the ppa, test it, and then promote it to the UME release archive
[17:09] <lool> However for the kernel for instance, we just copy hardy-updates / hardy-security sources and binaries to the UME release archive
[17:10] <lool> We can also prepare additional changes for UME/hardy, but I'd recommend focusing on intrepid now
[17:10] <lool> Is any part of the above unclear?  a particular area where I should tell more?
[17:11] <persia> It might be worth a quick overview of best practices to get updates into intrepid.
[17:11] <cwng> Will current bug fixes for UME still goes into the hardy base UME, or will it only goes to Interpid based UME?
[17:11] <davidm> I agree our focus is on Intrepid.  For any changes to UM&E/MID we must follow Hardy process even if it touches our PPA
[17:12] <persia> cwng: The bugs would have to meet the requirements for a Stable Release Update.
[17:12] <persia> https://wiki.ubuntu.com/StableReleaseUpdates
[17:12] <davidm> thanks persia I was looking for that URL:
[17:12] <lool> As persia indicated, anything which isn't forked in UME can follow the regular SRU process, and we apply basically the same type of QA checks for UME specific packages
[17:13] <davidm> [link] https://wiki.ubuntu.com/StableReleaseUpdates
[17:13] <MootBot> LINK received:  https://wiki.ubuntu.com/StableReleaseUpdates 
[17:13] <lool> Concerning intrepid versus hardy, it depends on the impact of the bug
[17:13] <lool> Typically, high impact bugs are likely to warrant a hardy upload while low impact one aren't
[17:13] <lool> Always fix bugs in intrepid first though
[17:13] <lool> This is in most cases a requirement to accept SRUs
[17:14] <GrueMaster> So, is there an intrepid base for MIC and UME yet?
[17:15] <lool> No
[17:15] <lool> At the moment, StevenK has modified livecd-rootfs to build images of UME
[17:15] <lool> This tool is the one which builds the squashfs images for the main Ubuntu builds
[17:16] <lool> This work is to the point where he can boot UME/hardy from a live USB stick
[17:16] <lool> But there's no installer
[17:17] <lool> Discussion in the coming weeks will revolve around such an installer and integration of livecd-rootfs builds with the current Ubuntu builds
[17:17] <lool> StevenK will also look on building intrepid images soon I hope
[17:18] <davidm> I expect we will start daily builds soonish, once we resolve the installer
[17:18] <davidm> Is there more on this topic?
[17:18] <lool> I think we can even start them without an installer   ;-)
[17:19] <davidm> lool, I suppose could at that, they do work.
[17:19] <davidm> :-)
[17:19] <persia> The current builds work for a live environment, for basic testing.
[17:19] <lool> I also wish we start building KVm images of intrepid
[17:20] <lool> The seed cleanups I made this afternoon will help in this respect I would guess
[17:20] <davidm> lool, I think so, 
[17:20] <davidm> so moving on to the next topic
[17:20] <davidm> [topic] <GrueMaster> Question: Status of S3/S4 issues? 
[17:20] <MootBot> New Topic:  <GrueMaster> Question: Status of S3/S4 issues?  
[17:21] <davidm> DebbieFoghorn, do you have any input on this?
[17:21] <lool> Concerning the beeps, she discovered some of them were caused by a bogus pm-utils script IIRC
[17:21] <lool> I think an empty or almost empty script dealing with 3G status or something was returning with an exit code which caused gpm to beep to reflect a failure
[17:22] <lool> The script was removed
[17:22] <davidm> Yes, I've seen some traffic on the bug list about this.
[17:23] <davidm> ChickenCutlass, bfiller is DebbieFoghorn in the office right now?
[17:23] <bfiller> davidm: I think so, but I'm not :)
[17:23] <DebbieFoghorn> davidm: I am! Reading IRC now
[17:24] <davidm> bfiller, thanks Hi DebbieFoghorn 
[17:24] <davidm> DebbieFoghorn, the question is around S3-S4 status and I knowi you have been doing a lot in that area
[17:25] <DebbieFoghorn> Basically, gnome-power-manager is very sensitive to any errors it receives when it tries to put the device in suspend
[17:25] <DebbieFoghorn> We call our own sleep script rather than call pm-suspend
[17:25] <DebbieFoghorn> If any non-zero status is returned or anything is written to stderr, then
[17:26] <DebbieFoghorn> hal (which calls our sleep script for us) will return an error and gpm will beep and fail to resume properly
[17:27] <ogra> if its only the beeps, these are all switchable through gconf keys ...
[17:27] <jerryfan> hello debbie. regarding the beep issue, after clean up in sleep.d, we found no more so far. Doing more intensive testing tmr
[17:27] <ogra> so you can disable them 
[17:27] <DebbieFoghorn> ogra: I did not see a gconf key that disables the sound
[17:27] <ogra> look for "alerts" 
[17:28] <DebbieFoghorn> ogra: ok, will do
[17:28] <ogra> hum, i wanted to point you to the path but dont seem to find them now :(
[17:29] <DebbieFoghorn> ogra: though its not just the beep--gpm seems to follow a different code path when it detects an error and results in an improper resume (screen remains black)
[17:29] <ogra> ah, there is /apps/gnome-power-manager/ui/enable_sound
[17:29] <lool> /apps/gnome-power-manager/notify/sleep_failed?
[17:29] <DebbieFoghorn> ogra: Note that in the code, I do not see it checking a gconf key before playing the suspend error sound...
[17:29] <ogra> lool, yeah, these ... there are more in the notify path
[17:29] <jerryfan> but there is new problem. We found on some sample, 3G and webcam are registered on different usb bus number. So S20powermanager for selective suspend will generate error to stderr again and S3 fails again
[17:30] <ogra> DebbieFoghorn, yeah, and it would just hide the actual prob ... 
[17:30] <ogra> you said you suspend through hal, dont you use pm-suspend/-hibernate ? 
[17:30] <ogra> they should wrap around the hal calls and apply quirks etc 
[17:30] <DebbieFoghorn> ogra: we do suspend through hal but we changed the hal code to call our own sleep script rather than pm-suspend
[17:31] <ogra> ah
[17:31] <jerryfan> Who knows how kernel deals with USB host ? Why on some JAX10 sample 3G is on USB 4-1 and some are on USB 3-1??
[17:31] <DebbieFoghorn> jerryfan: you had a question about the web cam's device path changing
[17:31] <DebbieFoghorn> jerryfan: you just beat me :)
[17:32] <DebbieFoghorn> jerryfan: i don't know the answer, by the way :(
[17:33] <lool> is that important?
[17:33] <jerryfan> I think it is not dev path change becasue /dev/ path is still same. It is /sys/bus/usb/ path different
[17:33]  * ogra wondered the same ... all you want from a cam is /dev/video, no ? 
[17:34] <lool> If you ever search for a USB device, I guess you could locate it by device class, vendor id or whatever?
[17:34] <ogra> yes, and rather use lsusb output and parse that 
[17:34] <ogra> or if you want a lower layer to see HW, dmidecode ...
[17:35] <jerryfan> nah.. In /etc/pm/sleep.d/ we put usb selective suspend on absolute sysfs path to echo selective suspend enabled msg to device. Since the sysfs path is different, we have problem to send selective suspend now
[17:35] <lool> Perhaps you can reach the same device over a different static sysfs path
[17:35] <lool> Or look at all sysfs devices until you find the one you want to special case
[17:36] <ogra> jerryfan, that shouldnt o to /etc/pm btw thats for local admins ... for packages use /usr/lib/pm-utils/
[17:36] <jerryfan> in addition, there is no web cam on USB 1-4, so sleep.d will make error msg and makes g-m-p suspend fail and beep beep
[17:36] <lool> Well that's all a consequence of looking to shutdown USB 1-4 insteadof looking up where the webcam is and shutting it down ;)
[17:37] <jerryfan> lool, yea we are trying to lookup /dev/video0 and /dev/video1 and traceback their sysfs path. Hope it will solve the problem
[17:38] <ogra> lshal can be helpful here
[17:38] <ogra> just look for the module ;)
[17:38] <ogra> if you knoe the 
[17:38] <ogra> name indeed
[17:38] <jerryfan> ogra, thx. will try
[17:39] <GrueMaster> So, if I understand all this correctly, the problem is that the scripts are hardwired for a single system, as opposed to being more generic?  That would explain why it fails on CB.
[17:39] <ogra> you might also be able to query hal with a dbus message to give you all info ...
[17:39] <persia> GrueMaster: Precisely
[17:39] <ogra> right
[17:40] <jerryfan> ogra, what did u mean " for package should use /usr/lib/pm-utils" ?
[17:41] <ogra> jerryfan, if you do it from the distro dont use /etc/pm ... look in /usr/lib/pm-utils, it has the same structure ... 
[17:42] <jerryfan> ogra, i see. 
[17:42] <ogra> the etc place is reserved if people poke around or start working around bugs for their local scripts
[17:42] <ogra> (i must admit i use /etc/pm myself on the classmate, ignoring that ... but knowing its unclean :) )
[17:45] <jerryfan> hey, did u guys know that I made linpus lite booting into 10 seconds :)
[17:45] <davidm> OK is there more on this topic right now?
[17:45] <ogra> jerryfan, well, i have still 10 to shove off, but getting there http://people.ubuntu.com/~ogra/hardy-20080623-5.png
[17:46] <davidm> Are there any other topics?  The wiki page has nothing else.
[17:46] <GrueMaster> I'm good for now.
[17:47] <davidm> OK, then if there is no other business ending the meeting going once .............................................
[17:47] <jerryfan> i just have a request here. Can someone find out how kerenl deals with USB bus number.
[17:47] <jerryfan> I afraid we have more things not generic enough and might fail soemthing
[17:48] <davidm> We can ask Amitk once he is back (I think he is on holiday)
[17:48] <ogra> i think thats rather udev than kernel
[17:48] <davidm> ogra, it might be, I'm not sure.
[17:48] <ogra> but not 100% sure
[17:48] <jerryfan> but udev deals with /dev path
[17:48] <lool> I would have thought it's kernel
[17:48] <jerryfan> sysfs is populated directly from kerenl
[17:49] <ogra> ah, right
[17:49] <davidm> I'll take the action to poke Amitk about it.
[17:49] <ogra> indeed
[17:49] <jerryfan> no more question
[17:49] <davidm> [action] davidm to poke amitk about how kernel populates sysfs relating to USB bus number
[17:49] <MootBot> ACTION received:  davidm to poke amitk about how kernel populates sysfs relating to USB bus number 
[17:50] <davidm> OK anything else?
[17:51] <lool> davidm: Thanks for chairing the meeting
[17:51] <davidm>  ending the meeting going twice ...................................
[17:51] <davidm> lool, it's nice to have been free this time....
[17:52] <lool> and bon appétit to you if you're getting lunch
[17:52]  * ogra would like to anounce that he was officially told to help filing the gap for netbooks on the distro/mobile team side ... fo feel free to poke me with issues :)
[17:52]  * lool will get dinner now
[17:52] <davidm> #endmeeting
[17:52] <MootBot> Meeting finished at 11:52.
[17:52] <ogra> s/fo/so/
[17:52] <lool> ogra: Fix my bugs!
[17:52] <davidm> lool, I am indeed heading for some food
[17:52] <ogra> lool, doing already :P