[07:52] <_ami_> apw: calling generic_handle_irq() explicitly on GPIO does the job which i wanted. [07:54] <_ami_> :) [08:20] _ami_, cool [08:30] <_ami_> apw: obviously this is the way. emulation of hardware irq to software irq to linux. gutted to not understand this at first place. :/ [09:27] does the meta package get an update for sru only when the kernel is migrated to -updates? [09:29] tjaalton, the meta-package migrates with the kernel as it moves -proposed to -updates [09:30] sure but does it get bumped for the abi only once or with every kernel abi change? [09:30] one guy claims that xenial-proposed didn't have an update for linux-generic.. [09:31] yeah it's there [09:31] should've just checked myself :) [09:32] tjaalton, -meta gets updated for any ABI change in linux, and copies out to -proposed with the kernel as a matched pair always [09:33] yeah, thanks [09:33] for confirming [09:33] np [12:39] elmo, 'apt-get install linux-generic-lts-yakkety' works a little better now that things are done building [12:41] rtg: thanks, will try [12:48] rtg, that reminds me you commiteed that "use src_pkg_name in udebs" thing to yakkety ... [12:48] rtg, that can't be on the main branch else it breaks the derivative kernels, that is an lts-foo only patch, and so has be carried on those explicitly [12:50] apw, hmm, I guess none of the derivatives build udebs this far. Perhaps we could modify the patch so that it works on mainline ? [12:50] thus far* [12:50] we'd only notice when d-i is built as it is only in the name of the linking package to that [12:50] it won't break the linux-raspi2 for instance, just any d-i respin we did for that [12:51] rtg, and yes, prolly the right thing to do is make that do some kind of if on src_pkg_name and if it is linux-lts-* then use that, else linux [12:51] on the master branch, but in the past we have just carried it on the linux-lts-X branch and been happy [12:53] apw, I think this regression appeared when we adopted the modern d-i layout for kernel-wedge. This is the first I've encountered this particular udeb generation bug. [12:54] rtg, the src_pkg_name thing, or the one i just fixed [12:54] the one i just fixed was introduced by me in the rejig [12:54] the src_pkg_name thing has been done to all the trees up to now as far as i know [12:54] its nothing to do with the bit which kernel-wedge plays with [12:57] rtg, in lts-wily for instance that change is squashed into "UBUNTU: [Packaging] Wily LTS backport" [12:59] apw, look at Precise, commit 2fcd9ea38097d1d27837b7a407d3f264e2cf4c7c. Looks like henrix ran into the same problem independently. [12:59] apw, nm, I was on the wrong branch [13:00] rtg, we had a variety of messes with that, one has the default the other way and alllll the derivates have the reversing patch [13:00] but it is only lts-foo that cannot use the approved linux--flavour form because it annoyingly duplicates the flavour names [13:01] so it is logical for that exceptional branch to carry the exception, or as we said earlier to bodge it in master using the name prefix [13:14] apw, I'll work on bodging it so we don't have to remember to port it to every LTS kernel going forward. [13:14] rtg, fine with me [13:31] We bought a new machine, installed 16.04 and our software setup and now our hardware RAID controller refuses to work after ~3-4 days of uptime with kernel messages similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703356 [13:31] Debian bug 703356 in src:linux "megasas: Failed to alloc kernel SGL buffer for IOCTL (ref.#688198)" [Important,Open] [13:32] So, what do I do? Wait and hope for this to be fixed? Downgrade to 14.04.X since I don't see if my RAID is healthy when running 16.04? [13:33] not the best question or wording, I know, but that bug has been open for 3 years === JanC is now known as Guest68752 === JanC_ is now known as JanC