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