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