[00:28] base system 64% [00:28] been forever [00:28] Configurring ca-certificates... [00:56] doh [00:56] still 62% [01:37] tada [01:38] yeah it took a while [04:48] Hi all [04:49] Can somebody tell me, please, is there some significant difference between ARM and ARMEL ? [09:22] amitk: You might have to enable stuff in fconfig to have networking available [09:24] lool: ok === ogra_ is now known as ogra === gletelli__ is now known as gletelli [12:22] suihkulokki, ping [12:50] https://lists.ubuntu.com/archives/ubuntu-users/2009-July/191184.html [12:50] nice [12:54] uh [12:54] i feel like i want some arm box myself [12:55] dont ge ARM11 though :) [12:55] *get [12:56] what should i get? [12:56] whats the matter with arm11? [12:56] beagleboard should be good for a start [12:56] we will only support ARMv6/v7 in the future arm11 is ARMv5 [12:57] oh [12:57] hmm [12:57] i thought qemu was only ARMv5 though? [12:58] no, it can support cortex-a8 (ARMv7) its just that there is no kernel for it [12:58] there is a hack for beagleboard support, google for it :) [12:58] and there is https://lists.ubuntu.com/archives/ubuntu-mobile/2009-May/002485.html === cbrake_away is now known as cbrake [13:02] i wonder if someone has prebuilt qemu, realview rfs also [13:02] kernel is pointed there.. [13:21] erm [13:21] i trid rootfilesystemfrom scracth [13:21] well it didn't give me network in qemu :/ [13:21] during build ? [13:21] after build [13:21] or do you mean the resultin image [13:21] resulting image [13:22] well, you need to configure it in the image [13:22] how? [13:22] sudo ifconfig only shows lo [13:22] /etc/netwrok/interfaces [13:22] ah, well, manually do the following: [13:22] sudo ifconfig eth0 up [13:23] sudo dhclient eth0 [13:24] if you configure it in /etc/netwrok/interfaces it will come up automatically on boot [13:25] ah [13:25] thanks [13:25] that helped [13:25] my linux skills are rusty [13:25] i tried sudo ifup eth0 [13:25] it complained something funny :D [13:25] ifup looks in /etc/network/interfaces for an entry ;) [13:26] heh [13:27] what does eth0 line there look like? [13:28] googled [13:30] openssh-server package is a bit funny [13:30] i dont understand why it needs all that libx* stuff [13:30] oh way, for X11 forwarding_ [13:30] right [13:33] maybe i should have used dropbear instead [13:55] hmm [13:55] i dont seem to be able to ssh to the qemu server though [13:55] i installed openssh-server [13:55] according to ifconfig the qemu is 10.0.2.15 [13:56] but i can not connect to that from host [13:56] yes, but thats internal [13:56] internal to.. qemu_ [13:56] ? [13:56] someone added a reciepe for setting up network forwarding to the wikipage [13:57] where is the wikipage?) [13:58] /topic :) [13:59] cant see :( [14:00] i mean anything about network [14:00] sorry [14:00] i was looking at the wrong page :D [14:04] erm [14:04] that bridge thing didnt quite work [14:04] sudo ifup br0 [14:04] add bridge failed: Package not installed [14:04] and more [14:05] Install bridge-tools [14:05] Sorry bridge-utils [14:05] ugh [14:05] i misread the instructions [14:05] and please correct the wiki if thats not mentioned there [14:05] i was doing the host stuff inside qemu :D [14:05] my host is windows.. [14:06] tricky [14:07] * ogra wonders if his rootstock test with cortex-a8 just hangs or is simply slow [14:08] i probably shouldnt hide kernel messages [14:08] probably not :D [14:08] oh ! it moved [14:09] wtf [14:10] i right client on bat file to edit the script to lauch qemu and windows claims that "Open File - Security Warning. The publisher could not be verified. Are you sure you want to run this software? Name: ubuntu_run.bat ..." [14:11] ah that was because i edited the file on network drive :D [14:11] wrong one [14:14] !o [14:14] Factoid 'o' not found [14:15] oh yeah, wrong room [14:15] ogra! [14:15] heh [14:15] HOw goes it? [14:19] busy working on rootstock [14:22] oh well [14:22] i can use -redir to get ssh connection to host [14:23] hmm [14:23] is it normal to get packages cannot be authenticated error? [14:23] gdb causes at least [14:24] * ogra grins ... i just googled for project rootstock ... second hit after the LP page: "PROJECT: Rootstock Effects on Mango Productivity" [14:24] neure, sudo apt-get update [14:25] your packagelist in the image is likely outdated [14:25] funny i thought i already did apt-get update [14:26] oh dear [14:26] i installed ubuntu arm [14:26] in qemu [14:26] i tried netinstall and rootfsfromscratch [14:26] call it rootstock :) less typing :) [14:27] does it have a new name?) [14:27] (and the new name for it) [14:27] :D [14:27] well the thing is.. qemu doesnt multithread very well :/ [14:28] same issue with all linux i've tried so far.. if i create a new thread which busyloops like for(;;), pthread_create / clone never returns :( [14:28] in fact, the system hangs [14:28] on some setups, i can break the offending program, but on this ubuntu, i cant do anything [14:29] well i think lool tried it yesterday and it worked on HW [14:29] yeah [14:29] so i think its some funny thing with QEMU [14:30] which is bad, because i need to get it work in QEMU [14:30] :( [14:30] well, it might even work in qemu if its not running under windows [14:30] who knows [14:30] i've tried that too [14:30] ah, so you know :) [14:30] didn't work any better in linux :/ [14:31] well i tried in in VMWare which was running on top of windows.. [14:31] and i only used qemu-system-arm [14:32] neure: which compiler are you using to test your threading testcase? [14:32] gcc [14:32] my qemu just hang so i cant check the version [14:32] 4.3 i think [14:32] suihkulokki, i'd really like to know which kernel and rfs you are using [14:32] a gcc from the same distro? [14:33] yes [14:33] that was just debian lenny armel [14:33] i tried with debian lenny arm [14:33] i tried with debian lenny armel [14:33] i tried with ubuntu armel [14:33] with their own kernels and packages [14:34] and they all behave more or less the same [14:34] on lenny i was able to break the offending thread [14:34] and if i run with gdb, it worked [14:34] on ubuntu i only did first try with gdb [14:34] i wasnt able to break [14:35] i also tried in windows qemu, and linux qemu (althought that linux run inside vmware on top of windows) [14:36] and i have absolutely no clue what is causing this :( [14:42] and i'm running out of things to try :/ === bjf is now known as bjf-afk === bjf-afk is now known as bjf [17:07] is there a specific platform the arm port is designed around right now or is it targetting hardware that isnt out yet? wondering what options I have right now besides a beagleboard.. I'm guessing sheeva wont be supported much longer in karmic when things move up to armv6+? === Sarvatt_ is now known as Sarvatt [17:11] Sarvatt, the targets are listed on the qemu page [17:11] oh [17:11] sorry [17:11] this is ubuntu :) [17:11] wrong # [17:20] Sarvatt, btw, rootstock is fixed, that your image ended up in /tmp was a bug [17:21] ohh thank you ogra [17:23] mcasadevall, ogra: So on these lzma slowness thing [17:23] * ogra is just working on cortex-a8 support for the karmic version :) [17:23] mcasadevall, ogra: Did we benchmark it/profile it? [17:23] lool, i thought mcasadevall did [17:23] It might be that there's a bug in lzma simply; unaligned access or something [17:24] lool, it works (slowly) on my Babbage boards [17:24] heres my log if it helps anything http://sarvatt.com/downloads/rootstock-200907121533.log.txt [17:24] lool, and I fed a few test files through lzma -9 on rimu, no issue [17:24] expect speed [17:24] mcasadevall: I had in mind that perhaps lack of VFP or unaligned accesses could slow it down [17:24] lool, VFP didn't make a difference [17:24] lool, in any case if the majority of packages makes actual use of the 10h timeout thats not feasable [17:24] mcasadevall: You rebuilt it with softfp? [17:24] lool, yeah [17:25] lool, there are no floats in the code [17:25] mcasadevall: Do you think it could be unaligned access? [17:25] lool, the buildds are set to mode 0: do nothing [17:25] unaligned access would cause a sigill [17:25] mcasadevall: Perhaps you could oprofile it? or gprof, dunno what exposes the issue best [17:25] mcasadevall: Well that depends on the system setup AFAIK [17:25] Also v7 handles unaligned accesses [17:25] lool, the buildds are v5 [17:25] Sarvatt, oh, thats a different issue but its fixed since some days ... the reboot command was missing because new upstart didnt build [17:26] and rimu is setup the same way as the buildds [17:26] mcasadevall: Oh really? I didn't know that :) [17:26] heh [17:26] lool, :-) [17:26] I wouldn't have imaginated we're running v5 buildds really :) [17:26] Ok, stupid point [17:26] * mcasadevall dons the dunce cap [17:26] :-P [17:27] lool, on my tests, compressing a 13MB tar file takes 48 seconds with lzma -9 [17:27] But that doesn't max out the RAM [17:27] you run into problems when compressing with lzma on 512MB [17:27] Ah [17:27] yay [17:27] lool, then the system starts paging out [17:27] can you change the compression level on an arch specific basis for dpkg-builddeb globally? [17:27] Perhaps we can configure lzma in a less expensive mode where it uses less memory? [17:27] lool, you can guess what happens next [17:27] * ogra has a cortex-a8 build with all features we need for qemu [17:28] lool, that was is a possibility [17:28] lol, lzma -9 [17:28] lool, I'm not in love w/ it though. lzma in almost any mode is going to guzzle down memory faster than anything else [17:28] mcasadevall: Could you check how much that helps and if yes how to make that the default on armel? [17:28] suihkulokki: It's to run KDE anyway :-P [17:28] * mcasadevall has run KDE on ARM [17:28] :-) [17:28] even just -7 would be half the memory required or less [17:28] Sarvatt: I think that's what we'd want to look into, yes [17:29] (re: compression level in dpkg-bd) [17:29] hmm, i thought i saw an rtc patch in lool's patchset ... weird [17:29] * mcasadevall grabs dpkg's source [17:30] I don't see any flag passed to lzma by dpkg-dev stuff though [17:30] lzma -9 gives, what, 1% size reduction over lzma -5ish and takes twice as long and multiple times the ram [17:30] * mcasadevall is looking now at the dpkg-deb code [17:30] ogra: Just enabling the RTC kernel CONFIG_ I guess? [17:31] lool, yeah [17:31] but it doesnt seem to work, it moans on shutdown [17:31] but ... [17:31] cat /proc/cpuinfo |grep Processor [17:31] Processor : ARMv7 Processor rev 0 (v7l) [17:31] :D [17:31] * ogra hugs qemu [17:32] * neure curses qemu [17:32] inotify and tcp.syncookies added [17:32] as well as sysfs deprecated dropped [17:32] apparently it messes up guest scheduling when run in windows :( [17:32] due to crappy timers [17:32] The default compression in lzma is 7 [17:33] lool, and that's what we use [17:33] we don't pass -9 on lzma [17:33] * mcasadevall just checked the source [17:33] mcasadevall: I just said that earlier [17:33] oh [17:33] mcasadevall: Could you see what lzma level is acceptable on 512m of RAM? [17:34] TBH, I would consider not using lzma at all on that little RAM [17:34] -0 :) [17:34] mcasadevall: Well I find it a bit ugly to patch a bunch of patches not to use lzma, or to patch dpkg-dev to map lzma to something else [17:35] While I find it decent to set the default lzma level in dpkg-dev or in lzma itself to something reasonnable depending on the arch [17:35] s/a bunch of patches/a bunch of packages [17:36] lool, well, changing the code in dpkg to remap lzma to bz2 looks simple enough. Its a case switch that needs to be conditionally overridden [17:36] I'll see on RAM usage [17:36] forget bz2 [17:36] suihkulokki, ? [17:36] mcasadevall: I find it ugly really [17:37] dh_foo --I-want-lzma => you get something else; that's a nono [17:37] --I-want-lzma-but-I-dont-care-which-compression-pick-it-for-me sounds nicer [17:38] mcasadevall: among other things, it's slower to decompress than lzma [17:38] suihkulokki, its not to bad on +1Ghz boards [17:38] suihkulokki, and decompression isn't quite so RAM hungry [17:38] ... [17:39] lool, well, the other idea I had, depending on how crazy I am, is we could write a distlzma-like program and offload the compression :-) [17:39] (probably not something we want to do, but worth throwing the idea around before its shot down) [17:40] mcasadevall: Situation at hand: packages FTBFS due to a timeout; we don't care about the packages being compressed (we don't use -dbg) [17:40] lool, I get the point [17:40] mcasadevall: did you read the benchmark link I gave you yesterday? [17:40] So I think a light touch and simple change is a better choice than inventing a new tool, integrating it etc. [17:41] suihkulokki, I did, but it didn't give a great overview of RAM usage per notch [17:41] * lool loads http://tukaani.org/lzma/benchmarks [17:41] er [17:41] wait [17:41] sorry [17:41] Wrong benchmark [17:41] * mcasadevall had a bunch of google links open to this [17:43] suihkulokki: The page underlines the relatively low gain in compression ratio of using higher lzma modes but the high cost in memory [17:43] So I think it kind of speaks for changing the default mode of lzma or the default lzma mode which dpkg-dev uses [17:43] suihkulokki: Don't you have issues building KDE packages in Debian as a result of this? [17:44] lool: I don't think we've gone lzma [17:45] the lzma change is only because we can't fit KDE4 on the CD anymore [17:45] *sigh* [17:45] mcasadevall: So it's 100% Ubuntu specific? [17:45] lool, at the moment, I'm not sure if pkg-kde plans to adapt it or not [17:46] I find it ugly, but it's the KDE folks' decision [17:46] mcasadevall: So are we in agreement over the proposed changes? [17:46] lool, mesa seems to use lzma for dbgsym or dbg packages [17:46] * ogra isnt sure which [17:46] ogra: -dbg [17:46] right it was one of the two [17:47] ogra, I think they simply set the dpkg-deb line to build all of them as lzma, and the -dbg just gets compressed. I'm not even sure if you can set per-packaging compression options with the standard rules foo [17:47] even lzma -2/-3 beat bzip2 -9 ratios and doesn't really use much more ram (and compressess faster) [17:47] lool, just a matter of determing which -X option we want [17:47] i think thats the only other package with probs currently on the ftbfs list [17:47] (which doesnt mean there arent others) [17:47] mcasadevall: So you agree we should just change the default compression ratio on armel somewhere? [17:47] mcasadevall, but other packages arent that huge [17:48] ogra, when you fighting for every kilobyte on the CD, it makes the difference [17:48] ofcourse, to be systematic, one would measure the different levels directly with the problematic -dbg package and pick a level that gives the best compression ratio/ram usage ratio [17:48] lool, best cost/effort ratio I can see [17:48] lool, we're not as concerned with the image size as everyone else since ARM is .img and not iso [17:48] mcasadevall: Could you bring this up either with dpkg or lzma upstream or both and see what they think of it? [17:49] About -dbg: sorry folks, I have been misleading: builds timeout when packing these because cdbs packs packages separately, but it's an option which is used on all .debs built by a source which is why it gives space savings on the CD and why it makes the build globally longer [17:50] It's not an option passed only to -dbg as I might have implied [17:50] lool, er, I can understand lzma upstream, but why dpkg upstream? This is a very ubuntu-specific change we're considering [17:51] mcasadevall: Don't you think dh_builddeb -Zlzma would behave equally as bad under Debian? [17:51] mesa built fine on 06-30 in 3 hours and failed to build even after 10 hours starting 07-07.. dpkg was updated between the two to 0.15.2 and they switched dpkg-builddeb to add format=gnu and drop all TAR_OPTIONS, was it using format=posix by default on arm before? thats really a long shot but it seems to me like the lzma problems started after a certain date [17:51] suihkulokki, unless you think such a change it worthwhile for debian-armel? [17:52] Sarvatt, I didn't look at mesa in depth. I saw the problem crop up w/ KDE packages at first [17:53] Sarvatt: It didn't build on 06-30?! https://launchpad.net/ubuntu/+source/mesa/7.5~rc4-1ubuntu1/+build/1100008 [17:53] * mcasadevall needs to rule something out [17:53] that was a debian/rules error tjaalton did [17:53] 1ubuntu2 built fine [17:54] Sarvatt: Indeed it built with lzma recently [17:54] O_o; [17:54] That's strange to say the least [17:54] the lzma package itself hasn't been touched since intrepid [17:54] I ruled that out [17:54] The TAR_OPTIONS removal was at my request because some users had -z exported in TAR_OPTIONS and were createing source packages with this set [17:54] the only change between 1ubuntu2 and 1ubuntu3 was a patch added that only touches the intel driver in mesa that doesnt even get built on arm [17:56] mcasadevall: Could you try downgrading dpkg-dev and see whether you get a faster lzma again? [17:56] I'm confused about the change in speed too [17:56] lool, I can't reproduce locally [17:56] lool, I setup launchpad-buildd on a Babbage board with latest chroots when this issue popped up [17:56] The package build successfully after many hours, and the recent change in KDE was lzma compression [17:57] mcasadevall: Check with mesa [17:57] mcasadevall: You have a reference speed of 3 hours in earlier versions [17:57] lool, I haven't reproduced that build failure yet though [17:57] Alright [17:57] let me start that now [17:58] Which bumps to more than 14 afterwards [17:58] Sarvatt: Good catch, thanks! [17:58] definitely looks like something in the environment that changed in that case to me [17:59] lool, my hardware it slower than the buildds, but if it hangs in the same place after ~5 or so hours, I think we can call it reproduced [17:59] If not, I think we have a bigger problem [17:59] * ogra enables preempt for fun on his test kernel [18:04] meh [18:04] uboot fat reading is very slow [18:04] dont use fat :) [18:04] use ext2 [18:04] how? [18:04] no idea [18:04] you got the hardware, i dont :) [18:05] oh bah [18:05] I gave the wrong offset [18:05] you need physical addresses in u-boot or BAD THINGS(tm) happen [18:05] hmm, preempt seems to speed it up [18:06] * ogra wonders what the drawback is [18:08] lool, did you try to enable smp when you played with the v7 kernel ? [18:08] * ogra wonders if that would be worth a try [18:15] i should have just bought a beagleboard a year ago, been holding off because its been sounding like theres going to be better released any time now since november but still cant find anything.. sheevaplug is looking alot better but i'm sure karmic will switch to armv6+ as soon as it gets here :D [18:16] i thought jaunty was going to be armv7 from the start going by the press releases [18:18] we tried to keep jaunty close to debian [18:18] since it was our first release and v7 hardware is rare [18:18] at least the v7 HW we support [18:20] * mcasadevall would love to know why u-boot takes 30 seconds to load a kernel image [18:21] my efika is begging to be upgraded with something arm :) [18:24] hrm [18:24] why does /etc/init.d/sendsigs not finish [18:46] I used ARM/RootfsFromScratch from https://wiki.ubuntu.com/ARM to create a rootfs. If I understood correctly, this takes the pre-build binary packages and creates the rootfs from it. Now I wonder how are the armel binary packages created from source? That is, how is Uuntu ARM cross compilation done? [18:46] not at all :) [18:47] the packages are all build natively [18:47] orga: Native compile? [18:47] https://launchpad.net/builders [18:47] there are three armel build machines at the bottom [18:48] ah, I see. Any info what hardware is behind this? [18:48] some 800MHz 512M boards [18:49] i dont know the exact SoC names [18:49] uuuhi, ARM @ 800MHz [18:49] yeah :) [18:49] well thats the avreage HW we also target with the distro build [18:50] *average [18:50] Is it possible for a user (e.g. me ;) ) to use these machines to compile something? [18:51] no, sadly not, there is work going on to set up a cloud based buildsystem though [18:51] but that will use qemu [18:51] and should make PPAs possible [18:51] or something similar to PPAs [18:52] sometihng like OpenSuseBuild System for ARM? [18:52] something like that, yes [18:52] sorry, PPA? [18:52] well, and indeed you can upload packages to ubuntu if you like ... through REVU and sponsoring [18:52] ok ;) [18:52] https://help.launchpad.net/Packaging/PPA [18:53] ok, thanks [20:49] ogra: are you around? [20:57] lool, so if this test passes, what is our next step? [20:57] (I had a previous pass with some the KDE packages, so I'm leaning that this will pass too) [20:59] NCommander: Which test? [20:59] :-P [20:59] ogra: We don't have SMP support in emulated qemu boards [20:59] ogra: But yes, I did try this out [20:59] Actually I tried the v6 realview SMP one [21:00] But realview is in a poor state of emulation/upstream support in that there's no PCI support in upstream linux and qemu expects one and actually needs one to offer network and SCSI hard disk... [21:00] lool, building mesa w/ the launchpad-buildd setup [21:00] NCommander: Well if it's fast, we need to find out why it's not on the buildds; with IS probably [21:01] NCommander: But I would expect it's slow and we need to find which package changed (e.g. try downgrading dpkg-dev) [21:01] lool, yeah, i found that out myself ... would also need kernel hacking, SMP is no option with versatile [21:01] rjune_wrk, whats up ? [21:02] * ogra has to go in 5 min, if its important, shot now or never [21:02] ogra: can I get you to try something for me? [21:02] *shoot even === cbrake is now known as cbrake_away