=== MTeck-ricer is now known as MTecknology
=== hrw|gone is now known as hrw
=== bryceh is now known as 40FAA7E1T
=== 40FAA7E1T is now known as bryyce
[09:19] <apw> morning
[09:19] <smb> morning
[09:21] <cooloney> apw: and smb morning
[09:21] <smb> cooloney, Heya
[09:21]  * apw waves
[09:22]  * amitk waves
[09:23]  * jk- plays 'find the terminal attached to this  screen session'
[09:24] <apw> jk-, can't you just reconnect to it with 'disconnect the other one'
[09:24] <apw> and not care ?
[09:24] <jk-> i can reconnect to it with -x
[09:24] <jk-> but yeah, that's a good idea :)
[09:25] <apw> -d -r looks to be the incantation
[09:25] <jk-> yup
[09:26] <amitk> jk-: I name my screen sessions with -S
[09:28] <jk-> amitk: i ony have one running, so the problem isn't finding the right session
[09:29] <jk-> just that I've lost the attached terminal :)
[09:34] <amitk> jk-: aah, in that case apw's suggest is best
[10:07] <kraut> moin
[10:33] <apw> moin
=== smb is now known as smb-afk
[11:35] <lamont> zinc upgrade in about 25 minutes, fyi
[11:40] <cking> lamont, ok, looks like extended lunchbreak for some of us then :-)
[11:41] <lamont> in my fantasy land, it's much less than 2 hrs of downtime
[11:44]  * cking hopes reality matches fantasy land
[12:00] <lamont> kernel-ppa has a build going on zinc atm, which may or may not finish before the upgrade kills it.  just fui
[12:00] <lamont> fyi, even
[12:21] <apw> config PARPORT_PC
[12:21] <apw>         tristate "PC-style hardware"
[12:21] <apw>         depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
[12:21] <apw>                 (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
[12:50] <lamont> zinc back to all y'all.
[12:50] <lamont> cking: enjoy
[12:51] <cking> ta
[12:52] <apw> lamont, ta
[12:52] <gnarl> lamont, thanks
=== gnarl is now known as smb
[12:57] <lag> What's the address to send patches upstream?
[12:57] <apw> lag the get_maintainers script tells you
[12:57] <apw> it uses the MAINTAINERS file to work it out
[12:59]  * lag "find"s get_maintainers script
[13:00] <lag> apw: get_maintainer.pl :)
[13:00] <lag> Found it
[13:00] <lag> Thanks
[13:01] <apw> yeah thats the one ... sorry was distracted
[13:01] <lag> Wow! I like this
[13:01] <apw> lag, you do need to take its output with a grain of salt
[13:01] <apw> it sometimes includes random people who changed the file but are not interesting
[13:01] <lag> Well I'm using the email address it provided me with
[13:07] <apw> Andrew Morton <akpm@linux-foundation.org>
=== psurbhi is now known as csurbhi-afk
[13:53] <cking> http://smackerelofopinion.blogspot.com/2009/08/compilers-dragon-book.html
[14:03] <apw> gnarl, should be ok now
[14:04] <gnarl> apw, yep looks good 
=== csurbhi-afk is now known as psurbhi
[14:12] <JFo> you got a great deal cking :)
[14:13] <cking> JFo, I just need to read it now ;-)
[14:13] <JFo> I need to find me a copy
[14:13] <JFo> haven't seen my last one in years
[14:13] <JFo> plus I never got 'round to finishing it
[14:15] <lag> apw: How does this look "depends on (SPARC64 && !PCI) || (M68K && !ISA) || X86"
[14:16] <lag> There doesn't seem to be an AMD64
[14:37] <lag> depends on PARPORT && (!SPARC64 || PCI) && (!SPARC32 || BROKEN)
[14:42] <apw> depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
[14:42] <apw> 		(!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && !ARM
[14:43] <apw> this original can be striped of all the architecture bits as it would be on X86 say ... and then i believe you get
[14:43] <apw> depends on PCI && ISA
[14:43] <apw> bibble
[14:44] <lag> depends on (PCI || ISA) && ((SPARC64 && !PCI) || (M68K && !ISA) || X86)
[14:44] <apw> yep that what i was angling at
[14:55] <lag>  * We don't actually have real ISA nor PCI buses, but there is so many 
[14:55] <lag>  * drivers out there that might just work if we fake them...
[14:55] <lag>  */
=== amitk is now known as amitk-afk
[15:09]  * JFo goes for some coffee
[15:23] <manjo> JFo, couple of successful results from firewire testing 
[15:25] <JFo> saw that :)
[15:25] <JFo> very cool
[15:25] <JFo> so far I have seen no negative feedback
=== cndougla__ is now known as cnd
[16:03] <apw> smb, did we build in i2c in lucid do you remember ?
[16:04] <smb> I would say so.
[16:04] <smb> All the edid stuff at least uses i2c
[16:04] <smb> Oh you mean built in or module?
[16:05] <apw> yeah i was wondering if it went to built-in
[16:06] <smb> Hm, i2c_algo_bit at least is a module
[16:07] <smb> Seems CONFIG_I2C=y but the rest of the specific drivers is modules
[16:07]  * apw screams at the intense slowness of his disk ... ARRG
[16:07] <smb> apw, ^
[16:14] <apw> smb, thanks .... yeah its just built so they should be able to use the kernel command line
[16:14] <apw> ogasawara, i've just linked bug #589439 to the configuration blueprint.  seems to be a bunch of requests recommendations in there we should think about for maverick
[16:14] <ubot2> Launchpad bug 589439 in linux (Ubuntu) "configuration gotchas with Maverick 2.6.35 kernel... (affects: 1) (heat: 105)" [Medium,Triaged] https://launchpad.net/bugs/589439
[16:15] <ogasawara> apw: ack
[16:19] <apw> ogasawara, also bug#592495 ... that one may well come out in the wash from the M686 changes coming from the tool-chain changes iff they have finally documented wtf we are menat to be doing there
[16:19] <apw> bug #592495
[16:19] <ubot2> Launchpad bug 592495 in linux (Ubuntu) "CPU for generic-pae kernel should be raised to M686 (affects: 1) (heat: 109)" [Undecided,Triaged] https://launchpad.net/bugs/592495
[16:21] <ogasawara> apw: indeed.  seems the spec still needs drafting so still no idea what our work items will entail
[16:22] <apw> ogasawara, got a pointer to the spec there ?
[16:22] <ogasawara> apw: https://wiki.ubuntu.com/FoundationsTeam/Specs/Maverick686DefaultCompile
[16:22] <ogasawara> apw: robbiew re-targeted to alpha3 due to the missing work items
[16:22] <apw> ogasawara, thanks i'll go poke him
[16:23] <robbiew> missing work items from doko, i believe
[16:23] <apw> ogasawara, we arn't going to want to change the kernel config at that fundamental level after alpha-3
[16:23] <ogasawara> apw: agreed
[16:23] <apw> robbiew, well if they don't sort out whats going to happen on that one before long we are going to have to punt on it
[16:24] <apw> we can't be making that level of change after a3
[16:24] <apw> and if they haven't changed the compilers yet, they are making all the archive rebuild tests moot
[16:24] <apw> none of which sounds like a good thing (tm)
[16:25] <robbiew> apw: ack
[16:32] <apw> smb, what time is the bug meeting ?
[16:33] <smb> apw, half an hour by my clock.
[16:33] <smb> Not that I had any time to prepare for anything
[16:34] <apw> smb, i know i am punching self in the face as it is
[16:35] <smb> apw, Well likely go there and make smug comments without being prepared. :-P
[16:37] <doko> apw, ogasawara: ping
[16:38] <doko> do you use explicit cpu flags for kernel builds?
[16:38] <apw> doko, yes we completely override all compiler flags
[16:38] <apw> that is the nature of the builds, as we build 3-4 different flavours
[16:39] <doko> apw: but you already did drop the i386 build, did you?
[16:39] <apw> doko, yes we already dropped the explicit i386 builds
[16:39] <apw> but our generci builds are hovering around the 586 level
[16:39] <doko> apw: and how is the default build on i386 built?
[16:40] <doko> apw: why i586?
[16:40] <apw> cause that is what lucid supported and its not be changed to match your documentation on where we are going, as its not yet documented
[16:41] <apw> the only info i have seen was scotts announcement at uds ... "we are going move up to M686 + CMOV" but ... i've no idea if thats been done
[16:41] <doko> apw: hmm, did we do document i586 as supported? the default was i486 in lucid
[16:41] <doko> apw: it's in the archive since uds
[16:41] <apw> doko, right in userspace that is correct.  if you wanted to use i486 you had to use the i386 flavours ... which were actually i486 minimum
[16:42] <apw> the generci ones are a middle m586, ie m586 + some specific features
[16:42] <doko> there is one guy who is keen on geode lx support
[16:43] <apw> doko, ok ... meaning?
[16:44] <apw> doko, i guess this is the discussion that we need to get written down in the spec, so that we can make an informed decision
[16:44] <doko> apw: that you should not pass -Wa,-mtune=i686 to the assembler
[16:45] <apw> doko, so have we changed the compiler flags to do that generally ?
[16:45] <doko> apw: no
[16:46] <doko> but some packages do pass this *explicitely*, and if you pass everything explicitely ... and no, not known when discussing this spec, just later when a user complained
=== hrw is now known as hrw|gone
=== bjf[afk] is now known as bjf
[16:58] <manjo> JFo, ping 
[16:58] <manjo> JFo, bug chat ?
[16:59] <JFo> yep
[16:59] <JFo> one sec
[17:08] <JFo> http://qa.ubuntu.com/reports/jfo/kernel-Top50.html
[17:08] <JFo> tgardner, ^^
[17:10] <JFo> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=&orderby=-importance&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=ker
[17:10] <JFo> nel-candidate&field.tags_combinator=ALL&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_no_branches.used=&search=Search
[17:10] <JFo> gah!
[17:10] <JFo> sorry
[17:10] <apw> https://wiki.ubuntu.com/Kernel/Tagging
[17:11] <JFo> this one is the one that I looked at fr overall needs-review: http://bit.ly/9AdcPG
[17:12] <apw> sconklin, hey ?  meeting ?
[17:12] <sconklin> apw sorry, off by an hour
=== kamalmostafa is now known as kamal
=== hrw|gone is now known as hrw
[17:43] <manjo> tgardner, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/556872
[17:43] <ubot2> Launchpad bug 556872 in linux (Ubuntu) "[lucid] [nouveau] blank screen on Dell Latitude E6410 (NVS 3100M [10de:0a6c]) (affects: 7) (dups: 1) (heat: 54)" [High,Fix committed]
=== hrw is now known as hrw|gone
[18:27] <apw> anyone got any usb-1.0 devices in their posession?  hearing rumours that all 1.0 devices fail on connect on maverick kernels
[18:27] <smb> Hm, I think I got an old stick
[18:28] <apw> smb, any chance you could shove it in something with a maverick kernel on it ?
[18:28] <smb> Not that I currently have any Maverick on anything yet
[18:28] <smb> But I likely need to set up some installations anyway
[18:28] <apw> smb, i only have the lts-backports kerenl installed that would do as this is slated to be kernel issue
[18:29] <smb> apw, I'd rather have it tried on a separate installation. Might do one tomorrow if that is soon enough
[18:29] <apw> smb, yep thanks
[18:31] <bjf> apw, i just tried the oldest stick I have and it worked, i have to believe it's 1.0
[18:31] <apw> bjf you can tell from dmesg, by which driver claims it
[18:32] <apw> ohci == 1.0
[18:34] <manjo> ogasawara, Bug #533784 looks like the comment #17 says the current lucid kernel / and your backport kenrel both fix the issue, the other -22 errs people are seeing has already been moved to a diff bug #557266. Since you have done a lot of work on this one, can you close this bug and ask people to follow the 557266 for the other issue ?
[18:34] <ubot2> Launchpad bug 533784 in debian (and 3 other projects) "[Radeon kernel module] drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command stream (affects: 15) (heat: 104)" [Unknown,Confirmed] https://launchpad.net/bugs/533784
[18:34] <ubot2> Launchpad bug 557266 in linux (Ubuntu) (and 1 other project) "[Radeon kernel module] drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream (affects: 13) (dups: 1) (heat: 70)" [Undecided,Confirmed] https://launchpad.net/bugs/557266
[18:34] <ogasawara> manjo: ack, will do
[18:35] <bjf> apw, dmesg didn't tell me anything usefull http://pastebin.ubuntu.com/462616/
[18:35] <tgardner> sconklin, can you finish review of http://patchwork.ozlabs.org/patch/57702/ and get it committed ?
[18:35] <apw> bjf does lsusb tell you ?
[18:36] <sconklin> tgardner: I'll have a look
[18:36] <apw> [183485.561355] usb 6-1: new full speed USB device using uhci_hcd and address 2
[18:36] <apw> bjf, thats telling you i think
[18:36] <bjf> hmmm
[18:38] <apw> bjf, i think thats telling us yes it is a slow device, but you have uhci in your machine which is not the failing case ... i believe
[18:38] <smb> lsusb -v should tell
[18:38] <apw> but that uhci works with slow devices is good information, thanks
[18:39] <manjo> smb, Bug #539655 
[18:39] <ubot2> Launchpad bug 539655 in linux (Ubuntu Lucid) (and 2 other projects) "nouveau hard lockup in nouveau_gem_ioctl_cpu_fini (affects: 2) (heat: 44)" [High,Triaged] https://launchpad.net/bugs/539655
[18:40] <bjf> apw, lsusb for the device: http://pastebin.ubuntu.com/462617/
[18:41] <smb> bjf, looks like usb 1
[18:42] <smb> bcdUSB               1.10
[18:42] <apw> yeah i concur.  thanks bjf
[18:42] <smb> apw, Did they have usb 1.0 hubs in that case?
[18:45] <apw> the tester i have problems with has usb1.1 devices ... old memory stick and a using ohci as interface
[18:45] <apw> looks like the only combination affected
[18:46] <smb> apw, But that could be ohci from a usb 2.0 hub (the companion hub) or a real usb 1.0 only hub, couldn't it?
[18:46] <apw> smb, yes it could no way to tell, the only info i have is they have ohci
[18:47] <apw> so i am assuming its a modern controller with a companion (as the machine is modern)
[18:51] <smb> right
[18:51] <bjf> apw, just fyi i tested on: 2.6.35-7-generic
[18:52] <apw> bjf, thanks thats excellent info
[19:02]  * manjo getting lunch will be back soon
[19:07] <bjf> http://www.swampbuggy.com/
[19:08] <bjf> http://www.youtube.com/watch?v=ADovhUcaZpo
[19:17] <JFo> I always wanted to drive one of those
[19:22]  * tgardner lunches
[19:40] <jjohansen> -> Lunch
[20:02]  * ogasawara lunch
[20:10] <kees> tgardner: thanks for working out a proper fix for that AGP issue.  It sounds like a lot of other people have been hitting it, but it's a really hard bug to report (since it just stalls the system completely).
[20:11] <tgardner> kees, I found at least one other guy for whom it fixed his boot.
[20:11] <kees> excellent :)
[20:11] <tgardner> haven't heard anything back from upstream (otehr then Rafael)
[20:11]  * kees nods
[20:12] <tgardner> kees, if -rc5 comes out without this obvious regression fix, then I'll put the full court press on Arlie et al
[20:13]  * kees hugs tgardner
[20:13] <kees> I've been utterly baffled why they've been seemingly ignoring it.
[20:13] <tgardner> kees, hard to say, but maybe they are just busy
[20:14]  * kees nods
[20:14] <tgardner> kees, maybe you could attach the patch to the BZ report (I don't have a login there)
[20:15] <kees> tgardner: sure I can do that.
[20:16] <tgardner> kees, thanks, it'll help them to not forget.
[20:16] <kees> heh
[20:21] <squarebracket> why wasn't the wacom kernel module included in the latest kernel update? (for lucid)
[20:23] <tgardner> squarebracket, there are 3 wacom modules. which one do you think is missing?
[20:23] <tgardner> input/tablet/wacom.ko, input/touchscreen/wacom_w8001.ko, hid/hid-wacom.ko
[20:23] <squarebracket> the first one.
[20:24] <squarebracket> searching for wacom.ko at packages.ubuntu.com it doesn't look like it's included in the latest kernel
[20:24] <tgardner> squarebracket, find /lib/modules/`uname -r` -name wacom.ko
[20:25] <tgardner> /lib/modules/2.6.32-24-generic/kernel/drivers/input/tablet/wacom.ko
[20:26] <squarebracket> yeah, i haven't done that yet... i compiled my own kernel module from the linuxwacom source but i'm looking into why my friend's tablet isn't working, and he didn't have the kernel module loaded; i assumed it was a missing kernel module
[20:26] <tgardner> squarebracket, maybe its a new and unsupported device
[20:26] <squarebracket> i've written a batch script to look for it, if not compile it from source... but he's at work right now
[20:26] <squarebracket> it's not
[20:26] <squarebracket> it worked before the kernel update
[20:26] <squarebracket> (which is -23 i think)
[20:27] <tgardner> squarebracket, he's running the -proposed kernel, right?
[20:27] <squarebracket> he's running just vanilla ubuntu, i figured it would be -generic?
[20:28] <tgardner> squarebracket, no, I meant which pocket is he subscribed to, e.g., -updates or -proposed. 
[20:29] <squarebracket> oh! that's a good question, i'm not sure.
[20:29] <squarebracket> should be whatever defaults
[20:29] <tgardner> squarebracket, get him to run 'ubuntu-bug linux' so we get the pertinent details.
[20:30] <squarebracket> sure, will do, i'll throw it into the bash script and pipe it to a file.
[20:30] <tgardner> squarebracket, uh, you only need to run it once, preferably using the kernel version that fails to load the tablet driver.
[20:32] <squarebracket> tgardner, yeah, it's a bash script to just check for wacom.ko / load one i compiled / compile if that doesn't work. it'll only run once.
[20:32] <squarebracket> tgardner, but considering there was no wacom.ko loaded when i did an lsmod, and wacom.ko isn't in linux-image-generic, i figured it was a missing module.
[20:34] <squarebracket> i'll file a bug in launchpad once i know for sure what the problem is. thanks for your help!
[20:36] <virtuald> my gpu froze and i got this in dmsg: http://pastebin.com/hdcuBa46
[20:39] <virtuald> anyone care to take a look?
[20:41] <virtuald> #
[20:41] <virtuald> [31584.658139] BUG: unable to handle kernel NULL pointer dereference at 00000080
[20:41] <virtuald> on line 819
[20:46] <sconklin> I'm getting some strange behavior from kernel.ubuntu.org, anyone else notice anything today?
[20:50] <apw_> Test
[20:51] <apw_> It was upgraded today ...
[20:52] <apw_> sconklin: ^^
[20:53] <sconklin> apw_: ok. It looks like the message I had never seem before is something seen in other places when git garbage collection is triggered during a push, and is harmless
[20:53] <sconklin> but I was unable to fetch one of rtg's trees as a remote but was able to clone it outright
[20:53] <tgardner> sconklin, yeah, I had it happen to me today as well. its a newer git that is causing it
[20:54] <sconklin> tgardner: thanks. The errors that really threw me were:
[20:54] <sconklin> fatal: protocol error: bad line length character: Remo
[20:54] <sconklin> error: error in sideband demultiplexer
[20:54] <sconklin> but I think they are OK
[20:55] <apw> i wonder what thats the start of ... remove perhaps
[20:55] <tgardner> sconklin, thats exactly what I got. don't make a lot of sense, does it?
[20:55] <apw> i bet it is the first four chars of something longer ... but git is not meant to do that
[20:55] <apw> its meant to negociate levels between the ends and dumb itself down
[20:55] <apw> sconklin, w
[20:55] <sconklin> no, and my brain kept trying to parse "sideband demultiplexer" in a radio context and failing
[20:56] <apw> what did you try to clone ... i'd like to as well
[20:56] <apw> sconklin, heh ... git protocol carries more than one channel ... so that you can get remote messages as well as the data you want
[20:56] <apw> thats how it does the percentages pulled down for example... its a bit like CD
[20:56] <sconklin> the above errors came from a puch on the ubuntu-lucid master when garbage collection got triggered.
[20:57] <sconklin> git://kernel.ubuntu.com/rtg/ubuntu-lucid-lbm is the one I can clone but not fetch as a remote
[20:57] <sconklin> apw ^^
[20:59] <sconklin> btw the push to lucid master was apparently ok, and now it matches my tree and looks ok
[21:01] <tgardner> apw, looks like we have alucid chroot on zinc now
[21:36] <tgardner> apw, do you have a moment to help with bzr commits?
[21:48] <tgardner> jjohansen, rtg@lochsa:~/maverick/ureadahead/ureadahead$ bzr commit -m"restore buffer_size_kb on exit"
[21:48] <tgardner> bzr: ERROR: Cannot lock LockDir(lp-70455952:///~scott/ureadahead/trunk/.bzr/branchlock): Transport operation not possible: readonly transport 
[21:52] <jjohansen> tgardner: http://doc.bazaar.canonical.com/latest/en/user-guide/index.html
[22:52] <bjf> sbeattie, i'm trying to run test-kernel-security.py from qa-regression-testing/scripts and am getting "getpcaps missing (please install libcap-bin)". this is on lucid
[22:53] <bjf> sbeattie, libcap-bin is not available?
[22:53] <sbeattie> bjf: replaced by libcap2-bin
[22:54] <bjf> sbeattie, thx
[22:56] <sbeattie> bjf: sure thing. The # QRT-Packages and # QRT-Alternates meta information should describe what needs to be installed.
[22:57] <bjf> sbeattie, they do, I just blindly cut and pasted without thinking that they were different release versions
=== sconklin is now known as sconklin-gone