=== asac_ is now known as asac === cr3_ is now known as cr3 [06:46] morning all :) [09:04] * ara reboots [09:53] * ara takes a break [13:03] happy weekend everybody! [13:03] cheers! === bureflux is now known as afflux === jcastro_ is now known as jcastro === thekorn_ is now known as thekorn [15:58] cr3: sconklin posted a link to a test kernel for bug 293372 (dell optiplex 330 reboot issue) [15:58] cr3: care to test and confirm it fixes it [15:58] ogasawara: sure thing [15:59] cr3: thanks [16:14] ogasawara: the package seems to contain a menu.lst, install package maintainers or keep? [16:15] cr3: hrm, dunno. I guess keep? [16:16] cr3: which .deb was it? [16:16] cr3: I think you only need to install the linux-image-2.6.27-8-generic_2.6.27-8.17_i386.deb [16:25] ogasawara: that's the package I'm installing [16:26] ogasawara: I'll install the package maintainer's version so that I can claim it works [16:26] cr3: ok thanks [16:32] cr3: I'd never seen that pop up before, how odd. I selected to "show the differences between the versions", it just shows is adding the 2.6.27-8 kernel to menu.lst. so probably good you picked the maintainer's version. [16:32] ogasawara: the package worked, I updated the bug [16:33] cr3: sweet, thanks for testing. [16:33] Umm, is this /boot/grub/menu.lst? [16:33] persia: yep [16:33] ogasawara: probably just mispackaged, no biggie [16:33] That *really* shouldn't be shipped in a package. It's modified by running update-grub. [16:33] If the kernel package is shipping it, that's different, and should be stopped. [16:34] Does it show in dpkg --contents on the .deb ? [16:34] persia: I think it's a side effect of having a ucf managed menu.lst [16:34] persia: it's not in the package, dpkg --contents linux-image-2.6.27-8-generic_2.6.27-8.17_i386.deb | grep menu.lst returns nothing [16:35] cr3, OK. Ignore me then. [16:35] cr3: it is sconklin's first patch/SRU for the kernel-team and I'm not quite sure of the steps he used to create the package [16:36] james_w, That makes sense, but regardless of how it's managed, the bootloader update hook is the right way to update it most of the time, and shipping it in a package would be a much more significant change than might be sane for an SRU. [16:36] persia: I agree, but in this case the message that the package includes a new version is misleading, as it doesn't include it at all [16:37] james_w, Yep. It certainly confused me. On the other hand, that's probably a relatively minor update-grub bug. [16:37] I'm also a little curious how cr3's system was changed in a way that raised the flag, but that's probably just a documentation gap. [16:40] persia: it I happened just now on my system as well when I tried. I'd never seen it before. [16:40] persia: http://people.ubuntu.com/~sconklin/293372/ [16:44] ogasawara, Do you know if source packages for that are available anywhere? [16:45] persia: unfortunately I don't, but let me get sconklin to join here === erle64- is now known as erle- [16:45] * persia doesn't have an i386 system handy anyway, but would prefer to avoid asking users a misleading and probably incorrect question if possible. [16:46] hi sconklin [16:46] hi, what's up? [16:47] sconklin, We're just looking at http://people.ubuntu.com/~sconklin/293372/ and it seems to prompt for a change in menu.lst, which is unexpected. [16:47] I was curious if there was a source package available that produced those .debs for comparison with the current version in the repos. [16:49] Mind you, I don't understand why a change to the vesa drivers would affect menu.lst that way. Maybe it's because the version number isn't different? [16:49] persia: I only built the ones that are there, but I can build the source package. It's quite possible I did something wrong, as I'm new to the process. [16:49] How did you build binary packages without first building the source package? [16:50] Prompting for the same version case makes sense, so you have a recovery path, but I don't know whether that's the case. [16:52] maybe I'm not understanding. I just built binary-generic from the git checkout. [16:52] Oh, maybe I'm looking at the wrong thing then. [16:52] * persia compares against 2.6.7-7.16 [16:53] I checked out Ubuntu-2.6.27-8.17 [16:54] Right, which is why I'm comparing to 2.6.27-7-16 as opposed to 2.6.27-8.17 (repo version). It might be that the change isn't your latest change, but something else. [16:54] cr3, ogasawara Can you reproduce the menu.lst issue with the current version in -proposed? [16:55] persia: I'll test, just a sec [16:56] Looks to me like -8.17 (both sconklin's and -proposed) have some extra stuff that doesn't belong. [16:58] http://pastebin.com/f255fc809 is the output of debdiff between 7.16 and the 8.17 in -proposed. I think most of that belongs in linux-firmware, and the /boot stuff doesn't belong at all. [17:00] Hmm. Seems to contain a bunch of modules stuff as well. Explains why *-modules-2.6.27-8-* have such small filesizes from http://archive.ubuntu.com/ubuntu/pool/main/l/linux/ [17:01] persia: installed normally, not prompt [17:01] * persia is confused. [17:02] not as confused as me. [17:02] binary debdiffs tend to be opaque, but the only thing different between the 8.17 in the pool and sconklin's 8.17 appears to be the vesa drivers. [17:03] Whereas the difference between the contents of 7.16 and 8.17 are *huge* [17:04] oh, pgraner said something about a bunch of firmware being put in at some point, but I didn't follow all of it. That was a couple of weeks ago. He might have some insight. [17:04] And I don't understand why changes to the contents of the vesa drivers would trigger a menu.lst warning. [17:05] ogasawara, Just to double-check (although I'm confident the answer is "yes"), the same procedure was used for each upgrade, from the same base state, right? [17:05] persia: yes [17:06] james_w, Any other ideas? This sounds like more than a ucf issue. [17:06] ogasawara: have you manually modified your menu.lst? [17:07] james_w: just small tweaks like removing 'quiet' [17:07] I assume you did it the "correct" way? [17:08] james_w: what's the "correct" way? I just manually edited [17:09] ogasawara: did you change the "# defoptions=quiet splash" line? [17:10] (the correct way is to change that, and run `update-grub`) [17:10] james_w: ah, I didn't do that [17:10] cr3: hey, did you edit your menu.lst at all? [17:12] ogasawara, But when you upgraded to sconklin's kernel with your manually edited menu.lst you got the warning, and when you upgraded to the proposed kernel with your manually edited menu.lst you didn't get a warning? [17:12] persia: correct [17:14] See, that's the confusing part, which makes me suspect that either the manual edits aren't the culprit, or that something else odd is happening. [17:16] sconklin: when you built the kernel you used the magic kernel scripts right? eg CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic [17:17] hunh? [17:17] Shouldn't it just be "debuild -b"? [17:17] (or build a source package, and feed it to pbuilder or sbuild) [17:17] maybe not. I used: [17:17] fakeroot debian/rules binary-generic [17:18] persia: the kernel builds straight from the git repository [17:18] ogasawara, Not on the buildds it doesn't. [17:18] And testing anything built differently than it will be built on the buildds invites unexpected differences. [17:20] persia: right, which might explain this oddity [17:21] Yeah. That makes a lot more sense than the other stuff, and it could well not show in a binary debdiff. [17:26] if I need to do things differently, please explain it in small words :) [17:30] sconklin: for test kernels I usually just build it with the kernel scripts like you did but I've never ran into this prompt issue about changing grub's menu.lst [17:31] sconklin: let's maybe raise it next week in PDX [17:32] yes please. [17:36] sconklin, I'd recommend running `apt-get build-dep linux-image-2.6.27-8-generic` on your system once, and then running `debuild -b` from the source directory as a quick hack until then, but I don't tend to do much on the kernels, so this might not be the best advice. [17:42] persia: thanks, I'll ask some other kernel folks, too. I did what I found on the wiki, so perhaps that page needs some love. [17:43] biab, emergency delivery of socks to my son's school. [18:00] back [19:08] cr3, with Ubuntu 8.10, for all message I receive in XChat, it highlights as I have received private message, is this known issue ? I have upgraded from 8.04 to 8.10 [19:09] nagappan: sorry, I wouldn't know, I don't use XChat :) [19:16] cr3, ok [19:17] cr3, can you point some one, I want it to be fixed [19:17] nagappan, You'd do better to file a bug about it, no? [19:18] persia, sure [19:22] persia: nice going, you scared him away ;) [19:27] cr3, persia, removed existing XChat conf and restarting the XChat, fixed the issue for me, thanks :) [19:28] nagappan, Oh, so it's a config issue, rather than a source issue? That's excellent to hear. [19:28] persia, :)