[00:24] <pgraner_> ogasawara: ping
[00:25] <ogasawara> pgraner: pong
[00:27] <pgraner_> ogasawara: can you add https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/272885 to the list?
[00:27] <ubot3> Malone bug 272885 in linux-meta "linux-image package must depend on package grub" [Undecided,New] 
[00:28] <pgraner_> ogasawara: I got bit buy this as well
[00:28] <ogasawara> pgraner_: yup, consider it added
[00:28] <pgraner_> ogasawara: great I'll see if rtg can fix it
=== pgraner_ is now known as pgraner
=== Nicke_ is now known as Nicke
=== thunderstruck is now known as gnomefreak
[13:51] <_ruben> what's the best way to get this (http://kerneltrap.org/mailarchive/linux-kernel/2008/10/16/3678594) included an upcoming kernel update (for atleast intrepid) ?
[13:56] <smb_tp> _ruben, If there is no bug for that issue, open one and add pointers to the upstream fixes. Then ping us/me here with the bug number.
[13:58] <rtg> ivoks: I got a response from Ted. Any more details on your ext4 problem?
[13:59] <ivoks> i didn't report it yet
[13:59] <_ruben> smb_tp: ok
[13:59] <rtg> ivoks: if you want it fixed, then you gotta describe it.
[13:59] <ivoks> hehe i know
[13:59] <ivoks> i didn't have time
[14:01] <_ruben> smb_tp: so far the only reference to this fix is the above mentioned url .. havent found any traces of an actual commit thusfar
[14:04] <smb_tp> _ruben, Which make things normally harder since stable updates in general should come from upstream repos. The patch itself looks safe. I think I saw you comment somewhere thatyou tried this and it made a difference for you
[14:08] <_ruben> smb_tp: correct, its one in the it-works-for-me category
[14:09] <ivoks> rtg: bug 331558
[14:09] <ubot3> Malone bug 331558 in linux "Unabe to boot linux-image-2.6.28-7 or newer" [Undecided,New] https://launchpad.net/bugs/331558
[14:10] <_ruben> i could very well my lack of google-foo to find evidence of an upstream patch, as I'd be rather surprised if this hadn't gone upstream yet .. since a change in one part of the kernel broke another part
[14:10] <rtg> ivoks: thanks. I'll let Ted know.
[14:12] <_ruben> bugger .. 2.6.27.18 doesnt have the fix :/
[14:13] <smb_tp> _ruben, Better be in the fixes-it-for-me. The bug/request should clearly state how things are without and with. So this gives an argument why this makes sense. And maybe upstream has to be reminded somehow. Or it did not make sense to them. It isn't even in the latest git. Justchecking tip
[14:13] <smb_tp> No, neither
[14:14] <_ruben> ah .. was about to check 2.6.28.6
[14:19] <ivoks> rtg: great
[14:20] <smb_tp> _ruben, The problem is likely that in theory both forms should yield the same results. 
[14:23] <_ruben> smb_tp: hmm .. could be a problem scst itself then in some odd way .. a scst contributer claimed to have sent a patch upstream, which apparently never came through .. nor did a fix submerge within scst .. lets ask around for details
[15:05] <_ruben> linus prevented said patch from entering mainline without detailed explanation
[15:08] <smb_tp> _ruben, I would guess it was not enough reason. As said, regardless of the warning this should make no difference. And if so it has to be proved.
[15:49] <blizzle> I was recommended to try the latest 2.6.29.x kernel in jaunty last night, as I can't get any joy with the 2.6.28.x kernels on my system. Bug is the same as thins one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/314050
[15:49] <ubot3> Malone bug 314050 in linux "Jaunty doesn't boot on my DELL Latitude C810 with current kernel" [Undecided,Confirmed] 
[15:50] <blizzle> The 2.6.29.x kernel failed even to boot. I was recommended to report the issue here. 
[16:39] <rtg> smb_tp: it would seem that 2.6.27.19 will render ext4 no longer experimental.
[16:40] <smb_tp> rtg, I saw that big bunch of ext4 patches. I still have to look at them and then it depends when they are flushed. At least it won't cause regressions
[16:41] <rtg> smb_tp: its the same set I'm carrying in Jaunty. I puklked from Ted's tree a few weeks ago
[16:42] <smb_tp> I actually saw mails about this on both stable queues
[16:43] <rtg> yep - I'm going to revert a bunch of SAUCE patches in favour of the official stable commits.
[16:45] <smb_tp> Actually it could be a good indicator on how complete things are. If you pulled those from Ted's tree before, they should be at least near 1:1 wit what you have to revert
=== Mauro is now known as Mauro2
=== Mauro2 is now known as [Mauro]
[20:23] <maxb> On one of my machine's today's kernel update seems to have had an unacceptable impact on interactive performance.
[20:23] <maxb> I assume it's the cpufreq stuff
[20:24] <maxb> Rolling back to -7 ABI fixes things
[20:24] <maxb> I shall now check the -8.x ones
[20:33] <rtg> maxb: what are you doing that you would even notice interactive performance? Is it under load?
[20:34] <maxb> even not under load, I found that screen redrawing was affected enough to be quite awkward
[20:34] <maxb> It could take a full second just to redraw an xchat window after clicking a different channel tab
[20:34] <rtg> maxb: can you change the cpu governor and see an effect?
[20:35] <maxb> let me quickly get back into -8.24
[20:39] <maxb> "quickly"
[20:39] <maxb> it's fscking
[20:42] <blizzle> I raised the issue earlier, got zero response, so I'll try again. I'm not able to boot jaunty using any 2.6.28.x kernels here, the bug has been reported: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/314050 .. If I use the patched kernel I can boot, but get other issues.. anyone one if/when this bug is likely to be addressed?
[20:42] <ubot3> Malone bug 314050 in linux "Jaunty doesn't boot on my DELL Latitude C810 with current kernel" [Undecided,Confirmed] 
[20:42] <blizzle> s/one/know
[20:46] <maxb> The panel applet doesn't seem to be working
[20:46] <maxb> oh, I have an apport-crash of cpufreq-selector
[20:51] <blizzle> I should also mention that I've seen 2 machines unable to boot with the 2.6.28.x kernels (different hardware), and the 2.6.29.x latest kernel from the ppa failed to boot, also.
[20:52] <maxb> Can someone point me to the right place in /proc or /sys to change the governor manually?
[20:53] <rtg> maxb: /sys/devices/system/cpu/cpu0/cpufreq
[20:54] <rtg> actually, /sys/devices/system/cpu
[20:57] <maxb> right
[20:57] <maxb> that fixes it
[20:57] <maxb> My 3GHz processor was running at 375MHz, and was being excessively conservative about scaling up with 'ondemand'
[20:57] <rtg> maxb: changing the governor fixes it? What specifically did you do?
[20:58] <maxb> echo performance > thatsysfile
[20:58] <maxb> echo performance > ..../scaling_governor
[20:59] <rtg> maxb: would you open a bug report and add this detail? Keybuk and mjg59 will likely find it of interest.
[21:05] <soren> maxb: 375MHz? Seriously? I didn't think it could go lower than 600.
[21:31] <maxb> soren: that's what the panel applet claims....
[21:31] <maxb> seems rather excessive, especially for a desktop part
=== TheMuso_ is now known as TheMuso