=== Sweetsha1k is now known as Sweetshark === figarocorso is now known as miky_jr === figarocorso is now known as miky_jr === yofel_ is now known as yofel === zequence_ is now known as zequence === figarocorso is now known as miky_jr [13:18] hey guys. === Ursinha_ is now known as Ursinha === rsalveti_ is now known as rsalveti === chiluk_away is now known as chiluk [16:01] * ogra_ waves [16:01] ogra_, dholbach: is there a meeting today? [16:01] hey [16:02] I'm in a separate meeting right now [16:02] ogra_ announced it before, so I'd assume that yes [16:02] seb128, well, at least for a quick status run-down, yes [16:02] who is leading? [16:02] hi [16:02] is there an agenda? [16:02] nope [16:02] we could make one up for next week though [16:02] #startmeeting [16:02] Meeting started Fri Jan 25 16:02:49 2013 UTC. The chair is ogra_. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [16:02] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired [16:03] hey everyonw, this is the nexus7 status meeting [16:03] hi [16:03] i'll give a quick summary of what happened this week ... [16:03] so thanks to jani who wrote a prototype in GO, we now have auto-rotation working ! [16:03] as well as the ambient light sensor [16:04] (i took the prototype and implemented it in shell, as an interim solution) [16:04] togather with the autorotation, an xorg fix landed that makes touch input in portrait mode work [16:04] if we are to integrate with gnome-system-daemon we need changes to the kernel so we expose an input interface as that daemon expects [16:05] we may get it this cycle or we may just stick with the shell daemon, not sure yet [16:05] right, the question is if we will keep g-s-d in this form on the later tablet setup [16:05] I have been looking into it the past few days though and I'd like to get it done properly [16:05] right, the shell daemons are really just interim solutions [16:05] no idea. What is the later tablet setup - related to ubuntu phone? [16:05] g-s-d is being discussed [16:05] i found it important for testing the features to have it in asap [16:06] we want to reduce its scope for sure [16:06] so we can see how the UI reacts to rotation etc [16:06] so if it's as easy to implement those feature in other places feel free [16:06] seb128, well it is certainly easier but at the cost of extra footprint that a separate daemon brings [16:06] something we keep ignoring and that got us into this bloated mess in the first place :) [16:06] right [16:07] well, we should perhaps implement those feature in unity itself for example [16:07] well, i wouldnt mind a small daemon in C [16:07] we were supposed to have a push for reducing memory footprint this cycle, at leats not add extra stuff if we can't make it lower :) [16:07] depending on the feature though [16:07] the issue is that the higher number of process, the higher cost in context switches, wakeups, memory usage, etc [16:07] janimo, as long as the new extra stuff is smaller i dont care :) [16:08] janimo, btw, did tvoss talk to you ? [16:08] this daemon is by far not among the high footprint daemons but everything adds up [16:08] nope [16:08] he seems to work on an API for sensor stuff [16:08] nice, I'll follow up after the meeting [16:08] so if there is something in the works we could use, that might help [16:09] i pointed him to you ... hm [16:09] (days ago) [16:09] well I discovered g-s-d covers accel and screen rotation, but only with a paritcular type of accelerometer in the kernel [16:09] there's no unifying interface [16:09] right [16:09] seems better to build on that codebase [16:09] though the question is, will we stay with g-s-d at all for sensors [16:09] rather than to write a new one [16:09] also discovered by accident while poking in sysfs that my x86 laptop has an accelrometer [16:10] which also does not work with g-s-d [16:10] ogra_, no immediate plan to replace g-s-d, and we can easily move bits of code out of gsd to some other source later if needed [16:10] ok [16:10] ogra_, it's not like the work would be wasted [16:10] I would improve g-s-d as a start [16:10] seems the less work path [16:10] well sensors are not that separate from settings, it makes sense imo to have light sensor integrated in backlight settings and other screen related stuff [16:10] right, making g-s-d actually generic deinitely helps [16:11] definitely [16:11] so from what limited knowledge I have g-s-d seems the place for it - if we plan on keeping g-s-d that is [16:11] right [16:11] we do plan to keep it in the near futur [16:11] i'm just careful because i heard we might not ... but what seb128 said, it helps in general [16:11] we might move some bits out to small "on-demand" services [16:11] ++ [16:12] once upstart can handle it :) [16:12] I hope those are not written in python though [16:12] like if "rotation" can be an upstart daemon we could span the helper from an upstart script [16:12] and take it down again [16:12] yeah [16:12] thats what i do atm [16:12] upstart daemon->signal [16:12] but for the session side it uses Xsession.d [16:12] rotation does not seem like an on-deman thing though, I expect people want it on all the time with a tablet [16:12] instead of upstart ... [16:12] well, if the rotation triggers an upstart signal we can bind a script to it [16:12] janimo, in android i dont :) [16:13] that would avoid having the code running all the time to poll for the rotation event [16:13] if i read a book and lie on the side in bed i dont want it rotating all the time [16:13] * seb128 always turn off autorotate [16:13] it's more annoying than useful [16:13] seb128, well, the polling is the biggest issue atm, yeah [16:14] the daemon is like 20 lines of shell :) [16:14] wouldnt eat much if it wouldnt have to poll every second [16:14] in the current state its one of the biggest CPU consumers though [16:14] we could fix that by doing the poll in the kernel and firing off uevents when things change [16:14] can we make xorg/the kernel to send a signal? [16:14] yeah [16:14] needs some coding but can be done - not sure if it's the right place though [16:15] kernel [16:15] it might be worth dropping an email on ubuntu-devel list? [16:15] Apparently gsd reads an ID_INPUT_ACCELEROMETER_ORIENTATION property via gudev [16:15] to get input from kernel people? [16:15] seb128, but we also need to add code to interpret the raw data and keep track of orientation in the kernel then - moving the shell code to kernel C code [16:15] lool, rhight, which only very few accelerometers seem to trigger [16:16] If I understand what you folks are saying: 1) this doesn't work on N7 2) we would like to change this from poll to event-based [16:16] seems a bit crazy - but this sensor does not have an orientation even itself unless loaded with proprietary firmware which we do not have [16:16] so on 1), do we know what to do to set this property right? [16:16] lool, right, but 0.5) we only have the free part of the driver [16:16] lool, I am looking into this now. The nexus7 sensor is dumb [16:16] and 2), do we have a way to trigger something in the active session based on udev events? [16:16] and only provides raw accel data [16:16] lool, which doesnt give us 100% of the features [16:17] I think there's an udev bridge for upstart, can we use it? [16:17] lool, g-s-d listens to udev events from accel devices [16:17] right, we just need the events [16:17] so that part is covered if we make our kernel side similar to what is already handled [16:17] yeah [16:17] janimo: ah so it's not poll, it's already uevent based [16:17] so an input device with uevents, polling [16:17] lool, right. [16:18] our current driver doesnt even provide a device [16:18] so we only miss a correct kernel path for this [16:18] when the currenlty handled (asus-laptop pega I think) accel fires off an ACPI even saying rotation changed [16:18] so these bits need adding [16:18] the driver emits an uevent [16:18] a udev helper is called that reads the raw data and calculated orientation - again, as uevents cannot carry metadata [16:18] and exports that as env -var [16:18] udev property I mean [16:19] and g-s-d reads it [16:19] that sounds like a really slow process [16:19] compared to what we do atm [16:19] lool, the rewason I am not sure about the kernel part is that there is no standard kernel way of exposing accels, g-s-d uses one of the existing approaches [16:19] i wonbder if we couldnt have that with less players involved [16:20] but for instance it does not work with my acer accelerometer either, that too does things a bit differently [16:20] * xnox realises it's meeting time. [16:20] ogra_, well g-s-d as our shell script could just read raw data and handle everything, but would need to have a lot of sensor specific code [16:20] and would need to do detection [16:20] udev handles detection of device at least [16:20] and would need to poll [16:21] right, i just wonder if that cant be done more direct ... udev->xorg [16:21] so the g-s-d stuff seems ok to me, just that restrict all sensor to the input subsystem (nexus is on IIO does not even provide an input device) [16:21] and have g-s-d only intercept if the user actually switches it off [16:21] and a specific devnode with input_struct layout as a joystick (X, Y, X values) [16:22] yeah [16:22] it is doable, I'll keep at it for a few more days [16:22] well, lets not go to much into detail [16:22] we'll see what you come up with ;) [16:22] xnox, want to give an update ? [16:22] * xnox also thought that udev is ought to be generating the events from accelorometer and then g-s-d or whatever can piggy back on top. Gives us the most flexibility to consume those events. [16:23] and take into account the galaxy nexus too which has a sensor from the same family but different [16:23] same but different ... yay [16:23] I'd rather we not have to add code to every sensor if upstream decides they are all going to be IIO and not input devices [16:23] I finished usb-creator support for flashing nexus7 tablets using .img + .bootimg files. [16:23] wohooo [16:23] so maybe changing g-s-d is better long term [16:23] janimo, yeah [16:23] Currently it only "recognises" nexus7 ID_VENDOR_ID and ID_MODEL_ID [16:24] thats enough for a start [16:24] we can add a big database over time :) [16:24] so if there are other devices please send me their VENDOR_IDs / MODEL_IDs [16:24] janimo, maybe drop a summary email to ubuntu-devel@ about the rotation/g-s-d/kernel topic? might be better for discussion [16:24] xnox, nexus devices you mean? [16:24] once we switch to nexus4 and nexus10 :) [16:24] seb128, ++ [16:24] seb128, I will follow up to the original thread once I have a bit more info [16:24] janimo: yeah, i do want ids of the nexus range to be in the usb-creator. [16:24] janimo: but I don't have them. [16:24] janimo, thanks [16:25] xnox, so galaxy nexus phone too? [16:25] [action] jani to mail ubuntu-devel about accelerometer plans [16:25] ACTION: jani to mail ubuntu-devel about accelerometer plans [16:25] janimo: yes please. [16:25] janimo: we don't have images for those devices yet, but I'd like usb-creator to know about them already. [16:26] (.img + .bootimg style images that is) [16:26] xnox, one thing I remember is that both nexus 7 and galaxy report different USB IDs depending on whether they booted in recovery mode or regular android [16:26] note though that the phone installation functions differently from our installation procedure [16:26] janimo: currently I trigger on two ID_MODEL_IDs [16:26] ogra, when appropriate, I have a short topic. [16:26] (i assume we can adjust that though) [16:26] kyleN, well, we dont have an agenda atm. feel free to just start when its quiet [16:27] i.e. now :) [16:27] ogra_: yeah. =/ given enough demand we can add additional types of flashing. the *.bootimg and *.img backend took only have a day to code in the end. [16:27] Before the holidays there was some discussion of using valgrind to find memory leaks and thereby improve Ubuntu for resource constained devices. [16:27] I worked on apport-valgrind, which was released into raring as part of apport. [16:28] nice ! [16:28] This allows you to run valgrind for an executable (to find memory leaks) while first populating a temporary directory with available debug symbols for the executable, which makes the resulting valgrind log file more complete and useful (because more symbols names are filled in, making the stack traces clearer) [16:28] Alex Chiang submitted a needed patch for this that landed in valgrind. [16:28] and in Ubuntu/R [16:28] This is a first step. There are many aspects to this. I started a blog to cover some of this: http://kylenubuntu.blogspot.com/ [16:28] you need to blog about that, that extends far beyond nexus7 [16:28] I expect to add more blog posts soon on this topic. [16:29] DONE [16:29] and sounds helpful everywhere [16:29] time you get onto planet ! [16:29] I was going to say [16:29] nobody is going to read those if they are not on planet [16:29] do I need a rocket ship to get there? ;) [16:29] no offense to your blog popularity ;-) [16:29] just ubuntu membership [16:29] BTW, nexus 7 testers please http://people.canonical.com/~jani/linux-image-3.1.10-8-nexus7_3.1.10-8.21_armhf.deb [16:30] ack [16:30] note that this will break your touchscreen :P [16:30] for me this deb fixes sound on boot without having to do a suspend. I'd like other opinions too [16:30] well log in via ssh and install http://paste.ubuntu.com/1570120/ over /usr/bin/acceld :) === fenris is now known as Guest10857 [16:31] janimo, is that need ? i would just drop the "Rotatet "right"" from xorg.conf [16:31] *Rotate [16:32] anyway, the current nx7 looks pretty good already ... we have one big showstopper bug left though [16:32] bug 1068994 [16:32] bug 1068994 in ubuntu-nexus7 "button1 gets stuck after a while" [Critical,Confirmed] https://launchpad.net/bugs/1068994 [16:32] * ogra_ pokes the bot [16:33] ogra_, it needs to correlate xrandr names to xinput rotation matrix. The latter get shifted with the kernel 90 degree rotation [16:33] so it is needed [16:33] and after the fix for portrait mode i must say that i clearly suspect compiz to be at fault, not xorg [16:33] if the bug occurs to me, i can still hit the ubuntu key on onboard to switch apps, and i can interact withj the app content [16:34] what doesnt take any input are window frames, panel and launcher [16:34] all therr are compiz [16:34] *three [16:34] so i start to suspect compiz itself has an issue here [16:35] what we are also still missing is bluetooth [16:35] is cyphermox around ? [16:36] the quantal image has some hacks to push the binary firmware into the driver when BT starts ... we dont have that in raring atm (and i'm not sure we want it) [16:37] so it would be good to know the plans here, can we get it to work without the binary bits, if not, ho do we integrate them properly [16:37] *how [16:37] seb128, could you forward that question ? [16:38] ogra_, sure [16:38] (probably also better discussed by mail= [16:38] yeah, sounds like something for ubuntu-devel@ as well [16:38] what else did i miss ? [16:38] is anyone working on collecting the valgrind datas from the community? [16:38] do we have anyone from QA around ? [16:39] plars, ? [16:39] what about optimizing processes running? [16:39] oh, definitely [16:39] who? [16:39] I want to start organizing those better [16:39] so I want to get everybody in touch [16:40] how about we make a task table and people can pick from it ... [16:40] Gema and Paul Larson both mentioned activities related to collecting smem output in QA labs [16:40] we have started doing a table with lool [16:40] unclaimed tasks will then be forcefully assigned [16:40] we need to publish it [16:40] great [16:40] we have also some blueprints [16:40] lool, yeah, i know plars wroks on nexus stuff [16:40] (thus the ping) [16:41] ogasawara: hi, I'm here [16:41] i implemented preseeding support for him last week [16:41] grr [16:41] hehe [16:41] ogasawara: sorry [16:41] ogra_: yes, I'm here, but in about 30 different irc windows at the moment :) [16:41] plars, so anything you want to tell us about nx7 work ? [16:42] seb128, for collecting stuff from the community it sounds like balloons might be the right guy [16:42] ogra_: just that I got your email about preseeding and I am anxious to try it, but I was off yesterday and haven't gotten to it yet today [16:42] ogra_: assuming that works, we should be able to automate installs on the nexus in the lab and have automated tests running pretty soon [16:42] ok, i'm not sure it works 100% yet, please bug me if there are issues [16:43] ogra_, ok, I think I will try to draft a "status update/summary/how we organize a bit better going forward" email early next week [16:43] ogra_, I will run the draft through you, lool and some others before sending [16:43] ogra_: if you have an example preseed or script for munging it into the image already, that would streamline things considerably [16:43] seb128, great, lets turn that (or parts of it) into our meeting agenda [16:44] plars, heh, no, i dont, i used to abuse tobin as a preseed stoirage in the past :) [16:44] oh, btw, do we have anyone from the kernel team here ? [16:45] cking used to work on power management on the nx7 [16:45] and it got really really bad since we switched to raring [16:45] ogra_, it's the same kernel though right? [16:46] from battery values <50% on i get a battery popup every second until the device shuts down (3-4h long)+ [16:46] janimo, nope, it was re-based on the later android release [16:46] ah right [16:46] i got these issues since the first raring kernel landed [16:46] so a quantal kernel has no such issues ? [16:47] hey guys. [16:47] could be a raring userland policy bug as well [16:47] ogra_, has a bug been filed so we can track that? [16:47] percentage and time are totally off all the time and i get weird power messages on charging or after a few hours of usage [16:47] cking, sure [16:47] janimo, yeah, could be, i also noticed that upower shows an additional usb charger [16:47] i dont think that was there in quantal [16:49] cking, bug 1093543 [16:49] bug 1093543 in ubuntu-nexus7 "Battery status behaves erratically" [Medium,Confirmed] https://launchpad.net/bugs/1093543 [16:49] (sorry, tootk a moment to find it) [16:50] ogra_, thanks, i'll look at that one [16:50] great [16:50] i think we talked about it before btw [16:50] but didnt find any cause [16:51] ok ... [16:51] anyone from the community around with questions etc ? [16:51] doesnt look like [16:52] doesn anyone want to bring something up before i close ? [16:52] going once [16:52] ogra_, do we know if the pointer/grab lock issue is being worked or making any progress? [16:52] it's pretty much a blocker if you want to use the nexus [16:52] seb128, tjaalton sent it upstream [16:52] seb128, its not as bad as you think [16:52] is it just sitting there or did somebody pick itup? [16:53] i use the nx7 all day, if you use it carefully you can get through with only having the issue once a day [16:53] lol [16:53] i think it rots upstream [16:53] "if you use it carefully" [16:53] seb128: upstream knows about it, pinged him earlier this week but no new patches to try [16:53] ogasawara, are you using a mouse? [16:53] like explain to users to not use the indicators? ;-) [16:53] there was quite some activity in the beginning [16:53] but that died [16:53] janimo, indeed not :) [16:54] tjaalton, did you try with the latest fixes, its really only compiz that freezes [16:54] "if you make sure not to use the touchscreen on your tablet, you're fine" [16:54] ogra_: hm, no [16:54] tjaalton, i can interact with everything else on the desktop just fine [16:54] oh [16:54] sweet [16:54] just not panel, launcher and *window frames* [16:54] lol, because who needs to use a panel or launcher? ;-) [16:55] but firefox content, terminal, onboard etc work fine [16:55] seb128, well, if i just read a long article in FF, all i need is the grab'n drag extension to work ;) [16:56] and switching apps works fine via onboard (_hit the ubuntu key, pick the number of your app) [16:56] tjaalton, so i think it would be worth taking a second look with focus on compiz [16:57] 3 min left ... anything else ? [16:58] ogra_: update the lp bug and I'll ask peter again where the bug is. the previous logs we had did show that the grab state was fooked, but.. we'll see [16:58] tjaalton, well, there were a bunch of issues with input fixed in the last xorg upload [16:58] so i would suspect we might have cleared the xorg side now [16:58] oh the patch bryce put back in? yeah sorry about that, it was a bad merge by me :) [16:59] mistakenly dropped a patch that fixed the rotation [16:59] well, i think bryce and danien van vugt added patches [16:59] when merging new bugfix release [16:59] *daniel [16:59] xserver only got this one back [16:59] also a point release before that [16:59] well, todays raring works pretty well for me [17:00] apart from the compiz hang [17:00] no other input issues here [17:00] ok, time is up [17:00] going once [17:00] going twice [17:00] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology [17:00] Meeting ended Fri Jan 25 17:00:41 2013 UTC. [17:00] Minutes (wiki): http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-01-25-16.02.moin.txt [17:00] Minutes (html): http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-01-25-16.02.html [17:00] could be that the apps that are working are using XI1 and it's the multitouch-aware clients (XI2) that are busted [17:00] thanks everyone, see you next week :) [17:00] cheers [17:01] thanks [17:01] tjaalton, yeah [17:01] I'll verify that next week [17:01] .au is well past beer-o-clock already [17:01] :) [17:08] tjaalton, oh, are you at LCA ? [17:11] ogra_: no, but upstream is from there [17:11] heh, ok === doko_ is now known as doko [17:59] Just checking, the ubuntu-tv meeting will start soon, right? [18:00] Pajn: yes [18:00] thanks! [18:00] tgm4883: whenever you're ready [18:03] I'm here [18:03] bobweaver, are you here too? [18:04] he may not be here for this one [18:05] #startmeeting Ubuntu-TV Community Meeting [18:05] Meeting started Fri Jan 25 18:05:06 2013 UTC. The chair is tgm4883. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [18:05] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu-TV Community Meeting Meeting | Current topic: [18:05] #chair tgm4883 mhall119 [18:05] Current chairs: mhall119 tgm4883 [18:05] So since this is our first community meeting, it's a bit unstructured [18:06] #topic Community Questions === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu-TV Community Meeting Meeting | Current topic: Community Questions [18:06] Are there any questions from anyone in the community? [18:06] I have a few, can just fire them all out? [18:06] fire away [18:07] I'll make subtopics for them, so it's well organized [18:07] according to the wiki, you still need unity 2d to get UbuntuTV to work, but it seems that Ubuntu is moving from that ... is there any plans to support it in unity3d any time soon? [18:08] #subtopic according to the wiki, you still need unity 2d to get UbuntuTV to work, but it seems that Ubuntu is moving from that ... is there any plans to support it in unity3d any time soon? [18:08] hmm, I'm assuming that meetingology got that [18:08] I've got no input on that question. mhall119? [18:08] steve_fi: yes, since last year the efforts have been focused on re-writing everything in Nux and Unity 3d, but it's not been a very easy process [18:09] AFAIK, bobweaver works on most of that. Unfortunately he isn't here [18:10] yeah, he's been the only one working on it [18:10] jhop said he'd be a little late as well, although IDK if he knows any more [18:10] various issues with the compexity of compix and the lack of good Nux documentation has been holding it back [18:10] lastly, I also pinged willcooke about the meeting, but didn't hear back [18:10] ah ok, next is just does anyone know if the current build of UbuntuTV works at all on Raring? [18:11] #subtopic does anyone know if the current build of UbuntuTV works at all on Raring? [18:11] I'd say it's doubtful. But again, a question for bobweaver [18:11] I think bobweaver has the unity2d version working in Quantal now, and available in PPA that makes it easier to install and try [18:11] steve_fi, no I or at least I dont. also the phone uses qml so once the phone code is released then there is that [18:11] o/ [18:11] everything that I have is 12.04 [18:11] ah ok, thanks for the information! [18:11] yo [18:12] hi bobweaver [18:12] hello [18:12] steve_fi, more questions? [18:13] Nope, that's all for now thanks [18:13] ok [18:13] anyone else have any questions? [18:13] Lets move on to status updates, and we'll ask for questions again at the end [18:14] #topic Status Updates === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu-TV Community Meeting Meeting | Current topic: Status Updates [18:14] bobweaver, any updates? [18:15] as far as ? [18:15] bobweaver, anything you want to update [18:16] nope maybe that I will be just doing things(coding) for fun and the "heck" of it . until the phone goes public. maybe I have a lot of personal things going on [18:17] ok [18:17] mhall119, anything to update [18:18] no, but hopefully we'll have more to report once the Phone code is public and we can start getting an idea of how it will integrate with desktop and TV [18:18] ok [18:18] DVR/Guide update [18:19] I made a large push this week with the guide scope. I'd say it is 95% done. [18:19] I still need to get a guide lens written, as I'm still using the videos lens for it [18:19] It also needs packaged [18:20] I'll need to figure out how to package a python library as well. The library for accessing the mythtv services is probably only 30% done, but it's the 30% we need :) [18:21] tgm4883: I can try and help with that [18:21]