[00:31] <komputes> Sarvatt: awesome, thanks
[00:32] <komputes> Sarvatt: ATI will show 'drm'?
[00:32] <Sarvatt> ati/intel have drmfb's nouveau only has KMS
[00:32] <komputes> ah yes - [drm] radeon defaulting to kernel modesetting.
[00:32] <Sarvatt> its looking for nouveaufb or drmfb
[00:33] <komputes> Sarvatt: sorry, confused. again from the beginning.
[00:34] <komputes> /proc/fb contains a list of frame buffer devices, with the frame buffer device number and the driver that controls it
[00:34] <Sarvatt> yeah if nouveaufb or any of the drmfb's are in there it's using KMS
[00:35] <komputes> Sarvatt: and just to be clear those drmfb's are inteldrmfb, nouveaufb, radeonfb
[00:35] <Sarvatt> nouveaufb radeondrmfb or inteldrmfb
[00:35] <komputes> cool, thanks Sarvatt 
[00:40] <Sarvatt> no problem, also I forgot but vmwgfx is svgadrmfb as well
[00:47] <komputes> Sarvatt: which are?
[01:45] <ripps> Can someone please mentor me with l-b-m? I want to add an updated wacom module fix problems with new wacom bamboo tablets. I've already discussed this and submitted a proposal on the mailing list, but nobody has responded. See bugs #568064 and #606278
[01:45] <ubot2> Launchpad bug 568064 in linux (Ubuntu) "Wacom new bamboo models are not recognized in Lucid (affects: 19) (heat: 101)" [Undecided,Confirmed] https://launchpad.net/bugs/568064
[01:45] <ubot2> Launchpad bug 606278 in linux-backports-modules-2.6.35 (Ubuntu) "Add linux-backports-modules-input (affects: 6) (dups: 1) (heat: 42)" [Undecided,New] https://launchpad.net/bugs/606278
[01:46] <ripps> Since I can see any sign of anybody working on this, I wanted to know if somebody can help me write a patch instead. I've taken a look at the l-b-m source, but it's so complicated I can't really make much sense of it.
[01:46] <ripps> *don't see any sign
[01:49] <ion> It might be nice to have CONFIG_COMPACTION on.
[01:51] <ripps> I'm not some noob with packaging, I was just hoping somebody give me some hints or guidance on how to start adding a new component to l-b-m
[02:41] <Sarvatt> ripps: does l-b-m make sense for something thats not a backport? what's wrong with your dkms package?
[02:42] <ripps> Sarvatt: nobody would accept it. MOTU's said to try and get it into Debian, and Debian said that it was just working around a problem with the kernel. Problem is, the linuxwacom project isn't updating their wacom kernel source because apparently their refactoring it or something.
[02:44] <ripps> After discussing it here, I was advised to propose an addition to linux-backport-modules. But apparently, nobody wants to help me get in there, either.
[07:21] <tjaalton> any known regressions in the current lucid kernel? I 
[07:21] <tjaalton> hrm
[07:22] <tjaalton> I'm unable to do a full install (~2500 packages) anymore, since dpkg sees some packages are corrupt (same size, different md5sum as on the archive)
[07:23] <tjaalton> or when unpacking some config stubs in /tmp are missing etc
[07:23] <tjaalton> maybe I should try with ext3 to rule it out
[07:30] <tjaalton> ah, actually.. the installer image is the release one :)
[07:30] <tjaalton> the one that worked was from March
[07:34] <tjaalton> though the corruptness happens on an installed system as well, and that has the latest kernel
[08:47] <apw> /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
[08:59] <era> hi ogasawara, is anything being done to implement this? https://bugs.launchpad.net/ubuntu/+source/ndiswrapper/+bug/590090/comments/7
[08:59] <ubot2> Ubuntu bug 590090 in ndiswrapper (Ubuntu) (and 1 other project) "package ndiswrapper-dkms 1.56-1 failed to install/upgrade: ndiswrapper kernel module failed to build (affects: 40) (dups: 3) (heat: 206)" [Medium,Confirmed]
[10:32] <apw> if ! git remote | grep FOO >/dev/null; then echo NO; fi
[12:33] <tumbleweed> can anyone suggest things to try and get useful debug information? Got a user who's USB controller seems to hang ~once a day (leaving him without working keyboard and mouse). Nothing interesting in kernel/X logs, and lsusb hangs on open("/dev/bus/usb/002/005")
[12:34] <tumbleweed> nm that, after a while, starteg tetting task blocked messages in kernel logs
[13:29] <Ejdesgaard_> hi, is there any chance that https://bugzilla.kernel.org/show_bug.cgi?id=16315 will be backported to 10.04 LTS?
[13:29] <ubot2> bugzilla.kernel.org bug 16315 in i386 "icebp (opcode 0xf1) no longer causing a SIGTRAP, breaks Wine" [Normal,New]
[13:30] <smb> Ejdesgaard_, If the patch goes upstream as a stable patch it will come back as soon as upstream stable picks it up
[15:07] <JFo> lag, the picture is up on my Facebook
[15:09] <JFo> sent to you in e-mail
[15:30] <lag> JFo: That's awesome!
[15:30] <JFo> :)
[15:40] <lag> JFo: http://people.canonical.com/~ljones/lastsupper/
[15:47] <JFo> nice!
[15:48] <JFo> not a bad approximation
[15:55] <lag> It's there or there abouts 
[15:55] <lag> Someone is facing completely the wrong way and I'm a few degrees off
[15:55] <lag> Overall I think we did okay :)
[15:56] <vanhoof> lol!
[15:57] <vanhoof> you guys werent kidding around :D
[15:57] <Ejdesgaard_> smb, it was included in .35-rc4
[15:58] <bjf> ##
[15:58] <bjf> ## Kernel team meeting in two hours
[15:58] <bjf> ##
[16:14] <ogasawara> era: it seems that bug was recently resolved in the last few hours by the package maintainer
[16:18] <ogasawara> era: I'm not opposed to going with their plan B in the future and completely dropping ndiswrapper from the kernel but that's a discussion that needs to probably take place on the kernel-team mailing list
[16:31] <Riddell> jcrigby: has the binary package names in the linux-linaro upload been OKed by the kernel team?
[16:32] <tgardner> Riddell, its been uploaded, but is awaiting acceptance by an archive admin
[16:32] <jcrigby> Riddell: I don't know.  What constitutes approval.
[16:32] <Riddell> tgardner: why do you think I'm asking :)
[16:33] <Riddell> jcrigby: tgardner's blessing? :)
[16:33] <tgardner> Riddell, random curiosity?
[16:33] <tgardner> Riddell, slangasek said he had some concerns, but he's at debconf
[16:34] <Riddell> why do some of the binary packages have "linaro" in the name and some go for the -1000 suffix?
[16:34] <tgardner> Riddell, um, not supposed to. I guess I'd better look closer. I only looked at the control file
[16:35] <jcrigby> I tried to follow the abstracted debian model.  May have messed up.
[16:35] <Riddell> well it looks deliberate I presume there's a reason why that's the best way to do it
[16:35] <jcrigby> tgardner:  I removed a bunch of entries from the control file yesterday.  It now looks like the ti-omap4 control file.
[16:35] <Riddell> e.g. linux-headers-2.6.35-1000
[16:35] <tgardner> Riddell, whats the URL for looking at the generated packagesd?
[16:36] <Riddell> tgardner: there are no generated packages, I'm reviewing the source
[16:38] <jcrigby> I think you will see the same convention in the ubuntu kernel
[16:38] <jcrigby> without the 1000
[16:38] <tgardner> Riddell, according to debian/control I think the package names are correct. it follows the same model as other kernel topic branches
[16:38] <Riddell> yeah that's the ABI number
[16:39] <Riddell> but it seems curious to namespace some packages with "linaro" and some with <mega big ABI number>
[16:39] <smb> Ejdesgaard_, Is that definitely needed for 2.6.32 (10.04 LTS) as the patch seems to have been sent for 2.6.33.y specifically
[16:40] <tgardner> Riddell, oh, you mean the 'linaro' part? I guess he's using it to distinguish these kernel binaries from the omap4 packages that are already in the archive.
[16:41] <Riddell> tgardner: yeah that makes sense.  bumping the ABI to 1000 is what seems strange to me
[16:42] <tgardner> jcrigby, so, do you want to respin with new binary package names?
[16:42] <tgardner> Riddell, we use the ABI number to distinguish between kernel topic branches
[16:42] <tgardner> otherwise we'd have binary package name collision
[16:42] <jcrigby> tgardner:would be glad to if someone tells me what to change them to
[16:42] <Riddell> I'd have thought e.g. linux-linaro-headers-2.6.35-1 would make more sense
[16:43] <tgardner> Riddell, its a restriction of the installer, which insists on the linux-header* pattern
[16:43] <jcrigby> ahh
[16:43] <tgardner> similarly for linux-image*
[16:43] <Riddell> tgardner: ah, I knew there'd be a perfectly rational explanation
[16:43] <tgardner> well, rational is a stretch :)
[16:45] <jcrigby> on a different matter, I changed the control yesterday and removed some stuff and made Architecture: armel for everything
[16:45] <jcrigby> so the build system only tries to build on armel
[16:46] <Riddell> jcrigby: in that case should I reject the current upload and save the non-arm buildds the hassle of building something they don't want?
[16:46] <tgardner> jcrigby, I'm not sure you can do that. Some of the packages have to be constructed on the default arch (i386), e.g., the headers _all.deb
[16:47] <jcrigby> tgardner:I made it look like the ti-omap4 control
[16:47] <jcrigby> is that known good?
[16:47] <tgardner> Riddell, why don't you go ahead and reject this upload. I
[16:47] <tgardner> I'll work with jcrigby to fix the control file issues
[16:49] <jcrigby> tgardner:thanks
[16:49] <Riddell> ok rejected, ping me when you reupload if you want a quick review
[16:50] <tgardner> Riddell, later today I think. Thanks for your help.
[16:51] <jcrigby> tgardner:what is best for you.  Do you want to just send me a patch?
[16:52] <tgardner> jcrigby, send a pull request with your current bits
[16:52] <jcrigby> with the ti-omap4 changes?
[16:52] <jcrigby> style changes that is
[16:52] <tgardner> jcrigby, yep
[16:53] <jcrigby> ok, I notice one thing that your comment above sheds some light on:
[16:53] <jcrigby> Package: linux-headers-2.6.35-1000
[16:53] <jcrigby> Architecture: armel
[16:53] <jcrigby> Section: devel
[16:53] <jcrigby> Priority: optional
[16:53] <jcrigby> Depends: ${misc:Depends}, coreutils | fileutils (>= 4.0)
[16:53] <jcrigby> #Provides: linux-linaro-headers, linux-linaro-headers-2.6
[16:53] <jcrigby> Description: Header files related to Linux kernel version 2.6.35
[16:53] <jcrigby>  This package provides kernel header files for version 2.6.35, for sites
[16:53] <jcrigby>  that want the latest kernel headers. Please read
[16:53] <jcrigby>  /usr/share/doc/linux-linaro-headers-2.6.35-1000/debian.README.gz for details
[16:54] <jcrigby> explains the commented out Provides:
[16:55] <tgardner> jcrigby, correct
[17:07] <apw> bjf, is there a meeting today?
[17:07] <bjf> apw, yes
[17:07] <apw> ahh i see your 2 hour warning now
[17:14] <smb> sconklin, bjf Seems there is no need to start a new release on Lucid, that was already done
[17:15] <sconklin> smb: yes, I'm just applying the patches. I'll start with the things we wanted on the short list
[17:15] <smb> sconklin, ok
[17:17] <smb> sconklin, We should sync on the writeback patches. I got the feeling there is a patchset you got and one I have done
[17:18] <sconklin> smb let me check what I have and see if they're in my public repo
[17:18] <smb> bug 643617
[17:18] <ubot2> smb: Error: Bug #643617 not found.
[17:18] <smb> hm
[17:18] <smb> bug 543617
[17:18] <ubot2> Launchpad bug 543617 in linux (Fedora) (and 3 other projects) "Unmount of an fs with dirty cache buffers causes pathological slowdown (affects: 11) (dups: 2) (heat: 101)" [Unknown,Unknown] https://launchpad.net/bugs/543617
[17:19] <smb> same as bug 585092
[17:19] <ubot2> Launchpad bug 585092 in linux (Ubuntu) "giant IO delays (affects: 1) (heat: 22)" [Medium,In progress] https://launchpad.net/bugs/585092
[17:20] <sconklin> smb: yes, there's already a branch "bug bug543617" in my public repo that I used to build the test kernel for that bug
[17:21] <sconklin> oops, branch name is simply bug543617
[17:21] <smb> sconklin, Let me check what is there. Cause I have been working on that and probably got a different set
[17:25] <smb> sconklin, My set is there (http://kernel.ubuntu.com/git?p=smb/linux-2.6.32.y.git;a=shortlog;h=refs/heads/writeback) and looks like being a superset of yours. I am currently trying to get Jens Axboe look at those to get them backported to stable upstream. There is a set for 2.6.34.y as well
[17:25] <smb> sconklin, Have you sent your patches for review already. I cannot remember having seen that
[17:26] <sconklin> as I recall, they were sent for review weeks ago, and I just picked them up. Let me check
[17:27] <sconklin> smb: [1/2] writeback: fix WB_SYNC_NONE writeback from umount
[17:27] <smb> I was holding back because I at least wanted to have some feedback on them before. These series has been taking a lot of time to mature upstream
[17:28] <sconklin> [2/2] writeback: ensure that WB_SYNC_NONE writeback with sb pinned is sync
[17:28] <smb> Ok, maybe my bad not deleting those
[17:28] <sconklin> smb: OK, I just grabbed them and built a test while you were out sick because rtg asked about them
[17:28] <smb> sconklin, Please don't pick them for applying now
[17:29] <sconklin> smb: they were still active in patchwork also
[17:29] <sconklin> ok, I won't pick them
[17:29] <smb> Right, I should have marked them as superseeded 
[17:30] <smb> Thanks. Unfortunately there was a time in between when I knew the ones we had were not good but upstream was not fixed yet. And not to forget I did not set them as rejected
[17:31] <bjf> ##
[17:31] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[17:31] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[17:31] <bjf> ##
[17:32] <smb> sconklin, The set now seems to be ok, but as you can see in that tree its a huge set.
[17:33] <smb> sconklin, The only thing we need to remember is to revert the workaround when we apply the writeback set
[17:33] <sconklin> smb: I'll apply the graphics fixes for the two issues we have patches for, then the writeback patches, then the stable update, OK?
[17:35] <smb> sconklin, Leave out the writeback patches completely. I want to get feedback on the backport first and then do another round of sending those to the kt-mailing list
[17:35] <sconklin> smb: ok
[17:36] <vanhoof> sconklin: i assume you need that sru sooner than later for the x201 display bug?
[17:36] <sconklin> vanhoof: yes, I'd hate for it to end up being the gating factor
[17:36] <vanhoof> manjo: ^^ :D
[17:37] <manjo> yes building kernel with patch now 
[17:37] <manjo> I will send it to SRU as soon as I am done 
[17:37] <vanhoof> manjo: ok, i can re-test if you'd like
[17:38] <manjo> yep that will be great!
[17:38] <sconklin> vanhoof, manjo: also, people have been ignoring the SRU requests or not completing them properly. We've been fixing them up without complaining, but I'm going to start bouncing them until they are correct.
[17:39] <smb> sconklin, I removed the writeback parts from patchwork for now so there won't be confusion on that part
[17:40] <sconklin> smb: ok, but I think I acked them on the mailing list, so you'll want to follow up on that
[17:41] <smb> sconklin, There is another one to disable CONFIG_LGUEST for hardy lpia which went in as part of the security update to fix the build failure
[17:41] <smb> sconklin, I probably should post a message there, too
[18:29] <manjo> Is there an issue with tangerine ?
[18:29] <manjo> manjo@tangerine:~$ dchroot -c lucid-amd64
[18:29] <manjo> W: Group ‘sbuild’ not found
[18:29] <manjo> E: Access not authorised
[18:29] <manjo> I: You do not have permission to access the schroot service.
[18:29] <manjo> I: This failure will be reported.
[18:29] <manjo> manjo@tangerine:~$ 
[18:29] <manjo> I was able to dchroot just couple of hrs ago
[18:29] <JFo> <-starving... headed to lunch
[18:31] <manjo> tgardner, ^^ any idea ?
[18:31] <tgardner> manjo, I guess you're not special.
[18:31] <manjo> ?
[18:32] <bjf> tgardner, i think it's because he *is* "special"
[18:32] <tgardner> manjo, just kidding. lemme check
[18:32] <manjo> bjf, thanks
[18:33] <tgardner> apw, smbgot some oops on tangerine.
[18:34]  * manjo brb
[18:34] <tgardner> smb, ^^ need to reboot.
[18:34] <smb> Hm, just for compiling six kernels in paralell
[18:34] <smb> ok
[18:34] <apw> tgardner, stuck in writeback ... smb could that be your writeback issue you had patches for ?
[18:34] <tgardner> shall we try the 2.6.35 kernel?
[18:34] <bjf> ogasawara, you want me to leave "delta-review" on the agenda?
[18:34] <smb> tgardner, apw Let me have a quick look
[18:35] <ogasawara> bjf: I'd say take it off
[18:36] <ogasawara> bjf: the last big item is to review if any of our ubuntu drivers need updating (which I suspect they won't)
[18:36] <bjf> ogasawara, it's gone
[18:36] <sconklin> smb: do we put the buglink for the stable update bug in every patch that's part of a stable pile?
[18:37] <smb> sconklin, yes. maint-modify-patch
[18:37] <sconklin> ok, doing that now
[18:37] <smb> tgardner, apw Seems the process that was stuck first was returning later. So it might well be the slow writeback problem
[18:38] <bjf> apw, you still have two agenda items do you want to keep them?
[18:38] <tgardner> smb, lets try the LTS backport kernel for awhile.
[18:38] <simar> I want to triage bugs for kernel at first. So I'm going to read documents of Ubuntu Kernel Bug triaging ..
[18:39] <apw> bjf, the misc one is likely redundant
[18:39] <smb> tgardner, as long as we can switch back to the lts kernel later, ok. Cause that machine is good for running stress io tests
[18:40] <smb> tgardner, I am off it again, so you can reboot if you like
[18:43]  * smb is gone
[18:45] <manjo> tgardner, please let me know when tangerine is back
[18:50] <apw> simar, sounds great for us ...
[18:51] <manjo> simar, talk to JFo he should be able to help you as well 
[18:52] <manjo> simar, he leads the bug triaging effort 
[18:56] <manjo> tgardner, looks like tangerine is back... can I use it ?
[18:57] <manjo> ah same issue cannot dchroot ...  
[18:57]  * manjo getting lunch will be back soon 
[18:58] <tgardner> manjo, should be OK now. you'll need to logout first.
[20:33]  * ogasawara lunch
[20:33]  * jjohansen lunch too
[22:06] <sconklin> manjo, vanhoof: The graphics patches you wanted are now in the lucid repo
[22:06]  * manjo sconklin beer++
[22:15] <bjf> ogasawara, sconklin just pushed some patches to the lucid repo is there anything that will automatically build that (some kind of pre-proposed / stable crack of the day)?
[22:15] <ogasawara> bjf: hrm, I can't remember if smb's pre-proposed in the kernel-ppa builds automatically
[22:16] <tgardner> ogasawara, bjfAFAIK it does
[22:16] <ogasawara> bjf: it certainly should be easy enough to make it do so automatically as apw does the same for the latest maverick tip
[22:16] <bjf> ogasawara, that's what i thought, was just wondering if we already did it
[22:17] <bjf> tgardner, i guess we'll know in a bit then
[22:19] <manjo> latest maverick iso i386 from cdimage current does not seem to boot ... 
[22:19] <manjo> I recall apw posted something in this regard wrt to usb keys .. anyone recall ? 
[22:21] <ogasawara> manjo: bug 608382 ?
[22:21] <vanhoof> sconklin: awesome!
[22:21] <ubot2> Launchpad bug 608382 in usb-creator (Ubuntu) (and 1 other project) "USB images of Maverick CDs fail to boot with -- Error: Unkown keyword in configuration file (affects: 13) (dups: 1) (heat: 70)" [High,New] https://launchpad.net/bugs/608382
[22:21] <manjo> looking 
[22:23] <manjo> ogasawara, thanks a ton 
[22:24] <tgardner> bjf, kernel-ppa@zinc:~$ crontab -l
[22:24] <tgardner> # m h  dom mon dow   command
[22:24] <tgardner> 0 *    *   *   *   $HOME/buildscripts/mainline-build/kernel-version-map >$HOME/public_html/info/kernel-version-map.html.new && mv $HOME/public_html/info/kernel-version-map.html.new $HOME/public_html/info/kernel-version-map.html
[22:24] <tgardner> 0 09    *   *   *   USER=kernel-ppa $HOME/kteam-tools/mainline-build/mainline-trigger >>$HOME/logs/mainline-trigger 2>&1
[22:24] <tgardner> 5  *    *   *   *   USER=kernel-ppa $HOME/kteam-tools/mainline-build/cod-execute >>$HOME/logs/cod-execute 2>&1
[22:24] <tgardner> @hourly /srv/kernel.ubuntu.com/www/scripts/gitfind > /dev/null 2>&1
[22:25] <manjo> ogasawara, if you are channel operator can you add "10.10 USB boot issues see https://launchpad.net/bugs/608382 for workaround" ? 
[22:25] <ubot2> Ubuntu bug 608382 in usb-creator (Ubuntu) (and 1 other project) "USB images of Maverick CDs fail to boot with -- Error: Unkown keyword in configuration file (affects: 13) (dups: 1) (heat: 70)" [High,New]
[23:23] <apw> ogasawara, bjf, sconklin-gone, the pre-proposed engine builds all of the releases, assuming they have non-ignored commits following a release
[23:24] <bjf> apw, yes, i was looking at the scripts and sort of decided that
[23:24] <bjf> apw, if i understand it, they should kick off 0900 UTC
[23:25] <apw> bjf yes indeedy
[23:25] <apw> bjf with the new queuing ability we could reschedule the pre-proposed to a better time independantly if needed
[23:26] <apw> night
[23:26] <bjf> g'night