[00:20] <jewsucanuse> hi, if i wanted to disable a kernel flag, would that take a full 2 hour reroll or could i just build the network stuff?
[06:27] <LLStarks> i'd like to request a kernel rebase against the iwlwifi-2.6 git. over the past week, there has been a major commit to the tree that fixes the 3 year-old speed issue with iwl3945.
[06:27] <LLStarks> http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=commit;h=0d8e0e28a27779f480adb6674ca5fc29879a2080
[13:25] <mpoirier> sconklin ?
[13:25] <sconklin> mpoirier: yes?
[13:26] <mpoirier> good morning - the armel build for proposed is broken
[13:26] <mpoirier> hold on.
[13:27] <mpoirier> fixing lp 645689 broke it.
[13:27] <ubot2> Launchpad bug 645689 in linux (Ubuntu Maverick) (and 1 other project) "linux-omap cant bring up eth0 on igepv2 board, no network (affects: 1) (heat: 94)" [Undecided,Fix committed] https://launchpad.net/bugs/645689
[13:27] <sconklin> mpoirier: sigh. OK, thanks. what are the symptoms of the failure?
[13:28] <mpoirier> I will fix it but after I file an SRU for it  or there is another process ?
[13:28] <mpoirier> its in the packaging steps.
[13:28] <sconklin> thinking
[15:16] <mpoirier> sconklin: you on ?
[15:18] <sconklin> mpoirier: yes
[15:19] <mpoirier> who would know the arguments that are given to the build to generate the armel image found in the archive ?
[15:20] <mpoirier> I just did an fdr binary-omap and that worked properly.  I therefore have to assume the archive build is started differently.
[15:23] <sconklin> mpoirier: what we've just discovered in the last 5 minutes is that the patch to "temporarily disable module check for armel" is incorrect, so we can fix it without any changes from you. I'm sorry for the fire drill for you
[15:23] <mpoirier> So I don't need to do anything for you then - right ?
[15:25] <sconklin> mpoirier: that's correct - no action required from you. Sorry to get you spun up.
[15:26] <mpoirier> ok, when should I expect the armel image in -proposed to show up so that I can test the changes as requested ?
[15:36] <repete> Can anyone tell me if rw to an NTFS volume is still experimental?
[15:36] <repete> I noticed "CONFIG_NTFS_RW" is not set in the default kernel
[15:36] <repete> but I could swear I could copy files to an NTFS partition...
[15:41] <jk-> repete: from CONFIG_NTFS_RW:
[15:41] <jk-> The only supported operation is overwriting existing files, without
[15:41] <jk-> 	  changing the file length.  No file or directory creation, deletion or
[15:41] <jk-> 	  renaming is possible. 
[15:41] <jk-> so I'm guessing this isn't what you would have used
[15:42] <jk-> maybe ntfs-3g? this a fuse FS for NTFS read/write
[15:43] <repete> jk-: thx.  Was just looking at that as the former seemed odd.
[15:44] <repete> jk-: btw are those comments in the config from the kernel source package?  I'm just looking at /boot/config-2.6.35-22-generic
[15:44] <repete> and there doesn't appear to be any comments
[15:45] <jk-> repete: no problem
[15:45] <jk-> they're in the kernel tree itself, fs/ntfs/Kconfig
[15:46] <jk-> (so yes, kernel-source)
[15:47] <repete> good old wikipedia.  That cleared things up. :-D
[15:48] <repete> Answer: It's complicated...
[15:48] <jk-> :)
[22:23] <persia> apw, Just a follow-up on hardware-kernel-n-version-and-flavours: I thought I remembered an action item for someone to document how community-supported flavours should be uploaded or processed, but I don't see it listed.  Is that planned somewhere else?
[22:24] <persia> sconklin, Alternately, would that be part of "document officially supported flavours on a per release basis and who is responsible for those (eg ti etc)" ?
[22:24] <apw> persia, not the latter
[22:25] <persia> I'd presume that folks supporting kernels would have to integrate into such a thing for the future, though.
[22:25] <apw> [apw] write a skeleton document for outside consumers to reference for migrating from older versions/flavours:TODO
[22:25] <apw> #
[22:26] <apw> persia, the above is suspected to mean that, though the words suck
[22:26] <persia> OK.  I thought that meant handling the cases for kernels planned to be dropped entirely.
[22:26] <persia> (e.g. -versatile)
[22:26] <apw> hrm maybe so, there is no notes for that
[22:26] <apw> i'll add one
[22:27] <persia> Thanks.  I've had two people ask me when it happens already, and been answering "We'll have some more information soon", and just wanted to make sure it was actually being tracked.