[12:53] <apw> if i am looking at a bug which is current filed against xserver-xorg-whatever, and i also think it may be kernel related, how do i go about adding the kernel task to the top
[12:53] <apw> is that 'also affects distribution' ?
[12:56] <smb_tp> apw, yes
[12:56] <Ng> is the upstream kernel fix for bug 207473 suitable for intrepid-updates? :)
[12:59]  * apw looks
[13:03] <smb_tp> apw, hm, wasn't that the patchset you posted on the kernel mailing list?
[13:03] <apw> yeah i think so, though for another bug ...
[13:03]  * apw checks
[13:07] <apw> bah the link to the patch is returning 'kernel.org is sick' messages right now, so i can't be 100% sure
[13:08] <apw> but ... Ng could you perhaps test the kernels listed in bug #257827, which seem to fix a similar double shift of brigtness and report back against that bug for me
[13:09] <apw> kernels are here: http://people.ubuntu.com/~apw/lp257827/
[13:09] <apw> we are looking for testing for those, to justify an SRU
[13:10] <Ng> apw: I was asking on behalf of someone else, but I'll certainly ask him to test
[13:10] <apw> thanks
[13:12] <apw> i have also noted the similarity and request for testing in this new bug
[13:27] <BenC> Anyone have anything last minute for jaunty kernel?
[13:27]  * BenC is prepping an upload right now
[13:46] <Kano> hi, could somebody fix the packageing of jaunty git? the new "ub" addon breaks the kernel-headers, target binary-headers
[13:48] <BenC> Kano: already working on it
[13:49] <Kano> btw. whats the correct way to fill in the changelog?
[13:50] <laga> git commits AFAIK
[13:50] <Kano> well there is only a placeholder
[13:50] <Kano> how to fill it with content?
[13:51] <BenC> Tells you on the wiki
[13:51] <BenC> but it's debian/rules insertchanges
[13:51] <Kano> thanks
[13:52] <_ruben> hmm .. what's the deal with the -virtual flavour having its files in -server? did those 2 flavours merge or smth?
[13:54] <_ruben> in intrepid that is
[14:00] <amitk> _ruben: -virtual is derived from -server
[14:00] <amitk> BenC: did the -ub changes look sane?
[14:01] <BenC> amitk: yeah, just fixed up linux-headers-x-x-x thought, and all seems good
[14:01] <_ruben> amitk: ah, so now its just a subset (module-wise) of -server? this a change between hardy and intrepid?
[14:01] <BenC> _ruben: yes
[14:03] <_ruben> ic, so -virtual would only give a smaller footprint (disk and possibly memory/security wise) .. wonder if i should just standardize my machines on -server for both physical and virtual machines
[14:11] <BenC> _ruben: right, -virtual is meant to be -server with a smaller disk footprint (mainly for virtual appliances)
[14:12] <BenC> _ruben: which for -virtual appliances may even result in a smaller memory footprint on the host side (if the disk is loaded entirely in memory for example)
[14:14] <BenC> 2.6.28-1.1 is in mid-upload
[14:21]  * amitk pictures BenC pushing through the last straggling driver bits to the upload server.
[14:44] <_ruben> BenC: does the same apply to hardy, since on hardy the files are in a -virtual dir, only cosmetic or does that kernel actually differ from the -server one
[14:47] <BenC> _ruben: it differs
[14:48] <BenC> _ruben: on hardy, -virtual is compiled from a separate config, on intrepid, -virtual is just built from the -server package
[14:49] <BenC> _ruben: unless 100Megs of disk really makes that much of a difference to you, I wouldn't even bother with -virtual
[14:58] <rtg> BenC: you sure what you have checked in for Jaunty is gonna build? I have a bunch of missing modules.
[14:59] <BenC> rtg: I added a modules.ignore...maybe it doesn't cover the x86 list
[14:59] <BenC> I only did the x86-64 build
[15:00] <rtg> well, this is 32 bit
[15:01] <BenC> rtg: What's the missing ones not accounted for?
[15:01] <rtg> there were 23 missing
[15:01] <BenC> rtg: right, but I assume some of them said "(ignored)" next to it
[15:01] <rtg> ok, there are 22 listed in modules.ignore, so likely its one other in the 32 bit build.
[15:02] <BenC> rtg: at the top of the module-check output it should list each one, and likely one doesn't have "(ignored)" next to it...do you have that handy?
[15:02] <rtg> BenC: I'll re-run it. Using screen it had scrolled off the top (and screen's scroll back sucks)
[15:02] <BenC> ok
[15:05] <rtg> BenC: looks like snd-cs4231-lib and snd-ad1848-lib. I'll add and verify
[15:08] <BenC> I canceled the upload, so I'll revert head and repackage the source
[15:08] <BenC> s/revert/reset/
[15:08] <rtg> BenC: ok, gimme a minute and I'll push the commit
[15:09] <BenC> I'll add it to mine, so I can reset the tag and everything
[15:09] <BenC> if those are the right modules
[15:10] <rtg> BenC: they seem to be.
[15:10] <BenC> rtg: Thanks
[15:33] <rtg> BenC: you should do a full 32 bit test build. kernel-wedge is bitching about missing modules as well, 'missing module dm-raid4-5'
[15:36] <BenC> damint
[15:48] <BenC> rtg: ok, a quick grep shows that to be the only one
[15:49] <rtg> BenC: I didn't dig any further. I'm totally annoyed that iwl4965 can't seem to work with an 802.11n AP.
[15:50] <BenC> rtg: in jaunty?
[15:50] <rtg> Intrepid LBM
[15:50] <rtg> I should force a Jaunty install to see what happens there
[15:52] <BenC> fixed up d-i and rebuild...I'll start a full 32-bit build now
[15:52] <BenC> rtg: current jaunty build should work now
[15:57] <apw> amitk, about?
[16:00] <apw> rtg isn't 11n some kind of separate compile option?  or is it not yet working?
[16:01] <rtg> apw: in Intrepif LBM you have to set HT (or something similar). Its short for High Throughput. I wonder what they'll call UWB? Really High Throughput?
[16:01] <apw> SooperDooperHT
[16:01] <rtg> perhaps UHT
[16:02] <rtg> BenC: 32 bit build looks like its gonna complete. its into the packaging phase.
[16:03] <amitk> apw: yeah?
[16:03] <BenC> rtg: how do you prep alsa for lum/lbm?
[16:03]  * BenC forgets the whole process
[16:03] <rtg> BenC: I'm not sure what you're talking about? Its part of the kernel since Hardy.
[16:04] <BenC> rtg: I need to update hardy-lum's alsa for lpia (separate tree from standard hardy)
[16:04] <rtg> BenC: uh, lemme refresh my memory. I think it was a serious pain in the ass.
[16:05] <BenC> that feeling came to mind when I started this...
[16:05] <BenC> I can't remember how to get the alsa-driver/alsa-kernel tree's output
[16:06] <BenC> actually, I see it
[16:06] <rtg> BenC: I think all you have to do is unpack the ALSA tarball. debian/rules.d/2-binary-arch.mk actually runs the configure phase.
[16:06] <apw> rtg, there is a bug on our list to fix up the wireless EU thingy ... i am assuming we are basically expecting the release notes to fix people on intrepid, and for jaunty that this is a UDS topic ... 
[16:07] <rtg> apw: you mean channel 13?
[16:07] <rtg> or is it 14? I forget
[16:25] <mkrufky> whats the correct way to signify that a bug filed in launchpad against "linux-ubuntu-modules-2.6.24 (Ubuntu)" also affects the intrepid kernel?
[16:25] <mkrufky> it looks like im supposed to file as "also affects LINUX" ... but how to signify specifically the intrepid kernel?
[16:26] <smb_tp> mkrufky, add also affects and then do a nomination for intrepid
[16:26] <mkrufky> hmm, ok will try this
[16:27] <apw> rtg, yeah the fact you need to tell the kernel you are on you are in the EU ...
[16:27] <apw> i am looking to 'resolve' the bug, as 'won't fix' in intrepid as we have a work around, and something that means UDS will fix it
[16:27] <rtg> apw: what do you know about the new firewire stack?
[16:28] <apw> heh not a whole heap other than we seem to have both in the kernel
[16:28] <apw> we have a bug on asking for the new one iirc
[16:28] <rtg> well, we don't have the new one enabled.
[16:29] <apw> yeah thats what i meant, that we have he src in the tree, but only the old on
[16:29] <apw> the bug i think asks for us to enable both and blacklist the new
[16:29] <rtg> apw: didn't pgraner have a session scheduled to talk about config options? I was gonna make sure it got into the list of notes for that session
[16:30] <apw> hmmm, yes i think so
[16:30] <CarlFK> apw: where/what about a firewire bug?  (I have been trying to figure out why cam corders randomly disconnect)
[16:30] <mkrufky> smb_tp: that worked, but now it has both hardy and intrepid listed under both linux and the LUM package...  how do i make the "linux (ubuntu)" nominate for intrepid, and "linux-ubuntu-modules-2.6.24" only for hardy?   to see what im talkiong about, this is bug #299671
[16:30] <rtg> mkrufky: https://bugs.launchpad.net/bugs/276463
[16:30] <smb_tp> mkrufky, open the unwanted one and mark it invalid
[16:31] <mkrufky> ok
[16:31] <apw> CarlFK, this was a bug only about asking for both to be enabled
[16:34] <mkrufky> ...maybe it wont allow me to mark the nominations as invalid while bug status is "new" ?
[16:35] <mkrufky> ok, well these are bugs that are fixed, and i have pending pull requests to hardy to fix them.....  i am about to push the same fixes into an intrepid branch and issue a similar pull request ...  should i mark them as "in progress" ?
[16:36] <mkrufky> i apologize for the newbie'isms to bug tracking :-P
[16:36] <smb_tp> mkrufky, could just be some user restrictions. since ubuntuid is absent, could you paste me the link?
[16:37] <mkrufky> https://bugs.launchpad.net/belmont/+bug/299671
[16:37] <mkrufky> yeah its in belmont, but i made the bug public, and it applies to hardy and intrepid as well as belmont
[16:38] <smb_tp> rtg, actually the nominations have to be approved first... ^^^ 
[16:38] <mkrufky> ah...  well i have a few other bugs that i need to do this to (add also affects intrepid) ...  should i do the same thing i did here to the remaining bugs?
[16:39] <smb_tp> mkrufky, which I also am not allowed to do
[16:39] <mkrufky> understood
[16:39] <smb_tp> mkrufky, yep would be some process
[16:39] <mkrufky> so, it is better for me to do this to the remaining bugs, or just leave them as-is without showing "also affects intrepid" ?
[16:40] <CarlFK> if Juju (new firewire) can be included in jaunty, I can do a bunch of testing next week.  Here is what I have so far: http://spreadsheets.google.com/ccc?key=pIfz0wOzPtW1E6KpNZ_9oUQ&hl=en#
[16:40] <rtg> smb_tp: done
[16:41] <mkrufky> oh!  thanks, rtg
[16:41] <smb_tp> mkrufky, maybe best will be note the facts in a comment and we'll have to sort it out
[16:41] <BenC> CarlFK: is this a third firewire?
[16:42] <CarlFK> BenC: um.. I dont think so
[16:42] <rtg> BenC: Juju is the v2 stuff
[16:42] <mkrufky> smb_tp:  ok... my intention was to send my "intrepid" pull request in a few minutes ... the commits reference the bug numbers, so i hope thats good enough ... i'll just add comments to the other bugs in text form stating "...also affects the intrepid kernel"
[16:42] <CarlFK> "new FireWire kernel driver stack (alias Juju)" http://ieee1394.wiki.kernel.org/index.php/Juju_Migration
[16:42] <rtg> CarlFK: doesn't Juju require a newer library?
[16:42] <BenC> CarlFK, rtg: Ah, I thought maybe someone rewrote my entire stack...again :)
[16:43] <smb_tp> mkrufky, Yes, in that case it should be enough to say once in the mail this also affect intrepid and possibly jaunty or whatever
[16:43] <mkrufky> will jaunty star at 2.6.28?  or is there a chance that might go to 2.6.29?   (i assume its too early to say for sure)
[16:43] <mkrufky>          ^ staY
[16:44] <BenC> mkrufky: too early to say
[16:44] <rtg> mkrufky: your assumption is correct
[16:44] <BenC> we'll probably do like we did with intrepid and have an ubuntu-next once .28 is released, and go from there
[16:44] <mkrufky> im hoping to get these patches into 2.6.28 via the -stable kernel series ....  but they will go into 2.6.29 naturally ....   so i will hold off on jaunty updates until it gets closer to release
[16:45] <CarlFK> rtg: no clue.  just saw the mention of it here.  I have been trying to nail down a dvgrab problem, and so have a bit of a test framwork setup right now.  so testing it will be 'easy' and might solve my problem too
[16:46] <rtg> CarlFK: looks like libraw1394 v2.0 handles either kernel stack.
[16:50] <CarlFK> I could probably find the source, build, swap out, test... but would rather that happen outside of my petri dish 
[16:54] <mkrufky> smb_tp: ...and one more final (small) headache for you .....   in preparing the intrepid patches i noticed three more tiny patches that need to be applied to hardy.  since that tree still hasnt been pulled yet, i'll just ass those 3 patches and send a new request.  On the bright side, I'm going on vacation after today, so no more patches from me for at least a week :-P
[16:55] <smb_tp> mkrufky, Well I am sorry to say that, but it has been. So those three will have to wait for next upload
[16:56] <CarlFK> BenC: so you know about the current firewire stack? :)
[16:57] <BenC> CarlFK: you mean drivers/firewire/ ?
[16:57] <mkrufky> smb_tp: oh, no problem then.... . thats actually better news .....  
[16:57] <mkrufky> smb_tp: its three trivial fixes that can wait until the next time i have a functional change ....  only one was important -- a typo in the license headers   (the code says GPLv3 but its actually GPLv2)
[16:57] <mkrufky> minor issue can wait
[16:58] <CarlFK> BenC: whatever it is I am using, which is causing random problems, mostly: ieee1394: Node suspended: ID:BUS[0-00:1023]
[16:58]  * BenC lubes up his internet connection hoping this upload will go faster
[16:58] <smb_tp> mkrufky, oh good, good. :) I quite happy the package is bundled now. So stack for next time is better for me
[16:58] <BenC> CarlFK: Ah, that's the standard drivers/ieee1394/ stack, which I do know a bit about
[16:59] <rtg> BenC: oh yeah - both Jaunty versions built. I'm running the 64bit one on my xps1330
[16:59] <BenC> rtg: sweet...64-bit booted on this XT with no problems, except for fglrx crashing in xorg
[17:00] <BenC> rtg: still uploading...
[17:00] <rtg> oddly enough, 802.11n works with i4965
[17:00] <BenC> rtg: and the alsa update was easy, just copied alsa-kernel, and then the rest of the source to alsa-driver and make a symlink to alsa-kernel there
[17:01] <rtg> I remember having a  lot of practive with that one once upon a time
[17:05] <CarlFK> BenC: 2 or 3 times a month starting in March I have been using dvgrab to record a few hours of user group presentations.  seems like every time I had some sort of problem.  last week I became active on the kino/dvgrab list and started testing.
[17:08] <CarlFK> I too am leaving for vacation - will be back tuesday.  
[17:13] <CarlFK> so the tit for tat is: if the v2 stuff is easy for me to test next week, Ill spend a fair amount of time testing it. 
[17:45] <alex_joni> anyone good with GPL license interpretation around?
[18:19] <BenC> 2.6.28-1.1 upload done finally
[18:25] <fransman> BenC: May i thank you !
[18:26] <fransman> I was again a lot of work
[18:27] <BenC> fransman: you may
[18:29] <fransman> Is it gonna get in the cue for PowerPC and Sparc as well
[18:31] <BenC> fransman: that will be linux-ports...this just coverts x86, x86_64 and armel
[18:32] <fransman> year , and what version will linux-ports be?
[18:45] <TheMuso> Linux-ports is following upstream releases, so since 2.6.28 is not officially released, it won't go 2.6.28 just yet.
[18:45] <TheMuso> At least I think thats what nCommander is doing.
[18:46] <TheMuso> BenC: Is lpia still going to be a separate kernel tree this cycle?
[18:46] <BenC> TheMuso: talk to amitk
[18:46] <TheMuso> BenC: Oh ok, was just curious.
[18:47] <BenC> Sorry, I don't have a good answer
[18:47] <BenC> he would know though
[18:47] <TheMuso> Right.
[18:47] <fransman> TheMuso:  upstream releases means the released Debian ones?
[18:48] <TheMuso> fransman: No, upstrea as in kernel.org.
[18:48] <TheMuso> upstream even.
[18:48] <fransman> ok that clear
[18:49] <BenC> fransman: our kernel is not based on debian's
[18:49] <fransman> i know it's your own git
[18:51] <fransman> does anyone know when the .28 rc are going into releasing ?
[18:52] <TheMuso> Whenever its ready I guess.
[18:57] <fransman> ok that's not so clear
[19:10] <BenC> fransman: it never is clear for upstream to set a hard date on a release
[19:49] <CarlFK> BenC: I asked Dean Dennedy (dvgrab author) "should I test Juju" he says "Yes, absolutely! Just make sure you have at least libraw1394 v2.0.0."
[19:50] <CarlFK> is there anything I can do to help get it into jaunty?
[19:51] <gregd> hello, is there a repository to use jaunty kernel in intrepid ?
[20:02] <asac> whats the best way to do a custom (hardy) kernel with just a patch on top ... i want to upload that to a PPA
[20:15] <fransman> gregd: Are you looking for http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git ?
[20:16] <gregd> fransman: exactly
[20:16] <gregd> but now, is there a ready repository to use to get the compiled version of the kernel?
[20:16] <gregd> or do I have to compile it by myself?
[20:19] <fransman> gregd: If it's build, it will be ready for install
[20:20] <gregd> fransman: so is ubuntu-jaunty kernel build?
[20:25] <fransman> gregd: please check https://launchpad.net/ubuntu/+builds in the next day's !
[20:28] <gregd> fransman: ok, understand that the kernel is being build, however then, once it is built, where can I find some information on how to install it in my intrepid?
[20:30] <fransman> gregd: please ask of the guy's here around
[20:31] <gregd> ok I will have to do it in the next day than, thanks a lot!