[11:03] <apw> hallyn_, heh you should indeed
[13:05] <alex116> hi, I'm trying to read i2c data and from userspace the example code uses ioctl
[13:06] <alex116> I want to read i2c data from a kernel module and would like to figure out how to read from the device
[13:06] <alex116> can I just use the normal open read write close functions?
[13:12] <cking> alex116, how about https://www.kernel.org/doc/Documentation/i2c/dev-interface
[13:35] <cking> maybe https://www.kernel.org/doc/Documentation/i2c/writing-clients
[14:10] <alex116> I was hoping I could just use the loaded driver's functions because thats all ioctl does
[14:41] <igalic> Can I somehow make it impossible (or near impossible) for apt to even consider removing linux-image-server, linux-server, linux-headers-server, etc..?
[14:44] <infinity> zequence: It's SRU time again, if you missed out on the new bugs.
[14:44] <infinity> igalic: There's no reason it would remove them unless you ask it to remove something they depend on.
[14:44] <infinity> igalic: As a general rule, people are expected to read apt's output when it tells them what it intends to do.
[14:45] <apw> infinity, arn't they even manually installed top levels so it should be hard to force them off
[14:46] <apw> igalic, how did you get into a sitruation where it wanted to, what did you ask for
[14:46] <apw> that it though could only be solved by so removing it
[14:47] <infinity> apw: They're manually installed, yeah.  Not that autoremove would ever pull them anyway, since they're never installed as deps.
[14:47] <infinity> apw: So, people removing them are doing it intentionally (ie: by removing the kernel they depend on)
[14:47] <apw> i can only assume you asked it to remove the latest kernel ?
[14:47] <igalic> We're trying to remove automatically installed kernels. We don't quite trust autoremove, since it tends to uninstall things that are "running". This "recipie" http://dpaste.com/1464493/  (from https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels ) however will remove /other/ stuff that we'd rather kept.
[14:48] <igalic> (I like how the automatic section is actually empty)
[14:51] <igalic> oh.. that's the latest kernel. That's why it's removing it.
[14:52] <igalic> so that "documentation" is lying.
[14:53] <diwic> ogasawara, I understand you will discuss this next week, but do you today have a feeling for whether you'll end up with 3.13 or 3.14 for the LTS?
[14:54] <ogasawara> diwic: most likely 3.13
[14:54] <diwic> ogasawara, thanks, that was my guess too
[14:56] <rtg> apw, dropped 'UBUNTU: SAUCE: (no-up) drm -- stop early access to drm devices' during the rebase. Do you think we still need it ?
[15:01] <infinity> igalic: "apt-get autoremove" will not remove the running kernel.  Random other weird snippets on wikis are generally suspect.
[15:02] <igalic> infinity: apt-get autoremove will not remove the running kernel, but it will remove the running kernel's utils, tools and headers.
[15:02] <infinity> igalic: Not anymore.
[15:02] <apw> rtg, i think i am supprised to still find it applied, i thought that that was fixed another way in upstream now
[15:03] <rtg> apw, well, I've been faithfully forward porting it for several releases
[15:03] <infinity> igalic: That was fixed in saucy.  In precise, it'll yank tools probably, yeah.  Maybe also headers.
[15:03] <apw> rtg, hehe ... oh well ... 
[15:03] <apw> infinity, didn't we fix those deps back in the end?  i thought we did
[15:03] <rtg> apw, guess we'll find out. I haven't even boot tested this pile yet
[15:04] <igalic> infinity: that's badd, because we're running LTS
[15:04] <infinity> apw: I may have made the header fix in precise.  Can't fix the tools issue without backporting the rename/reorg.
[15:04] <igalic> infinity: can you link me to the bug?
[15:04] <apw> infinity, point, that we have done for the lts-backport kernels, saucy onwards but .. yes not before that
[15:05] <infinity> igalic: Okay, just verified, precise won't autoremove headers, but it will autoremove tools.
[15:05] <infinity> igalic: And the tools problem is hard to solve without us reorganizing the precise kernel packages.
[15:05] <infinity> (Which is probably not worth doing with another LTS around the corner, IMO)
[15:05] <infinity> Given that the number of people who need tools installed is tiny.
[15:06] <igalic> perf top is invaluable.
[15:06] <infinity> For normal users?
[15:07] <igalic> >_o
[15:07] <infinity> You and I may define normal differently. :P
[15:07] <igalic> Define normal users.
[15:07] <infinity> s/normal/average/
[15:07] <infinity> Statistically, very few people use perf.
[15:07] <igalic> I'm a Unix Admin. I don't know what you mean.
[15:07] <infinity> And the people who do use it probably intersects well with people who can read the output of "apt-get autoremove" and say "no" when it's not what they want.
[15:08] <igalic> Yes, except we have everything puppetized on hundreds of machines.
[15:08] <infinity> Anyhow, we *could* backport the whole tool renaming madness to precise, I'm just not sure it's worth the pain.
[15:09] <igalic> infinity: if I run the cool new kernels on LTS, will that still be an issue?
[15:10] <infinity> apw: Is the tool renaming magic represented in linux-lts-saucy?
[15:10] <igalic> i.e.: linux-image-generic-lts-saucy 
[15:10]  * infinity looks.
[15:10] <igalic> (or any other)
[15:10] <apw> infinity, yes
[15:10] <infinity> Yeah, looks like that works.
[15:11] <apw> infinity, oh well ... perhaps the answer is "in the new one"
[15:11] <infinity> igalic: Only lts-saucy, not the earlier ones.
[15:11] <infinity> But, I'd need to backport the matching apt fix for that.
[15:11] <apw> it may not have hit updates yet, or is about to now or something
[15:11] <igalic> infinity: apw: can you link me to the issues describing this?
[15:11] <infinity> linux-tools-3.11.0-12-generic linux-tools-3.11.0-13-generic linux-tools-3.11.0-14-generic are all what I'd expect in precise.
[15:12] <infinity> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205284
[15:12] <ubot2> Launchpad bug 1205284 in linux (Ubuntu Precise) "linux-tools naming is not scalable to multiple source packages" [Medium,Fix committed]
[15:12] <apw> infinity, the bits for master might not be in yet, and there is a common tools package fix pending on the lts-saucy branch
[15:13] <apw> infinity, yeah the wrapper fixes are pending for the next sru round for master
[15:13] <infinity> apw: s/next/current/, or in another month?
[15:13] <apw> as in only on master-next right now
[15:14] <infinity> Bummer.  Well, I'll backport the apt fix, since that's trivial.
[15:14] <apw> ie the /usr/bin/perf won't recognise the new perf binaries till that fgoes out
[15:14] <apw> yeah, it got missed in testing
[15:14] <apw> its not like you cannot find them manually so not world ending, they are there installed
[15:18] <infinity> apw: Alright, apt backport uploaded.
[15:18] <igalic> wowzers!
[15:19] <infinity> apw: If someone wants to mangle all the tools crap in 3.2, that might make somoene happy, but I personally think it's likely not worth the effort.
[15:19] <igalic> infinity: do you have a bug for that also I can track?
[15:19] <infinity> igalic: Same bug I pasted above.
[15:23] <igalic> so, once this gets promoted (demoted?) to precise, if we have linux-image-generic-lts-saucy installed, and the system's apt-to-date, we can simply have Unattended-Upgrade::Remove-Unused-Dependencies "true"; and everything will be perfectly fine.
[15:25] <ppisati> bjf: i'm preparing the P/omap4 kernel
[15:25] <bjf> ppisati, ack
[15:28]  * ppisati disappears for a bit
[15:30] <infinity> igalic: If you want headers too, that would be linux-generic-lts-saucy
[15:30] <infinity> igalic: And linux-tools-generic-lts-saucy for tools.
[15:30] <igalic> infinity: linux-generic-lts-saucy installs headers also?
[15:31] <infinity> igalic: "linux-generic" depends on "linux-image-generic" and "linux-headers-generic" (trade "generic" for flavour du jour, like generic-lts-saucy)
[15:31] <igalic> infinity: I think I've asked this question a couple of times, but, what's the difference between -generic, -server, -chewgum, -etc ?
[15:32] <infinity> igalic: These days, generic is the only flavour, though there's a fake not-quite-flavour called virtual, which is actually just generic without most of the modules.
[15:33] <infinity> igalic: But, on LTSes, you'll have different generic options for the HWE backport kernels (like lts-raring, lts-saucy, etc).
[15:33] <infinity> Oh, I guess it's not fair to say "generic" is the only one, as there's also lowlatency.
[15:33] <infinity> But it's the only one built from the master sources. :P
[15:34] <igalic> What's that mean?
[15:35] <infinity> There's a "linux" source package, maintained by the Canonical kernel team, and it only produces the generic (and virtual) flavour.
[15:35] <apw> (and notionally the server flavour)
[15:35] <infinity> lowlatency is a rebased fork maintained by the Ubuntustudio team, which has a few different twiddles.  Not particularly ideal for servers, so probably of little intrerest to you.
[15:35] <infinity> apw: There is no server flavour.
[15:36] <infinity> (Not anymore)
[15:36] <apw> there is a linux-server and linux-{image,headers}-server though
[15:36] <apw> which are used in server images, which is why it is notional
[15:37] <infinity> apw: Sure, but it just installs generic. ;)
[15:37] <apw> right, just .. dunoo ... being a pedant
[15:37] <infinity> I suppose it keeps the option open if we feel the need to fork configs again some day.
[15:37] <infinity> But with scheduler improvements and the like, forked configs are less interesting over time.
[15:37] <igalic> It would be nice to install -server and have sysctl settings actually worthy of a server.
[15:38] <apw> igalic, that would be possible, as it has its own meta package
[15:38] <apw> igalic, if there was a definative set which made sense
[15:43] <igalic> apw: disabling the oom killer for instance ;)
[15:45] <apw> igalic, i don't think disabling that is going to solve any issues, yo should never ben runnig a server to the point it would need to
[15:49] <infinity> Disabling the OOM killer doesn't magically prevent you from running out of RAM.
[15:50] <infinity> It does, on the other hand, assume that the first few processes started are the only ones allowed to have memory leaks, which might be a desired behaviour for some.
[15:50] <igalic> No, it doesn't but it magically prevents the kernel from not killing processes even though I'm NOT out of RAM.
[15:51] <infinity> igalic: When you're out of RAM, all your processes are out of RAM.  Until a sufficiently large one crashes.  *shrug*
[15:51] <infinity> The OOM killer attempts to make intelligent decisions based on usage patterns.  It's not necessarily any dumber than the non-oom-kill algorithm of "let stuff crash when it tries to malloc()".
[15:52] <infinity> igalic: Without the OOM killer, you could leak with some Java servlet, but the malloc() that hits the brick wall could be init.  Instant kernel panic, game over.
[15:53] <infinity> igalic: You can't control WHICH process hits the last available page and dies.
[15:53] <igalic> please read http://www.twistedmatrix.com/users/glyph/rant/softethics.html
[15:54] <apw> your point with that ?
[15:54] <apw> or is that a total no-sequiter
[15:54] <infinity> apw: It's unethical to prevent init(8) from dying, if that's what it chose to do.
[15:55] <infinity> apw: How dare we stand in the way of its suicide attempt via malloc().
[15:55] <apw> igalic, anyhow if you can change it via sysclt, one can do that, so ...
[15:57] <igalic> apw: read the bit about car manufacturers.
[15:59] <igalic> (I think a good resource is also http://www.loper-os.org/?p=284 )
[15:59] <infinity> igalic: It's a poor analogy, in reference to the above discussion.  If your car runs out of gas, do you think it would be appropriate for it to jam a piston through the hood and send a tire flying off the side of the road?
[16:00] <infinity> igalic: Sure, if you had just kept the tank topped up, you'd be a responsible driver, and you'd still have an engine.  On the other hand, lolwut?
[16:01] <igalic> I think a better "fuel" analogy is this one https://lwn.net/Articles/104179/ ;)
[16:03] <apw> so all one needs to do is swtich to full commit mode for allocation and ensure you have enough swap
[16:04] <igalic> And suddenly you have a predictable VM. YAY. It's almost like I'm using a Unix.
[16:06] <apw> yeha right, like they wern't the same
[17:09] <ppisati> rtg: i'm building a test kernel
[17:10] <rtg> ppisati, ack, I'm about to email a comment to robher about the mac learning patch
[17:12] <TooLmaN> Hi guys.  I'm back to working on embedded projects and I'm rusty on kernel building.  What is a good resource for building a kernel from source on Ubuntu/Mint?  The Wiki appears to be a bit dated.  Thanks
[17:16] <ppisati> [flag@luxor ubuntu-saucy]$ git fetch origin
[17:16] <ppisati> [flag@luxor ubuntu-saucy]$ git rhard origin/master-next
[17:16] <ppisati> HEAD is now at a223125 UBUNTU: SAUCE: (no-up) apparmor: Fix tasks not subject to, reloaded policy
[17:16] <ppisati> [flag@luxor ubuntu-saucy]$ git cherry-pick -sx f0915781bd5edf78b1154e61efe962dc15872d09
[17:16] <ppisati> [master-next 15fa8df] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops Author: Will Deacon <will.deacon@arm.com> 3 files changed, 123 insertions(+), 30 deletions(-)
[17:16] <ppisati> rtg: ^
[17:16] <ppisati> rhard is an alias for 'reset --hard'
[17:17] <rtg> ppisati, huh, well maybe I fat fingered something.
[17:17] <ppisati> rtg: actually that hash comes from rmk's git tree
[17:18] <rtg> ppisati, well, try the same patch from Linus' tree
[17:18] <ppisati> rtg: but if you don't have that remote, it would probably say 'unknown hash or something'
[17:18] <ppisati> rtg: let's see
[17:21] <TooLmaN> disregard.  I had to add the source repos.  
[17:22] <ppisati> rtg: even linus version apply ok
[17:22] <ppisati> [flag@luxor ubuntu-saucy]$ git cherry-pick -sx f091578
[17:22] <ppisati> [master-next acaa3ca] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops Author: Will Deacon <will.deacon@arm.com> 3 files changed, 123 insertions(+), 30 deletions(-)
[17:22] <rtg> ppisati, ok, works for me then
[17:22] <ppisati> anyhow
[17:22] <ppisati> let's wait until it builds
[17:23] <rtg> ppisati, isn't that the same SHA1 as rmk tree ? f091578 and f0915781bd5edf78b1154e61efe962dc15872d09
[17:23] <ppisati> same sha
[17:24] <rtg> ppisati, ok, I see what I did. I got the wrong patch, e.g., 'ARM: tlb: don't perform inner-shareable invalidation for local BP'
[17:24] <ppisati> rtg: yeah, slightly different subj
[17:24] <ppisati> rtg: local BP vs local TLB
[17:24] <rtg> ppisati, too damn close...
[18:10] <ppisati> rtg: sent
[18:10] <rtg> ppisati, ack
[20:54] <slangasek> apw: hey, can you sanity check me... does fsync() have any meaning on ptys?
[21:01] <apw> slangasek, i cannot think what it would mean on a pty
[21:01] <slangasek> hmm
[21:01] <apw> the data is either in the hole or it is not
[21:02] <slangasek> so I'm asking because of https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-upstart/14/ARCH=amd64,label=adt/ - an upstart test that's failed intermittently, because a log file that's supposed to be created didn't get created
[21:02] <slangasek> and I'm trying to figure out why; my current guess is in-kernel buffering
[21:03] <slangasek> but that's a SWAG
[21:03] <slangasek> the other possibility is the kernel is doing everything right, and upstart is just failing to create the logfile with the data it's meant to be reading from the pty ;)
[21:08] <apw> slangasek, if you can point me at the source for the test, i'll have a think about it and figure out if fsync means anything
[21:10] <slangasek> apw: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/init/tests/test_state.c#L2115 vs. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/init/tests/test_state.c#L2143
[21:12] <slangasek> anyway, fsync() returns non-zero, so in practice that's the wrong interface anyway ;)
[22:04]  * rtg -> EOW