=== pgraner-afk is now known as pgraner [07:42] could it be considered a bug that an invalid character has ended up in sysctl.conf? [07:42] or does it not really matter? [07:43] sorry, to clarify - the character is not ascii [07:49] brendand, it would depend on how it got there, which character is it [07:50] apw, it's a fancy one of these: ' [07:50] 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] single characters are much less likely to have been the kernel [07:51] apw, i can only imagine someone copy and pasted text from another document, since you can't (easily) type that character [07:51] yeah probabally an example if it has words open and close ' the slightly angled ones [07:55] it looks awful when opening the file in any normal text editor: [07:55] # 0 - don<80><99>t use privacy extensions. [07:56] so is that in each and every version of the file [07:57] brendand, which sysctl file exactly is this in [08:00] 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] brendand, and that file is in procps [08:07] apw, it's probably not actually. i came across this just now on some ARM hardware (Calxeda) [08:08] apw, although i see it here on my system too [08:08] strange [08:09] i'm just wondering why i'm not seeing the same bug triggered by this as i did on the calxeda [08:15] you are connecting differently and do not have an 8 bit clean utf-8 connection [08:20] apw, what do you mean by 'connecting differently'? [08:21] something is different about how you are accessing that system such that [08:21] it does not think you are on a UTF-8 terminal, and that character needs one [08:21] if it bothers you then just file a bug and patch against procps and be happy [08:27] alright, thanks === fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi [10:04] * ppisati goes out for a bit [11:15] * henrix wonders why would anyone send 29M emails! [11:29] henrix, because 30M might be the send quota at his provider [11:30] ogra_: heh, may i should ask IS :) [12:26] * henrix -> lunch [13:55] jjohansen, about ? your pull-request for maguro seems to have a >>>>> in it [14:00] jjohansen: apw: ogra_: I'm getting http://paste.ubuntu.com/5836282/ with maguro, is that fine or expected? [14:00] rsalveti, already fixed [14:00] (not uploaded) [14:01] ogra_: is that causing us any harm? [14:01] nope [14:01] just noise apparently [14:02] 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] right, in the ml [14:03] should be in after review, cool [14:37] rsalveti, i think that is the one with a merge conflict in the pull request [14:38] apw: yeah [14:41] ogra_, was the manta aa issue sorted in userspace, ie can i reenable it [14:41] (i ahv the feeling it was ... but i would like to be 100% sure) [14:46] apw,, yes, lxc apparmor usage was disabled across the board afaik so it shouldnt interfere anymore [15:10] ** [15:10] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [15:10] ** [15:44] drat. deleted $HOME/ubuntu-quantal.git on zinc. not realizing i was using that as objects alternates in an exported tree. [15:44] well, it was getting crufty anyways i suppose. [15:53] 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] Should I just add them to the "generic" ARM flavor, or create a new flavor (just like OMAP) has? [15:54] I assume building all the drivers as modules rather than built-in would be best. [15:58] srwarren, if generic works for that device, then i would enhance that rather than making a new flavour [15:58] 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] the config right there [15:58] OK, sounds good. [15:58] hallyn, doh [15:59] 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] 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] srwarren, if we haven't disabled them all together it seems reasonable [16:55] ## [16:55] ## Kernel team meeting in 5 minutes [16:55] ## === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues July 9th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [17:52] 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] 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] 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] BenC: Did you test the raring-proposed kernel on any of your kit? [18:12] 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] psivaa: Is ti-omap4/quantal running into problems, or is the regression test still ongoing? [18:14] psivaa: Err, s/quantal/precise/ [18:17] 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] smb: I'm pretty swamped right now, but I can try. :/ [18:18] smb: Or you can hit me in person in London (and put it on the sprint agenda) [18:19] 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] Beer can produce stellar results. [18:19] Red wine, moreso. [18:20] results probably... the intended ones, maybe not. But the conversations are... "interesting" [18:20] I've done some of my best work under the influence of Penfolds. [18:21] And Belgian Blondes. I leave it to you to interpret that noun phrase however you prefer. [18:21] 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] 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] Yeah, there is that too. :/ [18:24] 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] 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] infinity, sure, yeah [18:25] to both [18:26] One reason to to say heck we just backport latest shit and close eyes [18:26] Possibly, yeah. [18:57] infinity: i once had an issue of corrupted mmc with that, running it for the second time now. will update asap [18:59] 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] infinity: ack :) [19:06] infinity: works on mine [19:14] * bjf -> lunch [19:25] BenC: Shiny. === fmasi is now known as fmasi_afk [19:54] 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] ERROR: "inode_capable" [fs/xfs/xfs.ko] undefined! [19:54] 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] hallyn, you'll need to do EXPORT_SYMBOL(inode_capable) in order to be able to use that in the other module [19:57] I thought surely that was already done, but i bet you're right [19:57] bguthro: indeed it's not. thanks! [20:27] apw, it looks like d-i can be persuaded to pick up a new modules udeb by editing build/pkg-lists/*, right? [20:51] srwarren: Yes, though this should generally not be necessary. [20:52] In general yes, although I can't see a good fit in the existing -modules.udeb for general SoC infra-structure modules [21:15] srwarren: Possibly just in the kernel-image udeb itself. [21:15] OK, that would make sense. I didn't realize it was OK to dump modules there. Thanks. [22:03] 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] Ubuntu bug 1196295 in lxc (Ubuntu) "lxc-start enters uninterruptible sleep" [High,Incomplete]