=== bjf is now known as bjf[afk] === kentb is now known as kentb[out] [07:18] morning all [07:19] amitk: good morning [07:21] morning amitk [07:21] hi ikepanhc, jjohansen [07:21] jj never sleep... === ivoks_away is now known as ivoks [07:22] security people never can... [07:24] ikepanhc: I hope you meant vacation instead of vocation in your email. Vocation is just more work :) [07:25] eh..... [07:25] ahley [07:25] I must need more coffee [07:25] next time I will write "day off" [07:26] I sent two mail because after push the sent, I found my phone number is wrong... seems not only number is wrong [07:28] heh [08:37] morning all [08:38] Good morning. [08:38] good morning [08:41] Hm. Has the kms-disablement sauce for i8xx chips got lost somewhere in the Maverick changes? [08:43] Guess we would need to use the SOURCE for that. :-P [08:43] Perhaps I could phrase that in a slightly less passive way: Hm. The kms-disablement sauce appears to have got lost somewhere in the Maverick changes. Is this intentional? [08:45] I probably can find out who committed the change, but I would not remember (if I ever knew) why. === ivoks is now known as ivoks_away [09:01] RAOF, So those rather seem to have vanished in either a rebase or rework of the tree. I think the best option here is to ask ogasawara when she comes online. [09:01] Will do. Thanks. [10:23] smb: what do we need to do to kick the mainline builds? [10:24] jjohansen, We should not need to do anything. Do we miss one? [10:25] smb: hrmm, I'm not sure. I am trying to figure out what is meant by "due to the kernel-package in ubuntu being broken once again, I can't build myself" [10:25] https://bugzilla.kernel.org/show_bug.cgi?id=16711 [10:25] bugzilla.kernel.org bug 16711 in ext4 "Oops with 2.6.36-rc1" [High,New] [10:25] jjohansen, Need to look at the bug, maybe meaning the source package... [10:26] right maybe [10:27] jjohansen, Is he really comparing 2.6.35-rc2 with 2.6.36-rc1??? [10:27] smb: I believe so [10:28] he report 36 rc1 and rc2 fail [10:29] cannot see 36 rc2 from the upper level (if not hidden in the links) [10:29] smb: yeah mean neither I assum he did something manual for rc2 [10:30] * jjohansen questions the rc2 bit altogether [10:30] Well on the rc2 side of it is 35 not 36 [10:30] at least in the text [10:31] what he may mean is probably different [10:31] his last comment he mentions both rc1 and rc2 oopsing [10:31] first comment .35-rc2 works [10:31] ah I see in the jpeg [10:31] yeah [10:31] I'll get him to clarify what is broken with the ppa [10:32] better than wasting time guessing [10:32] I would not really be worried about a -rc1 oopsing, I rather be surprised it boots at all [10:32] I thought apw changed it to have patches [10:32] but let me check [10:33] jjohansen, mainline build -rc2 is actually there [10:33] smb: well I am not particularly worried, I pretty much ignore anything before -rc3 [10:33] ah cool, I haven't really poked [10:33] My first concern was potential AA bug [10:34] second was kernel packaging being broken in some way [10:34] I would much rather him do the bisecting on something broken than us :) [10:34] No I guess its "how can I compile the same" [10:34] It should be possible with git and the patches that now are added [10:34] Andy removed the source package as that was often useless [10:36] hrmm, /me is going to have to look into the packaging changes sometime [10:36] jjohansen, Basically from the BUILD.LOG you get the sha1 -> 76be97c1fc945db08aae1f1b746012662d643e97 [10:36] (which is Linus -rc2 commit in this case) [10:36] ah, sha1 for upstream kernel is good :) [10:36] Then there are now 5 patches to add debian packaging and configs and whatnot. [10:38] gah, /me needs to look into overheating I've had my laptop shutdown twice today because of it [10:38] and the one time I had the cpu locked to low 800 MHz [10:39] jjohansen, nast, you may be the hero of akgraner then. She got that too [10:39] heh, only if I figure it out [10:39] at least its easy to replicate [10:40] Do fans at least try to cope with it or do they remain on low speed? [10:40] just let the flash player run :( [10:40] it seems they are remaining low speed [10:40] at least the time that I had the cpus locked to their lowest freq [10:41] If the temp goes up I would expect them to go faster [10:41] yes, I would too [10:42] Can be fun to track that. I think there have been cases which were a sde effect of accessing the ec the wrong way [10:42] yeah, it can be bios (unchanged), ec, acpi, ... [10:43] every stupid machine is different [10:43] Yes, sadly [10:45] These are the frightening messages I get [10:45] Aug 25 18:49:20 ortho kernel: [ 5178.678361] Critical temperature reached (128 C [10:45] ), shutting down. [10:46] At least thermal shutdown happens at some time. Though 128 seems a tad too high [10:46] yeah, quite hot === yofel_ is now known as yofel === smb is now known as smb-afk === smb-afk is now known as smb [13:32] ls === diwic is now known as diwic_afk === kentb[out] is now known as kentb [14:23] I got a problem running kernel 2.6.35 in Ubuntu 10.04 [14:26] guest1 It might help to say what the problem is... [14:26] PS/2 Keyboard and PS/2 Mouse dont work with X window system after I boot with 2.6.35 (custom compiled). [14:27] Have you tried the backport 2.6.35 driver that is pre-compiled? In the kernel-ppa I believe [14:28] https://launchpad.net/~kernel-ppa/+archive/ppa has a linux-maverick [14:29] Actually I meant kernel when saying driver [14:30] No. Actually I have an AMD Athlon II 245 system. Ubuntu work just perfect with the default kernel i.e. 2.6.32-24-generic. I downloaded kernel 2.6.35 from kernel.org and recompiled. Everything works fine in text mode. After running X, KB and mouse wont work. [14:31] * smb wonders why someone would compile a kernel when the default system works [14:32] And using a custom compile you may end up with options set differently which mean probably some drivers not configured... [14:32] But I want to try Ubuntu with 2.6.35. Plz help. [14:32] See ppa [14:32] That is a 2.6.35 kernel === simar__mohaar is now known as simar [14:35] Ok. I will check that out. Thanks for the help. === ivoks_away is now known as ivoks === JFo is now known as JFo-swap === amitk is now known as amitk-afk === bjf[afk] is now known as bjf === diwic_afk is now known as diwic === sconklin-gone is now known as sconklin === kentb is now known as kentb_dell [15:46] tgardner, just got your email [15:47] tgardner, when is drop dead time for sending you different update [15:48] jcrigby, that really has more to do with the beta freeze rules from Linaro [15:48] ok [15:48] let me look and see if I can figure out what went wrong with the merge [15:49] I'll get back to you [15:49] jcrigby, ok [15:49] what is lirc btw? [15:50] jcrigby, infrared controller [15:50] ok, I saw some noise about that on kernel team list [16:14] RAOF: hi, just want to confirm with you the kms-disablement patches you're referring to are the following 6 patches - http://pastebin.ubuntu.com/484007/ [16:15] RAOF: as they do indeed appear to have been dropped from Maverick, now to investigate/remember why [16:57] tgardner, I just did a git diff of my head and don't see any missing debian stuff. http://pastebin.ubuntu.com/484025/ [16:58] tgardner, sorry diff of my HEAD and Ubuntu upstream [17:00] jcrigby, I have 2 trees; Linaro-2.6.35-1003.7 and Ubuntu-2.6.35-19.25 checked out into separate directories. diff those to see what you come up with. [17:03] ok, maybe I sent you a bad pull request the linaro version should be 1004.8 [17:05] jcrigby, or maybe I forgot to 'reset --hard FETCH_HEAD'. doh! [17:05] diffing again.... [17:05] I was wondering about that. How to format a pull request that is a complete rebase [17:09] jcrigby, ok, my bad. I totally screwed the pooch. its looks good to me. [17:10] tgardner, wonderful [17:10] tgardner, that is great news [17:10] and yes it did boot on beagle [17:11] tgardner, btw do you guys stop rebasing now [17:11] for maverick that is [17:12] jcrigby, thats a bit up to ogasawara, but usually we won't reorder anything after Beta that has a tag. [17:12] ok, just hoping to avoid another mega rebase for awhile:) [17:13] tgardner, jcrigby: I actually have taken the approach to still rebase onto any upstream 2.6.35.y stable release [17:13] thats, fine. It gets easier each time I do this [17:13] jcrigby, besides, rebases are good for the soul. it forces you to look at conflicts. [17:14] good point [17:15] I suppose I should try out git rerere so I can remember confict resolutions automatically [17:21] is there a way to look at the buildd queues, i'm curious to why it's taking so long before my source uploads are building [17:22] bjf, you're meaning the PPAs, right? [17:22] httos:launchpad.net/builders [17:22] errr [17:22] https://launchpad.net/builders [17:24] hmm, thats kind of a handy link [17:25] tgardner: yes, and smb, thanks for the link [17:25] welcome [17:38] smb, is there a link that shows the amd64 ppa job queu (so I can see exactly where I am in the queue right now)? [17:40] bjf, I don't know a good one, only the general build score, but that does not really mean much [17:40] smb, ack [17:40] maybe lamont knows some magic that apprentices can use [17:42] bjf: the ppa queue is not exposed in the api... /ubuntu/maverick/amd64/+builds (or maybe /u/a/m/+b) is the queue for a given distroarchseries [17:42] and laggy in a meeting [17:42] smb, jjohansen, lamont, elmo: fyi, I just unembargoed the fix for xen [17:43] jdstrand: woot. I'll kick them ppas shortly [17:43] jdstrand, Cool [17:44] smb: nice work. I know that was rather painful [17:44] smb: and thank you again :) [17:44] * lamont remembers to wait for the publisher run [17:45] jdstrand: thanks, and smb yes very nice work [17:45] Sort of a Murphy issue, anything that could be wrong was wrong. o_O [17:48] tgardner, About the packaging, maybe we should ask about that. Probably the replaces is not needed because the 35 package is not an upgrade path to the 34 package. But maybe I have not grasped the whole concept [17:49] smb AFAIK the conflicts forces you to remove the conflicting package _first_ before you are able to install the new package. thats the primary behavior I'm interested in. [17:51] Right and the Replaces causes the old one to get actually removed when you are updated via the meta files. I just want to prevent us showing the next package and being told of again [17:52] smb, I'm reading the Debian policy manual... [17:54] smb, but there is no meta file upgrade path. you'll have to explicitly change from compat-wireless-2.6.34 to compat-wireless-2.6.35 [17:55] smb, another issue with replaces is that it only replaces files, not packages. [17:55] right, that would be point to have that requirement only for compat-wireless-2.6.34 as that will upgrade [17:56] hm, I probably should read the manual myself [17:56] lag: I'm adding your SOB to the arm patches for 613855 [17:56] yes, so I think the current combination of conflicts and replaces is correct. [17:56] smb, http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces [17:56] ogasawara: That would be fine, thank you [17:57] So thats the 7.6.2 usage [17:59] I think so, though I don't really understand the mail-transport-agent example [18:00] Its a bit complicated because its for virtual packages [18:01] But I think it declares to provide bla and conflict and replaces it. So when you install this packages it would uninstall all other packages that provide bla [18:02] well, I think I want the behavior to be explicit. no automatic replacement, etc. you'll have to explicitly remove the conflict. [18:03] Most of the time yes, so the only time this should happen is when I have lbm-wireless-generic installed and the new meta package points to lbm-compat-wireless-... [18:04] smb, correct. [18:04] Which is what is done so you were right that only the conflicts is needed for the other package [18:04] I got it now as well [18:04] once we're on to the next ABI series, then this is no longer a problem [18:05] right, if people want to change, they should make that decision knowingly [18:06] And I think that would be all we were asked to. I would just take what you had pushed and make the adaption for the conflicts and buglink [18:07] don't I have a public buglink? or did I get the wrong one? [18:07] No I thought you said you forgot to add a buglink on the latest patch [18:07] I mean yes you have the public bug in the mail [18:07] I amended and re-pushed [18:07] ah ok [18:08] Then lets do lbm try 3 [18:18] can someone help me to understand kernel package names vs. the actual kernel binary? output from dpkg -l gives, e.g. linux-image-2.6.32-24-generic 2.6.32-24.41, [18:18] so from that, i understand that 24 is the ABI version and .41 is the build number [18:19] achiang, so far, so good. [18:19] my question is, in practice, do we ever increase the build number without also changing the ABI? [18:20] e.g., would we ever ship a 2.6.32-24.42 ? [18:20] achiang, no, though the build number is completely arbitrary, the ABI number is not. [18:20] oh, lemme back up a littlwe [18:20] But we increase the build number without abi bum [18:20] yeah, what smb said [18:21] In fact we know should have an 2.6.32-24.42 in proposed [18:21] bump* [18:21] yep [18:22] ok, i think i understand. all kernel updates that do *not* require an ABI bump will simply have an increased version number, which dpkg --compare-versions would understand to be greater, right? [18:22] and that's how apt would know to pull down and install the new, updated package? [18:22] achiang, correct [18:22] yep [18:23] achiang, and when the ABI bumps, then we update the meta package so that it references the _new_ package [18:23] is there any way to get the ubuntu version number out of vmlinuz? or is that only stored in the debian packaging? [18:23] The build/upload number _always_ increments, though not always by 1 [18:23] nod [18:23] You see it in uname -a [18:23] and in /proc/version_signature [18:24] smb: no, you only see the package name, not the version string [18:24] Linux maximegalon 2.6.32-25-generic #43 [18:24] maybe my terminology is messed up [18:24] oh! [18:24] duh [18:24] So this is 2.6.32-25.43 [18:25] darn, i can't pass an arbitrary kernel path to uname [18:26] err, why would you want to do that? [18:26] tgardner: smb: ok, thank you for the explanations, they make sense. [18:27] smb: i am doing some evil stuff for an OEM customer's customized system update tool. don't ask, it's horrible. [18:27] * smb puts his fingers into his ears [18:29] smb: well, conceptually, i want to know: "is this kernel newer than that kernel?" [18:29] * smb still cannot hear achiang [18:30] where "this kernel" might live somewhere in the filesystem (not /boot/) and "that kernel" is typically the one in /boot/ [18:30] But yeah, basically you can compare version numbers, newer always inclrements. With the + and ~ magic of course [18:31] but the version numbers don't really live anywhere, except in the debian packaging; or by combining some fields from uname [18:31] so 2.6.32-24.41~pre1 comes before 2.6.32-24.41 [18:32] Well that information is in the kernel image too. If you boot you see it. In dmesg [18:32] but certainly, if you saw /boot/vmlinuz-2.6.32-24-generic you could not figure out if it was newer or older than /my/special/path/vmlinuz-2.6.32-24-generic [18:33] not from that filenames alone [18:33] because the kernel in /my/special/path might have a greater version number, but it's not easy to figure out. unless maybe you use strings and grep [18:34] right strings and grep will work [18:34] is there a case to be made for incorporating the version number into the file name (instead of merely package name) for generic ubuntu? or is my use case truly unique? [18:35] obviously not for this cycle, but for future cycles [18:36] no, as the parts that are used now are used for modules dir and we certainly don't want separate directories for each upload [18:36] i guess basing the filename on package name makes life a little easier in the non-ABI change case [18:36] ah, that makes sense too, re: modules [18:38] I guess this is just a very special usecase, but I tried strings/grep and it looks quick and simple (as long as you are not truely evil and want to do the same for old releases like Hardy ;-)) [18:40] smb: actually, yes, i sadly do need a solution for hardy as well [18:41] * smb runs away [18:44] smb: hm, strings seems to work on a hardy kernel [18:44] strings vmlinuz-2.6.24-27-lpia | grep '2\.6\.'2.6.24-27-lpia (buildd@midyim) #1 SMP Thu Apr 8 18:04:46 UTC 2010 [18:44] oops, the output is garbled [18:44] there should be a newline after grep '2\.6\.' [18:47] no it does not. its aways #1 [18:48] urk [18:48] * achiang runs to wherever smb is running [18:51] * tgardner lunches === bjf is now known as bjf[afk] [19:50] * jjohansen -> lunch [20:08] tgardner: when beta freeze lifts next week, could I get you to help me upload pciutils (just need to update the pci.ids file). [20:08] tgardner: it's for bug 601079 [20:08] ogasawara: Bug 601079 on http://launchpad.net/bugs/601079 is private [20:09] ogasawara, funny you should mention taht. I uploaded pciutils about 20 minutes ago [20:09] heh awesome [20:09] tgardner: I'll just mark that fixed then [20:10] ogasawara, yep, I think thats a safe move [20:10] ogasawara, are you subscribed to maverick-changes@lists.ubuntu.com ? [20:11] tgardner: I'm not at the moment, but I'll subscribe now so I see the notices [20:12] its a good way to survey what kind of development activity is going on === bjf[afk] is now known as bjf [20:21] * ogasawara lunch === ivoks is now known as ivoks_away [20:56] Any plans to incorporate the kernel patch for the damn Toshiba Sattelite ACPI/DSDT bug causing us to be forced to turn of ACPI and then only run ONE cpu core? http://bugzilla.kernel.org/attachment.cgi?id=23958 [21:00] * DJAshnar hears crickets [21:00] * DJAshnar stomps on em [21:14] DJAshnar: it looks like that patch is already in maverick [21:14] DJAshnar: though not in the form of the link you gave [21:15] on my Sattelite c655d s5057, it hangs on ACPI on boot unless I use the older patched kernel [21:17] booting the generi kernel in maverick just leaves me a blank screen. I have a radeon 4250 chipset if that helps [21:17] DJAshnar: that's likely a different issue [21:18] DJAshnar: try rebooting, hold down the left shift key to get into grub and remove "quiet spash" from the boot command line [21:20] no joy [21:21] DJAshnar: well, do you now get debug output on your screen? [21:21] no [21:22] DJAshnar: were you able to get into grub and edit the kernel command line? [21:23] yup [21:25] DJAshnar: hm, weird. try repeating, and add "ignore_loglevel earlyprintk=vga" [21:25] so "quiet splash" should go away and the other two should be added [21:26] just a black screen... [21:30] DJAshnar: hm, maybe the earlyprintk argument was wrong. maybe just remove it completely, actually [21:30] but do keep ignore_loglevel [21:42] no luck [21:52] that seems rather bad, and i'm out of ideas, sorry [21:54] I love the daily upstream kernel debs. very handy! [21:55] how can I update the kernel daily? [21:55] kees, I've opened the natty repo, but I've not really advertized it yet [21:55] tgardner: oh! very cool. I guess I should start rebasing nx-emu and yama... [21:56] kees, I dropped the nx emulation patches for now. had some conflicts, so I need to get back to it [21:56] tgardner: okay, I'll go poke at it. [21:59] cannot reserve MMIO region... wth? [22:34] <\_^_\> bjf: We chatted recently about bug #616501 and you told me that this will be part of some review by kernel team. Do you know what came out of this review? [22:34] Launchpad bug 616501 in linux (Ubuntu) "Kernel > 2.6.32-20 doesn’t boot, /dev/disk/by-uuid/... not found (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/616501 [22:45] \_^_\: yes, i'm embarrassed to say it didn't happen, we will do it monday a.m. [22:45] \_^_\: it's on our list, we just need to talk about it [22:46] <\_^_\> bjf: OK, thanks a lot. :) [22:46] \_^_\: np === sconklin is now known as sconklin-gone === bjf is now known as bjf[afk] === JanC_ is now known as JanC