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