=== DavidBz is now known as berco === XorA|gone is now known as XorA === JaMa|Away is now known as JaMa|Wrk === hrw|gone is now known as hrw [08:19] morning [08:21] hrw: morning [08:32] sebjan: hi, morning [08:32] amitk: morning [08:32] cooloney: morning [08:32] sebjan: i saw your email. yes, try that 'exclude' d-i patch will solve your issue [08:32] morning cooloney, all [08:33] cooloney: yes, I'll do that thanks! [08:34] sebjan: normally, how long will it take for building package in your omap4 hardware? [08:35] cooloney: :) that's a good question. It ran for 5 hours tonight until it stopped on this error. [08:36] cooloney: I have all my files on NFS, and my NFS settings may not be optimal either. [08:39] sebjan: ok, good, understand. hehe, i guess it is using -j2 defaultly, right [08:41] cooloney: I specified -j4, and the cores seemed quite loaded when I checked [08:42] ooh, dual-core? [08:42] DanaG: yeah, it is omap4 [08:42] sebjan: 5 hrs?! so not too much better than our existing situation. [08:43] dual-core a9 [08:43] sebjan: We're at 7hr per arm flavour ATM [08:43] amitk: right, i don't see any improvment [08:43] * amitk wonders if we should to some study about how I/O bound this is [08:43] amitk: maybe NFS is the bottleneck [08:44] NFS? [08:44] hmm, I'm curious what omap4 hardware. [08:45] my gripe with the ARM stuff is that the 3D stuff is often blobby (and not nvidia okay blob, but PowerVR doesn't-even-build blob) [08:46] amitk: hehe, sebjan is using NFS with omap4 hardware as rootfs, so i guess it is building via NFS [08:46] DanaG: powervr for omap3? [08:47] cooloney: ok, that could be reason if the source are on NFS [08:47] amitk, i'm building a native kernel faster (no package though) [08:47] and on SD [08:47] yeah, beagleboard. The TI PowerVR Makefile tries to make clean on a hardcoded target dir that doesn't exist. [08:47] create it :) [08:47] ogra: want to try a 'debuild -b' of the lucid package on your shiny board? :) [08:48] amitk, will do that on the weekend, currently i need the board with constant reboots (testing jasper) [08:48] ogra: how is panda compared to normal bb? [08:49] hmm, I wish there were an Ubuntu phone. [08:49] yes, I access the sources over NFS. I will give a try on SD card. [08:49] hrw, compared to normal bb ... hmm normal bb is on my desk, panda is in shipment ... if that suits you as comparison :) [08:49] Panda? Is that a code name? [08:50] ah ok [08:50] should arrive today/tomorrow though [08:50] i had some customs issues [08:50] ogra: ah, right - you told that before [08:50] hi zyga [08:50] DanaG: run ubuntu on n900? [08:50] hrw, hi, how are you [08:51] ah, surprised I didn't think of that. [08:51] Oh yeah, and my criteria for "Useful 3D" is Compiz. [08:51] zyga: fine thx. forgot that we have long weekend in Poland and wanted to visit one place... kissed door handle ;( [08:51] Or at least accelerated metacity compositing would be good. [08:51] DanaG: n900 uses omap3 so powervr glx libs [08:52] compiz uses full GL afaik, you wont make it work properly on GLES i guess [08:52] hrw, I need to visit some government place next week, I figured trying to go there today would be a waste of time [08:52] ~curse gcc4.5 configure [08:52] zyga: it was 10-15 minutes walk with daughter [08:52] ah, poland had a bank holiday too yesterday ? [08:53] Bummer... that old "XGL" would be exactly what we'd need. [08:53] Implement that on GL ES... [08:53] germany only had it for half the country (mainly the catholic parts) [08:53] ogra: yes [08:54] ogra: in theory Poland is catholic country [08:54] hrw, what's wrong with configure :-) [08:54] zyga: ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest > /dev/null 2>&1 [08:54] zyga: ${CC} == gcc in that case [08:54] mmm [08:55] so what's wrong with this line? [08:55] zyga: but --target=arm-linux-gnueabi [08:55] zyga: it should use arm-linux-gnueabi-gcc [08:55] oh [08:55] but I have to check one thing more [08:55] hrw, apt-get source x-loader-omap4 and look at debian/rules [08:55] cross vs native all over agian [08:56] i think there is a solution in it [08:56] ogra: you want me to have nightmares? [08:56] ogra: I think that it uses proper cc and inproper objdump [08:56] one coffee later I will solve [08:56] right, look at the rules there, it solves that [08:56] gracias my friend [08:56] u-boot-omap4 has the same snippet [08:57] so tomorrow is BBXM premiere? [08:58] I'm still wondering where all of Marvell's stuff is. Not out yet. [08:58] ogra: maverick/arm only source? [08:58] yep [08:58] is omap4 cortex-a8 or cortex-a9, I'm confused [08:58] my adm64 fetched [08:58] well source is arch agnostic [08:58] markos_: a9 [08:59] hrw: cool, it will have a fast fpu [08:59] markos_: it has already [09:01] hrw: I mean because it's based on a9 :) [09:01] ok [09:02] markos_: I hope that storage i/o will not kill omap4 [09:02] markos_: as it is SD or USB only as options for storage [09:03] yes, that sucks [09:03] well, one can connect a fast disk on usb2 but that negates the advantage of its small size [09:03] now I am running bb/c3 with rootfs on usb stick, 40GB 2.5" pata drive on usb as storage [09:04] yeah, marvell's stuff has SATA.... but the currently-available ones won't run lucid. [09:04] markos_: small size of BB is disadvantage when you use it as devboard [09:05] 17.8MB/s from pata drive is not that bad (hdparm -Tt) [09:05] my efikamx here has flash on ata and it's quite fast, much faster than the sd [09:05] yes, sth like that, SD gets 10MB/s max [09:06] time to check OE gcc patches === ericm|ubuntu is now known as ericm-afk [09:20] hrw, I did some benchmarks on netbook [09:20] hrw, my BB pulls solid 20MiB/s from 2.5" SATA HDD [09:21] zyga: via usb2 you mean? [09:21] markos_, yes [09:21] _and_ it was two USB hubs away from BB [09:21] well, that's not surprising, usb2 can get up to 400Mbps [09:22] zyga: I have 3.5" sata hdd in usb2/sata case. does 110MB/s over sata and is able to max sheevaplug usb connector with 40-50MB/s. did not tried it with beagleboard [09:23] zyga: I get ~25MB/s here, on an old 40GB in a pata ->usb case [09:24] but that's not very important, the thing is that BB's internal storage is slow, and fast SD cards aren't avaialble yet [09:29] * gsnedders wonders how fast he gets over NFS [09:35] zyga: That's still relatively far from what a common intel system with SATA can do (75 MiB/s or so I'd expect) [09:35] It's decent, but it's one of the bottlenecks [09:36] CPU speed is one as well on beagle, but with GHz SMP it should be better [09:36] lool, if you attach SATA SDD the speed can go even higher [09:37] lool: the bottleneck is usb2 not the disk, no matter how fast the disk is, usb2 will max at ~40MB/s [09:38] markos_: Yes, I know [09:38] markos_: that's why I mentin SATA [09:38] lool: it's not a fair comparison :) [09:38] mmm [09:38] heh.. oom on 8gb ram.. [09:38] The only ARMv7 SoC with native SATA that I've seen is dove [09:38] * zyga notices nitl netbook got cheaper [09:38] markos_: it exists, but it's hard to find [09:38] lool: imx53 is supposed to have sata as ell [09:38] does anyone know what how they roll their software? [09:39] markos_: Isn't it fake SATA on USB as on imx51? [09:39] or SATA over PATA or something equally poor [09:39] * ogra_cmpc thought imx53 only has PATA [09:39] good question, i don't know [09:39] markos_: babbage had a SATA connector, but the soc has no native SATA; it was USB behind it IIRC [09:39] in the SoC, not sure how its exposed to the outside, might be a SATA socket [09:39] So same limitation [09:40] http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX535&nodeId=0162468rH31143ZrDR988D [09:40] well, SATA over PATA might imnprove it [09:40] doesn't say if it's over USB though [09:41] babbage (imx51) is definately USb [09:41] 53 has a PATA bus but i dont think a SATA one [09:41] markos_: I checked the PDF brief, and it mentions PATA *and* SATA connectivity [09:42] PATA is not even mentioned in iMX515 page [09:42] http://cache.freescale.com/files/32bit/doc/fact_sheet/IMX535ANNCMNTFS.pdf [09:42] so I guess iMX53 does include PATA/SATA on the chip [09:42] markos_: Do you have an idea of timeline to availability of imx53? [09:43] http://cache.freescale.com/files/32bit/doc/fact_sheet/IMX515FS.pdf [09:43] imx51 mentions PATA [09:43] (well it mentions ATA) [09:43] the text below the diagram mentions P-ATA [09:44] no sorry, but I understand samples will be available to Genesi before the end of summer === cooloney is now known as cooloney-afk [09:48] Rob mentioned late this year for something that we could buy [09:48] All: j'ai mis a dispo un pre-kernel L24.7 sur le serveur dans www/releases/L24.7/pre-release (sans les modules, mais c'est pas genant pour booter et faire des builds) [09:49] oops... sorry :) [09:49] 24.7? wow [09:49] tell me it aint linux 2.4.x! [09:50] lool: :) [09:54] lool: 24.7 is internal TI version number [09:55] its actually 2.6.33 + TI stuff [09:56] asac, ping [09:56] asac, I need to be able to display package build failures, is there an interface to harvest that data? [09:57] zyga: you mean in ppas? [09:57] asac, mmm I mean our 'derived archive' concept [09:57] fta: ^^ ... i know you recently did that with our daily builds, do you have input? [09:57] let's say you setup a linaro spinoff [09:57] asac, with your own 'archive' [09:57] and dashboard to see how it works [09:58] so this dashboard needs to know _all [09:58] _all_ packages you have in the archive [09:58] including daily package changes (new uploads/rebuilds) and build failures [09:58] zyga: i think the problem is that there are no derived archives yet so we cant tell for sure what will happen. however, i know that there is an api for ppas and i would assume you can do the same for a real archive [09:59] zyga: you could also talk to the ubuntuwire folks ... and see how they maintain: [09:59] asac, can you give me any pointers to PPA APIs? [09:59] http://qa.ubuntuwire.com/ftbfs/ [09:59] zyga: i havent used it, but fta has ... i think he will reply when he is available [09:59] zyga: otherwise you can ask on #launchpad [10:00] let me see if i can find who is maintaining ubuntuwire [10:00] ogra_cmpc: do you know? [10:04] http://qa.ubuntuwire.org/ [10:04] wow [10:04] coooooool [10:11] asac, stgraber [10:12] though he is not responsible for the ftbfs page [10:12] zyga: yep. so talk to stgraber ... he is your friend for sure [10:12] ask in #ubuntu-motu [10:12] zyga: you can find him in -motu or -testing [10:12] zyga, http://qa.ubuntuwire.org/ftbfs/source/ [10:12] ogra: i asked in -motu ... didnt get anything back yet [10:13] there is the code [10:13] zyga: I would hope such spinoffs aren't needed, sadly things like arm11 support will only come that way [10:13] zyga: go to #ubuntu-motu ... and ping geser [10:13] i prepared him that you will ask him a few questions ;) [10:17] asac, so did you make a decision about LinuxTag ? [10:19] asac, ogra: I know stgraber, I traveled with him to the UDS :-) [10:19] * zyga switches networks [10:19] zyga, ah, nice [10:20] ogra: dates? [10:20] 8th to 12th (next week) i'll go there from thu to sat [10:21] the beagle community will be there, surely worth to meet them [10:24] I am considering going there but need to check program more [10:25] beer in the evenings [10:25] and likely good weather [10:25] isnt that enough as a good program ? [10:25] ogra: sure, but need to convince slangasek too [10:25] heh [10:26] bribe him with beer :) [10:27] pretty sure the company can buy you beer for a lot cheaper than they can get you a hotel room, if that's all you're after ;) [10:27] lol [10:27] ;d [10:30] slangasek: I need to convince myself too - my car probably be ready to get it from service next week. and this can higher priority for me then going to LT [11:24] ogra: tell me, is there any serial number inside an ARM CPU? [11:24] ogra: please tell me there is [11:25] zyga: depends on SoC [11:25] zyga: but only some offers such function [11:25] zyga, what do you want to achieve ? [11:26] ogra@babbage2:~$ cat /proc/cpuinfo |grep Serial [11:26] Serial : 0000000000000000 [11:26] ogra: well basically, device identification [11:26] zyga, look at flash-kernel [11:26] ogra: uboot shows some serial number [11:26] zyga: not really, is the answer [11:26] could be more fine grained but its already pretty good [11:26] mmm [11:26] okay [11:26] another question [11:26] it isn't foolproof [11:27] fw_setenv/fw_printenv [11:27] can I put UUID inside and assume it will be more-less portable? [11:27] that I can fw_setenv my_env=UUID on all devices (somehow) [11:27] well, you usually never touch the root= cmdline option after install [11:27] again look at flash-kernel [11:28] ogra: I'm looking for something outside the FS, if you reinstall the filesystem UUID is gone [11:28] this time the flash-kernel-installer.postinst script, thats what d-i and ubiquity execute during installation [11:28] zyga: so you want to be able to identify HW? [11:28] yes, exactly [11:29] I'm looking for a foolproof way to provision devices [11:29] flash-kernel --supported :) [11:29] JamieBen1ett: what happened to arm-m-liquid spec? did that get dropped when moving it from ubuntu-arm to ubuntu? [11:29] or who was leading that moving effort? [11:29] asac, rbelem [11:29] oh, he was leading the spec :) surely not the moving [11:30] zyga: how you identify x86 boxes? [11:30] hrw, you dont need to [11:30] ogra: yeah. seems it got renamed back to mobile-m [11:30] thats why flash-kernel exists :) [11:30] i will rename it back as we are embracing it [11:30] yeah [11:30] we dont have it on the trachker even [11:30] *tracker [11:30] asac: https://blueprints.launchpad.net/ubuntu/+spec/mobile-m-liquid [11:30] asac: Was renamed to mobile- [11:31] yes, i take it back as i am approver and dont want to make naming complicated [11:31] ++ [11:31] we also dont have manpower to care for it in mobile [11:32] dropped a note why that name was choosen (technical burndown purpose etc) [11:32] so hopefully they dont feel offended by being arm-m ;) [11:35] hrw, I don't identify x86 boxes [12:20] ogra: asac: hi. quick question on packages... I need to write a xxx.install file in my package to split into multiple bin packages. in ubuntu gstreamer, the xxx.install file has debian/tmp/usr/lib... when I build my pacakge I don't have debian/tmp subfolder, but debian/xxx instead. and my package fails to build. where does this tmp come from? [12:22] ndec, omit debian/tmp and it will work [12:22] ogra_cmpc: i tried this as well, but without the leading '/' and it did not work [12:22] ndec: yeah. omit that debian/tmp [12:23] hmm, it should work [12:23] ndec, can you paste a line from your current .install file [12:24] debian/tmp is automatically used by debhelper if you have multiple binary packages in control [12:24] right [12:24] if you have just one it usually installs all in the target package [12:24] now i wonder how to filter stuff out ;) [12:24] hopefully there is magic that still allows .install ;) [12:24] by dirs in .install or specifying the actual single files [12:24] * asac hasnt done a single binary package for a long time it seems [12:25] asac: ok, i see... i do want more packages, but I only added 1 in control for now.. I was planning to add the 2nd one later ;-) [12:25] that shouldnt make a difference [12:25] ndec: yeah. just add a second. but even then the debian/tmp isnt needed anymore [12:25] if you have a modern compat level [12:25] e.g. put 7 in debian/compat [12:25] * ogra_cmpc does single binary files all the time [12:25] s/files/packages [12:25] yeah. ogra is always going for the simple stuff ;) [12:25] hehe [12:25] asac: is the leading '/' needed if I omit /debian/tmp? [12:26] no [12:26] doesnt matter iirc [12:26] both should work [12:26] ogra_cmpc: well, in fact I need a package for -dev for header files [12:26] if you add usr/lib/ it will install everything below debian/tmp/usr/lib in your package [12:27] then you need to add some more fine grained magic and also have different .install files [12:27] you usually put usr/lib/*.so.* in the lib .install ... and usr/lib/*.so and usr/include in the -dev [12:27] (matching the entries in debian/control) [12:27] assuming you use autotools with -version-info to versoin the lib properly [12:31] asac: ogra_cmpc: thanks. I have added the -dev, and started a rebuild. [12:31] good luck :) [12:32] amitk: I'd like to generate kernel source and binary packages, but with a name like 2.6.33-900.1~ti+release0. What files do I need to edit for that? (debian/changelog is re-gerenated by the debuild command) [12:37] sebjan: you need to do a debian/rules clean, 'git clean -df' to get a clean tree, edit debian.ti-omap4/changelog to change your version number, This time debuild -b should DTRT [12:39] sebjan: you can run 'debian/rules clean' before the build to make sure your debian/changelog reflects your changes correctly === amitk is now known as amitk-afk [12:41] amitk: ok, thanks, it seems fine! === amitk-afk is now known as amitk [14:23] robclark, hey, whats the branch you built the u-boot from which i got from you with the blaze ? seems the omap_dev branch doesnt work on the panda [14:23] (omap4_dev) [14:24] ogra: there are some panda patches.. I'm not sure they are all integrated back in u-boot tree.. [14:24] oh, you applied them manually to your build ? [14:24] and I guess the x-load/u-boot on the blaze is a bit older, so for sure won't have the panda patches [14:24] yeah.. I can mail you the patches I have [14:24] well, the two binaries you gave me work fine [14:25] really? [14:25] but from the stuff i packaged in ubuntu only MLO works [14:25] oh.. yeah, that is right.. [14:25] u-boot exits with: ** Can't read from device 1 ** [14:25] the MLO/u-boot I had on that card was actually the panda version.. [14:25] it starts though, but there seems to be an issue with mmc [14:26] ok.. if you want to build something that actually works on panda, I think I should send you the patches [14:26] http://paste.ubuntu.com/444610/ is what i get with the packaged binaries [14:26] works on blaze [14:26] which you could apply on top of dev.omapzoom.org tree.. [14:26] ok [14:38] hrw: ayt? [14:41] hrw: ayt? [14:42] hrw: where can i have a look to the patch merging binary-cross target into binary for binutils? is that affecting debian or is it only ubuntu thing? [14:43] zumbi: it is integrated in next ubuntu binutils package release [14:43] zumbi: moment and I will give you bug link [14:43] zumbi: https://bugs.launchpad.net/bugs/587851 [14:43] hrw: please update README.cross file and if you care, please fill a bug report on `buildcross` the tool for getting cross tools built (now, in debian/experimental) [14:43] Launchpad bug 587851 in binutils (Ubuntu) "merge cross build into "binary" target (affects: 1) (heat: 8)" [Undecided,Fix released] [14:44] zumbi: ok [14:44] hrw: thanks nad thanks for the merge :) [14:45] zumbi: will have to check that buildcross tool [14:45] zumbi: I got gcc-4.5 crossbuilt today [14:45] zumbi: http://paste.ubuntu.com/444614/ was needed on my system to get gcc 4.5 cross built. [14:47] interesting, i have not tried 4.5 [14:47] hrw: make sure cross-fixes and cross-include patches are up to date [14:47] maverick base libs has from 4.5 [14:47] zumbi: cross-fixes got update - sh part needed dropping [14:48] zumbi: merged it latest gcc-4.5 ubuntu package so I think that doko will merge it back to debian [14:49] hrw: sure, thanks, you are doing great! Let me know if you want to hack on buildcross code too, for getting cross tools built [14:50] at least I will look at it [14:50] http://www.emdebian.org/repos/current/host/trunk/buildcross/trunk/ [14:50] or http://www.emdebian.org/svn/browser/current/host/trunk/buildcross/trunk [14:53] looks interesting [14:55] hrw: it could be used for daily builds to see if toolchains are fine [14:55] and it needs more love. I have great plans for it, but -ENOTIME [14:55] common problem [14:55] bb in few [14:57] btw - Stylish extension to firefox roxx - whiteboard in blueprints is now 2x wider D: === bjf[afk] is now known as bjf === Hrww is now known as hrw [15:42] zumbi: buildcross lacks deps on embedian-tools, dpkg-cross dep needs to be versioned [15:42] zumbi: grep-dctrl is also checked for being installed [15:45] zumbi: and it needs to run as a root ;( [15:48] hrw: why does it need emdebian-tools (which has also been deprecated) [15:49] dpkg-cross and grep-dctrl, agreed [15:49] zumbi: it checked for those [15:50] hrw: and it needs root to install packages, i have not tested, but i was planning to start using fakechroot stuff [15:50] you can not build gcc, without installing binutils :-/ [15:50] any idea how to work that arround? (besides looking fakechroot) [15:51] I plan to depend on *-source packages and call them one by one + temporary install dirs [15:51] btw - i am updating my launchpad info, to work better with you [15:52] so you would do "apt-get source cross-toolchain; cd cross-toolchain*;echo armel >debian/target;dpkg-buildpackage" [15:52] and this will build linux-libc-dev, binutils, gcc, eglibc [15:52] hrw, and how do you plan to get cross libraries? [15:52] are you going to bootstrap glibc headers? [15:52] yes [15:53] zumbi: buildcross suggestions: s/-v/-V/ and make -v == --verbose (display logs on screen) [15:53] hrw: lool had some code in his ppa and i have splitted that into packages into git repo, http://emdebian.org/git/ [15:53] zumbi: and for now small check at start "am I root" check [15:54] thx [15:54] look under packages/.. [15:54] those are not perfect, but a start [15:55] zumbi: any readmes for them? [15:55] readmes? what do you mean? what for? [15:56] those just build in a standard debian way [15:56] sorry, looked at wrong page [15:58] hrw: hint, if you need some buildcross ubuntu changes, $ debcheckout buildcross, make-a-patch :-) [15:58] you would need a deb-src line for debian experimental archive [15:58] zumbi: need to make ubuntu vm for it first [15:58] zumbi: already fetched sources from p.d.o/buildcross [15:58] vm as virtual machine? [15:58] yes [15:59] we usually work on chroots, done by debootstrap (or newer multistrap) [15:59] I do not like to run root-automats on my normal systems [15:59] do you know debootstrap? [15:59] I know [15:59] ok, sorry :) [16:00] np [16:10] hrw: actually you do not need root, but sudo on apt-cross and dpkg [16:11] hrw: it is not good idea to build packages being root [16:12] hrw: do you think just a warning would be fine? [16:13] yep [16:31] hrw: `buildcross-0.0.2` released. Uhmmm, I forgot to thank you (will do on next release) [16:31] no problem [16:31] zumbi: you use some scm for it? [16:32] svn [16:32] ah. sorry, you gave me link [16:32] yes, also if you have devscripts package you could use debcheckout [16:33] but you need to add deb-src line for debian/experimental [16:33] ok [16:34] zumbi: scm allows me to look at patches etc [16:34] git-svn uber alles [16:34] yet another git fanboy :) [16:35] zumbi: I like to be able to make commits without going to server [16:35] then use debcommit [16:35] oh! nevermind [16:36] yes, i also like git, but sometimes it is over abused [16:36] btw - "gcc-4.4" instead of "4.4" maybe? [16:37] uhm.. i am not sure about that one, as we do not use package names, like `libs` [16:38] but you have 'binutils' not '2.20.51' [16:38] well, I'll have a look [16:39] I have a patch [16:40] oh! great, then tell me how to fetch it :) [16:40] moment [16:47] zumbi: http://paste.ubuntu.com/444686/ === amitk is now known as amitk-afk [16:56] hrw: Committed revision 7278 [17:02] http://paste.ubuntu.com/444700/ adds help for --verbose [17:02] rcn-ee, not sure if this is a kernel problem or not yet, but I'm getting unexpected oom failures in 2.6.34-l0 [17:02] hrw: thanks, that is already done [17:02]