=== jjohansen is now known as jj-afk === bjf is now known as bjf[afk] === bjf is now known as bjf[afk] === BenC___ is now known as BenC [04:36] bjf[afk]: around? [04:36] yup [04:36] I have a ppa abi question [04:37] ok [04:37] I have a ppa that is failing on the abi check [04:37] however it worked the first build and I haven't bumped abi since [04:38] wow, that's weird [04:38] yeah, I am sure I have done something wrong but, the whole abi bump, upload part is uhmm poorly documented [04:39] do you have some docs you follow when working through the bump? [04:40] I noticed certain steps in the maintanence guide don't seem to work anymore [04:40] trying to find my notes [04:42] mostly we use the maint-starnewrelease script, it advances the build number however i'm not sure how it knows to bump the abi [04:42] it doesn't [04:42] one thing you can do is "git mv

" [04:43] won't that cause a failure if the abi has change though [04:44] let me send you my notes and see if they make any sense to you, they don't to me right now [04:44] okay, and I will give moving the abi file a try [04:46] i've only had to go through this once [04:46] email sent [04:46] ah, okay. I've only bumbled through it on my ppa once and fluked out on getting it to work, and now it won't :) [04:46] thanks [04:47] now that my notes don't make sense to me i'm going to have to go through them again tomorrow and fix them up === amitk-afk is now known as amitk === amitk is now known as amitk-afk [11:59] apw, ouch ... [11:59] apw, we have another package description pointing wrongly to versatile ... [12:01] apw, omap4 meta seems to still have it === amitk-afk is now known as amitk === ivoks-afk is now known as ivoks [15:07] apw: who can tell me about binary demotions of kernel packages? see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt [15:07] or ogasawara ? ^^^ [15:08] smb: do you know if all of the releases of 2.6.36 have the security fix with arch_compat_alloc_user_space? [15:10] tseliot, Some of the early -rc's may not but the change is in upstream now [15:11] tseliot, commit was between -rc4 and -rc5 [15:12] smb: ok, as I'm facing a weird issue with fglrx (from maverick) and (mainline) 2.6.36 where the workaround doesn't work (i.e. the compilation flag seems to be ignored. Therefore I was wondering if I should just replace compat_alloc_user_space with arch_compat_alloc_user_space when dealing with 2.6.36 kernels (I can do this with DKMS) [15:13] smb: make.sh.log: http://pastebin.ubuntu.com/499734/ [15:15] tseliot, That seems to use a slightly different approach. Is the code in fglrx expecting COMPAT_ALLOC_USER_SPACE being a macro? [15:18] smb: make.sh sets COMPAT_ALLOC_USER_SPACE to either of the compat_alloc_ functions and then passes it as a flag (MODFLAGS). Then the C file calls COMPAT_ALLOC_USER_SPACE(size) [15:18] tseliot, I would be a bit careful with the wholesale replacement. You never know against which 2.6.36 you may be compiling against and -rc4 and earlier are different. [15:18] yes, that's why I asked [15:19] The error sounds like something generally goes wrong with the definition [15:19] and COMPAT_ALLOC_USER_SPACE is not replaced at all [15:20] smb: make.sh http://pastebin.ubuntu.com/499736/ [15:21] * tseliot nods [15:22] smb: the weird thing is that the same fix works with 2.6.35 [15:23] tseliot, This is quite odd. I'd probably try to modify the Makefile in the subdir to pass V=1, to see what gets passed in [15:24] ok, thanks [15:24] It feels like the flag might not get repeatedly get set in there [15:33] smb: I definitely don't see it there: http://pastebin.ubuntu.com/499750/ [15:35] No if it had been correctly passed on it would be somewhere around PAGE_ATTR_FIX [15:35] Have you checked the module Makefile? At least thea PAGE_ATTR_FIX was set again there for the kernel compile [15:38] smb: wait a second, PAGE_ATTR_FIX is being passed while COMPAT_ALLOC_USER_SPACE is not: http://pastebin.ubuntu.com/499752/ [15:38] but why does this work with 2.6.35??? [15:39] tseliot, i bet if you add something there it works. I am as puzzled as you may be. [15:39] It should not work there either [15:39] smb: yes, that's what I'm trying now [15:44] doko: I'll send email to the team asking about the binary demotions of kernel packages. most of the guys are in taipei at the moment. [15:44] ogasawara: thanks! [15:50] smb: something's definitely wrong. I doesn't fail now but COMPAT_ALLOC_USER_SPACE is set to nothing http://pastebin.ubuntu.com/499762/ [15:51] smb: and I added a -DCOMPAT_ALLOC_USER_SPACE=$(COMPAT_ALLOC_USER_SPACE) in the makefile [15:51] O_o [15:52] I am not sure, but make.sh currently adds it to MODULE_FLAGS which I am not sure about how this gets passed on [15:53] I think in the code i saw it was passed on differently [15:54] yes, I really should ask AMD how they pass MODULE_FLAGS === ivoks is now known as ivoks-afk [15:55] tseliot, Maybe its something that used to be in older kernels... let me check something [15:56] oh [15:56] that would explain it [16:01] tseliot, Seems AMD got hit by progress again "kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line" in 2.6.36-rc1 replaced MODFLAGS with something new [16:02] "Note2: MODFLAGS was not documented and is dropped [16:02] without any notice. I do not expect much/any breakage [16:02] from this." [16:02] smb: d'oh [16:03] smb: do you have a link to the commit? [16:04] tseliot, 6588169d516560f68672e2928680b71c647b7806 (a second I try to give you a link) [16:05] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6588169d516560f68672e2928680b71c647b7806 [16:05] thanks [16:06] I guess a new workaround will be required for 2.6.36. The one we adopted in lucid and in other releases should work [16:08] Yeah, generally EXTRA_CFLAGS is probably longer supported. Even if not as specific as CFLAGS_MODULE now. But its an out of tree module anyway [16:13] smb: ok, so I guess that any other flag that relied on MODFLAGS will have to be passed in a different way (not only the one we need) [16:13] right [16:13] #freeipmi [16:19] smb: thanks for your help [16:19] tseliot, np. At least the riddle is solved and we can sleep over the weekend. :) [16:20] smb: hehe [16:31] smb: replacing MODFLAGS with CFLAGS_MODULE did it. Now I can sleep at night :D [16:31] :D === ivoks-afk is now known as ivoks [17:01] ogasawara: mumble ? [17:02] mpoirier: sure, just a sec [17:16] Once an LTS is released, will changes by made to the kernel that would require me to recompile drivers ( modules ) that were compiled against an earlier kernel in the same LTS version ? [17:19] david506, yes, there can be changes that require to re-compile (everytime the abi number changes) === jj-afk is now known as jjohansen [17:20] Why would the ABI number change ? [17:21] ok, so if the ABI number changes, can I recompile that same source with no modifications ? [17:21] jjohansen: just curious if you have the AppArmor patches pushed to a branch that I can look at. I just need to write up a proposal for the 0-day kernel upload and wanted to get the specific details for your patches. [17:22] ogasawara: not pushed to a branch but I can send you them [17:22] both are 1 line [17:22] only one is needed 0 day [17:22] jjohansen: ok cool, just send me the one we need for 0 day [17:22] okay [17:23] david506, because some functions or structure have changed. Usually yes. There can be rare changes that make the compile fail. But this should be really rare. The only reason it happened now once was for non-gpl modules [17:23] jjohansen: you can even just pastebin it if you want [17:24] david506, So I would rather say, there should be no need to change the source of the module in 99.9% of the cases [17:25] but a severe security issue might warrant that .1% ? [17:25] FWIW this was david506 original question in #ubuntu 18:11 < david506> I have a hardware provider who might agree to run a repository for their specialized software or have their software included in the LTS versions, but I need to know what changes normally happen in the kernel in LTS versions. [17:25] david506: hope you do not mind [17:25] david506, correct [17:26] :) [17:26] I was trying to make the question more clear :d [17:26] If you could give me links to any relevant web pages to my questions, I would be most happy to read them [17:30] I would not know of a page where this written down in detail. Not that you probably could. It also depends on what you modules rely on. If it is only using more general kernel interfaces change will less likely happen than if someone tries to hook to a very specific module === bjf[afk] is now known as bjf [17:33] jjohansen, when you have some time, i have a question (no hurry) [17:34] bjf: shoot [17:35] jjohansen, i'm rebasing Lucid ec2 and ran into a conflict [17:36] bjf: big surprise [17:36] jjohansen, actually, it went pretty smooth, just a couple of minor conflicts and only one that i have a question about [17:37] okay [17:38] jjohansen, sorry wife interrupt [17:39] np [17:40] I have server team interrupts [17:41] jjohansen, can you look at the diff of kernel/irq/manage.c between the master branch and the ec2 branch? [17:41] jjohansen, to resolve the conflict, i went with the ec2 version [17:41] bjf sure where is it [17:42] jjohansen, my public ubuntu-lucid has it [17:42] jjohansen, actually, let me just pastebin it [17:43] jjohansen, http://pastebin.ubuntu.com/499829/ [17:44] jjohansen, i went with this patch [17:46] bjf what did the upstream patch look like [17:46] * jjohansen is stunned the conflict was this small [17:49] bjf: so I redid the abi check following your guide, it worked fine when I built on tangerine but failed again when I pushed to the ppa [17:49] ogasawara: how much do you know of kernel ppa builds, and abi checks? [17:50] jjohansen: I know a bit about the abi checks, the kernel ppa builds though might suffer from bug 645653 [17:50] Launchpad bug 645653 in linux (Ubuntu) "kernel is unbuildably large (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/645653 [17:51] hrmm, I suspect it is different as the abi check comes after the build and the failure log clearly shows its failing in the abi check [17:51] jjohansen: have a pointer to the build log [17:51] ? [17:51] this is on a lucid kernel btw [17:52] http://launchpadlibrarian.net/56380500/buildlog_ubuntu-lucid-amd64.linux_2.6.32-27.47~debugmpath_FAILEDTOBUILD.txt.gz [17:57] jjohansen: this looks a little weird... you're buildling version 2.6.32-27.47~debugmpath but it's looking for ABI 2.6.32-26.45? I'd think it'd look for 2.6.32-26.46 [17:57] jjohansen: does debian.master/abi/2.6.32-26.45/amd64/server actually exist in your tree? [17:58] jjohansen: and did it get committed? [17:58] ogasawara: no, it got moved to 2.6.32-27.47 [18:00] ogasawara: basically I skipped up a couple abi drivers for testing the mptsas and skipped .26 entirely [18:00] jjohansen: ah, so you really need the previous ABI directory to exist for the current build to check against [18:00] -26 ... -27 how far in the future is htis? [18:01] smb: its not, its something that will die [18:01] smb: its for testing only [18:01] jjohansen: but you mentioned it built ok on tangerine? [18:01] jjohansen: which is odd [18:01] yes, that is what puzzels me [18:01] jjohansen, Not sure you are aware but as long as you would make your tree so the previous version remains what it was you only need to bump the abi once [18:02] smb: right, I recognize that it only needs to be bumped once [18:02] jjohansen, Did you clean completely between the builds? [18:02] jjohansen: mind if I look at your tree on tangerine? [18:02] on tangerine [18:03] but I noticed a stable update bump the abi during testing and figured I would get ahead of that one a wee bit [18:03] ogasawara: hrmm, you could but its changed since then [18:04] basically, it worked and I pushed and moved on to the next thing I wanted to test [18:04] smb: I did an fdr clean [18:04] I followed the abi doc as close as I could [18:04] I had a couple of odd things happen like [18:04] jjohansen, So if you look at you tree and do a fdr printenv, it would tell you what it considers as the previous release. Then the tree needs an abi dir for that [18:05] fakeroot debian/rules insertchanges doesn't insert changes for me [18:05] Hm, an fdr clean would remove any generated abi i believe [18:06] jjohansen: ah, so on tangerine ubuntu-lucid/debian.master/abi/2.6.32-26.45 exists (but is not committed) [18:06] smb: okay, so that may be it, if it is looking for a previous abi and I skipped 2 would it be smart enough to figure that out [18:06] insertchanges relies on the previous version being commited with a message that is formatted "UBUNTU: Ubuntu-..." [18:06] jjohansen: explains why it passes on tangerine [18:06] ogasawara: really? weird okay that explains it then [18:07] alright I take another stab at this. /me wonders why that one exists [18:07] jjohansen: well according to git status it's not committed in that tree on tangerine [18:07] jjohansen, It gets created on compile. Though I had been thinking clean would remove it [18:07] jjohansen: not sure if you used that tree or another to build the package to upload [18:07] but maybe that is not ture [18:07] ogasawara: yeah no, it wouldn't be. I git am'd the patches from my local tree [18:09] so, it doesn't exist locally, on tangerine I built the latest pull, then branched to an earlier state and applied my patches as I didn't want any extra changes in while testing. [18:09] * jjohansen doesn't get why an fdr clean didn't clean up abi cruft is all [18:09] thanks guys, at least it makes sense now [18:10] jjohansen: yah, I usually just to a git clean -f -d since fdr clean doesn't remove everything (and actually generates some files) [18:10] yeah [18:11] or even git clean -d -f -x [18:13] smb: heh, I like that you pass your flags alphabetically [18:13] ogasawara, And I did not even try to. :) [18:14] haha [18:15] Well, before I order all letters I type alphabetically... Its Friday and past 7pm, I think I be gone [18:19] smb: yes, it's well past beer:30 for you [18:21] smb, which patches did you want on ti-omap? [18:29] so, kamal taught something great yesterday - meld understands git repos. If you didn't know this, check it out. "meld ./" works in a git repo and shows your changed files. [18:33] sweet [19:19] what is meld? [19:19] sweet GUI diff utility... apt-get install meld (you'll like it :-) [19:20] achiang, it's like taking a flame-thrower to your code :-) === bjf is now known as bjf[afk] [19:21] kamal: are you saying that the output of diff -Nurp is insufficient? ;) [19:21] j/k, the tool looks pretty cool [19:23] achiang: far be it from me to ever cast aspersions upon the glory of diff -- just another tool^Wflamethrower for the toolbox :-) [19:24] fwiw, when i need to see visual differences, i use gvimdiff [19:24] but maybe i'll try meld next time [20:10] * ogasawara lunch [21:16] * jjohansen lunch [22:03] hi [22:04] I'm building a custom kernel with patches to support pv-hvm for better performance under XenClient. how do I go about creating a new flavour like there is the -pae one currently? [22:04] I followed the instructions on https://help.ubuntu.com/community/Kernel/Compile for how to get the sources and patched them from there [22:10] sorry after reading http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/ I'm unstuck.. === MTeck is now known as MTecknology === yofel_ is now known as yofel === ivoks is now known as ivoks-afk