#ubuntu-arm 2009-12-28
<armin76> asac: slaaaacker!
 * bizkut is away (i am away now)
<lool> bizkut-offline: Please turn your verbose away off
 * armin76 thinks asac is away too *g*
<asac> armin76: whats up?
<asac> any luck?
 * asac considers to build a NEON kernel for imx51 to figure if chromium works with that at least
 * armin76 cries because asac didn't read what i wrote
<asac> armin76: can you paste again?
<asac> ;)
<asac> armin76: so it worked?
<asac> just not with flash pages?
<asac> hmm
<armin76> http://irclogs.ubuntu.com/2009/12/24/%23ubuntu-arm.html
<armin76> asac: not flash, as google.com didn't work either
<asac> armin76: but some pages worked?
<armin76> gentoo.org and forums.g.o did
<asac> cool. guess you neither have arm_thumb nor armv7
 * asac should try that combo too
<armin76> nope, no ricing here
 * asac does that
<armin76> i won :D
<asac> i think that either no opimization works ... or full
<asac> but with NEON in kernel of course
<asac> but the thing in between is f***ed
<asac> armin76: what gcc version are you using?
<armin76> can't remember if 4.4 or 4.3
<armin76> and the board is down atm
<asac> fta: tools/pretty_sln.py -> no license (gyp)
<asac> tools/pretty_vcproj.py
<asac> same
<asac> test/defines/defines.c
<asac> test/dependencies/a.c
<asac> test/hello/hello2.c
<asac> test/hello/hello.c
<asac> test/rules-rebuild/gyptest-all.py
<asac> test/rules-rebuild/gyptest-default.py
<asac> test/scons_tools/tools.c
<asac> test/toolsets/main.cc test/toolsets/toolsets.cc test/variables/update_golden
<asac> thats it i think
<asac> gyp_dummy.c setup.py (last ones)
<asac> fta: bug filed: http://code.google.com/p/gyp/issues/detail?id=133
<fta> asac, if you mean gyp, iirc, the full source tree is covered by a global license file
<asac> fta: sure, but source files disagree (either metnioning nothing, or even all rights reserved)
<asac> check the bug
<asac> http://code.google.com/p/gyp/issues/detail?id=133
<asac> once those are fixed i would like to upload ..
<asac> (to archive)
<armin76> asac: 4.3.4
<armin76> asac: mirror.facebook.net works
<armin76> gentoo.org works
<armin76> google.com fails...etc
<armin76> asac: http://dev.gentoo.org/~armin76/googlechrome.png
<asac> armin76: u r cool guy ;) ... so maybe it worked for me too ... but i didnt try as google.com (homepage) snapped ;)
<asac> maybe the "fade in" feature?
<asac> ubuntu.com works?
<armin76> nope
<armin76> whats that feature?
<armin76> ubuntu.com doesn't work, thats why i thought it was flash :)
<asac> armin76: ubuntu.com hopefully has no flash (not sure)
<asac> armin76: if you go to google.com ... the whole decoration parts fade-in
<asac> havent seen that?
<asac> try ffox
<asac> like the "web images etc." on top of the page
<armin76> oh
<asac> it starts with just Google image and the input box
<asac> i am not sure why that was added though ;) ... feels overly funk<y
<armin76> asac: damnit, i'm unable to find a simple page that returns the user agent string :P
<asac> haha
<asac> write your own ;)
<asac> simple == not crashing?
<armin76> yeah
<asac> http://whatsmyuseragent.com/
<armin76> using php
<asac> thats too strange?
<armin76> since if its going to use javascript, its not going to work
<asac> hmm
<asac> armin76: did you disable v8_snapshot?
<asac> we have v8_snapshot=false as gyp flag
<asac> maybe we should just try =true if you have =false ;) (and if you are sure its javascript killing the beast)
<asac> we have v8_use_snapshot=false
<asac> if you dont have that ... try that
<asac> if you hvae that try =true ;)
<armin76> i do
<asac> armin76: can you try to get a backtrace?
<asac> chrome --renderer-cmd-prefix='gdb --args'
<asac> chromium
<armin76> http://www.pascalex.net/phpinfo.php <- *g*
<asac> mine was trashed when i tried ... maybe you have more luck
<asac> http://code.google.com/p/chromium/issues/detail?id=31063
<armin76> http://dev.gentoo.org/~armin76/googlechrome2.png
<asac> armin76: are those dots artifacts?
<asac> so i would suggest to try with snapshot flipped ... not sure why
<asac> its not on the Arm wiki (anymore?)
<armin76> those dots are from my gfx
<asac> http://code.google.com/p/chromium/wiki/LinuxChromiumArm
<asac> kk
<asac> fta: why do we disable v8 snapshot on armel? was that on the arm wiki page at some point?
<asac> i remember i read abou tthat somewhere ... but cant find
<asac> armin76: do you get "pure virtual function called" error on console when it snaps?
<armin76> asac: http://dev.gentoo.org/~armin76/googlechrome3.png
<asac> hmm
<asac> odd
<fta> asac, it had to do with v8 not supporting cross-compiling with snapshotting, and iirc, it didn't build natively either
<asac> ok. i will check that
 * armin76 is building
