joshhuntsconklin: around?00:17
=== BruceMa is now known as BruceMa_afk
=== hughhalf is now known as hugh_afk
=== smb` is now known as smb
=== hugh_afk is now known as hughhalf
psinoI've tried building an ubuntu kernel with a local version string (both by configuring the local version in the kernel menu config (general -> local version) and by using dch, but both methods give me the following error: https://gist.github.com/nkvoll/46509fa1aaaeda5441ef09:03
psinoi've tried searching for a solution, but I've been unable to find a way to build a kernel with a custom name so that I can distinguish it from the default, official one09:04
psinoI've successfully built a kernel without modifying the name in any way (following https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel), but it makes my custom kernel a bit hard to differentiate from the official ones09:06
apwpsino, so you changed the flavour name ?09:12
apwand i would guess you didn't change the list of flavours?09:12
smbpsino, You probably just want to modify the version number in the debian.master/changelog09:12
psinofirst I tried only changing the local version during editconfigs, it failed, then I used "dch --local -mmu-patched" (which seems to ignore the -patched-part)09:13
apwpsino, what is the version number as shown in the top of debian.master/changelog09:13
psinolinux (3.8.0-17.27) raring; urgency=low09:14
apwdch doesn't really work with the kernel, cause debian/changelog is not the master09:14
smbSo  change that into 3.8.0-17.27+mmupatched09:14
apwpsino, using a - in that string is destined for failure09:14
psinook, do I need to do anything else other than change the first line in the changelog?09:15
apwpsino, to get a unique version, only to clean ... debian/rules clean09:16
smbas long as the change itself would not change the abi, but you will notice that09:17
psinoit probably doesn't, since I managed to build a working kernel (booted on two different instances) when I didn't change the version string09:19
ppisatilp 116803909:20
ubot2Launchpad bug 1168039 in linux (Ubuntu) "highbank: network corruption" [High,Confirmed] https://launchpad.net/bugs/116803909:20
apwppisati, i suspect you will have to build him some kernels with highbank config for that bisect to work09:26
ppisatiapw: yeah, already doing that :)09:26
ppisatiapw: we miss you in mumble09:27
smbmaybe he will be back on Monday ... maybe not09:27
ppisatiapw: do you think it would be possible to have mainline compiled for armhf from now on?09:41
apwppisati, it does already in fact, but ... remember only ones built in raring and in raring since you added highbank to the configs would be a highbank compatible09:42
apwppisati, mostly we are building it for 'does it build' testing than for anything else09:42
ppisatiapw: yeah, from now on i mean09:43
ppisatiapw: we could build mainline for armhf using 'multi_v7_defconfig'09:44
ppisatiapw: or do we use our conig actually? /me never checked...09:44
apwppisati, we use 'our' config modulo any changes since then where we take the default answers10:04
rtg_apw, how the N7 USB config stuff going ?12:54
rtg_how is*12:54
apwrtg_, going ok in one sense, i am struggling with some other changes i have made which have made the damn kernel tooo big13:02
apwrtg_, did you see: 14:02:33        apw | rtg_, going ok in one sense, i am struggling with some other changes i have made which have made the damn kernel tooo big  13:13
rtg_apw, nah, missed that. busy updating kernels etc13:14
apwrtg_, enabling the filesystms we want triggers the initramfs to bloat needlessly and it won't fix, anyhow working on it13:15
rtg_apw, given that the N7 isn't _really_ a general purpose platform, can we disable some of the cruft ?13:16
rtg_apw, ppisati says the N4 is working for him, so I'm gonna get it in the archive.13:17
apwrtg_, well the issue is that things which are modules get pulled in to initramfs, we need some way to say not to do that, i think we can say "just this list" and put nothing in it.  for now i have dropped out the fliesystems changes and moved on, and will come back to it13:17
apwrtg_, great, now i have a 'proceedure' for this i can do the same to n413:17
rtg_apw, cool13:17
ppisatirtg_: yep, n4 works here13:21
* ppisati is stuck with calxeda bugs else he would tackle the n[4|7] happily :(13:21
ppisatiftrace is broken on n413:21
rtg_ppisati, did you update the wiki on how to install the new kerenl ?13:22
ppisatithe n7 has the touchscrenn patch problem13:22
ppisatirtg_: i used that procedure13:22
ppisatirtg_: i installed the .deb package13:22
ppisatirtg_: then13:22
ppisatirtg_: aboot -u /dev/block/mmcblk0p6 -k /boot/vmlinuz-foobar13:22
rtg_I wonder if we could get ogra_ to update flash-kernel13:22
ogra_for what exactly ?13:24
rtg_ogra_, for the n413:24
ogra_get me the data :) 13:24
ogra_shouldnt be any prob to add it to all.db13:24
rtg_ogra_, how about if I send you a patch ? I've got an N4 to experiment with.13:25
ogra_you should be able to just copy the db entry of grouper and minimally modify it13:26
rtg_ogra_, ack13:26
=== rsalveti is now known as Rsalveti_
=== Rsalveti_ is now known as rsalveti
=== hggdh_ is now known as hggdh
bullgard4Where is the function of the kernel process [netns] described?15:32
joshhuntsconklin: i'm seeing differences b/t the diff you prepared and what's posted on the usn page.15:44
sconklinthe one I prepared, or the one rtg did?15:44
pmatulisis this wiki [1] official and accurate?15:44
pmatulis[1]: https://wiki.ubuntu.com/Kernel/LTSEnablementStack15:44
sconklinjoshhunt: ^^15:45
joshhuntsconklin: good question, let me see which one i grabbed.15:45
joshhuntsconklin: it's the one rtg provided the link for15:45
joshhuntsconklin: i thought they were the same file15:45
joshhuntsconklin: let me grab the one from your link and check15:46
sconklinno, I linked to the wrong one. I'll take a look15:46
sconklinno, Mine is from the wrong release, the latest one15:46
sconklinjoshhunt: ^^15:46
joshhuntsconklin: ok, thx. one diff i see is this: linux-3.2/arch/arm/mach-omap2/include/mach/omap4-common.h15:46
sconklinlet me prepare one for the correct release and compare it with the one rtg did15:47
sconklinit'll take me a bit15:47
joshhuntsconklin: that file exists in your patch, but not the kernel linked on the usn page15:47
joshhuntsconklin: sure, np15:47
joshhuntsconklin: let me know if you want a list of the diffs, if that will help pinpoint what went wrong, although it'd be good to verify the one on the usn page is correct also.15:48
sconklinjoshhunt: ack, thanks15:49
smbpmatulis, Looks to me like the correct one / official one15:50
pmatulissmb: thanks.  why does it mention only x86?16:01
smbogasawara, ^ 16:02
ogasawarapmatulis: because we only provide HWE kernels for x8616:04
ogasawarapmatulis: we don't provide backport HWE kernels for say our arm flavors16:04
pmatulisogasawara: ok, i was confused thinking x86 does not include amd6416:05
sconklinjoshhunt: can you point me to the exact usn page you're talking about? I want to make sure we're on the same page16:09
joshhuntsconklin: sure, https://launchpad.net/ubuntu/+source/linux/3.2.0-40.6416:10
sconklinThanks, now I'm sure I have the right tag16:11
smbhenrix, Hey just wanted to let you know that I have been running the master-next lucid in a xen pv and hvm guest. Ok, the hvm guest still has an eta of 80mins on the regression tests but in general I think we can say those xen ds  patch looks good16:32
henrixsmb: cool, thanks. i guess that if there was a prob with that backport it would crash ugly during boot :)16:33
smbhenrix, one would guess. Though it did not crash ugly on boot before either. :)16:34
henrixsmb: heh true :)16:34
henrixthanks for testing that16:34
smbno prob16:35
sconklinjoshhunt: ok, there was some confusion here. There are diffs that get generated as part of the packaging, which are diffs from the original tarball for for the series. We an reproduce these.16:44
sconklinBut the diffs on the page you linked are generated by launchpad as a consequence of the order in which packages are uploaded and copied to -proposed, and we cannot reproduce those16:44
sconklinwe'll try not to let this happen again16:46
joshhuntsconklin: i'm not sure what you mean exactly. do you know why the diff rtg provided did not match what's on launchpad?16:46
ppisatiok, friday evening here16:48
ppisatigym -> booze -> EOW16:48
sconklinjoshhunt: show me precisely which diff you mean by "what's on launchpad"16:48
joshhuntsconklin: if i take the diff rtg linked to and apply it to a vanilla kernel and then download https://launchpad.net/ubuntu/+archive/primary/+files/linux_3.2.0-40.64.tar.gz the contents do not match when I diff -Naur them16:49
sconklinjoshhunt: define "vanilla kernel" - do you mean the .orig tarball we use to package with? Because that's what those diffs are generated against16:51
joshhuntsconklin: so the only reason this concerns me is it raises a question to me as to which one is "correct"16:51
joshhuntsconklin: kernel.org tarball16:51
joshhuntsconklin: i make an assumption that is the same as your .orig tarball16:51
joshhuntsconklin: if you tell me what's on the launchpad page is correct, then i will just generate my own diff b/t 3.2.0 from kernel.org and linux_3.2.0-40.64.tar.gz and use that for this releaes16:52
sconklinjoshhunt: ok, now I get what you're asking, let me check on some things.16:54
sconklinjoshhunt: 1. Yes, our .orig is the same as upstream17:04
sconklin2. try the diff here and see if it looks better: http://people.canonical.com/~sconklin/17:04
joshhuntsconklin: so it seems it's the same as the one rtg gave me yesterday17:08
joshhuntsconklin: you can verify for yourself by downloading the file from https://launchpad.net/ubuntu/+archive/primary/+files/linux_3.2.0-40.64.tar.gz and diff'ing that with your patch + orig tarball17:09
sconklindoing that17:09
joshhuntsconklin: but i see things like linux-3.2/arch/arm/mach-omap2/include/mach/omap4-common.h is in your diff, but not in the 40.64 tarball17:09
joshhuntsconklin: hmm actually i think i worded that last statement incorrectly17:12
apwsconklin, when you make an orig + patch version you will have files which would have been 'deleted' still present in the combination ... because the +diff cannot represent the removal17:18
apwsconklin, so if that differs from one where you missed the orig, that is not unexpected.  you should compare to one before which has an orig17:18
sconklinapw: maybe that accounts for it17:18
joshhuntapw: just curious, why can't the diff represent the removal?17:22
joshhuntsconklin: to correct my prev statement, arch/arm/mach-omap2/include/mach/omap4-common.h is actually not in the linux_3.2.0-40.64.tar.gz tarball.17:30
joshhuntsconklin: apw seems to be onto something, when i go through the diff i believe the differences are only whole files which are not present in the linux_3.2.0-40.64.tar.gz17:30
kamaljoshhunt: I just came to the exact same conclusion -- its all just the deleted files which aren't represented in the diff17:31
sconklinjosh, our testing here (Kamal looked at this also) indicates that this is the case. All differences are attributable to deleted files17:31
sconklinthanks, apw17:32
kamalspecifically, that list of deleted files (not counting a bunch of .gitignore files) is http://paste.ubuntu.com/5702168/17:33
joshhuntkamal: yes that's the same list i get thanks.17:34
kamaljoshhunt: and just fyi, along the way I also verified that (a) our .orig tarball is identical to the upstream 3.2 tarball, and (b) the sconklin/rtg diff's are precisely what would have been produced, if that 40.64 package had been constructed with the .orig.17:36
joshhuntkamal: ok thanks. i appreciate all (sconklink, apw, kamal) of your help17:36
sconklinand in the process, uncovered an interesting side effect of our build process that resulted in my diff being different than rtg's17:37
joshhuntare these deleted files usually present in diff you normally post for USNs?17:38
joshhuntand i just didn't notice them17:38
rtg_ogasawara, you can update a blueprint, I got the N4 kernel uploaded this AM. working on getting flash-kernel functional.17:39
ogasawarartg_: nice!17:39
rtg_ogasawara, OMG! tl;dr - 'UBUNTU: SAUCE: cpuidle: Fix NULL pointer dereference when off-lining CPU's'  :)17:41
ogasawarartg_: way too long, just ack it17:42
rtg_ogasawara, done17:42
* rtg_ -> lunch17:42
* henrix -> EOD17:46
joshhuntsconklin: i'm just trying to make sure i understand what happened. how are you generating the diff you provided to me? git-diff?17:50
sconklinjoshhunt: I rewound the git repo to the tag we released from, then generated a source package with a diff against the .orig tarball (the way we normally package)17:51
sconklinso it was generated by producing a source package just like a release.17:51
sconklinjoshhunt: I can give you instructions for how to do the same thing17:51
sconklinif you want to verify it that far17:51
joshhuntsconklin: that would be cool, as i'm trying to convert us over to pulling this stuff from git anyway. i'd be interested in your process.17:52
sconklinjoshhunt: you know how to clone our repo already?17:52
joshhuntsconklin: yep17:53
sconklinso basically, find the rigth tag and reset to that. In this case it was: git reset --hard 985689a17:54
sconklinthen follow the directions here:17:54
sconklinwhich in this case was:17:54
sconklingit clean -dxf17:54
sconklinfakeroot debian/rules clean17:55
sconklindebuild -S -I -i -uc -us -sa -v3.2.0-39.6217:55
sconklinand if you have the .orig tarball in the directory above the repo, it should all work17:55
kamal sconklin, joshhunt: fyi, instead of the initial "git reset", it also works to just do:   git checkout Ubuntu-3.2.0-40-6417:55
joshhuntsconklin: thanks so much, i appreciate it.17:56
joshhuntkamal: thanks17:56
kamalnote also that the "-v" flag there is not relevant -- you'll get the same diff.tar.gz with or without it17:56
kamaljoshhunt: note also that the orig tarball in .. must be named "linux_3.2.0.orig.tar.gz" ... the debuild process won't find it if you leave named as kernel.org provides it.17:57
joshhuntkamal: ok thakns17:58
joshhuntwill this process generate a package or a diff?17:58
kamaljoshhunt: it will generate a "source package", which is comprised of a few files including the .diff.tar.gz17:59
joshhuntok so then if in this particular case if i were to apply the diff generated here to an orig tarball and diff that against the package which is created, we'd see the same thing with the deleted files not being in the diff. is that correct?17:59
joshhuntif so then i think i finally understand :)18:00
kamaljoshhunt: yes, that's exactly the procedure I did18:00
joshhuntkamal: awesome thanks so much for your help. i will leave you all alone now :D18:00
joshhuntsconklin: thanks again18:01
kamaljoshhunt: no worries -- its helping us refine our process too, and that's a good thing18:01
sconklinjoshhunt: np.18:03
ogasawarartg_: I assume I can ping rsalveti to try rolling the N4 kernel into the phablet image?  or would you prefer I wait till we sort the flash-kernel bits18:11
rtg_ogasawara, yeah, wait until I'm sure flash-kernel is correct. likely someimte next week when I sync up with ogra_.18:11
ogasawarartg_: ack18:11
ogra_well, we dont have the n7 kernel in use on the touch images either, rsalveti can surely start playing woth it and test etc18:13
ogra_flash-kernel will need adjustment for both 18:14
rtg_ogra_, Paolo has to figure out the touch pad issue first.18:14
ogra_ah, right, there was that18:14
rsalvetiogasawara: flash kernel will only be useful when we finish the container work anyway, so we can at least use the same git tree18:14
rsalvetiwhile we make the package available and tune flash-kernel for later18:14
rsalvetiogra_: waiting paolo ack on that as I don't have the hardware18:15
ogra_rsalveti, why would the container have anything to do with it ?18:15
rsalvetiI only got galaxy nexus, nexus 4 and 1018:15
rtg_rsalveti, I think I have it working on the N4 within the Ubuntu chroot.18:15
rsalvetiogra_: because then the entire kernel and boot image is maintained by the ubuntu side18:15
ogra_as long as we dont overwrite the initrd ... 18:15
rsalvetisure, we'd need some temporary hack to reuse whatever it's available at the bootimg18:15
ogra_right, but even in todays model we could updatte vmlinuz18:15
rsalvetiwhich doesn't make sense18:15
rsalvetiotherwise we'll replace the bootimg and the device will not boot18:16
ogra_thats what i mean. you dont replace bootimg 18:16
rsalvetiif we get ubuntu as the main host, it'll all just work once we finish the flash-kernel piece18:16
ogra_only vmlinuz18:16
rsalvetiright, which will not affect the device18:17
ogra_on /dev/block/mmcfoo ...18:17
rsalvetiboth kernel and initrd is part of the boot.img18:17
ogra_i know 18:17
rsalvetithere's no single partition for the kernel18:17
ogra_but initrd in android doesnt carry anything kernel relevant18:17
ogra_there is the bootimg partition18:18
ogra_which abootimg can directly operate on18:18
rsalvetiwe could extract, change and update, I'm just saying we don't need to do that now18:18
rsalvetias we'll change it soon anyway18:18
ogra_why ?18:18
rsalvetionce we start using our own initrd18:18
ogra_abootimg -u /dev/block/mmcfoo -k /boot/vmlinuz-xyz18:18
ogra_that works today18:19
ogra_no need to extract 18:19
rsalveticool, that makes it easier18:19
ogra_if we cant switch the container we can use that method18:19
ogra_(and probably without even involving f-k)18:20
rsalvetiwouldn't it be better to just use f-k and make f-k call abootimg?18:20
ogra_well ... abootimg has all checks we need ... and the kernel package knows which device we want to flash to 18:20
rsalvetiogra_: right18:21
ogra_i would just have the kernel package ship the proper postinsts18:21
rsalvetiogra_: how this is done with nexus 7 for desktop?18:21
ogra_and hooks for initrd ....18:21
ogra_f-k using the ac100 method18:21
ogra_we can indeed use that 18:21
ogra_but i find it less complex to have the kernel just ship the right thing in case we dont touch the initrd18:22
ogra_if we flip the containers f-k might be better thanks to its initrd hooks and triggers18:22
rtg_ogra_, rsalveti: so I should just quit messing with f-k and just build it into the kernel postinst ?18:22
ogra_not yet ... we need to know what container model we will use 18:23
ogra_i woudl prefer the direct methid if the images stay as is 18:23
ogra_but f-k in case we can move android into its own container 18:23
ogra_(since then we want initrd handling)18:23
rsalvetithen we might know better next week18:24
rtg_ogra_, well, I've gota functional Quantal version of f-k18:24
rsalvetionce mike finalizes his investigation18:24
ogra_time is getting short for uploads 18:24
ogra_i thinnk lfinal freeze is next thu (didnt check the schedule but it should be around next week)18:24
rsalvetiwell, we don't necessary need to worry with raring anyway18:25
ogra_and if we change f-k's android method that needs testting on ac100 and n7 desktop for verification18:25
ogra_true 18:25
rsalvetiyou'll be testing that for us anyway :P18:25
rsalvetidon't have n7 neither ac10018:26
ogra_expectations :)18:26
ogra_i dont even know if the archive kernel still works on the n7 18:26
ogra_i guess i should test on the weekend :)18:26
ogra_i fear paolo uses the android config 18:27
ogra_(though i think he said he tested it)18:27
janimortg_, hi is there a more or less comprehensive list of ubuntu kernel security CVEs so far in a single place19:10
rtg_janimo, you'd have to ask my security dude sconklin19:11
janimoubuntu-security-announce ml is what I see closest, but it is not kernel only19:11
janimortg_, sconklin I am interested in aproximately how many of the security issues are arch or driver dependent vs those that affect any kernel19:13
janimoto have an idea how vulnerable a random android or BSP based kernel for a single ARM SoC would be on average, knowing the kernel security fixes cover a much wider surface area than a single specialized kernel has built in19:14
rtg_janimo, I guess you could grep commit logs looking for CVE.19:14
janimortg_, yeah, that's why I asked for a preexisting list or even such a rough classification which may have already been done :)19:16
rtg_janimo, I am not aware of any such classification.19:17
janimoor a guesstimate of someone doing this on a daily basis who 19:17
bjfjanimo, you can also look at the changelog. cves are indicated19:17
janimobjf, right, I am aware of those too, but thanks :) . As you can see I am lazy and first look for anything that may be done already19:18
bjfjanimo, there is also http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html19:18
bjfjanimo, but that doesn't cover ones that have been closed out19:18
janimobjf, I guess the UBuntu kernel CVE is more or less the same as upstream kernels right?19:18
janimoCVE list that is19:19
bjfjanimo, i'd expect them to be very close if not the same19:19
janimohm, than this may be a good list19:20
janimoor something on that website anyway19:20
bjfjjohansen, may know of something19:20
janimoor this may be a cleaner list http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=3319:22
jjohansenhrmm, I have really dived into that kind of data yet, it would be a good idea to shift through the CVEs we have had in the past and see what it shows19:22
* janimo is relieved to see there have been 0 CSRF vulnerabilities in the Linux kernel19:22
jjohansenand yes our kernel CVEs are the same as upstream19:23
janimojjohansen, the cvedetails page seems really nice, but I do not see classification based on modules or other components. That may indeed need some extra greeping work, hopefully CVEs have the affected source file paths in a searchable location19:25
jjohansenjanimo: right I am not aware of anything breaking it down by module/driver/subsystem it would be interesting to see19:26
janimono idea if there's a CVE database in a machine-friendly format 19:26
jjohansenours isn't bad we process it with scripts, it does have some issues19:27
janimoa more or less fixed form is good too, right19:28
jjohansenI'm wondering how far bug our break-fix entries (git commits that caused the cve and ones that fixed it) go, I think its only a couple of years19:30
janimojjohansen, based on what you saw so far and with no such analysis being done, what would you estimate is the split between vulnerabilites that would affect almost every kernel and those that involve rarely used drivers or more obscure FSs or network fucntionality?19:30
janimojjohansen, I do not need too much history, just an idea of how much chance a given CVE has of affecting an ARM kernel built for a single SoC supporting only the drivers that areneeded on a single mobiel device19:31
janimoso likely no advanced network or server storage stuff, no huge x86 or supercomputer data buses, etc19:32
jjohansenhrmmm hard to say I would guess it tips to the obscure fs or network functionality, but I'm not sure how much 60/40, 70/30 ?19:32
janimojust a random Android kernel from a mobile phone19:32
janimofrom the few android kernels I saw, their updates seem to cover hw enablement issues and not really securitty updates19:32
janimoprobably becasue user-space also has less chances of doing dangerous stuff19:33
* ogasawara lunch19:39
* rtg_ -> EOW19:59
=== mehdi is now known as mmsabwat
=== hggdh_ is now known as hggdh
yigalTo use an old device with 12.10 I need to patch its kernel.  Where can I find an up-to-date accounting on how the Ubuntu kernel should be patched and then (re)built?  Secondly, I need instructions specifically on compiling its kernel on another platform, as my desktop is much faster.23:04
yigalI believe I need to for EZEX touchscreen23:04
yigalunless someone else knows evtouch or other will work with tweaks?23:05
bjfyigal, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel23:07
yigaland then he's out23:08
yigalIt's just been a couple years since compiling and new tools seem to come more frequently than that so 23:12
yigalSo I've tried through the source in a i386 chroot environment to compile but have had issues.  Owell it's always fun to do this type of stuff.23:18

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!