[12:53] 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] is that 'also affects distribution' ? [12:56] apw, yes [12:56] is the upstream kernel fix for bug 207473 suitable for intrepid-updates? :) [12:59] * apw looks [13:03] apw, hm, wasn't that the patchset you posted on the kernel mailing list? [13:03] yeah i think so, though for another bug ... [13:03] * apw checks [13:07] bah the link to the patch is returning 'kernel.org is sick' messages right now, so i can't be 100% sure [13:08] 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] kernels are here: http://people.ubuntu.com/~apw/lp257827/ [13:09] we are looking for testing for those, to justify an SRU [13:10] apw: I was asking on behalf of someone else, but I'll certainly ask him to test [13:10] thanks [13:12] i have also noted the similarity and request for testing in this new bug [13:27] Anyone have anything last minute for jaunty kernel? [13:27] * BenC is prepping an upload right now [13:46] hi, could somebody fix the packageing of jaunty git? the new "ub" addon breaks the kernel-headers, target binary-headers [13:48] Kano: already working on it [13:49] btw. whats the correct way to fill in the changelog? [13:50] git commits AFAIK [13:50] well there is only a placeholder [13:50] how to fill it with content? [13:51] Tells you on the wiki [13:51] but it's debian/rules insertchanges [13:51] 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] _ruben: -virtual is derived from -server [14:00] BenC: did the -ub changes look sane? [14:01] 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] _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] _ruben: right, -virtual is meant to be -server with a smaller disk footprint (mainly for virtual appliances) [14:12] _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] 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] _ruben: it differs [14:48] _ruben: on hardy, -virtual is compiled from a separate config, on intrepid, -virtual is just built from the -server package [14:49] _ruben: unless 100Megs of disk really makes that much of a difference to you, I wouldn't even bother with -virtual [14:58] BenC: you sure what you have checked in for Jaunty is gonna build? I have a bunch of missing modules. [14:59] rtg: I added a modules.ignore...maybe it doesn't cover the x86 list [14:59] I only did the x86-64 build [15:00] well, this is 32 bit [15:01] rtg: What's the missing ones not accounted for? [15:01] there were 23 missing [15:01] rtg: right, but I assume some of them said "(ignored)" next to it [15:01] ok, there are 22 listed in modules.ignore, so likely its one other in the 32 bit build. [15:02] 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] BenC: I'll re-run it. Using screen it had scrolled off the top (and screen's scroll back sucks) [15:02] ok [15:05] BenC: looks like snd-cs4231-lib and snd-ad1848-lib. I'll add and verify [15:08] I canceled the upload, so I'll revert head and repackage the source [15:08] s/revert/reset/ [15:08] BenC: ok, gimme a minute and I'll push the commit [15:09] I'll add it to mine, so I can reset the tag and everything [15:09] if those are the right modules [15:10] BenC: they seem to be. [15:10] rtg: Thanks [15:33] 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] damint [15:48] rtg: ok, a quick grep shows that to be the only one [15:49] 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] rtg: in jaunty? [15:50] Intrepid LBM [15:50] I should force a Jaunty install to see what happens there [15:52] fixed up d-i and rebuild...I'll start a full 32-bit build now [15:52] rtg: current jaunty build should work now [15:57] amitk, about? [16:00] rtg isn't 11n some kind of separate compile option? or is it not yet working? [16:01] 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] SooperDooperHT [16:01] perhaps UHT [16:02] BenC: 32 bit build looks like its gonna complete. its into the packaging phase. [16:03] apw: yeah? [16:03] rtg: how do you prep alsa for lum/lbm? [16:03] * BenC forgets the whole process [16:03] BenC: I'm not sure what you're talking about? Its part of the kernel since Hardy. [16:04] rtg: I need to update hardy-lum's alsa for lpia (separate tree from standard hardy) [16:04] BenC: uh, lemme refresh my memory. I think it was a serious pain in the ass. [16:05] that feeling came to mind when I started this... [16:05] I can't remember how to get the alsa-driver/alsa-kernel tree's output [16:06] actually, I see it [16:06] 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] 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] apw: you mean channel 13? [16:07] or is it 14? I forget [16:25] 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] it looks like im supposed to file as "also affects LINUX" ... but how to signify specifically the intrepid kernel? [16:26] mkrufky, add also affects and then do a nomination for intrepid [16:26] hmm, ok will try this [16:27] rtg, yeah the fact you need to tell the kernel you are on you are in the EU ... [16:27] 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] apw: what do you know about the new firewire stack? [16:28] heh not a whole heap other than we seem to have both in the kernel [16:28] we have a bug on asking for the new one iirc [16:28] well, we don't have the new one enabled. [16:29] yeah thats what i meant, that we have he src in the tree, but only the old on [16:29] the bug i think asks for us to enable both and blacklist the new [16:29] 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 === mdomsch is now known as mdomschbb [16:30] hmmm, yes i think so [16:30] apw: where/what about a firewire bug? (I have been trying to figure out why cam corders randomly disconnect) [16:30] 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] mkrufky: https://bugs.launchpad.net/bugs/276463 [16:30] mkrufky, open the unwanted one and mark it invalid [16:31] ok [16:31] CarlFK, this was a bug only about asking for both to be enabled === mdomschbb is now known as mdomsch [16:34] ...maybe it wont allow me to mark the nominations as invalid while bug status is "new" ? [16:35] 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] i apologize for the newbie'isms to bug tracking :-P [16:36] mkrufky, could just be some user restrictions. since ubuntuid is absent, could you paste me the link? [16:37] https://bugs.launchpad.net/belmont/+bug/299671 [16:37] yeah its in belmont, but i made the bug public, and it applies to hardy and intrepid as well as belmont [16:38] rtg, actually the nominations have to be approved first... ^^^ [16:38] 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] mkrufky, which I also am not allowed to do [16:39] understood [16:39] mkrufky, yep would be some process [16:39] 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] 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] smb_tp: done [16:41] oh! thanks, rtg [16:41] mkrufky, maybe best will be note the facts in a comment and we'll have to sort it out [16:41] CarlFK: is this a third firewire? [16:42] BenC: um.. I dont think so [16:42] BenC: Juju is the v2 stuff [16:42] 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] "new FireWire kernel driver stack (alias Juju)" http://ieee1394.wiki.kernel.org/index.php/Juju_Migration [16:42] CarlFK: doesn't Juju require a newer library? [16:42] CarlFK, rtg: Ah, I thought maybe someone rewrote my entire stack...again :) [16:43] 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] 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] ^ staY [16:44] mkrufky: too early to say [16:44] mkrufky: your assumption is correct [16:44] we'll probably do like we did with intrepid and have an ubuntu-next once .28 is released, and go from there [16:44] 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] 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] CarlFK: looks like libraw1394 v2.0 handles either kernel stack. [16:50] I could probably find the source, build, swap out, test... but would rather that happen outside of my petri dish [16:54] 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] mkrufky, Well I am sorry to say that, but it has been. So those three will have to wait for next upload [16:56] BenC: so you know about the current firewire stack? :) [16:57] CarlFK: you mean drivers/firewire/ ? [16:57] smb_tp: oh, no problem then.... . thats actually better news ..... [16:57] 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] minor issue can wait [16:58] 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] mkrufky, oh good, good. :) I quite happy the package is bundled now. So stack for next time is better for me [16:58] CarlFK: Ah, that's the standard drivers/ieee1394/ stack, which I do know a bit about [16:59] BenC: oh yeah - both Jaunty versions built. I'm running the 64bit one on my xps1330 [16:59] rtg: sweet...64-bit booted on this XT with no problems, except for fglrx crashing in xorg [17:00] rtg: still uploading... [17:00] oddly enough, 802.11n works with i4965 [17:00] 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] I remember having a lot of practive with that one once upon a time [17:05] 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] I too am leaving for vacation - will be back tuesday. [17:13] 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] anyone good with GPL license interpretation around? [18:19] 2.6.28-1.1 upload done finally [18:25] BenC: May i thank you ! [18:26] I was again a lot of work [18:27] fransman: you may [18:29] Is it gonna get in the cue for PowerPC and Sparc as well [18:31] fransman: that will be linux-ports...this just coverts x86, x86_64 and armel [18:32] year , and what version will linux-ports be? [18:45] 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] At least I think thats what nCommander is doing. [18:46] BenC: Is lpia still going to be a separate kernel tree this cycle? [18:46] TheMuso: talk to amitk [18:46] BenC: Oh ok, was just curious. [18:47] Sorry, I don't have a good answer [18:47] he would know though [18:47] Right. [18:47] TheMuso: upstream releases means the released Debian ones? [18:48] fransman: No, upstrea as in kernel.org. [18:48] upstream even. [18:48] ok that clear [18:49] fransman: our kernel is not based on debian's [18:49] i know it's your own git [18:51] does anyone know when the .28 rc are going into releasing ? [18:52] Whenever its ready I guess. [18:57] ok that's not so clear [19:10] fransman: it never is clear for upstream to set a hard date on a release [19:49] 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] is there anything I can do to help get it into jaunty? [19:51] hello, is there a repository to use jaunty kernel in intrepid ? [20:02] 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] gregd: Are you looking for http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git ? [20:16] fransman: exactly [20:16] but now, is there a ready repository to use to get the compiled version of the kernel? [20:16] or do I have to compile it by myself? [20:19] gregd: If it's build, it will be ready for install [20:20] fransman: so is ubuntu-jaunty kernel build? [20:25] gregd: please check https://launchpad.net/ubuntu/+builds in the next day's ! [20:28] 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] gregd: please ask of the guy's here around [20:31] ok I will have to do it in the next day than, thanks a lot! === thunderstruck is now known as gnomefreak