=== fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta === bjf is now known as bjf[afk] === fta_ is now known as fta [07:45] zumbi: the story is over, Linus pulled :-) === fta_ is now known as fta === hrw|gone is now known as hrw [08:30] morning [08:31] cooloney, urgh, please ship vmlinuz in the linux packages [08:32] we use flash-kernel on all arm platforms to do special stuff to the binaries (i.e. running mkimage to create uImage) [08:32] i dont want to special case flash-kernel for certain platforms [08:33] cooloney, we need to create uInitrd anyway on each update-initramfs trigger so it makes no sense to ship uImage in the package (and we had that discussion before several times) [08:35] * cooloney nods to ogra [08:35] ogra: great, understand. [08:37] :) === amitk-afk is now known as amitk [09:13] mythripk: Hi [09:26] Hello, I created a rootfs using this command sudo rootstock --fqdn qemu-test --login qemu --password qemu -d karmic --notarball, I compiled a kernel in the standard way (make, make modules, make zImage) and try this command sudo qemu-system-arm -M versatipb -cpu arm11mpcore -kernel ./zImage -hda qemu-armel-201007121813.img -m 256 -append "root=/dev/sda rootwait", but I got just a black screen. [09:26] thanks in advanced for any comment about this. [09:27] other thing is : is this the right way to cross compile my kernel ? make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- [09:27] thanks again in advanced [09:27] if you got a binary thats likely the right way :) [09:27] i would suspect you are missing some console settings [09:28] fjrivash: Which board are you using? [09:28] ogra, I got it after make zImage [09:28] try with -nographic [09:28] (on the qemu cmdline) [09:28] that should at least show some kernel messages [09:29] lag, a CNS3410 (it is an arm11mpcore which is compatible with armv6kz) [09:29] ogra, thanks I will try it right now [09:30] (note that you cant ctrl-c qemu then, you need to close the terminal to stop it) [09:30] or kill it from another term [09:30] jejejeje I see! it was so funny, I thought that was something else bad [09:31] Well done ogra [09:31] ogra, I got nothing :S. it think it must be the kernel [09:31] I take it back ;) [09:32] Does qemu not have pre-boot messages [09:33] Similar to a bootloader? [09:33] actually yesterday I built a new image using karmic. lag AFAIK you must install a bootloader if you want to use it to load a kernel image [09:33] Do you need one? [09:34] Or will qemu be the bootloader too? [09:34] well to be honest I trying to avoid that. but it seems that I need one, for example u-boot [09:35] Ask ogra [09:35] ogra: Do you need a bootloader when you use qemu? [09:35] lag thank you very much. :D [09:35] lag, nope [09:35] Okay [09:35] I might install it and have a play [09:36] ogra: coming back to uImage creation - how to make update-initramfs generate the uImage? Is there a script to update in the kernel package or somewhere else? [09:36] lag, i think you *can* use a bootloader ... i think lool does that in his qemu-maemo experiments, but specifying the kernel should be enough to get a booting system [09:36] sebjan, flash-kernel does it [09:36] sebjan, have a look at update-initramfs and the flash-kernel source [09:37] sebjan, since my last update to flash-kernel that should happen automatically on ubuntu images [09:37] for omap3 and 4 at least [09:38] ogra: it does not for our omap4 kernel packages at least, this is why I came up with this dirty hack :) [09:38] ogra, lag thank you very much I will recompile the kernel because I think that is the problem, I will let you know [09:39] sebjan, flash-kernel requires /etc/flash-kernel.conf on omap4 (thats created during first boot of the image) [09:40] fjrivash: Where did you get qemu-system-arm from? [09:40] from repositories [09:40] sebjan, and you need at least flash-kernel 2.28ubuntu2 for panda support [09:40] actually I did a qemu-system-arm --cpu ? and there is an arm11mpcore support- [09:41] sebjan, and also a /boot/boot.script file as input for the used boot.scr [09:41] It's not in my repository [09:41] lag, qemu-kvm-extras [09:42] ogra: Thanks [09:42] iirc [09:42] rootstock pulls it in automatically [09:42] together with qemu-arm-static [09:42] for arm chroot handling [09:42] that is right [09:42] ogra: ok, I was far from it :) thanks! Could you please send me an example flash-kernel.conf file? [09:43] sebjan, UBOOT_PART=/dev/mmcblk0p1 [09:43] sebjan, thats all :) [09:44] sebjan, flash-kernel only needs to know where the bootloader partition is (and you need the /boot/boot.script as input) [09:46] * ogra takes a break [09:46] ogra: thanks! [09:46] in which cases do I have to use a ramdisk? [09:47] I mean I have read that you can specify a initrd in qemu command but I am not pretty sure if I need it. [09:48] (figuring out) === XorA|gone is now known as XorA [10:04] lool: Ping [10:06] fjrivash: Did you build the kernel yourself? [10:07] yes [10:07] fjrivash: Do this from the root of your kernel tree: "find . | grep vmlinuz" [10:08] there is no vmlinuz, there is a zImage which is in a boot directory, I am compiling the kernel (again) [10:08] the first time I got a zImage of 40mb [10:08] You must have debugging symbols turned on [10:09] And all your drivers built into the kernel [10:10] fjrivash: Use this: http://www.aurel32.net/info/debian_arm_qemu.php [10:10] And slowly supplement its components for your own [10:10] I've just tried one of my kernels, but it doesn't support omap out of the box [10:11] mm I see. let me check that url. [10:11] mythripk: ping [10:19] yes lag [10:19] Good morning [10:19] Or afternoon where you are [10:19] How are you/ [10:19] ?* [10:20] I found this one http://wiki.debian.org/ArmEabiHowto which is based on that one lag but with new kernel images. [10:20] lag : ya good afternoon, fine thank you , did you see the mail i sent on the code sequence for sysfs and bootargs [10:21] fjrivash: Good. Use that and slowly supplement its components for your own [10:21] mythripk: I did [10:21] mythripk: I am seeing some odd behaviour [10:21] ie ? [10:21] lag thank you very much I am working on it right now, I will let you know. [10:22] lag: pong [10:22] mythripk: When the monitor goes to sleep after a time - when it wakes up, the setting have gone back to fuzzy [10:22] lag: even with the sysfs u mean [10:23] mythripk: So: Boot up -> Fuzzy | Use sysfs -> Good | Sleep-Wakeup -> Fuzzy [10:23] The board is still awake [10:23] It's just the monitor which is put to sleep [10:23] lag: with fuzzy you mean the out of range [10:24] lag: how do you get the display out of sleep , if you set fb black it would not go to sleep [10:27] lag: Ping ping echo "0" > /sys/class/graphics/fb0/blank this command would not suspend the TV . [10:30] mythripk: I get the display out of sleep by pressing the keyboard [10:30] mythripk: Yes, I mean 'out of range' [10:30] Why would I want to do that command? [10:31] lag: even with the out of range block appearing at the centre , you can still see the commands ? [10:31] Yes [10:31] lag: That command will not blank the TV , ie the TV will not go to sleep [10:31] have you tried a different HDMI cable ? [10:31] I didn't use that command [10:31] That cable works fine on my Beagle [10:32] you could use that command in case you dont want the TV to sleep [10:32] We have to put our displays to sleep [10:32] We are an Operating System [10:33] Well a distribution [10:33] that is fine , you need not , that was just in case it was not expected. [10:33] That is not the problem [10:34] The problem is that it does it and it's not meant to [10:34] So needs fixing somehow [10:34] That is not the only odd behaviour [10:35] When you told me to boot with less arguments, it worked perfectly on start-up (with the cmdline args) [10:35] But on a subsistent boot it was 'out of range' again [10:35] With the same settings [10:36] one reason from your log i have seen is that there are too many bootargs and thus hdmimode is not effective , thus it is going to a wrong non desired setting [10:37] But I have reduced the number of bootargs [10:37] And the behaviour is the same [10:37] and now the timing is correctly set? can you pastebin the log since bootargs [10:38] because i dont see this behaviour on viewsonic or samsung TV that i have [10:43] They are not correctly set [10:43] It was, once [10:44] But on subsequent reboots they reverted to incorrect [10:46] ok , I have an RFC for autoboot of HDMI , i will be posting on OMAPPEDIA , that would atleast remove your bootargs problem [10:47] Can I follow that? [10:47] yes , Please [10:48] How? [10:49] lag:I will be putting it on http://omappedia.org/wiki/Display_Drivers_Domain_Wiki [10:49] once i'm done with sanity testing [10:50] lag: Hey you pinged me, I ponged, but then I didn't hear anything anymore? :) === amitk is now known as amitk-afk [10:55] lag: But one confirmation , it is only in your LG make TV you are seeing this issue right , not in any other monitors [10:59] lool: Everything came alive at the same time - can you give me a minute please? [10:59] mythripk: I don't have any other monitors to test [10:59] mythripk: If you want to send me other monitors to test, I'd be more than happy to [11:00] lool: Do you use qemu to boot omap images? [11:13] lag: I do [11:14] lag: They need a bootloader on the images, and that apparently doesn't work with current Ubuntu images, but it should in theory work [11:14] lag: https://launchpad.net/~lool/+archive/ports-dev/+packages has maverick packages of qemu-maemo [11:14] lool: Okay, that explains a lot [11:14] lag: something like qemu-maemo-system-arm -M beagle -m 256 -sd ubuntu.img -serial stdio [11:15] That works more or less with Angstrom ATM, it boots well into the kernel, but then I get some divide by zero in the kernel which I didn't lookinto [11:15] lool, hmm, we had that with the omap kernels too [11:15] (division by zero errors) [11:15] Yes we did [11:15] smells like a kernel prob, not like qemu [11:15] I can't remember what the cause was though? [11:16] * ogra neither [11:16] but i remember some oopses that had such an error in front of them [11:16] I think I had them when I tried to boot the XM with Lucid [11:17] I tried an older Angstrom kernel, I'd be surprized if it had divide by zero errors [11:17] * ogra thinks he saw them together with the ureadahead OOMs too [11:17] Anyway [11:17] First thing with Ubuntu images would be understanding why it doesn't work in qemu-maemo [11:17] Ogra likes to blame everything on the kernel [11:17] It's an easy scapegoat [11:17] indeed :) [11:17] :) [11:17] ogra: Let's just blame everything straight to lag then? [11:18] lool, can only be the bootloader/x-loader [11:18] ogra: it could be the partition layout [11:18] * lag == scapegoat No1 [11:18] lool, else you would at least see u-boot messages [11:18] lool, we use the angstrom script to create our bootloader partition [11:18] lool: fwiw, I've officially sent a request to rejoining Debian, I intend to work on the armelhf -or whatever it's called- in a much more official -or semi-official- way now [11:18] no idea how long it takes, but it won't take as long as a full NM application [11:19] markos_: did you follow linaro-dev discussions? [11:19] (this after reading most mails on linary and debian-arm lists) [11:19] yes [11:19] About NOT doing a new port :-) [11:19] lool, well, the OE script which angstrom uses as well :) [11:19] markos_: I find the discussion very interesting, but I find it a hard sell for the bunch of people interested in working on the port [11:19] still reading, haven't finished yet :) [11:19] markos_: I've personally written to zumbi to tell him I would like to semi-officially work on that port [11:20] as in, with my Debian hat on and on a best effort basis [11:20] but I expect to help as much as I can [11:20] linaro goes debian ? :) [11:20] well [11:21] Sure, we're not tightened to Ubuntu [11:21] we're helping all distros out there if we can and know how to [11:21] * ogra was joking, i know that [11:21] But we're also splitting our time wisely ;-) [11:22] there is nothing to prevents us (Genesi) from working on an unofficial hardfp port just as we are now, with no new port name, because on our cpu (a8), there is a lot to gain and it can give us a competitive advantage -and of course to others that choose to use our repository [11:23] at the very least we can provide testing and patches for packages that fail to build for hardfp [11:23] I'd really hope for a new port though [11:23] it would make things easier -and- provide a new optimized port for newer cpus [11:24] with no new port -regardless of the toolchain changes- it's guaranteed that performance will always be sub-optimal [11:24] other arches don't have such a big problem [11:25] * zumbi confirms lool's wanting to help on Debian port [11:25] eg. on ppc, the abi is the same always, if someone wants more performance they can always install a -altivec version of the package -if available of course [11:25] markos_, depends ... look at ubuntu, we still call what we have "armel" even though its totally not what you get in debian [11:26] lag: I shall send the link to the RFC to solve your bootargs problem , it would do an autodetect , but for your out of range problem i have contacted the hardware and power management folks i shall get back once i get a reply , as it doesnt appear to be a HDMI s/w issue. [11:26] we could as well just default to hardfp [11:26] ogra: debian is upstream, linaro, ubuntu, mint, .. all of them will fork [11:26] since we dont support any of the old CPUs anymore [11:26] zumbi, indeed and its surely the better move to have what we have in ubuntu in our upstream already [11:27] will save us a lot of work [11:27] i'm just pointing out that armel != armel if you look at it today [11:27] mythripk: Thanks, I'll look forward to it [11:27] and to be honest i'm not really lookinf forward to all the script changes we have to do based on a name change [11:28] ogra: yes, that's exactly what I did as well, if I waited for toolchain fixes, I still wouldn't be able to test a single package :) [11:29] 12:19 < ogra> lool, well, the OE script which angstrom uses as well :) [11:29] ogra: thats Ångström script which is stored in OE repository [11:29] ;D [11:30] hrw, heh, well, whatever way you want it around, our boot partition is created the same way :) [11:30] sebjan: ping [11:30] so it cant be poartitioning imho [11:30] -o [11:30] ogra: so do you suggest 3 different "armel" flavours: debian, ubuntu and genesi's [11:31] zumbi: if ubuntu decides to go hardfp themselves, there would be need for only 2 [11:31] zumbi, no, the opposite [11:31] ogra, ok, i misunderstood :) [11:31] zumbi, if hardfp shows up in debian (and also uses our current defaults v7 etc) it would be the logical choice for me to switch ubuntu over [11:32] zumbi, i'm just fearing all the script changes for scripts that look at $arch+$subarch we currently use in ubuntu [11:32] markos_: The point Mark is making is that they are other ways to rip (most?) of the benefit of hardfp, a new port adds permanent fragmentation though [11:32] ogra: but ubuntu will keep maintaining two different armel ports? or just one? [11:33] zumbi, preferably just one optiomized for cortex-a8 and bigger [11:33] markos_: Costs such as doing the validation twice, or costs such as for ISVs trying to provide binaries are quite high [11:33] zumbi, thats what our current armel already is [11:33] markos_: Consider that we don't have a flash plugin for 64-bits after all this time [11:33] zumbi, for me it would just be a name change plus a different fpu [11:33] lool: I don't see that as necessarily a bad thing, why should a router developer care for neon optimizations or vfp stuff that a desktop distro developer would insist upon? [11:33] markos_: flash might just land on arm soon, and now we will require two versions? [11:33] and vice versa [11:34] markos_: Fragmentation [11:34] markos_: You might release an android phone build on vfp or non-vfp hardware [11:34] suddenly, you have to use a different stack [11:34] and people have to provide different native builds [11:34] lool: by the time it arrives, lightspark might work on arm already and even surpass official flash [11:34] important as it is, flash is not the driving force behind a distro [11:35] markos_: Eh it was just an example obviously [11:35] lool: I'm not aware of any important non-free software that would act as a show-stopper, apart from flash [11:36] lool: many android/winmo phones with armv6 cpu do not have vfp [11:36] lool: how much is codesourcery, ARM and linaro to make those compiler changes? -- are they worth it? [11:36] lool, what ? you are not working on fixing a 64bit flash ? [11:36] markos_: Even for Debian, it means new buildd network, new images to validate, packages to change, the work will eventually be distributed on a bunch of DDs, but the sum of it is HUGE [11:36] hrw: precisely, thanks for mentionning it [11:36] markos_: Consider the market place use case [11:36] markos_: I ship an OS, and ISVs can offer apps for it [11:36] lool: qualcomm msm armv6 cpus to be exact [11:37] hrw: the msm72XX CPUs tend to lack VFP [11:37] also, android is totally irrelevant to ubuntu/debian, they already have totally separate binaries [11:37] markos_: Suddenly, this OS might come in two incompatible flavors and ISVs have to provide builds for the two flavors and test the two [11:37] and totally incompatible [11:37] markos_, its not ... there are hacks that make android work in ubuntu [11:37] not officially in the archive but you can use them [11:37] exactly that, hacks, it even has a different libc [11:38] These are just example [11:38] I could have said MeeGo and made the same point [11:38] I understand your point [11:39] but in my experience, users will very rarely pick a package from another distro -eg. a meego user from an ubuntu netbook for example and try to make it work [11:39] there might be a meego ubuntu image at some point, who knows [11:39] markos_: It's not about other distros, it's about ISVs [11:39] so compatibility is not really important here, Adobe for example, will most likely have a single instance of most important distros and build on each one separately -I don't know if that's the case, but I imagine it's a logical scenario [11:40] markos_: In Android, Maemo, MeeGo, Ubuntu, you get to add packages and software from ISVs [11:40] and these users would surely want to be able to use all of the ubuntu archive on their systems [11:40] markos_: heck, that's even true for Ubuntu, vmware provides binary .debs [11:40] Or Adobe Acrobat Reader [11:40] or many others [11:40] or flash :) [11:40] (that was covered already) [11:40] yes I totally understand your point [11:40] * ogra was referring to adobes flash package :) [11:40] markos_: Once you create the port, and you have a somewhat popular userbase [11:41] Debian derivatives will appear (probably including Ubuntu I'd guess) [11:41] and products will ship based on it [11:41] and the ARM world will be fragmented a bit more [11:41] So I'm /very/ split on this point [11:41] my point is, if Adobe would provide the same package with just rebuilding it on the same hardware -and no other extra development- why should they not do that, [11:41] markos_: they need to port it, validate it twice etc. [11:41] lool: ARM is way beyond unification :) === fta_ is now known as fta [11:42] markos_: You think adobe flash would work without any tweaks on hradfloat calling conventions? I bet not [11:42] the opposite is the case thanks to linaro [11:42] lool: it's the most fragmented architecture out there : [11:42] I bet upcoming ones have NEON opts and stuff [11:42] lool: neon works just fine on hardfp [11:42] markos_: And fragmentation is the main issue, and initiatives like Linaro fight fragmentation towards consolidation [11:42] markos_: My point is, there is manual assembly in flash player, so they will have to adapt [11:43] if done using pure asm, maybe, if done using C intrinsics, they most definitely not [11:43] s/they/then [11:44] markos_: I think it's a large body of code with assembly, and has good chances of hitting the issue [11:45] markos_: In any case, I think the main problem is that the alternate plans being discussed are far away [11:45] markos_: Both because they need long developments and because they need a certain class of people (experienced toolchain devs) [11:46] markos_: So I currently suspect the port will happen by virtue of being atteinable now [11:46] we could switch M+1 to hardfp in ubuntu and act as a testbed for debian [11:46] debian would just have to take our armel defaults then [11:47] and we would rename to armelfp in M+2 [11:48] without having to do more changes than renaming [11:48] ogra: I could act as a testbed for Ubuntu myself, I could rebuild Maverick for example for hardfp and provide testing/patches [11:49] my goal ofc would be to have a hardfp maverick build [11:49] ogra: "switch" [11:49] well, we wont do a hardfp build in maverick but test results would surely be appreciated [11:50] ogra: you dont switch [11:50] it's binary incompatible [11:50] lool, its a full rebuild, i'm aware of that [11:50] you can introduce a new port, deprecate armel, and them move to the hard-float one [11:50] ogra: No, it's incompatible [11:50] it's a new bootstrap [11:50] ogra: You can't "upgrade" to it [11:50] oh, indeed [11:51] ogra: I think you need to read the debian-arm@ discussion [11:51] lool, i do [11:51] not extensively but i have read some of the thread [11:51] brb [11:52] lool, indeed we would have to make a cut, but we will become the best optimized v7 distro in the end so i dont think its a bad thing [11:53] lool, what i wont do is maintain two arm arches [11:53] ogra: See that's the main issue [11:53] ogra: You dont want to maintain two arm arches [11:53] Nobody wants [11:53] well Debian is ready to start that [11:53] debian does already, no ? [11:53] they would get a third [11:54] debian is discussing it! not ready for anything, just Genesi is ready [11:54] but in practice, ARM Cortex-A class CPUs with VFP are the high-end ones, and many devices will ship with A-class CPUs without VFP, including phones and netbooks [11:54] ir is the arm oabi port completely gone ? [11:54] ogra: Debian only has an armel port right now [11:54] ah, i thought arm was still existing [11:54] That said, Ubuntu already excludes non-VFP hardware [11:54] right [11:55] for us its not such a big step apart from upgradeability [11:55] lag: pong === amitk-afk is now known as amitk [12:09] lool: anything new reg. soyuz release as standalone? [12:10] markos_: I'm not tracking that personally, ping salgado on #linaro [12:10] .br time [12:14] sebjan: Good morning [12:14] Afternoon even - doesn't time fly? [12:14] lag: yes indeed :) [12:15] sebjan: Do you have any documentation you can send me for OMAP3 and OMAP4? [12:15] sebjan: A developer's manual or such [12:16] sebjan: Containing memory maps, register addresses and definitions etc [12:17] lag: the technical data manual for omap3 shall be available publicly... [12:18] lag: it is not out yet for omap4 [12:21] lag: regarding the beagle, there seem to be good links here: http://elinux.org/BeagleBoard#Manuals_and_resources [12:22] But nothing for the XM? [12:22] Or Panda? [12:22] The two boards I own :D [12:23] lool: does gcc-linaro include hardfp patches from CS? I'm pulling the 4.4 branch now to test [12:24] lag: I have never looked for the XM, if it exists, it shall be reference on the wiki? For panda, it will come when it is release ;) We shall have omap4 data manual soon I hope. [12:30] sebjan: Perhaps I need to be a little more specific [12:30] sebjan: Do you have the developers reference for the OMAP3630 [12:32] lag: you shall ask this on the #linux-omap channel, they shall be able to provide you clear answers regarding public documentation and where to get it [12:33] should be on ompazoom.org [12:33] Thanks sebjan [12:33] (if it exists) [12:33] markos_: Yes [12:33] though there is likely no XM docs yet since XM isnt sold yet [12:33] markos_: We're rolling a test tarball if that makes testing easier for you [12:36] cool === fta_ is now known as fta [13:17] lag: others: http://omappedia.org/wiki/RFCs please have a look at it and provide comments if you have any , it is for the Autodetect feature for HDMI [13:21] mythripk, could it be a higher default than 640x480 or would that break on to many screens ? [13:21] (800x600 would be a bit better for X driven distros) [13:23] mythripk: That system for RFC is weird [13:23] mythripk, what also would be cool would be if custom_edid_timing could seed the available framebuffer modes (and xrandr) [13:23] lag, you mean using powerpoint ... ? :) [13:25] Yeah [13:25] Naff! [13:26] ogra: My Maverick install falls into a initramfs shell [13:26] did you fiddle with boot.scr ? [13:27] manually i mean [13:27] Yep [13:27] aha :P [13:27] It's the only way I can see the screen at all [13:27] must be the kernels fault then *g* [13:27] Jerk [13:27] did you update the system recently ? [13:28] flash-kernel changed a bit and expects a clear text /boot/boot.script file as input now [13:28] (which jasper now creates by default) [13:28] It's the current build from last week [13:29] ogra: it would break many screens and the only compliant resolution is 640 480 [13:29] well, if you didnt upgrade and your root=UUID line in boot.scr is still correct i dont see how you could end up in a busybox [13:29] mythripk, ok, no choice then i guess [13:30] but it would read EDID , and set it to the timing supported by TV [13:30] lag, show me your boot.scr :) [13:30] mythripk, right, i only think about the fallback default [13:30] so only reason why it would set 640 480 would be if EDID is not read correctly [13:30] yeah [13:31] ogra,lag , so does the design look ok ? [13:31] yes, looks ok to me, did you look how the kms drivers do it btw ? [13:31] i guess there is a lot overlap [13:31] kms? [13:31] kernel mode setting [13:31] it is what all distros use nowadays [13:32] i'm pretty sure there is code that reads EDID in all of them [13:32] ogra , i shall have a look [13:32] :) [13:33] eventually we would like to have KMS working on omap4 [13:33] * ogra thinks robclark knows some background here [13:34] as i'm not a graphics guy and only scratch the surface of such technology [13:34] gm mythripk, gm ogra [13:34] heya, morning [13:34] gm rob, the discussion is on the redesing of HDMI edid for auto detect [13:34] ahh [13:34] * lag feels left out of robclark's gms [13:34] http://omappedia.org/wiki/RFCs [13:34] robclark, i was just wondering if there isnt possible overlap with KMS stuff that could be used [13:34] gm lag [13:35] probably is [13:35] mg robclark :) [13:35] * lag is happy now [13:35] gm robclark, ogra :) [13:35]