[05:32] will the vanilla kernel build configs get synced/fixed? [11:15] jjohansen: Have you seen: pastebin.ubuntu.com/255032 ? [11:49] smb, i see that 27.31 just dropped reverting something... might want to check we didn't slurp it up someewhere [12:09] seems like a nice reference to git: http://progit.org/book/ === seann_ is now known as Jseann === Jseann is now known as JSeann [12:54] apw, Thanks, seems we are safe. Did not find the original patch in our trees. [12:54] smb, phew ... [12:56] ogra: should the bootloader be set to "flash-kernel" for dove as well? [12:56] ... to facilitate updates? [12:56] amitk, depends on the design NCommander develops [12:56] which he didnt document *anywhere* [12:56] (grmbl) [12:57] ogra: I assume it should be for imx51 atleast? [12:57] yes, for imx51 we use flash-kernel for updates (not as the bootloader indeed) [12:58] bootloader == redboot, flash-kernel is the upgrade tool for kernel and initramfs in flash [12:58] (where flash might be mtd or SD here ) [12:58] ogra: ok, I've pushed that fix to the FSL branch (rtg, FYI). Will await your instructions for dove. [12:58] dove uses uboot as bootloader, i'm not sure how NCommander planned to implement it [12:59] amitk, did you change to uImage as the target (I haven't looked at all my email yet) [12:59] https://blueprints.launchpad.net/ubuntu/+spec/mobile-karmic-marvell-desktop is the dove spec [13:00] rtg: not yet. It requires adding the uboot-tools dependency. I'd much prefer NCommander to finish his design before making those changes. [13:00] right [13:01] nobody apart from him even remotely knows how the images will look like [13:01] amitk, I think all it requires from the kernel side is uboot-mkimage. [13:01] i asked him to document it already but seems he didnt yet, https://wiki.ubuntu.com/Specs/KarmicMarvellDesktop looks quite empty [13:01] right, for uImage you need a dep on uboot-mkimage [13:02] rtg: uuh, right. uboot-mkimage, not uboot-tools [13:02] and indeed make the build process call "make uImage" instead of zImage [13:02] i think thats a clear fact that we'll need it [13:02] marvell wont switch to another bootloader [13:02] true [13:03] i dont know how the whole rest of the bootprocess will look like though [13:03] theoretically we shouldnt need flash-kernel given that uboot should be able to read the kernel and initramfs binaries from disk [13:05] ogra, will you ever need udebs for Dove? I've disabled all but the nic-modules [13:05] we might at some point, not urgent now though [13:05] but i think your naming of the headers wil cause probs [13:05] http://paste.ubuntu.com/255034/ is a snippet from the livefs builder script [13:06] can you shuffle the name a bit for them ? [13:06] ogra, much like linux-image-* ? I suppose. [13:06] yeah [13:07] well, it even looks for linux-image-2* and linux-headers-2* [13:07] * apw waves to rtg. i see you pulled in some of the abstraction stuff into the arm branches [13:08] apw, its where I actually developed the proof of concept. master came last [13:08] ahh makes more sense when you think about it that way [13:09] * rhkfin_ wonders if #403656 aka CVE-2009-2692 (incorrect proto_ops initializations) will get a fix soon... (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/413656) [13:09] Malone bug 413656 in linux "Local root exploit via CVE-2009-2692 (incorrect proto_ops initializations)" [Unknown,Confirmed] [13:10] * Nakkel wonders if anyone notices rhkfin_'s wondrings about #403656 aka CVE-2009-2692 (incorrect proto_ops initializations) [13:11] luckily that doesnt affct 9.04 at least [13:11] really? [13:11] why? [13:12] but #ubuntu-security would be the better place to ask about 8.10 and 8.04 [13:12] because the 9.04 kernel sets vm.mmap_min_address to 65535 via sysctl, the issue only shows up if thats not the case [13:12] well, actually if its set to 0 [13:13] but its definately a question for #ubuntu-security more than here [13:13] cat /proc/sys/vm/mmap_min_addr [13:13] 0 [13:13] Reaaallly safe [13:13] *definitely [13:13] well, thats not the default [13:13] If you've got wine or dosemu installed you'll have it at that address [13:14] * rhkfin_ has 0 there too.. [13:14] right wine wipes that setting [13:14] * rhkfin_ thinks it makes it an issue for 9.04 too... [13:16] but doesnt make it more on topic here :) [13:16] -> #ubuntu-security... [13:16] right :) [13:17] apw, if you're OK with the abstracted-debian branch, then I'm just gonna do it for master, then make all of the topic branches work right with rebase. [13:20] rtg am happy with it, i already implemented it for head on my abstracted-debian branch [13:21] that contains the runes to allow it be reconstructed on any master [13:21] apw, I'd just planned on cherry-picking and squashing those 4 commits. [13:21] it might be worth squashing 2-4 and leaving 1 as a separate entiry [13:21] entity as that better lets someone implement the same on older trees [13:22] which we are going to do (smb^^) [13:22] as the first is a 'programatic step' and 2-4 is just the delta [13:22] ie can be cherry-picked back to older debian's [13:22] but yes squash 2-4 for sure [13:22] apw, why don't you go ahead and push those changes the way you'd like to see them [13:23] rtg, Was your comment about the branches or the security issue? [13:24] smb, about master as well as the topic branches. [13:26] rtg, I have not followed to be honest. I know you had done some things to the karmic arm branches to make rebasing a simple rebase. But I had no time to look at what you actually did [13:26] smb, so now that yingying has slapped you around, are you gonna backport the igb driver? [13:27] rtg i am guessing we could do the equivalent on just the branches on jaunty... ie make i safer by not modifying the master branch [13:27] rtg, If that is completely new, why not. They could use a few new numbers to be a bit more diverse [13:27] as the conversion there is the programatic step and then the patch on top [13:27] that can just as well be in the branch [13:29] apw, why wouldn't we do Jaunty master? The rebase issues there are at least as problematic as they are for Karmic, what with the netbook and arm branches [13:29] hi all [13:30] rtg we can, from a risk point of view we could choose to leave master alone but do the same trick inside the branch [13:30] it depends how risk averse we are feeling [13:30] apw, these are build issues. I consider that to be pretty low risk, if not zero. [13:31] fair enough [13:31] apw, Likely most of it is in the buildenv, so at least it would be failing early [13:31] yeah likely so, fair enough, i am convinced [13:34] rtg shall i prepare a jaunty master delta to see how it looks? [13:34] apw, sure [13:34] i am assuming you are handling karmic en-toto as its complex with the branches there [13:34] then i can see how easy my jaunty netbook branch rebases too [13:35] apw, nope, just [ush the master branch changes and I'll fix the topic branches after the fact. [13:35] ok i'll squash 2-4 and push that [13:58] rtg: fsl-imx51 doesn't need uboot (ATM) [13:59] only mvl-dove needs it for now [13:59] also, fsl-imx51 will still use zImage, while mvl-dove will use uImage [14:07] amitk, oops, wrong flavour. [14:07] as long as yu dont switch -generic to uboot :) [14:08] i suspect even grub2 wouldnt handle that :) [14:16] amitk, I just slammed HEAD on the fsl-imx51 branch to drop the build-dep patch [14:17] rtg: ack [15:10] Hi! Two questions: 1. Are the kernels at http://kernel.ubuntu.com/~kernel-ppa/mainline/ built from http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=summary [15:11] 2. With the latest 2.6.31 kernels my DVB-T receiver stopped working. It seems that the modules are not built anymore. Is that known? [15:15] rtg, ping? [15:16] apw, I though we were gonna squash the karmic master branch 'ARM: IMX51:' patches out of existence? [15:16] NCommander, yo [15:17] rtg, I just wanted to compare notes w.r.t. to the dove kernel on the generation of the output files (I heard that the kernel packages are getting twisted to build uImages now) [15:17] NCommander, if that is what you want, then now is the time to make the change to uImage [15:18] Well, I did a writeup of what I'm sorta hoping to get w.r.t. to filesystem layout in the Marvell spec (it was living on the internal wiki until earlier today: https://wiki.ubuntu.com/Specs/KarmicMarvellDesktop) [15:18] NCommander, I'll have a look. I'm in the middle of reorganizing the dove branch, so it'll be a bit. [15:19] rtg, I'd appeicate your input in it [15:19] oh right [15:20] using uImage saves extra hacks and the dove cant use a zImage anyway [15:21] ogra, right, and then we can just update any boot script (if we use one, which I'm in favor of) as part of the postinst after the updated ramdisk is generated [15:21] beyond that marvell will take care of the load adresses change in the kernel tree and you dont need to make the up yourself [15:21] s/of/if/ [15:21] s/the/them/ [15:21] ogra, load address changes? [15:21] for mkimage you need load adresses [15:21] Right [15:22] Oh, Marvell gave us a set of addresses to use for uImage/uRamdisk? [15:22] the kernel tree has some for uImage [15:22] mkimage wont run without proper load address [15:22] to create a uImage mkimage is run [15:23] I was using the addresses from the sheevaplug, but I much rather use a more sancationed address :-) [15:23] ^- ogra [15:23] right, make uImage will set the ones definaed by marvell [15:23] \o/ [15:23] *defined [15:23] Yay for making life easier [15:23] thats how make uImage works [15:24] Ah, I didn't know there was a pre-existing target in the Marvell kernel tree to spit out a uImage [15:25] so the only change you will need will be to initramfs-tools [15:25] if you even need a uInitramfs [15:30] NCommander: the 'make uImage' target isn't just in the Marvell kernel tree. Upstream kernels also support it IIRC [15:31] rtg, we were and erm did [15:31] * apw looks whats occured [15:31] apw, they appear to be back in the repo [15:31] yes they do [15:32] amitk, that's good to know [15:32] * apw must have the original branch here somewhere [15:36] ogra: what command are you running? [15:37] i run fakeroot debian/rules binary, kill that if i see it starting to build (assuming it configured) and then run make uImage [15:37] apw, I'm wondering if I didn't do it because of the way I rebase against origin/master. [15:37] * ogra knows thats wrog but seemed the fastesr [15:37] *fastest [15:37] rtg as in you think you might have undone it? [15:38] ogra: use fakeroot debian/rules prepare-dove [15:38] apw, right. after you pushed I likely did 'git fetch origin;git rebase origin master'. Since I still had those commits in my master branch, then I probably pushed 'em back out. [15:38] hmm perhap :/ [15:38] ogra@dove:~/kernel/mvl-dove$ fakeroot debian/rules prepare-dove [15:38] make: *** No rule to make target `prepare-dove'. Stop. [15:39] ogra: the prepare target will create the debian/build dire [15:39] hrm [15:39] are you on the dove branch? [15:39] well i can get rid of them again in short order [15:39] i thought so [15:39] * ogra curses git once again [15:39] apw, I've already done that. [15:39] I'll just re-push, OK ? [15:39] rtg ok then [15:39] ogra@dove:~/kernel/mvl-dove$ git branch [15:39] * master [15:39] absolutly [15:39] meh [15:40] ogra, building that way in the dove/mvl branch isn't working [15:40] how do i have to build it then ? [15:40] rtg do the dove and imx51 branches have my patch to allow all targets trhough? [15:40] right, git fetch only gets me [15:40] + ba9ee58...a5dde05 fsl-imx51 -> origin/fsl-imx51 (forced update) [15:40] + b5c2598...a436a05 master -> origin/master (forced update) [15:41] ogra, you need to:debuild --no-lintian -eCROSS_COMPILE=arm-none-linux-gnueabi- --prepend-path=/home/toolchains/arm-2009q1/bin -b -aarmel -us -uc [15:41] apw, not yet. I'm in the middle of it. [15:41] bjf, no [15:41] ahh so prepare-dove won't work [15:41] ogra, no? [15:41] you would need to do fakeroot debian.mvl-dove/rules prepare-dove to get it to work [15:41] bjf, a) i dont crossbuild, b) i dont want to use debuild, amitk wants the binary from make uImage [15:41] that will be fixed shortly [15:42] apw, master HEAD pushed. I suggest you make sure your update doesn't recreate those damn IMX51 patches. [15:42] heh yep am updating now to make sure it doesn't [15:42] ogra: make ARCH=arm CROSS_COMPILE=arm-linux- O=`pwd`/../build/ [15:43] ogra: you'll need to create a ../build and copy the .config there first, though [15:43] fakeroot debian.mvl-dove/rules prepare-dove [15:43] amitk, dove won't build out of tree yet [15:43] somthing like that ought to get it prepared in theory [15:43] it did so last week [15:43] ohh right, drop the O= [15:43] the kernel i currently run is built from your mvl-dove tree [15:44] ogra, yeah but someone keeps wanting machinary changes, and they have risk of breakage [15:44] :) [15:44] * ogra hugs apw [15:44] that seems to work :) [15:44] ogra, that should get fixes shortly when we rebase those trees onto the new abstracted stuff [15:44] sure, i only care about an uImage to give feedback to amitk [15:45] * ogra doesnt want to touch the packaging :) [15:45] rtg on this abstracted form for jaunty... it occurs to me we are also going to want the stuff to allow us to change the source package name and the like [15:45] apw, correct [15:45] and so i am thinking that actually i should really be looking to take the karmic machinary [15:45] and all the nice fixes therein [15:45] * amitk steps out for a bit [15:45] apw, agreed [15:45] good. thats much easier (i hope) [15:46] ogra, are you talking mvl or fsl? [15:46] mvl [15:46] apw, my goal is to have the packaging for all branches in all repos look mostly the same. [15:46] yeah so thats also the right thing that way [15:46] bjf, amitk wants to know if the resulting uImage from make uImage works fine so we can enable it in the package [15:47] amitk: no I haven't seen pastebin.ubuntu.com/255032, where did you hit it [15:47] instead of running make zImage [15:47] apw, hmm, still fails with "make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop." [15:48] ogra,ok [15:48] * ogra just ran make oldconfig now ... seems to work [15:49] though it used my existing /boot/config-2.6.31-0-dove apparently [16:04] jjohansen1: just saw it randomly on my laptop (rebooted since and not seen) [16:05] bjf: make uImage is a supported target in the kernel. If that works already, then we don't have to do postinst munging of zImage to uImage. Therefore, I asked someone who had the HW to test if the resulting kernel is bootable. [16:06] I recall that sometimes the kernels aren't bootable (wrong addresses, perhaps) [16:06] amitk, well, it definately worked on friday i'm currently running that uImage on my dove [16:06] amitk: hrmm okay that is a strange failure [16:06] i just dont have the latest merges [16:07] but i doubt they change anything wrt mkimage [16:07] amitk, I had been building that way before this last week and I was giving the mobile guys my uImage to test with [16:07] ogra: but you did a manual mkimage then, right? [16:07] amitk, that had/has been working [16:07] amitk, no [16:07] amitk, oh, sorry, i did [16:08] i used debuild and used the vmlinuz from that package [16:08] amitk, the issue right now is that the work that rtg and apw have been doing has "changed" things a bit [16:09] bjf: ok, great. Then we should change rule.d/vars.armel in the mvl branch (build_image = uImage, kernel_file= arch/$(build_arch)/boot/uImage, etc.) [16:09] amitk, yes [16:10] amitk, don't forget the prerm, postinstall, etc scripts [16:10] ack [16:10] rtg: does this new debian.* world order mean that all the debian.* directories are in the master branch? [16:11] amitk, yeah, have a look at Karmic master. There is now a debian.master [16:11] the only thing under the debian directory is rules. [16:12] s/thing/file/ [16:12] and some other invariant stuff [16:12] doesn't debuild complain (about the relatively empty debian/ dir)? [16:13] amitk, run 'fakeroot debian/rules clean' first [16:15] rtg: I see it now. But can't _all_ the debian.* directories now live in the master branch? That way all the topic branches only muck with code. [16:15] amitk, the debian.branch is still only in the branch currently [16:15] if you do that, to change something which needs to add code and modify configs say [16:15] you would have to commit half to master, the other half to branch and then rebase the branch to get the whole [16:16] or somthing nasty like that [16:16] amitk, I found that the packaging rules vary enough across topic branches that it was simpler to just separate them out. [16:16] ok === bjf is now known as bjf-afk === bjf-afk is now known as bjf [16:57] ** [16:57] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [16:57] ** [17:07] I have a question regarding suspend problems in 2.6.31-6-generic not present in v2.6.31-rc6 [17:08] rydberg, rfkill related? [17:10] Hello Tim, long time no see. I cannot say, sorry - was just wondering if these problems seem common, and thus whether I should simply wait with whistle-blowing until after karmic catches up with rc6. I guess from your answer that it is common indeed. [17:11] rydberg, we did note some suspend issues with bluetooth. try 'sudo rfkill block all' prior to suspending. [17:11] if you indeed have bluetooth. [17:12] amitk, http://paste.ubuntu.com/255224/ ... lets see if it boots now :) [17:12] i usuall keep it off, but i will have a look anyways, thanks for the tip [17:24] rtg, no dice using 'rfkill block all'. What does work so far is a pristine rc6, without ramdisk. [17:31] rydberg1, what is your platform? [17:33] its a macbook air 1,1 running karmic alpha 4 plus updates. I just noted there were updates in the karmic kernel today, I will try building those and report back [17:33] rydberg1, its just packaging changes. I doubt it'll have any effect [17:34] oh, ok [17:34] you have ath5k wireless? [17:35] the bcm4328, which works with the bcmwl dkms package [17:35] rydberg1, try 'sudo modprobe -r wl' before suspending. [17:35] oki [17:35] apw, FYI, I pushed all repos [17:36] ack, thanks [17:36] nope, still hangs with blinking cursor on suspend [17:37] you might want to boot with no_console_suspend, and then perform the suspend from VT-1 using sudo pm-suspend [17:37] rydberg1, do you still have older Ubuntu kernels installed, like 2.6.31-5.24 ? [17:38] thanks apw, ive been doing all those things, there is a distinct difference in behavior between ubuntu-2.6.31-6 and v2.6.31-rc6 [17:39] trying the 2.6.31-5 now [17:44] same thing there, not suspending but hanging. i am happy to wait with further testing until a rc6 rebase, i am hopeful it will work [17:45] 2.6.31-6 is an -rc6 rebase? [17:45] i thought it was rc5? [17:46] nope its definatly an -rc6 rebase [17:47] i just read the git tree, couldnt find the rebase point but that changes things drastically. Ok, ill dig a bit more [17:48] the -rc6 kernel you are testing, is that our mainline build? [17:48] its staight off linus' tree [17:48] apw, the reading back he tested 2.6.31-5 not 2.6.31-6 [17:48] $ git show `git merge-base linus/master Ubuntu-2.6.31-6.25` [17:48] commit 64f1607ffbbc772685733ea63e6f7f4183df1b16 [17:48] Author: Linus Torvalds [17:48] Date: Thu Aug 13 15:43:34 2009 -0700 [17:48] Linux 2.6.31-rc6 [17:49] rydberg1, can we confirm which ones of ours you have tested? [17:50] i have tested the two packages 2.6.31-6-generic and 2.6.31-5-generic [17:50] and i have tested the -rc6 from linus, without ramdisk [17:50] the two former hangs on suspend, the latter works flawlessly, both suspend and resume [17:50] that implies the bug is in our delta, so you could consider doing a bisect between -rc6 and Ubuntu-2.6.31-6.25 [17:51] yep [17:53] "day" means US day time, I suppose? this will take a couple of hours :-) [17:59] day ? [17:59] as in bug day - im in europe === lieb_ is now known as lieb [18:00] bug days in ubuntu usually span across all timezones [18:01] long working hours, then :-) [18:01] starting at NZ moring and ending in pacific evening [18:02] well, the ubuntu developer and bugtriager teams span across the whole world ;) [18:02] (as well as the users reporting bugs :) ) [18:03] ogasawara: thanks for subscribing yourself to the bug :) [18:03] rtg, apw: ill start off verifying the problem between 64f1607ffbbc772685733ea63e6f7f4183df1b16 and the karmic head, just to make sure its not my kernel config that makes it work [18:03] sensible idea [18:28] tlsup seems to have a problem compiling here, same for you? [18:29] dhillon-v10: hi! thanks for sitting in on the meeting [18:29] ogasawara: Hi how are you [18:30] dhillon-v10: great, so you mentioned you'd be interested in helping out [18:30] ogasawara: yes how can I get started [18:30] dhillon-v10: one of the biggest problems we face as a team is dealing with a large volume of bugs coming in [18:31] dhillon-v10: I think dealing with some of these bugs would be a great starting point [18:31] ogasawara: yah I read that in the wiki, I am actually working with Ubuntu-doc team in the wikis and such [18:32] dhillon-v10: awesome. we can also always use help cleaning up or documentation on the wikis also [18:32] ogasawara: :) [18:32] dhillon-v10: as it happens, today we're holding a kernel bug day [18:33] ogasawara: I am subscribed to the mailing list and I get a lot of bugs in my mail but I can't solve any of them can you help me with that [18:33] ogasawara: most of them are sound related, I mostly work in computer vision [18:33] dhillon-v10: sure, do you have a list of them you can point me to [18:34] ogasawara: please elaborate yourself, I don't get it [18:35] dhillon-v10: you mentioned you have some sound related bugs which you'd like to try to work on, I'm wondering if you have specific bug #'s we can work through [18:35] ogasawara: oh sure just one sec. [18:36] ogasawara: how about this one: Bug 414977 [18:36] Malone bug 414977 in pulseaudio "in karmic, any application being started mutes the volume" [Undecided,Fix committed] https://launchpad.net/bugs/414977 [18:37] dhillon-v10: hrm, that's reported against pulseaudio (ie not the kernel) but it seems Daniel's commited a fix? [18:38] dhillon-v10: I do know that the upgrade to pulseaudio 0.9.16 cause some regressions [18:38] dhillon-v10: which I believe they are trying to resolve by uploading test packages to their PPA [18:40] ogasawara: sorry about that [18:41] * apw ^5's ogasawara [18:41] ogasawara, i've rearranged the regressions review to next monday, sorry we forgot yesterday even though you were ahead [18:41] ogasawara: my internet just got disconnected, I fixed that [18:41] and got it out on time [18:42] rtg, apw: 64f1607f: good (suspends, resumes) [18:42] apw: no worries, wasn't much to review this week anyways [18:42] rtg, apw: ad1dfe69: good (suspends, resumes) [18:42] rtg, apw: thus the problem lies somewhere in the configuration, not the tree itself (phew, saved me a couple of hours of bisecting :-)) [18:42] ogasawara: So what was that you were saying before my Internet got disconnected [18:43] ogasawara, we did meet this morning in and doa quick review [18:43] rydberg1, interesting, now to bisect the configuration delta [18:43] [10:37:40] dhillon-v10: hrm, that's reported against pulseaudio (ie not the kernel) but it seems Daniel's commited a fix? [18:43] [10:38:33] dhillon-v10: I do know that the upgrade to pulseaudio 0.9.16 cause some regressions [18:43] [10:38:49] dhillon-v10: which I believe they are trying to resolve by uploading test packages to their PPA [18:44] dhillon-v10: do you have another kernel bug we could look at? Or I can put together a list for us to work through. [18:44] ogasawara: I think you should put together a list, thanks [18:44] dhillon-v10: would you prefer to target sound related bugs? If not, I'll assemble a variety. [18:45] ogasawara: I doesn't really matter :) [18:46] dhillon-v10: ok, care to privately msg me your email address and I'll send you a good starter list with instructions [18:46] ogasawara: how do I do that [18:46] I'll message you [19:01] Whats the equivalent of kern.maxproc for Ubuntu? [19:02] in /etc/sysctl.conf? [19:04] Whats the equivalent of kern.maxproc for Ubuntu in /etc/sysctl.conf? I didn't see a default in there for it, but I think I need to set it higher than the default for the box. [19:40] ogasawara: is there anything I should do, now that we narrowed down the source of the regression and attached screenshots? [19:42] Q-FUNK: I pasted the bad commit we bisected to the upstream bug report so hopefully it'll get passed along [19:42] Q-FUNK: I noticed that in the thread on LKML you'd posted that another user mentioned they were not seeing issues . . . [19:43] Q-FUNK: looking at the config they posted it seems they have CONFIG_FS_POSIX_ACL list disabled so they won't be affected by that patch [19:43] ogasawara: I mentioned this earlier as well and attached that user's config to the LP bug. [19:43] Q-FUNK: since the bad patch is ifdef'd with CONFIG_FS_POSIX_ACL [19:43] indeed [19:43] Q-FUNK: you did? maybe I missed that [19:44] good point [19:44] I'll reply to him and point this out [19:47] Q-FUNK: if you like, I can build you a test kernel with that config disabled [19:48] Q-FUNK: else we can try to revert that commit, but I recall it didn't revert cleanly on the latest Karmic [19:48] ogasawara: sure, why not. against 2.6.31-rc6 ? [19:48] Q-FUNK: yup [19:48] ogasawara: sure, let's have a go at it [19:49] Q-FUNK: k, gimme a bit, I have to queue up another build first but you're next in the queue [19:49] ogasawara: ok, fair enough :) [19:53] rtg ok i've reconstructed abstracted debian against jaunty before smbs latest pushed its here: git://kernel.ubuntu.com/apw/ubuntu-jaunty abstracted-debian [19:53] will update it shortly to the latest tip# [19:55] smb, am i only expecting to find one new tag in jaunty? [19:55] apw, In theory there should be one new one, yes. Why? [19:56] i was expecting a tag for security and a new proposed one? [19:56] apw, Which proposed? :) [19:57] we have no -proposed to jaunty now then i guess? [19:57] apw, Right, the old one just was accepted and I had no time to create the new one [19:57] ok cool thanks, thought i was going mad for a sec there [19:58] apw, Relax, its just me being slow [19:58] heh no i think thats the definition of _me_ being slow :) [19:59] Heh, lets agree on that it is past beer o' clock for both of us. We are entitled to being slow. :) [19:59] yeah thats all very true, and worse my beer store is empty [19:59] i must go get some more asap [19:59] Not even cider? [19:59] nope ... not a drinkable thing other than ... water [20:00] eek. thats an emergency [20:01] bring some for the rest of us, too :-) [20:01] heh a plan indeed [20:03] We should pre-order for Portland. The bars tend to get out of stock if we arrive. :) [20:08] quite the contrary happened when Las Vegas hosted the yearly American Physical Society conference: they were kindly asked never to return :-) [20:09] apw, looks good. i assume you test built? [20:17] apw, you're gonna have to rebase your Jaunty abstracted-debian branch against Ubuntu-2.6.28-15.49 [20:19] rtg, apw: ad1dfe69 with config-2.6.31-6-generic: fail (hangs on suspend) [20:19] looking at suspicious modules now [20:20] rtg, apw I might make a new proposed tomorrowish. Maybe it is more worth the effort to rebase against that... [20:21] smb, lets get it tip of the tree soonish [20:22] rtg, I guess apw and me will sort things out tomorrow morning [20:23] bjf, amitk, git://kernel.ubuntu.com/rtg/ubuntu-karmic fsl-imx51 for a preview of the havoc I'm gonna wreak on your branch [20:29] rtg, debuild: fatal error at line 630: [20:29] cannot find readable debian/changelog anywhere! [20:29] Are you in the source code tree? [20:29] bjf, fdr clean first [20:30] rtg, ok, thats working, when we settle on this we'll need to do some wiki updating [20:30] bjf, right. my hope is to have all of the topic branches behave the same way. [20:37] rtg, I'm looking at that tree & branch, what should I notice? [20:37] bjf, just make sure I didn't lose any IMX51 patches. [20:38] rtg, that's kind of hard to tell, I'm not sure what amit commited [20:38] bjf, do you HW to run the kernel on? [20:39]