[00:01] I did all that [00:01] NCommander: Ok. [00:01] Very strange [00:01] Let me know when its ready to pull. [00:04] http://kernel.ubuntu.com/git?p=mcasadevall/ubuntu-jaunty-ports.git;a=summary - I pushed it, but I don't see the tag .... [00:10] TheMuso, oh, it seems tags aren't automatically pushed === asac_ is now known as asac [00:12] NCommander: aaaaahhhhh! [00:13] TheMuso, lets try that again [00:13] This is a nice learning experience. [00:13] I dunno fi I call the lack of automatic pushing of tags a feature or a bug [00:13] Its uploading now [00:13] Ok. [00:14] I call it a bug personally, but thats just me. [00:14] SOmeone should note that you need to git push --tags :-) [00:14] Yeah. [00:14] Its designed so if you pull someone elses branch, you don't get private tags from during release [00:14] wow, 10MB worth of tags [00:14] Linus has been busy ;-) [00:15] Ouch. [00:15] (ubuntu-ports tags are obviously enough Ubuntu-ports vs Ubuntu so we can't accidently get the same tag) [00:15] NCommander: Well you probably need to change the debian/rules files to look for those tags then. [00:15] Otherwise the insertchanges et al commands will fail. [00:15] Probably [00:17] TheMuso, that change is in my branch, once 1.1 is released, it will be available for 1.2 (or 2.1) [00:17] NCommander: ok. [00:24] TheMuso, TADA http://kernel.ubuntu.com/git?p=mcasadevall/ubuntu-jaunty-ports.git;a=summary [00:25] The changelog is amusingly long [00:25] and [00:25] I think incorrect [00:25] Damn it [00:25] Freaking insert changes pulled in stuff it shouldn't [00:26] actually, wait, it only grabbed 2.6.27->2.6.27.4 [00:26] Which is correct === CarlFK1 is now known as CarlF1 [00:27] NCommander: ok. [00:27] Ok, so just grab my branch, build a source package (with a orig.tar.gz), sign and upload [00:28] Will do. [00:53] NCommander: Do you want me to give it a test build on PowerPC hardware? [01:42] TheMuso, sure [01:42] (I tested it on my box, but I haven't tested it since fixing the other archs, but there were no code changes) [01:53] Right. [01:53] TheMuso, if you do, save the abi folder [01:53] We'll need to generate those on all architectures from this release forward, since we'll have lbm and lrm soon [01:53] NCommander: I'm building in an LVM snapshot with sbuild. [01:54] oh [01:54] Ok [01:54] I can grab it during the build however if you like. [01:54] Its not a priority until we start getting lrm and module packages [01:54] Is it created early on? [01:54] No [01:54] Towards the very end of the build [01:55] Right. [02:00] NCommander: actually I will build it manually, so I can get the ABI folder. [02:00] * NCommander nods [02:01] NCommander: I thought there was a bug opened for ports kernel in intrepid to not use gcc 4.1 for powerpc, yet I see it in the build-deps. [02:01] I haven't cleared it yet [02:01] 1.2 build task [02:02] ok [02:02] (doko wants to zap 4.1, once 1.1 is uploaded, that will be the first thing I do, since I need to make sure we don't have any nasty ices on any platform and still have working kernels) [02:02] i.e., I want a baseline to work against [02:03] Right. [02:34] NCommander: Kernels are cooking. [02:34] I thought I smelled something burning ;-) [02:34] * NCommander runs from the bad pun [02:34] It still made me laugh however. [02:35] Yay, 7 packages pending uploading (with an eight pending successful pbuildering) [02:35] * TheMuso slaps his head. I should have told it to use both CPUs to build faster... [02:35] -j2 is broken [02:36] Oh ok. [02:36] That solves that then. [02:36] It kinda works [02:36] But you get a weird race condition which causes dpkg to explode [02:36] Right. [02:36] I need to sit down and debug it at some point [02:36] I wonder if that can be sorted out. [02:36] Enviornmental variable which just passed -j to the kernel build [02:36] WHich is what is already implemented [02:36] Yeah I saw that. [02:36] (KERNEL_CONCURENCY_LEVEL or something) [02:37] Yeah. [03:19] NCommander: powerpc kernel cooked, powerpc-smp kernel now cooking. [03:21] * NCommander holds the extinisher ready [03:22] lol [03:37] NCommander: powerpc64-smp now cooking. [03:38] TheMuso, can you test run them? [03:38] NCommander: As in try to boot from them? Sure. [03:50] TheMuso, since we're on the topic of things to be done [03:50] TheMuso, can I get a few sponsoring on other packages? [03:56] NCommander: Sure. Shall we take it to a more appropriate channel? [03:56] motu or devel, your pick [03:57] NCommander: doesn't bother me, whatever suits you. [03:57] :p [03:57] \/c [04:47] Wow documentation takes a while. [04:50] TheMuso, yup [04:50] * NCommander should have told you to debuild -B [04:51] Oh well. [04:51] TheMuso, did you get your zinc acocunt fixed? [04:53] NCommander: Its in progress I believe. [05:05] NCommander: kernels done. [05:05] I can smoke test powerpc, and powerpc64-smp. I don't have a generic powerpc-smp box though. [05:05] now do they boot? [05:05] Bout to try powerpc64-smp. [05:06] powerpc-smp will work fine on powerpc, or on a powerpc64-smp box [05:06] Ok. [05:08] NCommander: booting into powerpc64-smp. [05:08] * NCommander crosses fingers [05:09] It boots. [05:11] Ok sound works, all disks present and correct, hrm not sure what else to check. [05:16] Good enough for me [05:16] The powerpc kernel been tested [05:16] testing powerpc-smp now. [05:16] TheMuso, just as a reminder, remember to leave my name on the changelog (on the bottom) so I get the build failure notices if any occur :-) [05:17] NCommander: since you fixed the changelog, that is not a problem. [05:20] hrm powerpc-smp doesn't want to boot. [05:20] on my G5./ [05:20] coooooool [05:20] yeah [05:20] it brings up a screen with a lot of OpenFirmware stuff, or thats what it looks like. [05:22] ok will try the powerpc and powerpc-smp kernels on my mini. [05:23] Hrm [05:23] the smp kernel might be hosed [05:23] haha and the old boot option is broken. Time to dig out a desktop CD from hardy... [05:23] I'll have to smash it with a stick but unless I can find someone with a 32 bit SMP box [05:26] TheMuso, maybe the -smp kernel for some ungodly reason tries to put the G5 into little endian mode which would crash and burn [05:28] possibly. [05:29] NCommander: what makes you think that? [05:29] Its the only thing that could possibly cause the kernel to fault all the way back into open firmware [05:29] NCommander: right [05:29] At least thats what I'm thinking [05:29] If it works on your mini, yay, if not [05:29] 1.2 :-) [05:30] * NCommander hears a gunshot [05:30] * TheMuso slaps his head. [05:30] I was trying to boot old on my mini, not the G5. [05:31] oh [05:31] Your mini crashed and burned [05:31] Nice :-/ [05:31] no [05:31] Wait [05:31] huh? [05:31] What machine failed to boot the smp kernel? [05:32] When I tried to boot into another kernel on what I thought was my G5, it didn't work, but it was on my mini. [05:32] Oh I see [05:32] the G5 failed to boot the powerpc-smp kernel. [05:32] * NCommander is resmoketesting the -smp kernel [05:32] I dunno why we have an non-smp/smp varient [05:32] Every other architecture is compiled to smp [05:33] Yeah I know what you mean. [05:34] THere may be issues with the smp kernel on non-smp PPC hardware [05:34] THats the only reason I can think of [05:34] The G4 made it through a full startup with the SMP kernel [05:34] (its a single chip box) [05:34] Right. [05:34] I think there must be hardware the SMP kernel crashes and burns with [05:35] TheMuso, I think we can write the issue as "Needs Investigation" and upload it [05:35] Ok. [05:40] TheMuso, I just had a brainwave [05:40] TheMuso, your mini might have faulted because the kernel uses OpenFirmware to determine the presence of a second processor [05:40] Want to be on your mini crashed and burned due bad OF information? [05:40] *bet [05:41] NCommander: it was the G5. [05:41] NCommander: not the mini. [05:42] Oh! [05:42] same point applies ;-) [05:42] Right. [05:42] But powerpc64-smp worked. [05:42] and powerpc-smp worked on non-smp hardware [05:43] We need someone with an SMP G4 [05:43] Yep. [05:47] ok powerpc works on the mini [05:49] so either smp is broken on smp hardware :-/, or smp is broken on smp64 [05:52] NCommander: NCommander Well 64-smp is fine, as I am now back on that with my G5, and both CPUs are showing. [05:52] I think infinity or lamont have to have a multicore non-SMP G5 [05:53] can you boot a powerpc kernel on your G5? [05:53] (maybe its a general 64-bit issue vs. smp) [05:53] NCommander: the powerpc kernel non-smp boots fine. [05:53] ok [05:53] We'll have to mark that on the Needs Debugging list [05:59] NCommander: powerpc-smp boots on mini. [06:00] woooo [06:00] so its just a 64-bit issue [06:01] sounds like it. [06:02] do we care enough to fix it at this very moment? [06:03] I don't. [06:06] * NCommander doesn't [06:13] NCommander: i have some things to do so I'll look further into this later. [06:13] TheMuso, the smp crash, or uploading ;-)? [06:13] NCommander: uploading. [06:13] ok, no [06:13] *np [07:32] ah, abogani [07:32] NCommander: Hi [07:33] abogani, I've been working on linux-rt-powerpc, and I found a rather disturbing problem [07:33] The current rt kernel in Intrepid isn't actually RT :-/ [07:33] :-? [07:33] (CONFIG_PREEMPT_RT is not defined) [07:34] and I can be blamed for it [07:34] * NCommander whacks head on the desk [07:34] No way: it is defined. [07:35] Nope [07:35] abogani, here's the debdiff [07:36] oh wait [07:37] bah [07:37] Screw me, I can't spell "PREEMPT" [08:05] morning smb_tp [08:06] Good morning NCommander [08:06] smb_tp, how goes your morning [08:07] NCommander, Good so far. :) Just got the first coffee. Saw your mail [08:08] smb_tp, TheMuso will be uploading the first ports kernel soon, and I'm bending linux-ports-lrm into shape :-) [08:10] NCommander, Sounds great. :) I guess I will give the mail some time today to be seen by others and then pull it to the repo. [08:11] \o/ [08:11] smb_tp, if you have sometime at some point to sit down with the ia64 config files, and figure out what things should be built as modules, it would be apperiated because then I can fix d-i for ia64 [08:16] NCommander, I only had a config that compiled (but had to discard serial-modules) and produced some udebs but whether this really is useful for the installer, I don't know. [08:16] smb_tp, someone who knows the hardware needs to sitdown and smash the kernel into shape :-/. Even HPPA has working d-i/udeb support and thats the architecture thats usually broken [08:18] NCommander, True. I will try to ask BenC whether he got a little time to help. At least he has the HW [08:18] Oh, I thought you had ia64 [08:18] d'oh [08:20] NCommander, No, I only have access to one (but only as user, so I can't install new kernels) [08:20] oh right === lamont` is now known as lamont [14:12] hello [14:12] does apt-get provide a static or dynamic kernel image for any given kernel? === smurfix is now known as smurf [15:04] hello [15:04] i got a problem [15:05] i can't change the brightness...the fn-keys and the applet in the panel doesn't work [15:05] i tested even now pre-release of fedora 10 and i could change the brigthness with the applet in the panel [15:15] F10 implements opregion support which is required for backlight control on a bunch of Intel graphics laptops [15:15] It'll be in 2.6.28 of the upstream kernel, but it's not in Intrepid [17:07] isn't there a libata option somewhere for verbose debugging output? [17:11] lamont: https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27 has finished building. this time it should _really_ fix your b44 issue. [17:12] rtg: and which suite does it show up in, I wonder? [17:12] intrepid-proposed? [17:13] lamont: yes. [17:13] kewl [17:14] lamont: adventurous souls such as yourself should always have -proposed enabled :) [17:14] heh. not. [17:14] well. maybe pinned at 25 :-) [18:05] rtg: I'm worried about the patch that fixes backlight key...it's not in upstream yet [18:06] BenC1: which patch? i have problems too witch backlight [18:07] drunkenkilla: what's the problem you are having? === BenC1 is now known as BenC [18:07] i can't change the brightness [18:08] i'm using ubuntu 8.10 and i can't change the brightness with the fn-keys and the applet in the panel [18:08] Could be fixed by this patch [18:08] but today i tested pre-release of fedora 10 and i could change the brightness with the applet, but not with the fn-keys [18:09] The case I'm fixing is where the brightness key causes two key press events [18:09] i will show you dmesg... [18:10] BenC: http://paste.ubuntu.com/67995/ [18:13] drunkenkilla: full dmesg would be better [18:15] BenC: http://paste.ubuntu.com/67998/ [18:29] re [18:50] BenC: when will come this patch? [18:51] drunkenkilla: not sure [18:52] BenC: You get an ACPI key event and an event from the keyboard? [19:46] what did you have to do to see KERN_DEBUG printks again? [20:05] Howdy kernel people. It looks like the current kernel compiling help on help.u.com assumes that the user is running Intrepid. I don't really know enough about kernel compiling to split out the directions, but this is the wiki diff that appears to be the culprit: https://help.ubuntu.com/community/Kernel/Compile?action=diff&rev1=69&rev2=61 [20:06] linux-kernel-devel is not on Intrepid and makedumpfile isnt on anything pre intrepid [21:02] mjg59: yeah [21:11] hey BenC [21:45] NCommander: hey [21:46] BenC, did you see my email to the list? [22:00] BenC: I suspect gnome-power-manager is the right place to handle that