=== bjf is now known as bjf[afk]
=== bjf[afk] is now known as bjf
[00:50] <bjf> RAOF, after an a.m. dist-upgrade today, i find myself without X
[00:51] <bjf> RAOF, this is a thinkpad x301 with intel graphics
[00:51] <RAOF> Reinstall ubuntu-desktop, everything's installable now.
[00:52] <bjf> RAOF, a daily iso *does* work
[00:52] <bjf> RAOF, will give it a whirl
[00:52] <bjf> RAOF, can you also fix my btrfs on the same system :-)
[00:53] <RAOF> bjf: Did you perhaps miss the u-d@ & u-d-d@ notification a couple of days ago that X upgrades would be broken until everything was rebuilt for the new X server? :)
[00:53] <bjf> RAOF, i saw the notice, thought everything was rebuilt (I was *wrong*)
[00:54] <RAOF> Everything (well, almost everything) that needs rebuilding has now been rebuilt.
[00:54] <RAOF> In return, would you like to fix the frequent kernel oopses in iwlwifi? :)
[00:54] <bjf> RAOF, which kernel version you running?
[00:55] <RAOF> 2.6.35-2
[00:55] <RAOF> or possibly -1
[00:55] <bjf> hmmm, if -1 try -2 but I haven't seen that problem
[00:57] <RAOF> Hah.  I bet you also haven't been having kernel crashes every couple of days, either :)
[00:58] <bjf> i'm fighting a btrfs issue right now, gotta love these linux release candidates
[00:58] <RAOF> You'd have a launchpad bug already if launchpad would accept ~255MiB vmcore apport attachments.
[00:58] <bjf> lol
=== bjf is now known as bjf[afk]
=== ericm-afk is now known as ericm
=== bjf[afk] is now known as bjf
=== ericm is now known as ericm-afk
[06:35] <lag> Morning all!
[06:48] <jk-> hey lag
[06:48] <lag> Hey jk-
[06:48] <lag> How are you this morning?
[06:49] <jk-> not too shabby, and you?
[06:50] <lag> Yes mate, bonza ;)
[06:50] <lag> What time is it there?
[06:55] <lag> jk-: --^
[06:57] <jk-> :)
[06:57] <jk-> 1:57pm
[06:57] <lag> +7hrs
[06:57] <lag> That's not too bad
[08:32]  * apw yawns
[08:33] <abogani2> apw: good morning :-)
[08:33] <apw> moin
[08:50] <apw> heh now thats a good one ... my belkin KVM got mixed up so video and USB were switching in the opposite directions
[08:56] <abogani2> funny
=== ericm-afk is now known as ericm
[09:58] <TeTeT> hi, a customer has a problem with netbooting and installing 10.04. The last line when booting the kernel is stating 'addrconf link eth0 becomes ready'
[09:58] <TeTeT> any ideas how to add more debugging output to the kernel, so the messages become more verbose and we have a chance to figure out what's going on?
[10:03] <kraut> moin
=== gnomefreak76 is now known as gnomefreak
=== sconklin-gone is now known as sconklin
[15:18] <apw> TeTeT, normally you remove quiet and splash, you can then up the loglevel ... loglevel=8
[15:18] <apw> may get you more, but just as likly not
[15:18] <TeTeT> apw: thanks
[15:18] <TeTeT> apw: quiet and splash was already gone
[15:19] <apw> though addrconf doesn't sound like the kernle
[15:20] <apw> do you have any capture of the lines up to the error ?
[15:48] <apw> bah how did it get to be so late already
[15:49] <tgardner> apw, what is this? http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.11-karmic
[15:49] <tgardner> a mis-fire?
[15:49]  * apw looks
[15:53] <apw> tgardner, yeah thats a false broken build, i'll zap it and get it rebuilt
[15:54] <tgardner> apw, how about similar 2.6.33*lucid and 2.6.34*lucid ?
[15:57] <apw> tgardner, i'll have a finger print for the issue so i should be able to get them all
[16:01] <apw> we'll  find out in a few hours if they build properly this time
[16:02]  * apw drops offline for a bit to move location
[16:16] <manjo> anyone else seeing slow network to/from emerald ? 
[16:22] <ogasawara> kamal: bug 553498 came up in the release meeting today ... but based on comment #52 from yourself, it seems this should be resolved for Maverick
[16:22] <ubot2> Launchpad bug 553498 in linux (Ubuntu Maverick) (and 2 other projects) "Intel Core i3/i5/i7 hang on resume from suspend (SCI_EN) (affects: 13) (heat: 84)" [High,In progress] https://launchpad.net/bugs/553498
[16:23] <ogasawara> kamal: the only thing is I can't see that sha1 id you noted
[16:23] <ogasawara> ~/linux-2.6$ git show 74ca255e19aac16a689d98126c935ad99a47778c
[16:23] <ogasawara> fatal: bad object 74ca255e19aac16a689d98126c935ad99a47778c
[16:23] <kamal> ogasawara: ha!  did I make it all up!?  ;-)  looking
[16:23] <ogasawara> kamal: I'm sure you're not crazy, maybe just a sha1 typo?
[16:24] <kamal> ogasawara: maybe my cut-n-paste button broke! ;-)   gotta boot my other machine -- will be just a minute.
[16:26] <tgardner> ogasawara, hmm, I pasted the same comment in the bug report :)
[16:26] <ogasawara> tgardner: heh, did you really?  maybe I can't read.  /me refreshes
[16:29] <kamal> ogasawara, tgardner:  hmmm.  When I do   git show 74ca255e19aac16a689d98126c935ad99a47778c    I do get the patch I'm talking about.
[16:29] <tgardner> kamal, what repo?
[16:30] <ogasawara> kamal: what's the patch subject?  I can search by that.
[16:30] <kamal> tgardner: I see it in my linux-2.6 and in my ubuntu-maverick repos
[16:31] <kamal> ogasawara: commit 74ca255e19aac16a689d98126c935ad99a47778c   ACPI: Unconditionally set SCI_EN on resume
[16:31] <ogasawara> tgardner: b6dacf63e9fb2e7a1369843d6cef332f76fca6a3
[16:32] <tgardner> b6dacf63e9fb2e7a1369843d6cef332f76fca6a3
[16:32] <manjo> lag, looks like you are beating the heck out of emerald
[16:33] <tgardner> ogasawara, hmm, theres a lot of patch there, but mostly ripping out code
[16:33] <ogasawara> kamal: ok looks like that was upstream as of 2.6.35-rc1.  Since we've already rebased maverick to 2.6.35-rc2 I'm going to mark the Maverick task Fix Released.
[16:34] <kamal> ogasawara: I agree
[16:34] <ogasawara> kamal: for lucid, have you tested with this patch backported?
[16:35] <kamal> ogasawara: yes, I've applied exactly that change to lucid and published a test kernel, and have positive test results from myself and from other people on the bug report.
[16:36] <lag> manjo: My build is finished
[16:36] <kamal> tgardner, ogasawara: any explanation why I see this patch with two different SHA ID's?  (the one you guys found also works in my trees).
[16:36] <manjo> lag, yes I noticed 
[16:36] <manjo> lag how did you get more priority over my build task... it virtually stopped all my builds
[16:37] <tgardner> kamal, perhaps your repo is polluted. try 'git gc;git prune"
[16:37] <lag> I had the same thing with ogasawara yesterday, but the roles are reversed 
[16:37] <lag> It just like the machine has a scheduling issue
[16:38] <lag> looks*
[16:38] <ogasawara> as long as it always schedules me with a higher priority I'm happy :)
[16:38] <lag> Pfft...
[16:38] <manjo> lag, and your build took 1/2 the time mine normally takes 
[16:38] <lag> That's because it wasn't a clean build
=== ericm is now known as ericm-Zzz
=== JanC_ is now known as JanC
[16:58] <bjf> pgraner, ping
[16:59] <pgraner> bjf: pong
[17:04] <manjo> tgardner, @selinuxfest
[17:04] <tgardner> mpoirier, manjo, lag, cnd, sconklin - bouncing emerald for new kernel 2.6.35.2.7. ready soon?
[17:04] <manjo> tgardner, I have a build going 
[17:04] <tgardner> manjo, lemme know  when its done
[17:05] <manjo> tgardner, ack
[17:05] <mpoirier> not good.
[17:05] <mpoirier> you're just doing to reboot ?
[17:06] <cnd> tgardner: I can be off, can you give me a 3 min heads up before you do so?
[17:06] <tgardner> mpoirier, yep, just a reboot
[17:06] <mpoirier> give me 10 minutes, just to finish compilation/git clone.
[17:07] <mpoirier> I'll touch base with you.
[17:07] <sconklin> tgardner: any time is fine for me
[17:07] <sconklin> tgardner: I had kernel builds in the lucid chroot hang yesterday during linking on emerald
[17:08] <tgardner> sconklin, which is why I'm updating the kernel. I think there are some fixes for taht
[17:08] <sconklin> great
[17:08] <lag> tgardner: I'm okay with it
[17:11] <tseliot> mjg59: so, any ideas? I'm asking you as you're the author of that moduel
[17:11] <cnd> big storm overhead, lost power once, may lose it again
[17:12] <mjg59> tseliot: What hardware is this?
[17:12] <cnd> tgardner: feel free to take the machine down anytime
[17:12] <cnd> power loss disrupted my work anyways
[17:12] <tseliot> mjg59: it's an unreleased inspiron
[17:13] <tseliot> mjg59: with fglrx and acpi_listen I get the following: video VGA2 00000081 00000000
[17:14] <tseliot> mjg59: the F1 button acts as a video switch while Fn+F1 acts as F1
=== sconklin is now known as sconklin-afk
[17:16] <mjg59> tseliot: Ok, so you should be getting KEY_SWITCHVIDEOMODE through the ACPI video driver
[17:16] <mjg59> Are you not?
[17:16] <tseliot> mjg59: no, I'm not. Nothing happens if I use the radeon driver instead of fglrx
[17:17] <tseliot> and no output in acpi_listen
[17:17] <mjg59> Well, then there's a bug somewhere
[17:17] <mjg59> I don't think it has anything to do with dell-wmi
[17:17] <tseliot> do you think it can be the graphics driver?
[17:17] <mjg59> Can you send me the acpidump for the machine?
[17:17] <bjf> http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/3.1rc2/linux-i686/en-US/thunderbird-3.1rc2.tar.bz2
[17:18] <mjg59> I have NDAs with Dell
[17:18] <tseliot> mjg59: sure
[17:20] <mjg59> Anyway, lunchtime
[17:21] <tseliot> mjg59: BTW I'm also booting with acpi_osi="!Windows 2009"
[17:21] <mjg59> Why?
[17:21] <mjg59> Oh, because otherwise it sends Windows+P?
[17:21] <tseliot> yep
[17:21] <mjg59> Ok, don't bother sending me the acpidump
[17:21] <mjg59> Eh. Actually, do
[17:22] <tseliot> I will
[17:22] <mjg59> mjg@redhat.com is probably the best
[17:22] <mjg59> But I suspect that the correct fix here is "Make sure windows+p does the right thing", since we're not going to modify the kernel to disable the Windows 7 OSI string
[17:22] <tseliot> mjg59: ok, I'll send it there, thanks
[17:23] <tseliot> ah
[17:27] <tseliot> mjg59: the key also seems to send an enter key event after a few seconds (per spec)
[17:31]  * apw wanders back
=== sconklin-afk is now known as sconklin
[17:35] <apw> tseliot, where in the spec do you see the return being mandated 
[17:35] <tgardner> mpoirier, manjo - about to bounce tyler
[17:35] <manjo> tgardner, OK
[17:35] <tseliot> apw: something worth asking mterry
[17:36] <mpoirier> I'm out of tyler
[17:36] <apw> tseliot, i don't even see the spec saying win-P is required
[17:41] <winlundn> 1364926 objects in karmic, ha. How-dee, all
[17:43] <winlundn> apw: they're doing that in ayatana
[17:43] <winlundn> voluntary
[17:44] <winlundn> just over a mil objects in jaunty. cool, I like git
[17:44] <tseliot> apw: you may want to ask mterry the same question again
[17:44] <tseliot> now that he's here
[17:45] <apw> mterry, where do we see a requirement for the return after the win-p in the windows spec
[17:46] <mterry> apw, oh, you're going to ask me hard questions.  let me try to find the reference for that
[17:46] <mterry> apw, jerone knows more on this than I do, will try to find him talking about it in email
[17:47] <apw> mterry, i've not even found a reference in any of his docs that says win-p should be generated.  only that pressing win-p produces that dialog and your button should produce the same one
[17:47] <apw> which is miles from must produce win-p
[17:48] <apw> winlundn, i don't think i understand you
[17:49] <winlundn> unrelated to what you're talking about now, I see. My mistake
[17:49] <apw> winlundn, ahh ok
[17:55] <mjg59> tseliot: Well, I see part of the problem
[17:55] <mjg59> Looks like Radeon needs to call the ATIF method
[17:55] <mjg59> I'll talk to AMD about that
[17:56] <tseliot> mjg59: thanks
[18:00] <mterry> apw, everything I know is in bug 539477.  Jerone says (comment #40) that he has a secret data sheet that recommends the logic he outlines in comment #39.   The one presentation he can link to has (slide 36) says that "modifying ACPI hot key to display Windows 7 projection hot key" is "highly recommended".  which doesn't talk about return key, but does imply that BIOS should report Super+P for the display key
[18:00] <ubot2> Launchpad bug 539477 in linux (Ubuntu) (and 4 other projects) "Video out hot key sends super + p + return on many upcoming Dell & HP systems (affects: 10) (dups: 1) (heat: 110)" [Undecided,Confirmed] https://launchpad.net/bugs/539477
[18:00] <mterry> apw, presumably Jerone can share the secret data sheet with you
[18:02] <apw> mterry, i think he has, and as i say i just cannot see what they are doing as mandated
[18:03] <mterry> apw, "what they are doing" means the return key?
[18:03] <mterry> apw, I haven't seen the data sheet.  You're saying that it's not even suggested?
[18:03]  * winlundn is always going to look at acpi and go, ``Oh that.''
[18:04] <apw> mterry, i don't even see the wording meaning you need to win-p at all, cirtainly there was nothing saying anything about also hitting return for the user
[18:04] <apw> it is a god awful idea
[18:05] <mterry> apw, agreed.  :)  slide 36 has the language I quoted.  That doesn't strike you as suggesting Super+P?
[18:05] <mterry> apw, to my eyes it directly says as much
[18:05] <apw> it says what super-p will produce, and says any magic key should produce the same dialog
[18:06] <apw> i don't see words saying tehy are the same
[18:06] <mterry> apw, no, it says any magic key should "display win7 projection hot key"
[18:06] <mterry> apw, it doesn't say anything about a dialog there
[18:06] <apw> it says display, not type or send
[18:06] <apw> and even if i am very generous and accept that win-p is required
[18:06] <apw> read me the bit about return being required
[18:07] <mterry> apw, agreed.  But it also says hot key.  And if it was intended that the dialog come up for the magic key, it would be done on win7 side, no need to ask bios people to change anything
[18:07] <mterry> apw, so it sounds like they are asking bios people to change reported hot key
[18:08] <mterry> apw, (I mean, if MS wanted dialog to come up for old VIDEOSWITCHMODE key press, they could do it themselves, don't know why that request would be directed at BIOS people)
[18:08] <apw> i don't agree, but that is imeterial to my point which is the extra return is not mentioned, and that would be a sane thing to do in the win7 side if desired
[18:08] <apw> ie if the dialog should be self answering why would win7 not do that, why would the bios need to be involved
[18:09] <winlundn> aye, metric
[18:09] <mterry> apw, well, Jerone says that the return behavior is clearly spelled out in his secret data sheet.  You say you've seen this sheet but don't agree.  I can't really add anything to this discussion
[18:09] <mterry> apw, except to say that BIOS's in the wild are doing this
[18:10] <apw> that bios vendors do stupid things is the very definition of the breed
[18:10]  * manjo going down for a reboot
[18:10] <apw> there is almost no way to do anything sane with those semantics
[18:10] <mterry> apw, except to ape Win7 exactly (throw up a dialog, etc).  Which I agree is a crazy requirement to have to meet
[18:12] <winlundn> mterry: yes, from what I understand that's bridging that where it's un-needed
[18:23] <apw> tgardner, the first rebuild just completed, looking good
[18:24] <tgardner> apw, ack
[18:25] <apw> right beer time ... see yo lot
[18:27] <tgardner> apw, havea good weekend
[18:27] <ogasawara> Mmmm beer
[18:27] <tgardner> ogasawara, you wish.
[18:28] <ogasawara> tgardner: I'm still going through withdrawl
=== sconklin is now known as sconklin-afk
[19:36] <philsf> hi, I can't get my bluetooth adapter to be recognized with Lucid's 2.6.32 kernels. The last one I got it working it, was the 2.6.31 from beta stage. I also lost ability to use my wifi killswitch (which also works with the old .31). How can I debug this, so can I open a proper bug? Sorry for asking here, but no one answered in #ubuntu
[19:39] <manjo> philsf, does lsusb list anything ? 
[19:40] <philsf> manjo, nope
[19:40] <manjo> philsf, what adapter is it ? 
[19:40] <manjo> philsf, what make model of laptop ?
[19:40] <philsf> hmm, I think I'll have to reboot in 2.6.31 to see what module it uses
[19:41] <philsf> it's an Asus EEEpc 1005HA
[19:41] <philsf> netbook
[19:41] <manjo> philsf, yep please do
[19:41] <philsf> ok, I'll check back here then, thanks
[19:41] <manjo> that will be the easiest way to find out what device/driver we are missing 
[19:45] <manjo> philsf, https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/416487
[19:45] <ubot2> Launchpad bug 416487 in bluez (Ubuntu) (and 1 other project) "Bluetooth Doesnt Work - Eee PC 1005HA-P (affects: 5) (dups: 1) (heat: 32)" [Undecided,Won't fix]
[19:46] <philsf> manjo, lsusb gives now Bus 005 Device 002: ID 0b05:b700 ASUSTek Computer, Inc. Broadcom Bluetooth 2.1
[19:46] <philsf> wontfix?
[19:46] <manjo> philsf, a while back I found the problem with bios that prevented bluetooth 
[19:46] <manjo> philsf, please look at the bug see if that is the same you are experiencing 
[19:47] <philsf> I will. what about the radio killswitch, is it the same problem?
[19:48] <manjo> philsf, not sure about radio kill switch... I think there was a recent patch for it ... 
=== sconklin-afk is now known as sconklin
[19:51] <philsf> manjo, it looks like the same issue, I'll try upgrading the bios, thanks
[19:52] <manjo> tgardner, build on emerald still hangs (mine hangs in [LD]
[19:52] <manjo> philsf, cool!
[19:54] <jjohansen> -> Lunch
[20:17] <bladernr> Can someone clarify something for me about the time stamping in kernel messages?
[20:17] <bladernr> Jun 11 11:46:02 klaatu kernel: [  184.568662] ehci_hcd 0000:00:1d.0: PCI INT A disabled
[20:17] <bladernr> am I correct in reading that as 184.5 seconds since boot?
[20:17] <manjo> does any one know what this means ? chroot: cannot run command `mount': Exec format error
[20:18] <manjo> I get this when I try to create my chroot env using the build-chroot scripts 
[20:18] <phunge0> bladernr: yes i believe it's since boot
[20:19] <bladernr> any way to reset that without a reboot?  Because, according to my logs (64 bit 10.04) I have been running either a few thousand seconds or over 18 billion seconds...
[20:21] <bladernr> Here'e one example: http://pastebin.ubuntu.com/448373/
[20:23] <bladernr> And here's some showing just before entering S3, and just after starting the resume: http://pastebin.ubuntu.com/448374/
[20:24] <tgardner> bladernr, it sounds like your TSC is getting wonky. its a known problem on some classes of CPU. Atom for example.
[20:24] <bladernr> Hrmmm... ok.  It's a quad core i7...
[20:25] <bladernr> Oddly enough, my atom based netbook doesn't seem to have this issue
[20:37] <kees> ogasawara: so, I take it maverick's tree rebased recently.  how should I deal with this for my local trees?  "git pull" alone doesn't seem to cut it.
[20:37] <ogasawara> kees: yep, we rebased to 2.6.35-rc2 a few days ago
[20:37] <ogasawara> kees: you should be able to git fetch origin
[20:38] <tgardner> kees, if you've no local changes then 'git fetch origin master;git reset --hard FETCH_HEAD'
[20:39] <kees> tgardner: gotcha, yeah.
[20:42]  * ogasawara lunch
[20:47] <kees> tgardner: and how do I rebase local branches that are based on the now-rebased maverick?
[20:47] <tgardner> kees, git checkout -f YOUR_BRANCH;git rebase master
[20:48] <tgardner> kees, if they are in the same repo
[20:49] <kees> that fails for me.
[20:49] <tgardner> rebase conflicts?
[20:49] <kees> not from my changes.  my change was a single commit on top of regular maverick, and now it's yelling about merge conflicts in debian/*
[20:50] <lag-mobile> Can you do cross-repo rebasing?
[20:50] <kees> $ git rebase maverick
[20:50] <kees> First, rewinding head to replay your work on top of it...
[20:50] <kees> Applying: UBUNTU: Fold down debian for ubuntu-m
[20:50] <kees> Using index info to reconstruct a base tree...
[20:50] <kees> <stdin>:160857: trailing whitespace.
[20:50] <kees> ....
[20:50] <kees> *boom*
[20:50] <kees> and that rewind took a looong time
[20:51] <kees> I assume it tried to find the branch point and re-applied the entire old maverick stack to the rebased maverick stack.
[20:51] <kees> how do I tell it "throw away all of this except my top commit" ?
[20:51] <tgardner> kees, ah. then the simplest thing to do is restore your original branch and save off your local patch; git checkout -f YOUR_BRANCH;git format-patch -1;git fetch origin master;git reset --hard FETCH_HEAD;git am 0*
[20:52] <tgardner> kees, does that make sense?
[20:53] <kees> tgardner: yeah.  though it seems a bit clumsy.  I was hoping to automate this, so "-1" won't always be correct.  hmmm
[20:53] <tgardner> kees, it is clumsy, but its conceptually simple (for me at least)
[20:53] <kees> yeah
[20:58] <kees> tgardner: oh, actually, can't I use FETCH_HEAD as the cut-off for doing the format-patch, since it was set during the last fetch?
[20:59] <tgardner> kees, I'm not sure that makes sense because your local patches are relative to HEAD.
[21:00] <kees> hm.
[21:00] <tgardner> kees, once we stop messing with the debian cruft then rebasing will likely work better.
[21:02] <kees> I mean, if I do this:  git checkout master; git fetch origin master;git reset --hard FETCH_HEAD; git checkout -b test-branch; *work*commit*; git checkout master; git fetch origin master;git reset --hard FETCH_HEAD; git checkout test-branch.  isn't FETCH_HEAD here equal to where I started my work? as in FETCH_HEAD through HEAD are my local patches, so I could do git format-patch FETCH_HEAD; git fetch origin master;git reset --hard FETCH_HEAD;git am
[21:03] <tgardner> kees, you're making my head hurt.
[21:03]  * kees blames git
[21:03] <kees> also, I think git am is lossy, in that it starts ignoring text after a --- line
[21:04] <tgardner> kees, which is why I never use it unless its been a 'git format-patch' created file
[21:05] <kees> well... i have format-patch'd patches that include --- for the purpose of having "am" drop the text after it when someone upstream takes my patch (i.e. I have the patch version history after ---), but I don't want to lose it locally.  that said, I think rebase might be able to do a "from, to" kind of a thing here.
[21:05]  * kees goes off to dig
[21:10] <kees> I think some combination of --onto and --root is needed
=== sconklin is now known as sconklin-gone
[23:00] <kees> hm.  .35 doesn't boot for me.
[23:00] <kees> seems to hang the system
[23:11] <jjohansen> kees: well it is only at RC2
[23:12] <kees> but it's been uploaded to the archive...
[23:36]  * bjf is headed to work out
=== bjf is now known as bjf[afk]