[07:44] <asac> we have problems getting http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ath6k.tar.gz :) ... wonder if we have that in any ubuntu firmware package in archive?
[07:51] <asac> found it in linux-firmware (obviously) ... thanks
[09:46] <apw> Trying 2a01:450:10:1::10...
[10:04] <Kano> hi, since 2 weeks no updates to mainline kernel. why cant somebody change the git repo?
[10:08] <apw> Kano, hadn't considered it, we have enough problems due to that breakin as it is
[10:08] <Kano> couldnt be a huge change in your script i think
[10:09] <Kano> also i forgot how to update the kernel config with your package, something with update-config or so?
[10:09] <apw> probabally not even a change there, probabally only need to change the remote url
[10:09] <apw> fakeroot debian/rules updateconfigs
[10:09] <Kano> ah
[10:10] <Kano> i did a grep in the rules and did not find it
[10:10] <Kano> also i had to remove the dpkg >... depend, why is that there?
[10:11] <Kano> hmm, maybe fix your target
[10:11] <Kano> debian/scripts/misc/kernelconfig: line 130: /root/kernel/linux-3.0.0/debian/scripts/misc/splitconfig.pl: Permission denied
[10:11] <Kano> in your release package
[10:12] <apw> thats a 'problem' introduced by the orig+patch format for debian
[10:12] <apw> those are not really intended for use against the package but in the git repo
[10:12] <apw> where the permissions are honoured
[10:12] <Kano> chmod 755 there
[10:12] <Kano> same for config-check
[10:13] <apw> yep, you simply cannot represent that in the package
[10:13] <Kano> but you can add that in the rules
[10:13] <apw> patch does not carry executable information at all, and can not do so
[10:13] <Kano> thats not impossible
[10:14] <apw> yeah, but we never use it that way ever, its not our process model, so we'd never notice
[10:14] <apw> the normal debian way is not chmod, but to change it to like $(PERL) script or $(SHELL) script
[10:15] <Kano> well then use that
[10:15] <apw> or i could spend my time fixing cves
[10:15] <apw> its a priority thing, its not a priority as noone working they way we intend would ever hit it
[10:15] <apw> and they will hit the cves
[10:16] <apw> but we'd happily accept a patch if someone figured out all the places it is needed
[10:16] <Kano> what was the reason to add dpkg >..?
[10:17] <Kano> not mentioned in changelog
[10:17] <apw> in which release
[10:18] <Kano> oneric
[10:18] <apw>     UBUNTU: [Config] Make linux-libc-dev coinstallable under multiarch
[10:19] <Kano> ok, i dont build that, can ignore that
[10:20] <Kano> it build still too much, like tools/source/doc with emtpy packages
[10:20] <apw> yep, we only turn those off for debugging builds, and its simpler to handle the empty packages than add a bunch of handling to the control file generation to turn them off
[10:21] <Kano> i would prefer when they would not build at all when i disable em
[10:21] <Kano> i dont see those in mainline too
[10:22] <apw> right in mainline i use the uber-complex 'rm' command to remove them before syncing them out
[10:23] <Kano> well if you have got free time maybe consider em not to build
[10:23] <apw> i have considered it, i have even got patches to do it, and it makes the rules vile and complex
[10:23] <apw> for something we never use
[10:24] <apw> and afterall they are our packages to build our kernel not all things to all men
[10:24] <Kano> well they would be more usefull
[10:25] <Kano> i always try to write scripts as generic as possible
[10:25] <cking> generic for whom?
[10:26] <apw> so do we but at some point one has to trade genericity for maintainability
[10:26] <apw> we have to maintain them for years against old kernels and that is not free
[10:27] <Kano> well i just want to script all changes i need against your packages
[10:28] <apw> so what you are saying is, its too much effort for you to fix the packaging, but you think we should
[10:28] <Kano> well you know the packageing
[10:29] <apw> indeed, so which is more important for your kernel
[10:29] <apw> having pretty packaging that allows a derivative to build easily, or having CVEs fixed in your kernle
[10:29] <apw> as right now, that is what you are stopping me doing
[10:29] <Kano> well i mainly use that for live mode, i need mainline builds...
[10:29] <Kano> for the hd installs
[10:31] <Kano> i write a tiny script for every kernel update, but there is no update
[10:31] <Kano> daily is of course always the same script
[10:32] <apw> yep the entire kernel.org infrastucture being compromised has been a huge problem
[10:32] <apw> not least because it has _prioritised_ security fixes above _ALL_ELSE_
[10:32] <apw> now i wonder why that would be
[10:35] <Kano> you mean for the older kernels?
[10:36] <Kano> the latest is on github, that should be no problem to build rc6/daily
[10:43] <apw> yep, indeed and i'll put it on my todo list
[10:57] <Kano> is armel somehow differently handled? not that i would use it but
[10:59] <Kano> http://paste.debian.net/129942/
[11:01] <apw> no its not handled differently
[11:02] <Kano> why is there no 1000 hz for it then
[11:03] <apw> perhaps because it can't do 1000Hz ?
[11:03] <Kano> maybe
[11:03] <cking> 1000Hz for arm is a bit excessive isn't it?
[11:03] <apw> 1000HZ == 10% powerformance cost too
[11:09] <Kano> what bootloader is used on arm?
[11:12] <apw> depends on the board they are all different pretty much
[12:16] <Kano> the wireless-cdra package is weird, it has got no depends but
[12:16] <Kano> crda: error while loading shared libraries: libnl-genl.so.3: cannot open shared object file: No such file or directory
[12:16] <apw> sounds like a bug to me
[12:19] <AnAnt> Hello
[12:20] <AnAnt> I am developing a kernel module under Ubuntu, sometimes this module causes the PC to freeze, is there a way to get dmesg (or whatever debug info) output over the network ?
[12:20] <apw> AnAnt, netconsole might do it, depending how hard it freezes
[12:22] <AnAnt> apw: how about serial port (note, the PC does not have a serial port, but I can use a USB/serial converter)
[12:22] <apw> usb serial can work sometimes, again depending on how hard the kernel is crashing
[12:58] <tgardner> apw, need to bounce gomeisa for kernel update
[13:00] <apw> tgardner, ACK now is as good a time as any
[13:02] <AnAnt> apw: thanks
[13:02] <apw> tgardner, let me know when its done i have some builds pending
[13:02] <tgardner> apw, its bouncing, should be back up in 90 seconds or so
[13:03] <AnAnt> apw: how to do it on serial ?
[13:03] <apw> AnAnt, usb serial? 
[13:03] <AnAnt> apw: yes
[13:03] <apw> just add console=ttyUSBN I think
[13:04] <AnAnt> ok, thanks
[13:05] <AnAnt> apw: so I can only set the serial console during boot?
[13:05] <apw> i believe so ... never heard of any way to add them
[13:07] <AnAnt> apw: ok, thanks a lot
[13:30]  * ogasawara back in 20
[13:33] <cking> apw, git://kernel.ubuntu.com/cking/pmdebug.git --> systemtap/s3.stp  led_flash()
[13:41] <ppisati> herton: lucid was respinned, and the reverted patchset was only the i915, right? i'll invalidate all the derivative arm lucid bug trackers
[13:42] <herton> ppisati: yep
[14:10] <apw> $ ps -ef | grep gcc | wc -l
[14:10] <apw> 282
[14:10] <apw> $ ps -ef | grep cc1 | wc -l
[14:10] <apw> 41
[14:29] <hallyn> so is there a non-kernel.org mirror of Linus' tree right now?
[14:29] <apw> hallyn, yes
[14:29] <hallyn> Need to base some patches on it to send upstream...
[14:30] <apw> git://github.com/torvalds/linux
[14:30] <hallyn> apw: great, thanks
[14:49] <ogasawara> ubuntu-oneiric$ git push origin :Ubuntu-P-sync
[14:49] <ogasawara> remote: *** Deleting a tag is not allowed in this repository
[14:49] <ogasawara> remote: error: hook declined to update refs/tags/Ubuntu-P-sync
[14:49] <ogasawara> To git+ssh://zinc.canonical.com/srv/kernel.ubuntu.com/git/ubuntu/ubuntu-oneiric.git
[14:49] <ogasawara>  ! [remote rejected] Ubuntu-P-sync (hook declined)
[14:49] <ubot2`> ogasawara: Error: I am only a bot, please don't think I'm intelligent :)
[14:49] <ogasawara> error: failed to push some refs to 'git+ssh://zinc.canonical.com/srv/kernel.ubuntu.com/git/ubuntu/ubuntu-oneiric.git'
[14:50] <ogasawara> apw: ^^ I assume that's due to the new restrictions in our repo?
[14:53] <apw> ogasawara, yeah, hmmm, thats neither a signed tag, nor is updating them allowed ... hmmm ... push it as a branch for now perhaps
[14:53] <ogasawara> apw: ack
[14:54] <apw> we can likely just add an exception for that tag namespace
[14:56] <apw> :q
[14:57]  * apw punches unity in the face repeatedly ... _do_not_paste_my_output_in_the_wrong_window_that_might_be_my_password_
[14:58] <_ruben> :q is your password? good to know :)
[14:58] <ogasawara> heh
[14:58] <apw> heh luckily not, but it might be safest if it was
[14:58] <_ruben> ;)
[14:58] <apw> "smb, what time is it there?" would make a good password
[15:09] <hallyn> hm, laptop isn't even that hot, but just shut itself down...
[15:09] <hallyn> nothing in syslog
[15:18] <apw> hallyn, how quickly
[15:19] <apw> and its not suspended is it?
[15:19] <hallyn> no, it just acted as though i'd hit the power button
[15:19] <apw> we seem to have a new suspend on idle on AC
[15:19] <hallyn> it also wasn't idle, i was in the middle of typing :)
[15:19] <apw> so ... like you pressed it (full shutdown messages) or like you held it
[15:19] <hallyn> like i held it
[15:19] <hallyn> no shutdown msg
[15:20] <hallyn> nothing in syslog at all for several mins before booting up
[15:20] <apw> hallyn, running what release, which kernel
[15:20] <hallyn> oneiric, uptodate
[15:20] <apw> not see that, no
[15:20] <hallyn> thermal0/temp is showing 84000 - whatever that means
[15:20] <apw> could be anything, likely as not 84c
[15:21] <apw> but hte units are not easy to determine at times
[15:21] <hallyn> I've had this happen once or twice before, but when it was much hotter, and I do believe that file was around  100 when i rebooted
[15:21] <apw> 105 is a common 'i am turning of NOW' value
[15:21] <hallyn> i think i once deduced it actually did correspond to degrees celsius, don't recall how/why
[15:21] <apw> indeed they are often listed in /proc/<somewhere>
[15:22] <apw> cking, where is the thermal trip stuff hidden in proc ?
[15:22] <cking> apw - i'm on a call at the mo
[15:22] <hallyn> serge@sergelap:/sys/devices/virtual/thermal/thermal_zone0$ cat trip_point_0_temp 
[15:22] <hallyn> 98000
[15:22] <apw> ahh there you go then, but if you are at 84c that in of itself is worrying
[15:22] <apw> are you fanning?
[15:22] <hallyn> I'm down to 70 now
[15:23] <hallyn> yeah, fan is always goin gon this thing
[15:23] <apw> thinkpad ?
[15:23] <hallyn> vaio f11
[15:23] <apw> what is your machine doing that 70c is a sane temp ?
[15:23] <hallyn> I had shut down u1 some time before, so i was just doing a libvirt build, running kvm, and playing a song...
[15:23] <apw> it'd want to be compileing on something
[15:24] <apw> so you are kicking the crap out of it, so perhaps 70 is expectable
[15:24] <hallyn> well, it's an 8-core 8G laptop, I don't take it easy on it
[15:24] <hallyn> no serioualy this thing easily hits 90
[15:24] <hallyn> but i dont' think it had hit 98
[15:24] <apw> that sounds like pretty poor thermal control.  an 8 core thingy in a laptop, mental
[15:24] <hallyn> all right, i guess i'll keep a little display up with the temp values
[15:24] <apw> yeah good plan try and keep some history
[15:25] <hallyn> heh, i had to quickly choose something when i joined canonical.  i'd have preferred a good desktop and a netbook.  but this thing mostly serves me well
[15:25] <hallyn> all right, i'll ping back if it does it again without hitting 98
[15:25] <hallyn> thanks
[15:29] <apw> hallyn, made the same mistake myself
[15:30] <hallyn> I guess in about 1.5 years I'll start looking for a kick-ass desktop :)
[16:10] <hallyn> (this is one of those times i'm happy to be using wmii so i can just change my status shellscript :)
[16:10] <hallyn> hanging steady at 67 right now
[16:28] <tgardner> apw, dpkg-buildpackage is just a script. AFAICT it simply adds -jX to MAKEFLAGS before running debian/rules. 
[16:28] <apw> hmmmm
[16:28] <tgardner> I haven't quite been able to simulate it by hand yet
[16:50] <tgardner> ppisati, do you want the ti-omap4 kernels uplaoded with the DMA/SMP performance fix ?
[16:53] <tgardner> apw, ogasawara: pushed 'UBUNTU: [Config] Fix binary-% build target' to oneiric master-next
[16:53] <ogasawara> tgardner: ack
[16:54] <apw> tgardner, nice
[16:54] <tgardner> I'll figure out the AMKEFLAGS business and build it into debian/rules somehow
[16:54] <tgardner> MAKEFLAGS*
[17:12] <hallyn> apw: say do you know of a way to set the trip_point? file isn't writeable...  and a simple sbuild of libvirt-bin quickly brought temps to 92 (trip point being 98)
[17:13] <apw> hallyn, normally they are bios set and bios enforced, they are exposed to allow the OS to help in heat managment i expect
[17:13] <tgardner> hallyn, trip points are typically the domain of BIOS/SMI AFAIK
[17:13] <hallyn> drat
[17:13] <apw> i really don't think you should be hitting anywhere near it if the bios was managing fans correctly
[17:13] <hallyn> at least 94 seems to be another, 'passive' trip point.  I guess I should go read up.  must be some discussion online
[17:13] <apw> it must burn your hands if you go anywhere near the case
[17:14] <hallyn> it gets warm, but not that bad.  
[17:14] <hallyn> maybe one of those fancy powered laptop stands would help :)
[17:15] <apw> i am suspicious that there are a number of bioss out there which do not handle the fans, but they ship windows drivers to override the fans to make things work
[17:15] <hallyn> oh!  actually, i guess sony had a bios update about this.
[17:15] <hallyn> but the damned thing isn't usable in linux or even in windows 2008
[17:16] <hallyn> now, this time after it hit 94 it started going down.  so maybe the 'passive' trip poitn didn't trip last time, and so it kept climbing?
[17:17] <hallyn> maybe i should drop by the sony store
[17:18] <tgardner> hallyn, maybe you should be using tangerine
[17:18] <hallyn> tgardner: i was just compiling libvirt...
[17:19] <hallyn> that would feel like abusing resources
[17:19] <tgardner> hallyn, well, it beats having your laptop sizzle
[17:19] <hallyn> true
[17:19] <bjf> hallyn, i use http://pastebin.ubuntu.com/689370/ to jam the fans on for my thinkpad, don't know what you'd need to change for it to work for you
[17:20] <hallyn> bjf: yeah, i might have to bypass the kernel's trip point and have my own little daemon bump up the fan.  good idea.
[17:20] <tgardner> its gotta have support in the platform driver
[17:23] <hallyn> yeah and i don't see a fan control under /sys/module/sony_laptop
[17:36]  * tgardner --> lunch
[17:55] <apw> bjf, did you get the magic for bootchart ?  as i have just seen one with the lines which was generated this week
[17:55] <bjf> apw, yes been working on it all a.m. :-)
[17:59] <apw> bjf, can you make sure you also turn on initcall_debug on the test boots and grab the dmesg as well
[18:00] <bjf> apw, ack
[18:04] <jjohansen> rebooting
[18:06] <htorque> ogasawara: hi! bug 834725 → looks like this is not a bug in linux after all, right?
[18:06] <ubot2`> Launchpad bug 834725 in linux "Powertop fails to report number of wakeups/events" [Undecided,Confirmed] https://launchpad.net/bugs/834725
[18:06] <ogasawara> htorque: was just about to comment there.  indeed, I do not believe this to be a kernel issue.  so I was going to close out the linux task.
[18:07] <htorque> good, thanks :)
[18:37]  * jjohansen -> lunch
[19:25] <smoser> smb, do you happen to be around ?
[19:25] <smoser> http://groups.google.com/group/ec2ubuntu/browse_frm/thread/57ff20c6370f7bb9
[19:26] <smoser> we should have someone look at that.
[20:30]  * ogasawara bails a little early for an appointment, back on later.
[21:26] <jj-afk> back on later
[22:54] <openfly> well that sucks