<asac> thx
<asac> i think it was really on that page ... so feels like a good pointer
<armin76> check the history? :)
<asac> no clue how
<armin76> :D
<armin76> yep, looks like disabled or something
<fta> asac, http://code.google.com/p/chromium/source/detail?r=1475&path=/wiki/LinuxChromiumArm.wiki
<asac> armin76: http://pastebin.com/f7d1b7956 ... makes sense?
<asac> right
<armin76> fta: damn :P
<asac> fta: cool. plesae drop
 * asac wonders if he should abort his karmic build ;)
<armin76> asac: why do you ask me? i have no clue :P
<asac> armin76: you are "arm"in ;) ... thought that means you know about "in"trinsics
<asac> ;)
<fta> asac, done
<armin76> i wish :)
<asac> armin76: so you are trying with snapshot?
<asac> db4.2 fix (potential) uploaded
<asac> http://identi.ca/notice/17674970
<armin76> asac: yep
<asac> good
<asac> NCommander: pong
<asac> ;)
<asac> NCommander: db4.2 is now avail fwiw (not sure if it was you who requested it for something)
#ubuntu-arm 2009-12-29
<armin76> asac: g++ -march=armv5te -pipe -pthread -fno-exceptions -fvisibility=hidden -Wall -D_FILE_OFFSET_BITS=64 -m32 -fno-ident -fdata-sections -ffunction-sections -fno-asynchronous-unwind-tables -fomit-frame-pointer -O3 -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -DENABLE_LOGGING_AND_PROFILING -DENABLE_DEBUGGER_SUPPORT -D__STDC_FORMAT_MACROS -DDISABLE_NACL -DV8_TARGET_ARCH_ARM -DCHROMIUM_BUILD -DNDEBUG -DNVALGRIND -Iv8/src -MMD -
<armin76> MF out/Release/obj.host/v8_nosnapshot/gen/libraries.o.d.tmp -c -o out/Release/obj.host/v8_nosnapshot/gen/libraries.o out/Release/obj/gen/libraries.cc
<armin76> cc1plus: error: unrecognized command line option "-m32"
<armin76> make: *** [out/Release/obj.host/v8_nosnapshot/gen/libraries.o] Error 1
<armin76> ah well, you hit the same issue :)
 * bizkut is away (i am away now)
 * armin76 looks at lool 
<armin76> fta: seen the armel build failure of crhomium?
<shenki> armin76: looks like v8 hasn't been set up to build natively for arm yet
<shenki> armin76: do you know if fta has a bug open for that?
<armin76> shenki: no clue
<shenki> you guys are the only ones that are attempting to build chromium natively; upstream does cross builds, and so do I
<shenki> (i've been babysitting the arm build for the past 6 months or so)
<armin76> i know, buts its fun ricing!
<shenki> :D
<shenki> how much RAM do the build machines ahve?
<armin76> 512mb, i guess
<armin76> no clue
 * armin76 is not ubuntu dev, nor related to ubuntu at all
<armin76> but they should be either marvell dove or imx515, which means 800mhz && 512mb afaik
<shenki> nice. so it takes about a week to link? :)
<armin76> takes 10 hours to do all
<armin76> shenki: have you tried the crossbuilds?
<shenki> armin76: yeah, i wrote the cross build infrastructure for arm. it takes about half an hour on my phenom-II 3ghz, with 4G of ram
<armin76> shenki: but does it work? :P
<shenki> s/wrote/helped write/
<shenki> yeah, it does
<armin76> fully?
<armin76> have a binary i could test?
<shenki> well, i don't build the tests
<shenki> but yes, i have buildt and run binaries
<shenki> i'll build you one now and upload it
<armin76> thanks
<shenki> what hardware do you have?
<armin76> sheevaplug, efikamx and ssh access to marvell disco duo
<shenki> i'm not familiar with the 2nd two. what architecture are they?
<armin76> armv7a and armv5te
<armin76> the latter has 3g of ram :)
<shenki> !
<shenki> want
<armin76> ubuntu has plenty of them, ask asac :D
<shenki> ah, but it's only armv5
 * lool whistles
