[08:45] <dholbach> good morning
[08:45] <jussi01> dholbach: morning Daniel!
[08:46] <dholbach> hey jussi01
[12:54] <dholbach> MOTU Q&A session in 6 minutes in #ubuntu-classroom
[13:28] <agoliveira> amitk: Where can I find the .config kernel file for lpia?
[13:28] <agoliveira> amitk: Duh... forget it :)
[13:29] <amitk> agoliveira: assuming you have the git repo, go to debian/binary-custom ^W^W^W
[13:29] <agoliveira> amitk: Ooops... maybe I got wrong. No, I don't get it.
[13:30] <agoliveira> amitk: Can you just send it to me?
[13:30] <amitk> agoliveira: debian/binary-custom.d/lpia/patchset
[13:30] <amitk> agoliveira: actually debian/binary-custom.d/lpia/config.lpia
[13:32] <agoliveira> amitk: Ok, let me explain my idea: I want to create a monolithic kernel for my Q1 for testing. I suposed I could do that using the stock kernel but looks like I can't?
[13:32] <amitk> agoliveira: you want to change all modules to built-ins, right?
[13:33] <agoliveira> Yes
[13:34] <amitk> agoliveira: edit debian/binary-custom.d/lpiacompat/config.lpia; s/=m/=y/; fakeroot debian/rules custom-binary-lpiacompat
[13:35] <agoliveira> amitk: I have to leave now for an appointment. Are you going to be here in 1 hour +-?
[13:35] <amitk> agoliveira: be warned that the kernel binary will be huge
[13:35] <amitk> agoliveira: yes
[13:35] <agoliveira> amitk: I just want to test the loading time versus the current one. I'll talk to you when I return. Thanks.
[14:49] <agoliveira> amitk: Can we return to that chat about the kernel?
[16:16] <amitk> agoliveira: sure
[16:17] <agoliveira> amitk: Fine. Ok, I've tried the old .config method but looks like I was superseeded :) Can you explain to me how to obtail the kernel I want? I have to pull from the git tree?
[16:18] <amitk> agoliveira: start by pulling the git tree
[16:18] <agoliveira> amitk: I've never done it before. A hint would be great...
[16:19] <amitk> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-hardy.git
[16:19] <amitk> agoliveira: replace with hardy with gutsy if that is your target
[16:19] <agoliveira> amitk: Right now it is.
[16:20] <agoliveira> Hmmm.... this is going to take a while...
[16:20] <amitk> agoliveira: once that is done (it will take a while depending on your connection speed), edit debian/binary-custom.d/lpiacompat/config.lpia; s/=m/=y/; fakeroot debian/rules custom-binary-lpiacompat
[16:20] <agoliveira> amitk: and that's it?
[16:21] <amitk> agoliveira: in theory, yes :)
[16:21] <agoliveira> amitk: Will it produce a .deb of just the binaries?
[16:22] <agoliveira> Indexing 511590 objects... ouch...
[16:23] <amitk> agoliveira: yes.. it will create a .deb for linux-image in the parent directory
[16:23] <agoliveira> amitk: Great, thanks.
[17:06] <agoliveira> amitk: fakeroot debian/rules custom-binary-lpiacompat
[17:06] <agoliveira> No rules to process target: `custom-binary-lpiacompat'.
[17:57] <amitk> agoliveira: I forgot to mention that you need to run the last command inside a lpia chroot
[17:57] <amitk> you could use the chroot created by MIC
[17:58] <agoliveira> amitk: Won't make-kpkg do the same trick if I change .config directly.
[17:59] <amitk> agoliveira: yes, but you will still need the chroot. And we don't support that method of creating .debs
[18:00] <agoliveira> amitk: FIne, thanks.
[18:01] <davidm> robr, robr2 bspencer, rustyl, rustyl_  are we having the USB continuing meeting now?  Or were people not available?
[18:01] <bspencer> I'm here and available.
[18:02] <bspencer> davidm, you are right that we said today for a follow up mtg.
[18:02] <rustyl_> i'm here
[18:02] <davidm> I did not see an announcement but thought I'd ask, are the folks in china here?
[18:02] <rustyl_> alek_desktop, you online?
[18:03] <bspencer> I didn't ask him to come.  It's pretty late there.
[18:04] <davidm> If folks are not here we can reschedule but I do want to make sure we have this meeting soonish, 
[18:04] <rustyl_> it's 2am in PRC
[18:04] <bspencer> davidm, we could discuss what open issues there are
[18:04] <davidm> We are in next week and then gone for the holiday.
[18:04] <bspencer> davidm, same around here
[18:05] <bspencer> what was the goal of this meeting?
[18:05] <rustyl_> IIRC, we had to cut off a few discussions 
[18:05] <davidm> I have a feeling that with no announcment lool and others also did not come
[18:05] <bspencer> Intel is planning to implement a Fat32 USB client solution as a point of reference.
[18:06] <bspencer> Other technologies can be investigated in parallel
[18:06] <rustyl_> yeap, but it sounds like the long term solution might be a PTP/MTP solution
[18:06] <davidm> But yes, as rustyl_ said a few discussions were cut off and more conversation was desireds on both sides in the last meeting.
[18:06] <smagoun> davidm: lool said he couldn't make a mtg at this time
[18:07] <bspencer> is there a Canonical or community member who is able to help in this investigation?  (e.g. do some proof of concept work around PTP/MTP and make a recommendation)  
[18:07] <davidm> So I think the goal was to figure out if there was something better longer term since the vfat is not a very good answer especially on devices that have limited space.
[18:07]  * lool is closing the computer and waves good week end
[18:08] <davidm> bspencer, I don't know but if we open the conversation up we might get some takers.
[18:08] <smagoun> I'm not convinced that MTP will let users get, say, saved PDF documents off the device. That is a requirement.
[18:08] <smagoun> Anyone willing to convince me?
[18:08] <rustyl_> i still need to read more about the protocol
[18:08] <davidm> Again, I'm just doing the pm job here, making sure to have the right people at the meeting.
[18:08] <bspencer> googling...
[18:09] <rustyl_> is it really just media file specific?
[18:09] <smagoun> rustyl_: I don't know, but that is my concern.
[18:09] <rustyl_> I think we have a potential to share various types of application data
[18:10] <rustyl_> it's just that today we know about videos/photos/music/pdf etc
[18:10] <rustyl_> if mta is really just transfering files, then it seems like we could make it work
[18:11] <rustyl_> what was that URL for the protocol?
[18:11] <bspencer> interesting:  Most MTP-compatible devices do not appear through drive letter assignment in Windows Explorer, instead they will appear as "devices" in Windows Explorer. 
[18:11] <rustyl_> http://en.wikipedia.org/wiki/Media_Transfer_Protocol
[18:11] <bspencer> right
[18:13] <lool> libmtp has a list of devices for which "file transfer" is support; I guess this means one can transfer files
[18:13] <lool> smagoun: ^
[18:13] <davidm> rustyl, I noticed that with a camera I plugged into my Linux desktop, some of my software saw it and enabled me to download stuff from the camera but it was not shown on the desktop like HD appear.
[18:14] <bspencer> lool, howdy.  ... just couldn't shut the laptop lid?
[18:14] <rustyl_> if we can transfer any type of file, then we can most likely shoehorn a solution out of this
[18:15] <rustyl_> the bigest open is around the client side, not the host side
[18:15] <lool> bspencer: It's my desktop, I can't close any lid; I'll simply throw away the lcd at the bottom
[18:15] <davidm> It seems to have a misc file type and you can extend the types also.
[18:16] <rustyl_> with any luck, we can write a user space USB driver for the client side to implement the protocol
[18:16] <agoliveira> Just jumping in to remind you that there's a wiki page with the last meeting's topics and data.
[18:17] <smagoun> "Additional confusion is created by the fact that Windows Explorer treats MTP devices somewhat like a file system, except without an assigned drive letter, making it impossible for other applications to access the data directly" (from Wikipedia)
[18:17] <smagoun> That sounds....limiting
[18:17] <lool> http://www.wentnet.com/projects/xnjb/screenshots/data-tab.png <- referenced from mtp website
[18:19] <rustyl_> smagoun, why does that sound limiting?  if you have enough information/control to expose a filesystem interface on the host side, then it seems like we would have everything we need.  or... am i missing a big concept?
[18:19] <davidm> https://wiki.ubuntu.com/MobileAndEmbedded/UsbClientMeeting
[18:19] <davidm> http://kryten.incognitus.net/mootbot/meetings/ubuntu-mobile.20071211_1702.html
[18:19] <davidm> For reference purposes the URL's above from last meeting
[18:20] <smagoun> rustyl_: With MTP there *isn't* a filesystem on the host side. Right?
[18:21] <rustyl_> smagoun, yea, it was my understanding that windows was just creating a virtual filesystem interface out of the information available via MTP
[18:21] <rustyl_> so users could still have their familiar folder/file exploring interface
[18:22] <smagoun> rustyl_: I think that's only accessible via Windows Explorer though - the Wikipedia article implies that an arbitrary app like Word can't see the contents of the MTP-enabled device.
[18:22] <rustyl_> makes sense
[18:23] <smagoun> There are workarounds to that problem, to be sure (drag stuff to the HD before opening). Workarounds aren't always obvious to users though.
[18:23] <rustyl_> yea, if MS did a good job, then any applications would see the filesystem interface.  I see your point
[18:24] <rustyl_> just like all linux apps can see sysfs mounted on /sys
[18:24] <rustyl_> and not just some gnome file explorer application
[18:24] <smagoun> exactly
[18:25] <smagoun> (of course, what human user knows to look in /sys for anything :)
[18:25] <rustyl_> i was just seeing it as a plus that if anyone could make this thing look like a filesystem, then we could pretty much implement all the use cases of shared application data that we currently know about
[18:25] <smagoun> I agree 100%, that would make things much easier for everyone
[18:26] <rustyl_> so we have all these potential paths to walk down, and on the Intel side a couple of guys are wondering down the path of a simple vfat mount
[18:27] <rustyl_> but we need to explore some other paths with limited resources
[18:27] <bspencer> fat32 first, ptp next.  Given the resources.  Probably start looking in Feb/March at PTP if I were to guess.
[18:27] <rustyl_> it looks to me like mtp is the best path to explore 
[18:28] <rustyl_> it might very well lead to a tar pit, but it seem promising enough from my viewpoint
[18:28] <smagoun> It'll be a good 80% solution
[18:28] <rustyl_> how do others feel... are we being unfair about the difficulties in a samba mount type solution?
[18:29] <smagoun> (mtp/ptp that is)
[18:29] <rustyl_> for mtp/ptp, we really need to understand how the implementation would work
[18:30] <rustyl_> for example, do we need to have coordination for access to the shared files?
[18:30] <rustyl_> do we have the same potential corruption issues that the mass-storage path leads us too?
[18:30] <davidm> bspencer, if the vfat was a translation layer on ext3 or something that would be OK but splitting a small file system into smaller chunks not so good.
[18:31] <rustyl_> in order to make the mass-storage solution share access to the data, i am guessing that we really need a user space usb driver
[18:31] <bspencer> davidm, yes.  any idea how to create a translation layer?  
[18:32] <rustyl_> i say that because the access needs to happen from the top of the virtual filesystem
[18:32] <davidm> Me,  no I'm not a filesystem guy but there are emulators out there that do it.
[18:32] <rustyl_> for host usb, you can do amazing things in a user space driver
[18:33] <smagoun> bspencer: I think you create a USB mass storage driver that exposes itself as a FAT block device, and has a translator that reads/writes to the underlying FS.
[18:33] <rustyl_> i'm just not positive if we have those same options for client stuff
[18:33] <rustyl_> smagoun, and if that driver was in user space then it would be a hell of a lot easier
[18:33] <rustyl_> we could at least lock the file
[18:34] <smagoun> rustyl_: I believe it can be 100% userspace
[18:34] <rustyl_> hmm... who is THE guy/gal for usb client stuff?  for all linux?  who should we be talking with?
[18:34] <davidm> in the Linux community?
[18:35] <davidm> or Intel?
[18:35] <rustyl_> maybe Greg KH can give us a pointer
[18:35] <rustyl_> linux community
[18:35] <bspencer> earth
[18:35] <davidm> Yea, I'd say Greg KH is the smartest person about USB in the Linux community that I know.
[18:35] <rustyl_> in general, were is most of the brain trust on this subsystem
[18:35] <rustyl_> it's just that the client side of USB has a lot less interest
[18:37] <rustyl_> at least we are at a point where someone could start experimenting with a CB system
[18:37] <smagoun> Have the embedded guys (handhelds.org, openembedded, montavista, etc) solved this problem for us?
[18:37] <davidm> smagoun, I have no idea
[18:38] <rustyl_> not that i have seen, but sometimes these guys work in their own trees that are not found so easy from google
[18:38] <rustyl_> the problem is that truely embedded devices tend to be a lot more limited
[18:39] <rustyl_> so sharing with running apps isn't that big a deal.  Concepts like booting into a sync mode make a lot more sense
[18:39] <smagoun> The linux-usb-devel ML seems to be quite active: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[18:40] <smagoun> rustyl_: Since Intel's doing the work, do you have time to ask there?
[18:41] <smagoun> MARC archive of that list, since sf.net is miserably slow: http://marc.info/?l=linux-usb-devel&r=1&w=2
[18:41] <rustyl_> if we look into it then i don't expect to see much till after the new year
[18:42] <smagoun> right, we're pretty well booked until the new year too.
[18:43] <rustyl_> http://www.linux-usb.org/gadget/ ... there is a blurb in the "Upper Layers" section that sound promising.  It pretty much says that you can implement the upper layers of the protocol stack in user mode just like you can for the host side 
[18:44] <rustyl_> How about this... we can commit to starting some exploritory work on this in mid january
[18:45] <rustyl_> with any luck, we could have some hard data / working prototype code to present/demonstrate at the sprint in Oregon
[18:45] <davidm> That would be great rustyl_
[18:46] <davidm> Would solve issues for smagoun's team and mine.
[18:46] <smagoun> rustyl_: that would be great
[18:46] <rustyl_> bspencer, thoughts? I was thinking having alek_desktop own this.  You think this would kill something else?
[18:46] <bspencer> nothing I'm doing :)
[18:46] <rustyl_> rob__, rob ... you listening to this?
[18:47] <bspencer> frank could assist if needed a little
[18:47] <rustyl_> yea, lets go with this
[18:47] <rustyl_> bspencer, and myself can chat off-line with alek_desktop 
[18:47] <davidm> rustyl_, do you have your logging on?  If not I can capture the screen and mail it to you if you like.
[18:47] <rustyl_> and expect some related chat on this channel from time to time
[18:48] <rustyl_> no, i don't have logging on.  I guess we forgot to startup the meeting bot
[18:48] <bspencer> #startmeeting
[18:48] <MootBot> Meeting started at 18:48. The chair is bspencer.
[18:48] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:48] <bspencer> [topic] Summary of USB Client discussion.  Friday Dec 14, 2007
[18:48] <MootBot> New Topic:  Summary of USB Client discussion.  Friday Dec 14, 2007 
[18:49] <bspencer> [idea] bspencer, rustyl, alek to investigate USB client strategies including MTP and ext->vfat translation
[18:49] <MootBot> IDEA received:  bspencer, rustyl, alek to investigate USB client strategies including MTP and ext->vfat translation 
[18:49] <bspencer> http://www.linux-usb.org/gadget/
[18:49] <MootBot> LINK received:  http://www.linux-usb.org/gadget/ 
[18:49] <bspencer>  http://marc.info/?l=linux-usb-devel&r=1&w=2
[18:50] <bspencer>  http://marc.info/?l=linux-usb-devel&r=1&w=2
[18:50] <bspencer> oopes
[18:50] <bspencer> http://www.wentnet.com/projects/xnjb/screenshots/data-tab.png
[18:50] <MootBot> LINK received:  http://www.wentnet.com/projects/xnjb/screenshots/data-tab.png 
[18:50] <bspencer> http://en.wikipedia.org/wiki/Media_Transfer_Protocol
[18:50] <MootBot> LINK received:  http://en.wikipedia.org/wiki/Media_Transfer_Protocol 
[18:50] <bspencer> .
[18:51] <bspencer> ok.  so end meeting now?
[18:51] <smagoun> There is a vfat translation layer in block-vvfat.c, which is included in the qemu emulator: http://fabrice.bellard.free.fr/qemu/
[18:51] <bspencer> http://fabrice.bellard.free.fr/qemu/
[18:51] <MootBot> LINK received:  http://fabrice.bellard.free.fr/qemu/ 
[18:51] <bspencer> [idea] There is a vfat translation layer in block-vvfat.c, which is included in the qemu emulator: http://fabrice.bellard.free.fr/qemu/
[18:51] <MootBot> IDEA received:  There is a vfat translation layer in block-vvfat.c, which is included in the qemu emulator: http://fabrice.bellard.free.fr/qemu/ 
[18:51] <bspencer> .
[18:51] <bspencer> good discussion.  Thakns guys
[18:52] <davidm> bspencer, don't forget to #endmeeting
[18:52] <bspencer> #endmeeting
[18:52] <MootBot> Meeting finished at 18:52.
[18:53] <davidm> I'll send you the URL to the log
[18:53] <bspencer> k
[18:54] <davidm> Sent 
[21:50] <ToddBrandt> asac: you online?
[21:51] <asac> yeah
[21:51]  * asac is the hero who works in his holidays 
[21:51] <ToddBrandt> asac: do you have any idea how to get rid of the white background that shows up for the nm-applet in hilson desktop?
[21:51]  * ToddBrandt commends asac
[21:52] <ToddBrandt> raji here is working on it and has come up with some potential solutions and I've seen similar things with the brightness and volume applets
[21:52] <ToddBrandt> but I was hoping you may have some insight
[21:52] <ToddBrandt> The volume and brightness applets were pulled from gnome-media and gnome-power-manager respectively
[21:53] <ToddBrandt> both used libbonobo and their objects were based on the PanelApplet class
[21:53] <asac> ToddBrandt: you mean the icon in the tray?
[21:53] <ToddBrandt> asac: yea
[21:53] <ToddBrandt> both initially shows up with white backgrounds
[21:53] <asac> maybe its not transparent?
[21:53] <asac> (the image itseflf(=
[21:53] <ToddBrandt> hmm
[21:53] <asac> oops
[21:54] <asac> hmm i doubt it is ... there is no white background here on gnome panel
[21:54] <ToddBrandt> good point, I don't think I've specificaly looked at the nm-applet images, however the brightness and volume ones were and produced the same behavior
[21:54] <asac> how did you fix them?
[21:55] <ToddBrandt> asac: I checked, they're transparent
[21:55] <asac> changing the background color of the gnome panel to purple shows that there is no issue with the icons in general
[21:55] <asac> so it must be something with your tray implementation
[21:55] <ToddBrandt> asac: I fixed then by removing the PanelApplet as a parent and replacing it with GtkButton
[21:56] <ToddBrandt> I think the hildon-desktop uses some of the GtkButton member fields or functions
[21:57] <asac> which part of hildon implements the tray? the marquee?
[21:57] <ToddBrandt> Raji basically did the same thing, and it's working somewhat (she's not finished yet), but the process if much harder with nm-applet because not only does it use a whole different line of GtkObjects, it even invents a new one: EggTrayIcon
[21:58] <ToddBrandt> hildon-desktop, that's where the marquee and status bar are created and populated with libraries
[21:58] <ToddBrandt> I've looked at the source and it seems interested in recieving a GtkButton object from any of the plugins it pulls in
[21:59] <ToddBrandt> and the images have to be contained in the GtkButton object, using gtk_container_add
[21:59] <ToddBrandt> brb, need caffiene
[22:06] <ToddBrandt> asac: does any of that make sense? I think nm-applet is !@$# awesome but it just has this one tiny little flaw where it doesn't play nice with Hildon Desktop (or the other way around, Hildon Desktop has a major flaw and doesn't play nice with anything other than its own stuff)
[22:06] <ToddBrandt> I'd hate to have to carve up the code for such a small detail but it's coming to that
[22:08] <asac> ToddBrandt: yes i guess its a hildon bug
[22:08] <asac> what would it take to fix the tray for real=
[22:10] <asac> hacking the nm-applet to use a GtkButton isn't nice as well ... who knows what happens on all other desktops then :)
[22:10] <ToddBrandt> hmm, yea, I guess we're at this point where it might be smart to see how hard it would be to just get hildon-desktop to play nice
[22:10] <asac> right ... i mean in the long run you want to be able to install other apps that use the tray
[22:10] <ToddBrandt> asac: yea, that's where the wall is, either we make a configuration that leaves everything else intact, or we fork it, and the first solution is looking harder and harder
[22:10] <asac> and they should work as well
[22:10] <asac> so its good that this popped up with a default component in the UME stack
[22:11] <ToddBrandt> I suppose ;) I would have much preferred everything to magically work ;)
[22:11] <asac> ToddBrandt: why is the configuration --with-tray-in-gtk-button a problem?
[22:11] <ToddBrandt> I'm new to earth apparantly
[22:11] <asac> hehe
[22:12] <ToddBrandt> asac: it's not, but I've looked at the latest patch from Raji and it's 22k, so that's lots of stuff to switch around with a configuration option
[22:12] <ToddBrandt> she's already added a --enable-buildlib option which builds it as a library, and that works with very little modification
[22:13] <ToddBrandt> we just wanted to pack all of this into a single patch, I think we'll break them into parts for now
[22:13] <asac> a single patch for nm-applet?
[22:14] <asac> please break them up ... you have to maintain them over time after all
[22:14] <ToddBrandt> yea, I figured with both it would have been tiny still, but it's growing larger and larger
[22:14] <asac> yes, but keep issues addressed seperate so you can back them out easily
[22:15] <ToddBrandt> good call
[22:15] <asac> if you need help or want anything included in the nm-applet package of ubuntu just let me know
[22:15] <asac> as long as it doesn't break normal desktops i am fine to have them as a temporary solution here
[22:16] <ToddBrandt> ok, cool, thanks