| infinity | Is there a plan for a new kernel upload built against the latest binutils? | 00:42 |
|---|---|---|
| infinity | ogasawara: ^? | 00:42 |
| ogasawara | infinity: indeed we should, I'll prep an upload right now. | 00:45 |
| infinity | ogasawara: Thanks. I was going to do a d-i upload, and then realised that would end up baking in the broken kernel, so figured I'd hold off. :P | 00:45 |
| ogasawara | infinity: I've got it ready to upload, I just want my quick test build to finish since it's got a single patch in it. eta 10min. | 00:55 |
| infinity | ogasawara: Check. Does that single patch cause an ABI bump too? | 00:55 |
| infinity | ogasawara: (Not that I mind if it does, just curious) | 00:56 |
| ogasawara | infinity: nope, it shouldn't | 00:56 |
| infinity | Kay, if it's not an ABI bump, care to skip the -proposed thing, and just upload straight to release? | 00:56 |
| infinity | Doesn't really buy us anything to artificially delay the fix if there won't be package skew or anything. | 00:56 |
| ogasawara | infinity: I can | 00:56 |
| infinity | Danke. | 00:57 |
| infinity | Of all the Leanns I know, you are definitely somewhere in the top ten. | 00:58 |
| infinity | *nod* | 00:58 |
| ogasawara | infinity: I demand to be #1! screw the top 10. | 01:04 |
| infinity | There are so many inappropriate ways to read the second half of that. | 01:05 |
| infinity | Well, only one way, really. | 01:05 |
| infinity | But it's inappropriate, regardless. | 01:06 |
| ogasawara | infinity: ok, uploaded. | 01:09 |
| infinity | \o/ | 01:09 |
| ogasawara | infinity: I'll try and keep an eye on it, but I'll be drinkin with the other managers too, so not sure how reliable I'll be | 01:11 |
| infinity | ogasawara: Meh, s'all good. I'll poke it from time to time, and re-upload d-i laterish, or in the morning. | 01:12 |
| infinity | ogasawara: It can't actually be much more broken on x86 than it currently is, so not much to keep an eye on. :P | 01:12 |
| ogasawara | infinity: ack | 01:12 |
| infinity | ogasawara: Don't you enjoy that warm fuzzy feeling you get when the kernel has regressed so hard that you could upload emacs, call it linux, and it would still work just as well? | 01:13 |
| infinity | ogasawara: In other words, go drink. And give my manager a hard time. | 01:13 |
| ogasawara | infinity: heh, will do :) | 01:14 |
| === cheako911 is now known as cheako | ||
| === doko_ is now known as doko | ||
| === henrix_ is now known as henrix | ||
| === lool- is now known as lool | ||
| === Kiall is now known as zz_Kiall | ||
| === zz_Kiall is now known as Kiall | ||
| * henrix -> lunch | 11:36 | |
| doko | rtg, I'm having difficulties to reproduce #1049650. even with the binutils that you did check with, I always see the same offset | 12:05 |
| doko | rtg, I'm having difficulties to reproduce #1049650. even with the binutils that you did check with, I always see the same offset | 12:11 |
| rtg | doko, the binutils you uploaded yesterday still has the problem. | 12:11 |
| doko | rtg, yes, however even using the 2.22.90.20120816-2ubuntu1 one, which you do report success with, apparently has the problem. see the comment in the report | 12:12 |
| rtg | doko, getting there .... | 12:12 |
| doko | rtg: was the chroot you did use for testing up to date? | 12:14 |
| rtg | doko, well, that is odd. | 12:14 |
| rtg | doko, pretty much. lemme try again | 12:14 |
| doko | I was trying to provide some object files for the issue, but can't seem to build the correct ones | 12:15 |
| rtg | doko, up to date chroot: | 12:29 |
| rtg | rtg@salmon:~/ubuntu/ubuntu-quantal$ readelf -s ./debian/build/build-generic/arch/x86/boot/setup.elf|grep video_card | 12:29 |
| rtg | 147: 00002f3c 0 NOTYPE GLOBAL DEFAULT ABS video_cards | 12:29 |
| rtg | 148: 00003650 0 NOTYPE GLOBAL DEFAULT ABS video_cards_end | 12:29 |
| doko | rtg, with the old binutils? | 12:30 |
| rtg | (quantal-amd64)rtg@salmon:~/ubuntu/ubuntu-quantal$ dpkg -l|grep binutils | 12:31 |
| rtg | ii binutils 2.22.90.20120913-1ubuntu1 | 12:31 |
| rtg | doko, makes me wonder if the kernel ogasawara uploaded last night built correctly. guess I can check that out quick enough. | 12:32 |
| doko | rtg: yes, the amd64 build log shows the correct version | 12:33 |
| rtg | doko, correct, but did the kernel get linked correctly ? will it boot, etc. | 12:34 |
| rtg | doko, ogasawara: downloaded new kernel. seems to work. | 12:50 |
| rtg | lemme build on gomeisa again. its got a virgin chroot. | 12:50 |
| doko | I'm currently building on osageorange | 12:51 |
| doko | $ readelf -s debian/build/build-generic/arch/x86/boot/setup.elf | grep video_cards | 13:00 |
| doko | 138: 00003660 0 NOTYPE GLOBAL DEFAULT 12 video_cards | 13:00 |
| doko | 151: 00003660 0 NOTYPE GLOBAL DEFAULT 12 video_cards_end | 13:00 |
| doko | this is what I get on osageorange | 13:00 |
| doko | rtg: ^^^ | 13:00 |
| rtg | doko, I don't think thats gonna work too well | 13:00 |
| doko | rtg: which gcc-4.7 package did you use for the build on salmon? | 13:02 |
| rtg | doko, what is salmon? a buildd ? looks like the amd64 kernel built on allspice last night. | 13:03 |
| doko | <rtg> (quantal-amd64)rtg@salmon: | 13:03 |
| rtg | doko, oh, it a local SandyBridge server that I have. duh. forgot. | 13:04 |
| rtg | doko (quantal-amd64)rtg@salmon:~/ubuntu/ubuntu-quantal$ dpkg -l|grep gcc | 13:05 |
| rtg | ii gcc 4:4.7.0-5ubuntu1 amd64 GNU C compiler | 13:05 |
| rtg | ii gcc-4.7 4.7.1-8ubuntu1 amd64 GNU C compiler | 13:05 |
| doko | strange | 13:05 |
| doko | rtg: I would like to understand why I get different results (osageorange non working), and the buildd (working, as you tested) | 13:06 |
| brendand | cking - is the mailing list for you and the other people working on fwts 'fwts-team@lists.launchpad.net'? | 13:06 |
| cking | brendand, try fwts-devel instead of fwts-team | 13:06 |
| rtg | doko, while the buildd kernel is working, the linker issue may be different on that machine. without being able to look at setup.elf we can't say for sure. | 13:07 |
| brendand | cking - is it private? | 13:07 |
| cking | nope | 13:07 |
| doko | rtg: maybe add a readelf -s to the build? | 13:07 |
| rtg | doko, yeah, perhaps. lemme mess with your chnistrap package again first. | 13:08 |
| doko | rtg: it's just odd that the buildd kernel works, while I still see the issue on osageorange | 13:10 |
| rtg | doko, we don't _know_ that the buildd kernel linked correctly. that fact that it works on my laptop is inconclusive. | 13:11 |
| doko | ahh, so how can we tell? | 13:12 |
| rtg | doko, lemme do a local sbuild with some debug. that shold be about as clkose to the buildds as I can get. | 13:12 |
| doko | rtg: after you did that, could you (with the same binutils version) rebuild with cpp-4.7 and gcc-4.7 4.7.1-7ubuntu1? I'm starting to think it's not a binutils issue after all | 13:13 |
| dantti | hi, is there someone I could poke to get this changed before Quantal? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1003090 | 13:15 |
| ubot2 | Launchpad bug 1003090 in linux "Please enable HID_BATTERY_STRENGTH (on xorg-edgers and quantal kernel packages)" [Medium,Triaged] | 13:15 |
| doko | $ readelf -s debian/build/build-generic/arch/x86/boot/setup.elf|grep video_cards | 13:17 |
| doko | 160: 000041a4 0 NOTYPE GLOBAL DEFAULT 12 video_cards | 13:17 |
| doko | 173: 000041f8 0 NOTYPE GLOBAL DEFAULT 12 video_cards_end | 13:17 |
| rtg | doko, so that looks right. different gcc-4.7 ? | 13:17 |
| doko | rtg: -7ubuntu1 | 13:18 |
| rtg | doko, so you're thinking -8ubuntu1 might be broken ? | 13:19 |
| doko | rtg: yes, and not binutils. maybe you did test with the old compiler yesterday? | 13:20 |
| rtg | doko: dunno, | 13:20 |
| rtg | doko, so, the archive reaper has already cleaned out -7ubuntu1. Do you have those packages stashed somewhere ? | 13:22 |
| doko | rtg: you can get the older ones by the publishing history | 13:23 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| rtg | doko, ah, thats good to know | 13:23 |
| rtg | doko, egads, there are a lot of .deb files there. Is there a handy way to install the ones I need ? | 13:25 |
| hallyn | stgraber: looking at the "Release Meeting 2012-09-14" email, I don't see the netns bug in the "Summary of bugs working on by team". Do you have the bug# handy? | 13:25 |
| doko | rtg: you only need cpp-4.7 and gcc-4.7. install using dpkg --force-depends | 13:26 |
| rtg | doko, ok, gimme a bit. | 13:27 |
| doko | <jakub> doko: from quick look at the kernel, I'd say the kernel is buggy | 13:32 |
| stgraber | hallyn: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1021471 | 13:32 |
| ubot2 | Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Triaged] | 13:32 |
| doko | <jakub> doko: I'd say used attribute is a must in the #define __videocard struct card_info __attribute__((section(".videocards"))) | 13:32 |
| doko | <jakub> doko: because when it declares static __videocard var = { ... }; then the compiler has all rights to just nuke those as unused | 13:32 |
| doko | rtg: ^^^ | 13:32 |
| hallyn | stgraber: thanks | 13:37 |
| hallyn | ogasawara: ^ bug 1021471 wasn't on the list of quantal bugs the kernel team is looking at? | 13:38 |
| ubot2 | Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Triaged] https://launchpad.net/bugs/1021471 | 13:38 |
| ogasawara | hallyn: that should have been on the list, I seemed to have missed getting it on there | 13:39 |
| ogasawara | hallyn: and it should be getting worked by cooloney | 13:39 |
| hallyn | ogasawara: phew :) thanks | 13:40 |
| rtg | doko, ack | 13:40 |
| rtg | doko, this seems to be somewhat random. I just built with binutils 2.22.90.20120913-1ubuntu1, cpp-4.7 4.7.1-8ubuntu1, and gcc-4.7 4.7.1-8ubuntu1. | 13:45 |
| rtg | readelf -s /home/rtg/ukb/quantal/amd64/master-next/ubuntu-quantal/debian/build/build-generic/arch/x86/boot/setup.elf|grep video_card | 13:45 |
| rtg | 147: 00002f3b 0 NOTYPE GLOBAL DEFAULT ABS video_cards | 13:45 |
| rtg | 148: 00003650 0 NOTYPE GLOBAL DEFAULT ABS video_cards_end | 13:45 |
| rtg | lemme try an sbuild | 13:46 |
| doko | strange | 13:48 |
| doko | rtg: and wondering why the Ndx column sometimes has ABS, sometimes 12 | 13:48 |
| ppisati | seems like i'm finally back... | 13:59 |
| cking | welcome back ppisati | 13:59 |
| === henrix` is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| ppisati | :) | 14:01 |
| doko | rtg: adding the used attributes on osageorange: | 14:02 |
| doko | $ readelf -s debian/build/build-generic/arch/x86/boot/setup.elf | grep video_cards | 14:02 |
| doko | 159: 000041a8 0 NOTYPE GLOBAL DEFAULT 12 video_cards | 14:02 |
| doko | 172: 000041fc 0 NOTYPE GLOBAL DEFAULT 12 video_cards_end | 14:02 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| rtg | doko, I'm wondering why video_cards is treated special in the kernel ? how are you applying the used attribute ? | 14:05 |
| doko | --- arch/x86/boot/video.h.orig 2012-09-14 14:06:49.005979707 +0000 | 14:07 |
| doko | +++ arch/x86/boot/video.h 2012-09-14 13:43:47.116013331 +0000 | 14:07 |
| doko | @@ -80,7 +80,7 @@ | 14:07 |
| doko | u16 xmode_n; /* Size of unprobed mode range */ | 14:07 |
| doko | }; | 14:07 |
| doko | 14:07 | |
| doko | -#define __videocard struct card_info __attribute__((section(".videocards"))) | 14:07 |
| doko | +#define __videocard struct card_info __attribute__((used, section(".videocards"))) | 14:07 |
| doko | extern struct card_info video_cards[], video_cards_end[]; | 14:07 |
| doko | 14:07 | |
| doko | int mode_defined(u16 mode); /* video.c */ | 14:07 |
| sforshee | doko, your readelf output still doesn't really look right, that array should be bigger | 14:08 |
| rtg | it should be 3650-2f3b | 14:09 |
| doko | sforshee, maybe, however I'm trying to reproduce the values which rtg does get. currently I can't | 14:11 |
| jsalisbury | rtg, cjwatson took a look at bug 1047092 and re-assigned to linux-firmware. Looks like a packaging fix is needed? Anyone specific you think I should ping about this? | 14:11 |
| ubot2 | Launchpad bug 1047092 in linux-firmware "Mini.iso doesn't load wireless drivers" [Medium,Triaged] https://launchpad.net/bugs/1047092 | 14:11 |
| * ppisati is shuffling cables around... | 14:11 | |
| === Kiall is now known as zz_Kiall | ||
| rtg | doko, ogasawara: my sbuild produced an empty video_cards section, which is also likely what happened on the buildd | 14:15 |
| ogasawara | jsalisbury: I'm prepping a patch for that bug right now | 14:16 |
| jsalisbury | ogasawara, cool, thanks | 14:16 |
| ogasawara | jsalisbury: rather I have the patch, just kicking off a test build to confirm the fw shows up in the udeb | 14:16 |
| jsalisbury | ogasawara, ok | 14:16 |
| ogasawara | jsalisbury: I've told cjwatson on ubuntu-devel I'll upload shortly | 14:17 |
| === zz_Kiall is now known as Kiall | ||
| jsalisbury | ogasawara, ahh, I see that now :-) | 14:18 |
| rtg | ogasawara, you're also adding zd1201 as well ? | 14:19 |
| ogasawara | rtg: I did | 14:19 |
| ogasawara | rtg: added zd1201.fw and zd1211/* | 14:20 |
| doko | <rtg> readelf -s /home/rtg/ukb/quantal/amd64/master-next/ubuntu-quantal/debian/build/build-generic/arch/x86/boot/setup.elf|grep video_card | 14:20 |
| doko | <rtg> 147: 00002f3b 0 NOTYPE GLOBAL DEFAULT ABS video_cards | 14:20 |
| doko | <rtg> 148: 00003650 0 NOTYPE GLOBAL DEFAULT ABS video_cards_end | 14:20 |
| rtg | doko, that looks right. is that with the 'used' attribute ? | 14:20 |
| doko | rtg: could you tar up the boot dir for this build and put it somewhere? it also would be good to get the preprocessed source files for this dir | 14:21 |
| rtg | oh, nm. I pasted that. | 14:21 |
| doko | right | 14:21 |
| rtg | doko, what is the boot dir for a build ? | 14:22 |
| rtg | doko, do you mean the full build directory ? | 14:23 |
| doko | rtg: debian/build/build-generic/arch/x86/boot/ *.o and setup.elf | 14:25 |
| === Kiall is now known as zz_Kiall | ||
| sforshee | doko, actually looking closer I think your output looks correct and rtg's is too big. There should be 3 card_info structs linked in the section, and they aren't all that big. | 14:31 |
| rtg | sforshee, hmm, I never thought to check the size. if what you're saying is true, then what fills the 715H in my case ? | 14:34 |
| sforshee | rtg, no idea | 14:34 |
| sforshee | rtg, doko's section is 84 bytes, or 28 bytes per struct, which is about right if pointers and ints are 32 bits | 14:35 |
| rtg | sforshee, this is amd64 | 14:35 |
| sforshee | rtg, right, that's the only part that doesn't make sense | 14:35 |
| sforshee | rtg, but that still wouldn't account for that much of a difference | 14:36 |
| doko | rtg: this code is built with -m32 | 14:36 |
| sforshee | rtg, and I get the same results in an amd64 chroot | 14:36 |
| rtg | doko, hmm, so we add 'used' to the attribute definition and call it good ? | 14:37 |
| === zz_Kiall is now known as Kiall | ||
| doko | for the kernel, maybe. however I would like to followup upstream. currently I can't get the .o file built by hand. maybe I'm missing something | 14:38 |
| sforshee | rtg, I think it makes sense to add __used to the definition of __videocard. Otherwise the variable does look unused within the file. | 14:38 |
| doko | sforshee, rtg: if I look at the verbose build log, then this vesa-mode.o is built with -o arch/x86/boot/.tmp_video-vesa.o however I can nowhere see where it's moved to the final name/place | 14:40 |
| doko | and: $ gcc -m32 -c -Os -march=i386 -mregparm=3 -fno-strict-aliasing -fomit-frame-pointer -ffreestanding -fno-toplevel-reorder -fno-stack-protector video-vesa.i | 14:40 |
| doko | $ nm video-vesa.o U boot_params | 14:40 |
| doko | 00000000 T vesa_store_edid | 14:40 |
| doko | 00000000 b vginfo | 14:40 |
| doko | what am I missing? | 14:41 |
| rtg | doko, chinstrap.canonical.com:~rtg/boot.tgz | 14:41 |
| sforshee | doko, scripts/Makefile.build does the move to the final name | 14:42 |
| sforshee | doko, see cmd_modversions | 14:43 |
| doko | sforshee, what I'm looking for is a video-vesa.i, and the command to build the video-vesa.o | 14:43 |
| doko | sforshee, hmm, even in verbose mode, parts of rule_cc_o_c are hidden :-/ | 14:48 |
| sforshee | doko, yep | 14:50 |
| doko | sforshee, could you help with this? | 14:50 |
| sforshee | doko, sure, what do you need? | 14:50 |
| doko | a video-vesa.i, and the command to build the video-vesa.o | 14:51 |
| doko | because I get something different with the commands I did paste | 14:51 |
| arges | cking, hey | 14:51 |
| cking | arges, hiya | 14:51 |
| doko | sforshee, hmm, I'm missing the ld -r call maybe | 14:55 |
| doko | rtg, I'm surprised that it works with your tarball, because: | 15:02 |
| doko | $ nm video-vesa.o | 15:02 |
| doko | U boot_params | 15:02 |
| doko | 00000000 T vesa_store_edid | 15:02 |
| doko | 00000000 b vginfo | 15:02 |
| rtg | sforshee, doko: I'm inclined to upload with this 'used' attribute patch so we can get a working kernel in the archive. | 15:07 |
| doko | rtg, I can't say that adding the attribute would be wrong | 15:08 |
| sforshee | rtg, I think we send it upstream as well, because to me it just looks correct | 15:08 |
| rtg | sforshee, doko: agreed | 15:08 |
| doko | after the kernel is built, I'd like to revert the binutils change, after testing that I get the same result with the used attribute | 15:09 |
| sforshee | doko, are you actually seeing the command to build video-vesa.i in your verbose build? | 15:10 |
| doko | sforshee, yes, I saved that and added -save-temps | 15:10 |
| sforshee | doko, I'm not seeing it. I thought it was just a debugging feature anyway. | 15:13 |
| doko | sforshee, so we now have three section sizes. 0 without the used attribute, 84 with the attribute, and rtg's even bigger one. however the bigger one is only seen by rtg, correct? | 15:13 |
| sforshee | doko, I've never seen the bigger one | 15:13 |
| rtg | doko, as far as I know that is correct. | 15:14 |
| doko | sforshee, I set KBUILD_VERBOSE=1 in the env | 15:14 |
| sforshee | doko, I have that too, just not seeing any .i files generated when I run build-generic | 15:14 |
| doko | sforshee, you have to explicitly add -save-temps | 15:15 |
| sforshee | doko, ack | 15:15 |
| rtg | hmm, grub 2.0 sure looks different. | 15:19 |
| doko | rtg, am I needed for the grub issue too? ;) | 15:23 |
| rtg | doko, no, I was just noticing menu differences. | 15:23 |
| sforshee | doko, in my experimentation .tmp_video-vesa.o doesn't have the __ksymtab section, so I think it just gets renamed to video-vesa.o | 15:24 |
| doko | ahh, ok | 15:24 |
| doko | sforshee, rtg: was -fno-toplevel-reorder recently added to build this file? | 15:37 |
| rtg | doko, no change to scripts/Makefile.build since Jan 24 | 15:39 |
| doko | because with gcc-4.6 -fno-toplevel-reorder, the symbol is emitted, but not with gcc-4.7. but I don't see a behaviour change on the branch | 15:40 |
| sforshee | doko, that option has been in arch/x86/boot/Makefile since at least 3.3 | 15:40 |
| sforshee | doko, is what you're looking for how you can generate video-vesa.i? Because I'm not getting one even with -save-temps. | 15:42 |
| doko | sforshee, well, let's stop with it for now. | 15:44 |
| sforshee | doko, okay | 15:44 |
| rtg | doko, ogasawara, sforshee: Uploading linux_3.5.0-14.18_source.changes: done. | 15:46 |
| ogasawara | rtg: ack | 15:46 |
| doko | ahh, and at least 4.7.0 -fno-toplevel-reorder had this symbol emitted too. so this did change on the branch | 15:48 |
| rtg | doko, so that option was removed in 4.7.1 ? The description says, "When this option is used, unreferenced static variables are not removed." | 15:54 |
| doko | rtg: no, actually this might be the root cause. | 15:56 |
| doko | and it works in gcc-snapshot. so I'll have to look when this did change. I see the same behaviour in Debian, so it's not caused by any Linaro change | 15:58 |
| kirkland | cking: hey! is there an easy way to tell if my i7 has the rdrand instruction? | 16:04 |
| kirkland | cking: anything in /proc/cpuinfo or the like? | 16:04 |
| kirkland | cking: I'm guessing "not", as I tried to run your rdrand test, and I got :-) Illegal instruction (core dumped) | 16:05 |
| kirkland | cking: http://smackerelofopinion.blogspot.com/2012/08/simple-performance-test-of-rdrand.html fwiw | 16:05 |
| cking | kirkland, see http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide - rdrand_check_support() | 16:09 |
| cking | kirkland, or grep "rdrand" in /proc/cpuinfi ;-) | 16:19 |
| cking | * /proc/cpuinfo | 16:19 |
| === Kiall is now known as zz_Kiall | ||
| cking | kirkland, I've updated the code to test rdrand CPU features. | 16:42 |
| cking | oops, nope, failed | 16:43 |
| * ppisati -> gym workout | 16:45 | |
| cking | kirkland, fixed now | 16:46 |
| rtg | doko, when you have figured out root cause, please add your explanation to bug #1049650 for _why_ 'used' is a required attribute so that when I punt this patch upstream I can point to something factual. | 16:49 |
| ubot2 | Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,Fix released] https://launchpad.net/bugs/1049650 | 16:49 |
| kirkland | cking: neat, thanks | 16:56 |
| dileks | checking for video_cards... so this is good? http://nopaste.snit.ch/166160 | 17:08 |
| * cking spots a jump in page hits on the blog | 17:09 | |
| * rtg -> lunch | 17:30 | |
| dileks | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1049650/comments/4 | 17:30 |
| ubot2 | Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,Fix released] | 17:30 |
| dileks | ok, than precise gcc-4.6 is not affected | 17:30 |
| * cking --> EOD | 17:58 | |
| === cmagina_ is now known as cmagina_away | ||
| * henrix -> EOD | 18:13 | |
| === henrix is now known as henrix_ | ||
| infinity | rtg: You seem to have left some debug code in your kernel upload that broke !x86. | 18:57 |
| rtg | infinity, damn, I didn't think about that. | 18:58 |
| infinity | +$(build_cd) readelf -s `find . -name setup.elf` | grep video_card | 18:58 |
| infinity | At the very least, I didn't check the rest of the diff. | 18:58 |
| infinity | But it chokes there, for obvious reasons. | 18:58 |
| rtg | infinity, I left there on purpose so we could see the section sizes, but they won't exists for !x6 | 18:58 |
| rtg | infinity, ok, I'll fix and re-upload | 18:59 |
| infinity | Danke. | 18:59 |
| * ogasawara lunch | 19:02 | |
| rtg | infinity, ogasawara: Uploading linux_3.5.0-14.19.dsc: done. (sigh) | 20:24 |
| ogasawara | rtg: ack | 20:25 |
| rtg | ogasawara, I'm not gonna bother with the LTS upload until there is a substantive change | 20:27 |
| infinity | rtg: Thanks. | 20:27 |
| ogasawara | rtg: yah, sounds good | 20:27 |
| * rtg drifts away for the weekend... | 20:29 | |
| === yofel_ is now known as yofel | ||
| === cmagina_away is now known as cmagina_ | ||
| geofft | Is there a recommended way to recompile a single kernel module with different Kconfig options? | 21:46 |
| geofft | preferably without recompiling the entire kernel? | 21:47 |
| geofft | I'm trying to make sense of debian/rules.d but not having much luck :) | 21:47 |
| geofft | Looks like you can play some dirty tricks that start with `fakeroot debian/rules config-prepare-check-generic` | 22:35 |
| geofft | I'd be happier if I somehow got a .deb out of this process, but I do have the .ko I want. | 22:35 |
| === cmagina is now known as cmagina_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!