=== 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 | ||
apw | morning | 09:19 |
---|---|---|
smb | morning | 09:19 |
cooloney | apw: and smb morning | 09:21 |
smb | cooloney, Heya | 09:21 |
* apw waves | 09:21 | |
* amitk waves | 09:22 | |
* jk- plays 'find the terminal attached to this screen session' | 09:23 | |
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:24 |
apw | -d -r looks to be the incantation | 09:25 |
jk- | yup | 09:25 |
amitk | jk-: I name my screen sessions with -S | 09:26 |
jk- | amitk: i ony have one running, so the problem isn't finding the right session | 09:28 |
jk- | just that I've lost the attached terminal :) | 09:29 |
amitk | jk-: aah, in that case apw's suggest is best | 09:34 |
kraut | moin | 10:07 |
apw | moin | 10:33 |
=== smb is now known as smb-afk | ||
lamont | zinc upgrade in about 25 minutes, fyi | 11:35 |
cking | lamont, ok, looks like extended lunchbreak for some of us then :-) | 11:40 |
lamont | in my fantasy land, it's much less than 2 hrs of downtime | 11:41 |
* cking hopes reality matches fantasy land | 11:44 | |
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:00 |
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:21 |
lamont | zinc back to all y'all. | 12:50 |
lamont | cking: enjoy | 12:50 |
cking | ta | 12:51 |
apw | lamont, ta | 12:52 |
gnarl | lamont, thanks | 12:52 |
=== gnarl is now known as smb | ||
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:57 |
* lag "find"s get_maintainers script | 12:59 | |
lag | apw: get_maintainer.pl :) | 13:00 |
lag | Found it | 13:00 |
lag | Thanks | 13:00 |
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:01 |
apw | Andrew Morton <akpm@linux-foundation.org> | 13:07 |
=== psurbhi is now known as csurbhi-afk | ||
cking | http://smackerelofopinion.blogspot.com/2009/08/compilers-dragon-book.html | 13:53 |
apw | gnarl, should be ok now | 14:03 |
gnarl | apw, yep looks good | 14:04 |
=== csurbhi-afk is now known as psurbhi | ||
JFo | you got a great deal cking :) | 14:12 |
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:13 |
lag | apw: How does this look "depends on (SPARC64 && !PCI) || (M68K && !ISA) || X86" | 14:15 |
lag | There doesn't seem to be an AMD64 | 14:16 |
lag | depends on PARPORT && (!SPARC64 || PCI) && (!SPARC32 || BROKEN) | 14:37 |
apw | depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \ | 14:42 |
apw | (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && !ARM | 14:42 |
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:43 |
lag | depends on (PCI || ISA) && ((SPARC64 && !PCI) || (M68K && !ISA) || X86) | 14:44 |
apw | yep that what i was angling at | 14:44 |
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 | */ | 14:55 |
=== amitk is now known as amitk-afk | ||
* JFo goes for some coffee | 15:09 | |
manjo | JFo, couple of successful results from firewire testing | 15:23 |
JFo | saw that :) | 15:25 |
JFo | very cool | 15:25 |
JFo | so far I have seen no negative feedback | 15:25 |
=== cndougla__ is now known as cnd | ||
apw | smb, did we build in i2c in lucid do you remember ? | 16:03 |
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:04 |
apw | yeah i was wondering if it went to built-in | 16:05 |
smb | Hm, i2c_algo_bit at least is a module | 16:06 |
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:07 |
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:14 |
ogasawara | apw: ack | 16:15 |
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:19 |
ogasawara | apw: indeed. seems the spec still needs drafting so still no idea what our work items will entail | 16:21 |
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:22 |
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:23 |
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:24 |
robbiew | apw: ack | 16:25 |
apw | smb, what time is the bug meeting ? | 16:32 |
smb | apw, half an hour by my clock. | 16:33 |
smb | Not that I had any time to prepare for anything | 16:33 |
apw | smb, i know i am punching self in the face as it is | 16:34 |
smb | apw, Well likely go there and make smug comments without being prepared. :-P | 16:35 |
doko | apw, ogasawara: ping | 16:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
apw | doko, ok ... meaning? | 16:43 |
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:44 |
apw | doko, so have we changed the compiler flags to do that generally ? | 16:45 |
doko | apw: no | 16:45 |
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 | 16:46 |
=== hrw is now known as hrw|gone | ||
=== bjf[afk] is now known as bjf | ||
manjo | JFo, ping | 16:58 |
manjo | JFo, bug chat ? | 16:58 |
JFo | yep | 16:59 |
JFo | one sec | 16:59 |
JFo | http://qa.ubuntu.com/reports/jfo/kernel-Top50.html | 17:08 |
JFo | tgardner, ^^ | 17:08 |
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:10 |
JFo | this one is the one that I looked at fr overall needs-review: http://bit.ly/9AdcPG | 17:11 |
apw | sconklin, hey ? meeting ? | 17:12 |
sconklin | apw sorry, off by an hour | 17:12 |
=== kamalmostafa is now known as kamal | ||
=== hrw|gone is now known as hrw | ||
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] | 17:43 |
=== hrw is now known as hrw|gone | ||
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:27 |
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:28 |
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:29 |
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:31 |
apw | ohci == 1.0 | 18:32 |
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:34 |
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:35 |
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:36 |
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:38 |
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:39 |
bjf | apw, lsusb for the device: http://pastebin.ubuntu.com/462617/ | 18:40 |
smb | bjf, looks like usb 1 | 18:41 |
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:42 |
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:45 |
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:46 |
apw | so i am assuming its a modern controller with a companion (as the machine is modern) | 18:47 |
smb | right | 18:51 |
bjf | apw, just fyi i tested on: 2.6.35-7-generic | 18:51 |
apw | bjf, thanks thats excellent info | 18:52 |
* manjo getting lunch will be back soon | 19:02 | |
bjf | http://www.swampbuggy.com/ | 19:07 |
bjf | http://www.youtube.com/watch?v=ADovhUcaZpo | 19:08 |
JFo | I always wanted to drive one of those | 19:17 |
* tgardner lunches | 19:22 | |
jjohansen | -> Lunch | 19:40 |
* ogasawara lunch | 20:02 | |
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:10 |
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:11 | |
tgardner | kees, if -rc5 comes out without this obvious regression fix, then I'll put the full court press on Arlie et al | 20:12 |
* 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:13 |
* kees nods | 20:14 | |
tgardner | kees, maybe you could attach the patch to the BZ report (I don't have a login there) | 20:14 |
kees | tgardner: sure I can do that. | 20:15 |
tgardner | kees, thanks, it'll help them to not forget. | 20:16 |
kees | heh | 20:16 |
squarebracket | why wasn't the wacom kernel module included in the latest kernel update? (for lucid) | 20:21 |
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:23 |
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:24 |
tgardner | /lib/modules/2.6.32-24-generic/kernel/drivers/input/tablet/wacom.ko | 20:25 |
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:26 |
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:27 |
tgardner | squarebracket, no, I meant which pocket is he subscribed to, e.g., -updates or -proposed. | 20:28 |
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:29 |
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:30 |
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:32 |
squarebracket | i'll file a bug in launchpad once i know for sure what the problem is. thanks for your help! | 20:34 |
virtuald | my gpu froze and i got this in dmsg: http://pastebin.com/hdcuBa46 | 20:36 |
virtuald | anyone care to take a look? | 20:39 |
virtuald | # | 20:41 |
virtuald | [31584.658139] BUG: unable to handle kernel NULL pointer dereference at 00000080 | 20:41 |
virtuald | on line 819 | 20:41 |
sconklin | I'm getting some strange behavior from kernel.ubuntu.org, anyone else notice anything today? | 20:46 |
apw_ | Test | 20:50 |
apw_ | It was upgraded today ... | 20:51 |
apw_ | sconklin: ^^ | 20:52 |
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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
sconklin | btw the push to lucid master was apparently ok, and now it matches my tree and looks ok | 20:59 |
tgardner | apw, looks like we have alucid chroot on zinc now | 21:01 |
tgardner | apw, do you have a moment to help with bzr commits? | 21:36 |
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:48 |
jjohansen | tgardner: http://doc.bazaar.canonical.com/latest/en/user-guide/index.html | 21: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:52 |
bjf | sbeattie, libcap-bin is not available? | 22:53 |
sbeattie | bjf: replaced by libcap2-bin | 22:53 |
bjf | sbeattie, thx | 22:54 |
sbeattie | bjf: sure thing. The # QRT-Packages and # QRT-Alternates meta information should describe what needs to be installed. | 22:56 |
bjf | sbeattie, they do, I just blindly cut and pasted without thinking that they were different release versions | 22:57 |
=== sconklin is now known as sconklin-gone |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!