[05:35] <poelzi> ohh man. kms is so broken on my radeon
[08:56] <apw> poelzi, on what release
[08:58] <poelzi> apw: 10.10, but i'm running a vanilla kernel. 2.6.36. without kms the desktop is fast, without it's slow like hell
[08:58] <apw> not heard of that i am afraid, but .36 wasn't a release we tested
[08:59] <poelzi> 2.6.37 crashed on my 2 times so i booted back into 2.6.36.3 . i have to test if 37 with kms works
[08:59] <poelzi> both times x died and sysctl key did not work eighter except for reboot
[09:00] <poelzi> oh man. i just had to write a very dirty workarround because you can't set a pids task group id even as root :-(
[09:01] <poelzi> now i can't restart ulatencyd without loosing my grouping of processes :-((((
[09:54] <cooloney> apw: hey, andy, i am trying to fix the linux-tools package breakage for ti-omap4
[09:56] <apw> cooloney, yep, that was a the bug that there was no way to instlal the linux-tools-foo package for ti-omap4 right?
[09:56] <cooloney> apw: in debian.ti-omap4/control.stub.in
[09:56] <cooloney> apw: yeah, exactly.
[09:57] <apw> cooloney, the tools work fine if you install the linux-tools-foo package right ?
[09:57] <cooloney> apw: currentlt we got SRCPKGNAME-tools-common and SRCPKGNAME-tools-PKGVER-ABINUM in ti-omap4
[09:58] <cooloney> apw: oh, i manually install the deb package which is linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel.deb
[09:58] <cooloney> apw: SRCPKGNAME = linux-ti-omap4 is not linux
[09:59] <cooloney> apw: so i think i might need to modify that to linux-tools-common and linux-tools-PKGVER-ABINUM
[10:00] <apw> cooloney, i don't think changing those names will help
[10:00] <apw> as the issue is there is no way to ask for them whatever their name
[10:01] <apw> people expect to be able to install linux-tools to get those files for their system
[10:01] <apw> and those map normally to linux-toolss-XXX
[10:01] <apw> however the linux-tools for armel points to the ones built out of the armel architecture builds from the master branch
[10:02] <apw> i think the simplest solution is to add a linux-tools-<flavour> type meta package which points to linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel.deb
[10:02] <cooloney> right. 
[10:02] <apw> then at least one can install linux-tools-omap4 and get some tools
[10:02] <apw> and get updates automatically
[10:03] <cooloney> apw: you mean the linux-meta package?
[10:03] <apw> yes in the linux-meta-ti-omap4 package
[10:03] <apw> i can have a look at it later on if you like
[10:03] <apw> it should be pretty easy
[10:04] <cooloney> yeah, i am studying that, but failed find such linux-tools mapping in our natty linux-meta
[10:04] <cooloney> neither master nor ti-omap4
[10:05] <cooloney> so i assume it is not a issue about linux-meta
[10:05] <apw> apw@dm$ cd git2/ubuntu-natty-meta/
[10:05] <apw> apw@dm$ git grep linux-tools 
[10:05] <apw> meta-source/debian/changelog:  * Enable linux-tools on armel
[10:05] <apw> meta-source/debian/changelog:  * Add linux-tools meta package
[10:05] <apw> meta-source/debian/control.common:Package: linux-tools
[10:05] <apw> meta-source/debian/control.common:Depends: ${misc:Depends}, linux-tools-${kernel
[10:05] <apw> cooloney, it is in my linux-meta ...
[10:06] <cooloney> apw: ah, got it. let me checkout that
[10:06] <cooloney> is that public?
[10:08] <apw> cooloney, that is the contents of the public git repo ... that is the source for the meta package
[10:08] <poelzi> ohh man, having a script language to optimize kernel sheduling is really the best idea of the hole project
[10:09] <cking> wish I knew what that meant
[10:09] <poelzi> https://github.com/poelzi/ulatencyd/
[10:11] <apw> every time someone has tried to implement a core key function partly in userspace it has had severe corner cases issues particularly when there is insufficient cpu to run the userspace scheduler
[10:12] <poelzi> apw: it is not a scheduler
[10:12] <poelzi> it is a scheduler optimizer, that is something completly different
[10:12] <apw> "Ulatency is a daemon that controls how the Linux kernel will spend it's
[10:12] <apw> resources on the running processes."
[10:13] <poelzi> yes. 
[10:13] <apw> where i come from that is the definition of the role of a scheduler
[10:13] <cooloney> apw: is this one: git://kernel.ubuntu.com/ubuntu/ubuntu-natty-meta.git
[10:13] <apw> cooloney, that is the one for the master branch yes
[10:13] <apw> you need to change the one for your branch
[10:13] <cooloney> apw: thanks a lot, my bad, i always grepping in the ti-omap4 branch
[10:14] <apw> you need to change the ti-omap4 branch one
[10:14] <apw> to include a linux-tools-<flavour> package similar to that one
[10:14] <cooloney> ok, i will try to provide a patch to ti-omap4,
[10:14] <poelzi> apw: i do not schedule, but i "constantly" optimize the parameters of the kernel scheduler. so, the sentence is true
[10:14] <cooloney> got it
[10:14] <cooloney> thx
[10:14] <apw> poelzi, that makes it a scheduler component, part of the scheduler
[10:15] <apw> and if it is necessary to run something to change the way things run, you are in a risky spot for corner cases under load
[10:15] <poelzi> not exactly i would say. the scheduler will never ever wait on the optimizer for a result of some sort. but the optimizer uses the interfaces of the scheduler to adjust him
[10:16] <poelzi> apw: i do work hard on the corner cases. man i fixed the swap of death with it
[10:16] <cooloney> apw: need i post the patch back to maverick?
[10:17] <apw> cooloney, do we really care about maverick for that kernel?
[10:17] <poelzi> and optimization should never be done in kernel, to much heuristics involved
[10:19] <cooloney> apw: yeah, some users are still trying to use linux-tools in ti-omap4 maverick, i believe
[10:22] <apw> cooloney, we have some h/w they can install maverick on somewhere in the world?
[10:23] <cooloney> apw: sure, Panda board is our Maverick release targeting HW.
[10:24] <apw> cooloney, well the rules state, update natty then SRU previous releases
[10:24] <cooloney> apw: got it.
[10:25] <cooloney> apw: about this?
[10:25] <cooloney> Package: linux-tools-ti-omap4
[10:25] <cooloney> Architecture: armel
[10:25] <cooloney> Section: metapackages
[10:25] <cooloney> Depends: ${misc:Depends}, linux-ti-omap4-tools-${kernel-abi-version}
[10:25] <cooloney> Description: Linux kernel versioned Tools This package will always depend on the latest Linux kernel versioned tools available. The Ubuntu patches have been applied.
[10:32] <cking> apw, gpes + SCI: http://zinc.canonical.com/~cking/presentations/gpes-and-embedded-controller/EmbeddedControllerAndACPI.odp
[10:33] <apw> cooloney, i suspect its either linux-ti-omap4-tools, or its linux-tools-omap4 (assuming the installed flavour is omap4)
[10:33] <apw> generally things on the right hand end are flavour names, and things on the left end are source package names
[11:14] <cooloney> apw: thx, sorry for the delay, i think linux-tools-omap4 is right
[11:15] <apw> cooloney, i think i do to, then we can consider making that the norm for all flavour
[11:16] <cooloney> ls
[11:16] <cooloney> apw: i found the deb file name is linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel.deb 
[11:16] <cooloney> is that right?
[11:17] <apw> the name in the binary seems right yes, as its architecture specific for that branch, ie not flavour specific
[11:17] <apw> but i think the right thing is to make the name flavour specific
[11:17] <apw> just in case it does become flavour specific
[11:18] <cooloney> it's supposed to be linux-ti-omap4-tools-2.6.35-1101_armel.deb
[11:19] <apw> the tools are version specific so the binary name should be linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel.deb
[11:19] <cooloney> SRCPKGNAME-tools-PKGVER-ABINUM = linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel ?
[11:19] <apw> yes
[11:20] <apw> well no, its the first bit, linux-ti-omap4-tools-2.6.35-1101, the bit after the _ is the version of the package from changelog the next bit after _ is the architecture
[11:20] <apw> in the dev
[11:20] <apw> so to link to the contents of the deb _filename_ linux-ti-omap4-tools-2.6.35-1101_2.6.35-1101.4_armel.deb you link to a package called  linux-ti-omap4-tools-2.6.35-1101
[11:22] <cooloney> oh, yeah, linux-ti-omap4-tools-2.6.35-1101 = linux-ti-omap4-tools-${kernel-abi-version} = SRCPKGNAME-tools-PKGVER-ABINUM
[14:33] <shadeslayer> could someone look at bug 702341 ?
[14:33] <ubot2> Launchpad bug 702341 in xserver-xorg-input-synaptics (Ubuntu) "synaptics touchpad does not work (affects: 1) (heat: 416)" [Undecided,New] https://launchpad.net/bugs/702341
[14:34] <shadeslayer> or would this be a #ubuntu-x issue?
[15:40] <tgardner> sconklin, I'm gonna re-upload Hardy LUM to see if I can figure out the lpia build failure. It won't rebuild because it was pocket copied from the c-k-t PPA, and the original package has since been deleted.
[15:41] <sconklin> tgardner: ack
[15:41] <tgardner> I'll just bump the upload number
[15:41] <sconklin> tgardner: there's special magic required to upload to the new ppa
[15:42] <tgardner> Has it changed? I'vev uploaded to c-k-t before
[15:42] <sconklin> https://wiki.ubuntu.com/Kernel/StableReleaseCadence
[15:42] <sconklin> bottom of that page
[15:42] <tgardner> sconklin, yep, I grok that
[15:42] <sconklin> ok
[15:43] <sconklin> I think SteveK said that there's another way to do it, but this works
[15:44] <tgardner> sconklin, yeah, once I have the magic runes correct, I don't really care what they are
[16:09] <JFo> <- food
[16:26] <tgardner> sconklin, bjf : did the c-k-t PPA armel build issues get sorted? we need to remember to revert the meta package carnage if so.
[16:27] <sconklin> tgardner: when we reupload packages tomorrow or monday, the armel builds should complete, then we'll fix the metas
[16:28] <sconklin> Need a complete LSI-11/2 system? http://huntsville.craigslist.org/zip/2167211100.html
[16:41] <tgardner> sconklin, bjf : the no-change Hardy LUM upload appears to have built on lpia this time. I guess it was just a transient failure
[16:52] <bjf> tgardner, good
[16:52] <cking> apw, http://freeworld.thc.org/root/phun/unmaintain.html
[17:21] <jjohansen> so sconklin: basically this is bug#683743 and the best way currently is indeed adding a rule to the profile file, the plan is to add a directory where application can drop their own rule bits, that would automatically get included without modifying the profile but its not done yet
[17:21] <sconklin> ok, thanks. I'll pass that on
[17:34] <tgardner> sconklin, bjf : Hardy LUM has successfully rebuilt. Who does the security pocket copies ?
[17:34] <bjf> tgardner, i usually ping kees
[18:33] <bigon> hi, I'm trying to boot the natty installer (daily build), but it seems that the kernel freeze (back screen just after grub) an idea?
[18:33] <bigon> booting on a machine with uefi mode
[20:04] <LetoThe2nd> hello! i have a board here on which ubuntu names all connected usb memories starting with sda, and puts in the sata stuff afterwards from sdf or sdg, depending on how much is connected. is there a way around this?
[20:05] <LetoThe2nd> (cpu: phenom ii x6, chipset ati sb800
[20:07] <BenC> There probably is, but the best thing is to not use the dynamic naming...use the uuid device nodes for example
[20:08] <LetoThe2nd> yeah, but thats more like a workaroung to me...
[20:16]  * jjohansen -> lunch
[20:18] <sforshee> smb, you there?
[20:19] <cking> sforshee, it's probably bit late for smb now
[20:20] <cking> way past beer time :-)
[20:20] <sforshee> yeah, i figured, but he's still logged in so I thought I'd check
[22:42] <bryceh> has anyone packaged 2.6.38-rc1 any place so far?  Intel is demurring about looking at our X bugs unless confirmed against the newest upstream gunk.
[22:44] <bjf> bryceh, yes, it's been built but last i heard was borked quite badly
[22:44] <bryceh> bjf, ah ok
[22:44] <bryceh> I will tell them so
[22:44] <RAOF> I saw apw complaining that it didn't boot on any of his 32bit machines, at least.
[22:51] <RAOF> LetoThe2nd: No, a work-around is to try to wrangle a stable naming out of the inherently unstable dynamic naming scheme :)  The UUID *is* the stable naming scheme, so it's what you should use if you need stable naming.
[22:55] <ohsix> mjg59: what am i looking at if gnome-power-manager tends not to know the backlight level, but it often changes appropriately (showing ui from the hard buttons and stuff)