<shenki> armin76: the chromium i build is for thumb2, is that okay?
<armin76> shenki: guess so, will take a while to test it then, as the efika is a bit busy atm
<shenki> hrm. i don't have a v5 rootfs, so it's a bit harder to build for that
<armin76> don't worry
<armin76> :D
<shenki> armin76: what does the efika use for it's hdmi output?
<armin76> and hdmi port :D
<shenki> er, in terms of hardware. does it have a open driver?
<armin76> nope
<shenki> (i brought a openrd client and have been mega annoyed at not being able to use a modern kernel on it, due to no support for the video card)
<armin76> does the beagleboard have open driver?
<shenki> yeah
<armin76> guess its the only one
<armin76> afaik marvell dove has no open driver as of now
<shenki> not for the 3d hardware, but it can display graphics no worries using the kernel driver. it's just been re-written too, presumably it's better
<shenki> ok
<shenki> that blows. silly embedded companies.
<cwillu_at_work> armin76, recent dss2 work has made settings modes quite nice, although it's not quite xrandr yet.
<shenki> cwillu_at_work: do you know if the dss2 stuff can allocate framebuffer memory dynamyicly (as in, when it sees how big the display it's driving is). or do we still need to provide it with the kernel boot args?
<shenki> err, excuse the typos
<cwillu_at_work> shenki, I don't know about going to bigger sizes than the initial framebuffer, no;  I've mostly been concerned with 1280x1024x16 myself
<shenki> cwillu_at_work: ok
<cwillu_at_work> it'd be easy enough to try though, although I don't have a spare board handy at the moment (my only board is tied up with some tests today)
<shenki> yeah, i should just try it
<armin76> shenki: i have sh board that has a siliconmotion gfx
<armin76> the fun is that the x11 driver doesn't detect it :D
<shenki> :/
<shenki> someone should make some embedded gpu IP, and write an open driver for it. i imagine they would do quite well out of it
<lool> armin76: The dove drivers are pretty open
<lool> https://code.launchpad.net/~lool/+junk/marvell-libgfx http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-dove.git
<armin76> lool: junk :D
<armin76> shenki: ^
<shenki> thanks
<lool> armin76: Yeah, I hate that name; it's the name of a special folder where you can push any branch
<lool> armin76: launchpad forces you to push to lp:$people/$project/$branch kind of trees
<lool> e.g. lp:~ubuntu-core-dev/apt/ubuntu
<lool> The special /+junk allows you to throw in any branch you like
<lool> Without having to register a project first
<shenki> armin76: ah, you're on gentoo? i wonder if the ubuntu builds will run on your system
<armin76> shenki: who knows
<lool> In theory they shold
<lool> should
<shenki> not really, ubuntu/debian names some libraries differently which throws the dynamic linker out
<shenki> also you need to be running similar versions to the ones i linked against in my rootfs
<shenki> armin76: http://jms.id.au/~shenki/chromium-arm-r35329.tar.bz2
<armin76> shenki: got it, thanks
<shenki> armin76: no worries. let me know how it goes
<lool> shenki: Most libs have identical SONAMEs in Debian and Ubuntu; which ones did you have in mind?
<shenki> lool: not sure, im not a gentoo user.  i was trying to convince a friend to use the google-built images and he had trouble
<asac> shenki: armin76: yeah. seems to be an issue with "toolsets"
<asac> like it sets -m32 if _toolset==host
<asac> not sure where in gyp that toolset thing is done
<asac> any idea?
<armin76> grep :D
<asac> armin76: haha
<asac> already did that
<asac> didnt find the trick
<asac> i see where it sets -m32 if toolset==host
<asac> but i dont see how the hell toolset = host
<asac> _toolset=host
<asac> actually
<armin76> maybe its host = toolset *G*
<asac> ho
<asac> ho
<asac> ho
<armin76> merry christmas asac
 * asac waits for shenki to tell me ;)
 * asac kicks off a fresh build for a bug
<asac> file
<asac> armin76: http://code.google.com/p/chromium/issues/detail?id=31063 ... thats our snap with javascript bug ;)
<armin76> :D
<armin76> asac: sorry i forgot to run the backtrace, do you still want me to do it?
<christoph_debian> hm maybe someone wants to update https://wiki.ubuntu.com/ARM ? it still tells arm5t ?
<christoph_debian> don't like to ask around on IRC on multiple channels to find out my CPU is no longer supported
<asac> armin76: give it a try. though its not meanng much until we have a snapshot biuld
<asac> and thtahat has the same issue
<asac> christoph_debian: feel free to update that page?
<asac> ;)
<asac> done
<asac> hmm. not sure about karmic
<armin76> karmic is armv6 you slacker
<christoph_debian> asac: tells mit it's a ineditable page?
<asac> christoph_debian: you need to log in ;)
<asac> i updatred it now
<asac> check if that is good enough for you
<christoph_debian> I'd had put it into FAQ as well (the difference point tells it's v5 opposed to debian's v4) but it's quite vissible this way
<christoph_debian> (login requires an account)
<asac> ok let me edit that too
<asac> done
<asac> check it please
<asac> (FAQ)
<asac> shenki: ping me when back ;)
 * asac makes some coffee
