[09:29] persia: Wow flags: OC in /usr/share/binfmts/qemu-arm [09:30] but flags: in /proc [09:30] Pff someone typo-ed that [09:36] persia: Just after fixing flags, it works [09:36] persia: I can sudo [09:37] No change needed to qemu [09:40] Heh. It takes a night's sleep to try the obvious :) [11:00] persia: LP #519228 [11:00] Launchpad bug 519228 in binfmt-support (Ubuntu) "Support for C flag (affects: 1)" [Undecided,New] https://launchpad.net/bugs/519228 [11:01] I saw the discussion in -devel. Looks promising :) [11:01] * persia presses the "me too" button [11:01] (works here) [11:03] sudo worked for me yesterday btw ... i only had a hostname not found warning [11:05] ogra: OK. Were you root at the time? Based on the docs I read 12 hours back, it couldn't have worked. [11:06] Because all setuid bits are being dropped by the binfmt_misc handler. [11:07] * persia notes that opening a chroot whilst not being root can be tricky [11:09] persia, i have to be root to chroot :) [11:09] well, i usually dont use fakechroot or fakeroot :) [11:09] * persia uses schroot [11:09] ah, right [11:10] The other option is to do something like sudo to some unprivileged user inside the chroot. [11:10] whoops, i just dropped off the canonical server [11:11] hmm, and LP doesnt respond [11:11] heh, that just looked like a loose cable in the DC ... all back :) [11:21] ogra: Try su - someuser in your chroot, and then sudo something [11:21] It wont work [11:21] See above bug [11:23] yes, i just read it [11:23] lool, btw, do you see something like http://paste.ubuntu.com/371902/ trying to start any gtk apps in qemu ? [11:24] ogra: Did you file a bug? [11:24] I didn't try running gtk+ apps [11:25] not yet, i was researching oem-config and ran into it ... wanted to see if its only me or a missing dep in my minimal setup rootfs [11:26] Would anybody be interested in doing the reverse of the cleanup I did to the qemu versatile config? [11:27] the reverse ? [11:27] Basically there are some configs which I turned on and ended up being armel specific (or versatile specific; it's the same) but are useless and should be turned off again [11:27] To minimize delta with other Ubuntu configs [11:27] For instance CONFIG_MTD doesn't actually work with qemu/versatile, so could be turned off to reduce delta [11:27] * ogra doesnt really care as long as there are no lockups or other bad breakage [11:28] Flags in debian.master/configs/armel/flavour.versatile should be examined [11:28] and i'm sure the kernel team wont care either unless they actually get a patch [11:29] if something gets in my way i'll research the issue and make a change, but if its just a silent delta i'm really not concerned [11:32] lool, i'm currently more worried about the glibc failure i have seen and start to suspect its caused by the v7 hack we use [11:33] since it only fakes the v7 CPU but doesnt actually add the features cpuinfo exposes (i.e. neon) [11:33] (not that i have run any neon capable apps, but you know what i mean i guess) [11:39] cpuinfo doesn't matter for neon [11:52] I just got the double free (fasttop) error when installing packages [11:52] It's not specific to gtk+ apps [11:53] It was during the ldconfig trigger [11:55] startx segfaults in Xorg here [12:04] I also get it with gtk-demo in Xorg [12:08] startx works for me if i just use xterm [12:08] as soon as i use a toolkit it breaks, plain X seems to work [12:08] I get a segfault when Xorg quits [12:08] yay, imx51 with populate_rootfs \o/ [12:08] Try running startx, leaving your session; do you have a segfault in /var/log/Xorg.0.log? [12:08] * ogra hugs ApOgEE__ [12:09] opps [12:09] apw i meant :P [12:09] ogra, ? [12:09] lool, only if i use toolkit based apps [12:09] ogra, thank me if it boots for you [12:09] apw, yay, imx51 with populate_rootfs \o/ [12:09] i will as soon as i can get it from the archive :) [12:10] heh, lets hope it builds in there :) [12:10] wow, that changelog looks like someone nearly rewrote ext4 :) [12:11] heheh [12:11] lool, i have no segfault with an .xsession that just contains xterm [12:12] apw: This is boot speedup work for imx51? [12:12] lool, for ubuntu in general [12:13] Oh and it was borken on imx51? [12:13] it just didnt make it in yet [12:13] its a rebase for security and stable updates, plus a couple of patches from brian for performance [12:13] (boot performance) [12:13] we try to get all the sweetness from our mainline kernel backported now that the patches dont create any hassle [12:14] lool, the fsl patchset just applied smoothly this time so we actually have time for kernel improvements which we try pull in as many as we can from the ubuntu kernel [12:14] dunno if you will gain anything with such cpu limited platforms, i assume brian tested it and measured it before asking for it [12:14] no weird forward porting makes everything so much easier [12:15] shame they still frig about in usb, and then wonder why usb drives fail to work properly [12:15] well, the devtmpfs backport surely gained us a lot already [12:16] so i'm suspecting the populate_rootfs stuff will too [12:16] ogra, 'surley' ... i am guessing noone tested [12:16] ogra, in my experience its not a gain if you only have 1 cpu [12:16] i did and see 2-3 sec speedup [12:16] apw: Note that there exists Ubuntu-compatible hardware for other architectures with even less CPU performance than most available ARMv7 hardware. [12:16] persia, indeed, but we are not targetting any specific performance for them [12:16] are you talking celeron without L2 cache ? :) [12:17] * ogra has such a thing and its slower than my babbage board [12:17] apw: I did test devtmpfs with 2.6.32 kernels in qemu, and I can say the MAKEDEV was taking more than 5 seconds in qemu [12:17] apw: BTW, there are further MAKEDEVs on startup ATM, perhaps we could add more devices to devtmpfs and avoid one more call? [12:18] saved about .2s on a real machine as i recall [12:18] apw: /etc/init/mounted-dev.conf still calls /sbin/MAKEDEV fd in all cases [12:18] ogra: That would be but one example of a large class :) [12:18] i dont think it was produced in large amounts actually [12:18] apw: Also, I wonder whether we could avoid remounting devtmpfs on top of devtmpfs; that's probably not very long, but still... [12:19] keybuk deals with all that side, i thought all devices were made which were registered in the kernel [12:24] I get the glibc corruption with a minimal gtk+ program which does gtk_window_new + widget_show_all + gtk_main, but not without the window [12:26] Setting MALLOC_CHECK_=0 I can actually run the app [13:18] ericm_: -meeting? [13:25] ogra: I definitely get the segfault when exiting from xterm [13:26] "startx" startx an xterm, I ^D and I get a segfault [13:26] hmm, i didnt have one yesterday [13:54] dmart: Hey [13:54] dmart: I have this glibc errors which ogra mentionned [13:55] dmart: I wrote a trivial gtk program which reproduces these [13:55] and it aborts but, the backtrace is either useless or useless [13:55] dmart: I've installed our -dbgsym packages for libc6, libx11-6, gtk, pango, and cairo [13:55] I even got a gdb segfault at some point, but not consistently [13:55] dmart: How would I track this down? [13:56] I can break on main() in gdb, but when I get the actual abort, it's somewhere down the gtk internals, and it's hard to break on that [13:58] Ah! G_SLICE=always-malloc also fixes the bug [13:58] So it's either a bug in glib'c gslice support on armel, or in glibc's memory checks on armel [14:00] Add some trace I guess, if you can't get a backtrace from the segfault/abort. [14:00] What do you mean by add some trace? [14:00] Don't really have bright ideas here I'm afraid [14:00] dmart: Do you find gdb useful on armel these days? [14:00] It frequently crashes for me [14:01] Which version are you using? lucid's gdb seems a lot more stable than karmic's gdb, but maybe I was lucky. [14:01] lucid's latest [14:01] 7.0 helped, but it's still crashy and frequently fails finding backtrace [14:01] In this case, I get either a corrupted backtrace or an infinite loop [14:02] hmmm, is there any way you can reproduce the crash? I often get no backtrace though. I wondering whether some components are built in a way which nukes the backtrace; or maybe there's some broken unwind info support in gdb. [14:03] The crash only happened one time out of 6 or so, but perhaps I will be able to reproduce it [14:03] I suspect the versatile kernel under qemu might be having some issues of its own which don't help gdb [14:03] Maybe you can catch it with nested gdb [14:04] dmart: So you gdb gdb? [14:04] I'm sure I've managed to do this in the past. gdb has special support for this. [14:05] Ok; never tride this [14:07] A simple g_slice checks works [14:07] Folks, the glib atomics patch was removed in january [14:08] Hmmm, maybe we need it back in? [14:09] I suspect we do, that might explain my issue [14:09] Anyway why it was pulled out? [14:09] Is https://bugs.launchpad.net/bugs/491342 the correct reference? [14:09] Launchpad bug 491342 in glib2.0 (Ubuntu) (and 1 other project) "assembly fails to build on armel/lucid (affects: 1)" [Critical,Fix released] [14:09] * debian/patches/70_glib2.0-gatomic-arm.patch: [14:09] - dropped since that patch was added without details nor reference [14:09] to a launchpad or upstream bug and it's not clear if it's still required [14:09] now with the change done upstream recently [14:10] Seb, who removed the patch, had fixed it when syncing 2.23.1-1 over: [14:10] * debian/patches/70_glib2.0-gatomic-arm.patch: [14:10] - change to fix the build for armel [14:10] If the change is upstream, it shouldn't be needed; maybe take a look at the patch and make sure the relevant changes are in the code? [14:11] Yes; glib wouldn't build without it, would it? [14:11] Probably not... it was a swp issue [14:11] It built on armel [14:12] https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491342 was forwarded at https://bugzilla.gnome.org/show_bug.cgi?id=603780 [14:12] Launchpad bug 491342 in glib2.0 (Ubuntu) (and 1 other project) "assembly fails to build on armel/lucid (affects: 1)" [Critical,Fix released] [14:12] Which points at https://bugzilla.gnome.org/show_bug.cgi?id=531902 which is closed [14:12] Gnome bug 531902 in general "Use GCC atomic buildins for g_atomic*" [Enhancement,Resolved: fixed] [14:12] Bug 531902 - Use GCC atomic buildins for g_atomic* [14:12] Summary: Use GCC atomic buildins for g_atomic* [14:12] lool: Error: Bug #531902 not found. [14:12] * persia pets ubot4 for trying [14:12] :) [14:13] Looks like it was fixed upstream, so long as ubuntu's package is now based on the new enough version. [14:13] It's merged in out glib2.0 ubuntu package [14:13] checking whether to use assembler code for atomic operations... checking whether GCC supports build-in atomic intrinsics... yes [14:13] looks good [14:14] Perhaps your problems are caused by something else... [14:14] * dmart has do disappear for a bit [14:14] * dmart also can't spell [14:15] I looked at the testsuite, there is one failure trying to create files in the non-writable home, another one on threadpool-test [14:15] and there might be more since it doesn't complete [14:16] slice-test does pass though [14:16] So it could also be a gtk+ issue [14:17] In gtk+, the only failing test is abicheck; again the testsuite might not be running all tests [14:30] lool, it couls also be a codesourcery issue, lets wait for the actual archive build of versatile [14:31] * ogra still thinks its kernel related [14:33] I have the same issues with my own cross-gcc [14:33] Which is based on a relatively recent FSF tree [14:33] hmm [14:35] Hmm it's not the same error as with ldconfig [14:35] ldconfig was on fasttop, gtk+ is on !prev [14:36] lets be patient and see what an in-archive kernel brings us :) [14:40] There's an experimental-malloc in eglibc which takes another code path [14:43] MALLOC_CHECK_=0 G_SLICE=debug-blocks doesn't catch the error [14:54] Ah slice-test actually fail under my kernel [14:54] dmart, ogra: Could one of you try on real hardware with lucid userspace? [14:54] To check whether it's a toolchain or kernel regression [14:55] lool, i have no issues at all on imx51 [14:55] since weeks [14:55] just build slice-test from glib2.0 [14:55] i'm not sure i can get to that today but will do so if nobody else does [14:55] my babbage is fully swamped today === 18VAACOTE is now known as Meizirkki [14:56] I'll have a go... what's the easiest way to build just the affected test? [14:56] dmart: unpack memchunks.c and slice-test.c from glib2.0's tests/ [14:57] dmart: And then basically gcc `pkg-config --cflags glib-2.0 gthread-2.0` -c memchunks.c [14:57] dmart: And then basically gcc `pkg-config --cflags glib-2.0 gthread-2.0` -c slice-test.c [14:57] dmart: And then basically gcc -o slice-test *.o `pkg-config --libs glib-2.0 gthread-2.0` [14:57] (Sorry for the noise) [14:58] So ./slice-test 1 c 100 works and ./slice-test 1 c 1000 fails [14:58] ok, I'll let you know what happens. [14:58] It works up to 512 and fails starting at 513 [14:58] dmart, ogra: What's the kernel memory allocator on your kernel? [14:59] It's SLAB on versatile [14:59] I think ARM requires SLAB anyway [15:00] /boot/config.blah says CONFIG_SLUB=y [15:01] yeah [15:01] dunno whether that's better though [15:08] dmart: There was a recent post of slab versus slub on kernel-team@lists.ubuntu.com [15:08] I don't know whether it's better or worse, but I care that it works or not :-) [15:08] versatile_defconfig has SLAB=y instead [15:09] lpia, i386, amd64 and ports have SLUB=y; pretty much only versatile has SLAB=y [15:09] * dmart is still updating his fs [15:10] The versatile is probably derived from the ARM kernel trees, which tend to use a more traditional/embedded style config (for whatever reason) [15:10] * lool tries turning on SLUB [15:12] Ok; that worked, let's see if I can build a working kernel with it [15:23] it built, but for some reason I'm missing disk drivers; /me tries again === asac_ is now known as asac [15:35] So it still fails [15:35] I have CONFIG_SLUB=y [15:36] Same symptoms [15:37] dmart: Did you manage to test on real hardware? [15:40] not yet... trying to do too many things at the same time... [15:41] argh, more update problems [15:41] What's the issue? [15:42] ricing [15:42] Any idea what's causing the contents of the archive to be broken at the moment? I get a load of conflicts [15:42] dmart: I don't have that [15:42] dmart: Perhaps some packages you have are missing on armel; I have a minimal chroot [15:42] mono [15:43] Yeah I was about to mention it [15:43] Currently mono-runtime is older than mono-gac [15:43] mono breaks the world and the desktop team made half the world depend on it [15:43] So you can't install mono or ubuntnu-desktop [15:43] so lots of stuff is outdated [15:43] asac, is working on the mono ftbfs [15:43] Hmm, I didn't even find that among the conflicts. But trying to install/upgrade ubuntu-desktop is certainly broken right now. [15:43] right [15:44] laincpad-integration and all the indicator- stuff are broken [15:44] anything that uses either will likely fail to install [15:44] Is that really all caused by mono? [15:44] yes [15:44] argh [15:44] most of the indicator bits hard depend on mono now [15:45] Oddly it took 2 hours to build in karmic and has been building since 3 hours in lucid [15:45] as well as LP-integration [15:45] Looks like the build hanged in configure [15:46] oh, and nautilus depends on mono as well now [15:46] mono is a mess [15:46] it opens zillions of files ... but only on arm [15:46] asac: Does the buildd output looks normal to you? [15:46] lool, forget about the buildd :) [15:46] ogra: ? [15:46] lool: what do you mean? [15:46] for now we'd be happy to be able to build on sane HW we have full access to [15:46] lool: i tried it locally and found that we hit the 1024 open files barrier [15:46] asac: https://launchpad.net/ubuntu/+source/mono/2.4.3+dfsg-1ubuntu1/+build/1477421 [15:47] lool: no. that doesnt look normal [15:47] lool, looks like a won't have time to try and reproduce your issues right now [15:47] and isnt what usually happened [15:47] dmart: Ok; thanks [15:47] I'd love to know whether this is kernel specific or not [15:47] sorry [15:47] * ogra smells one of the regular buildd segfaults [15:47] yeah [15:47] Perhaps someone else could try it on real hardware with up to date lucid?> [15:48] asac, you gave it back today, didnt you ? [15:48] i tried it on real hardare [15:48] same issue ... open files barrier [15:48] i am now going to debug that [15:48] asac, i think lool means the qemu issue [15:48] unfortunately i trashed the build tree [15:48] asac: Did you complete a build after bumping the open file limit? [15:48] oh [15:48] sorry [15:48] lool: no it failed later on jocote [15:48] Yeah, I have an issue with glib under qemu [15:48] havent tried to finish it here ... [15:48] asac: Ah so no mono anytime soon [15:49] I wanted to look into the double binfmt issue [15:49] will do that after confirming for the mono guy which mono it is [15:49] which files are kept open [15:49] config.status: creating mono/arch/s390x/Makefile [15:49] make: *** wait: No child processes. Stop. [15:49] make: *** Waiting for unfinished jobs.... [15:49] make: *** wait: No child processes. Stop. [15:49] Session terminated, killing shell... ...killed. [15:50] yes, we see frequent random segfaults on the buildds since a while [15:50] thats not the real issue. most likely just random buildd bustage as ogra said [15:54] ogra: Is there a bug about the mono-runtime binfmt format that doesn't work with qemu? [15:55] no, there are plenty in debian i think [15:55] they all point to syscall 242 though which is nonsense [15:56] get_sched_affinity() [15:57] ogra: could you file a launchpad bug? [15:57] lool, i filed the one on the possible use of binfmt_ vs non binfmt_ [15:57] What is that? [15:57] * ogra cant remember the number [15:57] lool, bug 427863 [15:57] Launchpad bug 427863 in linux (Ubuntu) (and 1 other project) "binfmt allows breaking out of chroots due to not respecting namespaces (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/427863 [15:58] ogra: That one is blocked on information on your side [15:58] Upstream and Kees both asked you for more info [15:58] which i dont really have time for to gather atm [15:58] Since September? [15:58] yes [16:12] dmart, btw, do you use update-manager ? my upgrade works fine here just removes some stuff i'd rather keep, but still [16:13] No, that was via apt-get dist-upgrade. I should probably switch to apt-get upgrade so it doesn't unexpectedly uninstall half the system :P [16:13] you are not using netbook yet i guess [16:14] for me only two indicators, rhythmbox, nautilus and the netboot-meta package are removed [16:14] stuff i can live with until it comes back [16:17] Gah karmic userspace doesn't boot with devtmpfs [16:18] This so sucks [16:18] iirc the problem with mono in qemu is that it uses boehm gc which reads /proc/self/maps [16:18] suihkulokki: that's a good point [16:18] suihkulokki: Do you have any clue on the slice-test issues I have (see above) [16:19] It's under qemu-system-arm with a versatile kernel, not qemu-arm-static [16:19] havent seen any such issues [16:19] suihkulokki: You can run gtk+ apps fine under qemu-system-arm/versatile? [16:20] well, haven't tried versatile for ages [16:20] You're using OMAP? [16:20] but on omap2/omap3 no problems with our gtk [16:20] is omap stable already ? [16:21] yeah, I've been tempted to switch to OMAP kernels for qemu [16:21] suihkulokki: So which tree do you use to run qemu/omap? plain upstream, or do you need linux-omap for qemu too? [16:21] is there enough in upstream to make use of it for qemu ? [16:23] so far I've just used linux-omap kernels. [16:23] suihkulokki: You're using the maemo OMAP3 qemu support? [16:23] sad, no distro option for us atm [16:24] I see some commits from you, so I guess you do :) [16:24] You probably develop it too [16:25] yep [16:26] ogra: ...didn't stop you from shipping mx51 and dove kernels ? [16:27] suihkulokki, no, but for other arm stuff we can only refer to mainline, for these two arches the kernel team made explicit exceptions [16:28] s/arches/subarches/ :) [16:30] Does mainline linux-omap work on qemu cleanly? Might be easier to align, rather than chasing -versatile. [17:10] * ogra files bug 519398 [17:10] Launchpad bug 519398 in oem-config (Ubuntu) "oem-config with debconf frontent goes into endless loop (affects: 1)" [Undecided,New] https://launchpad.net/bugs/519398 [17:11] finally some progress ... [17:11] seems its actually an oem-config bug [17:11] phew [17:15] Can you replicate with a normal desktop install, or does it only happen with rootstock? [17:15] no idea, i wont do any normal desktop install atm [17:15] since i a) dont have a spare desktop machine to test on and b) it takes extra time :) [17:16] * ogra wonders why others sponsor fixes to rootstock ... why dont file people bugs so i can sponsor it :P [17:18] persia, though given that the debconf frontend isnt used on desktops it would have to ba a server install i guess [17:18] *be [17:19] Does -server support oem-config? [17:19] yes [17:19] Aha. Make them do the testing on !armel :) [17:19] you can do oem server installs nowadays apparently [17:19] how without HW and broken qemu ? [17:20] i guess they are using it very rarely :) [17:20] probably even only testing it on x86 for milestones [17:22] * ogra cant belive there is a thread in ubuntu-users about /bin/flase being to big [17:22] I thought they had working kvm. [17:22] *false [17:22] heh :) [17:23] its like 50 mails already [17:23] nearly beats the "OMG OO.o was dropped by canonical" one [17:28] rm / [17:28] oops [17:32] Um, did you really mean to run that locally? [17:32] That command is usually followed by a ping timeout [17:34] heh, no i hit tab and was on an SD card subdir in another term :) [18:02] haha [18:02] the slice-test issue doesn't affect karmic [18:02] So it's either a toolchain regression or a qemu bug with thumb2 [18:02] suihkulokki: ^ :) [18:02] suihkulokki: BTW do you use thumb2? [18:03] I know you use NEON heavily, but I'm not sure you went through the thumb2 pain yet [18:25] It's eglibc [18:25] Well upgrading it breaks things at least [18:27] funny that we dont see it on real HW [18:28] It might be a bug in qemu or linux/versatile with thumb2 [18:28] yeah [18:28] i find versatile most likely [18:28] we just patch the CPU naming but nothing of the instruction set at all [18:29] anyway, break before the call [19:20] there isn't a thermal sensor on the beagle is there? [19:20] use your thumb ? [19:20] :) [19:20] I can't log my thumb :p [19:23] also, when setting mpurate=720, how does one also bump the voltage, or is the recommendation to do that obsolete? [20:02] Hey, I'm looking for vendors who produce high-performance ARM CPUs for use with Linux... who's out there? [20:02] like, ti? [20:02] therealgalen: depends on what you consider high performance to be. everything is relative. [20:02] freescale, marvell, qualcomm [20:03] I'll get clearer [20:06] I'm looking for ARM CPUs with PCI-Express support. Examples: Marvell 88F6282 (1.6-2 GHz), Marvell MV78200 (800 MHz - 1 GHz dual core), Cavium Networks CNS3420-700 (700 MHz dual core) [20:07] ojn, ogra, cwillu_at_work: does that give you a better idea the performance range I am looking at? [20:08] therealgalen: Marvell is the only provider with pci-express solutions to date, I think. most others are targeting mobile devices where there's less need for high-performance interconnects. [20:08] ojn: Cavium has PCI Express too [20:08] I'm trying to find if there are any others [20:08] Cavium makes ARM processors? I thought they were mips [20:08] Without wading through the 300+ ARM licensees [20:08] * ogra has only seen marvell boards with PCI [20:09] ogra: dove has pci-e [20:09] and i'm not even sure these ones were PCIe [20:09] hey, a few starting points are better than 300+ :) [20:09] ojn: what is dove? [20:09] therealgalen: if PCI-e is a hard requirement, and ARM is a soft requirement, take a look at Freescale's PPC offerings as well. [20:10] therealgalen: The eval board for marvell's armv7 chip [20:10] ah [20:10] ojn: is it at all price competitive? [20:11] therealgalen: I have no idea where any of the vendors price their parts [20:11] the CNS3420-700 costs like $17/unit in 1k quantities [20:11] * cwillu_at_work should stop asking beagle specific questions in #ubuntu-arm [20:12] ogra's tongue-in-cheek response makes sense now :) [20:13] man, powerpc... [20:13] a blast from the bast [20:13] *past [20:13] cwillu_at_work, nah, there are ,many people using our userspace on beagle :) [20:14] ogra, I know, I'm one of them :p [20:14] I just didn't realize I was in this channel: I don't expect hardware questions to get good answers here :p [20:15] i'll just take whatever i can find, haha [20:15] cwillu_at_work, pfft [20:15] ogra, you told me to use my thumb when I asked about the thermal monitor :p [20:17] well its a reliable methot to measure ... at least in the blister/no blister area of precision ;) [20:17] *method [20:22] cwillu_at_work, but you are right, i could tell you more about imx51 than omap currently my beagle B3 is sitting on the shelf collecting dust [21:10] ojn: freescale's CPUs are very expensive! [21:10] at least the PPC line [21:47] ogra: Did you ever find a good way to suppress the extensive "qemu: Ubsupported syscall:" lines? [22:42] persia: Implement them? :) [22:44] lool: Well, that works too. ogra was talking at some point about some way to collect them and report each one only once or something.