[07:50] <sacarde> hi
[07:50] <sacarde> can you suggest me a driver for webcam ID: 10f1:1a08 ?
[08:59] <sacarde> can you suggest me a driver for webcam ID: 10f1:1a08 ?
[12:03] <gsedej_work> Hello! Does anyone know if there is some big change from kenrel 3.12 to 3.13 reguarding ACPI (laptop hot keys)? From 3.13 on, power button on my EeePC 1101HA does not work anymore. More info: http://ubuntuforums.org/showthread.php?t=2219864&p=13096245#post13096245
[14:03] <apw> gsedej_work, you likely should file a bug against the package linux (the kernel) in launchpad
[14:04] <apw> and put all that information in it, if you have a bracket like that working not working a bisect can find it
[14:05] <apw> rtg, on that hyper-v stackola i have a pile for each of trusty and utopic sorted, i'll get utlemming to test them before i send them in
[14:06] <rtg> apw, ack. this is packaging week for trusty
[14:07] <apw> rtg, i don't think it is a rush, so if it misses this one, *shrug*
[15:28] <jsalisbury> **
[15:28] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:28] <jsalisbury> **
[16:54] <jsalisbury> ##
[16:54] <jsalisbury> ## Kernel team meeting in 5 minutes - in #ubuntu-meeting
[16:54] <jsalisbury> ##
[19:05] <rtg> dannf, have you ever talked to chiluk about their hotfix helper ? I think they've solved the version issues that you're encountering.
[19:06] <dannf> rtg: i haven't
[19:06] <dannf> chiluk: got some info?
[19:06] <chiluk> dannf can you restate what you are trying to accomplish?
[19:07] <rtg> I think he wants versions that fit between distro release versions
[19:07] <dannf> chiluk: https://lists.ubuntu.com/archives/kernel-team/2014-August/047617.html (skip down to the 1-5 list)
[19:11] <chiluk> dannf take a look at https://bazaar.launchpad.net/~cts-engineering/cts-engineering/cts-platform-tools/files/head:/kernel/
[19:11] <chiluk> let me know if you don't have access.
[19:11] <chiluk> I'm still reading through your e-mail.
[19:12] <dannf> chiluk: no access
[19:13] <chiluk> dannf try now.
[19:13] <chiluk> and welcome to cts-engineering ;)
[19:14] <chiluk> basically we get around your abi issue by disabling abi checks for our hotfix kernels.
[19:15] <dannf> ah
[19:15] <chiluk> also we version using ~ and + after the ubuntu version string.
[19:15] <dannf> yeah - i've found it useful to keep the abi checking, because sometimes we're building modules that need to load in existing d-i
[19:16] <chiluk> + is newer than ~ is older than.
[19:16] <rtg> dkms is the bane of my existence
[19:16] <dannf> ~ *and* +?
[19:16] <dannf> oh, one or the other - gotchya
[19:16] <dannf> yeah, that's what i'd expect
[19:17] <dannf> chiluk: sorry for the internal link, but https://wiki.canonical.com/CDO/Hyperscale/KernelMaintenance
[19:18] <chiluk> dannf... I just checked actually we are not using + and ~ for kernel packages.
[19:18] <chiluk> instead we version like so.. 3.13.0-32.57hf70318v20140801b1
[19:18] <dannf> rtg: ^ btw - i was wondering about moving that content somewhere public, if there's not already a public equivalent, for how to create ubuntu-y commits
[19:18] <chiluk> hf=hotfix... then internal bug.. then external bug... then build number.
[19:19] <dannf> chiluk: heh - i thought that was a commit hash
[19:19] <chiluk> but dannf not that fancy.. but much more useful.
[19:19] <chiluk> especially in my line of work.
[19:19] <dannf> rtg: of course, i'm making up the policy based on what i've seen, dont' really know what ya'lls rules iz
[19:21] <rtg> dannf, my only rule is, "Don't cause regressions" :)
[19:21] <chiluk> right.. dannf ideally we would follow the same process for hotfix and test kernels .
[19:21] <rtg> chiluk, except for the whole ABI and DKMS issue....
[19:22] <chiluk> well i guess that's up to the developer not to screw that up.
[19:25] <rtg> chiluk, non-sequitur - looking at your dcache branch. the only patch missing is up through 3.16 is 'vfs: add cross-rename' which I don't think is necessary. Agreed ?
[19:26] <rtg> or rather, the only patch up through 3.16 _not_ on your branch is 'vfs: add cross-rename'
[19:40] <chiluk> rtg correct... it's also the only patch that doesn't touch dcache_shrink_list or it's related locking.
[19:40] <rtg> chiluk, cool. lemme know how your testing goes.
[19:43] <rtg> dannf, do you know for sure that DKMS will correctly detect an ABI change with the 2 field scheme you are proposing ?
[19:43] <dannf> rtg: right, that's why i started the commit with commands showing that the results are the same
[19:44] <dannf> rtg: i don't - dkms isn't something i deal with. but if it breaks w/ the 2 field, that shouldn't regress anything
[19:44] <rtg> dannf, so if you change your minor ABI number it _won't_ trigger a DKMS rebuild ?
[19:44] <dannf> well, i'd hope it *would* trigger a DKMS rebuild, but i haven't tried it
[19:45] <rtg> dannf, if it doesn't, then what good is the minor ABI number ? you could just as easily add skip_abi to your build.
[19:45] <dannf> rtg: d-i compat
[19:45] <rtg> and version appropriately
[19:46] <dannf> for example, with the x-gene sata changes, we needed to verify that the sata driver worked at install time. 
[19:47] <dannf> beacuse the abi was the same (and verifiably so), i could extrat that module and cat it to the d-i initrd
[19:47] <dannf> now, if things break, i could just skipabi and move on
[19:47] <dannf> things == my changes break the abi
[19:48] <dannf> but i've had customers building modules to test, etc - nice not to make those suddenly stop working
[19:49] <rtg> dannf, so these aren't DKMS modules, but just straightforward externally built modules ?
[19:50] <dannf> right. though i suspect it'd be a useful feature for chiluk et al if there's a case where they have a DKMS customer who needs to temporarily branch from ubuntu but resync later
[19:50] <dannf> but that doesn't sound like a case they've needed to handle yet
[19:51] <dannf> rtg: honestly, i'd be happiest if ubuntu just didn't use the abi number in the package version, but i guess there's a reason for that
[19:52] <dannf> nothing technically wrong with e.g. linux-image-3.13.0-33-generic_3.13.0-58_arm64.deb
[19:52] <rtg> dannf, the ABI number provides for a unique binary package name which allows you to have multiple kernels installed.
[19:52] <dannf> rtg: i understand that - but that doesn't mean it has to be in the version
[19:53] <dannf> you could have both linux-image-3.13.0-33-generic_3.13.0-58 and linux-image-3.13.0-34-generic_3.13.0-59 installed at the same time
[19:53] <rtg> dannf, its _not_ in the version, its part of the binary package name.
[19:53] <dannf> it is in the version.
[19:53] <dannf> that's where the existing packaging extracts it from
[19:54] <dannf> linux-image-3.13.0-33_3.13.0->>33<<.59
[19:54] <rtg> rather, the ABI is also in the version as well as the package name.
[19:54] <dannf> right - and that's what makes it a pain to do "normal" branch versions
[19:55] <rtg> well, we're gonna have to deal with it 'cause it ain't gonna change
[19:55] <dannf> rtg: i assuemd that was true, thus my hacky patch :)
[19:56] <dannf> if i thought you'd take a patch to drop the abi from the version i'd have done that first :)
[19:56] <dannf> though tbh i don't understand why it is that way
[19:57] <dannf> maybe easier to map back to a package version given just an oops message?
[19:58] <rtg> dannf, so I'm EOD. Lemme think about this some more. I'm trying to think through the implications for your packaging as well as mine.
[19:58] <rtg> I think I understand your use case though
[19:58] <dannf> rtg: understood, and no rush on my part - i just keep this patch in all my trees
[19:59] <dannf> though of course i'd like to shed it/share it eventually