[06:31] <ppisati> moin
[08:07] <smb> morning
[08:09]  * cking waves to smb
[08:09]  * smb waves his coffee mug back
[08:11] <cking> ah coffeeeeeee
[08:52] <ppisati> brb
[10:25]  * cking re-configs his network.. maybe off line for a while
[12:40]  * henrix hates his ISP!
[14:27] <rtg> jsalisbury, need to reboot tangerine for kernel update. you doing anything ?
[14:28] <jsalisbury> rtg, not currently.  Thanks for the heads up.
[14:28] <rtg> jsalisbury, you've got a couple of open sessions
[14:28] <rtg> ppisati, ^^
[14:28] <jsalisbury> rtg, just some bisects.  I can re-open them.  I keep track of them locally.
[14:29] <ppisati> rtg: go ahead
[14:48]  * ogasawara back in 20
[14:51] <cjwatson> Hi.  https://launchpadlibrarian.net/118007057/buildlog_ubuntu-quantal-armhf.debian-installer_20101020ubuntu179_FAILEDTOBUILD.txt.gz is a kernel packaging problem.  Anyone know what happened to crypto-modules in linux-armadaxp?
[14:51] <cjwatson> (quantal)
[15:02] <rtg> cjwatson, crypto-modules were explicitly excluded in Ike's tree, though no explanation was given. debian.armadaxp/d-i/exclude-modules.armhf-armadaxp:crypto-modules
[15:03] <rtg> the tree that he has made public is not up to date with what has been most recently uploaded
[15:04] <cjwatson> OK, that may be correct as far as it goes (perhaps all the modules are built in), but in that case I need debian.armadaxp/d-i/package-list to gain a "Provides: crypto-modules" in the "Package: kernel-image" paragraph
[15:04] <cjwatson> ikepanhc: ^-
[15:04] <rtg> cjwatson, this is a HWE owned kernel, so I'll bug Jani who uploaded last.
[15:04] <cjwatson> OK
[15:05] <ikepanhc> cjwatson: rtg: ACK
[15:05] <cjwatson> Can't really fix it otherwise - this is one of the special cases that has to exist
[15:06] <rtg> ikepanhc, I assume you and jani will work this out ?
[15:06] <ikepanhc> rtg: yes, I will file the bug first
[15:10] <cjwatson> thanks
[16:01]  * cking --> runs some errands
[16:14]  * ppisati -> gym
[17:19]  * rtg -> lunch
[17:23] <kamal> mjg59: hi Matthew!   in drivers/platform/x86/dell-wmi.c why is KEY_KBDILLUMTOGGLE set to KE_IGNORE?   on my XPS 13, the keyboard backlight fkey toggle works anyway (mostly), but if I do change that to KE_KEY, then I also get a pretty OSD notification bubble thingie.
[17:40] <bjf> sforshee, that latest test kernel has been working really well so far. no major issues.
[17:59] <infinity> ikepanhc: Around?
[18:01] <infinity> ikepanhc: The 3.5.0 armadaxp kernel is missing the crypto-modules and mouse-modules udebs.
[18:01] <infinity> ikepanhc: Oh, I see cjwatson already brought it up.
[18:02] <cjwatson> I didn't notice mouse-modules.
[18:02] <cjwatson> Not sure that's so important since I don't think any non-modules udebs depend on it.
[18:02] <infinity> cjwatson: I was just comparing 3.2.0 to 3.5.0 in rmadison.
[18:02] <infinity> cjwatson: mouse-modules may or may not be an issue.
[18:02] <cjwatson> d-i currently uses it unconditionally in netboot/gtk.
[18:03] <cjwatson> However, that isn't built in any flavour we care about.
[18:03] <infinity> Yeah, but I'm not sure we build that.
[18:03] <infinity> Right.
[18:03] <cjwatson> s/flavour/subarch/
[18:03] <cjwatson> So only crypto-modules matters.
[18:06] <infinity> Hrm, I clearly didn't commit my d-i change.  yay conflicts.
[18:07] <sforshee> bjf, good, seems I'm on the right track then
[18:07] <sforshee> bjf, I started completely rewriting the brcmsmac queueing code this morning
[18:08] <sforshee> bjf, there are still a few issues I'm aware of in the kernel you're running
[18:12] <ikepanhc> infinity: and also mouse-modules?
[18:13] <infinity> ikepanhc: Well, mouse-modules is missing compared to 3.2.0, but perhaps not a big deal either, as pointed out above, since we don't build the GTK d-i bits anyway.
[18:13] <cjwatson> Yeah, really don't care about that.
[18:13] <ikepanhc> infinity: I can upload 3.5.0-1602.4 with crypto-modules generated
[18:14] <ikepanhc> infinity: where I shall upload it
[18:14] <infinity> ikepanhc: That would be lovely.
[18:14] <infinity> ikepanhc: Straight to the release pocket is fine.
[18:14] <infinity> ikepanhc: Assuming it really isn't an ABI bump...
[18:14] <ikepanhc> infinity: no abi bumped
[18:14] <infinity> (Which seems odd, if you're changing configs)
[18:15]  * ikepanhc checks again .dsc and .changes
[18:15] <rtg> infinity, prolly no config changes, just udeb packaging BS
[18:16] <infinity> rtg: ;)
[18:17] <cjwatson> Hey, I never wanted it to be handled by the kernel packaging in the first place. :-P
[18:17] <cjwatson> (But I was overruled and it's probably unreasonable to revert that now)
[18:17] <rtg> cjwatson, really ? did that argument predate me ?
[18:17] <cjwatson> (Especially since Debian has since done the same)
[18:17] <cjwatson> Yea
[18:17] <cjwatson> er, yes
[18:18] <cjwatson> It was from the Herbert era
[18:18] <rtg> huh, I never thought packaging udebs in the kernel made sense
[18:18] <cjwatson> It saves an extra upload cycle every time
[18:18] <cjwatson> So there is some rationale to it
[18:20]  * henrix -> EOD
[18:20] <ikepanhc> cjwatson: uploaded, will check how it build tomorrow first thing
[18:22] <cjwatson> Thanks
[20:32]  * rtg -> EOD
[21:22] <Aquilas> Hey guys my program is accessing a kernel module to read/write to a proc file. Within the code of the module(kernel space) I need to get the current thread id. I have process id. Does anyone know how to get this?
[21:34] <bjf> sforshee, still around?
[22:21] <mjg59> kamal: Good question! I think that came from Dell.