| dholbach | good morning | 06:39 |
|---|---|---|
| === asac_ is now known as asac | ||
| === DannyZ_ is now known as DannyZ | ||
| === cprov-out is now known as cprov | ||
| === asac_ is now known as asac | ||
| === seb128_ is now known as seb128 | ||
| === hwilke is now known as hfwilke | ||
| davidm | #startmeeting | 16:59 |
| MootBot | Meeting started at 16:59. The chair is davidm. | 16:59 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 16:59 |
| agoliveira | davidm: You're 25 second early :) | 16:59 |
| mawhalen | Mauri joined | 16:59 |
| alek_desk | hi | 16:59 |
| * davidm grins | 17:00 | |
| cjwatson | present, sir | 17:00 |
| davidm | Hi all | 17:00 |
| mdz | good day | 17:00 |
| lool | Hey Colin! | 17:00 |
| cjwatson | lool: good evening | 17:00 |
| Don_Johnson | Don Johnson is here | 17:00 |
| amitk_ | hi all | 17:00 |
| davidm | We have some old business to cover and then we have some new items that are important | 17:00 |
| === amitk_ is now known as amitk | ||
| davidm | Is bspenser here today? | 17:01 |
| mawhalen | Rusty cannot attend today | 17:01 |
| mawhalen | I'm checking | 17:01 |
| davidm | Ah, OK then I'll skip the rustyl old business | 17:02 |
| bryce | hi | 17:03 |
| davidm | In the mean time we have an old item that I think is closed | 17:03 |
| === davidm changed the topic of #ubuntu-mobile to: amitk to update hardy ppa with drivers | ||
| davidm | amitk, is this now moot? | 17:03 |
| amitk | davidm: yes | 17:03 |
| davidm | OK, I'll close it | 17:03 |
| amitk | all the new drivers are in the hardy kernel | 17:04 |
| === davidm changed the topic of #ubuntu-mobile to: bspencer & horaceli to verify the ubuntu branch works | ||
| mdz | davidm: I think you meant [topic] rather than /topic | 17:04 |
| davidm | you are correct | 17:04 |
| davidm | [topic] bspencer & horaceli to verify the ubuntu branch works | 17:04 |
| MootBot | New Topic: bspencer & horaceli to verify the ubuntu branch works | 17:04 |
| === lool changed the topic of #ubuntu-mobile to: Ubuntu Mobile and Embedded | ||
| davidm | bspencer, is this still open, moot or what? | 17:05 |
| bspencer | davidm, we did that a few weeks ago | 17:05 |
| davidm | thanks lool | 17:05 |
| bspencer | and submitted patches | 17:05 |
| === cjwatson changed the topic of #ubuntu-mobile to: https://wiki.ubuntu.com/MobileAndEmbedded | https://wiki.ubuntu.com/MobileAndEmbedded/FAQ | ||
| bspencer | there was also a related bug | 17:05 |
| cjwatson | [restoring old URLs, seem useful?] | 17:05 |
| lool | cjwatson: Thanks; didn't find the topic in my /lastlog | 17:05 |
| davidm | bspencer, is it closed then? | 17:06 |
| bspencer | bfiller_, is there anything you know of with the ubuntu branch that isn't working (hildon stuff I think this is referring to) | 17:06 |
| bspencer | davidm, yes, as far as I know | 17:06 |
| bfiller_ | bspencer: I'm still tracking down a bug in new hildon-desktop where drags are not getting propogated to the Flash movie | 17:06 |
| davidm | OK, on to the next topic then | 17:06 |
| bspencer | bfiller_, curious. what are "drags"? | 17:07 |
| bspencer | dragging an object | 17:07 |
| bfiller_ | bspencer: click, hold and drag - animiates the flash movie in a certain way and is not now working | 17:07 |
| bspencer | but was working befofre | 17:08 |
| bfiller_ | bspencer: yes and looking at the hildon-desktop change log, Nokia modified this code quite a bit | 17:08 |
| kyleN | bspencer: for example there is a carousel of apps that you used to be able to spin with a drag | 17:08 |
| bspencer | kyleN, yes, I've seen that | 17:08 |
| agoliveira | bspencer: Colective of drag queens? | 17:08 |
| bspencer | agoliveira, thanks for the clarification | 17:08 |
| agoliveira | :) | 17:09 |
| bspencer | bfiller_, alright. If horace gets a few cycles I'll have him play with that a bit. | 17:09 |
| bspencer | <davidm> OK, on to the next topic then | 17:09 |
| davidm | do we need to take an action about this before I move on? | 17:09 |
| bfiller_ | bspencer: thanks and I'll sync with horace to let him know what I've found | 17:09 |
| davidm | [topic] Lexington to test ext3 for boot speed and disk image corruption | 17:10 |
| bspencer | davidm, I don't think so. This is background work. bfiller already chasing it. | 17:10 |
| MootBot | New Topic: Lexington to test ext3 for boot speed and disk image corruption | 17:10 |
| davidm | I know the status of this just changed yesterday. | 17:10 |
| davidm | disk image corruption appears to be related to Image Creator was storing the squashfs image on an ext2 not ext3 partition | 17:10 |
| ChickenCutlass | I just sent a patch this morning to the moblin guys fixing the disk corruption issue | 17:11 |
| ChickenCutlass | I plan on testing the ext3 image before weeks end | 17:11 |
| davidm | So I'll close the disk image corruption portion | 17:11 |
| davidm | ChickenCutlass, thanks | 17:11 |
| alek_desk | I'm curious why squashfs on ext2 could make fs corruption. since the partition should be readonly | 17:11 |
| ChickenCutlass | good question -- However I would see the shashfs image file get corrupt when using ext2 but recover just fine when using ext3 to store the file | 17:12 |
| mdz | ChickenCutlass: ever checked the mount flags? | 17:12 |
| alek_desk | then I guess we mount it in wrong way. | 17:12 |
| bspencer | ChickenCutlass, so it gets corrupt in both cases but just recovered in ext3? :-\ | 17:12 |
| mdz | if it's read-only and being corrupted, then there's a scary issue we need to investigate regardless | 17:13 |
| agoliveira | bspencer: That's a good one... | 17:13 |
| ChickenCutlass | The patch I sent changes the mount flags as well -- to mount the partition as ext3 | 17:13 |
| agoliveira | ext3 has a journal so both get corrupted but ext3 recovers so nobody sees the problem. | 17:13 |
| mdz | ChickenCutlass: I mean, did you check the active ones in /proc/mounts to confirm that it's read-only as expected? | 17:13 |
| ChickenCutlass | mdz -- yes it was mounted as read only | 17:14 |
| davidm | So the issue still needs looking into, we have masked the problem then? | 17:14 |
| mdz | sounds that way | 17:14 |
| mdz | is this the corruption issue which seems to happen on an SSD device but not on a HDD device? | 17:14 |
| ChickenCutlass | I have seen this on HDD devices as well -- In fact it happened to Jon this week on his Q1 | 17:15 |
| mdz | maybe a driver bug? | 17:15 |
| alek_desk | anyway, I agree we could use ext3 and do some more test. and we have no reason not to use ext3 | 17:15 |
| smagoun | we're using unionfs, and I think only unionfs thinks it's mounted ro - I think the actual sqaushfs partition is mounted rw | 17:15 |
| mdz | smagoun: that would explain a few things | 17:16 |
| smagoun | nevermind, looks like I'm misreading /proc/mounts :/ | 17:16 |
| alek_desk | smagoun, even so, but no one would write to the partition. | 17:16 |
| davidm | OK, so is this an action for robr to look into? | 17:16 |
| smagoun | Here's /proc/mounts on my CB: http://pastebin.ubuntu.com/3445/ | 17:16 |
| ChickenCutlass | as a extra note on this | 17:16 |
| ChickenCutlass | I tried using aufs instead of unionfs and still had the problem | 17:17 |
| ChickenCutlass | I wanted to rule out unionfs | 17:17 |
| davidm | Good to know | 17:17 |
| alek_desk | davidm, please transfer the action to me directly. | 17:18 |
| davidm | OK | 17:18 |
| ChickenCutlass | looking at smagoun /proc/mounts | 17:18 |
| mdz | alek_desk: the kernel presumably will, e.g. updating the utimes when the squashfs loop file is accessed | 17:18 |
| ChickenCutlass | it looks like the squashfs partition is mounted as rw | 17:18 |
| ChickenCutlass | and should be ro | 17:18 |
| ChickenCutlass | /dev/sda1 /container ext3 rw,data=ordered 0 0 | 17:19 |
| smagoun | I think ChickenCutlass is right, I've misread /proc/mounts twice now :( | 17:19 |
| mdz | /dev/sda1 /container ext3 rw,data=ordered 0 0 | 17:19 |
| davidm | [action] alek_desk, to look into why squashfs fs corruption happens. | 17:19 |
| MootBot | ACTION received: alek_desk, to look into why squashfs fs corruption happens. | 17:19 |
| davidm | We OK to continue on? | 17:20 |
| mdz | yes | 17:20 |
| davidm | [topic] bspencer to talk with developers to push get tags when making a release, and report back on status of this | 17:20 |
| MootBot | New Topic: bspencer to talk with developers to push get tags when making a release, and report back on status of this | 17:20 |
| bspencer | bspencer to /talk/ with developers | 17:21 |
| bspencer | complete | 17:21 |
| bspencer | talked to | 17:21 |
| agoliveira | That was a cool sidestep :) | 17:21 |
| bspencer | we discussed this in our last trip to china and also here... but I doubt it has been taken to heart | 17:21 |
| bspencer | I haven't checked to see if such tagging has occurred but I think it probably hasn't | 17:21 |
| bspencer | because you have to jump up and down longer for results | 17:22 |
| smagoun | bspencer: it's intermittent, which is progress in the right direction | 17:22 |
| alek_desk | bspencer, at least I know that rule. :) | 17:22 |
| davidm | bspencer, Can you look into that further? | 17:22 |
| bspencer | alek_desk, good to hear :) . davidm, yes | 17:22 |
| davidm | [action] bspencer to checked to see if such tagging has occurred | 17:23 |
| MootBot | ACTION received: bspencer to checked to see if such tagging has occurred | 17:23 |
| bspencer | /checked/ ... good | 17:23 |
| bspencer | ;) | 17:23 |
| davidm | The action item from the 3rd will carry over since both rusty and tollef are not here today. | 17:23 |
| davidm | so we are on to new business | 17:23 |
| smagoun | davidm: there's 1 more action item from 12/20: | 17:24 |
| smagoun | davidm to query build team on best way to monitor the i386 builds and the LPIA builds to stay in sync | 17:24 |
| davidm | It's a manual process | 17:24 |
| bspencer | aside: mdz, are you waiting on rusty to schedule your next process meeting? | 17:24 |
| smagoun | I came across http://qa.ubuntuwire.com/ftbfs/ , which lists build failures for LPIA (among other things) | 17:24 |
| davidm | that was the answer I got. SO we have to monitor it. | 17:24 |
| cjwatson | smagoun: what's this, checking on out-of-date packages between the architectures? | 17:24 |
| cjwatson | smagoun: http://people.ubuntu.com/~ubuntu-archive/testing-ports/hardy_outdate.txt (etc.) may also be useful | 17:25 |
| mdz | bspencer: I'm waiting for a response from Intel to the proposal and requests for followup discussions, and I'm told that Rusty is going to do that | 17:25 |
| mdz | bspencer: I'd be happy to hear from anyone, to be honest | 17:25 |
| smagoun | cjwatson: yes. We've run into several packages on gutsy where the LPIA build doesn't have the same bits as the corresponding i386 build | 17:25 |
| cjwatson | (though it has noise from things that are building but just haven't built yet) | 17:25 |
| bspencer | mdz, that's what I thought. rustyl has been at CES distraction. I'll remind him | 17:25 |
| mdz | bspencer: you were CCed on it as well | 17:25 |
| cjwatson | smagoun: if both have built but the contents are wrong, then I agree with davidm, that's definitely manual | 17:25 |
| bspencer | mdz, yep. I'll reply | 17:25 |
| mdz | bspencer: mawhalen said she would mention it to Rusty but that he probably wouldn't get to it while at CES | 17:25 |
| cjwatson | since sometimes the contents are meant to be different | 17:26 |
| lool | cjwatson: I think the biggest problem was missing or out of date lpia binaries | 17:26 |
| mawhalen | mdz: rustyl is back today, I'll speak with him. | 17:27 |
| smagoun | cjwatson: I phrased that poorly. Builds are sometimes failing for LPIA though they work on i386, so LPIA winds up with older versions of a package than i386 | 17:27 |
| cjwatson | smagoun: ok, that's automated in various places as you've found, but if you can specify a particular query you'd like to have performed regularly then the archive team can help out | 17:28 |
| smagoun | cjwatson: The query I think we need is "show me all packages that built on i386 but failed to build on lpia" | 17:29 |
| davidm | OK are we good on this topic | 17:29 |
| davidm | [topic] Discuss Intel Schedule Deliverables, Need more detail, who, what, when | 17:30 |
| MootBot | New Topic: Discuss Intel Schedule Deliverables, Need more detail, who, what, when | 17:30 |
| bspencer | big topic | 17:30 |
| davidm | I've been trying to figure out what has been dropped when and I've had a very hard time matching to the SOW | 17:31 |
| davidm | For example there was a mobile browser drop on 17 Dec but was it a beta drop or CES drop or what? | 17:31 |
| davidm | I can't tell | 17:31 |
| bspencer | mawhalen, do you want to take this? | 17:32 |
| mawhalen | davidm: We released an internal image to our validation team on 12/21 | 17:32 |
| mawhalen | We called it our internal beta2 | 17:32 |
| mawhalen | All the browser code that is used for this drop is off moblin | 17:32 |
| patm | we also need to sync on terminology wrt alpha and beta | 17:32 |
| davidm | There are other things like that, there was supposed to be a applits drop on the 17th also but that did not happen but there was a drop on the 19th of December | 17:32 |
| smagoun | mawhalen: The difference between internal + external version numbering is very confusing to many of us. | 17:33 |
| patm | I would prefer if this group always used just the internal names | 17:33 |
| davidm | So I'm some confused by all of this and not sure what actually needs to go into a build. | 17:33 |
| bspencer | smagoun, package versions don't have any reflection of our internal "beta" milestones | 17:33 |
| mawhalen | smagoun: what we really need is to have the version numbers posted off moblin to stop confusion when people hear about something not available external | 17:34 |
| smagoun | bspencer: we hear a fair amount of "it's fixed in alpha 3" | 17:34 |
| bspencer | davidm, this is a topic that mdz has been addressing with rusty and I to get a clearer process for when things are pushed into Ubuntu from us | 17:34 |
| mawhalen | David - what is the 17th mention? | 17:34 |
| davidm | In the SOW schedule I have it shows a drop of moblin-applits for the 17 dec but there was no drop, There was a drop on the 19th however but I don't know if that was the 17th drop or something else. | 17:35 |
| davidm | I've been working with Don to gain clarity but there are items that are very dense. | 17:36 |
| mdz | bspencer: it's a related but distinct issue, I think. davidm is looking for details about your schedule for putting out new releases of components, and deviations from it | 17:36 |
| davidm | So that I can account to Don and Intel what is in a build that we deliver. | 17:37 |
| mdz | bspencer: I think when we nail the larger process issue, this will be moot, but that will take time, and davidm has some specific questions | 17:37 |
| davidm | Also patm relies on my schedule which depends on these items and their drop date. | 17:38 |
| bspencer | davidm, I'm having to defer to mawhalen because I'm not intimate with the SOW. I've seen it but don't track it myself | 17:38 |
| davidm | So, we can take this off line if need be since we have some addition items that are critical for this meeting but I do need to understand this better. | 17:38 |
| mawhalen | davidm: I just looked at Don's new schedule, yes we should take offline with Don. | 17:38 |
| mawhalen | davidm: let's talk in the next meeting | 17:39 |
| davidm | OK, [action] mawhalen Don_Johnson davidm to meet off line on schedule issues | 17:39 |
| davidm | [action] mawhalen Don_Johnson davidm to meet off line on schedule issues | 17:39 |
| MootBot | ACTION received: mawhalen Don_Johnson davidm to meet off line on schedule issues | 17:39 |
| davidm | [topic] Discuss issues around libdrm and getting a working X for hardy | 17:40 |
| MootBot | New Topic: Discuss issues around libdrm and getting a working X for hardy | 17:40 |
| davidm | This is critical we still can't get a kernel and x working bryce, amitk can you inject here | 17:41 |
| davidm | We might be able to stay on gutsy but there are issues around that too. | 17:41 |
| bryce | there's two issues with X, one about libdrm, one about -psb | 17:41 |
| smagoun | davidm: I assume the issue is hardy, we have it working on gutsy | 17:41 |
| amitk | All the kernel bits are ready for upload as soon as the alpha freeze is lifted | 17:41 |
| cjwatson | alpha freeze> that's expected today, perhaps tomorrow at worst | 17:42 |
| davidm | smagoun, the current gutsy fix is fragile from bryces point of view which increases risk | 17:43 |
| bryce | libdrm: the moblin.org patch to libdrm has been proving difficult to port to ubuntu. It's a 63,000 line patch. | 17:43 |
| agoliveira | Ouch... | 17:43 |
| bryce | I got a new copy last night, so am going to give it another go today | 17:43 |
| bryce | apparently Tungsten Graphics does their X development against git head of libdrm, and thus basically requires a git snapshot of libdrm | 17:44 |
| amitk | they seem do all their development against git heads, including the DRM kernel bits. | 17:45 |
| bryce | I think if they continue doing this, it's going to continue causing issues such as this in the future with the X stack. | 17:45 |
| bryce | it's a really frustrating problem from the packaging side of things | 17:45 |
| bspencer | amitk, bryce can you send your comments about Tungsten in a verbose email we can follow up | 17:46 |
| bryce | it also makes it infeasible to roll any of the libdrm / -psb bits into Ubuntu proper, but that's a lesser issue for now | 17:46 |
| amitk | can't there be alternate packages, so you have two full libdrm packages, one lpia-only | 17:46 |
| bspencer | because they aren't here and we have to coordinate with other group working with them | 17:46 |
| bryce | the second issue, and perhaps more critical, is the -psb driver | 17:46 |
| mawhalen | bryce: amitk: Rob has pursued this and has other information like diff files. Rob could not join today but know he has additional information. | 17:47 |
| mawhalen | please do summarize and make sure Rob Rhoads is on the email. | 17:47 |
| amitk | bspencer: I think I have already put all my comments during or after UDS. | 17:47 |
| davidm | [action] bryce and amitk to provide verbose emails to bspencer about issues surronding Tungsten | 17:47 |
| MootBot | ACTION received: bryce and amitk to provide verbose emails to bspencer about issues surronding Tungsten | 17:47 |
| bspencer | amitk, ok. if done then I'll assume it has been communicated to Tungsten already | 17:47 |
| amitk | bspencer: I will resend those emails | 17:48 |
| bryce | bspencer: I've emailed about this in the past, and I'm arranging to go to the UME on site at Intel at the end of the month to try voicing this more clearly | 17:48 |
| bspencer | bryce, sounds good. thanks | 17:48 |
| davidm | In the shorter term what does it take to get a working image, is it possible? | 17:48 |
| bspencer | bryce, psb driver... did you finish ? | 17:48 |
| bryce | the second issue is with -psb - in addition to requiring the git head of libdrm, it's also developed against xserver 1.4's EXA | 17:49 |
| bryce | if we ship UME based on gutsy, this becomes a problem | 17:49 |
| davidm | cjwatson, you had some thoughts on this? | 17:50 |
| smagoun | bryce: As you know Intel's solution is to move aside libexa and ship their own copy. The actual diff between the gutsy EXA and the Intel EXA is quite small - maybe 10 lines. | 17:50 |
| cjwatson | so it sounds to me from the call earlier that there are two alternatives for shipping UME: either a substantially modified branch of gutsy, or hardy | 17:50 |
| smagoun | Building a new EXA for gutsy is no big deal for us | 17:50 |
| bryce | moblin.org got around it by including a copy of libexa in the -psb driver, and simply overwriting the xserver's libexa. This is a brittle solution, but sidesteps the problem. | 17:51 |
| cjwatson | the key in the first case is that (AFAICT) we don't necessarily have to preserve correct operation on normal systems | 17:51 |
| bryce | the second option would be to backport the EXA changes - which I've done in the past. However it looks infeasible this time... too much code changes | 17:51 |
| cjwatson | bryce: from your comments last night, it sounded like we would need to build a complete new X.org stack? Would that be easier if you didn't have to worry about keeping it working for normal Ubuntu users? | 17:51 |
| bryce | the third option is to backport xserver 1.4 and related dependencies to gutsy. I'm worried this could turn into a largish time commitment | 17:52 |
| amitk | cjwatson: exactly the question I was asking above... can we maintain a separate stack? | 17:52 |
| cjwatson | bryce: what parts break if one essentially just builds all the hardy packages on gutsy? | 17:52 |
| smagoun | bryce: The delta between gutsy + Intel EXA is very small. Is a full backport really necessary? | 17:52 |
| cjwatson | amitk: well, I wasn't even thinking of a separate stack, just blatting over the top | 17:52 |
| bryce | cjwatson: possibly; although I suspect if it works, it'd work for regular users as well | 17:53 |
| cjwatson | separate stack means renaming stuff which is generally fragile in the case of something with complex dependencies and maintainer scripts like X | 17:53 |
| raji | asac, I have question about nm-applet windows, you there? | 17:53 |
| amitk | for the kernel bits, in case of LPIA we just disable the stock kernel DRM and add the whole damn stack from Tungsten in LUM. | 17:53 |
| bspencer | raji, we're in a meeting now. maybe touch base in 15mins? | 17:53 |
| raji | asac, ok. | 17:54 |
| bryce | there's a couple dependencies that'd need backported in addition to xserver; other than that, it'd also require rebuilding all the drivers and such | 17:54 |
| cjwatson | smagoun: bryce referred to two separate instances of problems, one that happened in gutsy and one newer than that; is it possible you're referring to the older problem? | 17:55 |
| bryce | anyway, that's where we're at with -psb. I'm not sure which option is best to take. | 17:56 |
| davidm | We are running short of time, does anyone object if we run over? | 17:56 |
| davidm | After this Don_Johnson had a query | 17:57 |
| bryce | (fwiw, the root cause of this issue was also that tungsten graphics had been doing the development against git head of xserver before 1.4 was released) | 17:57 |
| Don_Johnson | I have to drop for another meeting. I was going t o ask about 8688 status, but we can cover that at the next meeting. | 17:57 |
| davidm | OK Don_Johnson | 17:58 |
| cjwatson | it's hard to blame upstream developers for developing against git, really; it's the most expedient course for them to get stuff merged | 17:58 |
| smagoun | cjwatson: Maybe I don't understand the problem. The psb driver is developed against a special version of EXA, which is very similar to the EXA in gutsy. EXA in hardy is at least as new as the one in gutsy, so there should be a smaller delta (intel's patches are from the exa development tree) | 17:58 |
| cjwatson | smagoun: as I understand the problem bryce is describing, the psb driver targeted at hardy has jumped ahead considerably in terms of its EXA requirements, well beyond what's in hardy | 17:58 |
| cjwatson | (and well beyond anything that's yet stable) | 17:59 |
| bryce | smagoun: no, -psb is developed against a version of EXA that is similar to the EXA in hardy | 17:59 |
| === dholbach_ is now known as dholbach | ||
| smagoun | bryce: Is there another Intel exa tree someplace? The only one I know of is at moblin.org, which is EXA 2.1 + a handful of small patches | 18:01 |
| smagoun | (and it hasn't been updated since 10/2007) | 18:01 |
| bryce | smagoun: that sounds like the one I put together last fall | 18:02 |
| bryce | smagoun: in the beta3 of -psb there is a copy of the libexa tree | 18:02 |
| bryce | unfortunatley it's not broken out by patches, so I don't know exactly what of it is needed | 18:02 |
| smagoun | bryce: Is the beta3 version not public then? | 18:03 |
| bryce | it's in moblin's git | 18:03 |
| smagoun | forgive my ignorance, where? I haven't found it at the top level or in xf86-video-psb | 18:04 |
| bryce | it's in xf86-video-psb/exa | 18:06 |
| bryce | smagoun: I'd be happy to forward you emails with more background on this if you'd like | 18:07 |
| davidm | OK, I guess for me the question is, short term how do I get a per-beta out next week? | 18:09 |
| davidm | What is the best path for the short term which could be different for the longer term? | 18:09 |
| bryce | well, assuming we stay with gutsy, the xserver backport seems like the cleanest, most likely to work solution, given the manpower to do it | 18:10 |
| bryce | the other viable option would be to use the moblin hack of just copying libexa over the top of the xserver libexa. Short term that may be sufficient, and probably not too much work. | 18:11 |
| agoliveira | Fenario: Hi Jon. How's the party with the casino hostess? | 18:11 |
| agoliveira | Ooops... :) | 18:11 |
| davidm | OK, I think we take this off line and examine the best paths to solution then. | 18:12 |
| bryce | my working plan is basically a) get libdrm built (problem #1), then b) test out the moblin hack on my own UME hardware, and finally c) we need to decide about whether to do the xserver backport, or move to hardy, or .... | 18:12 |
| lool | I don't quite understand the big drawbacks we have in hardy? In the past, stability was mentionned as an issue, but is this still the reason we're considering gutsy? | 18:12 |
| davidm | We still are not on hardy yet. | 18:13 |
| davidm | That is issue | 18:13 |
| lool | Well I succeded in building hardy images until the new .24 kernel which is being fixed and what we target | 18:14 |
| lool | Certainly I can agree there are visible issues on hardy, but these look like less work to fix than the gutsy discussions above | 18:14 |
| cjwatson | bryce: could you start down that path on a time-limited basis? it seems that it'd be useful to make progress on this, up to and including the xserver backport - but if the UME project needs to move to hardy or face not being able to do anything, then that terminates the backport project | 18:14 |
| bryce | cjwatson: sure; how much time should I limit it to? | 18:15 |
| cjwatson | davidm: what are the time constraints here? | 18:15 |
| cjwatson | as in what is your drop-dead date for making a decision? | 18:15 |
| bspencer | do canonical mobile customers care whether we use hardy or gutsy? | 18:16 |
| smagoun_ | bspencer: from patm: no, they only care about features and whether the gfx drivers work | 18:17 |
| davidm | we need to have a working solid product and then we can explain to customers what it is. We have opened the possibility of gutsy prime as possible stability solution, but would prefer hardy since it has a better kernel and longer term support for security fixes and such | 18:18 |
| agoliveira | bspencer: It's also an internal issue, if we could keep the same base for everything, easier. | 18:18 |
| bspencer | yep. k | 18:18 |
| davidm | And I need to work to a schedule and can't right now | 18:18 |
| davidm | I need to produce a pre-beta next week and this is a blocker for it. | 18:19 |
| amitk | davidm: besides the kernel and X what is required for a pre-beta? | 18:19 |
| davidm | Some drops from Intel, and java | 18:19 |
| davidm | Thus the first new topic on schedule from Intel | 18:20 |
| davidm | Was supposed to happen today but I postponed to next week | 18:21 |
| bspencer | davidm, "some drops" you'll work out with mawhalen in next meeting, true? | 18:21 |
| davidm | Yes, this week and early next | 18:21 |
| bspencer | and for java it should install and work. (if you know the /persistmnt workaround for old kernel) | 18:21 |
| davidm | before next meeting I hope | 18:21 |
| davidm | bspencer, yes on java | 18:21 |
| davidm | if we wait for next meeting I miss release since it's currently next thursday. | 18:22 |
| bspencer | although I haven' t successfully run eclipse on a target image, I've run a few other java apps | 18:22 |
| davidm | But that I can track with Don and Maurie | 18:22 |
| bspencer | yep | 18:22 |
| agoliveira | bspencer: Why would you run eclipse there? | 18:22 |
| bspencer | debugging large app | 18:23 |
| davidm | OK, I'll continue to work with Intel, bryce and amit to make sure we have a plan. | 18:23 |
| agoliveira | bspencer: Well, this makes sense. Eclipse is a hog... | 18:23 |
| bspencer | sure. | 18:23 |
| bspencer | this was in xephyr, not on a device | 18:23 |
| bspencer | my processor was capable but eclipse crashes | 18:24 |
| bspencer | anyway, we digress. | 18:24 |
| davidm | Moving on, there is only one open item left Don's query on the Marvel 8688 driver. Anyone have any input? | 18:24 |
| davidm | Or we can revisit that next week | 18:25 |
| davidm | [topic] Marvel 8688 driver status? | 18:25 |
| MootBot | New Topic: Marvel 8688 driver status? | 18:25 |
| amitk | davidm: In your meeting with Intel I would like to know delivery schedules of the kernel drivers that I mentioned | 18:26 |
| davidm | That is part of what I am asking about. | 18:26 |
| amitk | Also our licensing agreement with marvell to ship the firmware for 8686 and 8688 is still open. | 18:27 |
| davidm | OK, I'll carry the query on Marvel 8688 driver status to next week. | 18:27 |
| davidm | amitk, I'll look into that | 18:27 |
| davidm | I'm going to end the meeting unless more to review? | 18:28 |
| amitk | thanks davidm | 18:28 |
| davidm | gooingf once.......... | 18:28 |
| lool | Thanks | 18:28 |
| davidm | that is going once.......... | 18:28 |
| davidm | that is going twice.... | 18:29 |
| davidm | #endmeeting | 18:30 |
| MootBot | Meeting finished at 18:30. | 18:30 |
| bryce | inuka, I just tried the new libdrm patches you sent last night - they also fail to apply | 18:59 |
| raji | asac, you available? | 18:59 |
| bryce | inuka, it appears the issue is that the patches are trying to create files that already exist in the Ubuntu libdrm tree | 18:59 |
| inuka | bryce, I am stumped. I applied the patches on source you had and it worked | 19:01 |
| inuka | bryce, did all the patches fail? | 19:01 |
| bryce | 00 applied | 19:02 |
| bryce | 01 partly applied, but complains about many files already existing | 19:03 |
| bryce | I didn't try the other patches | 19:03 |
| inuka | bryce, bare with me since I am still a grasshopper on this kind of thing, but when I patch against the tar of the source you had it worked.... all of them | 19:04 |
| bryce | well let me ask this - when you do an apt-get source libdrm, before any patching, is there already a libdrm-2.3.0/shared-core/drm_pciids.txt file? | 19:05 |
| bryce | patch 01 is trying to create that file (as an example), yet it already exists | 19:05 |
| bryce | ohh | 19:05 |
| inuka | bryce I didnt do apt-get source librm, I untared the libdrm source from your build and applied it against them.... am I doing something wrong... | 19:06 |
| bryce | did you use libdrm_2.3.0.orig.tar.gz, without the ./libdrm_2.3.0-4ubuntu1.diff.gz patch on top? I bet that's it | 19:06 |
| inuka | yes exactly, | 19:06 |
| bryce | ah, that would explain it | 19:06 |
| inuka | oh | 19:06 |
| bryce | yeah our goal is to get this stuff built atop the debian/ubuntu libdrm | 19:07 |
| bryce | that orig tarball is the original upstream libdrm, before any of the debian changes | 19:07 |
| inuka | I think some of the patches are alredy applied which is why its complaining, I will check it and e-mail..... | 19:09 |
| bryce | yup, that's what I think too | 19:11 |
| bryce | this is why having them broken down will be helpful | 19:11 |
| bryce | ok, I'll bbiab | 19:11 |
| bryce | inuka, I can get the patches to apply and build by dropping all the Debian changes. Not sure what we lose in doing this, but I'll go this route for now. | 20:48 |
| === cprov is now known as cprov-out | ||
| inuka | bryce, you shouldn't be losing anything since the patches cover all the changes, with 0-3 covering each change up until Beta3 | 21:44 |
| bryce | alright | 21:44 |
| bryce | whew, -psb is building finally | 21:44 |
| === DannyZ_ is now known as DannyZ | ||
| inuka | bryce, appreciate your patience.... for a bit there I was going down a different road. | 22:06 |
| inuka | bryce, hopefully the next time will be simple as syncing from the libdrm git tree. | 22:08 |
| === benj3one is now known as benj3one_nothere | ||
| === mawhalen__ is now known as mawhalen | ||
| bryce | libdrm, -psb Hardy+Gutsy debs and packages posted... http://people.ubuntu.com/~bryce/Testing/libdrm/ and http://people.ubuntu.com/~bryce/Testing/xserver-xorg-video-psb/ | 23:48 |
| InSearchOf | bryce, what team are you with? | 23:52 |
| bryce | not sure what you mean, I don't think I'm with any team in particular | 23:53 |
| InSearchOf | ubuntu core, MID, intel? | 23:54 |
| davidm | InSearchOf, platform | 23:55 |
| InSearchOf | ahhh ok | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!