| === pgraner-afk is now known as pgraner | ||
| 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:42 |
| brendand | sorry, to clarify - the character is not ascii | 07:43 |
| apw | brendand, it would depend on how it got there, which character is it | 07:49 |
| 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:50 |
| 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:51 |
| 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:55 |
| apw | so is that in each and every version of the file | 07:56 |
| apw | brendand, which sysctl file exactly is this in | 07:57 |
| 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:00 |
| apw | brendand, and that file is in procps | 08:01 |
| brendand | apw, it's probably not actually. i came across this just now on some ARM hardware (Calxeda) | 08:07 |
| brendand | apw, although i see it here on my system too | 08:08 |
| brendand | strange | 08:08 |
| brendand | i'm just wondering why i'm not seeing the same bug triggered by this as i did on the calxeda | 08:09 |
| apw | you are connecting differently and do not have an 8 bit clean utf-8 connection | 08:15 |
| brendand | apw, what do you mean by 'connecting differently'? | 08:20 |
| 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:21 |
| brendand | alright, thanks | 08:27 |
| === 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 | ||
| * ppisati goes out for a bit | 10:04 | |
| * henrix wonders why would anyone send 29M emails! | 11:15 | |
| ogra_ | henrix, because 30M might be the send quota at his provider | 11:29 |
| henrix | ogra_: heh, may i should ask IS :) | 11:30 |
| * henrix -> lunch | 12:26 | |
| apw | jjohansen, about ? your pull-request for maguro seems to have a >>>>> in it | 13:55 |
| 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:00 |
| rsalveti | ogra_: is that causing us any harm? | 14:01 |
| ogra_ | nope | 14:01 |
| ogra_ | just noise apparently | 14:01 |
| 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:02 |
| rsalveti | right, in the ml | 14:03 |
| rsalveti | should be in after review, cool | 14:03 |
| apw | rsalveti, i think that is the one with a merge conflict in the pull request | 14:37 |
| rsalveti | apw: yeah | 14:38 |
| 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:41 |
| ogra_ | apw,, yes, lxc apparmor usage was disabled across the board afaik so it shouldnt interfere anymore | 14:46 |
| jsalisbury | ** | 15:10 |
| jsalisbury | ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 15:10 |
| jsalisbury | ** | 15:10 |
| 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:44 |
| 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:53 |
| srwarren | I assume building all the drivers as modules rather than built-in would be best. | 15:54 |
| 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:58 |
| 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! | 15:59 |
| 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:00 |
| apw | srwarren, if we haven't disabled them all together it seems reasonable | 16:39 |
| jsalisbury | ## | 16:55 |
| jsalisbury | ## Kernel team meeting in 5 minutes | 16:55 |
| jsalisbury | ## | 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! | ||
| 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:52 |
| 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 | 17:53 |
| infinity | BenC: Did you test the raring-proposed kernel on any of your kit? | 18:11 |
| 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:12 |
| infinity | psivaa: Is ti-omap4/quantal running into problems, or is the regression test still ongoing? | 18:13 |
| infinity | psivaa: Err, s/quantal/precise/ | 18:14 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:24 |
| 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:25 |
| smb | One reason to to say heck we just backport latest shit and close eyes | 18:26 |
| infinity | Possibly, yeah. | 18:26 |
| psivaa | infinity: i once had an issue of corrupted mmc with that, running it for the second time now. will update asap | 18:57 |
| 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. :) | 18:59 |
| psivaa | infinity: ack :) | 19:02 |
| BenC | infinity: works on mine | 19:06 |
| * bjf -> lunch | 19:14 | |
| infinity | BenC: Shiny. | 19:25 |
| === fmasi is now known as fmasi_afk | ||
| 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:54 |
| bguthro | hallyn, you'll need to do EXPORT_SYMBOL(inode_capable) in order to be able to use that in the other module | 19:55 |
| hallyn | I thought surely that was already done, but i bet you're right | 19:57 |
| hallyn | bguthro: indeed it's not. thanks! | 19:57 |
| srwarren | apw, it looks like d-i can be persuaded to pick up a new modules udeb by editing build/pkg-lists/*, right? | 20:27 |
| infinity | srwarren: Yes, though this should generally not be necessary. | 20:51 |
| srwarren | In general yes, although I can't see a good fit in the existing -modules.udeb for general SoC infra-structure modules | 20:52 |
| 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. | 21:15 |
| 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] | 22:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!