| === gerald is now known as Guest26322 | ||
| * apw yawns | 08:57 | |
| * smb readies the Shreddies | 09:00 | |
| === chuck_ is now known as zul | ||
| === pgraner` is now known as pgraner | ||
| rtg | dannf, can you get the arm64 branch tested this morning ? I'd like to get that pile merged and uploaded. | 12:29 |
|---|---|---|
| jtn | Hello. I gather 3.14 is unlikely to make Trusty. Unfortunately, driver support for Wacom's current range of graphics tablets debuts in 3.14 (I believe). Is there any chance of sneaking the driver into Trusty somehow? -- should I raise a bug? I have hand-rolled a DKMS package of the upstream linux-wacom 0.20 driver for Precise [sic], which suggests it should be straightforward to integrate. I understand if it's too late for Trusty though (I can alw | 12:36 |
| === gerald is now known as Guest31627 | ||
| rtg | jtn, just the 7 wacom patches ? from 3.13 to 3.14-rc7 ? | 12:39 |
| rtg | git log --pretty=oneline v3.13..HEAD -- drivers/input/tablet/wacom* drivers/hid/hid-wacom.c drivers/input/touchscreen/wacom* | 12:40 |
| jtn | rtg: hang on, I'll see if I recognise those | 12:40 |
| * jtn refreshes his kernel git... grind grind grind... | 12:43 | |
| rtg | jtn, they all apply cleanly | 12:43 |
| rtg | gb | 12:43 |
| jtn | rtg: the log messages look about right (especially b5fd2a3e looks like what I'm interested in) | 12:46 |
| rtg | jtn, ok, gimme a bit to study them and make sure they look good for back porting | 12:46 |
| jtn | rtg: OK, thanks. (FYI, I can certainly test a new installer image against Intuos hardware, not sure about anything less packaged.) | 12:48 |
| jtn | rtg, (the diff looks about like what I expected too) | 12:48 |
| ogra_ | apw, could it be that the latest touch kernels are missing the ureadahed patches again ? i dont see it started in http://people.canonical.com/~ogra/touch-bootcharts/ | 13:03 |
| rtg | ogra_, are you sure mako ever had it ? | 13:06 |
| ogra_ | rtg, yep, i opened a bug for it and that one got fixed | 13:06 |
| jtn | (afk) | 13:06 |
| ogra_ | Bug 1194127 | 13:07 |
| ubot2 | Launchpad bug 1194127 in linux-manta (Ubuntu Saucy) "ureadahead does not work in current linux-maguro/linux-mako/linux-manta" [High,Fix released] https://launchpad.net/bugs/1194127 | 13:07 |
| === lool- is now known as lool | ||
| rtg | ogra_, that patch is still in the mako kernel: 'UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib()' | 13:08 |
| ogra_ | ok | 13:08 |
| rtg | Ubuntu-mako-3.4.0-4.22 | 13:09 |
| ogra_ | right | 13:09 |
| ogra_ | hmm | 13:09 |
| ogra_ | then i wonder why it doesnt run | 13:09 |
| rtg | yama ? | 13:09 |
| rtg | ogra_, how about this : | 13:11 |
| rtg | 811bb1b343784ead1d31109e62e13b55fe9ccc18 security: allow Yama to be unconditionally stacked | 13:11 |
| rtg | 83595aa667e65243780e4d453b3c4ee561fb0d82 Yama: higher restrictions should block PTRACE_TRACEME | 13:11 |
| rtg | 15b979177a2f77598f0d62c9f1202ec11e0b649c Yama: add additional ptrace scopes | 13:11 |
| rtg | the PTRACE patch looks like a likely candidate | 13:12 |
| * ogra_ googles yama and finds weird stuff | 13:12 | |
| rtg | we could ask jjohansen | 13:12 |
| ogra_ | its either a death god or a yoga thing :P | 13:12 |
| ogra_ | or a restaurant in NY :P | 13:13 |
| rtg | yet another mandatory authenticator (I think) | 13:13 |
| ogra_ | ah | 13:13 |
| ogra_ | yeah, adding kernel to the search helps slightly :) | 13:13 |
| ogra_ | rtg, another thing, could we default to performance governor on all touch kernels ? android forces ondemand later anyway and it might speed up the boot a bit | 13:14 |
| rtg | ogra_, start a bug for it please. assign me or apw so we don't lose it in the noise | 13:15 |
| ogra_ | ok | 13:15 |
| rtg | jtn, wacom patches pushed | 13:16 |
| rtg | ogra_, can you build a kernel with CONFIG_SECURITY_YAMA=n to see if it affects ureadahead ? | 13:20 |
| ogra_ | will try, yeah | 13:21 |
| apw | ogra_, let us know the bug # for that performance thing | 13:46 |
| apw | ogra_, though, if we have the waiting for battery thing, we need to be careful it changes the governor before waiting | 13:46 |
| ogra_ | apw, well, we might set it from userspace so we can check for low battery before forcing performance ... | 13:46 |
| rtg | apw, they may be reconsidering.... | 13:46 |
| ogra_ | still discussiong it | 13:46 |
| apw | heh ... htat | 13:46 |
| === hatch__ is now known as hatch | ||
| rsalveti | ogra_: yeah, I believe we should boot->check battery->enable performance->android->enable ondemand | 14:07 |
| jtn | rtg: excellent, thank you very much! | 14:07 |
| rsalveti | so we don't need to change the default in the kernel side | 14:07 |
| rsalveti | that would also affect recovery afaik | 14:08 |
| rtg | rsalveti, ack | 14:08 |
| ogra_ | yep | 14:08 |
| * apw likes plans with no work in them :) | 14:08 | |
| rtg | apw, I think will still have to deal with YAMA breaking ureadahead | 14:09 |
| apw | if it is that indeed, but would that not break on all including amd64 ? | 14:09 |
| rtg | hard to say | 14:10 |
| dannf | rtg: you bet | 14:10 |
| rtg | ogra_ is gonna test it | 14:10 |
| apw | rtg, the patch is on our master-next branch right? | 14:10 |
| rtg | apw, no - I asked him to build with YAMA=n | 14:11 |
| rtg | oh, you mean the ptrace patch ? | 14:11 |
| apw | yeah i mean the ptrace patch | 14:11 |
| rtg | UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib() (for v3.7+) | 14:11 |
| apw | right that is the hooks, but we have the yama patch you are suspicious of too, so if we have that combo and the ureadahead produces packs, i don't think it can be those | 14:12 |
| apw | rtg, i cirtainly have packs from the last few days when i upgraded, so it works in that combo | 14:13 |
| apw | i wonder if they are even starting it :) | 14:13 |
| rtg | apw, dunno, I was pushing off the legwork on ogra_ :) | 14:15 |
| apw | yeah works for me, suspect it is not that patch though :) | 14:15 |
| rtg | dannf, I just slammed HEAD on that branch with a final packaging build fix for amd64. | 14:15 |
| rtg | am test building it now | 14:16 |
| dannf | i've got an arm64 build going | 14:16 |
| rtg | dannf, it'll likely fail 'cause of missing modules (phy-core) | 14:17 |
| rtg | dannf, do you cross compile ? | 14:17 |
| dannf | no, native | 14:17 |
| rtg | its _way_ faster, isn't it ? | 14:17 |
| jtn | rtg: Wacom> btw, let me know if there's any testing I can usefully do (I'll check out the final beta at end of March in any case) | 14:18 |
| dannf | ccache ftw | 14:19 |
| rtg | jtn, Wednesday's daily ought to have the right kernel. | 14:19 |
| rtg | dannf, I've found that ccache spends moretime computing the hash and reading the object then it took to just compile the file. | 14:20 |
| rtg | at least on tangerine and gomeisa | 14:20 |
| === psivaa_ is now known as psivaa | ||
| dannf | rtg: built fine, other than the missing phy-core. sata/net both work, as does reboot driver | 14:57 |
| rtg | dannf, qemu/kvm ? | 14:57 |
| dannf | rtg: on deck | 14:57 |
| dannf | rtg: successfully booted an ubuntu trusty guest | 15:03 |
| dannf | looks good to me | 15:03 |
| rtg | dannf, ok. are you happy with the patch set then ? | 15:04 |
| rtg | your RTC driver works ? | 15:04 |
| dannf | oh, yeah - need to check rtc | 15:04 |
| rtg | dannf, also, I don't think I have an answer regarding the absence of the PCIe enablement patches. | 15:05 |
| dannf | yep, +1 on the patch set | 15:05 |
| dannf | rtc works, systortc kernel support works | 15:06 |
| dannf | yeah, we'll need to talk more about pci. i'm going to pull in the latest changes into my tree today for testing. another option is the -oldpci patches which are far less intensive, but not a general solution like what's going upstream | 15:07 |
| rtg | dannf, what is the affect of _not_ having the PCIe patches ? | 15:08 |
| dannf | rtg: but i think we can assume it will be needed by users for networking purposes - people that don't use xgene-enet | 15:08 |
| rtg | dannf, I'm not sure I care about that. they'll have to wait for 14.04.2 | 15:09 |
| === cetex_ is now known as cetex | ||
| trem | hi all | 17:21 |
| trem | hi apw, are you available few minutes ? I'll be pleased to talk with you | 17:22 |
| apw | hi | 17:31 |
| === _leb is now known as farfel | ||
| trem | apw: may we talk in private (of course, if you have some free time) | 17:42 |
| trem | ? | 17:42 |
| === farfel is now known as _leb | ||
| === _leb is now known as leb | ||
| === leb is now known as Guest63565 | ||
| === Guest63565 is now known as leb | ||
| infinity | BenC: SRU kernel nag. | 21:28 |
| infinity | zequence: Ditto. | 21:28 |
| ParkerR | I'm using the raring desktop image on my Nexus 7 (updated to Trusty) For about 12 hours now I've been trying to compile a kernel AND keep it at or under 8MB so it will fit in the boot partition. I have gotten it down to 8.82422 MB. Can somebody take a look and maybe provide some tips on how I can get this to fit? | 22:46 |
| ParkerR | http://paste.ubuntu.com/7108652/ | 22:46 |
| ParkerR | "Flashing kernel and initramfs to /dev/mmcblk0p2... /dev/mmcblk0p2: updated is too big for the Boot Image (9252864 vs 8388608 bytes)" | 22:46 |
| ParkerR | Or if that config would even work... the killer is that I want the Tegra DRm module and it HAS to be built in and not as a loadable module | 22:47 |
| ParkerR | *DRM | 22:47 |
| hallyn | apw: stgraber: aufs, feh - bug 1293549 | 22:55 |
| ubot2 | Launchpad bug 1293549 in juju-core "Filesystem mount from lxc template causes filesystem permission breakages" [Critical,Triaged] https://launchpad.net/bugs/1293549 | 22:55 |
| infinity | hallyn: Well, that certainly shouldn't change the permissions on the underlying dir, as that's immutable. | 23:07 |
| infinity | hallyn: But copying up, changing permissions, and using that copy would seem sane. | 23:07 |
| hallyn | infinity: right.. | 23:09 |
| hallyn | overlayfs allows it fwiw | 23:10 |
| infinity | hallyn: So, the same copy-up mechanism that happens on a contents change just needs to trigger on a permissions change, shouldn't be too hard to hunt that down. | 23:10 |
| infinity | Using overlayfs as a benchmark for how union filesystems should behave is probably not the best idea. | 23:12 |
| hallyn | actually cop-up happened, but chown did not | 23:12 |
| hallyn | infinity: same for aufs :) | 23:12 |
| infinity | But in this case, I agree that "rm && mkdir && chown" should behave the same as "chown" from the user POV. | 23:12 |
| infinity | And from the code POV, that would be a copy-up in the latter case, to emulate what the former is doing. | 23:13 |
| hallyn | i need to do a new post on the woes of every option for snapshotted clones | 23:13 |
| infinity | Well, copy-up and chown, obviously. :P | 23:13 |
| hallyn | there is no good one | 23:13 |
| infinity | I still find LVM snapshots to be the least crack-ridden. | 23:13 |
| infinity | They're just also, unfortunately, the hardest to set up. | 23:13 |
| hallyn | yeah the only downside for me for those is that i have to pre-allocate size | 23:13 |
| infinity | Right. | 23:13 |
| hallyn | i'm actually all set up for them, but for doing package builds i don't want to have to spend that much space per snapshot | 23:14 |
| hallyn | of course it's not really taking up the space... | 23:14 |
| hallyn | still may do that | 23:14 |
| hallyn | (gotta rewrite it all this week) | 23:14 |
| infinity | For local package builds, I use aufs backed on tmpfs. | 23:14 |
| stgraber | lvm also doesn't get you updates to the underlay which happen after you create the overlay right? | 23:14 |
| ParkerR | Any idea on how I could wrangle that under 8MB? | 23:14 |
| stgraber | (not that you usually care for that specific feature) | 23:14 |
| infinity | stgraber: Right, LVM is an actual snapshot, so no weird union "look, new files from nowhere!" behaviour. | 23:15 |
| stgraber | I really need to give btrfs another try since it'd give me the same thing as LVM snapshots but doing it at the fs layer instead, so no size limitation and a bit more flexibility | 23:15 |
| hallyn | regular lvm also is limited to depth of 1 | 23:15 |
| infinity | And, indeed, btrfs should also provide the same level of awesome, but I still don't trust it further than I can throw an s/390 mainframe. | 23:16 |
| hallyn | stgraber: fsync is now much faster than in 3.2, but still not quite fast enough for me | 23:16 |
| hallyn | infinity: it hasn't failed me in months of using it for all my containers. just horrible fsync. | 23:16 |
| hallyn | all my tests and package builds have been using btrfs snapshots | 23:17 |
| hallyn | dafuq - init-generate coredump in my aufs delta0 directory | 23:17 |
| stgraber | hallyn: yeah, my last try was 3.2 and that was dreadful (and getting much worse over time), I need to check whether it'd be reasonable to use for my LXC containers and maybe for my home partition. My laptop's rootfs I intend to keep on ext4 for quite a while still (though having upgrade rollback would be kinda neat) | 23:17 |
| infinity | hallyn: Well, I look forward to a day where it can maybe become a sane default. Being able to code high level distro features on top (like restore points^W^Wupgrade rollback) would be great. | 23:18 |
| hallyn | haha yeah, i'm using a 100G lvm partition for btrfs containers, mounted at /opt/lxc. rootfs? no way :) | 23:18 |
| hallyn | we've been looking forward to that since at least 2009 :) | 23:19 |
| infinity | btrfs on lvm? How meta. | 23:19 |
| stgraber | infinity: I actually never had or directly heard of actual dataloss with btrfs, the usual problem is performance and lack of tooling. The alternative is zfs-on-linux but I'm not too sure which I prefer... zfs is supposed to be a lot more stable, but it's a mostly unsupported dkms module with crazy license issues. btrfs is mainline but not really production ready... | 23:19 |
| hallyn | stgraber: no, i used to lose all data the moment i did a subvolume clone | 23:19 |
| hallyn | up to like a year ago | 23:19 |
| infinity | stgraber: I'm not hugely concerned about the ZFS license issues, I'm very concerned that I don't think anyone actually abuses it on Linux much. | 23:19 |
| infinity | stgraber: And saying "well, it works great on Solaris" doesn't mean a bunch. | 23:19 |
| hallyn | get that Tamas guy in here :) he keeps yelling me about zfs | 23:20 |
| stgraber | infinity: I know a bunch of HPC people using ZFS on Linux in production for a couple of years now (with crazy pools doing an insance amount of iops) | 23:20 |
| infinity | stgraber: Potentially comforting. | 23:20 |
| hallyn | stgraber: the kernel module, not fuse i assume? | 23:20 |
| infinity | I still suspect btrfs is the way forward for Linux. | 23:20 |
| infinity | Eventually. | 23:20 |
| stgraber | hallyn: right, the kernel module | 23:20 |
| infinity | If I hear that Tso has given up the fight for the One True Filesystem and started lending his expertise and time to btrfs, that would maybe sway me. | 23:21 |
| mjg59 | infinity: In which direction? :p | 23:22 |
| stgraber | the other problem with zfs is that 32bit support isn't really a priority, so everyone uses it on 64bit. I kind of like all my machines to use the same setup, and I'm not sure I want to be beta testing zfs on 32bit :) | 23:22 |
| infinity | mjg59: Yes. | 23:22 |
| * infinity discovers that the best way to melt an accidentally-frozen 1.5L block of tomato juice is to add 375mL of | 23:25 | |
| infinity | ... vodka, and declares today a success. | 23:25 |
| xnox | infinity: it must be spring in canada. | 23:27 |
| infinity | xnox: Well, yes, and because it's Canada, it's clamato juice, not tomato juice, but no one else knows what that is, so I translated. | 23:31 |
| hallyn | xnox: say, are you what one might call a current maintainer on libnih? | 23:34 |
| hallyn | ("muhahaha") | 23:34 |
| xnox | hallyn: perhaps. | 23:35 |
| hallyn | xnox: i'm trying to figure out why multiple threads, each opening and using their own separate nih-dbus connection, occasionally seem to get memory corruptoin or segvs | 23:36 |
| hallyn | every time the backtrace is different... | 23:36 |
| hallyn | i.e. http://paste.ubuntu.com/7111193/ is a few of the backtraces | 23:36 |
| hallyn | (source is at git://github.com/cgmanager/cgmanager file tests/cgm-concurrent.c) | 23:37 |
| hallyn | my first question is: am i doing something obviously wrong in how i'm opening the conection in that file? | 23:37 |
| hallyn | near as i can tell, libdbus should at this point be reasonably thread-safe (since 2011) | 23:38 |
| xnox | libnih is not thread safe, unless threading compile time option is enabled (i think) | 23:39 |
| xnox | and we don't enable that by default, let me check. | 23:39 |
| xnox | but your test-case seems reasonable. | 23:39 |
| hallyn | we don't? d'oh! | 23:41 |
| hallyn | all i see in configure.ac is a call to NIH_C_THREAD whatever tht means | 23:42 |
| xnox | hallyn: yeah, "threads are evil" is the general mantra and "upstart doesn't need them" apart from like starting to do async spawn et al. | 23:42 |
| xnox | see m4/libnih.m4 | 23:42 |
| xnox | AS_HELP_STRING([--enable-threading], | 23:43 |
| xnox | [Enable support for multi-threading]), | 23:43 |
| xnox | hallyn: recompile libnih with that enabled, install and see if that helps. | 23:43 |
| xnox | we can provide it as a separate package/library i guess... | 23:43 |
| hallyn | do we disable that for performance reasons? | 23:43 |
| hallyn | i mean, just bc it's enabled in libnih wouldn't mean upstart has to use threads :) | 23:44 |
| xnox | hallyn: no idea. True that. I see that in mainc and error.c it does reference things with __thread for e.g. context_stacks and exit_status /loops. | 23:44 |
| xnox | hallyn: recompile libnih and see if that helps your test-case at all. | 23:44 |
| hallyn | xnox: thanks! i'll do that and proceed from there (talk to jodh and yourself i guess) | 23:45 |
| miseria | "un maniatico destruye lo que el mecanico no puede arreglar, como ejemplo tenemos el calentamiento global" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival* | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!