| mssbrg | reposting in case no one saw this (ping apw): out of curiousity, if the idea for those mainline builds is to have a virgin upstream build, then what are the patches for? | 04:49 |
|---|---|---|
| mssbrg | also, are the patch files supposed to be applied to the tree from kernel.org or the Ubuntu tree? seems the first patch file is changing the debian.master directory which does not exist in the kernel.org tree | 05:19 |
| mssbrg | and if I'm indeed supposed to apply the patches to the ubuntu tree, for my case where I'm using the 3.17.8 ppa build, there is no v3.17.8 tag in the vivid tree to checkout to :/ | 05:23 |
| apw | infinity, a source package is bigger than the entire output we are making them for, and at least at the start we didn't have the space for that | 08:35 |
| apw | infinity, though yes, why that anchient poc | 08:35 |
| mjg59 | apw: Are you pointing people at an Ubuntu git mirror? | 08:36 |
| apw | mjg59, for the mainline builds, no, they are pure linus | 08:36 |
| apw | i guess i get to try and add some wording to every build, hmmm | 08:37 |
| mjg59 | apw: Hm. That's dubious. | 08:37 |
| mjg59 | Pointing to repositories outside your control isn't usually considered sufficient for GPLv2 | 08:37 |
| mjg59 | Just keeping a mirror of Linus on kernel.ubuntu.com/git should be fine, though | 08:38 |
| apw | mjg59, $DEITY i should just stop producing them | 08:38 |
| mjg59 | Heh | 08:38 |
| apw | mjg59, i'll look at sorting a mirror out, we may have one already | 08:38 |
| apw | and get some more docs in there | 08:39 |
| mjg59 | I mean, the alternative is for you to just fall back to written offer and provide source on request | 08:39 |
| mjg59 | And then manually put the packages together whenever someone asks for it :p | 08:39 |
| apw | mssbrg, the patches apply in theory at least to the virgin commit listed in the COMMIT file, from a linus clone | 08:39 |
| apw | that is how the binary builder which made the binaries, makes them | 08:40 |
| apw | bah some of these are so old they don't even have the commit file, thats ... annoying | 08:41 |
| apw | time for some heavy surgery me thinks | 08:42 |
| apw | mssbrg, you'd need to give me the exact version you are looking at to follow along | 08:43 |
| apw | mjg59, oh good we do have a virgin tree already, so i can just refer to that in a README perhaps | 08:46 |
| mjg59 | apw: Yeah, a pointer to that and a hash should be fine | 08:56 |
| apw | mjg59, i will make it so | 09:17 |
| === Odd_Blok1 is now known as Odd_Bloke | ||
| jhenke | hi folks, it seems today's kernel update introduced a regression for people using the 2015 Dell XPS: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1425445 | 09:31 |
| ubot5 | Launchpad bug 1425445 in linux (Ubuntu) "Regression: 3.16.0-31-generic breaks touchpad on Dell XPS13 (2015)" [Undecided,Confirmed] | 09:31 |
| smb | henrix, Sounds like ^this may require the patch that Seth posted recently for Vivid | 09:37 |
| smb | HID: i2c-hid: Limit reads to wMaxInputLength bytes for input events | 09:37 |
| apw | mjg59, how does http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0-rc1-vivid/README sound | 09:40 |
| mjg59 | apw: Looks good to me | 10:14 |
| apw | mjg59, great thanks, i've pushed that to them all, and will rebuild a few which are missing patches | 10:14 |
| henrix | smb: i'll have a look in a sec | 10:48 |
| smb | henrix, ok, thanks. I also sent some reply to our ml to make us not forget | 10:49 |
| henrix | smb: ack, thanks | 10:49 |
| mssbrg | apw: I'm looking at this version: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17.8-vivid/ | 14:38 |
| apw | mssbrg, ok there now is a README in there which should help you get the source you want | 14:42 |
| mssbrg | Thats so helpful, thanks apw! Part of my misunderstanding was that I didn't know that "virgin" referred to an actual tree in ubuntu's repos and not the one from kernel.org | 15:09 |
| apw | mssbrg, np, i've shoved those into all of the builds | 15:09 |
| Suudy | So, the latest Ubuntu ABI change for 14.04 moves from 3.13.0-45 to 3.13.0-46. Unfortunately, this change breaks my MVFS driver (for Clearcase). It looks like they have the 3.19 version of dcache.h sucked into a 3.13.0 kernel. I see the raw 3.13.0 version of dcache unchanged until 3.19, but certainly such a change to a key data structure (dentry) would trigger a much larger change. | 19:50 |
| Suudy | Is there a way to detect this sub-version (e.g. -46)? | 19:50 |
| infinity | bjf: ^ | 19:50 |
| bjf | apw, ^ we have a define for that don't we? ... /me goes looking for it | 19:53 |
| Suudy | I know the fix for the driver, I just need a way to tell the difference between 3.13.0-45 and 3.13.0-46 | 19:58 |
| infinity | So, this has an elegant(ish) autoconf solution to the problem: http://launchpadlibrarian.net/197087396/openafs_1.6.1-1%2Bubuntu0.4_1.6.1-1%2Bubuntu0.5.diff.gz | 20:00 |
| infinity | But yeah, if you're looking for a kernel version check, that's tougher, as it's all 3.13.11, with extraversion bumped. | 20:00 |
| infinity | (Thanks, Greg) | 20:00 |
| bjf | i'm sure we put something in for out of tree drivers detecting the abi ... i just can't find it ... still looking | 20:01 |
| infinity | You did. | 20:01 |
| infinity | I just forget where. :P | 20:01 |
| infinity | And if we backported it. | 20:01 |
| Suudy | Is that extraversion then Ubuntu specific? I suppose an ifdef check to see if that extraversion is there, then do further checks. | 20:02 |
| apw | bjf, we do indeed have an ABI specific define | 20:03 |
| apw | Suudy, bjf, UTS_UBUNTU_RELEASE_ABI | 20:03 |
| infinity | That said, relying on a version check will be fragile. | 20:04 |
| bjf | apw, yeah | 20:04 |
| infinity | apw: Oh, it's autogenerated at build time, no wonder I can't find it in a diff. Derp. | 20:04 |
| Suudy | And what I'm most confused about is how 3.13.0-46 changed dcache.h so significantly. Yet looking at the raw 3.13 dache.h (http://lxr.free-electrons.com/source/include/linux/dcache.h?v=3.13) it is the same as 3.13.0-45 | 20:04 |
| Suudy | infinity: Thanks for the autoconf solution. Sadly, the MVFS driver is Makefile based. And I'm not sure how to replicate the functionality of AC_CHECK_LINUX_STRUCT | 20:06 |
| infinity | Then yeah, you might be stuck with a version check. | 20:07 |
| bjf | Suudy, it was a backport of: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=946e51f2bf37f1656916eb75bd0742ba33983c28 | 20:09 |
| Suudy | I guess I'm a bit confused then. So when the version says 3.13.0-46, it really means 3.13.11 with a bunch of later changes merged in? | 20:11 |
| Suudy | Or is this for a pending (if ever) version of 3.13.12? | 20:12 |
| infinity | Suudy: It's 3.13.11-ckt15 | 20:12 |
| bjf | Suudy, it is 3.13.0 with all stable releases applied up to ^ what infinity just said | 20:12 |
| infinity | Suudy: 3.13.11 is dead upstream, we're the new maintainers, however for political reasons, we don't maintain it on kernel.org (not our choice). | 20:13 |
| Suudy | Ah! Well, I learned something new. I'd never heard of 'ckt' before. Now it makes sense. | 20:13 |
| bjf | Suudy, if you look at our git repo for trusty it's easier to understand (i think) | 20:13 |
| Suudy | And no wonder the folk on #kernel-newbies told me to talk to Canonical or IBM. Makes sense now. | 20:14 |
| infinity | Anyhow, it looks like this is about the only useful define you're going to find: | 20:14 |
| infinity | include/generated/utsrelease.h:#define UTS_UBUNTU_RELEASE_ABI 46 | 20:14 |
| Suudy | Thanks for the clarification! | 20:14 |
| infinity | Which is... Kinda useless for differentiating between upstream and Ubuntu, since you can't include it unconditionally... | 20:16 |
| infinity | And it's not uapi exported. | 20:16 |
| infinity | apw: Dude. | 20:16 |
| infinity | apw: How are people supposed to use this header? :) | 20:16 |
| infinity | Oh, I guess it doesn't need to be uapi. | 20:17 |
| infinity | But still. Not sure how one's meant to use it for code that's meant to work on !ubuntu as well. | 20:17 |
| Suudy | Well, since this change would be Ubuntu specific, I just forked off the source and made Ubuntu specific changes. | 20:18 |
| infinity | Suudy: Okay, well, in the forking world, easy enough, as above. | 20:18 |
| Suudy | And this driver source only checks for < 3.6. So any other changes (such as in 3.19) would be broken anyhow. | 20:19 |
| Suudy | Again, thanks for the help! Greatly appreciated. | 20:20 |
| apw | infinity, you'd use it in a define which is different depending on whether the underlying define is present | 21:04 |
| apw | infinity, and there is no point in us supplying that as you need to do something depending on whther that was present | 21:10 |
| apw | #ifdef UTS_UBUNTU_RELEASE_ABI | 21:10 |
| apw | #define UBUNTU_VERSION(a, b, c) (((a) * 10000) + ((b) * 100) + (c)) | 21:11 |
| apw | #else | 21:11 |
| apw | #define UBUNTU_VERSIONS(a, b, c) 0 | 21:11 |
| apw | #endif | 21:11 |
| apw | stylee | 21:11 |
| cyberkryption | anyone tell me what the three numbers after the hash in uname-a mean? | 21:16 |
| apw | cyberkryption, paste an example ... | 21:18 |
| apw | cyberkryption, as the default there is only one number there | 21:19 |
| cyberkryption | ok i am building arm kernel for a raspberry pi and have kernel modules that wont load. pi kernel uname -a is Linux raspberrypi 3.18.7-v7+ #755 SMP PREEMPT Mon Feb 23 19:52:56 GMT 2015 armv7l GNU/Linux my compiled kernel is Linux kali 3.18.7-v7+ #758 SMP PREEMPT Mon Feb 23 19:52:56 GMT 2015 armv7l GNU/Linux | 21:20 |
| cyberkryption | i want to know the difeerence between #755 and #758 it looks to be some sort of kernel subversion | 21:21 |
| mjg59 | That's the buld number | 21:21 |
| mjg59 | build number | 21:21 |
| mjg59 | The first build from a kernel tree will be #1 | 21:22 |
| mjg59 | Every subsequent build from the same source tree will increment it | 21:22 |
| mjg59 | It's ignored for module versions | 21:22 |
| cyberkryption | ok so my pi kernel is three builds from my kali ie 755 vs 758 | 21:23 |
| cyberkryption | could the difference be accounted for by difference source tree kernel branches/ | 21:23 |
| ogra_ | no, it just means that one of them was built 3 times more often from the same tree | 21:24 |
| cyberkryption | problem no kernel modules get loaded as part of boot process, if i try manual insmod i get uio: disagrees about version of symbol module_layout | 21:28 |
| cyberkryption | on googling this pointed me to some module or kernel differences | 21:28 |
| cyberkryption | but i have done modinfo on the modules that fail to load and they are identical | 21:29 |
| cyberkryption | so i wanted to know the significance of the hash in uname -a | 21:29 |
| cyberkryption | is there a better way to pull a running config than zcat /proc/config.gz | 21:29 |
| cyberkryption | does this mean that the symbols in the modules are in different position in the compiled modules to where the kernel expects it to be? | 21:30 |
| cyberkryption | therefore it wont load? | 21:30 |
| cyberkryption | ok solved it, it has to wth the fact that the modules.symers was not used in the kernel compilation process | 21:50 |
| infinity | apw: My point is that to get that ifdef working, you need to include a header that isn't included from any other standard header, which is a fail. | 23:07 |
| infinity | apw: You can't know it's Ubuntu without that header, so you can't conditionally include it, and you can't unconditionally include it, since it's not in !ubuntu kernels. | 23:08 |
| apw | infinity, that include file is a completely standard header that the other kernel version defines are in | 23:19 |
| apw | infinity, it is the one with the normal kernel base version in | 23:19 |
| apw | infinity, or at least that is the intent, if it is not it is broken | 23:21 |
| infinity | apw: Oh, is UTS_RELEASE an upstream define? In that case, never mind my whining. | 23:23 |
| apw | infinity, UTS_RELEASE is what is included in the uname -a output | 23:27 |
| infinity | apw: Check. | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!