[00:01] See, this is why I suggested you attach it to the bug when it's done :) [00:01] persia, rofl [00:11] persia, I had to run updateconfigs for a new configuration option. I'll have to re-test build it :-/ [00:14] NCommander, Well, at least your processor will get some exercise :) [00:15] Yeah yeah :-P [00:15] persia, I might be wrong on needing to rebuilding it [00:15] Hrm? [00:15] The build finished regardless [00:16] * NCommander will do a second smoke test on the build [00:17] reboot time [00:22] persia, I can confirm the -rt kernel works [00:22] persia, what was that bug number again? [00:22] 289683 [00:22] * NCommander is 99.9% sure that the second rebuild test is not necessary but I'm not willing to risk it this close to release [00:23] Thank you for the extra care. It's not default on the CD, but I'm fairly sure we only get one chance to upload before it becomes an SRU. [00:24] persia, I'm having trouble now, I think the linux-rt sources tainted my /usr/src package [00:24] * NCommander is getting patching failures [00:24] It's designed to be built under sbuild :) [00:24] You know [00:24] there is an easy solution [00:25] * NCommander shoots it to his PPA [00:25] If it builds there, I'm satified [00:25] Yep. That's a nice clean sbuild. Takes about an hour to build for a PPA. [00:25] persia, I didn't think of it before cause I'm usually working on the ports kernel [00:25] and away it goes [00:26] I think that's 90% of the reason that -rt doesn't also target powerpc [00:26] persia, thats going to change for jaunty [00:26] * NCommander already has it on the TODO list [00:26] Good. It's a frequently requested feature. [00:26] I need to get the normal ports kernel up to shape before studio can get some love [00:27] persia, I'm also talking to jdong on the possibility of backporting the ports kernels (as a different binary package so it won't be an auto upgrade) so studio users don't have to wait for 9.04 [00:27] You mean ports users? [00:28] Well, linux-rt-backports :-) [00:28] and linux-ports-backports [00:28] The powerpc varient of rt should build out of the linux-rt source package, having that changeset in the ports kernel will likely break things miserably :-/ [00:29] Definitely. Unless -rt goes mainline, I think the current architecture makes sense, although it's annoying to have to upload a new -rt every time -generic is uploaded. [00:29] persia, man, LP is lagging tonight, I still haven't got an ACCEPT or REJECT on the rt upload to PPA [00:30] persia, agreed. Talking with the rest of the kernel team, they also agreed [00:30] * NCommander brought it up at the last meeting [00:31] persia, the only problem is the rt kernel doesn't support SMP last time I checked, so its still somewhat limited on PowerPC [00:31] No, it's somewhat limited *everywhere*. It supports SMP on 2.6.26, but 2.6.26 has all sorts of other issues. [00:32] Ew [00:38] persia, good call on my part. FTBFS :-P [00:40] NCommander, That you find that a good call is an indicator that your glass will always be half full :) [00:41] persia, well, paranoia, especially with kernels and RC freeze is a healthy thing [00:42] Indeed :) [00:42] probably monday is the last day we get any uploading in [00:43] Considering how long it takes to populate dak, and test images... [00:43] It's been Monday for nearly 14 hours ... [00:43] (at least somewhere) [00:49] * NCommander sends it to the PPA again [00:51] persia, I'm also testing in pbuilder, so we should be good to go soon-ish [00:51] Excellent [00:52] persia, I'm just glad to do my bit for studio [00:52] I know better than that : you just want to join every team on launchpad ;p [00:56] I think its called NCommander has heaps of time now, but may not in the future. :p [00:57] TheMuso, actually, I'm not taking classes for winter quarter, so I'll actually have more time in the future [00:58] Cool. [00:58] * NCommander HATES updateconfigs [01:05] * nigel_c gets ABI differences even with a simple checkout of the right git tag. Maybe it's because I'm still using Hardy gcc. [01:06] nigel_c, that would do it [01:08] k. [01:09] It's only a few symbols - memcpy, __memcpy and something else I've forgotten, but still .... [01:10] I've nearly got my ppa sorted - some cleanups, pushing a patch upstream and remove a small feature. Still have one new symbol I can't do anything about, but that doesn't seem to kill the build. [01:10] Thanks for your help the other day, NCommander [01:11] nigel_c, what did I do? [01:25] I forget now, but it was helpful :) [01:25] lol [01:25] Oh [01:26] I think I taught you about bumping the ABI [01:26] mm. that souns right [01:26] oops one handed typing while eating lunch :) [01:26] lol [03:42] hey BenC1 === BenC1 is now known as BenC === asac_ is now known as asac === thegodfather is now known as fabbione === asac_ is now known as asac === asac_ is now known as asac === Keybuk is now known as Guest49306 === Keybuk_ is now known as Keybuk [09:47] * abogani waves [09:47] tseliot: Are you around? [09:49] abogani: sure [09:49] tseliot: Sorry to bother you. Only one question about DKMS/video... [09:49] ok [09:50] tseliot: How can I simulate fglrx dkms build process (obviously i don't have that hardware)? [09:50] for rt kernel [09:50] abogani: you don't need a specific device to build a module [09:51] abogani: you will have to install nvidia-VER-kernel-source [09:52] and if you want to build the module manually (i.e. without booting into a kernel for which you want to build a module) [09:52] you can type something like: [09:52] sudo dkms add -m nvidia -v 177.80 -k $(uname -r) [09:52] sudo dkms build -m nvidia -v 177.80 -k $(uname -r) [09:52] sudo dkms install -m nvidia -v 177.80 -k $(uname -r) [09:53] Put log somewhere? [09:53] yes, /var/lib/dkms/nvidia/177.80/build/ [09:53] (replace 177.80 with the version of the driver) [09:53] it's in the make.log [09:54] tseliot: Wow! Thanks a lot! [09:55] abogani: you're welcome === mdz_ is now known as mdz [11:34] i am trying to determine the source of broken alsa sound (crackles, OSS works) in the latest intrepid kernels, both of the reporters seem to have intel hda sound. so am wondering if anyone has working alsa sound, and if so which sound h/w they have [12:01] hello,where is the definition of "get_user" in x86? [12:03] fqh: include/asm-x86/uaccess_*.h [12:08] Oh, I see. But it is strange that linus-git has no a asm-x86 now. [12:08] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=include;h=0fd53c2abd87c28d05796ebe9c139678917a593b;hb=f8d56f1771e4867acc461146764b4feeb5245669 [12:11] haven't they moved into arch now [12:11] arch/x86/include/asm or something [12:11] fqh ^^ [12:13] fqh: arch/x86/include/asm$ vi uaccess.h [12:13] oops, meant: arch/x86/include/asm/uaccess.h [12:13] yes. I see it. :) [12:36] for getting fixes modules in hardy it has to go in linux-backport-modules correct? [12:37] zul: it depends. is it an existing module in LUM? [12:38] its drbd [12:39] so im assuming no [12:40] zul: it doesn't sound familiar, but then there are a bunch of drivers in Hardy LUM. Is this something we _want_ to support? [12:41] rtg: yeah we support it already, the reason Im asking is there is a push to update drbd to a newer version as a hardy SRU (not by me) and afair there is an ubuntu/drbd in the ubuntu-hardy git tree so if I get asked about Ill have the information [12:43] zul: ah, then you'll have to propose it on the kernel team list, and provide some corroborating evidence that it fixes real problems. [12:43] rtg: yep ok thanks [13:08] tjaalton, tseliot, superm1: Could you push the attached patch for bug 286961, please? [13:08] Morning [13:08] abogani, we're in final freeze, nothing can be pushed to the archive at this point [13:13] abogani: you might want to talk to superm1 about this (for an SRU) in #ubuntu-devel [13:14] tseliot: Ok, thanks. [13:14] morning tseliot, BenC [13:14] NCommander: good morning [13:14] tseliot, how goes it [13:15] fine [13:15] Thats a good way to start out ones morning :-) [13:15] NCommander: good morning [13:15] NCommander: BTW my patch for abiword was accepted by upstream [13:15] BenC, morning! You'll be pleased to know AppArmor has landed for ports ;-) [13:15] tseliot, woo! [13:17] BenC, so has squashFS, AuFS, a bunch of bug fixes, compcache, pretty much everything useful out of the normal ports branch [13:17] s/ports/main/g [13:17] NCommander: nice [13:17] NCommander: busy weekend? :) [13:18] BenC, You could say that. I also got my first round of rt hacking (a very last minute rebase against modern kernel sources) [13:19] * NCommander is also adding powerpc support to -rt :-) [13:19] NCommander: you're not patching ports directly with -rt are you? [13:19] No [13:20] with abogani's permission, I'll have it grab a ports tarball, and build against the ports kernel on powerpc (and arm/mips if we ever get those architectures in the DC) [13:39] rtg: you made the last kernel image i believe. i have been debugging the alsa sound issues some of us have been seeing with intel sound. i just rebuilt the kernel and install just that one module and my sound is working now. so i am trying to fathom how we have ended up with different modules from that process [13:40] apw: which one in particular? hda? [13:40] yeah hda, snd-hda-intel [13:41] apw: perhaps its an ordering issue. [13:41] i was doing a bisection on it from 2.6.24 [13:41] and ended up with all the patches installed, with the tree at our git HEAD [13:41] did the bisect converge? [13:41] now i did build it using make [13:41] with what config? [13:42] i found sound worked at 2.6.26 and 2.6.27 and indeed then at our latest HEAD [13:42] the one from /boot/ for the latest intrepid kernel /boot/2.6.27-7-generic [13:43] my module is massive compared to yours [13:43] 3.4M against your 815k, so its clearly not compiled the same way [13:44] apw: I imagine its more of an ordering issue then it is a code generation problem. [13:45] a bit of a pig to debug me thinks ... [13:45] i guess my next step is to build this kernel the way the tools do insteal [13:45] apw: have you talked to the ALSA guys about it? [13:46] not yet, only just confirmed its a kernel issue [13:46] where would you suggest i go to find them [13:46] apw: alsa-devel@alsa-project.org [13:49] apw: amd64 or i386? [13:49] this is amd64 [13:49] and my kernel build was on amd64 [13:49] * apw prays this is not a toolchain bug breaking the kernel [13:50] apw: describe your build process. I assume you cloned the git repo, copied the config, then 'make' [13:50] make oldconfig; make [13:50] then i literally copied the .ko into the installed kernel [13:50] dpkg -l|grep gcc [13:51] i have 4.2 and 4.3 installed it seems [13:51] defualt compiler seems to be 4.3 [13:51] 4.3.2-1ubuntu11 [13:52] apw: gimme a bit. [13:52] rtg np ... will go see if it can build it your way === Keybuk_ is now known as Keybuk [14:35] Error(/tmp/buildd/linux-ports-2.6.27//drivers/scsi/scsi_transport_fc.c:509): cannot understand prototype: 'atomic_t fc_event_seq; ' [14:35] ANy idea whats causing that? [14:35] ^- amitk, BenC, [14:39] NCommander: sounds like a missing include [14:39] It compiles fine :-/ [14:39] argh [14:39] NCommander: what patch introduced that problem? [14:39] I dunno [14:39] It compiles just fine [14:52] B [15:04] rtg ok built the kernel using debian/rules binary-generic, the .ko that made seems to work too [15:05] apw: when you run alsamixer, are you seeing only one output control? [15:05] yes only master [15:05] though in the gnome tools there are several [15:06] apw: well, none of those work for me. [15:14] rtg: not sure whats not working for you there? [15:15] * apw hits the build process with bigger hammers [15:21] rtg, even the stripped version of the .ko which gets built to make the .deb's (which is more the size of yours) seems to work ok [15:22] apw: I think this is an app space issue. I'm having problems on laptops that used to work. [15:23] How does docbook parse the source code [15:24] rtg, i have working sound with the hardy kernel and not with 'your' intrepid kernel with the same userspace, and here i am only changing the module. but i guess this doesn't rule out a userspace library and some luck making it work for me [15:31] Hi. I'm trying to debug a suspend issue, but I'm not sure if I'm looking at a bug or not (I think I am). [15:32] `echo standby >/sys/power/state` leaves the machine running with display still on after disabling devices. [15:32] That is not normal, is it? [15:32] The machine does seem to be "paused," in a way, and it correctly comes out of this state with normal wake interrupt activity. [15:36] BenC, I solved it, there was a comment above the struct that went /** [15:36] BenC, stupid docbook :-/ === thegodfather is now known as fabbione [16:22] Looking for kernel-team Openweek sessions: https://wiki.ubuntu.com/UbuntuOpenWeek [17:48] rtg: ok things just got wierd here, i just got a request from update-manager to install the -7.14 kernel again so i let it [17:49] and now sound works, even though the module is identicle to the 'non working one' [17:49] so i suspect that adds credance to your suspicion its userland [18:13] rtg "its back" ... [18:14] so its actually intermittant, so all my testing is meaningless [18:54] BenC, do you know anyone with ia64 boxes? (I have the ia64 kernel more or less building, but I have no idea how to setup ski, so I'm hoping to find someone who is willing to test these :-) [19:02] I have one, but it is powered off atm [19:16] BenC, handy. I should see if I can pick a cheap ia-64 for myself at some point ;-) === doko_ is now known as doko