[00:59] conics.net also ships the NetWalker worldwide [04:02] Hi guys, is it possible to get armel on Palm Tungsten T3? [04:07] * persia checks for specs [04:08] ericnj: You might be able to shove 9.04 on it, but nothing newer. I'd recommend trying to install Debian on that device. [04:08] where can I get a ready made image, rootfs? [04:10] 9.04 is fine for me, just want minimal with light widows manager. [04:11] There aren't any images for the Palm Tunsten T3. [04:12] can I use the instruction on https://wiki.ubuntu.com/ARM/RootfsFromScratch? [04:12] The babbage image from http://cdimage.ubuntu.com/ports/releases/jaunty/release/ will have an extractable rootfs for all of desktop (but that might need too much RAM) [04:13] Yes. Those instructions should work fine (you got the URL faster than I) [04:15] what is the smallest image size I can use on the rootstock? [04:17] I want to install it on a SD card [04:19] I don't know precisely about "smallest". The buildd minimal chroots are about 60MB after bzip2, so maybe a couple hundred MB? [04:19] Try installing the ubuntu-minimal task only, and see what that gets you. [04:20] Do I have to do it with qemu? [04:22] No, but that's easiest. [04:22] So, there are two ways to construct a chroot that are fairly easy. [04:23] 1) If you have a current Ubuntu armel install, you can use debootstrap. This may or may not work for some Debian installs, depending on a number of factors. [04:24] ok, I'm listening [04:24] 2) If you have an Ubuntu install on i386 or amd64 (and potentially other architectures, but not well tested), you can use rootstock to run debootstrap in an emulated environment. [04:24] There are, of course, N other ways, but neither is as easy as those. [04:25] can you send me some instruction on my e-mail? [04:25] I'm a noobie [04:25] What sort of instruction, and for which path? [04:26] and I'd much prefer to work with you interactively to sort it, rather than trying to write some customised documentation.. [04:26] I understand [04:26] yes and others may bennefit from it [04:27] That too :) [04:27] ;) [04:28] I've tried the instructions on the above page and that's what I've got at the end of my log file: Reading package lists... 99% Reading package lists... Error! E: Unable to write mmap - msync (28 No space left on device) E: The package lists or status file could not be parsed or opened. Kernel panic - not syncing: Attempted to kill init! I: Killed ... [04:28] That usually means you need to pass a larger value to --imagesize [04:29] if if setup ubuhntu-armel I should be able to debbostrap lenny right ? [04:29] tkmedia: That *should* work, but it's not well tested. There is a small chance that there are some internetworking issues that could be exposed. [04:30] thanks, I'll try that [04:30] k [04:30] tkmedia: If you are up for testing and reporting any bugs, that would be great. I'd much prefer if we could support that use case. [04:31] can i setup ubuntu-armel in kvm by chance ? [04:32] ?? [04:32] I thought there was zero KVM support in armel. [04:32] There's no hardware support for hypervisor functions... [04:33] (TrustZone doesn't provide the right kinds of abstraction) [04:33] tkmedia: You can't in kvm. You can in qemu-kvm. I personally use `mk-sbuild --arch=armel lucid` to create build chroots (works in lucid) [04:34] tkmedia: Also, read https://wiki.ubuntu.com/ARM/RootfsFromScratch for richer instructions on getting something running in real qemu, rather than just a chroot. [04:34] yep tried that [04:34] unfortunately i have arm 4 [04:35] Then you can't run Ubuntu anyway. [04:35] hence then lenny deboostrap question [04:36] aha! [04:36] You might do better to try to port rootstock to work also with Debian, and then just build your Debian rootfs directly. [04:36] am i way off [04:37] No, but I think you're doing it the hard way :) [04:37] k [04:37] what else is new [04:37] if there is a hard way ... i seem to find it [04:38] i guess i should jkust suck it up and build a qemu [04:38] tkmedia: What are you trying to accomplish as an end goal? [04:39] but i have proxmox and it makes kvm soooo easy [04:39] good question [04:39] dev environtment under lenny iguess [04:39] ARM 4 [04:39] kvm doesn't deal well with cross-architecture things. Works *great* for i386/amd64/powerpc as long as the guest architecture matches the host architecture, but that's not usually the case here. [04:39] tkmedia: What hardware? [04:40] samsung 9 [04:40] mini2440 [04:41] 7-10 touch screen [04:41] maybe a cortex board is better [04:41] ? [04:42] wall mount [04:43] If you're just looking for an electronic picture frame, a newer board is a waste of power. [04:43] http://www.friendlyarm.net/products/mini2440 [04:44] http://code.google.com/p/mini2440/wiki/EmdebianChroot might be a reasonable place to start. [04:45] yep i keep ending up back there [04:45] so iguess i should stop fighting that [04:46] It oughtn't be that hard to generalise the emdebian instructions to work with Debian proper. [04:46] Also, rootstock would benefit from growing the ability to also create Debian rootfs artifacts. [04:47] But if you just want it to work today, the emdebian instructions are probably fastest. [04:47] I have been tainted by the M$ world [04:48] so my mind needs reprogramming [04:48] and VB by day doesnt help [04:49] Martyn: Just for completeness sake: 9.04 supported ARMv5, 9.10 supported ARMv6, and 10.04+ is ARMv7. [04:49] is rootstock script based ? [04:50] Also, there were no formal Ubuntu releases of armel prior to 9.04 (although the mojo project had good stuff for several releases from cross-compilation) [04:50] persia : Thanks for the clarification [04:50] tkmedia: https://code.launchpad.net/project-rootstock is the best place to check. [04:50] k [04:50] thanks [04:50] Martyn: Thanks for steering now3d in the right direction :) [04:51] persia : I had a complete 8.04 system built for/from ARM itself, but that was before the release of the Cortex-A8... more a proof of concept than anything supported [04:51] Not the mojo stuff? [04:52] ( mojo.handhelds.org ) [04:52] nope, not the mojo stuff [04:52] in fact, a lot of it was compiled with the CodeSourcery toolchain, inside of ARM. It predates all the nice root filesystem tools too... [04:53] Which, for the record, rock my world. [04:53] rootstock = FTW [04:54] rootstock is very nice indeed. [04:54] But yeah, that sounds like a special thing. Not something I'd heard about before. [04:58] It was, but it was also fun [04:58] And these days I'm still working on getting Lenny working as an arm server [04:58] so much that we discussed at UDS has been abandoned [04:58] No Device Tree [04:58] no software boot [04:59] and there's no point in even trying to get an official arm server build... [04:59] Hrm? [04:59] What's http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/ [04:59] Looks like two armel server builds to me. [05:00] DeviceTree just didn't get finished in time, from what I heard. [05:00] And mukluk needs love, but there's been persistent bugs about kexec() issues, which I believe are finally just getting sorted (but too late for lucid). [05:00] Yep. Grant is working really hard [05:00] but the patches are only just now starting to flow [05:00] Yeah, all credit to him. It's just a matter of timing against the 6-month cycle. [05:01] Based on what I hear, I have a feeling that we might be able to get that for the next cycle. [05:01] yep [05:01] and that's kind of critical for smooth-stone chips [05:01] device tree will make booting our SoC much, much easier [05:02] hmm ps3 install [05:02] Make booting *everything* easier. [05:02] tkmedia: -> #ubuntu-powerpc :) [05:02] anyone try that? [05:03] is it virtual [05:03] it runs intheir hypervisor right ? [05:04] Martyn: Have you been testing the DT stuff in your kernels? Do you know what we need to tweak in image builds to make it just work? [05:04] or can you take full advantage of the hardware? [05:05] * tkmedia is off to read up [05:05] no, I'm not touching the DT stuff at _all_ [05:05] Right now, I'm porting linux to specifications, since we don't have a test chip built .. and RTL runs 8 million times slower than the actual processor [05:06] 8 million! So you get, what, about 1.5KHz? [05:07] * persia can't do math, and gives up. [05:09] no, 200Hz [05:09] 300 if the simulation is run on a very, very fast nehalem (3.2Ghz or better) [05:09] Ouch! [05:09] multicore isn't yet supported by anyone for RTL sim [05:10] so you basically are running unicore [05:10] (that's being addressed, but a lot of this kind of thing CAN'T be run parallel) [05:10] Right. [05:10] So if DT gets far enough to land in lucid+1, that actually works for you. [05:10] yep [05:11] One of my workmates (JAson Hobbes - n3onfr3on) is working on that part [05:11] Also, have you tested the server images at all? I don't know that they are getting enough testing, but I suspect they ought get some. [05:11] since he's writing the bootloader [05:11] (and it was your spec that made them happen) [05:11] I can't test them .. while they are built for v7a, my kernels don't properly support thumb2 yet [05:12] I thought you had a Lange [05:12] because I'm running in FastModel [05:12] Yeah, I have a lange board .. but I don't have the debug cable [05:12] I need to get that from ojn before I can reconfigure u-boot [05:12] lange 5.1 even [05:12] Oh right, I remember now. Sorry for the reminder of the pain. [05:12] in fact, I'd like to try the -desktop- build on the lange 5.1 [05:13] That's been dropped. THe only images being built are Ubuntu Netbook, Kubuntu Netbook, and Ubuntu Server. [05:13] Not to say you can't create one, but images just aren't being built. [05:14] yep [05:14] I can use the server image, and apply most of what's needed to get desktop [05:15] Just preseed a late-command to install the ubuntu-desktop task, and you can do it in one shot. [05:16] yep [05:16] Although netinstall images might be better for that use case, because most of the server pool is uninteresting for desktop. [05:16] but, for now the lange sits on my desk unused [05:16] the versatile2 gets a lot more attention [05:16] Waiting on ojn :) [05:16] even if it is just a 400Mhz Cortex-A9 [05:16] That's not bad at all. [05:37] interesting... device-tree coming to ARM? [05:39] DanaG: Indeed. The idea is to move from kernel-per-board to kernel-per-SoC by using DeviceTree to handle board-level variations. [05:40] hmm, how would it handle different memory locations? [05:40] And this is critical from a distribution POV, as it means we can actually support N devices. [05:40] How do you mean? [05:40] ah, that's the per-SOC part. [05:40] Same SOC will have same memory layout for at least main RAM. [05:40] Oh, yeah. Moving from per-SoC to per-architecture will require an entirely different level of cooperation [05:41] First time I'd used Device-Tree was with Microblaze.... that was an exercise in broken tools. [05:43] If you've experience working with it, and want to help make it happen (to avoid the broken tool situation), please track followups to http://www.kernel.org/doc/ols/2008/ols2008v2-pages-27-38.pdf [05:44] git://git.secretlab.ca/git/linux-2.6 test-devicetree seems another good source [06:06] what I mean by broken tools, is things like a cross-compiler, that, when trying to build, segfaults the host compiler. =þ [06:08] Ugh. Yet another argument against cross-compilers. [06:10] Yeah, I thought that was comically bad -- I mean, I don't even see how you could make a compiler segfault. Really bad code? =þ [06:13] ICE isn't hard to achieve if one takes the effort. [06:13] THis is unfortunate, but the nature of developing tools. [06:59] what do you guys think of the smart Q7 [07:02] tkmedia: It's too big :) Also, it can't run lucid (ARMv6) [07:02] persia: I thought lucid was armv7? [07:03] (or are you referring to the smart? [07:03] GrueMaster: SmartQ7 [07:03] ah [07:04] They ship with something based on jaunty, but I *think* they could be upgraded to karmic if someone uses a custom kernel. [07:04] I'm fairly certain they can't run lucid. [07:04] (although SmartDevices may well come out with another generation, and the price is certainly right) === ramana-away is now known as ramana [07:14] hello, from my Droid === ramana is now known as ramana-away === ramana-away is now known as ramana === ramana is now known as ramana-away === ramana-away is now known as ramana === ramana is now known as ramana-away === ramana-away is now known as ramana === ramana is now known as ramana-away === ramana-away is now known as ramana === ramana is now known as ramana-away === ramana-away is now known as ramana [13:38] JamieBennett: gave you a RC bug so we can upload in freeze: bug 537356 [13:38] Launchpad bug 537356 in webservice-office-zoho (Ubuntu Lucid) (and 1 other project) "application menu entries dont do anything (affects: 1)" [High,Triaged] https://launchpad.net/bugs/537356 [13:42] xserver with imx fallback patch is about to finish building ;) [13:43] asac: thanks :) [13:43] wohooo [13:44] asac, now it just needs proper EDID detection :) [13:44] ogra: the current solution is quite good enough i think ;) [13:44] Well, depends on one's monitor [13:44] i want my 1900x1002 ! [13:44] oh edid [13:44] yeah [13:44] *1200 [13:44] ogra: how is that done? [13:45] no idea i have to look into it, it wasnt ready in the old driver i have around here [13:45] well its not ready here either [13:45] but maybe its just a code fix ;) [13:45] but i think its already done when the fb device inits [13:45] hmm on init feels wrong [13:45] monitor might get plugged in/out swapped etc. [13:45] xrandr should tell us better info ;) [13:46] xrandr is after EDID [13:46] iirc [13:46] ok i will check that [13:47] sure xrandr hopefully just reflects what EDID gave us [13:47] or gives us (when mohnitor changes) [13:47] I was under the impression xrandr wasn't available based on the snipped of the log that was pasted yesterday. [13:48] fbcvt: 1024x768@60: CVT Name - .786M3 [13:48] thats what i have in dmesg [13:48] xrandr is available but only with a handfull of default resolutions [13:48] up to 1024x768 [13:48] ack [13:49] at least it detects for me its a lcd with proper subpixel [13:49] and we dont know if resolution changing works yet [13:49] cant you try lower resolution in fbdev? [13:51] you can try setting modelines with fbset [13:52] and you can indeed add modelines in xorg.conf [13:52] if xranbdr works you should even be able to use modelines there to add new modes [13:56] dmart: ping? [13:57] NCommander: hi there [13:57] dmart: sorry I missed you yesterday [13:57] no probs; just wondering what our next steps should be on OOo [13:57] dmart: funny, I was going to ask you the same thing :-) [13:58] dmart: I retested karmic gcc-4.3 + jaunty binutils, and got a working uno from fresh sources [13:59] NCommander, did you talk to doko btw, i think he did all these varaition tests already [13:59] he should have a test matrix for what combo works and which one doesnt [13:59] ogra: I talked to him earlier, but he didn't say anything about that. I'll make sure to ask him for that [14:00] i tested a *ton* of different builds he did [14:00] each with a different combo of gcc and binutils [14:00] ogra: I'll ping him [14:01] ogra: that's good to know. I just wish it was on the bug :-/ [14:01] dmart: TBH, I'm kinda out of ideas on this one. [14:01] dmart: we know what appears to be the base underlying cause for the OOo boom [14:01] but I don't really know how to fix it, or how to even rewrite the ASM snippet to be less evil [14:03] NCommander, just build it with --no-uno-crash [14:03] ;) [14:03] * NCommander whacks ogra [14:03] * NCommander feels better [14:03] * ogra feels short now [14:04] So, about OO.o. [14:05] From what I saw recently, I thought we knew what changes to the toolchain were providing what extra bits that caused which problems. [14:05] Was the .eh... issue resolved or still open upstream? [14:05] Or did someone confirm this wasn't really the issue? [14:11] dmart: I'm not even sure what to bring to OOo upstream about this, from there perspective, it looks like a pure toolchain bug [14:21] NCommander: the problem file had some maintainers' names -- have you tried to contact them? I think the first thing is to understand from them what the code is trying to do, and explain our concerns about why it looks incorrect. [14:22] dmart: no, I haven't === ndechesne is now known as ndec [14:24] I can draft a mail if you like. [14:28] oooh [14:28] hang on a moment [14:30] NCommander: did you look at this?: http://pastebin.ubuntu.com/393294/ [14:31] dmart: I smell magic in that file [14:31] deep scary magic [14:31] Ummm, yeah [14:31] The two first *p++ poke ARM instructions into memory [14:31] > mov r12, pc [14:32] > ldr pc, [pc, #4] [14:32] This explains why privateSnippetExecutor assumes there is something in ip (r12) [14:32] dmart: I think my crack fuse just burt out :-/ [14:33] I guess it's used to look up the functionIndex and vtableOffset values which get poked [14:34] dmart: there is no guarette thats going to laid out like that in memory though, or with no padding and stuff done [14:36] dmart: actually, it could have been the move to ARMv6 that might have brokened it in the first place since that removed the strict algnment access requirements [14:36] (not sure, but a possible theory) === dmart_ is now known as dmart [14:40] Hey ramana [14:40] I know what's in ip (ish) [14:41] It contains the pc value in a trampoline used to read the destination vtable offset and function index, see http://pastebin.ubuntu.com/393294/ [14:41] ...or at least it would contain that if any version of the linker ever provided a guarantee [14:41] dmart: on a scale of 1-10, how high is the crack factor of what OOo is doing here? [14:42] dmart: but privateSnippetExecutor works [14:42] dmart: thats been previously tested, and works as expected [14:42] Shouldn't it not work as expecting, as with all the mov *,pc stuff? [14:43] The linker is allowed insert trampolines for function calls, which are permitted to corrupt ip. The chance of this happening is pretty low, but it's not "safe" [14:43] I think the code in question will get executed as ARM, and the way it branches it interworking-compatible. [14:44] ...anyway, I don't think this code is failing, it's just a bit scary [14:44] dmart: bit? [14:44] dmart: ugh, I just realized something nasty [14:45] dmart: part of the ASM instructions exist outside the .S (as the hex magic) [14:45] dmart: so even if we add unwind table entries, ther're not going to properly "mesh" [14:46] Because the trampoline generated by privateSnippetExecutor only trashes ip, it might not need any unwind info... but I'm not the expert on this [14:47] Also, I think no exception can occur in the trampoline itself, because it calls no functions except for jumping to privateSnippetExecutor [14:48] dmart: thats not the problem, the problem is libgcc bails out because on CANTUNWIND segments (in theory) [14:48] * dmart is grepping the OOo source to try and work out where this code gets called from, but it will take a while [14:48] cortex a9 processor seems to be the fastest and most fitting processor for a small client with gui, does someone know where I can buy a mainboard with this cpu? [14:48] nvidia tegra2 [14:49] johannes_: I've seen Ubuntu at least Ubuntu karmic working on tegra2 [14:49] dmart: uno2cpp.cxx only [14:49] dmart: same folder [14:49] NCommander: I mean, where the functions codeSnippet and flushCode in uno2cpp.cxx are called from... [14:49] johannes_: http://tegradeveloper.nvidia.com/tegra/ [14:49] dmart: if you read the UNO CPP code, your mind will release itself from mundane concerns as the horror of it takes over [14:50] thanks Ill have a look at tegra2 [14:50] dmart: ah. theres a porting uno guide you might want to look at [14:50] Oh, where? That sounds useful [14:50] dmart: http://wiki.services.openoffice.org/wiki/Lazy_Hackers_Guide_To_Porting - skip to the first part of Hard Bit [14:51] dmart: it deals with how the HPPA port was done. === dl9pf_ is now known as dl9pf [15:02] mhm bei tegra2 finde ich nur dinge, wie tablet pcs, ich suche aber nach etwas, wie dem beagleboard nur mit einem oder mehreren Cortex A9 [15:03] johannes_, i dont think they are freely sold yet [15:03] One needs to apply. [15:03] oh sry for writing in german [15:03] macht nix :) [15:04] johannes_: Are you looking to build something, or do you want a shipping device? [15:04] I thought about a fileserver with a quadcore Cortex A9 as I read some articles it would have a lot of power [15:05] I want to build something for myself [15:08] tegra is dual core "only" [15:09] yeah, lame, isnt it ? :P [15:09] but there are processor on it, I dont need, 3d graphics for example [15:09] and I couldnt find a mainboard yet [15:09] it's too hot [15:10] you can't even buy it in Europe [15:10] I've not seen any bare mainboards except for "development boards". [15:10] Most stuff seems to be inside devices. [15:10] thats sad [15:11] http://www.dlink.com/boxeebox [15:11] that will use a tegra2 [15:11] i read somewhere [15:11] but who knows when they start shipping it out :) [15:12] Real Soon Now [15:12] hm, good [15:12] heh [15:13] That's why I like the devices I *know* are shipping. [15:13] We can get them today. [15:13] well, just hit the fast forward button ... [15:14] One of those several-month retreats? [15:14] heh, yeah [15:15] a question in general: would a quadcore Cortex A9 actually be powerful enough to support: mdadm raid 5, trunked Gigabit Ethernet, 2 HDTV tuner cards (for a vdr backend without decoding)? [15:16] if you find HDTV cards that fit into any ARM device ... [15:17] are there HD USB tuner cards ? [15:17] size doesnt matter, it is only about power consumption [15:17] some but most are pcie or pci [15:17] right, PCI is rare on ARM boards [15:17] sockets at least [15:18] There are USB HD DTV devices. [15:18] mhm I guess I was a bit naive, thinking I could simply change my opteron board with a armsystem [15:19] Well, there exist a few boards with PCIe, but nothing running those chips I've seen [15:19] * persia has PCIe on an orion board [15:19] there will surely be some server boards with a9 chips *soon* [15:19] what do you mean by soon? [15:19] those would have PCIe i assume [15:20] johannes_, within the next 254 months ? [15:20] Maybe. Maybe PCIx [15:20] err [15:20] 24 :) [15:20] No, 254 is definitely correct. 24 is a bet. [15:20] mhm better than 254, but still a long time [15:20] no idea ... i dont know how many companies wortk on server boards [15:21] but a9 are definately somehting thats intresting for datacenters [15:21] When ubuntu is installed on an arm system, can I use all the programs, that are available for x86 ubuntu too? [15:21] johannes_: I suspect that what you want is a next-generation NAS box (for the raid), with the HDTV USB bits plugged in the back. [15:21] This wouldn't be building it yourself, but is probably the earliest purchase option. [15:22] johannes_: There's a couple hundred packages that don't work right now, but we try to get that as close to zero as we can. [15:22] johannes_, yes, the majority works on arm as on x86 [15:22] I would prefer if it was still more pc than NAS, as I like to try things out with linux [15:22] that sounds great [15:23] what about drivers? (for tuner cards) can they simply be installed or do I need special ones? [15:23] johannes_: The difference between a "Small form factor PC" and a "NAS box" is a USB keyboard and a USB Display module :) [15:24] johannes_, as long as there are linux drivers they should just work [15:24] For USB tuner cards, the same drivers should work for any architecture. For other tuners, you may need to do some tweaking. [15:24] johannes_: openrd board comes with one PCIe slot [15:24] I look it up [15:24] suihkulokki, but can the CPU do HD processing ? [15:25] though its a backend ... probably thats not actually needed if the card is powerful [15:25] ogra: didn't he say we won't do decoding ? [15:25] suihkulokki: That's the ARMv5 chip that's in the SheevaPlug, right? [15:25] persia: which is good enough for the usecase. [15:25] Absolutely. Just wanted to confirm my reading. [15:25] suihkulokki, well, recording and streaming i guess [15:26] basically streaming only === mcasadevall is now known as NCommander [15:27] oviously thing like recompressing streams or analyzing + cutting out ad breaks is out of question with any arm cpu [15:27] dmart: *sigh*, how best do we draft this email? [15:30] I will look a bit more and then send you something... But I think the code in armhelper.s is a fairly straightforward trampoline in which case the solution might not be too complicated. Too early to say though... [15:32] how about using a network tuner like hd homerun [15:34] i think thats only DVB-T [15:34] there are no german HD channels over DVB-T [15:34] k [15:34] (assuming johannes_ is german after he spoke german here :) ) [15:35] wikipedia claims there are 4 modles of which only one is DVB-T [15:35] I use the US version [15:35] persia, the german version is DVB-T only afaik [15:36] Ah. [15:38] yes, I am german and thing is: I already got myself a skystar hd2 for the server I am using right now [15:44] NCommander, ramana: The code which looks interesting is in: [15:44] bridges/source/cpp_uno/shared/vtablefactory.cxx [15:44] bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx [15:45] bridges/source/cpp_uno/gcc3_linux_arm/armhelper.s [15:45] (if you want to look and didn't already look at one of those) === plars` is now known as plars [16:23] NCommander: hi again [16:24] dmart: Yes, that's the uno2cpp bridge, and it's what upstream told me was likely broken [16:25] dmart: hola again [16:25] Hi there... I was just chatting for ramana and matt [16:26] We now understand better what privateSnippetExecutor is doing [16:26] and we think we have a fix: http://pastebin.ubuntu.com/393376/ [16:26] (i.e., delete 2/3 of the function :P ) [16:26] dmart: O_o; [16:26] dmart: Amazing! [16:27] that will be one hell of a fix if it works [16:27] This may just expose the next bug :/ [16:27] Could you give it a try? [16:27] haha [16:27] My OOo build will take some more days to finish... [16:27] funny fix :) [16:27] * dmart admits that we did change a couple of lines as well as deleting some [16:28] !ohmy [16:28] Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others. [16:28] dmart: incremently building, please stand by [16:29] persia: where was the language violation? [16:29]