[00:00] <asac> http://paste.ubuntu.com/3385/
[00:00] <raji> asac, quilt push -a applied all patches, didnt give any errors. I think it works.
[00:00] <asac> now the patch looks like
[00:00] <asac> http://paste.ubuntu.com/3386/
[00:00] <asac> raji: you have to apply your patch on top
[00:00] <asac> see above
[00:00] <asac> anyway ... next time you know where to look :)
[00:01] <raji> asac, yes sir, I hope my second patch will be as clean as yours next time :) . thanks for accepting the changes.
[00:03] <asac> thanks :)
[00:04] <asac> thats ok ... i will commit what i have here now to the branch
[00:09] <asac> raji: fix is now in bzr branch (rev 86)
[00:30] <raji> asac. great. thanks for letting me know.
[07:10] <dholbach> good morning
[15:16] <bfiller> patm, kyleN : do we have a list in any of the documents you guys have been working on off the new dev work that we need to do for Compal?
[15:17] <kyleN> bfiller: the "diff". i thin patm had on, but it is probably not complete given recent prd changes
[15:17] <kyleN> darn typos
[15:21] <dholbach> Mithrandir, StevenK: will somebody of you take care of bug 181304?
[15:21] <ubotu> Launchpad bug 181304 in bluez-gnome "[bluez-gnome] Please upgrade to new upstream version release" [Undecided,New] https://launchpad.net/bugs/181304
[15:48] <Mithrandir> StevenK: ^^ ; if you could take care of that whenever you have the time, that'd be good
[15:49] <smagoun> bfiller: kyleN patm this is a public channel
[15:52] <bfiller> smagoun: my bad again
[17:05] <kyleN> lool, hey. Do you know whether debian packaging supports any kind of a signing mechanism? Such a mechanism would enable a facility through which client could control what apps a customer can install. 
[18:10] <agoliveira> rustyl: Hi Rusty. Looks like there's a problem with your git repository. I'm trying to download the latest moblin-applets withoout success. Can you confirm that to me?
[18:12] <agoliveira> Anyone from Intel feel free to step in and respond, please :)
[18:13] <Mithrandir> agoliveira: works fine for me (over ssh)
[18:13] <Mithrandir> moblin.org doesn't seem to have a working git daemon atm, for some reason
[18:14] <agoliveira> Mithrandir: I'm just using git clone and I starts nicelly but b0rks about half way.
[18:17] <Mithrandir> try pulling git://git.err.no/moblin-applets and see if that works for you.
[18:44] <davidm> I think rustyl is at CES today
[18:58] <rustyl> just got back
[18:58] <rustyl> i flew in for a bunch of meetings, then got back last night and then slept late this morning
[18:59] <rustyl> agoliveira, what protocol were you attempting to use? http? ssh?
[19:00] <rustyl> I don't think we offer git: since we use ssh: for people that need write access and have http and rsync
[19:00] <agoliveira> rustyl: Hi. It was http IIRC. I aways have done it and it usually works.
[19:01] <rustyl> agoliveira, we might be having transient issues with the hosting service
[19:01] <rustyl> especially if the transaction started and then failed half-way through
[19:01] <agoliveira> rustyl: Makes sense as it's starting nicelly and b0rking half way. I got it from Tollef anyway.
[19:02] <rustyl> HappyCamp_ubuntu, have you seen the above?  Anything funny happening i the system logs?
[19:04] <Mithrandir> in general, it's better to use rsync than http, git hosting over http is prone to hiccups IME.
[19:36] <agoliveira> Mithrandir: Agree.
[21:24] <lool> kyleN: You can sign package repositories or actual deb files; the former is the most common; however there's simpler: I think the application installer software on the N8x0 for example is checking whether you're installing from a particularly named repo
[21:25] <kyleN> lool, thx - good info
[22:28] <inuka_desk> bryce, https://launchpad.net/ubuntu/+source/libdrm which src package is it gutsy or hardy that you need the patch for, also are you applying any other patches other than ours? 
[22:30] <bryce> inuka_desk: gutsy
[22:31] <bryce> well, it's the same package in gutsy and hardy both
[22:32] <bryce> the log I posted is with only one patch (01_default_perms.diff), which I expect should not conflict, or at most would have only a couple conflicts
[22:33] <bryce> I also tried building with both patches 100_ and 101_ - which were the moblin patches from last time.  It also failed; I assumed that the new patch should supersede these
[22:40] <inuka_desk> bryce, do you mind pointing to what you have in the debian. My patch should work on top of your existing patch. 
[22:41] <bryce> http://people.ubuntu.com/~bryce/Testing/libdrm/
[22:41] <inuka_desk> bryce: what we get is a patch corresponding to each release, which we combined to one huge patch along with psb header files.  I created the patch assuming the other two patches are already applied. 
[22:42] <inuka_desk> bryce: thanks I will take a look at that
[22:44] <bryce> procedurally, it would be better for me if these patches were left broken out as individual patches applied in series
[22:44] <bryce> this way, if one of the patches is broken, it can be handled and dropped/repaired/refactored in isolation from the others
[22:45] <bryce> currently with it being one big (63,000 line) patch, it's practically impossible to do anything with it on my end if it doesn't apply
[22:46] <inuka_desk> got it, the reason we did that was because Jacob had issues with the older patches. I will try to break it down.
[22:47] <bryce> also, it would be *really* useful to have a summary of what the patches are and what they do
[22:47] <bryce> because that can give a clue if, for instance, a broken patch might be a dupe of or in conflict with another ubuntu patch
[22:47] <bryce> oh, along those lines - 
[22:48] <bryce> waldo mentioned that the libdrm changes were already taken upstream, 
[22:49] <bryce> are the libdrm patches you're putting together used simply to resync up to git head?
[22:49] <bryce> if so, then perhaps rather than doing it via patches, we should just create a literal git snapshot of libdrm?
[22:53] <inuka_desk> upstream but unreleased,  not exactly we add the psb headers into the patch as well...
[22:54] <bryce> hrm
[22:54] <inuka_desk> basically if you create a snapshot of libdrm at the point of the merge and add in the psb header files you should be at the same point as the patch.
[22:56] <bryce> hmm
[22:56] <inuka_desk> It maybe better if I just clean up this, and make the psb-kmd-dev dependancy of xf86-video-psb so that the headers are pulled, that way you can make snap shot and make things easier and a lot cleaner
[22:56] <inuka_desk> I have been doing this for the next release not for Beta03 though
[22:56] <bryce> that's what I'm wondering as well
[22:57] <inuka_desk> you take psb-kmd and xf86-video-psb from moblin as is right?
[22:57] <bryce> what is psb-kmd?  I've never heard of it
[22:58] <inuka_desk> the poulsbo kernel driver (graphics)
[22:58] <bryce> I take -psb from moblin, but I repackage it with a different debian/ directory.
[22:58] <bryce> amit handles the kernel side of things, I assume he takes care of that
[22:59] <inuka_desk> oh ok.
[23:00] <bryce> since psb is requiring libdrm to diverge so drastically from what's in Ubuntu, it's growing less and less likely that we'd be able to port much if any of this back to ubuntu proper
[23:00] <bryce> so it looks like UME will have to have its own forked off version of these things anyway
[23:04] <inuka_desk> for now I guess I will provide with you an other patch
[23:07] <bryce> sorry if I seem frustrated; it's just the more UME's X diverges from the main Ubuntu X, the larger a time commitment it imposes on me
[23:08] <bryce> but I know it's not anyone's fault, it's just the process is driving things in this direction on its own
[23:20] <inuka_desk> understood, we are trying to clean up things on our end.... as well. its a huge web :)
[23:22] <bryce> I can imagine :-)