=== smb` is now known as smb
* apw fights hanging X after resume ...08:34
apwgive ... me ... my ... computer ... back08:34
* smb does not want it08:36
apwarn't you mean today08:37
apwppisati, moin08:44
ppisatiapw: hey08:45
apwppisati, i take it we are keeping linux-ti-omap4 in raring as well as -generic ?08:45
ppisatiapw: nope, it's going away08:45
ppisatiapw: i think rtg already wiped it08:45
smbapw, today?08:45
ppisatiapw: we copy the Q/omap4 kernel to the R archive for therelease08:45
apwit is still in raring-proposed right now08:46
apwppisati, so we will have linux-ti-omap4 in raring, just the quantal one08:46
ppisatiapw: yep08:46
apwppisati, is it binary drivers stopping us using -generic ?08:47
ppisatiapw: yes :(08:47
ppisatiapw: pvr-omap408:47
ppisatiogra_: can we have abootimg builtin by default?09:58
* henrix will be away for a while10:06
ogra_ppisati, buildin ? in phablet ?10:07
ppisatiogra_: if it would be for me, i will seed it in every arm/android images10:07
ppisatiogra_: since we need it everytime we update a kernel10:08
ogra_ppisati, +1 ... i'll talk to rsalveti once he is up to add it to the seeds10:08
ppisatiogra_: nice10:08
ogra_i'm not sure it works on all devices though10:08
ogra_i.e. i cant make it work on my galayx S2 here 10:08
ppisatiogra_: nexus4/7, it works10:08
ogra_yep, i know10:09
* ppisati has got the nexus4 kernel to work10:11
* ogra_ applauds10:11
* ppisati goes to trim the config changes10:12
psinolooking at https://lkml.org/lkml/2013/4/10/757 and https://lkml.org/lkml/2013/4/10/756, the two commits are in a "linux/kernel/git/tip/tip.git" repository, but does that mean those commits have landed in "upstream linux kernel", or are they still pending more review/verification?10:25
apwpsino, if they are in tip, they are not yet in linus' tree which is where we like them to be11:06
psinois the tip merged into linus' tree regularily?11:07
apwhenrix, bjf, sconklin, just a heads up i have fixed up the relationship between linux-ti-omap4 in quantal and raring so you should see a big jump from pending to not-affected in that column11:07
apwpsino, it is merged in the merge windows generally, so every 10 weeks or so11:07
apwpsino, well sub branches which are ready from it are merged in each merge window11:08
psinoso, as it stands now, I might have to wait up to ten weeks for those commits to make it into linus' tree, and then a ubuntu kernel build?11:09
apwpsino, that would be the implication indeed11:10
apwpsino, and to be honest as raring has forked off onto 3.8.x stable if it doesn't go there (and it is not clear it would from the commit message) then unless someone asks for it and says why it is worth carrying it won't make raring11:10
henrixapw: i believe you're referring to CVEs, right?11:12
apwhenrix, yes the cve matrix11:12
henrixapw: ack. thanks11:12
apwhenrix, bjf, sconklin, just a heads up i have fixed up the relationship between linux-ti-omap4 in quantal and raring so you should see a big jump from pending to not-affected in that column (of the CVE matrix)11:13
jwipsino: x86/urgent sounds like a branch for rc-fixes, so maybe they'll take the short route and land in 3.9 before it's released11:14
apweven if they hit 3.9 that is not going into raring any time soon11:15
psinook, so the bug manifests in kernel crashes on current 13.04 randomly when starting/stopping lxc containers. without the patch, running lxc on a kernel is pretty much like playing russian roulette with your server. it might work, but it might crash.. fedora accepted the original patch pretty much straight away, but I don't think anyone has been willing spearhead a similar approach for ubuntu (yet). as such, it would seem that my options regarding lxc11:16
psino either 1) go through the process of getting the patch into an ubuntu-specific kernel change (creating a lp-ticket etc?) or 2) build a custom kernel or 3) change to another distro which already has this patch11:16
psinoif it's not obvious I mean no offence to ubuntu or the ubuntu kernel team with the above. I'm just not very familiar with the process of getting patches into the kernel, nor building my own kernel, so it's uncharted territories for me.11:17
psinoout of these options, building a new kernel sounds like the easiest route, as changing distros has too many ripple effects through my infrastructure11:18
apwpsino, well if it is that bad i am sure the server team would be interested anyhow11:52
apwpsino, but yes, i would suggest fileing a bug with the details 'ubuntu-bug linux'11:52
apwand let me know the number so i can investigate11:52
psinoI'm pretty sure they'll ask about "have you tested the patch", so that's what I'm doing right now -- trying to build a new kernel with the patch applied11:53
jodhapw: are you still seeing bug 1103406 on your server?12:01
ubot2Launchpad bug 1103406 in linux (Ubuntu) "kernel disabled console output and keyboard lights in early boot" [High,Confirmed] https://launchpad.net/bugs/110340612:01
apwjodh, i was seeing that on one of my servers ?12:02
jodhapw: I thought so as initially it looked like an upstart issue?12:03
jodhapw: if not, can anyone offer any further thoughts on it.12:03
apwjodh, it is unclear from the last comments wehter the issue is present with current kernels12:05
apwjodh, or are you saying its broken in non-recovery and ok in recovery12:05
jodhapw: I *think* I saw it in recovery mode once or twice, but I'll do some more testing. It's certainly 99% more reliable booting in recovery than non-recovery (which is almost guaranteed to fail on the 1st attempt from cold boot).12:07
apwjodh, and fail how12:07
apwjodh, 'kernel disables console output' what does that mean12:10
jodhapw: I get no screen output - just a blank purple screen. I'm just checking if it boots far enough to get a wifi connection...12:11
jodhapw: usb serial gives no output either.12:11
apwso purple would be the handoff screen12:12
jodhapw: it hasn't booted (far enough) to get on the network and, helpfully, none of the keyboard lights work when this problem is hit either :(12:12
apwdoes editing the kernel commandline to remove vt.handoff=7 from the normal boot line, make the issue go away12:12
jodhapw: let me check...12:13
apwjodh, it is known to affect some h/w and that h/w can then be blacklisted12:13
jodhapw: it doesn't specify vt.handoff=7 at all.12:15
apwjodh, no of course it is added later ...12:15
apwthere is set gfxsomething=keep, change that to =text12:15
jodhapw: k12:15
apwshows you just how long it is since we had issues with this, that it has gone from my memory12:16
apwjodh, that said in your menu mode, it still ahngs and display has successfully been initialised12:18
ppisatimore mumble fun...12:23
* smb was surprised it lasted that long12:26
jodhapw: sorry - just updating to latest kernel - problem still persists. I only have gfxmode $linux_gfx_mode in the non-recovery kernel12:29
apwchange that to gfxmode text12:30
jodhapw: 3 successfuly boots with "text", but the 4th failed (hangs with kernel splat over my menu).12:32
apwwell kernel splat sounds useful ... piccy12:33
jodhapw: it's identical in content to the image already on the bug: https://launchpadlibrarian.net/129183769/IMG_0541.JPG12:33
jodhapw: although I've now got a lovely purple background rather than the old blue :-)12:34
apwjodh, so nothing useful then, just usb async aquirey12:35
jodhapw: it's kinda surprising that I'm the only person running raring on this h/w and seeing the problem.12:35
apwjodh, that noone but you is testing is no supprise to me12:37
apw /b 3412:38
jodhapw: ru surprised that I'm surprised it's no surprise? :)12:38
apwjodh, frankly yes :)12:39
apwwe don't need to test now, we have rolling stability guarenteed by ... erm ... testing12:39
jodhapw: would dmidecode output be of use to compare to anyone with a working macbook air maybe?12:49
apwjodh, if you know of a working macbook air ... sforshee you still ahve one ?12:58
sforsheeapw, yeah I still have an air12:59
apwsforshee, any issues booting it ?12:59
sforsheeapw, I've got raring on it, updated yesterday and no issues12:59
apwjodh, cna you point sforshee to your bug, sforshee perhaps you can compare your machine to his (which is a crashy bag of dung)13:00
sforsheeapw, there were some problems a couple of weeks ago due to efivars stuff13:00
jodhsforshee: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/110340613:01
ubot2Launchpad bug 1103406 in linux (Ubuntu) "kernel disabled console output and keyboard lights in early boot" [High,Confirmed]13:01
jodhsforshee: my system is current but booting is still highly unreliable.13:01
ppisatii think we should tackle this: http://www.theregister.co.uk/2013/04/11/dell_sputnik_review/13:03
sforsheejodh, mine is the newer model than yours. We had one of your model floating around in the company, not sure where it ended up though.13:04
sforsheealso I think bjf has that model but in the 13-inch13:04
jodhsforshee: I've added dmidecode output to the bug - could you compare with your system.13:05
jodhsforshee: fwiw, I dual boot using rEFIt.13:05
jodhsforshee: I think I pulled the short straw. Base "dung" model'n'all :)13:05
sforsheejodh, already compared. You have the 4,1 which iirc is the sandy bridge model. I have the 5,1 which is the ivy bridge.13:06
sforsheeI dual boot, but not with refit13:06
* sforshee reads the backscroll to avoid asking duplicate questions13:07
sforsheejodh, at this point I'd probably suggest a bisect13:10
rtg_ogasawara, actually, I was gonna question David on that patch. it seems over engineered to me.13:12
* rtg_ works on ALPS pull request13:12
ogasawarartg_: I thought it seemed fairly well contained and tested13:14
ogasawarartg_: it's not too late to yank it if you have reservations13:14
jodhapw: I've just found http://irclogs.ubuntu.com/2013/01/22/%23ubuntu-kernel.html#t14:17 where you seemed to be having the same issue as I'm having on the macbook.13:14
rtg_ogasawara, in that it only affects haswell. however, why not just force the D0 and mute settings rather then interrogate the HW ? less code I think.13:15
jodhsforshee: tell me there's a kexec bisect tool please!! :-)13:15
ogasawarartg_: it's a valid question, want me to punt it till we get clarification?13:17
rtg_ogasawara, if we can get ahold of him today.13:18
rtg_ogasawara, by collapsing the code into a more definitive form I might worry about audio artifacts such as pops and clicks whilst programming those registers. thats really what I'd like to confirm from him.13:20
sforsheejodh, nothing I know of, but one of us can feed you the builds if you want. jsalisbury is quite adept at running bisects.13:20
jodhsforshee: cool - thanks.13:21
apwjodh, there you say you are sure i am not having the same issue13:23
apwjodh, that issue as i recall was not dead kernel side anyhow13:23
sforsheejodh, to start you probably want to identify when the regression appeared upstream. We already have builds for all the -rc kernels at http://kernel.ubuntu.com/~kernel-ppa/mainline/13:23
sforsheejodh, what's the last ubuntu kernel version you know to work?13:25
jodhsforshee: that's a problem - I don't think any of the raring kernels I have installed work reliably - this is a test machine so I'm not using it daily.13:26
sforsheejodh, oh. Well having a known good kernel is kind of critical to running a bisect ...13:27
jodhsforshee: the quantal kernels worked fine :)13:28
sforsheejodh, quantal kernels with everything else raring?13:28
smbhenrix, congrats for making it to lwn. :)13:28
henrixsmb: hmmm? me? what have i done wrong this time?13:29
jodhsforshee: no - pure quantal install. I think the ideal would be we find someone else with the identical hardware to compare notes with.13:29
smbhenrix, Nothing, just noted that this time they acknowledged us/you doing a stable tree13:30
sforsheejodh, well like I said we've got one of those machines somewhere in the company, if we can find it. Unless that's the one you have ;-)13:30
henrixsmb: oh, ok. yeah, that was last week, wasn't it?13:30
jodhsforshee: mine is indeed a company machine :)13:31
smbhenrix, Yeah, if you have not messed up the paid subscription thing13:31
sforsheeso we found it :-)13:31
henrixsmb: yeah, i saw that last week. haven't took a look at this week yet13:32
smbhenrix, I would not know until next week :-P13:32
apwogasawara, poke me when you have pushed the propose upload to the repo, so i can get the lowlatency in sync pls13:33
* apw moves13:33
ogasawaraapw: ack13:34
sforsheejodh, well the first step to bisecting would be to find some kernel which boots fine with everything else being the same13:34
Nafallohi :-)13:57
Nafalloanyone up for building me a test-kernel with a one-line change in a certain module? ;-)13:57
Nafalloor would be willing to instruct me how I build this thing without having to build the whole kernels+flavours?13:58
* ogasawara back in 2014:02
argesNafallo: hi. https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel might be a place to start14:25
rtg_ppisati, nice job on the N414:32
ppisatirtg_: thanks14:33
* rtg_ rebuilds a SabreLite after disk failure15:05
ckingrtg has all the fun15:07
rtg_cking, the dang thing ran unattended for about 6 months.15:07
rtg_it was a good drive, SATA Seagate Momentus15:08
ogra_ogra@anubis:~$ ssh sabre15:08
ogra_ssh: connect to host sabre port 22: No route to host15:08
ogra_seems mine died too 15:09
rtg_ogra_, the rootfs is OK. I'm just having to rebuild a raring chroot that was on the external SATA15:09
ogra_i must admit i havent used mine in months ...15:10
smbrtg_, always very annoying. burnt one drive last month, too15:10
ogra_the chromebook with USB 3.0 stick is so much faster15:10
rtg_I've been doing full test builds on it15:10
ogra_yeah, me too until i got a chromebook15:11
rtg_ogra_, aren't the chromebooks kind of expensive ?15:11
ogra_$349 for the 3G model15:11
rtg_maybe if I start whining right now ogasawara will take pity on me :)15:12
ogra_and it comes with a flashplayer the chromium browser in ubuntu can happily use15:12
ogra_if we all get chromebooks it might finally make sense to roll an image for them :) 15:12
ogra_(especislly since we already have the kernel source in the distro (or at least will sonn have it) ... its identical to the nexus10)15:13
ppisatiturning of function tracing in the nexus4 kernel results in an infinite reboot loop15:21
ppisati*turning on15:22
apwppisati, heh ...15:23
ppisatiand we don't know why15:24
rtg_ogasawara, just pushed a patch for https://bugs.launchpad.net/intel/+bug/103117315:24
ubot2Launchpad bug 1031173 in intel "[Feature] Haswell ULT - SATA DEVSLP (aka LPM) host side enabling" [Undecided,New]15:24
ppisatibecause there's no srial15:24
ppisatiis it the kernel? the binary gfx driver? or what else?15:24
ogasawarartg_: ack15:25
* apw whines about the kernel partition size on the n715:29
ogra_welcome to my world 15:29
ogra_you need to cur down the initrd 15:29
ogra_apw, http://paste.ubuntu.com/5698794/15:30
ogra_(from the ac100-tarball-installer source)15:30
rtg_ogasawara, wanna have a look at git://kernel.ubuntu.com/rtg/ubuntu-raring.git dw-dma-lp1031163 ? I'll be back in a few minutes. gotta house full of family that are preparing to take off (finally).15:56
davmor2ogra_: what would be nice is a clean up script that remove all but, the shipped kernel, the current kernel and the last kernel. then there are only ever 4 kernels on the system, the first one, the one you just upgraded from, the one you just installed and one about to be deleted :) 16:00
ogra_davmor2, that doesnt help if your bootimg partition can only carry 8M in total (including the initrd) :)16:01
ogra_note we're talking about android partitioning16:01
davmor2ogra_: it would at least cut it down a bit  :)16:01
ogra_and the bootimg is a raw space on the MMC wheer you dd your kernel/initrd to and that you cant resize16:02
davmor2ogra_: ouch16:02
ogra_yeah, it would surely save space on the rootfs16:02
Nafallodavmor2: current kernel pre-ksplice? ;-)16:02
ogasawarartg_: looking now...16:12
rtg_ogasawara, they appear to be well isolated.16:15
rtg_the 2 back ports were trivial context changes16:15
ogasawarartg_: and pretty straightforward too (at least the first half I've looked at)16:15
ogasawarartg_: push it16:19
rtg_ogasawara, ack16:20
rtg_ogasawara, slapped a bow on raring master-next. gonna quick build test and upload. looks like we've got everything thats gonna make it in time.16:34
ogasawarartg_: awesome, thanks16:35
joshhunti've got a question about USN-1793-1. the way in which the usn patch is delivered seems to have deviated in this usn from the std way of doing things. https://launchpad.net/ubuntu/+source/linux/3.2.0-40.6416:49
joshhuntwe are used to received a cumulative diff to apply to a vanilla kernel, but in this case there appears to be an incremental diff to be applied to some non-vanilla base tarball16:50
joshhuntlooking at the other kernel usns released this week they are using the method i'm used to16:51
rtg_joshhunt, it should be the diff against the kernel version in the updates pocket16:51
joshhunt3.5 ex: https://launchpad.net/ubuntu/+source/linux/3.5.0-27.4616:51
Nafallortg_: hrm. I'm just testing a one-liner for a new card I picked up today. worth waiting to support a card that has been out for a few years?16:52
NafalloI've just added the pciid to the module16:52
joshhuntrtg_: so are you saying the 3.2 usn's format is correct?16:53
rtg_Nafallo, send the patch to the k-team list with supporting test documentation, etc16:53
joshhuntrtg_: if so, do you know why there is a deviation from the normal process with this usn?16:53
Nafallortg_: okay. how long do I have? :-)16:53
rtg_Nafallo, mere moments16:53
Nafallortg_: building headers+generic on a HP mini...16:53
rtg_joshhunt, perhaps we should get jjohansen involved since he does the USNs16:54
joshhuntrtg_: is there a better channel i should be asking this question?16:54
Nafallortg_: to be fair, if this works it could just go in -updates I guess :-)16:54
rtg_joshhunt, no, this is the likely the right place.16:54
joshhuntrtg_: ok cool, thanks16:54
rtg_Nafallo, yeah, its getting close to the wire. I plan to upload within the next hour or two16:55
Nafallortg_: pretty sure I'm far from there... at around   CC [M]  fs/squashfs/lzo_wrapper.o16:57
jjohansenjoshhunt: as rtg_ said the USNs aren't a cumulative diff against vanilla, they are against the kernel in the updates pocket. It just works out that they usually can also be taken and applied against vanilla16:57
Nafallortg_: so yeah, post-release update should be fine.16:58
joshhuntjjohansen: i've been pulling usns for a while and this is the first that looks like this, which is why i'm asking the question.16:58
joshhuntjjohansen: kernel usns. also the 2.6.32 and 3.5 appear to be using the old format16:58
jjohansenjoshhunt: it has happened before16:59
jjohansenjoshhunt: old format?16:59
joshhuntjjohansen: old format may be a bad way to say it, but vanilla + diff16:59
joshhuntjjohansen: it appears that 3.5 offers vanilla + diff, and also the incremental diffs17:00
* ppisati -> EOD17:00
jjohansenjoshhunt: like I said they have never been vanilla + diff, they are always done against the ubuntu kernel in updates. It just so happens that they usually work out so that they will apply against vanilla17:01
joshhuntjjohansen: maybe i'm wording it wrong, but please take a look at the 3.5 usn here: https://launchpad.net/ubuntu/+source/linux/3.5.0-27.4617:01
jjohansenjoshhunt: we pull in the majority of the updates from upstream sources against the vanilla tree and seldom have to modify them17:01
joshhuntjjohansen: under downloads there are 3 files, 3.5.0.orig.tar.gz, and a diff, along with the dsc17:02
joshhuntjjohansen: for 3.2 https://launchpad.net/ubuntu/+source/linux/3.2.0-40.64 it is different17:03
joshhuntjjohansen: i would call linux_3.5.0.orig.tar.gz a vanilla kernel and linux_3.5.0-27.46.diff.gz the diff17:03
joshhuntjjohansen: for 3.2 there's a kernel in this format: linux_3.2.0-40.64.tar.gz17:04
joshhuntjjohansen: and a dsc file17:04
rtg_jjohansen, that looks like an upload botch. sconklin ^^17:04
rtg_missed the orig tarball ?17:04
joshhuntrtg_:yes no orig tarball and no cumulative diff against orig17:05
jjohansenjoshhunt: ah got it you are looking at a packaging issue. I was totally coming at it from a how we apply the patches and dev the USN17:05
joshhuntjjohansen: ok cool. the 3.2 usn's download files are non-std compared to what i'm used to seeing. which is what i'm asking about.17:06
joshhuntjjohansen: sorry i didn't make that clear originally.17:07
rtg_joshhunt, looks like a mistake on our part. it ought to be back to normal for the next upload17:07
sconklinrtg_: weird, I have the orig present and I don't think I changed anything in how I prep. Let me do a test17:08
joshhuntrtg_: cool, will you repost the usn? or at least update the page?17:08
rtg_joshhunt, likely not. it is what it is for the present. you cannot correct these kinds of errors once upload to the archive.17:09
jjohansenjoshhunt: we could update the USN text but the upload can't be changed17:09
rtg_joshhunt, the kernel is correct. its just the packaging thats a little screwed.17:09
joshhuntrtg_: is there any way I can get the diff? this becomes a large pita for our update process17:09
rtg_joshhunt, perhaps sconklin could provide you with a diff once he figures out what went wrong with the stable process.17:10
sconklinjoshhunt: I can probably rebuild it with the diff, it just won't get uploaded that way17:10
jjohansenjoshhunt: You can pull the git tree and get either an incremental diff from the previous update or the full diff from the base kernel17:10
sconklinI'm investigating now17:11
joshhuntjjohansen: we are moving to doing git pulls, but have noticed that the diff and git tags aren't exactly the same (i think maybe it's firmware) and so i can't do that for this particular kernel ver. we've moved to git pulls for 3.517:11
joshhuntsconklin: if you can provide me a diff i'd really appreciate it17:12
sconklinjoshhunt: no problem, it'll take a few minutes17:13
rtg_sconklin, -41.65 looks like it was correctly packaged.17:14
sconklinrtg_: I think I know what happened, I need to package twice more to confirm17:14
rtg_sconklin, -40.64 is definitely hosed.17:15
rtg_joshhunt, try http://kernel.ubuntu.com/~rtg/linux_3.2.0-40.64.diff.gz17:19
sconklinrtg_: I can't reproduce the error. But the latest one I packaged is ok.17:23
rtg_sconklin, does the packaging script check for the orig tarball ?17:24
sconklinthere is no packaging script, it's just the dpgk command line. I'll check whether out post-build source package checker tests for that17:25
rtg_sconklin, that should definitely be a check somewhere in the process.17:25
sconklinrtg_: actually, we ~just~ switched to a dpgk command line that does warn you in the case of a missing orig. And it was that release that I noticed it on. But I thought that I had fixed it and uploaded the fixed package, and not the bad one.17:28
sconklinso fyi:17:28
sconklindpkg-buildpackage -S -us -uc -sa -rfakeroot -I -i -v<whatever>17:29
sconklinwill NOT stop, and the warning is buried in out put.17:29
sconklindebuild -S -I -i -uc -us -sa -v<whatever> will17:29
sconklinkamal helped me out on that 17:30
rtg_sconklin, so debuild bitches if the orig tarball is not present ?17:30
sconklinrtg yes17:30
sconklinand also runs lintian, which is a good idea17:30
rtg_interesting, I did not know that17:30
sconklinwhat you get from debuild if the orig is missing is this:17:31
sconklinThis package has a Debian revision number but there does not seem to be17:31
sconklinan appropriate original tar file or .orig directory in the parent directory;17:31
sconklin(expected one of linux_3.2.0.orig.tar.gz, linux_3.2.0.orig.tar.bz2,17:31
sconklinlinux_3.2.0.orig.tar.lzma,  linux_3.2.0.orig.tar.xz or ubuntu-precise.orig)17:31
sconklincontinue anyway? (y/n) 17:31
kamalrtg_: ... y'know how every six months or so, I start whining about "can we get an orig tarball?"   ;-)17:32
sconklinSo apparently I caught that, fixed it, and then uploaded the wrong package during the .64 cycle17:32
rtg_kamal, don't I _always_ do it as soon as you whine ?17:32
sconklinAll credit goes to kamal for educating me on this17:32
kamalrtg_: and I thank you for that!   (as does my debuild command, which no longer stops to make me type 'y')!17:32
joshhuntsconklin: i got knocked offline for a while. please ping me when you have the diff avail. i appreciate your help.17:48
rtg_joshhunt, http://kernel.ubuntu.com/~rtg/linux_3.2.0-40.64.diff.gz17:50
sconklinjoshhunt: http://people.canonical.com/~sconklin/ 17:50
sconklinheh either one17:51
joshhuntthanks guys17:51
sconklinjoshhunt: actually, use rtg's17:51
joshhunti really appreciate it17:51
sconklinMine is from this week's build17:51
* rtg_ -> lunch17:58
manjortg_, should the dkms package have a dependency on kernel headers ? seems like on raring they don't have any dependency 18:13
manjortg_, so if I install virtualbox for instance it fails to register the dkms modules coz the headers were not installed 18:14
manjortg_, seems like if you have dkms then you might need kernel headers anyways18:14
apwmanjo, nope they should not18:16
apwmanjo, as there is no way to specify the right ones ... you should have headers installed on any raring install18:17
manjoapw, should or should not ? 18:17
apwmanjo, unless you installed when there was a installer bug which deinstalled them18:17
manjokernel headers (linux-headers-3.8.0-17-generic) was not installed in my case 18:17
apwmanjo, dkms packages should not have header dependancies.  there is no way to specify correct dependancies18:17
manjoI had the same problem when I installed 11.10 as well 18:18
manjoapw, ok I see what you are saying 18:18
apwmanjo, a correctly installed system will have linux-generic or wahtever installed which installs the headers18:18
apwthis is a change for raring, and there was an early raring installer bug which removes the headers incorrectly18:18
manjoapw, but the issue still remains that I did not have kernel installed ... it might be the installer bug issue then 18:18
apwyou should have linux-image-<flavor> and linux-headers-<flavour> installed, anything else is a bug18:19
apwif you install now it should leave them installed, it was a window in early raring where they got zapped18:19
manjoapw, ok I did an upgrade on this machine from 12.10 to 13.04 yesterday 18:19
apwi am less clear what an update should do, if the headers were not installed before upgrade18:20
apwi would suggest a bug against update-manager on this so it can be investigated18:20
manjoapw, ok sound good I will open a bug 18:21
rtg_manjo, yeah, what apw said18:23
manjo:) 18:24
rtg_ogasawara, jsalisbury: bouncing gomeisa for kernel update18:48
jsalisburyrtg_, ack18:49
ogasawarartg_: ack18:51
rtg_jjohansen, kamal: rebooting tangerine for kernel update18:54
kamalrtg_: thanks18:54
tedgHey folks, I'm hearing there is no standard way to expose an ambient light sensor.19:09
tedgWhich seems a bit crazy to me.  Is that true?19:09
tedgIs there a good reason or just a "no one's bothered" reason?19:09
rtg_sforshee, ^^19:09
sforsheetedg, there's an iio driver subsystem in staging that I think targets devices like this19:12
sforsheeI've seen some android devices are using this for ALS devices19:12
tedgHmm, found an article from 2011: http://lwn.net/Articles/433601/19:13
tedgYeah, it seems to be very fractured on the Android side of things as well.19:13
sforsheewell, lot's of things are very fractured in Android :-P19:14
tedgThis looks more recent, which implies they're on the kernel schedule: http://blog.gmane.org/gmane.linux.kernel.iio19:16
sforsheetedg, iio _is_ in mainline, it's just in the staging tree right now19:16
tedgsforshee, Educate me a bit on what that means.  Does that mean it's in the ubuntu kernel?19:17
sforsheetedg, the source is there at least19:18
NafalloI don't quite get what the staging tree does either. looks like kernel-experimental :-P19:18
sforsheeoh, maybe the core isn't in staging anymore19:18
sforsheethere's a drivers/iio now19:18
sforsheetedg, raring at least has iio enabled in the kernel19:20
tedgsforshee, Ah, cool!19:22
sforsheetedg, however that doesn't necessarily mean that every ALS driver in the kernel is using it though19:22
tedgsforshee, Sure, but it means we can start to talk about it as a feature.  And handle those that don't as exceptions.19:23
tedgsforshee, I can look, but do you have a quick way to figure out if there are any that do?19:23
sforsheetedg, well there's drivers/iio/light which looks promising19:24
sforsheeand drivers/staging/iio/light19:24
* tedg is trying to figure out how to get a kernel :-)19:25
sforsheesource you mean?19:25
tedgYeah, using apt-get source now.19:26
tedgFigured for one-off that makes sense.19:26
sforsheegit clone git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git19:26
sforsheefor example19:26
tedgHa, no I'd rather use apt than have to use git :-)19:27
tedgHmm, chip numbers aren't as useful as I'd hoped.19:30
GrueMasterQuestion for one of the kernel gurus.  I need to build a custom kernel package with minor modifications, but I want this modified kernel as a separate package vs default.  I.e. -custom instead of -generic.  What's the easiest way to do this with the apt-get source linux-image-`uname -r` package?20:30
rtg_GrueMaster, there isn't an easy way to create a new flavour, but you can create a relatively unique version by appending (for example) ~grue1 to the version in debian.master/changelog20:32
rtg_an alternative is to 'make deb-pkg' which will give you a completely non-conflicting package name20:34
* rtg_ -> EOD20:35

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!