<asac> shenki: armin76: http://code.google.com/p/chromium/issues/list?thanks=31274
<asac> fta: ^
<fta> asac, wrong link?
<fta> crbug.com/31274 ?
<fta> seems more like it
<asac> hmm
<asac> guess os
<fta> triagged
<asac> ok patched that stuff away ... lets see
<asac> 14:49 < jdstrand> asac: netbook-launcher-efl accepted
<asac> ole!
<asac> NCommander: did you check whether kexec sitll broken on arm?
<asac> fta: so triaging means its still left in unconfirmed state?
<asac> it was confirmed by armin76 and me ;)
<fta> asac, well, i usually semi-triage stuff, i won't assign a milestone as i'm not release manager there
<fta> just moved it to untriaged, meaning confirmed but not reviewed for priority & assignment
<asac> where do i see "untriaged"?
<asac> i always say "unconfirmed" ;)
<asac> see
<fta> status
<asac> what does available mean?
<fta> you can't set it yourself, you have to be bugcontrol
<fta> available is fully triagged, but not assigned
<asac> ah
<asac> felt like "fixed" ;)
<asac> which would have been odd
<asac> fta: do you see where _toolset is defined?
<fta> asac, http://www.sofaraway.org/ubuntu/tmp/chromium-status.png
<asac> its odd as i see toolset without _ being tested elsewhere
<asac> and i see _toolset nowhere being set
<asac> neither gyp code, nor chromium
<asac> are there .py extensions to .gyp in the chromium tree?
<asac> i only grepped in .gyp there
<fta> grep gyp and gypi
<asac> hmm. i think i also tried that
<asac> let me check
<fta> i need to run, be back later
<asac> there are only tests
<asac> no sets
<asac> hah
<asac> found it
<asac> LoadAutomaticVariablesFromDict
<asac> http://paste.ubuntu.com/348585/
<armin76> quick
<asac> still ;)
<asac> no clue how this whole thing works
<asac> e.g. is that injected from outside ... detected during build time? etc.
<asac> hmm ... now the build failed with the same "pure virtual function called"
<armin76> asac: what did you do?
<asac> armin76: i dropped the -m32 flags hackishly
<armin76> hah
<asac> armin76: http://paste.ubuntu.com/348631/
<armin76> asac: which gcc are you using?
<asac> armin76: tried both: gcc-4.4 and gcc-4.3
<asac> gcc-4.4.real (Ubuntu 4.4.1-4ubuntu8) 4.4.1
<asac> Copyright (C) 2009 Free Software Foundation, Inc.
<asac> This is free software; see the source for copying conditions.  There is NO
<asac> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
<asac> hmm
<asac> though i didnt build all with g++-4.3 yet
<asac> maybe i should try
<asac> i now disabled arm_thumb=0 alltogether
<asac> seems the v8 code generation has special casing
<asac> so could be that the combination armv7=0 arm_thumb=1 isnt good
<asac> ok kicking a new build with AVOID_GCC44
<asac> armin76: http://pastebin.com/f73b8edfb
<asac> thats the hackish patch to continue
<asac> you didnt get the virutal func issue before, so maybe it just works for you with that
<armin76> asac:   export LD_LIBRARY_PATH=/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/lib.host:/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/lib.target:$LD_LIBRARY_PATH; cd v8/tools/gyp; mkdir -p /var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/obj.target/geni; "/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/mksnapshot" "/var/tmp/portage/www-client
<armin76> /chromium-9999/work/chromium-9999/out/Release/obj.target/geni/snapshot.cc"
<armin76> /bin/sh: line 1: 14154 Segmentation fault      "/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/mksnapshot" "/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/obj.target/geni/snapshot.cc"
<armin76> make: *** [out/Release/obj.target/geni/snapshot.cc] Error 139
<fta> armin76, looks familiar, could you get a backtrace?
 * bizkut is away (i am away now)
