#ubuntu-arm 2009-01-22 <ChEx> Hello everyone. <ScriptRipper> hi, <ScriptRipper> it got now Jaunty 9.04 with HDMI output on LCD, Keyboard, Mouse, Networking, xubuntu-desktop files installed and xfce login running <ScriptRipper> on my beagleboard.... <ScriptRipper> using the linux kernel package "linux-image-2.6.27-oer4_1.0hasty_arm.deb" <ScriptRipper> ogra, persia: are you happy with that? <ogra> sure, i run the same here :) <ian_brasil> dunno about ogra and persia but i sure am happy about that <ScriptRipper> ogra: you use a beagleboard? <ScriptRipper> ogra: the same image works with QEMU also. <ScriptRipper> ogra: i only use another kernel for that <ogra> i have a beagle here among a bunch of other arm hw <ScriptRipper> ogra: what kind of windowmanager etc. do you use with 128 MB of RAM? <ScriptRipper> ogra: even xfce is using quite a lot of memory for the beagleboard <ogra> xubuntu-desktop <ogra> on a udb disk, with 512M swap <ogra> *usb <ScriptRipper> me here: Swap: 658656k total, 100928k used, 557728k free, 24868k cached <ScriptRipper> swap is on my Flash memory card <ScriptRipper> which is in fact suboptimal .... <ogra> yep <ogra> usb disks are chep <ogra> *cheap <ogra> though you need a powered hub ... * ogra goes back to dinner <ScriptRipper> I have a powered hub also running here. <ScriptRipper> otherwise I could not get Ethernet working... <ScriptRipper> I was told by the TI people that I should not start without a powered USB hub... <jkridner> is there a place where I should get the latest build for the beagleboard? #ubuntu-arm 2009-01-23 <ScriptRipper> jkridner: its the normal build from ports.ubuntu.com, with the "linux-image-2.6.27-oer4_1.0hasty_arm.deb" kernel package. <ScriptRipper> jkridner: I bootstrapped it on the mojo hard with debootstrap <ScriptRipper> jkridner: sorry, i meant: mojo hardy and then some expansive handywork... because the installer is not yet working, and involving lots of waiting due to QEMU <ScriptRipper> jkridner: maybe we can talk about this tomorrow, because i ll leave now.... <ScriptRipper> jkridner: and our ubuntu guys here want to have some first 2.6.28 kernel ready soon (or even have already) <ScriptRipper> NCommander: hi! <NCommander> hey ScriptRipper <ScriptRipper> NCommander: http://lists.opensuse.org/opensuse-buildservice/2009-01/msg00292.html :D <ScriptRipper> NCommander: what do you think ? <NCommander> yay for sane support :-) <ScriptRipper> which of the 3 options you would opt for? <NCommander> ScriptRipper, I'll tell you once I finish showering <ScriptRipper> ok.... * ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | <suihkulokki> is there gym excersizes to make ARMs faster? | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch <ogra> persia, do you think it makes sense to put a link to https://wiki.ubuntu.com/ARM/RootfsFromScratch on https://wiki.ubuntu.com/ARM ? <persia> Very much so. I'd add an item to the FAQ, and link from that. <ogra> col, thanks <ogra> *cool even <persia> If you'd like to review the rest of the questions, and make sure they aren't out of date, that'd be grand too :) <ogra> to sad xubuntu-desktop is brken atm ... i'd put an example log up on people <ogra> but something seems wront with tango <persia> Well, if you're into yak shaving, you could just fix xubuntu first ... <ogra> pfft <ogra> persia, i thinnk i'll leave that to xubuntu devs like NCommander :) * ogra tries an lxde build <persia> Missing lxtask, at least <ogra> we'll see <ogra> i just want to know which builds complete <ogra> xubuntu used to work last weekend <ogra> lxde is likely intresting for n8x0 users <persia> Very much so. <persia> It's just that some portions of the lxde environment aren't packaged yet. <persia> Or rather, that the packages aren't in the repo. <ogra> yep <ogra> ogra@osiris:/var/build$ ls -lh /var/build/armel-rootfs-200901231724.tgz <ogra> -rw-r--r-- 1 root root 151M 2009-01-23 18:02 /var/build/armel-rootfs-200901231724.tgz <ogra> not bad ... lxde desktop ... #ubuntu-arm 2009-01-25 <Stskeeps> anyone expericing HAL crashes on armel? <persia> Stskeeps, I haven't seen that. Can you reproduce with a stock rootfs? <Stskeeps> mm, things might be a bit special since it's on the nokia tablets, i'll see if i can reproduce in a second <persia> Stskeeps, If you can reproduce, even on the tablets, with no extra-repo patches to HAL, it's probably worth filing a bug. <Stskeeps> *nod* we didn't touch HAL whatsoever, so <persia> In that case, it's probably a valid bug. While there's no kernel that works on those, it's certainly one of the devices considered for the port. <ian_brasil> persia: doesn't the maemo kernel work? <persia> ian_brasil, Sure, but I don't think we can file bugs on the maemo kernel on LP. <persia> Or at least not against Ubuntu. <ian_brasil> true * Stskeeps unpacks newest rootfs * Stskeeps ponders where to find dbg package for ha <Stskeeps> l <persia> With debug symbols? <Stskeeps> yeah <Stskeeps> not sure there is one :) <persia> There's a repo for them johncrosby@example.net I think. I'll try to dig up the wiki page <Stskeeps> we both have the HAL problem (fixable by using older version) on the very-close-to-ubuntu-rootfs and mer, so :P <persia> https://wiki.ubuntu.com/DebuggingProgramCrash <Stskeeps> thanks <persia> Crash is with 0.5.12~rc1-0ubuntu7 ? <Stskeeps> 0.5.12~rc1+git20090120-0ubuntu1 , most recent <persia> Oops. Forgot dpkg version ordering != ASCII sort order :) * Stskeeps grabs his trust dbg <Stskeeps> er, gdb <persia> You might also try apport, especially if you're filing the bug. I like it because it automates the extraction of the stack trace post-crash, without needing to run gdb on the process. <Stskeeps> k, will read up on it <persia> Needs kernel support though, which may or may not be possible in your environment. <persia> https://wiki.ubuntu.com/Apport <Stskeeps> curious, crash in leds_add <Stskeeps> looking further <jonpackard> Ogra - I see you've updated your build-arm-rootfs script.. want any help testing it? <jonpackard> Or if anybody else would like some help testing anything.. I'm fairly experienced with running an arm system with qemu ;-) <Stskeeps> http://rafb.net/p/Qw09fQ38.html <- occasional HAL crash i'm running into <jonpackard> Hello. Has anybody had success with X in qemu with Jaunty-armel yet? I'm still getting the problem with no keyboard or mouse repsonse once X starts. #ubuntu-arm 2009-01-27 <doko_> somebody aware of the hal install failure on armel? causes build failures on the buildds (openjdk-6) <ogra> install failure ? <ogra> it installed fine yesterday here in a local bootstrap <doko_> ogra: https://edge.launchpad.net/ubuntu/+source/openjdk-6/6b14-0ubuntu10/+build/848818 <ogra> thats udev, no ? <ogra> cat: /sys/kernel/uevent_seqnum: No such file or directory <ogra> invoke-rc.d: initscript udev, action "restart" failed. <ogra> dpkg: error processing udev (--configure): <ogra> subprocess post-installation script returned error exit status 1 <doko_> maybe <ogra> well, i pinged keybuk ... <suihkulokki> ogra: that'n nutty, buildd's shouldn't be installing hal/udev to the build chroot. <suihkulokki> ogra: check which package is pulling them in <ogra> suihkulokki, its already fixed in udev <ogra> udev shouldnt start if installed in a chroot <ogra> there are packages that depend on stuff that in turn depends on hal <ogra> so you cant really avoid things like that <ogra> packages like hal, dbus and udev need special casing <suihkulokki> no <Stskeeps> shouldn't they "just" fake invoke-rc.d and start-stop-daemon? :P <ogra> all of xorg depends on hal <suihkulokki> you build-depend on libhal-dev libdus-dev etc <ogra> Stskeeps, thats what they do, but udev had a bad grep in the posinst before <suihkulokki> and none of those -dev packages should pull their respective daemon in <ogra> feel free to look at the build log <ogra> but i know the fix got into udev already so that might be moot <ogra> http://launchpadlibrarian.net/21658731/buildlog_ubuntu-jaunty-armel.openjdk-6_6b14-0ubuntu10_FAILEDTOBUILD.txt.gz <ogra> https://lists.ubuntu.com/archives/jaunty-changes/2009-January/003929.html is the fix <suihkulokki> ogra: that's fixing the symptom, not fixing the root of the problem - ie. "why is udev getting installed in the first place" <ogra> probably becuse the package needs a running X env ... we have a bunch of packages that need xvfb for example ... <ogra> dont ask me, i'm neither maintaining the buildds, nor maintain the openjdk package nor am i resonsible for udev :) <ogra> and the udev maintainer obviously considered that fis as appropriate <persia> suihkulokki, Probably a side effect of recommends-by-default <suihkulokki> persia: ...which is why recommends-by-default is not used on buildd's ;) <suihkulokki> at least, on debian that is <ogra> beyond fixing that particular buildd issue it will also fix chroot building in general (in case you dont have sysfs mounted in your chroot during bootstrapping) <ogra> well, ubuntu doesnt use dak :) <persia> suihkulokki, Heh. Well, that's one way to fix it. <persia> Personally, I'd rather it did, because many maintainers seem to build packages on their personal local systems, with all sorts of random stuff installed, and certainly recommends. <persia> Mind you, this is getting *lots* better, but still. <suihkulokki> ogra: I don't claim that udev bug was not worth fixing - merely that there is most likely still a unnecessary depends somewhere <suihkulokki> but if you don't care, whatever. <ogra> suihkulokki, well, ask doko_ about it ... :) <ogra> he was bringing it up since he tried to build openjdk <ogra> no idea what pulls it in <doko_> suihkulokki: pulseaudio sucks it in <persia> And pulse needs to do device analysis if the daemon is running. <persia> doko_, Why does OpenJDK need both libpulse-dev and pulseaudio to build? Would libpulse-dev itself not be sufficient? <persia> Is this for the test suite? <doko_> AC_DEFUN([FIND_PULSEAUDIO], <doko_> [ <doko_> AC_PATH_PROG(PULSEAUDIO_BIN, "pulseaudio") <doko_> if test -z "${PULSEAUDIO_BIN}"; then <doko_> AC_MSG_ERROR("pulseaudio was not found.") <doko_> fi <doko_> AC_SUBST(PULSEAUDIO_BIN) <doko_> ]) <persia> Blech. No helping it then, really. * suihkulokki grumbles <suihkulokki> 1) i would still check if that configure check can be fixed <suihkulokki> 2) if pulseaudio does really need to depend on hal <suihkulokki> then again, if the build system is pulling in recommends, this ranting is completly moot <ogra> there are more packages like that <ogra> all the stuff that uses xvfb for their test suites will run into the same now that xorg hard depends on hal <ogra> i think you should start to consider it a common case that udev *might* show up in buildd chroots <suihkulokki> that depends on how much you care about quality and bloat <ogra> well, self tests can improve the quality ... so i'D rather call it a philosophical thing :) <suihkulokki> I doubt even with current xorg xvfb would really hard-depend on hal <suihkulokki> so in other words, someone took the lazy route <ogra> xvbf runs X <ogra> and X needs hal to run <ogra> *vfb * ogra humms "times are changin ..." * suihkulokki humms unverified bullshit <ogra> heh <ogra> well, fix X to not use hal ... but i doubt upstream will accept any patches that revert this behavior ... they made quite a hard cut and dropped much backwards compatibility with this release <suihkulokki> you are confusing the dependency on libhal and dependency on hald <ogra> xorg moaning loudly if hald doesnt run doesnt help though :) but right, it doesnt have a dep on hal itself <NCommander> hola <ScriptRipper> NCommander: hi <NCommander> hey ScriptRipper <ScriptRipper> Did you think about the e-mail for the apt repo layout? <ScriptRipper> NCommander: your last comment was: i think about it under the shower, if i remeber correctly :) <ScriptRipper> NCommander: what did your shower say :) <NCommander> ScriptRipper, "ack, it burns" #ubuntu-arm 2009-01-29 <ScriptRipper> persia, ogra: how far did you come with the new kernel? * persia doesn't tend to do much kernel stuff <ScriptRipper> persia, ogra: I had a whish for you: a patch for a DVB-USB Frontend patch that seems not to be in the kernel officially <ogra> ScriptRipper, we were more focusing on images than on kernels atm ... (kernels are done by the ubuntu kernel team and in the works) <ogra> ScriptRipper, thats something that can be discussed if linux-omap is merged ... currently the focus is to get the existing debian arches proper <ogra> linux-omap will likely take another week or so <ogra> (have a look at http://cdimage.ubuntu.com/ports/daily/current/ ;) we have our first iso (no kernels on it yet)) <ScriptRipper> i can also build a kernel myself, no problem. this is not my first time. <ScriptRipper> i would just need the sources with the build kernel.. <ogra> just use the linux-omap tree <ScriptRipper> ok * ogra twiddles thumbs ... <ogra> ... watching d-i .... #ubuntu-arm 2009-01-30 <ogra> ScriptRipper, so i found the missing bit that caused mouse/kbd not to work, CONFIG_INPUT_EVDEV is missing in the kernel, the new hal infrastructure for X needs that <ogra> next kernel upload will have it <ScriptRipper> aha. <ScriptRipper> that was the reason why, I have to use 2.6.27 atm - right? you talk about 2.6.28? <ogra> yes <ogra> next upload will be there latest by monday <ScriptRipper> i was a bit confused, because i have mouse and keyboard running - ... <ScriptRipper> first <ScriptRipper> ok. #ubuntu-arm 2010-01-01 <mshooshtari> Hello <lool> zumbi: -Os doesn't work with eglibc itself, but not to build e.g. chromium <lool> zumbi: ISTR it's due to assumption on symbol visibility or something <zumbi> lool: aurelien told me (when migration to eglibc) that it was exposed to support -Os <zumbi> s/exposed/supposed to support/ * zumbi has never tried <lool> Oh yeah, indeed, eglibc probably fixes that over glibc anyway <asac> armin76: works for me with O3 ... only strict-aliasing is a prob in v8 on arm as it seems <asac> gcc 44 works too (tested locally) <cwillu_at_work> question: are there updated/trunk/newer-than-febuary09 libpixman debs available anywhere? * cwillu_at_work looks at http://www.emdebian.org/grip/search.php?package=libpixman-1-0&arch=&distro=sid * cwillu_at_work is curious about the state of neon accelerated blitting <cwillu_at_work> bug #385553 has some details, but ends with a cliff-hanger <ubot4> Launchpad bug 385553 in pixman "Integrate NEON optimisations for armel" [Wishlist,Confirmed] https://launchpad.net/bugs/385553 #ubuntu-arm 2010-01-02 <lool> cwillu_at_work: It's in lucid now <lool> cwillu_at_work: I updated the bug, thanks <cwillu_at_work> lool, I noticed a bunch of neon stuff in pixman git head , mid/late december <cwillu_at_work> would those be included? <lool> cwillu_at_work: This bug only mentions earlier NEON bits though <lool> cwillu_at_work: We currently have upstream release 0.16.2 <cwillu_at_work> which might have the neon stuff simply disabled, if I read the mailing lists correctly <lool> Apparently the latest release 0.16.4 is very similar to .2 and was out mid december <lool> cwillu_at_work: Sorry could you be more specific? <lool> Which NEON bits and which mailing-list? <cwillu_at_work> lool, a moment, just checking a head build <lool> Our pixman is from Sep 2009 so it definitely doesn't have anything from December commits <cwillu_at_work> head still shows some screen corruption of the same sort I saw on 0.15 (and don't on 0.16.2) <cwillu_at_work> doing a quick reboot to check a different display depth <cwillu_at_work> lool, sanity check, is it sufficient to upgrade libpixman/replace /usr/lib/pixman-1-0.so, or does cairo or X or anything need to match it? <lool> It should be sufficient to replace it, but it's not a good idea to replace the /usr/lib lib <lool> Install to /usr/local or create an updated pixman .deb <cwillu_at_work> yep <lool> Otherwise your changes will be lost wiht next upgrade <cwillu_at_work> not my first time around the block ;) <cwillu_at_work> well, first time around the block with pixman, but you know what I mean ;p <cwillu_at_work> giving lucid's a shot <lool> It's probably enough to update just libpixman-1-0 from a karmic install <cwillu_at_work> yep <cwillu_at_work> restarting x <cwillu_at_work> okay, looks like the relevant patches are in lucid's version <cwillu_at_work> or at least, I get the same display corruption under lucids as I did under head and on 0.15 <lool> So you have a regression with NEON enabled pixmans? Not an issue in 0.14.x? <lool> What's your hardware? <cwillu_at_work> lool, for reference, libpixman-1-0_0.16.2-1em1_armel.deb from emdebian.org doesn't have the display cheese <cwillu_at_work> while lucid's and head's does <cwillu_at_work> beagleboard <cwillu_at_work> nope, 0.14.x is fine <cwillu_at_work> running firefox, scrolling a relatively simple page. I get squares of varying patterns obscuring the page as I scroll, different for each redraw <cwillu_at_work> the obscured sections appear to line up with the existing page items, and don't always obscure the entire item <cwillu_at_work> I can post a photo if that's useful <lool> cwillu_at_work: Looks like a toolchain issue <lool> Is libpixman-1-0_0.16.2-1em1_armel.deb patched in any way? <cwillu_at_work> no idea, it's just a random version I found on the web <cwillu_at_work> the head test was compiled on the board itself, not sure if that's relevant to toolchains <cwillu_at_work> (uploading images) <lool> cwillu_at_work: If you grabbed libpixman from http://emdebian.org/grip/pool/main/p/pixman/ then its exactly the same source as in Debian/Ubuntu and only toolchain differ <cwillu_at_work> okay, yes, that's what I grabbed <lool> cwillu_at_work: Could you try rebuilding with gcc 4.3? <lool> (Was the default in Debian until recently) <lool> Either head or lucid's package <cwillu_at_work> k, that'll take a couple minutes <cwillu_at_work> photos at http://cwillu.com/files/arm/ <cwillu_at_work> forgive the filesize, although the pattern is visible in the corruption at that resolution <lool> cwillu_at_work: So the red stripes are corruption? <cwillu_at_work> yes <lool> Oh and number 4 is pretty clear too <cwillu_at_work> the corruption changes from frame to frame, and not every frame is corrupted (in fact, I'd say only about a third of the frames are corrupted, although they can be bunched up <cwillu_at_work> the colour, region, and direction of the pattern change (i.e., angled left vs right) <cwillu_at_work> and it's not clear in the photos, but the corruption begins and ends partway through a given horizontal line <cwillu_at_work> (build is running) <cwillu_at_work> hmm <cwillu_at_work> ./autogen.sh dies with "Illegal instruction" <cwillu_at_work> should I run gcc and company from karmic instead of lucid? <lool> Either should work <cwillu_at_work> (original head build was done with gcc from karmic <lool> But I'm interested in gcc-4.3's build result in any case <cwillu_at_work> well, autogen.sh doesn't even finish <lool> What's your kernel? <cwillu_at_work> one of rcn's <lool> Which upstream version? <cwillu_at_work> Linux overo 156.14.161.142-x1.0 #1 PREEMPT Thu Dec 17 02:23:37 UTC 2009 armv7l GNU/Linux <lool> That's quite good hmm <lool> cwillu_at_work: I'm a bit scared that you get an illegal instruction with lucid + custom 2.6.32 <lool> cwillu_at_work: It's definitely another bug, but I'd like to take a look at that one too <lool> cwillu_at_work: Could you set -x autogen and see which command triggers that? <cwillu_at_work> yep, one sec <cwillu_at_work> autoreconf: configure.ac: tracing <cwillu_at_work> Illegal instruction <lool> cwillu_at_work: autoreconf -v should tell you what it's running exactly <cwillu_at_work> + autoreconf -v --install <cwillu_at_work> autoreconf: Entering directory `.' <cwillu_at_work> autoreconf: configure.ac: not using Gettext <cwillu_at_work> autoreconf: running: aclocal <cwillu_at_work> autoreconf: configure.ac: tracing <cwillu_at_work> Illegal instruction <cwillu_at_work> hmm, that might have been a redherring <lool> ? <cwillu_at_work> what's the right way to use 4.3 instead of 4.4? <lool> CC=gcc-4.3 should work with most sources <lool> If you're building by hand; if you're building packages, you might have to -eCC or set it in rules instead <cwillu_at_work> one moment <cwillu_at_work> okay, things are proceeding now <cwillu_at_work> (I mean, why use an environment variable when I could just install gcc-4.3 and remove 4.4? :p)\ <cwillu_at_work> make[3]: Entering directory `/home/cwillu/work/pixman/pixman' <cwillu_at_work> CC pixman-access.lo <cwillu_at_work> CC pixman-access-accessors.lo <cwillu_at_work> CC pixman-cpu.lo <cwillu_at_work> CC pixman-gradient-walker.lo <cwillu_at_work> ../libtool: line 970: 6075 Segmentation fault gcc-4.3 -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden -MT pixman-gradient-walker.lo -MD -MP -MF .deps/pixman-gradient-walker.Tpo -c pixman-gradient-walker.c -o pixman-gradient-walker.o > /dev/null 2>&1 <cwillu_at_work> make[3]: *** [pixman-gradient-walker.lo] Error 1 <cwillu_at_work> make[3]: Leaving directory `/home/cwillu/work/pixman/pixman' <cwillu_at_work> make[2]: *** [all] Error 2 <cwillu_at_work> lool, * lool whistles <lool> cwillu_at_work: This is kind of unfortunate <lool> cwillu_at_work: You could do the reverse, build under sid + gcc 4.3 and then rebuild against gcc 4.4 <lool> cwillu_at_work: Basically, it's always the same source, so it's the build env which differs; I really suspect gcc here, and it just switched in Debian, but pixman did build with 4.3 in Debian <cwillu_at_work> sorry, I'm confounding things <cwillu_at_work> ran make clean (which I could have sworn I ran before), and now the build proceedeth <cwillu_at_work> build finished, installing <cwillu_at_work> and restarting x... <cwillu_at_work> lool, rebuild under 4.3 still has corruption <cwillu_at_work> git head <lool> Hmm <cwillu_at_work> checkout 0.16.2 and rebuild? <lool> Yeah, it's probably safer to always use the same source * cwillu_at_work rebuilds <cwillu_at_work> geez <cwillu_at_work> oh, no, good <cwillu_at_work> thought I had rebooted and did that last test against 4.4 <lool> So lucid + gcc-4.3 pixman 0.16.2 works? <cwillu_at_work> hasn't finished building yet <cwillu_at_work> I wasn't sure if I had run head against gcc-4.3, but I had <cwillu_at_work> build finished <cwillu_at_work> lool, gcc-4.3 pixman 0.16.2 still has corruption <lool> Hmm <cwillu_at_work> this is on an otherwise largely stock karmic <lool> cwillu_at_work: Well you could try the opposite approach of starting from squeeze which has 4.3, and then rebuilding with 4.4 <cwillu_at_work> lool, not sure I follow <lool> I don't quite know what else than gcc could cause a different in the runtime lib causing corruption <lool> cwillu_at_work: All libs you used were built from the same source, but some have display corruption and some have not; I proposed changing the corrupted build env into a working one by using gcc 4.3, but that didn't work, we could try changing a working build env (squeeze) into a broken one by upgrading gcc to 4.4 <lool> cwillu_at_work: Does that make sense? <cwillu_at_work> okay, so I need a squeeze rootfs? <lool> yeah; just debootstrap it from beagleboard <lool> I'd guess you'll need around 400MB counting build-deps <lool> debootstrap squeeze /path/to/new-chroot <lool> (as root obviously) * cwillu_at_work would have used fakeroot :p <lool> Then chroot into it and apt-get source pixman + apt-get build-dep pixman + apt-get install build-essential gcc-4.3 <lool> s/4.3/4.4 <lool> You mean fakechroot <cwillu_at_work> make any sense to use a git checkout of pixman instead of the apt-get source pixman? <lool> That's possible; it's a debootstrap variant; I don't usually bother fighting this additional layer ;-) <cwillu_at_work> alternatively, should I redo my current work based on an apt-get source checkout? <lool> No, I recommend you stick to a single source, the Debian/Ubuntu source package <cwillu_at_work> (and what's the deb-src line for ubuntu ports anyway?) <lool> If you change the source tree, you should redo all your tests to see which works and which don't (i.e. don't change multiple things at once) <lool> cwillu_at_work: deb-src for ports is just like deb * cwillu_at_work points out that he's been using a git checkout <lool> i.e. http://ports.ubuntu.com/ubuntu-ports karmic main restricted universe multiverse <cwillu_at_work> hmm, I tried that, didn't work <lool> cwillu_at_work: Well you also said you have been using binaries from emdebian and that *these* work <cwillu_at_work> yep <lool> The deb line certainly works for me; did you apt-get update? <cwillu_at_work> just making sure you're not under the impression that I did something that I didn't do <cwillu_at_work> oh, probably not <cwillu_at_work> although I thought I did <cwillu_at_work> (if memory serves, it was the update that didn't like it) <cwillu_at_work> okay, so I'm going to debootstrap squeeze, and then build pixman from apt-get source <lool> Yup <cwillu_at_work> and in the mean time find out if my btrfs root is really as good at load-levelling as I hope it is :p <lool> You might also want to test squeeze's libpixman to be on the safe side <lool> load-levelling? does that relate to wear-levelling? <cwillu_at_work> I'll snag it out of the debootstrap after it finishes <cwillu_at_work> sorry, wear-levelling is what I meant to say <cwillu_at_work> I always start by thinking "load-balancing, no that's not right, load-levelling, that's right" <lool> Not sure btrfs is what you want for wear levelling <lool> It usually causes more writes than other filesystems <cwillu_at_work> not a whole lot of good options for an sd card; mounted with ssd_spread it seems to do a decent job <lool> Oh right, I remember there's an SSD mode in btrfs now <cwillu_at_work> has been for a while now actually <lool> Too bad we don't have the underlying flash device easily accessible :-/ <cwillu_at_work> btrfs generally provides some nice-to-haves <cwillu_at_work> compression is useful, although at some point I want to get it using lzo instead of gzip <cwillu_at_work> and the checksumming provides a nice way of telling when my sd cards are starting to go bad <lool> Doesn't it make your IO slower on beagleboard during builds when you're CPU bound? * lool didn't dare the switch to btrfs just yet, but has been tempted <cwillu_at_work> it would, although you can always remount without compress; existing data stays compressed until you write to it <lool> Nice <cwillu_at_work> I've been using it on a couple machines with good backups, haven't run into anything scary yet <lool> What would be cool is per file or directory attributes to achieve compression or not <cwillu_at_work> not sure you can do that without a reboot currently though <lool> Like chattr's <cwillu_at_work> yep <cwillu_at_work> sub-volumes would allow it pretty easily <cwillu_at_work> (shares the storage pool, but mounted separately with whatever args) <cwillu_at_work> haven't played with that end of things yet though <cwillu_at_work> I've got a rootfs working, call me easily satisfied :) <cwillu_at_work> they do some braindead thing with df though: df against the mountpoint of a btrfs raid reports the total capacity of the underlying storage devices, not the available space in the raid <cwillu_at_work> I'm also using a 1gb swapfile on that btrfs partition <cwillu_at_work> which I find kinda hilarious :) <cwillu_at_work> 2.0gb usage (including the 1gb swap file) ends up using 663mb on the card <lool> Oh nice <lool> So you get compressed swap for free <cwillu_at_work> that's the hilarious part :) <cwillu_at_work> _wear_levelled_ compressed swap for free :) <cwillu_at_work> the #beagleboard folks never seem impressed by that for some reason :p <cwillu_at_work> #beagle rather, but ya <kblin> nice <kblin> but what do you do that uses swap? :) <cwillu_at_work> I'm lazy about removing things from my image that I don't need <lool> 512 MB isn't that much for large builds such as oo.o or xulrunner and then at runtime GNOME + firefox is pretty big too <lool> At least IME <cwillu_at_work> kblin, I usually only have 10 megs or so in swap, although I have to figure that on a beagleboard gaining 10mb ram is a win <kblin> oh, right, compiling would do it <cwillu_at_work> well, I meant in normal usage <cwillu_at_work> browser session really <kblin> ah, my beagles run as headless servers :) <cwillu_at_work> I end up with 10 megs or so of used swap; I haven't done much in the way of rigorous benchmarking <kblin> but at least on the revB, ram is a bit on the short side if I start up samba4 and bind <cwillu_at_work> the compression + ssd_spread is a win just for the storage, as long as the interface itself remains usable, which it does <cwillu_at_work> I basically see swap as the means by which I can extend my working set size <cwillu_at_work> firefox always ends up with a couple megs paged out with no visible delay in the ui <cwillu_at_work> so right there it's a win * kblin nods <cwillu_at_work> re: compression of the filesystem, there's definitely a cost, although my particular use isn't heavy on the reads or writes <cwillu_at_work> I'm interested in an lzo compression to replace gzip though for that reason <kblin> I'm running a fileserver :) <cwillu_at_work> lzo being an order of magnitude faster than gzip on the compression side, and I think 50% quicker or so on decompression <cwillu_at_work> not even sure what a good way of benchmarking throughput would be in this case <cwillu_at_work> hard to get away from the data dependence <cwillu_at_work> I: Unpacking the base system... * cwillu_at_work plans to head home after this finishes, and as such starts his car <cwillu_at_work> I: Base system installed successfully. * cwillu_at_work grabs squeezes pixman <cwillu_at_work> lool, sorry, you wanted me using gcc-4.4 under the squeeze chroot? or should I start with the default, confirm that it works, and then do gcc-4.4? <cwillu_at_work> lool, squeeze's binary package works without corruption * cwillu_at_work waits for apt to finis <lool> cwillu_at_work: You might want to do a test rebuild before trying with 4.4 + squeeze * cwillu_at_work waits for debian/rules to do its thing <cwillu_at_work> installing squeeze-chroot-built 4.3 <cwillu_at_work> lool, ^ <cwillu_at_work> lool, no corruption on 4.3, rebuilding with 4.4 <cwillu_at_work> lool, incidently, it looks like a simple CC=gcc-4.4 works with debian/rules * cwillu_at_work waits for 4.4 to build <cwillu_at_work> built, installing <cwillu_at_work> restarting x <cwillu_at_work> lool, still around? <cwillu_at_work> squeeze's 0.16.2-1 works fine (no corruption) against gcc 4.4 and 4.3 <lool> Gah <lool> cwillu_at_work: Well I have no idea what part of the toolchain / build env breaks it then :-( <cwillu_at_work> heh <cwillu_at_work> I'm going to do a build against the git tree, although I'm going to go to bed first <lool> The builddeps are pretty short <lool> Build-Depends: debhelper (>= 5), automake, autoconf, libtool, pkg-config, quilt <lool> It certainly is not one of these <lool> It could be binutils, but it would be kind of weird <cwillu_at_work> is there anything relevant to assembling the neon code? <cwillu_at_work> (the blit optimizations are handcoded iirc) <lool> yeah, the assembler is in binutils <lool> Oh right, it's manual assembly <lool> Well you could try installing Ubuntu's binutils under squeeze and see if that regresses the build <lool> But these quWe have 2.20-4ubuntu4 and squeeze/sid have 2.20-4, but we have some custom patches <cwillu_at_work> yep <cwillu_at_work> okay, I'll try that when I get back <cwillu_at_work> I have to play hockey in 8 hours, so it's time for bed :p <cwillu_at_work> thanks for the help, I'll poke you again #ubuntu-arm 2010-01-03 <gregoiregentil> Ping ogra? <porter1> Anyone happen to on in here? <porter1> I was having an issue with rootstock0.1.3, basically karmic with 2.6.31-rc3versatile1-cortex-a8 kernel. X server seems to freeze up badly when running in qemu. Tested by installing the xorg package and trying startx. Whole emulation crashes once xterm has started. <cwillu_at_work> my kingdom for a firefox that uses 16bpp internally :( <cwillu_at_work> er, a deb thereof <Daniele1> Hi! I'm italian! i've discovered today the existence of ubuntu mobile! i'm really happy because I hope it will be better than symbian running on my Nokia E65! I'm sorry for my bad english! <Daniele1> The processor of my mobile is an ARM 206 Mhz. <Daniele1> so, first question, can I install ubuntu manteining symbian and have something like a dual boot in my mobile-phone? <Daniele1> second question, ubuntu mobile have some program to use sms and mms? <Daniele1> third question: ubuntu is better than symbian 3rd edition? <armin76> fta: asac: http://code.google.com/p/v8/issues/detail?id=539 <- plz cc ppl? :) <Daniele1> noone can answer to my questions? <armin76> uh... <armin76> Daniele1: i doubt its able to run linux at all <Daniele1> armin76: my phone cannot run this sistem? <fta> armin76, didn't asac already have a patch for this -m32 thing? <Daniele1> armin76: i've read on line that ubuntu can be installed on the e65 <armin76> Daniele1: well, a quick google search returns nothing, so no, the only phones/tablets that are able to run linux are the n8x0 and n900 <armin76> Daniele1: really? have a link? <armin76> fta: its not a patch, its just a sed <armin76> fta: i believe the -m32 thing is only needed when crossbuilding <Daniele1> armin76: wait, i'm searching for pages thath i've vistied today <Daniele1> http://tuxmobil.org/phones_linux.html <Daniele1> what do you think? <Daniele1> http://tuxmobil.org/phones_survey_nokia.html <armin76> Daniele1: thats about connecting an ubuntu with a nokia, not using ubuntu on a nokia <Daniele1> armin76: ok, lol I don't understand very well english pages! <Daniele1> armin76: i'm sorry! <Daniele1> armin76: so I cannot do nothing to improve the speed of my phone? <armin76> Daniele1: nope <lool> cwillu_at_work: Did you manage to pursue investigations on the NEON fb corruption with pixman on beagleboard? <ssvb> hi, I have been told somebody is having problems with pixman here :) <armin76> lool: cwillu_at_work: ^ <ssvb> I'll be here for ~1 hour and will be glad to help if anybody has pixman ARM/NEON related questions <armin76> ssvb: http://irclogs.ubuntu.com/2010/01/02/%23ubuntu-arm.txt <armin76> ssvb: also may want to check the log for today <ssvb> cwillu_at_work: based on the symptoms description, your kernel has problems with VFP context save/restore for signal handlers <ssvb> cwillu_at_work: and this is a problem for X server as it is handling input using signals: http://ajaxxx.livejournal.com/62378.html <ssvb> cwillu_at_work: you need something like the following fix for your kernel: http://www.spinics.net/lists/arm-kernel/msg67148.html <ssvb> cwillu_at_work: hope this helps <armin76> ssvb++ <ssvb> cwillu_at_work: also feel free to report any issues you johncrosby@example.net under product 'pixman' * bizkut is away (i am away now) <armin76> lool: ^ :D #ubuntu-arm 2010-01-04 <lool> ssvb: Oddly, switching with another pixman and the problem goes away <lool> cwillu_at_work told me that squeeze/sid/emdebian libpixman doesn't have the issue but lucid pixman (same source, different toolchain) does <lool> I'm pretty sure he used the same kernel in all tests since we dont provide kernels for beagleboard on ubuntu <lool> bizkut-offline: This is seriously annoying; you don't even answer when we ask you to stop your verbose away <armin76> lool: :D <ssvb> lool: don't know, maybe recompiling pixman (and xserver?) with a different toolchain just hides the bug <ssvb> lool: but I know for sure that such problem existed with problematic kernels and it resulted in a similar looking artefacts on screen <lool> Ok <lool> Hmm right, I didn't think of rebuilding xserver, and it might be a bug in the kernel only triggered in specific conditions <ssvb> lool: what version of kernel are you using by the way? <lool> In Ubuntu we track 2.6.32 for the next release, but we don't provide beagleboard kernels; he was running a .32 IIRC <lool> 11:14 < cwillu_at_work> Linux overo 156.14.161.142-x1.0 #1 PREEMPT Thu Dec 17 02:23:37 UTC 2009 armv7l GNU/Linux <lool> I'm not sure from which branch <lool> I suppose -omap, but then it could be any tree derived from that <ssvb> I see, there is a small testcase which can be easily used to verify whether the kernel has this problem or not, I'll try to find it <lool> Great <ssvb> lool: here is a testcase for kernel bug: http://siarhei.siamashka.name/files/20100104/test-sighandler-vfp-corruption-bug.c <ssvb> lool: looks like the fix did not get upstream yet (just tested it with the latest linux-omap kernel), makes sense to send some ping messages <lool> cwillu_at_work: ^ <lool> ssvb: thanks! * armin76 kicks NCommander <ssvb> lool: also just verified that these old patches still apply cleanly and fix the problem * NCommander is beaten by armin76 * armin76 steals NCommander's dove boards <NCommander> armin76, :-P <NCommander> armin76, http://www.engadget.com/2010/01/04/freescale-reveals-7-inch-smartbook-reference-design-hopes-to-se/ - just buy one of these <armin76> NCommander: i prefer your boards *g* <armin76> NCommander: gimme Z0! <NCommander> armin76, I never had a Z0 <armin76> NCommander: get me one! * NCommander thinks armin76 didn't get any ARM hardware for the holidays * cwillu_at_work is pinged * cwillu_at_work pokes lool <armin76> NCommander: there's an dove arm buildd that hasn't build something since october, gimme! <NCommander> armin76, ? <armin76> NCommander: give it to me if it isn't doing anything :P * cwillu_at_work has finished reading the scrollback * cwillu_at_work runs ssvb's test-sighandler-vfp-corruption-bug.c <cwillu_at_work> cwillu@overo:~$ ./a.out <cwillu_at_work> error: x=1090022160 y=1090022161 d=523-777-4502 <cwillu_at_work> Aborted <ssvb> cwillu_at_work: it's a bit messy, but demonstrates that the signal handler can corrupt floating point registers from the main thread, normally this test should run infinitely without any problems <cwillu_at_work> ya, that run lasted all of 20 seconds <ssvb> cwillu_at_work: for pixman it means that the signal handler responsible for input handling may corrupt NEON registers and as these are used for processing pixel data, it results in image artefacts which look as horizontal stripes <cwillu_at_work> hmm <cwillu_at_work> only horizontal stripes? <cwillu_at_work> I only get 45degree stripes <cwillu_at_work> this is upstreams 523-777-4502 from git, with some patches applied <cwillu_at_work> although experienced this under 523-777-4502, only started playing with libpixman after I switched to that series, so I don't know about earlier kernels <ssvb> cwillu_at_work: well, any kind of bad things may happen in general, also including xserver crashes on some occasions, so the bug is better to be fixed <cwillu_at_work> do I only need that one patch, or do I also need patch 1/2? <ssvb> they depend on each other, so both need to be applied <cwillu_at_work> okay <cwillu_at_work> re: input handling, that explains why it was so much worse when dragging a scroll bar than when using the mouse wheel <cwillu_at_work> ssvb, this is only mildly related, but would you know what is required to gain any benefit from the neon routines in pixman? Is a new cairo build also required? <cwillu_at_work> (compiling a new kernel, will ping when it completes and I've tested it) <ssvb> cwillu_at_work: just neon optimized pixman is enough, cairo upgrade is not required <ssvb> cwillu_at_work: also pixman version 0.17.2 has more neon optimized functions and they are faster, git master has even more stuff <cwillu_at_work> yep, I was compiling git master <cwillu_at_work> among others... :p <cwillu_at_work> should it be a dramatic improvement? <cwillu_at_work> I'm mainly concerned with scrolling a firefox window at 1280x1024, and I haven't noticed a whole lot of difference <ssvb> cwillu_at_work: what is the desktop color depth? <cwillu_at_work> Which makes me inclined to think that firefox is either ignoring my efforts, or that I'm optimizing something that's only 1% of the problem anyway <suihkulokki> ssvb: re: pixman and neon, is reading /proc/self/auxv really the best way to find out if the cpu supports neon? <ssvb> suihkulokki: not sure about this, but it seems to work <suihkulokki> yes, but it is a slight problem when run under qemu linux-user where that file is x86 auxv of qemu <cwillu_at_work> ssvb, I've tried 16 and 24 <lool> suihkulokki: You can override glibc's hwcaps perspective though <cwillu_at_work> sorry, missed the question while I was typing :p <ssvb> suihkulokki: I see, but ARM CPUs unfortunately do not support any way to identify cpu type from userspace for the 'security reasons' <lool> Wont help with pixman but can help with shared libs <lool> suihkulokki: Perhaps qemu should provide an emulated /proc in some way though <lool> Things like cpuinfo will be bogus as well <ssvb> cwillu_at_work: firefox browser does all the rendering in 32bpp and converts the results to the desktop color format as the last step <suihkulokki> lool: yeah, Qemu providing virtual /proc to apps running inside qemu would be the correct fix <ssvb> cwillu_at_work: 32bpp is slow because memory bandwidth is limiting performance for most operations <cwillu_at_work> ssvb, I was under the impression that 24 and 32bit were the same memory layout, and hence I didn't mention that I also tried 32 explicitly :p <cwillu_at_work> ssvb, but should I expect to not see any improvement with the neon routines? <cwillu_at_work> <cwillu_at_work> my kingdom for a firefox that uses 16bpp internally :( <cwillu_at_work> ^^ is that basically the answer? <cwillu_at_work> and if that's the case, would there ever be any chance of ubuntu's armel firefox getting patched? <ssvb> cwillu_at_work: profiling scrolling in firefox 3.6 beta 5 looks more or less like this for me: http://pastebin.com/m669d1f7f <ssvb> cwillu_at_work: looks like it is already 16bpp friendly <cwillu_at_work> ssvb, as of 3.6? <ssvb> cwillu_at_work: don't know, I just remember that this was not the case for firefox 3.0 and I had a simple patch for it <cwillu_at_work> I'm on 3.5 right now, I'll install 3.6 and see if that improves things <cwillu_at_work> ssvb, or do I just need to adjust my expectations? <cwillu_at_work> i.e., is it fluid for you? <ssvb> cwillu_at_work: but still arora browser is much faster than firefox for scrolling <cwillu_at_work> I'm fairly reliant on a streamable xmlhttprequest in the browser, which is something of a gecko only thing <ogra> suihkulokki, shouldnt that be possible through containers ? <ssvb> cwillu_at_work: disregard the previous oprofile report, appears that for scrolling distribution of cpu time between graphics output and browser engine overhead heavily depends on how fast you are scrolling the page <cwillu_at_work> rm /tmp/ssvb/hard_data <ssvb> cwillu_at_work: this is a comparison of firefox vs. arara for scrolling with arrow down key pressed, firefox: http://pastebin.com/m6f334785 arora: http://pastebin.com/m9f98ed2 <ssvb> cwillu_at_work: arora feels much faster and it also spends almost half of the time in pixman, which firefox has a lot of other overhead <ssvb> s/which/while <cwillu_at_work> kernel just finished building, installing and retesting <ssvb> cwillu_at_work: basically these profile reports show that arora benefits from pixman optimizations a lot more and the effect is much more easily visible <ssvb> cwillu_at_work: great, let me know about the results <cwillu_at_work> just rebooting now (wanted to update some other stuff at the same time, nothing like mixing experiments to save time :p) <cwillu_at_work> for no particularly good reason, I've still got it booting into a 32bit framebuffer; if I understand you correctly, there's still a benefit to using 16, correct? <cwillu_at_work> (running the test now) <cwillu_at_work> hasn't stopped yet <cwillu_at_work> unsurprisingly, scrolling is slow as hell while its running :p <ssvb> cwillu_at_work: 32bit framebuffer is slower because there is more data to process, also display refresh steals some of the memory bandwidth <ssvb> cwillu_at_work: what is your screen resolution? <cwillu_at_work> ssvb, 1280x1024 :p <ssvb> cwillu_at_work: ok, same here <cwillu_at_work> the sigalarm testcase looks good, hasn't crashed yet <cwillu_at_work> ssvb, with an otherwise idle cpu, is firefox smooth on your hardware? <cwillu_at_work> I get about 3 frames per second <cwillu_at_work> during full-screen scrolling <ssvb> cwillu_at_work: it is *much* better for me, probably at least 10 frames per second <ssvb> cwillu_at_work: but it is subjective impression, I did not run tests with camera <cwillu_at_work> ssvb, 10 frames is just short of fluid, but still acceptable <cwillu_at_work> ssvb, would be able to compare against ff-3.5 would you? <ssvb> cwillu_at_work: it would take time to build ff-3.5 <cwillu_at_work> no apt-get? :p <cwillu_at_work> rebooting under 16bpp <ssvb> brb <cwillu_at_work> <3 <ssvb> cwillu_at_work: any news? <cwillu_at_work> performance seems to be respectable for a smaller scrolling region, I think I need to do some a/b tests to prove that they're actually better though <cwillu_at_work> the glitching is definitely fixed by that patch, I've got it sent to my upstream, who grumbled about Russel being up to his usual self such that they were never applied <cwillu_at_work> oh, hi rcn-ee, you joined :) <rcn-ee> hey cwillu_at_work, so did the patches help with pixman? i haven't been able to test them myself.. <cwillu_at_work> rcn-ee, yes, I actually sent them after I had verified that they worked this time :) * bizkut is away (i am away now) * armin76 rofls <armin76> ah, too bad lool is not here :D <asac> ogra: you said you had a fix for apex? <asac> http://launchpadlibrarian.net/36670366/buildlog_ubuntu-lucid-armel.libgd2_2.0.36~rc1~dfsg-3.1ubuntu1_FAILEDTOBUILD.txt.gz <asac> http://launchpadlibrarian.net/36947837/buildlog_ubuntu-lucid-armel.libgphoto2_2.4.7-0ubuntu1_FAILEDTOBUILD.txt.gz <asac> NCommander: you have buildd powers? <asac> e.g. can you give back with good prio? <asac> last build failure might be just fixed? <asac> hmm libtool still ftbfs * asac kicks off a build <NCommander> asac, yeah, I can do that <NCommander> asac, which package needs a nudge <armin76> NCommander: nageia is the buildd that doesn't do anything :) <asac> NCommander: nevermind. thought libtool wasnt retried <asac> NCommander: dove images broken/not booting? or just test builds? <NCommander> asac, the issue was that I didn't notice that we haven't had an alternate build in almost a month. cjwatson looking at antimony to see what went wrong <ogra> asac, http://paste.ubuntu.com/351393/ <ogra> (it doesnt respect CFLAGS) <ogra> but that only fixes the initial build failure, at the end it fails with a cast error in link.cc <ogra> well, "link.cc:236: error: invalid conversion from 'const char*' to 'char*'" <ogra> anyway, off again <asac> ogra: what context? <ogra> apex <ogra> you asked for my apex fix <asac> ogra: kk <asac> i can check <asac> ogra: if still there ... why -marm? is that a workaround or the right fix? <ogra> apex is a bootloader for armv5 <asac> oh ;) <ogra> and doesnt have any thumb support <asac> yeah <asac> makes sense <asac> ogra: why is it in main? <ogra> it is used for the nslu2 <ogra> that was our first supported armel arch before wer had any HW <asac> guess we dont support it anymore? <asac> e.g. we should unseed/demote it ;) <ogra> it can happily go to universe, but i feel bad if i demote it in that state <asac> sure <asac> should be fixed <ogra> yeah ... would feel like dumping trash on the MOTU <asac> ogra: do you know if its seeded or why it didnt get demoted in karmic? <asac> we want to fix all universe armel only failures too ;) <asac> just that we start in main as its on top of that webpage ;) <ogra> it didnt ftbfs and nobody had it on the radar <ogra> probably my fault since i cared for it in jaunty and didnt look after it later <asac> ogra: well. but afaik it shows up in component-mismatches unless its pulled in thorugh some mechanism <asac> just wnat to understand what is that ;) <asac> but no hurry <ogra> i think its just seeded in supported <ogra> that makes it not show up on the mistmatches page <asac> dyfet: checked chrome? <asac> kk <dyfet> asac: not extensivily but it works <dyfet> asac: and feels fast(er)... <dyfet> or did you mean chromeos rather than chromium browser? <asac> nope <asac> our packages <asac> good <armin76> thanks to me *g* <dyfet> asac: since it imports, I dumped my mozilla directory onto the box and let it try to import my bookmarks and passwords, it did not seem to import my passwords entirely though... <asac> dyfet: entirely? but parts? <dyfet> yes <asac> dyfet: any pattern what got imported and what not? <asac> maybe compare what you see in show passwords in ffox and chromium <dyfet> I am not sure, but they were all form based, and it happened to be one site it only filled the email/login id, not the password field <dyfet> but again I did not go through very many sites with it yet <asac> ok. if in doubt i would start comparing the show passwords dialog in preferences of firefox/chrome <asac> maybe its a bug about detecting password/input fields <asac> or something <dyfet> asac: it feels like there is more in my firefox saved passwords...in fact, there is some I can already confirm are missing <asac> JamieBennett: there still? <JamieBennett> asac: yes <asac> JamieBennett: someone claimed that n.b.l-efl isnt localized ... e.g. like the applications and categories etc. <dyfet> asac: never mind, I found the ones I thought were missing :) <asac> good :) <asac> JamieBennett: can you confirm that thats the case in our lucid build? <JamieBennett> asac: ummm, not sure, not something I've looked into but I can check <asac> that would be great <asac> JamieBennett: how do one best try the launcher? does it just show up as a session variant in gdm? <JamieBennett> When I installed it I just ran it from the command line <JamieBennett> asac: It seems that it is localized, most strings come from the .desktop. lfelipe has tested and can confirm along with k-s <asac> JamieBennett: ok. is sound recorder localized? <asac> like in chinese? <JamieBennett> no idea ;) <JamieBennett> I use neither :D <asac> JamieBennett: so you say you confirmed it by starting in a different language? <asac> (on your own?) <JamieBennett> asac: I confirmed it by asking the developer, I can play around with the local install I have if you need that but lfelipe says he can provide up-to-date screenshots for anything we need <JamieBennett> k-s also confirmed <asac> confirmed by running or by thinking ? <asac> i am find if they say they run lucid packages and all is there <asac> its just that we got a report about this ;) <asac> s/find/fine/ <asac> so developers saying "it should work" ... might not be right approach ;) <cwillu_at_work> I find your lack of faith disturbing <asac> faith? <cwillu_at_work> "it should work" <cwillu_at_work> therefore: it should work. <cwillu_at_work> (I'm done now :p) <asac> yes. but if there is a complain about it not working, its ok to double check :) <JamieBennett> I don't have a lucid desktop install at the moment, I'll set one up (its on the todo list for today anyway) <asac> JamieBennett: no need to if you dont have the infrastructure to check. just thought you had all in place <JamieBennett> asac: not in a Lucid environment yet, something I will fix tonight <asac> hehe <asac> i should upgrade too <asac> e.g. ~end of jan * bizkut is away (i am away now) <asac> bad away messages ;) <asac> dyfet: so did you check the moblin media player? <armin76> haha <armin76> where's lool! <armin76> !seen lool <ubot4> I have no seen command <asac> armin76: he left this channel <armin76> bah, useless bot <armin76> well, he just dissapeared in a net split :) <asac> yes.... so he left the channel <asac> because whereever i am is the main channel :-P <asac> armin76: so did you finally manage to get something usable wrt chromium? <armin76> asac: nah, segfault when building v8 <armin76> i'll try building on my armv7 board, but i'm busy building other stuff <armin76> thats what happens when you only have one board :) <armin76> could be that either something is broken or that doesn't build on armv5te <armin76> asac: build it on jaunty :) <NCommander> asac, I thought we had a working chromium on ARM ... <asac> NCommander: we have ... armin76 doesnt <armin76> :D <armin76> NCommander: he's using an ugly patch though! <NCommander> armin76, ? <armin76> NCommander: asac is using an ugly patch to make it work :) <armin76> s/work/build <asac> hey. i have the right one ... just need to check <mturquette> could someone point me to the apt repositories for the dove and babbage boards? * armin76 points to asac and NCommander <armin76> NCommander: btw meet mturquette, he wants ubuntu rocking on omap <NCommander> mturquette,
{'channel': 'ubuntu-arm', 'month': 1}