=== smb` is now known as smb
[08:11] <ppisati> moin
[08:14] <smb> morning
[08:22] <ppisati> i love the smell of Linus's rants in the morning
[08:38]  * smb rather prefers the scent of fresh coffee...
[08:38] <ppisati> :)
[08:38] <smb> ppisati, what is going wrong today? :)
[08:39] <ppisati> smb: nothing yet, but it could get worse
[08:39] <ppisati> it could rain :)
[08:40] <smb> it could snow if it was colder... no, anything particular that roused Linus?
[08:42] <ppisati> smb: opensuse security model requiring root password for everything
[08:42] <ppisati> smb: he said one of his daughter called him from school saying she couldn't add school's printer without root pwd
[08:42] <ppisati> you can imagine his reaction... :)
[08:42] <smb> heh. :) can imagine
[08:43] <ppisati> but the real question is, did he give the root pwd to hhis daughter at the end or not? :)
[08:44] <smb> maybe remote login and change it after... well in some way the security of being able to do all those things with your default user is relatively similar
[08:45] <ppisati> yeah
[08:45] <ppisati> but i agree he has a point
[08:45] <diwic> why not boot from a live-CD and just change the root pwd that way?
[08:46] <ppisati> he mentions some other mundane tasks like chaging wireless network or date/timezone
[08:48] <smb> Yes, I guess there are probably things/subsystems which you would expect to operate on their own rights without requiring additional ones. At least making decisions only affecting your profile
[08:50] <ppisati> right
[08:50] <ppisati> and i wonder where we stand in this stance
[08:50] <ppisati> e.g. will Linus's daughter be able to add a printer without root? changing network? timezone?
[08:51] <ppisati> anyway, dist-upgrade just finished, brb
[09:05] <smb> ppisati, Guess in out case she would not need the non-existent root password but do a lot of things as root anyway. :)
[09:06] <ppisati> :)
[09:23]  * apw yawns
[10:53] <cking> hrm, creating a minimal USB DOS image for a BIOS upgrade from scratch is interesting
[11:16] <Daviey> cking: does freedos not cover it?
=== gema_ is now known as gema
[11:42] <cking> Daviey, I wish it did, but alas no
[11:57] <ppisati> perhaps i'm drunk, but it seems i'm getting a completely different panic on armhf vs armel...
[12:41]  * henrix is out for lunch
[12:47] <apw> ppisati, if that is a float triggered issue then it could easily be different
[13:41] <apw> henrix, i assume we are still committing to lucid/mvl-dove, in order to make maverick/mvl-dove
[13:41] <apw> herton, ^^
[13:41] <apw> (a new h on the block, messing up my tab completion)
[13:42] <herton> apw, yes, ppisati usually pushes on his branch, I push the updated branch
[13:47] <ppisati> apw: yep, i update my zinc branch and then pull from it for M/dove
[13:48] <herton> then I verify and push to "master" (lucid/mvl-dove, maverick/mvl-dove) when ppisati sends the request to fetch/pull
[13:49] <ppisati> herton: ah btw, Houston we have a problem
[13:49] <ppisati> latest P/omap4 update is ok for armel
[13:50] <ppisati> while it complains about a missing module for armhf
[13:50] <ppisati> any way we can fix it?
[13:50] <ppisati> i mean, can we withdraw the pull and fix it? or it's already queued and thus we are screwed?
[13:50] <herton> ppisati, I think tgardner is taking care of P
[13:51] <ppisati> herton: yes, but he forgot we have armhf too
[13:51] <ppisati> herton: so he fixed the armel side only
[13:51] <ppisati> ah right, you are the stable team... :)
[13:54] <herton> yes, you have to see with him this, not sure what he already done/queued
[13:57] <apw> ppisati, which module is missing ?
[13:58] <apw> (i presume by this it is meant to be missing now)
[13:58] <ppisati> apw: the led heartbeat was compiled in
[13:58] <ppisati> apw: tim took care of the armel side, but not armhf
[13:58] <apw> oh yeah, so i assume it was a build faliure on armhf
[13:58] <ppisati> yep
[13:59] <ppisati> but since it takes AGES to build a kernrl on one of our arm builders, if we can fix it would be nice
[13:59] <apw> ppisati, so its not uploaded yet
[14:00] <ppisati> nope
[14:03] <herton> removing  ledtrig-heartbeat from debian.ti-omap4/abi/3.2.0-1406.8/armhf/omap4.modules should fix it, may be fixing the commit and rebasing, on push a fix on top, should do it
[14:04] <herton> *or push a fix on top
[14:04] <apw> herton, yeah easy to fix, will do that and repush it
[14:28] <ppisati> apw: thanks
[14:37] <apw> ppisati, pushed ... and tim emailed just in case
[14:43] <ppisati> apw: cool, thanks
[14:57] <henrix> cking: ping
[14:58] <henrix> cking: i remember you were asking yesterday something about ath9k-related panics...
[14:58] <cking> henrix, yep
[14:58] <henrix> cking: well, i accidentaly came across this commit: 07445f688218a48bde72316aed9de4fdcc173131
[14:59] <henrix> cking: not sure if related with the bug you were looking at...
[14:59] <henrix> and it looks like its not on precise
[15:00] <cking> henrix, that's a great find - I will spin a test kernel with that in for the user who's seeing issues with it - thanks!
[15:00] <henrix> it may be completely unrelated, but worth taking a look ;)
=== yofel_ is now known as yofel
[15:00] <henrix> btw, its already on stable
[15:03] <apw> henrix, nice :)
[15:03] <cking> it sounds like it definitely worth trying :-)
[15:03] <henrix> cool
[15:03] <henrix> i was looking for something completely unrelated on stable... and just found this
[15:19]  * ogasawara back in 20
[16:16] <jsalisbury> cking, henrix, comment #13 was added to bug 894584  This is someone other than the original bug reporter reporting panics possibly related to ath9k
[16:16] <ubot2`> Launchpad bug 894584 in linux "ath9k driver causes kernel panic" [Medium,Confirmed] https://launchpad.net/bugs/894584
[16:19] <cking> jsalisbury, I'll take a peek at that once I've popped my stack of things to do
[16:19] <jsalisbury> cking, cool.  Not much to look at.  Just another person stating they see panics and thing they could be related to ath9k.  I asked them to post a screen shot of the panic.
[16:22] <henrix> cking: have you managed to build the test kernel?
[16:22] <cking> henrix, yep, uploading the debs is taking a while at the mo
[16:22] <henrix> ah, ok. cool
[16:23] <cking> patch applied cleanly which is good
[16:23] <henrix> since we have a "fresh" comment, maybe the new guy may be able to test it quickly :)
[16:24] <cking> the user is sporadic, sometimes he tests immediately, sometimes it takes a week or more to get back to me
[17:21] <brendand> hey
[17:22] <brendand> if i install on a system with > 3GB of RAM, is there something that tells the -pae kernel to be used?
[17:22] <brendand> past experience shows this to be the case on my main laptop
[17:23] <brendand> but not sure if this is 'guaranteed'
[17:28] <brendand> in other words, is it a bug for a system which needs pae to address all it's memory not to install it?
[17:31] <brendand> never mind
[17:31] <brendand> preseed #fail
=== Guest54222 is now known as albrigha
[18:51] <JanC> a non-PAE kernel kan address 4 GiB of RAM, which is > 3 GiB...  :P
[20:05]  * cking ->EOD
=== bladernr_ is now known as bladernr_afk
[21:30] <jdstrand> ogasawara, jsalisbury: thanks for your work on bug #911059
[21:30] <ubot2`> Launchpad bug 911059 in linux "Intel wireless randomly drops connection" [High,Fix committed] https://launchpad.net/bugs/911059
[21:32] <ogasawara> jdstrand: np, jsalisbury did all the heavy lifting.
[21:43] <bjf> jjohansen: bug 931627 has been waiting for your signoff
[21:43] <ubot2`> Launchpad bug 931627 in kernel-sru-workflow/security-signoff "linux: 2.6.24-31.99 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/931627
[21:44] <jjohansen> bjf: hrmm, right sorry /me has been deal with a mailbox implosion
[21:44] <bjf> jjohansen: np, this was just a reminder :-)
[21:45] <jjohansen> bjf: looking at it now