<asac> armin76: so its still building with gcc 4.3
<asac> nice
<asac> armin76: do you get a reasonable backtrace  for that seg?
<asac> the sigill is just rubbish. maybe thats a better hint to see whats going on
<lool> asac, ogra_: http://paste.ubuntu.com/348756/
<lool> Will send to qemu-devel@ shortly
<asac> nice
<lool> I had also noted that I should fix qemu to sigill on instructions not in the emulated CPU, but actually it does
<lool> qemu-arm takes a -cpu arg, just like the system one
<lool> It's just the man page which sucks
<asac> cool ;)
<asac> armin76: mine is still spinning ;)
<asac> something must be wrong :)
<armin76> lool: funny away msg! :P
<armin76> fta: asac: will check tomm, i'm tired atm
 * lool is away (not reading armin76's temptations)
#ubuntu-arm 2009-12-30
<armin76> ogra: lool: does ubuntu support the netwalker?
<lool> armin76: The netwalker ships with a Canonical Ubuntu OEM version
<lool> I have one here
<lool> But it's not supported in vanilla Ubuntu
<lool> It's mostly imx51 though
<asac> fta: great. chromium works
<asac> please use gcc-4.3 for now
<asac> on armel
<asac> so its gcc 4.4 bustage that caused this mess
<asac> i already have an idea which compile flags those are
<asac> let me commit the hack to workaround the issue for -m32
<asac> armin76: ^^
<fta> ok
<fta> what about the other flags?
<asac> have to test
<asac> let me first get this working
<asac> one second
<asac> my guess is that its the -fdata-sections and -ffunction-sections flag combined with --gc-sections linkking
<asac> i will drop those to test that
<asac> they are supposed to remove symbols supposely not used from what i understand
<asac> feels rarely tested ;)
<asac> fta: btw, the GCC version hook you hvae in rules doesnt work with gyp=make
<fta> really? hm
<fta> how did you test then?
<asac> i fixed rules too
<asac> ;)
<asac> http://pastebin.com/f5757e288
<asac> ok all committed
<armin76> asac: but does google work?
<asac> yes
<asac> everything works
<asac> and is rockingly fast ... even over ssh ;)
<zumbi> congrats ! :-)
<asac> hehe
<asac> let me see how it is on real X
<fta> strange, CC and CXX are supposed to be used by gyp.. probably another bug there
<asac> 5 seconds on first startup
<asac> fta: yes. its a bug in the make generator most likely
<asac> i saw that scons generator at least looks at those
<fta> i will talk with the author of this generator
<asac> while the make one doesnt even reference those
 * asac a bit happy
<fta> btw, i'm working on setting up a dev-channel, between the beta-channel and pure dailies
<asac> i always thought that was the plan
<asac> actually i thought that the dailies are more or less redundant
<asac> at least for users (and most ubuntu devs) the -dev channel is more fruitful i guess
<asac> fta: so if i remove stuff from ppa ... will that give more space?
<fta> if users want to switch, i don't mind, but from the feedbacks i got with the beta, users prefer dailies
 * asac considers to upload rather than wait for a new daily to not upload a new tarball
<asac> yeah. but i think -dev is more what they want. but we will see
<asac> just push the builds to 4am for chromium ;)
<asac> hehe
<asac> last time i said that
<asac> i promiss
<fta> i have new problems with those 3 ppas now, like should i align the codecs and gyp on each version, or let those 2 track trunk..
<lool> asac: chromium on armel weee \o/
<asac> yeah
<asac> lool: do you remember why NEON is disabled for imx?
<asac> someone said CPU hangs ... is that understood?
<asac> fta: i dont know. isnt gyp more or less stable enough to do that on a as-needed base?
<fta> asac, well, yes
<asac> and codecs?
<fta> the code itself is quite stable, but they keep adding patches (mostly to fix security stuff) and build flags may change
<asac> darn. bad syntax error in my commit ;)
 * asac reuploads
<asac> ok retrying with gc 4.4 but with section gc dropped
<asac> its kinda strange. the CC=... isnt honoured for v8 altogether
<asac> still it helped here ;)
<asac> sigh. we should definitly enable V=1 on builders
<asac> there is no reason not to imo
<armin76> ricing
<armin76> lool: why nageia doesn't build stuff anymore?
<lool> asac: TO1 and 2 have broken NEON implementations which will hang with some NEON code
<lool> asac: But TO3 fixes it
<lool> asac: It's a silicon bug, and apparently you can trigger it in some uncommon circunstances, but valid uses cases
<lool> Ideally, we'd have a kernel patch to enable it only on TO3 and later at run time, but I don't think the kernel has any provision for this
<lool> armin76: I have no idea
<lool> armin76: Sometimes the buildd hang
 * armin76 blames rabeeh 
<asac> so since when is thumb (not 2) supported? i guess its good for karmic, but not jaunty?
<lool> asac: ?
<lool> asac: Thumb has always been working
<lool> AFAIK
<asac> cool
<lool> Only Thumb 2 and NEON had issues in TO before 3
 * asac enables thumb everywhere then
