[07:42] <brendand> could it be considered a bug that an invalid character has ended up in sysctl.conf?
[07:42] <brendand> or does it not really matter?
[07:43] <brendand> sorry, to clarify - the character is not ascii
[07:49] <apw> brendand, it would depend on how it got there, which character is it
[07:50] <brendand> apw, it's a fancy one of these: '
[07:50] <apw> brendand, when it is the kernel's fault it tends to be larger blocks of characters whcih get added and they tend to be aligned to filessytem block size
[07:51] <apw> single characters are much less likely to have been the kernel
[07:51] <brendand> apw, i can only imagine someone copy and pasted text from another document, since you can't (easily) type that character
[07:51] <apw> yeah probabally an example if it has words open and close ' the slightly angled ones
[07:55] <brendand> it looks awful when opening the file in any normal text editor:
[07:55] <brendand> #    0 - don<E2><80><99>t use privacy extensions.
[07:56] <apw> so is that in each and every version of the file
[07:57] <apw> brendand, which sysctl file exactly is this in
[08:00] <apw> brendand, anyhow if it is in the file as packaged, then it could be a bug, though it looks just fine in vi
[08:01] <apw> brendand, and that file is in procps
[08:07] <brendand> apw, it's probably not actually. i came across this just now on some ARM hardware (Calxeda)
[08:08] <brendand> apw, although i see it here on my system too
[08:08] <brendand> strange
[08:09] <brendand> i'm just wondering why i'm not seeing the same bug triggered by this as i did on the calxeda
[08:15] <apw> you are connecting differently and do not have an 8 bit clean utf-8 connection
[08:20] <brendand> apw, what do you mean by 'connecting differently'?
[08:21] <apw> something is different about how you are accessing that system such that
[08:21] <apw> it does not think you are on a UTF-8 terminal, and that character needs one
[08:21] <apw> if it bothers you then just file a bug and patch against procps and be happy
[08:27] <brendand> alright, thanks
[10:04]  * ppisati goes out for a bit
[11:15]  * henrix wonders why would anyone send 29M emails!
[11:29] <ogra_> henrix, because 30M might be the send quota at his provider 
[11:30] <henrix> ogra_: heh, may i should ask IS :)
[12:26]  * henrix -> lunch
[13:55] <apw> jjohansen, about ?  your pull-request for maguro seems to have a >>>>> in it
[14:00] <rsalveti> jjohansen: apw: ogra_: I'm getting http://paste.ubuntu.com/5836282/ with maguro, is that fine or expected?
[14:00] <ogra_> rsalveti, already fixed
[14:00] <ogra_> (not uploaded)
[14:01] <rsalveti> ogra_: is that causing us any harm?
[14:01] <ogra_> nope
[14:01] <ogra_> just noise apparently 
[14:02] <rsalveti> hm, don't see any new commit at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=shortlog;h=refs/heads/maguro
[14:03] <rsalveti> right, in the ml
[14:03] <rsalveti> should be in after review, cool
[14:37] <apw> rsalveti, i think that is the one with a merge conflict in the pull request
[14:38] <rsalveti> apw: yeah
[14:41] <apw> ogra_, was the manta aa issue sorted in userspace, ie can i reenable it
[14:41] <apw> (i ahv the feeling it was ... but i would like to be 100% sure)
[14:46] <ogra_> apw,, yes, lxc apparmor usage was disabled across the board afaik so it shouldnt interfere anymore
[15:10] <jsalisbury> **
[15:10] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:10] <jsalisbury> **
[15:44] <hallyn> drat.  deleted $HOME/ubuntu-quantal.git on zinc.  not realizing i was using that as objects alternates in an exported tree.
[15:44] <hallyn> well, it was getting crufty anyways i suppose.  
[15:53] <srwarren> If I wanted to build kernel udebs for debian-installer to run on Tegra (NVIDIA ARM SoC), I need to add some drivers into the udebs...
[15:53] <srwarren> Should I just add them to the "generic" ARM flavor, or create a new flavor (just like OMAP) has?
[15:54] <srwarren> I assume building all the drivers as modules rather than built-in would be best.
[15:58] <apw> srwarren, if generic works for that device, then i would enhance that rather than making a new flavour
[15:58] <apw> i don't think we make any di images for any arm platform at the moment so we would not have tried to get
[15:58] <apw> the config right there
[15:58] <srwarren> OK, sounds good.
[15:58] <apw> hallyn, doh
[15:59] <srwarren> FWIW, there are generic and omap4 images on the Ubuntu d/l site, and I booted one with a custom kernel and it even installed OK on my Toshiba AC100!
[16:00] <srwarren> So, if I start fixing up the udeb packaging etc., and send patches, is it likely you'd take the patches into the official sources even though Tegra presumably isn't an officially supported platform?
[16:39] <apw> srwarren, if we haven't disabled them all together it seems reasonable
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[17:52] <srwarren> So, I imagine I might add sdhci-tegra.ko to block-modules. What about modules for core system infra-structure like I2C (for communication with PMICs) and PMIC (Power-Management IC) drivers themselves. Should I create e.g. a new arm-soc-modules/soc-modules/soc-infrastructure-modules/...? There doesn't seem a good existing location for these.  << apw
[17:53] <srwarren> Another option would be to make them builtin, but by the time N SoCs are supported, that'd be a fair bit of bloat in the core zImage
[17:53] <apw> srwarren, the d-i stuff has 'fixed' names for things, so i would expect you would want to put them in one of the existing ones
[18:11] <infinity> BenC: Did you test the raring-proposed kernel on any of your kit?
[18:12] <infinity> BenC: I'd be happy enough to release it, knowing it works on mine, but since you have an interest in 2/4 flavours, it would be nice to know you've tested those. :P
[18:13] <infinity> psivaa: Is ti-omap4/quantal running into problems, or is the regression test still ongoing?
[18:14] <infinity> psivaa: Err, s/quantal/precise/
[18:17] <smb> infinity, Is there any chance of you finding time to look at crash backports or shall I wait till I can get more personal. :)
[18:18] <infinity> smb: I'm pretty swamped right now, but I can try. :/
[18:18] <infinity> smb: Or you can hit me in person in London (and put it on the sprint agenda)
[18:19] <smb> infinity, Yeah, that was my thinking. You cannot escape then ... and I can try to persuade with beers... though not sure this helps on getting results. :)
[18:19] <infinity> Beer can produce stellar results.
[18:19] <infinity> Red wine, moreso.
[18:20] <smb> results probably... the intended ones, maybe not. But the conversations are... "interesting"
[18:20] <infinity> I've done some of my best work under the influence of Penfolds.
[18:21] <infinity> And Belgian Blondes.  I leave it to you to interpret that noun phrase however you prefer.
[18:21] <smb> Heh, yeah its those where you come back later and admire that genius developer that wrote that shit which incidentally has the same name as you
[18:22] <infinity> Most of that has more to do with age than innebriation, I think.  I look at stuff I did from 20-25, and wonder where that really smart dude went.
[18:24] <smb> Yeah, there is that too. :/
[18:24] <infinity> smb: Anyhow, please do put it on the sprint agenda, and if we get to it before then, we can take it off again.
[18:25] <infinity> smb: But I think that even if I get to the reviews and we get it all uploaded, we'll want to discuss what we *should* be doing with crash, going forward, since it seems to be vaguely tied to kernel versions, so gets messed up with HWE stacks.
[18:25] <smb> infinity, sure, yeah
[18:25] <smb> to both
[18:26] <smb> One reason to to say heck we just backport latest shit and close eyes
[18:26] <infinity> Possibly, yeah.
[18:57] <psivaa> infinity: i once had an issue of corrupted mmc with that, running it for the second time now. will update asap
[18:59] <infinity> psivaa: Sure, not a massive rush, just noted the task had been running for a while, so prodded to make sure it hadn't been forgotten. :)
[19:02] <psivaa> infinity: ack :)
[19:06] <BenC> infinity: works on mine
[19:14]  * bjf -> lunch
[19:25] <infinity> BenC: Shiny.
[19:54] <hallyn> i'm trying to build a kernel with userns fixes for xfs.  it uses inode_capable(), which is defined in kernel/capability.c, in xfs_ioctl.c  xfs is compiled as a module, and capability.o apparently not included, so i get:
[19:54] <hallyn> ERROR: "inode_capable" [fs/xfs/xfs.ko] undefined!
[19:54] <hallyn> I don't see any other non-xfs files mentioned in fs/xfs/Makefile...  is there a way to specify that capability.o needs to be built in?
[19:55] <bguthro> hallyn, you'll need to do EXPORT_SYMBOL(inode_capable) in order to be able to use that in the other module
[19:57] <hallyn> I thought surely that was already done, but i bet you're right
[19:57] <hallyn> bguthro: indeed it's not.  thanks!
[20:27] <srwarren> apw, it looks like d-i can be persuaded to pick up a new modules udeb by editing build/pkg-lists/*, right?
[20:51] <infinity> srwarren: Yes, though this should generally not be necessary.
[20:52] <srwarren> In general yes, although I can't see a good fit in the existing -modules.udeb for general SoC infra-structure modules
[21:15] <infinity> srwarren: Possibly just in the kernel-image udeb itself.
[21:15] <srwarren> OK, that would make sense. I didn't realize it was OK to dump modules there. Thanks.
[22:03] <hallyn> jsalisbury: hey, i know you've been involved in the older versions of this, so bug https://bugs.launchpad.net/bugs/1196295 which i'ma bout to mark as affectinglinux may interesting you
[22:03] <ubot2`> Ubuntu bug 1196295 in lxc (Ubuntu) "lxc-start enters uninterruptible sleep" [High,Incomplete]