cjwatson | ogasawara: heads-up on bug 893395 | 00:25 |
---|---|---|
ubot2 | Launchpad bug 893395 in linux "ext2 modular in precise but missing from fs-core-modules" [Undecided,New] https://launchpad.net/bugs/893395 | 00:25 |
cjwatson | shame I missed today's upload | 00:25 |
=== BenC__ is now known as BenC | ||
=== ericm-Zzz is now known as ericm | ||
ogasawara | cjwatson: pushed a fix for 893395, I'll upload once the current upload finishes building (eta 5hrs). will then get linux-meta uploaded as well. | 04:41 |
smb | morning .+ | 08:25 |
abogani | morning | 08:27 |
* apw waves weakly | 08:58 | |
ppisati | smb`: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/kernel/guard-page/split-stack.c | 11:24 |
ppisati | smb`: do you remember if it relates to a CVE or a particular kernel option? | 11:25 |
=== smb` is now known as smb | ||
smb | ppisati, it had to do with a cve, but I cannot remember exactly what/which | 11:44 |
ppisati | smb: found | 11:44 |
ppisati | smb: https://bugs.launchpad.net/ubuntu/jaunty/+source/linux-mvl-dove/+bug/646114 | 11:44 |
ubot2 | Launchpad bug 646114 in linux "mlock on stack will create guard page gap" [Undecided,Fix released] | 11:45 |
=== tkamppeter_ is now known as tkamppeter | ||
smb | ppisati, Well, I believe that was a problem introduced by the attempted fix for the other problem | 11:45 |
smb | The guard page thing was supposed to prevent some bad collision but unfortunately the way this was shown to user-space was one-off (or so) | 11:47 |
smb | Hm, actually might have been that if the area was spanning more than one vm area the guard page hole was presented for each area | 11:48 |
smb | which is a lie for anything but the lowest (if your stack grows downwards) | 11:48 |
ppisati | smb: ok, seems to be 28d2e371327c8961ae593e1a3e275df32b35dd7d maverick/master | 11:50 |
smb | ppisati, That was the fix. It started with 52423b90e1f5b1bdbbcc6e32f4d37ada29b790c4 | 11:53 |
smb | ppisati, CVE-2010-2240 | 11:53 |
ubot2 | smb: The do_anonymous_page function in mm/memory.c in the Linux kernel before 2.6.27.52, 2.6.32.x before 2.6.32.19, 2.6.34.x before 2.6.34.4, and 2.6.35.x before 2.6.35.2 does not properly separate the stack and the heap, which allows context-dependent attackers to execute arbitrary code by writing to the bottom page of a shared memory segment, as demonstrated by a memory-exhaustion attack against the X.Org X server. (http://cve.mitre.org/c | 11:53 |
ppisati | cool, i'll import it | 11:55 |
ppisati | btw, does that mean that secuiry test routine were not run on arm branches? | 11:55 |
ppisati | but first, lunch! :) | 11:56 |
smb | ppisati, We do security on arm? :-P | 11:56 |
smb | Well it should be in there | 11:57 |
ppisati | well, it seems we just started to do security on arm... :) | 11:57 |
smb | The CVE required a whole bunch of changes but for Maverick those seem to be in from upstream stable | 11:57 |
smb | It turned out that the minimal invasive patch was a maximum pain in the butt | 11:58 |
ppisati | sounds like something to remember... :) | 11:58 |
* smb does not think that anything minimal invasive exists in memory management... | 11:59 | |
ppisati | smb: well, but you made my facebook status quote :) | 12:00 |
* smb tries to hide | 12:01 | |
apw | ppisati, so did someone in qa just bring up that security failure ? | 13:50 |
apw | ppisati, cirtainly in the early days we didn't record derivative branches as well as we do now, and so they had not CVE tracker entries and didn't get updated always; and once missed that was it | 13:51 |
herton | apw, bug 893190 (first reported on tracking bug 888569) | 13:53 |
ubot2 | Launchpad bug 893190 in linux-ti-omap4 "Qa-testing failures for 2.6.35-903.27" [Undecided,New] https://launchpad.net/bugs/893190 | 13:53 |
ubot2 | Launchpad bug 888569 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 2.6.35-903.27 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/888569 | 13:53 |
apw | so it must be new testing i suspect then, a good thing if a little late | 13:53 |
apw | herton, but if it is a missing CVE which simply is not applied to that branch, then its not a regression | 13:54 |
herton | indeed, I guess that's it also | 13:54 |
apw | herton, and we'd not necessarily want to hold the update. the previous release is as bad | 13:54 |
herton | apw, I was thinking about it as well, that's true, shouldn't hold if not a regression. If GrueMaster can confirm is not a regression, we could go forward with the update and release it | 13:55 |
apw | ppisati, is this just a cve we have missed on this branch, ie are the fixes simply missing? | 13:56 |
apw | herton, if that is a yes ^^ then its defnatly not a regression | 13:56 |
apw | let me know if so so i can get the security team to pull that entry back from retired for the matrix too | 13:56 |
herton | ok. There is more 1 test failure on the report, not sure if they are all missing cves, but if not a regression on all then ok | 13:58 |
herton | *more than 1 | 13:58 |
apw | ahh ok, so ppisati any cves we find missing via this testing i need the numbers for to reopen the CVEs | 13:59 |
smb | From past experience it can be worth looking at the failed test closely since some are doing statistical checks and sometimes those were to tightly checking | 13:59 |
smb | (like the stack randomization checks) | 13:59 |
apw | yep there is that, for the random placement checks they are poor | 13:59 |
apw | and can fail once in a while without being broken | 14:00 |
smb | Yep, I guess with less memory random place is less random than with more... | 14:00 |
apw | i believe that arm has less bits to be random with iirc | 14:01 |
ogasawara | apw: would you be able to stand in for me at the release meeting on fri | 14:11 |
apw | ogasawara, sure, i think there is a change to how its done which you'd have to get me up to speed on | 14:12 |
ogasawara | apw: yep, we send out our team specific bits to the ubuntu-release mailing list ahead of time. then the meeting is just any follow up Q&A for what we sent out. | 14:12 |
apw | ogasawara, and we chose the bugs for the list as well ? | 14:13 |
ogasawara | apw: yep | 14:13 |
apw | how we been picking them | 14:13 |
ogasawara | apw: apw: I'll go ahead and send out the email to ubuntu-release. that way you can just sit in on the meeting. | 14:13 |
apw | are we relying on jo for that, or do we have a tag | 14:13 |
apw | ogasawara, ok fair enough | 14:14 |
ogasawara | apw: mainly relying on the rls-p-tracking tag | 14:14 |
ogasawara | apw: but we're responsible for putting that on the bugs | 14:14 |
ogasawara | apw: but since we've just uploaded a 3.2 kernel, I haven't been real aggressive with using the tag just yet as it's not clear if some of the bugs will resolve themselves with the newer kernel. | 14:14 |
ogasawara | apw: but I've been keeping an eye on some, which I'll list in the email. | 14:15 |
apw | yeah for sure, till that mess is in and stable we're spinning wheels | 14:15 |
ogasawara | apw: I also uploaded a new 3.2.0-1.3 to fix up bug 893395 | 14:16 |
ubot2 | Launchpad bug 893395 in linux "ext2 modular in precise but missing from fs-core-modules" [Critical,Fix released] https://launchpad.net/bugs/893395 | 14:16 |
ogasawara | apw: once that builds I'll hopefully want to upload linux-meta finally | 14:16 |
ogasawara | tseliot: were you able to take a peek at wl? | 14:16 |
apw | ogasawara, yeah saw that on irc scroll back, a good decision me thinks | 14:17 |
tseliot | ogasawara: I'm working on it as we speak. I think I've found the change that causes the build to fail. I have to see if this is the only change though | 14:18 |
ogasawara | tseliot: great, thanks. please keep us posted. | 14:18 |
tseliot | ogasawara: sure | 14:18 |
=== ericm|ubuntu is now known as ericm-Zzz | ||
ogasawara | jsalisbury: think you'll you be ready to pick up chairing the weekly IRC meeting next week? | 14:38 |
tseliot | ogasawara, apw: my patch at least allows the module to build. Now I only need to test it on a device with broadcom | 14:48 |
apw | sounds good | 14:48 |
tseliot | now remembering which one of the bazillion devices that I have around has broadcom is the main problem ;) | 14:50 |
jsalisbury | ogasawara, yes, next week is good for me | 14:51 |
ogasawara | jsalisbury: and I haven't forgotten about the bug you pinged about yesterday, will get to it soon | 14:52 |
jsalisbury | ogasawara, cool. thanks | 14:53 |
* herton -> lunch | 15:03 | |
* ogasawara back in 20 | 15:29 | |
TeTeT | apw: thanks for the dpms suggestion for the random freezes! | 15:40 |
apw | hey np | 15:41 |
* tseliot has finally found a device with a broadcom chipset \o/ | 15:49 | |
mdeslaur | herton: is this table accurate? https://wiki.ubuntu.com/Kernel/Dev/ABIPackages | 15:54 |
mdeslaur | herton: is that what you use, or do you have a more authoritative source? | 15:55 |
herton | mdeslaur, yes, it's the official source | 15:56 |
mdeslaur | herton: ok...can I correct everything that's inaccurate in it then? | 15:56 |
herton | mdeslaur, yep | 15:56 |
apw | ogasawara, we need to add a WI to update the above page and its friends when we are about to release, by kernel freeze we should know i'd think | 16:00 |
apw | ogasawara, with our standard ones like emailing out the config | 16:00 |
tseliot | apw, ogasawara: unfortunately the only laptop (that works) which has a broadcom card only uses the open driver. I think the laptop that I used for testing is the one with the dead monitor... | 16:02 |
apw | tseliot, if you have .debs i have brcm that works with wl i believe | 16:03 |
tseliot | apw: sure, for amd64? | 16:03 |
apw | sadly its 32bit | 16:03 |
tseliot | apw: ok, let me create a 32bit chroot then | 16:03 |
apw | tseliot, hang on | 16:05 |
apw | tseliot, its a dkms package, isn't it an _all ? | 16:05 |
tseliot | apw: no, as we only support i386 and amd64 | 16:05 |
tseliot | unfortunately | 16:05 |
apw | tseliot, but the package would be identicle, as in its not a binary package? | 16:06 |
tseliot | apw: the makefile is patched so that the right binary is used according to the architecture | 16:07 |
apw | tseliot, yeah i mean if i just force the xmd64 binary on it'll work right ? | 16:07 |
tseliot | there are separate binaries in the same package for the two archs | 16:07 |
apw | oh ick ok, i'll shut up now | 16:07 |
apw | ogasawara, is the meeting in an hour ? | 16:08 |
ogasawara | apw: yep | 16:08 |
apw | you or joe? | 16:08 |
ogasawara | apw: me. joe will take over next week. | 16:08 |
tseliot | apw: even if you force the installation I think dpkg --print-architecture would report the right architecture and things should be fine | 16:09 |
tseliot | apw: so it's probably worth trying | 16:09 |
tseliot | (the makefile is called by DKMS) | 16:09 |
apw | tseliot, can do if you point me to a binary | 16:09 |
tseliot | apw: sure let me upload the deb file | 16:09 |
tseliot | apw: http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.112+bdcom-0ubuntu1_amd64.deb | 16:11 |
tseliot | apw: no, wait | 16:12 |
tseliot | it won't work | 16:12 |
apw | tseliot, /me waits | 16:13 |
tseliot | apw: some files are renamed when the package is built, therefore it's not gonna work | 16:13 |
apw | tseliot, ok | 16:13 |
tseliot | apw: hopefully my chroot will be ready in a few | 16:14 |
apw | ok | 16:14 |
tseliot | apw: the creation of an i386 chroot failed (because of perl...). I'm using my Lucid 32bit chroot | 16:23 |
* tseliot keeps his fingers crossed | 16:24 | |
apw | heheh | 16:25 |
ppisati | i didn't see the usual kernel meeting warning | 16:28 |
ppisati | it's still scheduler in 30mins, right? | 16:28 |
ppisati | *scheduled | 16:29 |
apw | ppisati, indeed should be, ogasawara did we miss a 1hr warning? | 16:29 |
ogasawara | yah, got sidetrack and didn't spam the channel | 16:29 |
ppisati | np | 16:30 |
ogasawara | ## | 16:30 |
ogasawara | ## Kernel team meeting today @ 17:00 UTC | 16:30 |
ogasawara | ## | 16:30 |
cking | eek | 16:30 |
apw | (that is in 30 minutes people) | 16:30 |
smb | he lives... | 16:30 |
cking | who me? | 16:30 |
smb | yes | 16:30 |
smb | :) | 16:30 |
cking | I've been grinding data all day | 16:30 |
apw | cking, i expect you have half a dozen reports for the thing right ? | 16:30 |
cking | I'm still working on it | 16:31 |
smb | I guess the meeting will take then a bit longer than usual... :) | 16:31 |
* cking keeps on finding weird corner cases which need double checking | 16:32 | |
GrueMaster | herton, apw. Not a regression, definately. I was just recently able to get the qrt kernel tests working on armel w/o a lot of false positives. | 16:34 |
apw | GrueMaster, ok cool, herton that sounds like we can at least release it | 16:37 |
ogasawara | jsalisbury: just fyi, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/892675/comments/2 | 16:37 |
ubot2 | Launchpad bug 892675 in linux "include/linux/usb.h missing" [Medium,Invalid] | 16:37 |
apw | ppisati, we do need to get a list of all the CVEs which are truly not fixed on there so i can get them active again | 16:37 |
herton | yep, GrueMaster can you tag it passing qa on the maverick ti-omap4 bug? ppisati opened a new bug to work on the failures | 16:37 |
GrueMaster | Will do. | 16:38 |
jsalisbury | ogasawara, thanks! | 16:38 |
ppisati | apw: so far, only 1 seems good and it's not a CVE | 16:39 |
ppisati | apw: it's a fix for the fix of a CVE | 16:39 |
apw | ahh, it should probabally have had a CVE number and didn't | 16:39 |
ppisati | apw: 2 of the failing tests seem not applicable to maverick/omap4 | 16:40 |
tseliot | apw: http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.112+bdcom-0ubuntu1_i386.deb | 16:40 |
ppisati | apw: and now i'm looking atthe last one | 16:40 |
apw | ogasawara, as the reporter is mentioning /usr/include those would be the copies in linux-libc-dev, are they in there too ? | 16:40 |
GrueMaster | There is one test that is failing (/dev/mem) that needs more research, but I am not counting it in the test failure results yet. | 16:41 |
apw | ogasawara, and indeed on my precise install there is no /usr/include/linux/usb.h | 16:41 |
ogasawara | hrm, /me double checks | 16:42 |
apw | ogasawara, that it _is_ in headers and not linux-libc-dev doesn't mean its meant to be in /usr/include of course | 16:43 |
apw | there is a process in the kernel to copy it over ... | 16:43 |
apw | ogasawara, i can take a look if you like | 16:43 |
ogasawara | apw: sure, go for it | 16:43 |
ppisati | GrueMaster: SECCOMP and STRICT_DEVMEM are not applicable to that release | 16:43 |
ppisati | GrueMaster: i sent you a test kernel for the mlock split stuff | 16:43 |
ppisati | GrueMaster: and the only missing part are the PTRACE* checks | 16:44 |
GrueMaster | ppisati: Not seeing a kernel link | 16:45 |
ppisati | GrueMaster: i sent it in #ubuntu-arm | 16:46 |
ppisati | GrueMaster: anyway | 16:46 |
ppisati | GrueMaster: http://people.canonical.com/~ppisati/linux-image-2.6.35-903-omap4_2.6.35-903.27~mlockfix_armel.deb | 16:46 |
ppisati | GrueMaster: this should fix the | 16:46 |
HadiM | hi | 16:46 |
ppisati | GrueMaster: "Make sure the stack guard page does not split the stack on mlock ... FAIL" | 16:46 |
ppisati | GrueMaster: in test-kernel.py | 16:46 |
HadiM | I dont find iwlwifi / iwlagn modules in 3.2 ubuntu kernel | 16:47 |
HadiM | http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/ | 16:47 |
HadiM | is that normal ? | 16:47 |
HadiM | (sorry if I am on the wrong channel) | 16:48 |
ogasawara | HadiM: not sure about the mainline build (which is the url you posted), but I'm using the iwlwifi driver right now on a 3.2.0-1.2 Ubuntu kernel | 16:51 |
ogasawara | modinfo iwlwifi | 16:52 |
ogasawara | filename: /lib/modules/3.2.0-1-generic/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko | 16:52 |
HadiM | 32bit or 64 ? | 16:52 |
ogasawara | HadiM: 64 | 16:52 |
HadiM | ok same here | 16:52 |
HadiM | I double check the deb | 16:52 |
HadiM | in the url I gave you the kernel name is 3.2.0-030200rc2-generic/ | 16:54 |
apw | ogasawara, when you did the rebase did you notice anything about those changing name | 16:54 |
HadiM | and there is no iwlwifi dir in /lib/modules/3.2.0-030200rc2-generic/kernel/drivers/net/wireless/ | 16:54 |
ogasawara | apw: not that I'm aware, but tgardner did the original v3.2-rc1 rebase | 16:54 |
HadiM | oh youre using the precise kernel build | 16:55 |
ogasawara | HadiM: right | 16:55 |
HadiM | I suppose it is not the same as http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/ | 16:55 |
HadiM | thats strange | 16:55 |
HadiM | I will try the precise build on my oneiric | 16:56 |
ogasawara | HadiM: that url is to the upstream vanilla v3.2-rc2 kernel. although I'm not sure why it would be missing there. | 16:56 |
apw | tseliot, on it | 16:56 |
HadiM | it is missing in 3.2 rc1 and rc2 for sure | 16:56 |
tseliot | apw: thanks | 16:56 |
GrueMaster | ppisati: Your kernel fixes that bug, but it must be an older spin. It is giving me a different mac on boot, and the eth0 is now usb0. | 16:57 |
* apw notes a netbook is not the speedyiest | 16:58 | |
ppisati | GrueMaster: no, i put the patches on top of maverick/omap4 tip | 16:58 |
GrueMaster | Well, system came up with a different mac, so not sure what is different. | 16:59 |
* ppisati notes kernel.ubuntu.com is dead slow... | 16:59 | |
ogasawara | meeting time... | 17:00 |
smb | already | 17:00 |
ppisati | GrueMaster: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4 | 17:01 |
ppisati | GrueMaster: latest 4 patches are the fix | 17:01 |
ppisati | GrueMaster: and are on top of the rest | 17:01 |
GrueMaster | Well it is failing my testmac test, which enables/disables the ethernet port 10 times and compares mac addresses in between. I can't reach the system now until dns catches up with dhcp (I'm remote and the system is at home). | 17:03 |
GrueMaster | Wait, I think I see the problem. It isn't polling the die id. | 17:05 |
GrueMaster | Let me reboot to the proposed kernel and verify. | 17:07 |
GrueMaster | ppisati: Sorry, I guess I just never noticed it before. I don't think 2.6.35 polls the die id for the mac address. nevermind. | 17:09 |
GrueMaster | I usually run sru tests on it locally. | 17:10 |
apw | tseliot, not looking good on my machine here ... seems to partially think its a wired network and generally doesn't connect | 17:10 |
jsalisbury | ogasawara, followed along ok. I should be fine to take over next week. Will you update the runes file to include ckings power topic? Or should I do it when updating it from the agenda next week? | 17:11 |
ogasawara | jsalisbury: I'll go ahead and update it | 17:11 |
tseliot | apw: did you reboot? | 17:11 |
jsalisbury | ogasawara, cool, thanks | 17:11 |
apw | tseliot, yep | 17:11 |
ogasawara | jsalisbury: I'm also thinking it would probably be good for you to take over reporting the "[TOPIC] Release Metrics and Incoming Bugs" | 17:12 |
jsalisbury | ogasawara, sure | 17:12 |
apw | tseliot, also hand blacklisted the kernel modules which pick up this device otherwise | 17:12 |
ogasawara | jsalisbury: it's just a copy and past of http://people.canonical.com/~kernel/reports/kt-meeting.txt | 17:12 |
jsalisbury | ogasawara, ok | 17:12 |
ogasawara | jsalisbury: if there are any other bugs which you want us to look at as well, that's probably a good time time to raise them as well. | 17:13 |
jsalisbury | ogasawara, good idea. I can add a reminder about the hot list. | 17:13 |
tseliot | apw: I also updated the driver to a new release, so maybe we're facing 2 different problems here. I could write a patch against the old driver and see if it helps | 17:13 |
apw | tseliot, ok whatever you think | 17:14 |
apw | cirtainly something is odd cause nm is mistaking it for a wired port | 17:14 |
apw | tseliot, though i have no idea how nm knows what sort of port any port is | 17:17 |
tseliot | apw: this is all I did: http://pastebin.ubuntu.com/746118/ | 17:18 |
apw | yeah seems unlikely that would fookulize everything else, so we must suspect the new driver | 17:19 |
tseliot | apw: right (hopefully). Let's see if the old driver works | 17:20 |
tseliot | apw: is this any better? http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.38+bdcom-0ubuntu5_i386.deb | 17:31 |
* ppisati -> eod | 17:42 | |
apw | tseliot, ok with that one, after a reboot i get what appears to be working wiki | 17:43 |
apw | wifi, done a bit of surfing so far, nothing hardcore | 17:43 |
tseliot | apw: \o/ | 17:46 |
* apw watches a movie on it | 17:46 | |
tseliot | apw: ok, I'll keep the old driver with my patch on top | 17:47 |
apw | tseliot, seems like a good first step to me | 17:48 |
tseliot | apw, ogasawara: ok, I've just uploaded the broadcom driver with my patch (in Precise) | 17:51 |
ogasawara | tseliot: awesome, thanks | 17:51 |
tseliot | yw | 17:56 |
tseliot | apw: thanks for testing | 17:56 |
apw | tseliot, thanks for fixing :) at least we have a full set of binary drivers before the kernel goes live, that must be a first | 17:57 |
tseliot | apw: hehe, nice :) | 17:57 |
iceroot | is it possible to build an amd64-kernel on an i386-cpu without amd64-instructions? | 19:42 |
iceroot | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502/comments/118 then i can provide here the amd64 version too | 19:43 |
ubot2 | Launchpad bug 869502 in linux "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed] | 19:43 |
iceroot | atm i am using skipabi=true skipmodule=true fakeroot debian/rules binary-iceroot and that is building i386 here | 19:45 |
ogasawara | smb: thanks for your review, I've reverted the "UBUNTU: SAUCE: xen: Do not use pv spinlocks on HVM" patch on Precise master-next. I'll rebase it out of existence at the next rebase. | 19:48 |
cdhm | Hi. I have done a lot of kernel building, but not withinb Ubuntu. What I want to do is build logfs as a module and load it. | 20:16 |
cdhm | There are a lot of howtos, each different, and different for various versions. So here is what I did: | 20:17 |
cdhm | mkdir /opt/ubuntu-kernel-src | 20:18 |
cdhm | cd /opt/ubuntu-kernel-src | 20:18 |
cdhm | sudo apt-get build-dep --no-install-recommends linux-image-$(uname -r) | 20:18 |
cdhm | apt-get source linux-image-$(uname -r) | 20:18 |
cdhm | cp /boot/config-2.6.38-12-generic-pae .config | 20:18 |
cdhm | make; make modules_install | 20:19 |
cdhm | That unfortunately builds and installs modules for 2.6.38.8 and not 2.6.38-12-generic-pae | 20:20 |
cdhm | Hints?? | 20:20 |
tgardner | cdhm, make oldconfig scripts prepare; make M=`pwd`/fs/logfs | 20:20 |
tgardner | cdhm, oh, first do 'fakeroot debian/rules prepare-generic-pae;cp debian/build/*/.confg .' | 20:21 |
cdhm | tgardner: So what's the order of operations... do the apt-gets, then do the fakeroot thing, then the make config, then make changes to .config to turn on CONFIG_LOGFS then make logfs. Is that correct? | 20:29 |
tgardner | cdhm, no, you want to change the CONFIG_LOGFS option in debian.master/config first, then the fakeroot thing | 20:31 |
cdhm | tgardner: Ok, so the order is:do the apt-gets, then nobble the debian.master/config then do the fakeroot thing, then regular make; make modules_install | 20:33 |
tgardner | cdhm, not regular make, e.g., 'cp debian/build/build-generic-pae/.config .;make oldconfig scripts prepare;make M=`pwd`/fs/logfs' | 20:36 |
cdhm | tgardner: So what then does the modules install? | 20:37 |
tgardner | cdhm, assuming you're running that kernel you can simply 'sudo insmod fs/logfs/logfs.o' | 20:37 |
cdhm | tgardner: Not that easy... logfs wants other modules installed too. Doing the depmod/install would be neater. | 20:39 |
tgardner | cdhm, well then perhaps you should just build the whole kernel and .deb, e.g., 'fakeroot debian/rules clean binary-generic-pae', then install the linux-image debian package that gets created. | 20:40 |
cdhm | So isn't there a middle ground without drinking the whole Debian KoolAid? | 20:42 |
tgardner | cdhm, not really. welcome to building kernels... | 20:43 |
cdhm | Hmmm. Building kernels for embedded is a lot more straight-forward with a quicker turnaround. | 20:46 |
Q-FUNK | howdy! would anyone have an ETA for applying the fix indicated for bug #892615 to the Precise kernel? | 22:04 |
ubot2 | Launchpad bug 892615 in linux "3.2.0-1-generic: completely fails to boot on Geode LX" [High,Confirmed] https://launchpad.net/bugs/892615 | 22:04 |
Q-FUNK | someone spotted an upstream commit that allegedly fixes it. | 22:05 |
tgardner | Q-FUNK, presumably it will show up in the normal course of development before 3.2 is released | 22:07 |
Q-FUNK | tgardner: it currently flat out prevents the kernel from loading. | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!