<armin76>   g++ -pthread -fno-exceptions -fvisibility=hidden -Wall -D_FILE_OFFSET_BITS=64 -fno-ident -fdata-sections -ffunction-sections -fno-asynchronous-unwind-tables -fomit-frame-pointer -O3 -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -DENABLE_LOGGING_AND_PROFILING -DENABLE_DEBUGGER_SUPPORT -D__STDC_FORMAT_MACROS -DDISABLE_NACL -DV8_TARGET_ARCH_ARM -DCHROMIUM_BUILD -DNDEBUG -DNVALGRIND -Iv8/src -Iv8/src/arm -MMD -MF out/Release/ob
<armin76> j.host/v8_base/v8/src/arm/cpu-arm.o.d.tmp -c -o out/Release/obj.host/v8_base/v8/src/arm/cpu-arm.o v8/src/arm/cpu-arm.cc
<armin76> /var/tmp/portage/www-client/chromium-9999/temp/ccs57NS8.s: Assembler messages:
<armin76> /var/tmp/portage/www-client/chromium-9999/temp/ccs57NS8.s:49: Error: selected processor does not support `bkpt 0'
<armin76> make: *** [out/Release/obj.host/v8_base/v8/src/arm/cpu-arm.o] Error 1
 * armin76 complains
<armin76> ah, stupid thing
<asac> hmm ... odd ... what did i do in my build to fix this LOGGING_AND_PROFILING thing
<asac> err
<asac> this virutal function call thing
<asac> it happens again with fresh builds ;)
<armin76> hah
<asac> i remember i removed a bunch of -D stuff
<asac> so its probably one of those
<asac> B
<asac> VALGRIND ... maybe
<asac> or DEBUGGER support ;) or really profiling and debugging
 * asac wonders what this mksnapshot thing does 
<armin76> fta: why isn't the sse2 patch applied upstream?
<asac> the patch isnt applied in our packages
<asac> hmm
<asac> seems it is ;)
<armin76> asacfail
<asac> +            # Disabled: see http://code.google.com/p/chromium/issues/detail?id=9007
<asac> Result: layout tests require SSE2, normal builds probably shouldn't and Google Chrome
<asac> packages don't. We don't control other packages.
<asac> "I understand it's not ideal but as Chrome Linux is now shipped without those SSE2
<asac> flags, i don't see why Chromium has to."
<armin76> ricing!
<asac> dunno what that means ;)
<fta> armin76: because they don't want it in chrome, it makes the testsuite regress
<armin76> i see
<armin76> asac:  echo | gcc -dM  -E -  | grep ARCH <- what does this return to you?
<asac> echo | gcc -dM  -E -  | grep ARCH
<asac> #define __ARM_ARCH_6__ 1
<asac> but i am on karmic
<asac> echo | gcc -dM  -E -  | grep ARCH
<asac> #define __ARM_ARCH_7A__ 1
<asac> thats on lucid
<asac> armin76: ^
<armin76> i see, thanks
<asac> http://people.canonical.com/~asac/screenshots/ffox35_vs_chromium_armel_sunspider.png
<asac> odd that gyp generator make doesnt create clean targets ;)
<asac> http://people.canonical.com/~asac/screenshots/chromium_karmic_armel_whatsmyuseragent.png
<asac> armin76: ^
<armin76> asac: quick!
<asac> just wanted to encourage you not to give up ;)
<asac> did you get further than the prop you posted above now?
<armin76> nope not yet
<armin76> that error happened because we tend to have the packages respect the cflags
<armin76> and we don't use default -march on gcc
<armin76> so it was building for armv4t as i forgot to add -march
<asac> kk
<asac> ok now it seems to work
<asac> those ugly gcc44 flags cause all the trouble
<asac>             'conditions': [
<asac>               [ 'gcc_version==44', {
<asac>                 'cflags': [
<asac>                   # Avoid gcc 4.4 strict aliasing issues in dtoa.c
<asac>                   '-fno-strict-aliasing',
<asac>                   # Avoid crashes with gcc 4.4 in the v8 test suite.
<asac>                   '-fno-tree-vrp',
<asac>                 ],
<asac> thats causing bustage for me
<armin76> and why are you using that?
<asac> me?
<asac> thats not me... thats chromium
<asac> they just run g++ --version ... and if its 4.4 they use those
<asac> would be interesting to know which one it is
<asac> mos tlikely the one preventing crashes ;)
<armin76> ah
<fta> we have tons of bugs that are 44 related
<asac> i will narrow it down now ... pushed one more round to builders to see if it succeeds there
<fta> like http://crbug.com/28749
<asac> imo they play too much with optimization flags ;)
<asac> that calls for troubles ;)
<asac> but lets see
 * asac goes back to 4.4 locally without the no-tree-vrp
<fta> you will crash in v8
<asac> well. i crash with both for sure ;)
<asac> even on 4.3
<asac> at least i dont run test suite ;)
<asac> hehe
<asac> darn. wanted to enable V=1 for that ppa upload :/
<asac> hmm failed on the builder again :/
<asac> wonder if i really included everything
<armin76> asac: on the GYP_DEFINES you're still using gcc_version=44
<asac> no
<asac> that happens automatically
<armin76> ah ok
<asac> hmm
 * asac scratches head
<asac> fta: so is VERBOSE = 1 really that bad that we dont know what flags got passed if something fails on builders ;)?
<fta> well, it's easier to spot errors without it. verbose makes very long lines filling the screen, that's why it's off by default
<asac> heh?
<asac> i think now with make build fails right away anyway
<asac> and you usually want to see the lines
<asac> if there are build failures
<fta> failing right away is not related to scons vs make, both has --keep-going, i just forgot to re-enable it since i move to make :P
<fta> +se +d, grr
<mturquette> i see on https://wiki.ubuntu.com/ARM that "Kernels are planned for omap targets".  Who is working on that?  I'd like to see what progress is made and how I can help.
<Martyn> mturquette : Actually, that is for the omap4
<Martyn> once it's comes out ..
<Martyn> *thinks*
 * ojn looks to his right
<Martyn> well, for lucid any armv7 ...
<ojn> got one right here. :)
<Martyn> ojn : So do I.. but that's not general availability yet :)
<mturquette> I'm employed by TI, so getting an OMAP4 board is possible.
<Martyn> ojn : That said though, even smooth-stone should have a processor out by the time general availability of the omap4 is there
<Martyn> which is all kinds of yay :)
<mturquette> and I want Ubuntu to rock on OMAP, so I'm trying to find out who to talk to ;-)
<Martyn> Well, you're certainly in the right place.
<ojn> mturquette: the basic work isn't that bad. Doing a kernel package is the easy part. DSP packaging, drivers, 3D accel X server, etc, is the more complicated parts. And none of the other supported platforms do that yet either.
<mturquette> interesting to know.
<mturquette> i'm basically interested in two things:
<mturquette> 1) how hard/much time is it to get the base armv7a packages for lucid working on OMAP (I assume that maybe the RootfsFromScratch wiki page should make that quite easy)
<mturquette> 2) how can I help get support for our accel packages (gles libs for 3D, gstreamer plugins for OMX, etc etc)
<ojn> mturqutte: 1) is easy. That's what we're doing (Agnilux). It's trivial (rootstock + SD card  or NFS root is my preference). Base system works out of the box, comes up with X, etc.
<ojn> mturquette: on the other packages, working on making deb packages to wrap them up in is a good start. That way you could even distribute them on your own on top of the distro, even if they don't get picked up by official ubuntu. There's a ton of resources out there on how to make debian/ubuntu packages, and this should be a decent place to ask questions about it as well.
<mturquette> sure, i've done dpkg's before.  i'm interested in what process is necessary to get them adopted by Ubuntu.
<armin76> mturquette: i want a board *g*
<mturquette> haha.  you're barking up the wrong tree.
<mturquette> *i* still have to beg for hardware and I work for the damned place!
<ojn> mturquette: good question. I suppose that requires answers from some of the canonical folks on here, of all seem to be quiet. lool, asac? Not sure who handles what.
<asac> mturquette: who are you working for?
<armin76> asac: TI
<asac> heh
<asac> ok
<armin76> not interested? :P
<asac> why not ;)
<asac> so he wants to recompile everything?
<asac> or just produce a custom rootfs?
<asac> mturquette: ?
<asac> armin76: so its strict-aliasing
<asac> unpatch that
<asac> and it will build even on 4.4
<armin76> asac: unpatch what?
<asac> that chromium sets -fno-strict-aliasing for gcc4.4
<asac> one sec
<asac> http://pastebin.com/f2d00a846
<asac> but could be that my build isnt at dtoa yet
<asac> with all 4.3 it works as that doesnt set it
<asac> mturquette: for your driver packages, what help do you want? just advice with how to package?
<asac> third_party/WebKit/WebCore/bindings/v8/DerivedSourcesAllInOne.cpp  takes really really long to biuld here ;)
<mturquette> asac: i'm actually not asking for help.  it seems i'm coming to the party a bit late and I just want to know, how *can* I help?
<asac> heh
<mturquette> i work for TI, on OMAP, all things Linux, and Ubuntu is important to me as another zealot-type.  so basically what has been done, what hasn't?  what is blocking you?
<Martyn> Ahhhh!
<Martyn> Now I know who you are :)  -laugh-
<Martyn> San Mehat and I were talking about you not that long ago
<Martyn> (nothing bad!  We were just discussing power management in OMAP vs other platforms)
 * mturquette is concerned by this turn of events.  ;-)
<asac> fta: no-strict-laiasing is used for gcc_version44=1 in v8 ... unconditionally in WebCore and if no_strict_aliasing=1 is set for the rest of the build
<asac> feels odd
<fta> it was initially just a temporary workaround for a crash in v8 snapshot
<asac> for v8, yes.
<asac> but what about WebCore ... thats right?
<fta> but we later discovered other areas where strict aliasing creates bad code
<fta> with gcc 4.4
<fta> some were understood and fixed, others are just obscure, or gcc bugs
<fta> hence the global no_strict_aliasing=1 i use for gcc 4.4
<asac> fta: yeah. so what you definitly dont need anymore is gcc_version44=1
<asac> thats auto detected
<asac> the no_strict_aliasing is not redundant though
<fta> yes, i know
<asac> however, thats why i ask
<asac> why arent the other uses of no-strict-aliasing being made dependent on gcc 44 rather than having two ways
<asac> and one unconditional way even
<fta> because some devs want to track those down
<asac> not sure how that conflicts with making them gcc44 dependent
<asac> if they are in fact gcc44 dependent
<asac> if they are not, then that answers my question
<asac> guess icu is at least needed for 4.3 at least
#ubuntu-arm 2009-12-31
<armin76> asac: hows it going?
<armin76> ah, i see it built finally :)
<armin76> this is sick
<ojn> ?
<armin76> ojn: chromium fails to build for me because it replaces -Os/-O2 with -O3
<armin76> quick!
<zumbi> armin76: do you use eglibc?
<armin76> zumbi: nope
<zumbi> armin76: i heard -Os does not work with glibc
<armin76> zumbi: that doesn't have nothing to do, it still replaces it with -O2
<zumbi> armin76: sure
<zumbi> anyway, i am going out.. happy new year 2010! :-)
#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 2.6.32.1-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 discover at bugs.freedesktop.org under product 'pixman'
 * bizkut is away (i am away now)
<armin76> lool: ^ :D
#ubuntu-arm 2015-12-28
<feep> reasking: hi, why is firefox built with --disable-webrtc on arm? and where can I get a build that has webrtc?
#ubuntu-arm 2015-12-31
<tobia> ubuntu mate doesn't seem to read the config.txt under /boot/firmware/
<tobia> e.g. I have black borders (overscan)
<tobia> how can I check if clocking worked?
<tobia> overclocking didn't work either, the file completely is ignored.
#ubuntu-arm 2016-01-01
<caden> Hey, I am having problems with installing the Ubuntu desktop. Whenever I install it I cannot login. It will wait a few seconds, the screen will go black and it takes me back to the login screen
<k1l_> caden: sounds like the wrong video drivers? ist that image known to work?
<caden> no, i have xubuntu installed and it works just fine
<k1l_> who is the owner of the .XAuthority file in that users home?
<k1l_> .Xauthority
<caden> sorry, you will have to tell me how to do that. (i'm new to ubuntu) :)
<k1l_> "ls -al " in a terminal
<k1l_> what device is it? what ubuntu version?
<caden> my device is a raspberry pi 2b and it is runnning ubuntu mate and xubuntu 15.04
<caden> oh and my x.org is configured
<caden> r u there?
<k1l_> who is ownerand group of that file?
<caden> the file doesnt seem to exist
<k1l_> so who is the owner of that users home?
<caden> me
<caden> there is only one user
<k1l_> i am quite sure xfce does need that file, too.
<caden> well i dont know what to tell yo
<caden> *you
<caden> my /etc /X11/xorg.conf exists and has text in it
<k1l_> its not about the x11
<caden> well thats the video driver's config file
<k1l_> the desktop needs the .Xauthority file in the users home.
<k1l_> and that owner and group needs to be the user.
<k1l_> if you fiddel with sudo/root that can make that file be owned by root. and then you get exactly the effect, that you cant login anymore.
<caden> ok sorry the file DOES exist. i was looking i /home instead of my user's home
<k1l_> who is the owner?
<caden> how do i find that out
<k1l_> "ls -al"
<caden> i am the owner
<k1l_> in terminal. if you open a terminal it will be in your users home.
<caden> ya i know a lot about terminal;
#ubuntu-arm 2016-01-02
<caden> Hey, I am having troubles logging in with the regular Ubuntu desktop on my Raspberry Pi 2B.
