=== bjf is now known as bjf_afk [09:43] smb, ok the kernel packages are in, so meta can be uploaded, would you do the honours [09:43] apw, sure [09:45] smb, in the normal place (i hope) [09:45] apw, yes it is [09:56] apw, From the debdiff it seems to add new suggest/recommend entries to control.common but not in control. Unfortunately that gets easily lost in the git tree. It will fix itself on build, but it would confuse a bit. Sorry, just saw that now. [09:57] smb, s'ok will have a look, rather get it right [09:58] apw, Right, actually that would probably be also something to go into the changelog as that change fixes a bug [10:00] smb, which bit fixes the bug? the removal of the delta control -> control.common or the adding of the recommends? === mdz_ is now known as mdz [10:01] apw, The addition of recommends [10:01] Recommend apport for linux-crashdump [10:01] [10:01] Bug: #391026 [10:01] yeah will make sure thats in the changelog [10:02] somehow it got lost that must be my erorr [10:02] this is why you are a good check for my packages :) [10:04] apw, Yeah, its always good to have the stupid/innocent second glance on it :) [10:05] i have learned a useful way to do a last ditch check this time round ... thanks [10:10] smb, ok ... updated the packages [10:11] apw, Looks fine to me now. Then I start upload. You will push? [10:11] smb, is pushed now (based on your ack there :) [10:12] apw, Got it :) [10:12] most excellent [10:15] apw, ubuntu installer san says "accepted" [10:16] hehe sounds good [10:27] apw: Speaking of the metapackage, I am happy to maintain a separate linux-ports metapackage, as the binary packages built from the meta won't be changing, and it means we update the kernels when the ports kernels are ready, separate from main arches. The metapackage is somewhat easier to maintain separately. :) [10:28] i assume we are still doing that :) as i don't see any ports arches in my lnux-meta upload [10:28] and yes that cirtainly sounds reasonable to me [10:28] I know that, and since I wasn't asked about that... But thought I'd double check [10:29] as they are likely to lag a little at least, cirtainly during this phase [10:29] yep [10:29] i don't see how that package hurts the admins either as its a single package and has a constant name, no newing required [10:30] yep [10:30] * apw calls that a decision and a plan [10:33] smb, ok i built something usnig the build tools .. .and its gone idle(last build failed) [10:34] is there a toy for finding the logs? [10:34] apw, There will be a build.log in the - dir [10:35] apw, the tool is ssh into the porter, I am afraid [10:35] heh ok thanks :) [10:47] smb, ok so how do i teach this thing about a group of machiens? [10:48] apw, You add a file in .ubuild/groups that contains the short names (or archs) you want to have in that group. Then you can use than (file-)name instead of a machine [10:48] nice [10:49] If you use the name of an arch, it would take just the first host it can find doing that arch [11:26] smb, does it know which ones are busy? [11:26] apw, It will check for status files, yes [11:27] so if i say build amd64 and my local builder is busy it will use ronne, sort of thign? [11:27] how does it define the order? [11:27] Err, no. not that intelligent [11:27] It will just tell you I am busy [11:27] damn [11:27] I was thinking of that feature but bacame distracted [11:38] hello everyone [12:18] kdub, hello there [13:46] apw: ping [13:46] pgraner, hi [13:47] apw: i saw your were working on the noveau kernel code... it blew up on me while it was trying to dkms-ify, known issue? [13:48] the nouveau stuff isn't in dkms? [13:49] apw: no it was but when I installed the ppa it tried to compile the dkms code and it shit itself [13:50] apw: I suspect the reason is cuz the code int he ppa was for .30 and the kernel I'm running is .31 [13:50] which ppa you using [13:51] apw: https://edge.launchpad.net/~xorg-edgers/+archive/nouveau [13:53] hrm so you are using the DKMS stuff for nouveau from there, not seen that even, in there is also my .30 nouveau kernel. most confusing [13:53] but yes, the chances of that dkms carrying forward with the level of drm change which occured is low [13:54] i'll have a look in a bit for the latest nouveau bits [13:54] apw: do you have a .31 nouveau kernel by chance? [13:54] not yet [13:54] apw: no worries, I have a card that is supposed to work with it and was trying to test kms [13:54] yep. and a good test it would be [13:55] apw: from now on when you update let me know and i'll run it thru its paces [13:55] sure [14:32] apw, I have a patch to fix the ia64 build (it got left out of Luke's tree because I accidently included config changes that were irreveleant to it). I sent a mail to the list but its stuck in a moderation queue [14:33] heh ... sounds pretty normal ... annoying list [14:33] ok so should i merge whats there, and wait for more, or just wait for more [14:33] apw, its a single patch, I think you merge what's there, then pop on my patch (I'm uploading it now) [14:34] NCommander, can do that [14:34] apw, I plan to work on sparc this weekend, I have the hardware, just a hosed install ATM [14:34] any idea what the sparc chroot issue is? [14:34] glibc isn't too happy on the porting boxes [14:34] Dunno why [14:34] WOrks fine on mine [14:34] (and my sparcs are two models earlier than whats in the DC) [14:35] apw, anyway, I hope to simply the ports tree down to one sparc kernel, and two powerpc kernels [14:35] hrm. is anyone looking at it? and i assume that affects the buildds too? [14:35] Which should make life much much easier for touching ports (although I need to fire an email, we accidently dropped support for Itanium1 machines w/ intrepid, not sure if we care enough to readd it) [14:35] apw, it only seems to affect dchroot, I'm not fully sure what's going on except it hangs hard [14:36] don't we use dchroot for the buildd builds also? === maxb__ is now known as maxb [14:36] apw, sbuild [14:36] apw, http://people.ubuntu.com/~mcasadevall/0002-UBUNTU-Upstream-Patch-to-fix-iommu-on-ia64-architect.patch [14:37] apw, if you want, I can kick the kernel tree after its merged into a devirtualized PPA [14:37] how do i get one of those setup i wonder, i could do with one which builds on all architectures for this very use [14:38] apw, talk to IS, but devirtualized PPAs build on the normal distro machines so they can block things building ina rchive [14:38] yeah ... but its the only way to do a proper test so someone in kernel should have one [14:39] apw, indeed. I've had one for ages, but it was never an issue for the kernel team before because the ports tree and the mainline trees were separate [14:39] Of course, now its an issue ;-) [14:39] does yours have just one machine in it? [14:39] as in one architecture?: [14:39] apw, its an all or nothing thing [14:39] Basically you get PPA only arches, or all of them [14:39] ahh i see [14:39] Yeah [14:40] apw, hopefully with this upload, this will fix ia64 d-i, and get CD images building again (which is nice because I have an ia64 desktop ;-)) [14:40] yeah there is some hope [14:42] apw, so everything except sparc should build now (sparc's config files need to be reworked, and the exclude modules updated, which is an annoying amount of drudge work) [14:42] but once done, it should just keep on going [14:43] apw, it looks like the linux-doc patch didn't make it into 2.6.31, is it still pending? [14:44] yes its still pending ... not forgotten, we should have no docs now is my understanding [15:20] Is there any sort of backport or whatnot of the creative x-fi modules for existing distros? Or should users wanting to use that soundcard with a release such as hardy just install their own kernels or manually build the modules? [15:30] hi [15:30] could someone have a look at https://bugs.launchpad.net/bugs/390292 ? [15:30] Malone bug 390292 in console-setup "undefined kernel key code ( in karmic a2)" [Undecided,Confirmed] [15:31] i can't boot my home machine because of the same problem [15:31] i've upgraded from jaunty to karmic [15:47] Kmos, that doesn't look like a kernel issue, they seem to be blaming some userspace code there. i am supprised its stopping you booting [15:49] apw: I tried to chmod -x console-setup and setupcon as cjwatson suggested but no luck [15:50] you still get the messages? [15:50] when I do dpkg-reconfigure console-setup it always show these warnings. [15:50] yes, i'm not at home right now, but there aren't no updates that fix it, i can boot in recovery, but not in normal mode [15:50] it hangs at setting console and font [15:52] you could try putting an exit 0 at the top of the console-setup script to ensure it does not execute [15:53] but its not obvious how setupcon could run if its -x [15:54] you might need to do the same to console-screen.sh (add an exit 0 to the top there too) [15:54] that also does stuff with the console if setupcon is not avaialble === cjwatson_ is now known as cjwatson [16:05] Kmos: for the avoidance of doubt, I did *not* advise you to chmod -x /etc/init.d/console-setup and /bin/setupcon [16:05] Kmos: I advised you to use 'set -x', which is a command you put in a shell script to turn on execution tracing [16:06] Kmos: but, if you did 'chmod -x', then that pretty much proves that it isn't actually console-setup causing a problem after all, but rather whatever runs directly after console-setup, I'd have thought ... [16:16] cjwatson: I didn't know about the 'set -x' command. sorry.. I made the -x and it also breaks. but the problem of dpkg-reconfigure console-setup giving that warning messages? [16:16] apw: I need to try that at home [16:16] is entirely unrelated to your boot trouble, and not a high priority [16:18] I don't know what's breaking it, because setting debug=vc and remove quiet and splash didn't show anything [16:18] and dont know how to debug it better [16:19] maybe the only solution is to reinstall :-( [16:19] find the thing after console-setup and debug that with set -x [16:19] (you'll need debug=vc and remove quiet/splash to get useful output there) [16:20] or debug /etc/init.d/rc with set -x to make absolutely sure of which script is being executed at the point of the hang [16:20] I need to -x the script at rcS.d after the console-setup [16:20] right? [17:05] apw, compcache source comes with scripts to load and unload the modules, do we need to ship these userspace scripts somehow ? [17:06] i am sure we don't in the kernel [17:06] i am sure whatever uses it knows how [17:06] ubuiquity or whatever [17:41] manjo: it's already integrated in initramfs-tools and casper [17:41] k === akgraner_ is now known as akgraner [18:27] apw: ping, that audio bug from yesterday is 394014 FYI [18:42] cking: Where does the source for the hpmini kerneld driver live? I'm sure I'd found it at some point, but now I can't [18:52] mjg59: gimme 5... [18:52] Ah, I've found a tarball with it [18:55] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=shortlog;h=refs/heads/netbook-lpia-dennis [18:55] Ah, wonderful [18:56] Thanks! [18:56] no probs [18:56] Didn't catch that it was under a different branch [18:56] yeah. What are you gonna do with it? [18:56] Was planning on adapting it to rfkill [18:57] Huh. git will give me the pretty version, but asking it for the raw blob gives me a 0 length file [18:57] great! [18:58] ? [18:58] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=blob;f=ubuntu/misc/hpmini.c;h=03b24dd7f18093bdae155b4df04d38616ffc1b62;hb=refs/heads/netbook-lpia-dennis [18:58] Clicking on "raw" gives me nothing back [18:58] And clicking on "HEAD" gives me 403 [18:59] mjg59, HEAD has the same results for me. But raw pops up a save window... [19:00] smb: Does it actually save anything, or is it just sending headers and no content? [19:00] mjg59, Ah, ok. I see [19:02] Oh, hang on [19:02] It's the same GUID as hp-wmi [19:02] Heh. It's an entirely unnecessary driver :) [19:22] Hi all, I have a question regarding a mac address flip flop reported by arpwatch, is this a rigth place to ask? [19:29] could someone with the power please fish my mail from the kernel-team moderation queue? [22:30] apw: you around?