| === smb` is now known as smb | ||
| * apw fights hanging X after resume ... | 08:34 | |
| apw | give ... me ... my ... computer ... back | 08:34 |
|---|---|---|
| * smb does not want it | 08:36 | |
| apw | arn't you mean today | 08:37 |
| apw | ppisati, moin | 08:44 |
| ppisati | apw: hey | 08:45 |
| apw | ppisati, i take it we are keeping linux-ti-omap4 in raring as well as -generic ? | 08:45 |
| ppisati | apw: nope, it's going away | 08:45 |
| ppisati | apw: i think rtg already wiped it | 08:45 |
| smb | apw, today? | 08:45 |
| ppisati | apw: we copy the Q/omap4 kernel to the R archive for therelease | 08:45 |
| apw | it is still in raring-proposed right now | 08:46 |
| apw | ppisati, so we will have linux-ti-omap4 in raring, just the quantal one | 08:46 |
| ppisati | apw: yep | 08:46 |
| apw | ppisati, is it binary drivers stopping us using -generic ? | 08:47 |
| ppisati | apw: yes :( | 08:47 |
| ppisati | apw: pvr-omap4 | 08:47 |
| ppisati | ogra_: can we have abootimg builtin by default? | 09:58 |
| * henrix will be away for a while | 10:06 | |
| ogra_ | ppisati, buildin ? in phablet ? | 10:07 |
| ppisati | ogra_: if it would be for me, i will seed it in every arm/android images | 10:07 |
| ppisati | ogra_: since we need it everytime we update a kernel | 10:08 |
| ogra_ | ppisati, +1 ... i'll talk to rsalveti once he is up to add it to the seeds | 10:08 |
| ppisati | ogra_: nice | 10:08 |
| ogra_ | i'm not sure it works on all devices though | 10:08 |
| ogra_ | i.e. i cant make it work on my galayx S2 here | 10:08 |
| ppisati | ogra_: nexus4/7, it works | 10:08 |
| ogra_ | yep, i know | 10:09 |
| * ppisati has got the nexus4 kernel to work | 10:11 | |
| ppisati | allelujah | 10:11 |
| * ogra_ applauds | 10:11 | |
| * ppisati goes to trim the config changes | 10:12 | |
| psino | looking 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 |
| apw | psino, if they are in tip, they are not yet in linus' tree which is where we like them to be | 11:06 |
| psino | is the tip merged into linus' tree regularily? | 11:07 |
| apw | henrix, 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 | 11:07 |
| apw | psino, it is merged in the merge windows generally, so every 10 weeks or so | 11:07 |
| apw | psino, well sub branches which are ready from it are merged in each merge window | 11:08 |
| psino | so, 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 |
| apw | psino, that would be the implication indeed | 11:10 |
| apw | psino, 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 raring | 11:10 |
| henrix | apw: i believe you're referring to CVEs, right? | 11:12 |
| apw | henrix, yes the cve matrix | 11:12 |
| henrix | apw: ack. thanks | 11:12 |
| apw | henrix, 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 |
| apw | better | 11:13 |
| henrix | heh | 11:13 |
| jwi | psino: 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 released | 11:14 |
| apw | even if they hit 3.9 that is not going into raring any time soon | 11:15 |
| psino | ok, 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 lxc | 11: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 patch | 11:16 |
| psino | if 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 |
| psino | out of these options, building a new kernel sounds like the easiest route, as changing distros has too many ripple effects through my infrastructure | 11:18 |
| apw | psino, well if it is that bad i am sure the server team would be interested anyhow | 11:52 |
| apw | psino, but yes, i would suggest fileing a bug with the details 'ubuntu-bug linux' | 11:52 |
| apw | and let me know the number so i can investigate | 11:52 |
| psino | I'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 applied | 11:53 |
| jodh | apw: are you still seeing bug 1103406 on your server? | 12:01 |
| ubot2 | Launchpad bug 1103406 in linux (Ubuntu) "kernel disabled console output and keyboard lights in early boot" [High,Confirmed] https://launchpad.net/bugs/1103406 | 12:01 |
| apw | jodh, i was seeing that on one of my servers ? | 12:02 |
| jodh | apw: I thought so as initially it looked like an upstart issue? | 12:03 |
| jodh | apw: if not, can anyone offer any further thoughts on it. | 12:03 |
| apw | jodh, it is unclear from the last comments wehter the issue is present with current kernels | 12:05 |
| apw | jodh, or are you saying its broken in non-recovery and ok in recovery | 12:05 |
| jodh | apw: 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 |
| apw | jodh, and fail how | 12:07 |
| apw | jodh, 'kernel disables console output' what does that mean | 12:10 |
| jodh | apw: 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 |
| jodh | apw: usb serial gives no output either. | 12:11 |
| apw | so purple would be the handoff screen | 12:12 |
| jodh | apw: 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 |
| apw | does editing the kernel commandline to remove vt.handoff=7 from the normal boot line, make the issue go away | 12:12 |
| jodh | apw: let me check... | 12:13 |
| apw | jodh, it is known to affect some h/w and that h/w can then be blacklisted | 12:13 |
| jodh | apw: it doesn't specify vt.handoff=7 at all. | 12:15 |
| apw | jodh, no of course it is added later ... | 12:15 |
| apw | there is set gfxsomething=keep, change that to =text | 12:15 |
| jodh | apw: k | 12:15 |
| apw | shows you just how long it is since we had issues with this, that it has gone from my memory | 12:16 |
| apw | jodh, that said in your menu mode, it still ahngs and display has successfully been initialised | 12:18 |
| ppisati | more mumble fun... | 12:23 |
| * smb was surprised it lasted that long | 12:26 | |
| jodh | apw: sorry - just updating to latest kernel - problem still persists. I only have gfxmode $linux_gfx_mode in the non-recovery kernel | 12:29 |
| apw | change that to gfxmode text | 12:30 |
| jodh | apw: 3 successfuly boots with "text", but the 4th failed (hangs with kernel splat over my menu). | 12:32 |
| apw | well kernel splat sounds useful ... piccy | 12:33 |
| jodh | apw: it's identical in content to the image already on the bug: https://launchpadlibrarian.net/129183769/IMG_0541.JPG | 12:33 |
| jodh | apw: although I've now got a lovely purple background rather than the old blue :-) | 12:34 |
| apw | jodh, so nothing useful then, just usb async aquirey | 12:35 |
| jodh | apw: it's kinda surprising that I'm the only person running raring on this h/w and seeing the problem. | 12:35 |
| apw | jodh, that noone but you is testing is no supprise to me | 12:37 |
| apw | /b 34 | 12:38 |
| jodh | apw: ru surprised that I'm surprised it's no surprise? :) | 12:38 |
| apw | jodh, frankly yes :) | 12:39 |
| apw | we don't need to test now, we have rolling stability guarenteed by ... erm ... testing | 12:39 |
| jodh | apw: would dmidecode output be of use to compare to anyone with a working macbook air maybe? | 12:49 |
| apw | jodh, if you know of a working macbook air ... sforshee you still ahve one ? | 12:58 |
| sforshee | apw, yeah I still have an air | 12:59 |
| apw | sforshee, any issues booting it ? | 12:59 |
| sforshee | apw, I've got raring on it, updated yesterday and no issues | 12:59 |
| apw | jodh, 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 |
| sforshee | apw, there were some problems a couple of weeks ago due to efivars stuff | 13:00 |
| jodh | sforshee: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1103406 | 13:01 |
| ubot2 | Launchpad bug 1103406 in linux (Ubuntu) "kernel disabled console output and keyboard lights in early boot" [High,Confirmed] | 13:01 |
| jodh | sforshee: my system is current but booting is still highly unreliable. | 13:01 |
| ppisati | i think we should tackle this: http://www.theregister.co.uk/2013/04/11/dell_sputnik_review/ | 13:03 |
| sforshee | jodh, 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 |
| sforshee | also I think bjf has that model but in the 13-inch | 13:04 |
| jodh | sforshee: I've added dmidecode output to the bug - could you compare with your system. | 13:05 |
| jodh | sforshee: fwiw, I dual boot using rEFIt. | 13:05 |
| jodh | sforshee: I think I pulled the short straw. Base "dung" model'n'all :) | 13:05 |
| sforshee | jodh, 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 |
| sforshee | I dual boot, but not with refit | 13:06 |
| * sforshee reads the backscroll to avoid asking duplicate questions | 13:07 | |
| sforshee | jodh, at this point I'd probably suggest a bisect | 13: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 request | 13:12 | |
| ogasawara | rtg_: I thought it seemed fairly well contained and tested | 13:14 |
| ogasawara | rtg_: it's not too late to yank it if you have reservations | 13:14 |
| jodh | apw: 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 |
| jodh | sforshee: tell me there's a kexec bisect tool please!! :-) | 13:15 |
| ogasawara | rtg_: 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 |
| sforshee | jodh, 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 |
| jodh | sforshee: cool - thanks. | 13:21 |
| apw | jodh, there you say you are sure i am not having the same issue | 13:23 |
| apw | jodh, that issue as i recall was not dead kernel side anyhow | 13:23 |
| sforshee | jodh, 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 |
| sforshee | jodh, what's the last ubuntu kernel version you know to work? | 13:25 |
| jodh | sforshee: 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 |
| sforshee | jodh, oh. Well having a known good kernel is kind of critical to running a bisect ... | 13:27 |
| jodh | sforshee: the quantal kernels worked fine :) | 13:28 |
| sforshee | jodh, quantal kernels with everything else raring? | 13:28 |
| smb | henrix, congrats for making it to lwn. :) | 13:28 |
| henrix | smb: hmmm? me? what have i done wrong this time? | 13:29 |
| henrix | :) | 13:29 |
| jodh | sforshee: no - pure quantal install. I think the ideal would be we find someone else with the identical hardware to compare notes with. | 13:29 |
| smb | henrix, Nothing, just noted that this time they acknowledged us/you doing a stable tree | 13:30 |
| sforshee | jodh, 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 |
| henrix | smb: oh, ok. yeah, that was last week, wasn't it? | 13:30 |
| jodh | sforshee: mine is indeed a company machine :) | 13:31 |
| smb | henrix, Yeah, if you have not messed up the paid subscription thing | 13:31 |
| sforshee | ah | 13:31 |
| sforshee | so we found it :-) | 13:31 |
| henrix | smb: yeah, i saw that last week. haven't took a look at this week yet | 13:32 |
| smb | henrix, I would not know until next week :-P | 13:32 |
| apw | ogasawara, poke me when you have pushed the propose upload to the repo, so i can get the lowlatency in sync pls | 13:33 |
| * apw moves | 13:33 | |
| ogasawara | apw: ack | 13:34 |
| sforshee | jodh, well the first step to bisecting would be to find some kernel which boots fine with everything else being the same | 13:34 |
| Nafallo | hi :-) | 13:57 |
| Nafallo | anyone up for building me a test-kernel with a one-line change in a certain module? ;-) | 13:57 |
| Nafallo | or would be willing to instruct me how I build this thing without having to build the whole kernels+flavours? | 13:58 |
| * ogasawara back in 20 | 14:02 | |
| arges | Nafallo: hi. https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel might be a place to start | 14:25 |
| rtg_ | ppisati, nice job on the N4 | 14:32 |
| ppisati | rtg_: thanks | 14:33 |
| * rtg_ rebuilds a SabreLite after disk failure | 15:05 | |
| cking | rtg has all the fun | 15:07 |
| rtg_ | cking, the dang thing ran unattended for about 6 months. | 15:07 |
| ogra_ | hmm | 15:07 |
| rtg_ | it was a good drive, SATA Seagate Momentus | 15:08 |
| ogra_ | ogra@anubis:~$ ssh sabre | 15:08 |
| ogra_ | ssh: connect to host sabre port 22: No route to host | 15:08 |
| ogra_ | *sniff* | 15: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 SATA | 15:09 |
| ogra_ | i must admit i havent used mine in months ... | 15:10 |
| smb | rtg_, always very annoying. burnt one drive last month, too | 15:10 |
| ogra_ | the chromebook with USB 3.0 stick is so much faster | 15:10 |
| rtg_ | I've been doing full test builds on it | 15:10 |
| ogra_ | yeah, me too until i got a chromebook | 15:11 |
| rtg_ | ogra_, aren't the chromebooks kind of expensive ? | 15:11 |
| ogra_ | $299 | 15:11 |
| rtg_ | hmmm... | 15:11 |
| ogra_ | $349 for the 3G model | 15: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 use | 15: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 |
| ppisati | *lol* | 15:21 |
| ppisati | turning of function tracing in the nexus4 kernel results in an infinite reboot loop | 15:21 |
| ppisati | *turning on | 15:22 |
| apw | ppisati, heh ... | 15:23 |
| ppisati | and we don't know why | 15:24 |
| rtg_ | ogasawara, just pushed a patch for https://bugs.launchpad.net/intel/+bug/1031173 | 15:24 |
| ubot2 | Launchpad bug 1031173 in intel "[Feature] Haswell ULT - SATA DEVSLP (aka LPM) host side enabling" [Undecided,New] | 15:24 |
| ppisati | because there's no srial | 15:24 |
| ppisati | is it the kernel? the binary gfx driver? or what else? | 15:24 |
| ogasawara | rtg_: ack | 15:25 |
| * apw whines about the kernel partition size on the n7 | 15:29 | |
| ogra_ | haha | 15: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 |
| ogra_ | s/cur/cut/ | 15:31 |
| 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 |
| davmor2 | ogra_: 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 partitioning | 16:01 |
| davmor2 | ogra_: 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 resize | 16:02 |
| davmor2 | ogra_: ouch | 16:02 |
| ogra_ | yeah, it would surely save space on the rootfs | 16:02 |
| Nafallo | davmor2: current kernel pre-ksplice? ;-) | 16:02 |
| ogasawara | rtg_: looking now... | 16:12 |
| rtg_ | ogasawara, they appear to be well isolated. | 16:15 |
| rtg_ | the 2 back ports were trivial context changes | 16:15 |
| ogasawara | rtg_: and pretty straightforward too (at least the first half I've looked at) | 16:15 |
| ogasawara | rtg_: push it | 16:19 |
| rtg_ | ogasawara, ack | 16:20 |
| ppisati | brb | 16:23 |
| 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 |
| ogasawara | rtg_: awesome, thanks | 16:35 |
| joshhunt | i'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.64 | 16:49 |
| joshhunt | we 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 tarball | 16:50 |
| joshhunt | looking at the other kernel usns released this week they are using the method i'm used to | 16:51 |
| rtg_ | joshhunt, it should be the diff against the kernel version in the updates pocket | 16:51 |
| joshhunt | 3.5 ex: https://launchpad.net/ubuntu/+source/linux/3.5.0-27.46 | 16:51 |
| Nafallo | rtg_: 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 |
| Nafallo | I've just added the pciid to the module | 16:52 |
| joshhunt | rtg_: 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, etc | 16:53 |
| joshhunt | rtg_: if so, do you know why there is a deviation from the normal process with this usn? | 16:53 |
| Nafallo | rtg_: okay. how long do I have? :-) | 16:53 |
| rtg_ | Nafallo, mere moments | 16:53 |
| Nafallo | rtg_: building headers+generic on a HP mini... | 16:53 |
| rtg_ | joshhunt, perhaps we should get jjohansen involved since he does the USNs | 16:54 |
| joshhunt | rtg_: is there a better channel i should be asking this question? | 16:54 |
| Nafallo | rtg_: 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 |
| joshhunt | rtg_: ok cool, thanks | 16:54 |
| rtg_ | Nafallo, yeah, its getting close to the wire. I plan to upload within the next hour or two | 16:55 |
| Nafallo | rtg_: pretty sure I'm far from there... at around CC [M] fs/squashfs/lzo_wrapper.o | 16:57 |
| jjohansen | joshhunt: 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 vanilla | 16:57 |
| Nafallo | rtg_: so yeah, post-release update should be fine. | 16:58 |
| joshhunt | jjohansen: 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 |
| joshhunt | jjohansen: kernel usns. also the 2.6.32 and 3.5 appear to be using the old format | 16:58 |
| jjohansen | joshhunt: it has happened before | 16:59 |
| jjohansen | joshhunt: old format? | 16:59 |
| joshhunt | jjohansen: old format may be a bad way to say it, but vanilla + diff | 16:59 |
| joshhunt | jjohansen: it appears that 3.5 offers vanilla + diff, and also the incremental diffs | 17:00 |
| * ppisati -> EOD | 17:00 | |
| jjohansen | joshhunt: 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 vanilla | 17:01 |
| joshhunt | jjohansen: 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.46 | 17:01 |
| jjohansen | joshhunt: we pull in the majority of the updates from upstream sources against the vanilla tree and seldom have to modify them | 17:01 |
| joshhunt | jjohansen: under downloads there are 3 files, 3.5.0.orig.tar.gz, and a diff, along with the dsc | 17:02 |
| joshhunt | jjohansen: for 3.2 https://launchpad.net/ubuntu/+source/linux/3.2.0-40.64 it is different | 17:03 |
| joshhunt | jjohansen: i would call linux_3.5.0.orig.tar.gz a vanilla kernel and linux_3.5.0-27.46.diff.gz the diff | 17:03 |
| joshhunt | jjohansen: for 3.2 there's a kernel in this format: linux_3.2.0-40.64.tar.gz | 17:04 |
| joshhunt | jjohansen: and a dsc file | 17:04 |
| rtg_ | jjohansen, that looks like an upload botch. sconklin ^^ | 17:04 |
| rtg_ | missed the orig tarball ? | 17:04 |
| joshhunt | rtg_:yes no orig tarball and no cumulative diff against orig | 17:05 |
| sconklin | looking | 17:05 |
| jjohansen | joshhunt: 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 USN | 17:05 |
| joshhunt | jjohansen: 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 |
| joshhunt | jjohansen: 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 upload | 17:07 |
| sconklin | rtg_: weird, I have the orig present and I don't think I changed anything in how I prep. Let me do a test | 17:08 |
| joshhunt | rtg_: 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 |
| jjohansen | joshhunt: we could update the USN text but the upload can't be changed | 17:09 |
| rtg_ | joshhunt, the kernel is correct. its just the packaging thats a little screwed. | 17:09 |
| joshhunt | rtg_: is there any way I can get the diff? this becomes a large pita for our update process | 17:09 |
| rtg_ | joshhunt, perhaps sconklin could provide you with a diff once he figures out what went wrong with the stable process. | 17:10 |
| sconklin | joshhunt: I can probably rebuild it with the diff, it just won't get uploaded that way | 17:10 |
| jjohansen | joshhunt: You can pull the git tree and get either an incremental diff from the previous update or the full diff from the base kernel | 17:10 |
| sconklin | I'm investigating now | 17:11 |
| joshhunt | jjohansen: 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.5 | 17:11 |
| joshhunt | sconklin: if you can provide me a diff i'd really appreciate it | 17:12 |
| sconklin | joshhunt: no problem, it'll take a few minutes | 17:13 |
| rtg_ | sconklin, -41.65 looks like it was correctly packaged. | 17:14 |
| sconklin | rtg_: I think I know what happened, I need to package twice more to confirm | 17: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.gz | 17:19 |
| sconklin | rtg_: 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 |
| sconklin | there is no packaging script, it's just the dpgk command line. I'll check whether out post-build source package checker tests for that | 17:25 |
| rtg_ | sconklin, that should definitely be a check somewhere in the process. | 17:25 |
| sconklin | rtg_: 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 |
| sconklin | so fyi: | 17:28 |
| sconklin | dpkg-buildpackage -S -us -uc -sa -rfakeroot -I -i -v<whatever> | 17:29 |
| sconklin | will NOT stop, and the warning is buried in out put. | 17:29 |
| sconklin | but: | 17:29 |
| sconklin | debuild -S -I -i -uc -us -sa -v<whatever> will | 17:29 |
| sconklin | kamal helped me out on that | 17:30 |
| rtg_ | sconklin, so debuild bitches if the orig tarball is not present ? | 17:30 |
| sconklin | rtg yes | 17:30 |
| sconklin | and also runs lintian, which is a good idea | 17:30 |
| rtg_ | interesting, I did not know that | 17:30 |
| sconklin | what you get from debuild if the orig is missing is this: | 17:31 |
| sconklin | This package has a Debian revision number but there does not seem to be | 17:31 |
| sconklin | an 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 |
| sconklin | linux_3.2.0.orig.tar.lzma, linux_3.2.0.orig.tar.xz or ubuntu-precise.orig) | 17:31 |
| sconklin | continue anyway? (y/n) | 17:31 |
| kamal | rtg_: ... y'know how every six months or so, I start whining about "can we get an orig tarball?" ;-) | 17:32 |
| sconklin | So apparently I caught that, fixed it, and then uploaded the wrong package during the .64 cycle | 17:32 |
| rtg_ | kamal, don't I _always_ do it as soon as you whine ? | 17:32 |
| sconklin | All credit goes to kamal for educating me on this | 17:32 |
| kamal | rtg_: and I thank you for that! (as does my debuild command, which no longer stops to make me type 'y')! | 17:32 |
| joshhunt | sconklin: 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.gz | 17:50 |
| sconklin | joshhunt: http://people.canonical.com/~sconklin/ | 17:50 |
| sconklin | heh either one | 17:51 |
| joshhunt | thanks guys | 17:51 |
| sconklin | joshhunt: actually, use rtg's | 17:51 |
| joshhunt | i really appreciate it | 17:51 |
| joshhunt | sure | 17:51 |
| sconklin | Mine is from this week's build | 17:51 |
| * rtg_ -> lunch | 17:58 | |
| manjo | rtg_, should the dkms package have a dependency on kernel headers ? seems like on raring they don't have any dependency | 18:13 |
| manjo | rtg_, so if I install virtualbox for instance it fails to register the dkms modules coz the headers were not installed | 18:14 |
| manjo | rtg_, seems like if you have dkms then you might need kernel headers anyways | 18:14 |
| apw | manjo, nope they should not | 18:16 |
| apw | manjo, as there is no way to specify the right ones ... you should have headers installed on any raring install | 18:17 |
| manjo | apw, should or should not ? | 18:17 |
| apw | manjo, unless you installed when there was a installer bug which deinstalled them | 18:17 |
| manjo | kernel headers (linux-headers-3.8.0-17-generic) was not installed in my case | 18:17 |
| apw | manjo, dkms packages should not have header dependancies. there is no way to specify correct dependancies | 18:17 |
| manjo | I had the same problem when I installed 11.10 as well | 18:18 |
| manjo | apw, ok I see what you are saying | 18:18 |
| apw | manjo, a correctly installed system will have linux-generic or wahtever installed which installs the headers | 18:18 |
| apw | this is a change for raring, and there was an early raring installer bug which removes the headers incorrectly | 18:18 |
| manjo | apw, but the issue still remains that I did not have kernel installed ... it might be the installer bug issue then | 18:18 |
| apw | you should have linux-image-<flavor> and linux-headers-<flavour> installed, anything else is a bug | 18:19 |
| apw | if you install now it should leave them installed, it was a window in early raring where they got zapped | 18:19 |
| manjo | apw, ok I did an upgrade on this machine from 12.10 to 13.04 yesterday | 18:19 |
| apw | i am less clear what an update should do, if the headers were not installed before upgrade | 18:20 |
| apw | i would suggest a bug against update-manager on this so it can be investigated | 18:20 |
| manjo | apw, ok sound good I will open a bug | 18:21 |
| rtg_ | manjo, yeah, what apw said | 18:23 |
| manjo | :) | 18:24 |
| rtg_ | ogasawara, jsalisbury: bouncing gomeisa for kernel update | 18:48 |
| jsalisbury | rtg_, ack | 18:49 |
| ogasawara | rtg_: ack | 18:51 |
| rtg_ | jjohansen, kamal: rebooting tangerine for kernel update | 18:54 |
| kamal | rtg_: thanks | 18:54 |
| tedg | Hey folks, I'm hearing there is no standard way to expose an ambient light sensor. | 19:09 |
| tedg | Which seems a bit crazy to me. Is that true? | 19:09 |
| tedg | Is there a good reason or just a "no one's bothered" reason? | 19:09 |
| rtg_ | sforshee, ^^ | 19:09 |
| sforshee | tedg, there's an iio driver subsystem in staging that I think targets devices like this | 19:12 |
| sforshee | I've seen some android devices are using this for ALS devices | 19:12 |
| tedg | Hmm, found an article from 2011: http://lwn.net/Articles/433601/ | 19:13 |
| tedg | Yeah, it seems to be very fractured on the Android side of things as well. | 19:13 |
| sforshee | well, lot's of things are very fractured in Android :-P | 19:14 |
| tedg | This looks more recent, which implies they're on the kernel schedule: http://blog.gmane.org/gmane.linux.kernel.iio | 19:16 |
| sforshee | tedg, iio _is_ in mainline, it's just in the staging tree right now | 19:16 |
| tedg | sforshee, Educate me a bit on what that means. Does that mean it's in the ubuntu kernel? | 19:17 |
| sforshee | tedg, the source is there at least | 19:18 |
| Nafallo | I don't quite get what the staging tree does either. looks like kernel-experimental :-P | 19:18 |
| sforshee | oh, maybe the core isn't in staging anymore | 19:18 |
| sforshee | there's a drivers/iio now | 19:18 |
| sforshee | tedg, raring at least has iio enabled in the kernel | 19:20 |
| tedg | sforshee, Ah, cool! | 19:22 |
| sforshee | tedg, however that doesn't necessarily mean that every ALS driver in the kernel is using it though | 19:22 |
| tedg | sforshee, Sure, but it means we can start to talk about it as a feature. And handle those that don't as exceptions. | 19:23 |
| tedg | sforshee, I can look, but do you have a quick way to figure out if there are any that do? | 19:23 |
| sforshee | tedg, well there's drivers/iio/light which looks promising | 19:24 |
| sforshee | and drivers/staging/iio/light | 19:24 |
| * tedg is trying to figure out how to get a kernel :-) | 19:25 | |
| sforshee | source you mean? | 19:25 |
| tedg | Yeah, using apt-get source now. | 19:26 |
| tedg | Figured for one-off that makes sense. | 19:26 |
| sforshee | git clone git://kernel.ubuntu.com/ubuntu/ubuntu-raring.git | 19:26 |
| sforshee | for example | 19:26 |
| tedg | Ha, no I'd rather use apt than have to use git :-) | 19:27 |
| tedg | Hmm, chip numbers aren't as useful as I'd hoped. | 19:30 |
| GrueMaster | Question 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/changelog | 20:32 |
| rtg_ | an alternative is to 'make deb-pkg' which will give you a completely non-conflicting package name | 20:34 |
| * rtg_ -> EOD | 20:35 | |
| GrueMaster | thx | 20:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
