#ubuntu-arm 2009-11-30
<cwillu_at_work> Hmm.  Having some difficulties getting a beagleboard to give me anything better than 640x480 (it should be running at 1024x768, with some reports of success at 1280x1024)
<cwillu_at_work> ugh, may just be me
<armin76> lool: does the lange board have sata?
<Meizirkki> does anyone here know if the debian unstable is no more armv4t ?
<armin76> Meizirkki: suihkulokki should know
<Meizirkki> ok
<ogra> armin76, no imx51 based board has sata yet
<armin76> ogra: i thought the babbage did?
<asac> no
<lool> armin76: No
<lool> armin76: Well there are multiple lange boards, but none of them has SATA I think
<armin76> ack, thanks
<lool> armin76: The babbage 2.x+ boards have a SATA port but it's actually wired to USB IIRC
<lool> (I think it's wired to USB, but I'm not sure it's not wired to PATA)
<lool> Plus, there's a software bug with the SATA port too
<armin76> lool: well, better than nothing :)
<ogra_> there is a patch and there should be an SRU soon
<cwillu_at_work> anyone have any success running karmic on a beagleboard at a video resolution better than 800x600?
<cwillu_at_work> I can't seem to get this figured out;  my lcd complains about the signal being out of range; as far as I can tell I'm running at 1024x768MR16@60, but I don't know that for sure
<cwillu_at_work> the lcd works fine on the default oe install
<cwillu_at_work> could somebody give me a hand?
<cwillu_at_work> woot, I have success!
<ogra> lool, tickle
<ogra> lool, in linux-user/arm/syscall.h in qemu user we have a hardcoded #define UNAME_MACHINE "armv5tel" for all little endian arms ... what do you think of defaulting that to v7 ?
<lool> That's odd
<ogra> well, the current situation is bad for using qemu for lucid stuff
<ogra> and i think we should match our default compile settings here ... probably with a commandline switch though
<lool> I'm fetching an up-to-date qemu.git to see if it's still relevant
<lool> ogra: I think it should report whatever is emulated
<lool> Not a hardcoded string
<ogra> well, how do you tell which exact armel platform is emulated with qemu-user :)
<ogra> it surely makes sense to do that for qemu-system
<lool> Still an issue in tip
<ogra> but -user will just emulate "something"
<ogra> and translate the syscalls
<lool> ogra: I guess they report the oldest uname which supports EABI
<ogra> right
<ogra> which doesnt help us on lucid
<lool> ogra: perhaps it's nicer to just use linux32 style overrides for this?
<ogra> i pretty much doubt there are many differences between the actual syscalls, but if apps use uname anywhere they will get the wrong thing returned
<lool> ogra: There are no differences since it's all EABI
<ogra> right
<lool> You can copy EABI binaries around to different armvN, as long as the binaries don't use instructions for the newer arches
<lool> sh-4.0# setarch armv7l uname -m
<lool> /usr/bin/setarch: armv7l: Unrecognized architecture
<lool> Hmm
<armin76> :D
<lool> Just needs implementatin in util-linux apparenlty, seems trivial
<lool> ogra: Actually I have to ask: why do we care?
<lool> Some packages might default to looking at uname output, but that's wrong
<ogra> lool, oem seems to use qemu-arm-static for testbuilds etc, lamont pinged me that he gets the wrong uname info
<ogra> well, depends ...
<lool> Yeah I told them about it
<ogra> for sure you shouldnt use uname during buiold
<lool> Perhaps it's someone else though
<ogra> but i bet there are a ton of packages that use uname calls at runtime, from scripts etc
<ogra> if you want to test your stuff and it relies on uname it will not work
<ogra> i agree its a failure if a package uses it at build time
<lool> ogra: I think setarch is an elegant fix
<ogra> if it works :)
<lool> I'm not sure whether we want to allow v5 -> v7 by default, so it might be good to add some force flag or something
<lool> ogra: it's a trivial table
<ogra> ah, well .... /me puts it on TODO to take a look at some point
<ogra> i just brought it up bacause lamont asked about it
<ogra> i dont think its *that* important
<fta> asac, could you please file bugs against chromium wrt the tests that abort but leave children behind?
<fta> asac, also if you feel brave, one bug per FAILED would be nice (the ones that are ARM only)
<stevesmith1983> hi all
<stevesmith1983> I've got a tevion pvr hardisk video recorder, wondering about trying ubuntu on it.  is the kernel mentioned in the last paragraph of https://wiki.ubuntu.com/ARM goingto be suitable?  I've never tried ubuntu on arm before!
<ogra> no, thats a qemu kernel for the emulator
<ogra> god, that page is horridly outdated
<armin76> :D
<stevesmith1983> lol!!
<stevesmith1983> ahh
<armin76> stevesmith1983: its highly unlikely you're going to find a kernel
<stevesmith1983> ah, okay :(
<stevesmith1983> I know nothing about kernels really
<ogra> see the url in the channel topic for the last paragraph ...
<stevesmith1983> well, I know what they do, just not how they do it :P
<stevesmith1983> ah, I have that webpage onscreen already...
<ogra> unlike x86 you need a kernel specifically build for the mainboard you use if you work with ARM
<stevesmith1983> ohh, I see
<stevesmith1983> the rootfsfromscratch, will that compline me a suitable kernel, or o I have to have someone write me one?
<ogra> so first of all you would have to find the linux kernel for your tevion ... without it you are lost
<stevesmith1983> *do
<stevesmith1983> well, it's got linux on it now, so could I use the existing kernel if I can get it off there?
<ogra> the rootfs from scratchj will only create you a userspace root filesystem
<stevesmith1983> that makes sense
<ogra> no kernel or modules or anything
<stevesmith1983> kernels aren't distro specific, are they?  so since it's runnign some version of linux now, I could use that kernel with ubuntu on it, have I understood that right?
<ogra> you probably could
<ogra> there are other arm specifics ...
<ogra> like the version of the arm implementation
<ogra> jaunty was supporting ARMv5 CPUs ... karmic only ARMv6 and lucid will only work on v7 CPUs
<stevesmith1983> I haven't yet dug out a datasheet for the one I've got, so not sure which arm version it's got in it
<ogra> so you first have to find out what implementation your CPU is and then you can make a decision what release/reootfs to use
<stevesmith1983> this is all sounding a bit out of my depth, I think!
<stevesmith1983> maybe I'm just going to have to accept that not everything in the house including the toaster needs to run ubuntu...
<ogra> heh
<stevesmith1983> :)
<ogra> you should probably ask in #ubuntu-toaster :)
<stevesmith1983> well, thanks so much for your help anyway, you've saved me hours of research!!
<stevesmith1983> haha :P
<ogra> welcome
<Q_Continuum> why is Ubuntu rapidly dropping arm5 and arm6 anyway?
<stevesmith1983> I'll have a go at seeing if I can get into a shell on it with the current version of linux it's got on it, that'll keep me busy for long enough :)
<Q_Continuum> I bought a SheevaPlug because Ubuntu ran on it, now it's basically EOL'd for 12 months from now :-(
<ogra> i heard ruoumors that the newer sheeva should run a dove CPU
<ogra> for which we provide images since karmic
<ogra> s/dove/armada iirc ... afaik it was renamed
<stevesmith1983> speak again ogra, bye!
<ogra> bye
<Q_Continuum> Eh, at this point I'll stick to x86 for whatever I end up using.  Either an Atom 330 or one of Via's new chips.  That way I won't have a "SURPRISE!" moment before I even get it set up. lol
<ogra> Q_Continuum, backwards compatibility costs performance ... even though it was a hard decision to make v7 provides the fastest and smallest today ...
<Q_Continuum> yeah
<ogra> v7 is and will stay the smallest denominator though ...
<Q_Continuum> At the same time, I wish the Sheeva had been done with a newer-tech chip
<ogra> even when cortex-a9 comes around next year we'll likely keep v7
<ogra> (we had a quadcore -a9 demo at UDS ... quite awesome)
<Q_Continuum> I was hoping to have a little shell box/email server, but now that I'm stuck with 9.04, and that will die in 12 months, it isn't worth my time to set it up.
<ogra> well, there is debian for pre v7 arches
<Q_Continuum> So for now it'll just have to be my old Athlon64 Desktop Replacement laptop until I have monies
<armin76> yep
<Q_Continuum> Eh, I try to stick to one distro.
<Q_Continuum> Makes it easier to keep track of things
<Q_Continuum> and how long until Debian drops v5? heh
<armin76> knowledge doesn't hurt :)
<Q_Continuum> knowledge doesn't hurt, but time is the limitation.
<armin76> don't think they ever will
<armin76> ogra: why ubuntu doesn't support the beagleboard?
<ogra> no comment :)
<ogra> our userspace does though ...
<armin76> ogra: why not?
<ogra> we just dont have distro kernels
<ogra> armin76, simply because nobody stepped up to maintain a kernel for it ... you are free to package one for uinverse
<ogra> *uni
<armin76> lol, no thanks :)
<ogra> anyway ...
 * ogra calls it a day now ... 
<ogra> for real ! :)
<cwillu_at_work> wait, who said ubuntu doesn't support the beagleboard?
 * cwillu_at_work is on a beagleboard right now with a nearly stock ubuntu
<cwillu_at_work> oh, kernel
<cwillu_at_work> ogra, what is involved in maintaining a kernel package for it?
 * cwillu_at_work has a bunch of beagleboards in little boxes that he has to support anyway
<cwillu_at_work> (afk, back later)
<Linjan> Ð´Ð¾Ð±ÑÐ¾Ð¹ Ð½Ð¾ÑÐ¸
<Linjan> Ð·Ð°ÑÐ¾ÑÐµÐ»Ð¾ÑÑ Ð¼Ð½Ðµ Ð²Ð¾Ñ Ð¿Ð¾ÑÑÐ°Ð²Ð¸ÑÑ ÑÑÐ¾ ÑÑÐ´Ð¾ Ð½Ð° O2 Xda Flame
<Linjan> Ð²Ð¾Ð·Ð¼Ð¾Ð¶Ð½Ð¾ Ð»Ð¸?
<lool> ELANG
<Linjan> english?
<lool> Yeah
<Linjan> ok
<Linjan> good night
<lool> I'm afraid we don't support phones
<lool> You can use an Ubuntu chroot if you like
<Linjan> i want to install ubuntu-arm on O2 xda flame
<Linjan> now it working on Windows Mobile 6.1
<Linjan> hm
<Linjan> ARM here is not a type of CPU?
<lool> It is
<lool> But you need some kernel to run it on
<Linjan> where can I read a... manual, for example
<Linjan> or known issues
#ubuntu-arm 2009-12-01
<neel_> hi i need some help with a OMAP3 board
<neel_> hi i need some help with a OMAP3 board
<amitk> neel_: what help?
<neel_> oh hi
<neel_> sorry you still there amitk?
<lool> ogra, asac: I'm writing an email summarizing my research and thoughts on the UDS session we had on debootstrap/qemu-arm; I was writing this as an email to you two, should I send it to some ML instead?
<lool> I'm not sure ubuntu-mobile@ is good for this, and people might lack context, but I would also like this to be archived so that I can point to it during discussions
<lool> ogra_: 15:00 < lool> ogra, asac: I'm writing an email summarizing my research and  thoughts on the UDS session we had on debootstrap/qemu-arm; I was  writing this as an email to you two, should I send it to some ML  instead?
<lool> 15:00 < lool> I'm not sure ubuntu-mobile@ is good for this, and people might  lack context, but I would also like this to be archived so that I  can point to it during discussions
<ogra_> hmm, i was planning to put a TODO item for that into the spec
<ogra_> probably just add it to the wikipage ?
<lool> Ok
<GrueMaster> asac: wrt mobile-lucid-arm-lib-tests, the issues I'm running into are mainly poor/out of date documentation and the way the system is designed.  Each test build requires the LSB build environment, which is a set of library stubs.  This is generated partially from a database of functions.  I just got the mysql database up and running (poor documentation) on my desktop, need to get my dove to connect to it.
<GrueMaster> After I get database connectivity, I need to figure out how to populate the database with info on arm.  Right now it has none.  Once I get that, there is a script in the build_env source tree to generate new code for arm.
<asac> GrueMaster: right.
<asac> sounds like a plan
<asac> remember to document what you do to setup etc.
<GrueMaster> Heh, yea.
<asac> in that way if you get blocked we can have someone else helping you ;)
<asac> without much communication
<asac> this is an important spec for us ...
<GrueMaster> I already have an email in to the linux foundation and key developers of LSB.  I hope to hear from them this week.
<asac> GrueMaster: maybe add progress and things we are waiting for to the whiteboard too
<asac> thanks
<GrueMaster> I could, but it is mostly trial and error at this point.
<asac> GrueMaster: right. what i meant was: asked XXX for clarification; waiting for reply ...
<asac> so we know that we are waiting for something
<asac> but do it like you prefer
<asac> ;)
<GrueMaster> Part of the problem is that while I can get a daily snapshot of their database, they are using an old version of mysql.
<asac> we will review this spec at least weekly ;)
<GrueMaster> I'd rather not say I'm waiting for them.
<GrueMaster> I prefer to continue hacking at this while waiting for them.  That way I'm still making some progress.
<asac> GrueMaster: have you found/documented the source trees by now?
<GrueMaster> Yes, I think I have.  let me check.
<GrueMaster> The only link I don't have is for the ABI tests, and any other tests we may add/replace.
<asac> lool: the idea was to document your qemu approach somewhere ... either mailing list or even in the spec
<asac> GrueMaster: add what you have for now. and maybe split those things in separate work items ;)
<GrueMaster> But the ABI test is a simple script that compares the old libs with the new ones.
<GrueMaster> Ok.
<asac> so we can document that there is progress ;)
<asac> thanks
<asac> ok have to do lunch and stuff
<asac> will be back in 1h or so
<ogra> lunch is a good idea !
<GrueMaster> I have a dental appoinment in 2.5 hours.
<lool> asac: Yeah that's why I was wondering where
<lool> asac: But I didn't think of the wiki and will copy that to the wiki now that I finished typing it
#ubuntu-arm 2009-12-02
<jerone-mobile> https://bugs.launchpad.net/bugs/487979
<ubot4> jerone-mobile: Error: This bug is private
<jerone-mobile> ubot4, wrong channel
<ubot4> Factoid 'wrong channel' not found
<jerone-mobile> ubot4, sorry about that
<ubot4> jerone-mobile: Error: I am only a bot, please don't think I'm intelligent :)
<Ramiz> hello
<Ramiz> any one know ETM 3.2?
<Ramiz> any one know ETM 3.2?
<Ramiz> hi
<Ramiz> hi
<Ramiz> any one know ETM 3.2?
<Ramiz> any one know ETM 3.2?
<Ramiz> any one know ETM 3.2?
<ojn> Ramiz: Repeating your question over and over will not give you a quicker answer
<Ramiz> no i am so sorry
<Ramiz> i repeted cuz i did not sure if it sent or not cuz i am not login
<Ramiz> sorry
<Ramiz> i am wating
<ojn> ah. What's ETM anyway?
<Ramiz> Embedded Trace Macrocell
<ojn> ok, figured it was but was but wanted to make sure. I'm guessing most people here aren't working with tools that low level
<ojn> you might be better off asking in a group related to the specific SoC you're trying to debug
<Ramiz> where i can find this on irc u think?
<ojn> depends. what chip are you working on?
<Ramiz> it is arm11 cutome one
<Ramiz> it is like omap
<ojn> custom? so your own soc?
<Ramiz> it is not mine
<lool> ogra, asac: I see https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-multiarch-execution-environment just got a work item: research possibility of integrating the build-arm-chroot script
<lool> functionallity directly into debootstrap (2 days): TODO
<lool> Isn't that what I just did?
<ogra> lool, well, sending that patch to colin, getting it approved upstream etc ... see the spec now, we postponed it
<lool> Is it research or is it implementation then?
<ogra> if we keep binfmt as well as the build-arm-chroot script for now the world wont end
<ogra> well, actually both, i could have formulated it better
<lool> This work item doesn't mention the static versus shared bit
<asac> the work items are kind of void as we pushed it back for lucid
<ogra> lets just keep it as is... if one gets to create the code beyond a proof of concept it gets implemented ... i consider it nice to have
<asac> if you want to fill stuff in in the spec go ahead
<ogra> s/it gets implemented/and it gets implemented/
<lool> I've put down my research; did you guys check it out?
<lool> I was surprized not to hear back from any of you two
<ogra> i read it, yes
<asac> ogra: right. thats what "Low" means. if someone gets to it fine. otherwise no problem
<lool> s/put/written
<asac> lool: will read it later today. needed to work full-time on spec stuff esterday ;)
<ogra> lool, if you feel like implementing what you found, feel free (i'm not really happy with the idea to fiddle with binfmt on the fly, but as long as it doesnt stop working i dont care)
<lool> What would really rock is doing it with multiarch, but it's not clear it will happen this cycle
<ogra> right
<lool> ogra: Well I'm not happy with relying on the host setup instead   :-)
<ogra> until then i'm happy to keep it as is
<ogra> right, i know
<lool> Frankly where the binfmt stuff happens is just a technical detail; I hate the requirement that the chroot pathname needs to match the host pathname though
<ogra> as i said, as long as the functionallity persists i dont really care, if you have spare cycles to implement it your way, feel free
<lool> Moving binfmt to this script is the only thing I didn't research -- as noted -- I dont know whether it's container friendly
<lool> It's probably though to do it in the chroot without a special helper: you can't run anything in the chroot without the wrapper and you need to setup the wrapper from withing the chroot for the container stuff to work  :-/
<ogra> i think the container stuff happens at another level ... i wouldnt see why it shouldnt work
<ogra> the kernels binfmt module just reacts on the magic number ... i dont think it cares if that happens in a container or not
<ogra> as long as the wrapper is found at least
 * suihkulokki has a way to execute arm binaries in a chroot using a dynamically linked qemu-arm without binfmt_misc
<lool> suihkulokki: I can do that for a single binary as well, but not one that forks
<suihkulokki> including forks
<lool> suihkulokki: Oh scratchbox2?
<ogra> lool, anyway, if you find a way thats as easy as buiold-arm-chroot for the user, feel free to go ahead and implement it
<suihkulokki> well, sb2 can do that too
<lool> suihkulokki: Would love to hear your way then
<suihkulokki> my way is just much more lightweight
<lool> suihkulokki: I've documented what I tried in https://wiki.ubuntu.com/Specs/Mobile/QemuStaticExecutionEnv/Research
<ogra> what i dont want is that the user needs to type in a chain of commands and options to create a chroot
<lool> ogra: That can always be reduced to a script    :-)
<ogra> as i said, feel free :)
<lool> ogra: My worries with the proposals I heard at UDS were: specific to Ubuntu, package proliferation
<ogra> i will only put time into it if i actually have a lazy day before FF ...
<ogra> which is unlikely
<suihkulokki> I hope to show my way next weekend latest
<lool> suihkulokki: Well you said too much now; mind sharing the high-level idea?
<lool> suihkulokki: Did you patch qemu to spawn itself on forks?
<lool> or exec rather
<suihkulokki> basicly a LD_PRELOAD a library that executes qemu on exec if the binary to be executed is not host arch
<lool> Ok; I thought of something similar by patching qemu's syscall emulation of the exec() syscall
<lool> Your approach is probably more self-contained and might also allow calling into a host binary more easily
<lool> Hmm not sure actually
<lool> LD_PRELOAD has to be inherited by all childs; it fails with env -i and the new childs will look for the preload data in the chroot
<lool> But still more self contained
<Stskeeps>  ld.so.preload maybe?
<dpb> and will fail for static binaries..
<suihkulokki> dpb, look, the ld_preload only affects qemu, not the binaries running inside qemu so it doesn't matter if the muck the env or are static
<suihkulokki> s/look/lool/
<lool> suihkulokki: Oh so it's a ld_preload trick to change qemu's behavior for exec(); ok that's exactly what I thought of except I envisionned that in the qemu code itself
<lool> That would work very well I think; good idea
<suihkulokki> lool: yeah. if some hardcoding is acceptable it would be easy to do the same modifying qemu's exec
<lool> suihkulokki: Is hardcoding really necessary?  can't qemu-arm exec() into itself with enough info to proceed to the target binary?
<dpb> suihkulokki: ah, right. I'm tired. :)
<lool> (I didn't look at the qemu syscall emulation itself at all, so feel free to call that impossible or very hard!)
<lool> asac: glib > we want to get rid of swp uses for v7 in any case, a short term stop gap would be to change the build flags of glib to build in arm mode; that would at least avoid failing a gazillion of builds, images etc.
<asac> lool: right. we dont want arm mode ... unles we cant find a patch quickly ;)
<lool> Well I'm only suggesting that as a stopgap
<lool> glib impacts a lot of packages
<lool> Of course we want thumb2
<ogra> lool, do you know swp will fail with -Wa,-mimplicit-it=thumb ?
<asac> lool: right. i just hope we can have a patch really quick ;)
<asac> (this afternoon)
<lool> I think it's not available in t2 mode
<asac> otherwise i agree we hsould upload with -marm
<ogra> hrm
<lool> Which would seem logical since v7 introduced thumb2 AND new stuff to get rid of swp
<asac> http://paste.ubuntu.com/333081/
<asac> thats the code
<lool> SWP instruction
<lool> is not supported in Thumb2 mode at all
<asac> i know
<lool> As confirmed from the Slide 5 notes in https://wiki.ubuntu.com/Mobile/ARMv7AndThumb
<asac> ;)
<lool> You were asking whether implicit-it=arm would help, it will not
<lool> I just double checked
<asac> its also here: https://wiki.ubuntu.com/ARM/Thumb2
<asac> lool: right. thats what i suspected
<lool> or here https://wiki.ubuntu.com/Mobile/ARMv7AndThumb
<lool> Well since ogra was about to fire a build with implicit-it=, I figured it was worth mentionning that it wouldn't help
<lool> Anyway, /me hops to pressing stuff
<ogra> well, i'm still writing on a spec
<asac>   __sync_val_compare_and_swap
<ogra> i wouldnt have fired it off right away :)
<asac> is there a good resource to track armel build failures?
<lool> ubuntuwire
<lool> http://qa.ubuntuwire.com/ftbfs/
<asac> th
<asac> x
<lool> that's the failing qt4-x11 code http://paste.ubuntu.com/333247/
<lool> The #else
<ogra> ../../corelib/io/qfsfileengine_unix.cpp:1309: error: unrecognizable insn:
<ogra> (insn 636 635 218 23 ../../corelib/io/qfsfileengine_unix.cpp:1286 (set (reg:SI 9 r9 [+4 ])
<ogra> set reg sounds like assembler to me, surely not like C++
* 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 | build probs with your packages in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2
<ojn> Hm, what's the reason for using softfp? I thought all supported platforms today had proper implementations?
<ojn> oh, nevermind. that's just the abi
<fta> asac, do you need -Wa,-mimplicit-it=thumb or is -mthumb good enough?
<ogra> fta, https://wiki.ubuntu.com/ARM/Thumb2
<ogra> i dont think -mthumb is enough
<fta> i get /tmp/ccRUIN1V.s:131: Error: thumb conditional instruction should be in IT block -- `moveq ip,#8'
<fta> but as it happens after 19h+ of build, i prefer to ask ;)
<fta> i should probably setup a crosscompile env
<ogra> no, that gets painful
<ogra> since you need to cross build all the deps first
<ogra> crossbuilding is fine for packages with only a few deps ... i wouldnt build something with lots of deps in a cross way
<fta> ogra, upstream provides this recipe: http://code.google.com/p/chromium/wiki/LinuxChromiumArm
<fta> looks possible but could be easier :P
<ogra> well, as long as you are sure the cross toolchain they provide uses the same options, that might work
<zumbi> ogra: our cross toolchain is not sysrooted
<ogra> zumbi, well, does it default to the options documented on https://wiki.ubuntu.com/ARM/Thumb2 ?
<zumbi> ogra, no, i do not think so
<ogra> right, thats what i suspected
<ogra> so it doesnt help much unless you hack around it in debian/rules since fta wants to fix build errors happening on the buildds
<zumbi> btw, which cross tool do you use? lool PPA?
<ogra> none
 * ogra is highly anti cross :) i build on real HW
<zumbi> ogra: do you native build kernels for new bootstraps?
<ogra> for small packages i use the ubuntu qemu-arm-static package
<ogra> oh, for test kernels i sometimes use codesourcery ...
<zumbi> yes, qemu is nice and helpful, also cross building
<ogra> but most of the time i simply use my dove board :)
<zumbi> which is fine and if you have the time and the power, it is best practice :-)
<ogra> but cross building does only cut down buildtime in half or so ... and i usually dont touch kernels
<zumbi> ogra: you can not native build a uclibc based device (no space)
<ogra> we dont use uclibc in our ubuntu images
<ogra> all devices we support have at least 800MHz and 512MB
<ogra> and usually a SATA port
<armin76> ricer board
<zumbi> yes, in those cases, cross building is not needed
<zumbi> but, i can not native build on my lynksys
<ogra> armin76, still envious, eh ?
<ogra> zumbi, well, i did native builds on my nslu2 ... but i agree its no fun
<ogra> armin76, just wait for the next gen sheeva plug :)
<armin76> boo
<armin76> ogra: why do i have to wait?!
<ogra> it will be dove based
<ogra> at least thats what roumours said :)
<zumbi> armin76: still you have not got an armv7?
<armin76> zumbi: nope
<armin76> zumbi: ogra doesn't wanna share *g*
<zumbi> armin76: get a beagleboard :)
<ogra> or if you are rich, get a babbage board
<zumbi> ogra: cross building is needed when you have to maintain a distro which runs on 4MB devices up to several GB
<ogra> indeed
<ogra> luckily ubuntu went beyond that :)
<zumbi> also uclibc would enter in thecocktail
<Stskeeps> zumbi: or compiling qt and not waste several days on it :P
<zumbi> qt-embedded ?
<armin76> ogra: i could get your babbage *g*
<ogra> Stskeeps, https://launchpad.net/ubuntu/+source/qt4-x11/4.5.3really4.5.2-0ubuntu1/+build/1292073 22h :) not even a day
<ogra> armin76, sure, i could sell it to you :) it being used i would even go down with the price by $50 ... so it would only be $700 :P
<ogra> afaik freescale sells them now
<ojn> genesi are shipping their pegatron smarttop rebranded device too (with u-boot as firmware)
<ogra> right, but you could only use ubuntu userspace with it
<ogra> there is no pegatron kernel
<ogra> and its stuck on 2.6.28 ...
<ojn> yeah i know. nice gpl compliance there.
<ogra> heh
<ogra> lucid will use uboot on the babbage too ...
 * ogra calls it a day
<ojn> yikes, 800 bucks from arrow
 * zumbi wonders if any of you know mpc8548 ppc processors
<ojn> zumbi: plenty of people on #mklinux do
<zumbi> ojn: yes, i just went there
<fta> ogra, i'm confused by the "-Wa,-mimplicit-it=thumb is not implemented as of gcc-4.4 4.4.2-3ubuntu1".. does it mean that passing it is useless as won't work, or that it's just not yet the default?
<fta> +it
#ubuntu-arm 2009-12-03
 * cwillu_at_work pokes at rcn-ee 
<rcn-ee> how's it going cwillu_at_work
<cwillu_at_work> building my debs in qemu as we speak becuase _somebody_ didn't build it for me :p
<ojn> qemu? painful.
<rcn-ee> well that's the proper way, no cross compiling allowed! ;)
<cwillu_at_work> what's the slow down in comparison to doing it native?
<cwillu_at_work> I was figuring that 2gb of ram + quad cores at 2.6ghz is faster at playing arm than an arm is
<ojn> pretty bad last time I compared (native freescale vs qemu on nehalem). Don't remember exactly how many times slower qemu was though.
<rcn-ee> man it's been a long time, but i think it took like 6 hours on my old x2 4200 to build 2.6.27 where the beagle did it in like 3... haven't used qemu since.. ;)
<cwillu_at_work> maybe I'll race them next time
<ojn> been toying some with scratchbox2 here. it's not entirely pain free either (especially when you realize you need another package installed), but performance is reasonable
<rcn-ee> cwillu_at_work, qemu is also not very good with multicores, so maybe two-three qemu sessions with distcc to share the compile.. ;)
 * cwillu_at_work nearly resists the urge to say "meh, I get paid by the hour" :p
<ojn> if you're going to distcc then you might as well distcc out to a native cross compiler
<ojn> that'd be better/faster/easier
<cwillu_at_work> that actually sounds sane
<ojn> what would be nice is if there was a shipped version of the cross toolchain for x86{,_64} that was built from the same sources as the native arm toolchain, just to be bug compatible with native builds.
<ojn> any plans on providing that, canonicalites?
<rcn-ee> i just want to get a setup like a guy on the beagleboard group email is building, a 13U server with 44+ beagles...
<ojn> rcn-ee: why would anyone want that?
<rcn-ee> take on the top500? ;)  not sure, but he's doing it..
<rcn-ee> Eric Fung here: http://groups.google.com/group/beagleboard/browse_thread/thread/f5f14f4ec66ab45d/df03479bf1ca0861?lnk=gst&q=44#df03479bf1ca0861
<ojn> Haha. the beagles aren't exactly fast. sounds like a good way to burn 5000 dollars to me.
<rcn-ee> since they are backordered he will be getting the new 720Mhz ones..  But otherwise it's hard to find cheap cortex-a8 boards...
<ojn> oh, he uses them for industrial automation? still, sounds odd not to do something more monolithic.
<cwillu_at_work> rcn-ee, is that why we can't buy beagleboards these days? :p
<ojn> rcn-ee: I prefer my cortex a8's to be able to cache clean data in l2. 3430/3530 can't. pretty amazing actually.
<rcn-ee> the dvi/video chip is very hard to get right now.. So the boards can't be finished for sale...
 * ojn heads to dinner.
<rcn-ee> ojn, yeah, the cortex-a8 in the beagle has a couple bad bugs, my chroot is puking on every lucid update right now... :(
<ojn> rcn-ee: it's got the thumb2 bug but the ubuntu toolchain should have the workaround for it. i don't know if it's enabled though?
<ojn> s/the thumb2 bug/the thumb2 branch bug/
<ojn> might be fixed in the new ones, not sure.
<rcn-ee> yeah, i think it's that one.. although my quick gcc compare didn't show too much damage.. thumb: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02447.html and nonthumb: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02538.html
 * zooko reads https://wiki.ubuntu.com/Mobile/ARMv7AndThumb
<zooko> Is it publicly known who are the hardware makers working with Canonical on ARM devices?
<ojn> Marvell and Freescale make the boards that are officially supported, if that's what you mean?
<zooko> I meant the story that Canonical is working with makers of netbooks./
<zooko> I suppose which makers is secret.
<zooko> Or maybe I'm supposed to call them smartbooks if they are ARM based.
<zooko> By the way, I'm also really interested in ARM-based servers.  Hard to find.
<ojn> Oh. Yeah, I don't think they've talked publically about that
<zooko> http://perspectives.mvdirona.com/2009/11/30/2010TheYearOfMicroSliceServers.aspx
<ojn> there aren't many arm based servers, no. smooth-stone are supposedly working on something but I'd expect silicon product to be years away from mass production
<ogra> fta, it means that the default is supposed to change, but that gcc version doesnt have the change yet (it's supposed to happen with the next upload of gcc)
<fta> ogra, ok, thanks. that sentence is just confusing then.
<ogra> its a wiki, feel free to fix ;)
<ogra> dmart, you rock !
 * ogra does a testbuild of glib
<dmart> -er- not yet, I've just been looking at the compiler output... __sync_synchronize() compiles away to nothing :(
<dmart> We're looking into this, but I might suggest using a slightly different patch using __sync_lock_test_and_set() and __sync_lock_release().  This will be cleaner example for people to copy, and avoids the explicit __sync_synchronize() call.
<dmart> Shall I just supply another patch on top of the old one?  The code will build as-is and work on Cortex-A8, so we have no immediate problem.
<ogra> dmart, hmm, i have some prob with your patch ...
<ogra> it succeeded with offset, i triggered a build but failed ... looking closer i see that:
<ogra> patching file glib/gatomic.c
<ogra> patching file configure.in
<ogra> Hunk #1 succeeded at 2491 (offset 11 lines).
<ogra> root@babbage2:/glib2.0-2.23.0# wc -l  glib/gatomic.c
<ogra> 1089 glib/gatomic.c
<ogra> did you patch the actual latest lucid upload ?
<ogra> or a former source
<dmart> It was against 2.22.2.  Do source packages not appear in the archive until a successful binary build has been uploaded?
<ogra> they do, did you apt-get update before apt-get source  ?
<ogra> 2.23.0 here
<dmart> Hmmm, possibly not.  I'll try again
<dmart> Is it more conveinent to provide a patch which applies on top of the patch stack in debian/patches, or against the original files (which is what I gave you before)?
<ogra> both is fine
<dmart> OK, now 2.23.0-1ubuntu1
<dmart> Is the build log for your failure visible on launchpad?
<ogra> do as you like it most, someone needs to touch the package anyway for sponsoring the upload
<dmart> OK... I'll attach a new patch to the bug when I've sorted it out.
<ogra> (its indeed less work if the patch is on top of the stack but doesnt make a big difference)
<asac> ogra: whats the prob?
<asac> configure.in problem?
<ogra> asac, the build fails with the same error due to the patch being for the karmic version
<asac> well.
<asac> but that cant be a big problem
<asac> its just confiugre.in, right?
<ogra> yes
<asac> ogra: it applies ... sure you ran autoconf?
<ogra> doesnt debian/rules do that ?
<ogra> hmm, seems not
<asac> no
<asac> gnome packages dont do that
<asac> you have to do a patch
<ogra> i thought they usually use some autoreconf.mk thingie
<lool> No
<asac> no
<ogra> ok
<asac> thats dirty anyway
<ogra> i know but i thought i saw that before in gnome packages
<asac> ogra: just remove the if stuff etc al
<asac> ogra: those are not real gnome packages then ;)
<asac> anyway
<asac> http://people.canonical.com/~asac/tmp/70_glib2.0-gatomic-arm.patch
<asac> ogra:
<asac> use that
<asac> and ignore the confiugre stuff
<ogra> oki
<asac> has a hacked "define ..." obviously not for upstream, but beter than doing the full configure thing in package
<ogra> yeah
<asac> dmart: so no need to update it to lucid version from what i see. should be ok as it is for now ;)
<dmart> ^ I had to rerun autoconf, but I didn't publish a patch for configure itself, because it came out half a MB smaller than before, which I found a bit scary
<dmart> Do you need an extra patch from me?
<dmart> ogra, asac, do you need an extra patch, or are you OK for now?
<asac> no all fine. thanks a lot
<asac> once we know we let you know ;)
<ogra> got past gatomic.c/o
<asac> very good ;)
<ogra> so seems all fine
<ogra> i'll let it finish
<dmart> Is it usual to upstream things like this, and what would the timescale be?
<ogra> heh, depends on the upstream i guess
<asac> dmart: real quick if there are no questions etc.
<asac> (for glib)
<dmart> Yeah, of course
<ogra> yeah, glib should be fast
<dmart> Note that we need to patch gcc to work round an issue with the implementation of the atomics; then glib2.0 should be rebuilt.  But the problems will only emerge on multi-core, so this isn't so urgent.
<ogra> right, our main focus atm is to get all packages building for alpha1
<dmart> agreed
<ogra> if we have packages with temp workarounds we need to touch later again, we should collect them somewhere though
<dmart> I'll upload another patch to tidy up the implementation a bit more in gatomic.  Since this will serve as an example for other packages, I'd like to get this one as clear as possible.
<dmart> orga, is the ARM/Thumb2 page the right place for that?
<ogra> yeah, probably a package section at the bottom would make sense
<asac> we should keep a bug open so we remember to rebuild glib etc. after the intrinsics are fixed
<asac> dmart: ogra: ^
<dmart> asac, ogra: I'm raising a bug on GCC to track this; we can reference it from the existing glib2.0 bug?
<asac> dmart: unfortuantely we can only dupe stuff (which isnt right here)
<asac> dmart: i would suggest to add a new bug to GCC
<asac> and then add the packages we identified as targets
<asac> so after filing the gcc bug, click on "also affects distributioN" ... and select glib2.0 there for now
<asac> then drop a comment that glib is affected blah blah blah and reference the other bug in the comment for background info
<dmart> ogra, asac: Raised: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491872
<ubot4> Launchpad bug 491872 in glib2.0 "[armel] Atomic intrinsics are not implemented correctly" [Undecided,New]
<dmart> I've added a note to https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491342
<ubot4> Launchpad bug 491342 in glib2.0 "assembly fails to build on armel/lucid " [Critical,Triaged]
<ojn> ogra: did you see my question from last night? I.e. are there any plans on providing an x86-hosted arm crosstoolchain built with the same options/from the same sources as a deb?
<ojn> (main use for me would be to use it for distcc:ing across to a faster machine)
<fta2> asac, did you retry chromium?
<armin76> asac: whats the status on chromium? did it build?
<fta2> it should, but i don't have access to any arm builder
<asac> copying now
<asac> just lucid though
<asac> copyied
<fta> asac, sure, no need to even try karmic unless i enforce armv7
<ogra> (karmic is v6 and no thumb)
<fta> ogra, yep, what i meant is upstream only supports v7, at least until someone ports it to something else
<ogra> ah, well ...
<fta> thumb doesn't seem to be required though
<ogra> i think we'Re the only distro building with thumb2 atm
<ogra> not even angstrom (beagleboard default distro and highly optimized) does use thumb
<ogra> given that ubuntu runs on beagle with an externally maintained kernel it will be very intresting if lucid runs faster than angstrom on the beagle
<ogra> roumors say up to 30% size reduction and up to 30% speedup is possible through thumb2
<asac> fta: the problem for non-armv7 was broken assembly?
<lool> maemo used to have thumb1 support, not sure whether they are using thum2 now
<fta> asac, apparently, it's supposed to work even on armv5. but as they don't have an arm buildbot yet, it probably diverged a bit and needs fixes
<fta> asac, when built for android, v8 build system adds a bunch of flags, incl -march=armv5te & -mthumb-interwork
#ubuntu-arm 2009-12-04
<siji> hi all
<siji> good evening
<siji> How to disable VSYNC in Ubuntu+Bealge Board
<fta> asac, http://codereview.chromium.org/download/issue463027_1001.diff
<asac> ok
<asac> but does that help?
<asac> i dont think that would fix builds < armv7
<asac> i agree its right to split this up though
<asac> is there no good codebrowser for chromium?
<asac> with cross reference?
<asac> fta: ?
<fta> no, there's google code search but it's not uptodate
<fta> asac, i wanted to setup an lxr but the deb package is a mess
<asac> kk
<rek> where can i find the repositories?
<ogra> ports.ubuntu.com
<rek> i man
<rek> where can i find what to put in etc sources list
<rek> hi ogra i remember you are in germany now
<ogra> deb http://ports.ubuntu.com/ubuntu-ports <distro> main universe
<fta> asac, chromium succeeded on lucid! \o/   (took 9 hours, 43 minutes, 23.6 seconds)
<ogra> rek, right, thats where i live
 * asac dances
<ogra> 9h isnt bad !
<rek> ?
<rek> ogra it's for a smartq 5
<fta> a big part of these 9h is due to the testsuite
<asac> fta: 9 hours is wrong imo
<asac> i think it started right when i uploaded
<asac> and that was aboug 24h ago ;)
<asac> about
<asac> hmm maybe a few hours later
<fta> Build needed 21:39:16, 6295520k disk space
<fta> hm
<ogra> rek, smartq 5 is ARMv5, right ?
<rek> i have karmic main universe restricted multiverse   i want jaunty
<fta> bad lp
<rek> i think it's arm
<asac> 17:36 < asac> chromium for lucid bits are here: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3
<asac> 17:36 < asac> anyone give it a check?
<asac> 17:37 < asac> https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1377663 ;)
<ogra> sure ... the version counts :)
<asac> dont ask me about the team name ;)
<fta> asac, can't you ask for a rename?
<ogra> rek, but if its v5 you will need to replace karmic with jaunty in your line
<asac> no
<asac> that team is still needed
<asac> ;)
<rek> ok i'll try
<asac> just was too lazy to get a new native ppa
<fta> asac, or ask for more generic team?
<ogra> ubuntu-arm-browser ?
<asac> atm native ppas are not avialable to anyone but employees unfortunately
<rek> ?
<fta> or just an arm native ppa
<asac> i will try to get that revisited
<ogra> i think its blocked on XEN
<asac> i would think that motu/core-dev together with a damn good reason should be ok too
<asac> ogra: reall ppas yes
<asac> real
<ogra> we'd need spare HW for PPA work
<rek> locale not supported by C library why?
<asac> ogra: it was about policy for native ppa
<ogra> right
<ogra> rek, prefix your commands with LANG=C then that goes away ... or run locale-gen <yourlocale>
<rek> don't understand
<rek> it happens also if i do apt-ge
<ogra> right, prefix the commands with LANG=C or generate the proper locale
<rek> what's a locale?
<rek> what does "umet dependencies/it's not going to be installed " means.... every time i try to get a new application
<rek> unmet
<ogra> that means that a depending package is missing
<ogra> a locale is a set of translations etc
<rek> so i cannot have a single application working damn?
<ogra> what exactly are you trying to do ?
<rek> sudo apt-get install amsn for example
<rek> i did apt get f now
<rek> var log apt missing damnit another error?
<ogra> did you do apt-get update after adding the line to sources.list ?
<rek> yeah
<ogra> and the smartq has ubuntu installed already ?
<rek> yes
<rek> ok
<rek> now it works
<rek> wait
<ogra> well, then its likely that a package amsn depends on failed to build and nobody fixed it
<rek> gimme a name of a cool application i can install
<ogra> no idea
<ogra> http://qa.ubuntuwire.org/ftbfs/jaunty.html has the list of packages that didnt build in jaunty
<ogra> as you can see there are a lot of broken packages in universe
<rek> why can't we have a flah?
<rek> flash
<ogra> ask adobe :)
<rek> is that true?
<ogra> they own flash
<rek> how can i have a sound recorder?
<ogra> probably with: apt-get install gnome-sound-recorder
<rek> how can i hae skype?
<ogra> no idea
<ogra> ask skype ... its proprietary
<rek> suggestions?
<asac> rek: check the download page. get the all static tar gz .. .unpack it somewhere in your home and run the skype command inside
<asac> but for arm ;) ...
<asac> hehe
<asac> sry didnt check the channel
<asac> try gnash
<ogra> yeah, gnash might work as flash replacement
<rek> gnash?
<rek> sure?
<rek> and skype?
<ogra> there is no skype for arm
<rek> can i have the sources and compile them all?
<ogra> its proprietary ... as long as skype doesnt offer an arm build ...
<ogra> same as with adobes flash
<rek> strange
<rek> is there something like skype out there?
<ogra> the protocol is proprietary
<ogra> so no
<ogra> they recently released the source for the client but it still uses a binary blob which would have to be compiled for arm
<rek> blob? can i do something?
<ogra> no
<lool> ogra: N810 and N900 have Skype for ARM though   :-)
<pwnguin> woo! Estimated Delivery Date:12/8/2009 (updated)
<pwnguin> nokia n900 on the way
<pwnguin> were there any notes from the arm track at UDS?
<pwnguin> particularly, I'd like to review the stuff i heard about arm board descriptors or something like that
<ojn> device trees? yes.
<ojn> one sec
<ojn> https://wiki.ubuntu.com/UDS-L/RemoteParticipation  see gobby instructions. Notes were taken there (they were still there when I checked a week and a half ago)
<pwnguin> quite a few gobby docs
<pwnguin> hmm. what's the difference between a flattened tree and a list?
#ubuntu-arm 2009-12-05
<powderluv> Folks anyone use rootstock to create Lucid rootfs ? It gets as far as the second stage but qemu doesnt seem to start (prints out usage and bails) so maybe some qemu parameters have changed??
<rcn-ee> powderluv, rootstock as isn't ready for lucid.. it need a couple changes: https://code.launchpad.net/~beagleboard-kernel/+junk/project-rootstock-lucid  doing daily builds with it right now..
<powderluv> rcn-ee: cool thanks i will check it out and let you know how it goes
<powderluv> rcn-ee: do you build ubuntu-minimal
<rcn-ee> powderluv, a lot of packages are in flux so keep it minimal.. although 'xfce4,gdm' worked on this morning's build..
<powderluv> rcn-ee: fyi, ubuntu-minimal works. ubuntu-desktop failed on gedit. so these packages are all built with thumb2 already ?
<rcn-ee> powderluv, until atleast alpha-1 but it could be later it's really going to be very hit and miss with missing packages/dependices..  Yeap, everything should be thumb2, unless the package is broken..  It's still really early thou, i still haven't successfully built a kernel in a native lucid chroot for the beagleboard
<powderluv> ohh because of thumb2 or just churn in the packages ?
<rcn-ee> powderluv, both..  ubuntu has a tinkerbox style build status log, don't remember the address, lots of red for armel..
<powderluv> ok i see. i will dig for it. have you tried running any of the lucid rootfs on a system. is it at a bootable state ?
<rcn-ee> powderluv, found it: http://qa.ubuntuwire.com/ftbfs/
<powderluv> thanks. we are leading the way in number of package failures :)
<rcn-ee> well i have a chroot setup for lucid on my beagleboard i use to build stuff, but lots of "illegal instructions" and random hardlocks.  It would be interesting to run it on a another cortex-aX platform..
<rcn-ee> i even have to rule out thumb mode, since i ran the gcc testsuite with it enabled and disabled, not much difference.  which just leaves bad packages...
<powderluv> i will try them out let you know
<powderluv> do you recompile those packages independently with thumb disabled?
<rcn-ee> powderluv, full gcc bootstrap..  digs for the two reports..
<rcn-ee> thumb: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02447.html
<rcn-ee> nonthumb: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02538.html
<OSS542> Good Evening All
<OSS542> anyone here using Zubuntu  ?
<rek> i want an application like skype
<rek> can i have a flash player?
<armin76> rek: you already asked that yesterday
<rek> really?
<rek> iis there a solution?
<kblin> yeah, reverse engineer the skype protocol and write an app supporting said protocol that compiles on arm
<OSS542> anyone here using Zubuntu  ?
<rek> hi i need an application to refresh my ip,i need also an application to manage a ftp server
<fta> asac, could you copy the codecs package to the arm ppa too? it's needed (dep)
<Stskeeps> g w00t
<Stskeeps> err.
<asac> fta: why is it a dep if its not needed during build. should at most be recommends
<fta> asac, because it's loaded dynamically and is not a build-dep, but i made chromium depends in either the free or non-free set of codecs
<fta> asac, depends vs recommends because upstream didn't want us to change the user experience, that whole free vs non-free is just to give users the choice
<asac> fta: we already change upstream experience by allowing free/non-free, right? i think that recommends should be similarly ok.
#ubuntu-arm 2009-12-06
<MarkGil> Hi, I due to Ubuntu dropping armV5 support, I was forced to move my Sheevaplug from Ubuntu to Debian, however I need to cross-compile for arm on my Ubuntu desktop machine, using emdebian, do I also need to switch my desktop PC's to Debian too, or is there a way to run emdebian on Ubuntu?
#ubuntu-arm 2010-12-06
<Crisco> hrw: are you there?
<dex`> â¦
<ranjith> hi all
<ranjith> any one know , how the gnome-rdp can be installed in the ubuntu-arm working or omap4-blaze .?
<hrw> ranjith: probably the same way as any other package
<ranjith> I ahve not yet installed any package in ubuntu-arm .. is it same as how we do in normal ubuntu ..?
<hrw> yes
<hrw> just other architecture
<ranjith> ok
<ranjith> so that means the installation will work with the apt-get install ..?
<ranjith> while doing sudo dd bs=4M if=ubuntu-netbook-10.10-preinstalled-netbook-armel+<omap image>.img of=/dev/<device name>  , will it create two parttions in the 4gb sdcard or three,
<ranjith> I had instaled the ubuntu-arm on omap4-blaze last day, but while trying to install it again, now its failing. its creating 3 parttions in my card and not booting ..
<hrw> I do not know - I do not use ubuntu images
<ranjith> hrw: is there any other way than using this image ..?
<belier> hi
<sveinse> Is there a mailing list similar to this channel?
<hrw> sveinse: ubuntu-devel is used now
<jacquesdupontd> hey guys anybody in U.S heard about a U.S missile launch those days?
<rsalveti> morning
<sveinse> morning
<sveinse> Is there a way to build apps with the cross compiler and make the linking against userspace target [dynamic] libraries?
<sveinse> I'm trying to build a Qt application, which I am able to fully build and link with a cross compiler. But as soon as I link against other libs which is installed on the target Ubuntu ARM, the linker gets confused
<sveinse> E.g 1) On target /usr/lib/libpthread.so is a linker script referring to "/lib/libpthread.so" which confuses the cross compiler, as this is then referring to the host lib
<sveinse> So I fixed that by modifying the scripts and the linker is partly happy. When I try to link against, say libpulse.so, it requires a lot of other libs, like libz.so, which the linker cannot find without explicitly naming -lz when linking
<sveinse> It gets me to wonder: How is it intended to use the cross compiler should be used and what option have i missed?
<sveinse> Is these problems at all familiar to anyone?
<sveinse> On target native building is really not an option for us, because it pratically renders the build servers useless...
<sveinse> One option could be to make a ARM rootfs with the -dev packages installed, and inject the cross-compiler into it and then use chroot.
<sveinse> But this seems like hairy methods to me
<rsalveti> and it's still slow, real cross should be the best option
<rsalveti> maybe hrw can help you better
<rsalveti> but I believe this will only be fixed with multiarch support
<hrw> sveinse: check for xdeb in wiki.linaro.org
 * hrw -> confcall
<janimo> rsalveti: hello
<rsalveti> janimo: hey
<janimo> rsalveti: was looking around what tasks to pick :)
<janimo> was looking into the haskell FTBFS's
<janimo> and to the linaro qemu thing
<sveinse> hrw: anything particular I'm looking for on the wiki?
<janimo> since my arm board arrives tomorrow, I think I'll try out the install in qemu first
<rsalveti> janimo: ok, should be ok with qemu
<hrw> https://wiki.linaro.org/UsingXdeb
<rsalveti> if you use the same qemu as linaro and the omap3 kernel
<janimo> rsalveti: yes, using qemu from linaro ppa, omap3 10.10 image
<janimo> and will look for a kernel image
<ogra_ac> bah
<ogra_ac> http://packages.debian.org/experimental/libreoffice
<ogra_ac> no armel builds
<janimo> ogra_ac: I'll look into OO as well
<ogra_ac> i guess you have to wait for the kdelibs stuff to be done
<janimo> s/OO/LibO/
<ogra_ac> it wont build otherwise
<janimo> sure
<ogra_ac> ah
<janimo> just when it is time
<janimo> so is the toolchain fix for Qt released then?
<ogra_ac> well, i'm not sure we will sync it into natty
<janimo> LibO ?
<ogra_ac> (libO i mean)
<janimo> hmm, past freeze or why?
<janimo> they have 3.3 RC1 out
<ogra_ac> the toolchain fix was actually there before A1 but nobody noticed (the changelog entry was a bit weird)
<janimo> and seem to be progressing nice, and the deb packager is up to date
<ogra_ac> well, i have no idea what the TB decided
<janimo> so QT stuff should just need a 'try rebuild' ?
<ogra_ac> so i dont know if we ship OO.o or libO
<janimo> ogra_ac: ah, was there a TB meeting regarding this
 * janimo missed it :(
<ogra_ac> no idea
<ogra_ac> but i would expect this to be a TB decision
<janimo> I hope we'll use LibO, much nicer upstream, much less work for ubuntu packager
<ogra_ac> yes
<ogra_ac> i was just writing some letters with zoho and its really unusable
<ogra_ac> that made me look at the debian libO stuff
<janimo> but isn;t current OO in natty working?
<ogra_ac> should work afaik
<janimo> LibO takes many hours to build on a decent x86 desktop
<ogra_ac> but my ac100 has only 4G free, i dont want to waste that space on an office suite
<janimo> I wonder how much it is on an arm borad
<ogra_ac> so i decided to use what we ship on arm
<ogra_ac> which is zoho
<ogra_ac> but that has multiple issues
<janimo> I did not know about zoho
<janimo> is that FOSS too?
<ogra_ac> its a web sevice
<ogra_ac> similar to google docs
<janimo> no deskto pcomponent at all?
<janimo> ok
<ogra_ac> there is mime integration and .desktop files we ship
<janimo> I knew about it but though maybe there some glue for the ubuntu desktoip (indicators whatnot)
<ogra_ac> JamieBennett did do that before he moved to linaro
<ogra_ac> nobody really improved it beyond that
<ogra_ac> but the issues i had were rather on the zoho side, not with our integration
<janimo> yes
<ogra_ac> main issue is that it hangs eternally once you try to use copy/paste
<ogra_ac> OO.o takes 36h to build on armel
<ogra_ac> i wouldnt expect libO to be much different
<ogra_ac> buut as soon as we switch to panda buildds that will change significantly
<ogra_ac> (should reduce the time to 1/2)
<sveinse> hrw: Can I build production apps with xdeb, or is it just for convenience (i.e. experimental) ?
<hrw> experimental rather
<hrw> ubuntu and crosscompilation does not match
<sveinse> so I've figured on my own..
<hrw> sveinse: never heard of that mistical 16core 5GHz arm cpus and mainboard which takes 8 of them + 128GB of 3333MHz ddr3 ram?
<hrw> I heard that ogra_ac uses such as desktop
<ogra_ac> ??
<hrw> </joke
<hrw> >
<ogra_ac> heh
<ogra_ac> i wouldnt mind to
<ogra_ac> would be wuieter than my laptop
<hrw> neither would I
<sveinse> hrw: I should propose this to the purchasing and the the IT dept... Guess they won't like :D
<ogra_ac> *quieter
<sveinse> Kind of ironic I would say. We have a large build server to our disposal in this project, but cannot use it properly to our benefit: cross-compile is dodgy, qemu is inefficient, running on target... :(
<janimo> hrw: is it only that ubuntu and xcompilation do not match or xdeb itself is not mature on any platform
<hrw> xdeb is not mature
<hrw> it is improving
<sveinse> Well on the flipside, my impression is that Ubuntu ARM is pretty stable, since it relies on only native compiling.
<sveinse> one of the reasons why we chose Ubuntu as system for our project (over OE)
<sveinse> Are there any risks in cross compiling an application and then exporting it to the target in relationship to which cross compiler is used?  E.g. when the app dynamically relies on libc, I cannot choose cross compiler (CodeSourcery vs. armel-cross) freely since these are build against specific libc libs, right?
<sveinse> (when running Ubuntu ARM on target, using libc installed from ubuntu)
<hrw> ubuntu 10.10 provides armel cross compiler
<hrw> but is has a bug 684625 which I have a fix for so matter of 2 weeks?
<ubot2> Launchpad bug 684625 in gcc-4.5 (Ubuntu) (and 2 other projects) "libc6 is compiled for armv5 instead of armv7a (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/684625
<davidm> ndec, holding on the phone
<ndec> davidm: sorry. i am a bit late. i am coming
<davidm> ndec, NP
<davidm> ndec, was worried I had messed up the time somehow
 * rsalveti lunch
<dmart> ogra_ac: hey there
<dmart> Trying to understand the initramfs thing ... where does run-init come from?  The only source I know of is klibc
<dmart> npitre: ah, the other guys here thought you do
<dmart> (wrong channel)
<dcordes> dmart: what is it you don't understand ?
<dmart> dcordes: I don't understand ogra's statement about run-init being linked against glibc ... if run-init is build from the klibc package ...?
<dmart>  /win 5
<GrueMaster> rsalveti: Did you know that Friday's (Alpha 1) image doesn't have networking?
<rsalveti> GrueMaster: I only saw that the nm-applet icon wasn't there
<rsalveti> that's kind of ok for alpha, you still can fire dhcp by hand if you need/want
<rsalveti> but would be good to reproduce the issue, fire a bug and debug
<rsalveti> seems that the gnome-panel is not that stable either
<rsalveti> some times I get seg fault while loading it
<rsalveti> just need to find time to debug and report these issues
<GrueMaster> Not a big deal for A1, but this kind of stuff needs to be listed in the release notes.  This is one of the reasons why I hate last minute respins.
<rsalveti> sure, but we did the respin because otherwise we would basically miss it
<GrueMaster> Friday was supposed to be dedicated to blueprint work.  Instead I had to pack up a panda & monitor to take downtown to the PDX meeting so I could try to figure this out.
<GrueMaster> I understand the reasoning behind the respin.  Never said I had to like it.  :P
<GrueMaster> But so far, I have had little time for blueprint work, due to respin testing, -proposed testing, and other interrupts.
 * GrueMaster wonders if someone added an automated test somewhere to test his sanity.
<rsalveti> yeah, I also got quite busy with stuff I wasn't planning for
<rsalveti> GrueMaster: if you find time, check if today's image also have this issue
<GrueMaster> I already pulled it.  Will look at in a little bit. (part of my morning routine).
<rsalveti> ok, let me know if you're still facing these issues, will try to debug later then
<tmzt> ogra_ac: abiword doesn't work for you? ac100 is going well then?
<Neko> ogra, ogra_ac about usb-imagewriter or so, is there a good reason why it can't use compressed images and decompress them?
<GrueMaster> Neko: You can file a wishlist bug for it.  The images it was originally designed for are x86 .iso type images though.  It really doesn't do a raw-write as needed by our preinstalled images.
<Neko> not Startup Disk Creator
<Neko> usb-imagewriter
<Neko> https://bugs.launchpad.net/ubuntu/+source/usb-imagewriter
<GrueMaster> I don't think it has been worked on in over a year, since usb-imagecreator became the default for Ubuntu.
<GrueMaster> And ogra is out until the end of the year (may make an appearance now and again, but doubtful).
<Neko> usb-imagecreator doesn't work for arm netbook images which are still shipped as .img
<Neko> I can't believe Ubuntu armel is still a second-rate distribution after Mark waved an AC100 round and said "this is the future!!"
<Neko> is he being overridden by committee or something who only care about amd64?
<rsalveti> well, as mark said, that's the future
<rsalveti> not now hehe
<rsalveti> but the idea is to get closer and closer with other archs
<Neko> startup disk creator only writes to partitions not to disks
<Neko> it's really clumsy :(
<GrueMaster> Like I said, it was designed for .iso images to be written to USB.
<Neko> I guess it's time to write a new tool for it
<Neko> sounds like a fun project for me :D
<Neko> BTW does Ubuntu hold the same "ARGH IT HAS TO BE GPL!!!!!" policy of Debian?
<armin76> lol
<Neko> okay let me rephrase that in a less funny way
<Neko> does Ubuntu hold the same "ARGH IT HAS TO BE GPL!!!!" policy as Debian, or comparitively the "OMG IF IT'S NOT BSD WE SHOULD REWRITE IT" of Open/FreeBSD for example?
<Neko> because to be honest the BSD tools are much better than the GNU ones.. BSD tar is awesome for example, since it uses libarchive
<GrueMaster> Neko: Why not pull a branch of usb-imagecreator and enhance it?
<Neko> I'm apt-get sourcing it now :D
<Neko> I just figured maybe it would be a cute idea to use the bsdtar and bsdcpio by default and make tar and cpio wrappers around it to mess with what the GNU differences are
<Neko> they can be faked..
<Neko> it reduces the footprint by a little bit, compression is automatically detected and extensible, it really is wicked
<GrueMaster> rsalveti: Something changed recently in natty as to networking.  I tried re-adding "auto usb0 ; iface usb0 inet dhcp" to /etc/network/interfaces and it works again.
<GrueMaster> I don't have manifests for the images prior to A1 though.
<rsalveti> GrueMaster: ok, but that should work, are you able to see the nm-applet now?
<GrueMaster> After adding the above two lines, yes.
<GrueMaster> And it connects.
<rsalveti> hm, weird
<GrueMaster> Although the nm applet icon appears to be a disconnected wifi icon.
<GrueMaster> Should be two arrows (up & down) for ethernet.
<rsalveti> iface usb0 inet dhcp probably says to nm to avoid managing it
<GrueMaster> hmm/
<GrueMaster> Will try w/o.
<rsalveti> on maverick we don't need to put these lines and it works ok, as expected
<GrueMaster> we used to.
<rsalveti> need to check the nm log to understand why it's not calling dhcp at the interface
<rsalveti> GrueMaster: check /var/log/daemon.log
<GrueMaster> I wrote a script to fix images prior to them working properly in mav.
<GrueMaster> ok.  rebooting, so one sec.
<GrueMaster> hmm.  Dropping "iface usb0 inet dhcp" fails.  No nm applet.
<rsalveti> so it's probably failing to manage the usb0 interface
<rsalveti> can you paste me the logs, since the boot?
<GrueMaster> Erm, give me a sec.  No network, no pastebinit.
<rsalveti> GrueMaster: give dhclient usb0 at serial
<GrueMaster> You assume I am using a serial console.
<GrueMaster> I'm getting it online.  Just need to install pastebinit.
<GrueMaster> Grrr.  universe is still not activated in the image.
<GrueMaster> rsalveti: http://paste.ubuntu.com/540406
<rsalveti> GrueMaster: this is with or without the modification you made?
<GrueMaster> Should have both.  I don't think the file changes between reboots.
<GrueMaster> My changes would be lower down the line.
<rsalveti> GrueMaster: Dec  6 02:44:58 sycamore init: network-manager main process (623) killed by SEGV signal
<rsalveti> not good
<rsalveti> first error
<rsalveti> nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with error status 1
<GrueMaster> Yea, I'm seeing that a lot as I scroll down.
<rsalveti> first thing would be to check why this script is returning error
<rsalveti> when you added your lines, nm probably decided not to manage the interface, and then it didn't get the segv
<rsalveti> nm is probably calling this script with usb0
<rsalveti> Ifupdown: get unmanaged devices count: 1
<rsalveti> here's where nm decided not to manage the usb0 interface
<rsalveti> GrueMaster: so our problem now is why nm is getting segv when trying to init the usb0 interface
<rsalveti> could be because it doesn't expect the script to return an error
<GrueMaster> I'm comparing with my other panda running maverick.
 * rsalveti is updating his natty image
<GrueMaster> I tried the script manually with all 4 cases it uses and haven't seen an error.
<GrueMaster> Will reboot w/o auto usb0 settings.
<GrueMaster> If I didn't know any better, I would think that it is going ipv6 only.
<rsalveti> will try to reproduce it here when it finishes the update
<rsalveti> argh, sd card is too slow
<sveinse> rsalveti: BTW: I noticed that there are huge difference between sd cards, even within the same class rating, because their latencies varies a lot.
<sveinse> It's a challenge for us when we are sourcing sd cards because we need the right one, but its selection parameters is not listed in the card's specs
<sveinse> I went to my local gadget store and bought a new SD card, and it was totally useless. It's read and write speeds were allright, even better than my old card, (I did verify) but the latencies are 5-7 times slower than my old.
<sveinse> Ubuntu was going from useful to useless
<rsalveti> sveinse: yeah, true, problem is that I cannot find many different sd cards around
<rsalveti> mostly they are from kingston
<rsalveti> that's why I have 2 usb disks around, currently running with maverick
<rsalveti> a *lot* faster
<sveinse> yes, the slow card was in fact a kingston. The old was a sandisk. I even tried a transcend bundled with my HTC. It's faster! (despite being a low-price card)
<rsalveti> cool, nice to know
<sveinse> Are you modifying the CHS layout of the card?
<sveinse> Some have proposed that doing so can really confuse the build in flash translation layer (FTL) since it needs to wrap 512b sectors into x kb flash sectors. Changing the CHS layout would probably make the sector requests out of order and thus creating a *huge* amout of erase cycles
<rsalveti> interesting, never heard about that
<sveinse> I havent confirmed if its really like this yet, though. In light of our commercial sourcing, I think I will ask specifically to the selected vendor about it to confirm/deny it.
<rsalveti> ok
<hrw> sveinse: kingston just brands cards - atleast it was that way some time ago
<sveinse> hrw: I think so too. And I also believe the card available at your local computer store are mostly low-price and low on performance.
<hrw> I run ubuntu on sata disk connected though usb
<sveinse> I also did that, but the USB stack died a couple of times and killed the FS :(
<hrw> but usb on pandaboard is not as fast as I woule too
<sveinse> I experience NFS being more stable, albeit slower
<hrw> depends - on some devices it is faster then local storage
<sveinse> hrw: I trust I can rely on that the host's libstdc++6-armel-cross and libc6-armel-cross are in sync/ABI compatible with the native armel counterparts?
<hrw> yes
<hrw> sveinse: same sources, same configs, same compile flags
<sveinse> excellent
<hrw> sveinse: but current one are broken
<sveinse> hrw: In what way? Do you have a reference to bug or similar?
<hrw> normal are armv7, cross are armv5
<hrw> bug 684625
<ubot2> Launchpad bug 684625 in gcc-4.5 (Ubuntu) (and 2 other projects) "libc6 is compiled for armv5 instead of armv7a (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/684625
<GrueMaster> rsalveti: I wonder if NetworkManager is having issues with the non-existent mac address that was fixed in 2.6.35-903.19?
<rsalveti> GrueMaster: don't know, what was fixed is the normal support of setting up the mac address
<rsalveti> but getting a segv is not that cool
<sveinse> hrw: Does this affect the cross compiled apps in any way? I manually specify -march & friends, and I only rely on dynamic libc/libstc++
<rsalveti> still waiting the update =\
<hrw> sveinse: should not for shared
<sveinse> hrw: In regards of bug #683832, Does this mean that Qt uses some inline asm that triggers the failure?
<ubot2> Launchpad bug 683832 in gcc-4.5-armel-cross (Ubuntu) (and 1 other project) "gcc fails to cross compile Qt (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/683832
<hrw> yes
<GrueMaster> rsalveti: I'm manually updating to 2.6.35-903.19 to see if the mac address fix helps.
 * hrw -> away
<rsalveti> GrueMaster: ok
<GrueMaster> Would be nice if kernel/sru teams would get it released already.  I spent part of my holiday testing that.
<rsalveti> the sru released for kernel takes quite a while, I noticed
<rsalveti> *releases
<GrueMaster> Only when it doesn't apply to security patches.  I went around this cycle several times during Lucid with network patches for both dove & babbage.
<rsalveti> GrueMaster: how can someone using an sd card update from one release to the other? it'll take hours!
<rsalveti> a lot easier to backup and grab a new preinstalled image hehe
<GrueMaster> ~7 releases later, it was finally released into main.
<rsalveti> ouch
<GrueMaster> I find using a local mirror helps immensely.
<rsalveti> sure, but the main problem is not getting the packages, but installing them
<rsalveti> dpkg uses the disk a lot, and that is really slow
<GrueMaster> Gah!  Got distracted during reboot.  HDMI switch moved to a different system, then this system came up with garbled display.
<GrueMaster> True.
<GrueMaster> But since these systems are mainly for development, it is easier to nuke & pave.
<rsalveti> yeah
<GrueMaster> Interesting.  Something in the panel (maybe the panel itself) is in a respawn loop.
<rsalveti> GrueMaster: yeah, with segv
<rsalveti> another weird segv issue
<rsalveti> doesn't happen all the time
<rsalveti> ok, finished the update, time to reboot
<GrueMaster> Hmm.  Kernel -19 has no effect.  Still get the error about permanent mac in the log and the SEGV.
<rsalveti> ok, good to confirm
<GrueMaster> Wow, this is new (for me).  I sometimes lose video in X.  Have to switch to text console & back.
<GrueMaster> never saw that before.
<rsalveti> GrueMaster: underflow?
<rsalveti> GrueMaster: check dmesg
<GrueMaster> Yep.  GFX_FIFO_UNDERFLOW
<rsalveti> GrueMaster: known issue
<GrueMaster> Yea, I had heard about it.  Just never saw it before now.
<rsalveti> http://people.canonical.com/~rsalveti/maverick/kernel/es2/linux-image-2.6.35-903-omap4_2.6.35-903.18rsalveti2_armel.deb this kernel brings the changes needed to improve it
<GrueMaster> Is it more pronounced on ES2.0?  That's what I'm currently testing on.
<rsalveti> but as the commits are not in the best shape, and it's just a workaround, we didn't move it further
<rsalveti> GrueMaster: yeah, probably because of a slower mem
<GrueMaster> ah.  figures.
<GrueMaster> Hey.  We have sunshine.  Haven't seen that much all year.
<GrueMaster> Kind of cool.
<rsalveti> :-)
<GrueMaster> Well, it is 1pm.  Need food.
<GrueMaster> brb
<ogra_ac> hmm, dmart is gone
<ogra_ac> Neko, usb-imagewriter needs porting to udisks first, i dont mind to add a line that calls zcat instead of dd if it finds a img.gz suffix indeed
<Neko> zcat can write to a block file?
<ogra_ac> see our installation instructions
<Neko> I gotta get into GTK anyway
<Neko> we need to write some tools to properly control power management and all kinds on the Smartbook anyway
<Neko> turning off wireless/bluetooth etc. individually etc.
<Neko> seems there is no clever way to do that in GNOME or anything
<Neko> also to control HDMI and audio on the Nettop
<ogra_ac> there is no difference in "gunzip file.img | dd of=/device/foo" or zcat file.img >/device/foo
<ogra_ac> ugh
<ogra_ac> why would you write extra tools for any of that ?
<Neko> ugh?
<ogra_ac> just fix integration with the existing tools
<Neko> well not so much write extra tools as extra panels in the existing tools :D
<Neko> as it stands though there is no existing tool for configuring HDMI settings
<ogra_ac> well, for gnome-power.manager you just need to make the kernel DTRT
<Neko> DTRT?
<Neko> oh that
<ogra_ac> yeah, for HDMI you should add something to the display settings
<Neko> well sure there is a sysfs interface
<Neko> or will be
<ogra_ac> but it should be generic enough that other machines with HDMI can use it
<Neko> yeah most of it is setting values that go into the AVI Infoframe and to select HDMI audio source (I2S or SPDIF)
<ogra_ac> after all its just UI work and making sure your kernel sticks to existing standards
<Neko> right now we're rewriting battery and display drivers though
<ogra_ac> HDMI audio is trivially done by a pulse profile (as long as your ASoC devide works right)
<Neko> but you can run both
<ogra_ac> *device
<ogra_ac> sure you can run both
<Neko> the idea is the hdmi chip is connected to both audio outputs. if you sink i2s to hdmi it converts it to hdmi. if you sink spdif to hdmi it spools it over hdmi
<ogra_ac> as long as alsa exposes them right to pulse
<Neko> but pulseaudio doesn't have any idea on how to switch between them, there is no way to add a setting users can poke
<Neko> it just makes sure it can use each device
<ogra_ac> sure
<ogra_ac> we use that on the pandaboard
<Neko> there just needs to be a switch somewhere to tell the chip which bus it's gotta move audio from
<ogra_ac> right, thats a matter of the driver
<Neko> we're taking the hint from the omap driver to add blocking notifier chains so they can all cooperate
<ogra_ac> just expose all controls in alsa and have a switch inside the driver
<ogra_ac> yeah, thats what omap does
<Neko> ehhh you can't have alsa controlling the hdmi audio switch it's freakish
<ogra_ac> works fine on panda
<Neko> we'd have to hack the ASoc and SPDIF drivers to talk directly to the SII9022
<ogra_ac> right
<ogra_ac> thats where that hack should happen
<Neko> well that's dumb it would not work on babbage
<Neko> or any other board on MX51
<ogra_ac> why would you lift it up to userspace and add latency
<Neko> or MX53.. it's board specific
<ogra_ac> bad
<ogra_ac> but well
<Neko> latency?
<Neko> what are you talking about
<ogra_ac> make the kernel expose the right things and the userspace will behave right
<Neko> you write a value to a sysfs file
<Neko> it changes whether i2s or spdif is going over hdmi
<ogra_ac> its all already there
<Neko> if it takes 5us or 5 seconds who cares
<ogra_ac> but why dont you do it like everyone else and expose the switch in the asoc driver ?
<Neko> this isn't about somehow sending audio it's just a i2c register write
<Neko> sigh
<ogra_ac> whs does it need to be an additional sysfs control instead
<Neko> show me where it bloody does this in another driver then
<ogra_ac> where all userspace tools can already handle it right
<ogra_ac> look at the omap4 asoc driver in the omap4 kernel tree of ubuntu
<Neko> url
<ogra_ac> (and probably talk to liam)
<ogra_ac> (ASoC upstream)
<Neko> we're not upstreaming shit. this is a hack so we can get it working.
<ogra_ac> also known as lrg in here ;)
<ogra_ac> well, if you dont want help, dont ask him then ;)
<ogra_ac> up to you
<Neko> maybe in 6 months we'll look for a fancy way of pushing it upstream but there's a good chance none of the drivers we're messing with now are even going into mainline, and the ones that are in mainline are broken as hell anyway
<ogra_ac> if you do a hack you will likely have to add more hacks to other areas (UI, userspace etc)
<Neko> it's a waste of time thinking about it
<ogra_ac> why ?
<ogra_ac> just do it right and port that stuff forward later
<Neko> because mainlining patches to one fucked up BSP driver and one broken mainline driver for this feature is a waste of time
<Neko> we're not thinking of mainline right now
<ogra_ac> i'm not talking about mainline
<Neko> upstream, mainline, whatever, it's the same thing
<Neko> rivers, trains..
<ogra_ac> i'm just pointing you to the guy who knows most about SoC audio and can help you
<ogra_ac> anyway, i'm on vacation ...
<ogra_ac> just took a quick look at mails
<Neko> eh there is no omap4 soc driver in the kernel tree for ubuntu
<ogra_ac> feel free to send a patch for usb-imagewriter, I'll happily apply it if its sane
<Neko> omap-hdmi maybe?
<ogra_ac> must be somewhere on the kernel teams git server
<Neko> okay I see it, and you're talking crack. this is a specific driver to push audio over that bus. we don't need that
<Neko> some other driver pushes audio on the bus
<Neko> this is just a switch so we can tell the sii9022 which bus it is meant to be looking at
<Neko> technically it'd be part of the framebuffer driver but we need the mxc_spdif and imx-ssi-3stack-sgtl5000 to report to it what the current audio playback settings are too,which is what the notifier is for.
<Neko> not framebuffer.. sii9022 i2c driver thingy. man this is too complicated. linux is so stuck in the early 90's :(
<Neko> anyway I figured it, coding it now
#ubuntu-arm 2010-12-07
<Sp0tter> does ubuntu support the Archos 32 hardware?
<tmzt> what is the archos 32 hardware?
<rcn-ee> ubuntu supports the cortex a8 'architecture' of the archoes 32, you'll have to either find someone who did the kernel, or do it yourself..
<ScottK-droid> ogra_ac: Qt finally built so FTBFS should start improving.
<tmzt> Neko: you should be able to add a dapm without a pcm then if it's just routing
<tmzt> nice if linux had a framework for this
<prpplague> ogra_ac: greetings
<rsalveti> GrueMaster: found the nm fix
<rsalveti> ScottK-droid: cool, nice to know
<GrueMaster> rsalveti: What was it?
<rsalveti> GrueMaster: lack of a proper variable type: http://paste.ubuntu.com/540509/
<rsalveti> fix is already upstream, will now open the bug following the debdiff with the fix
<rsalveti> will also post a new deb, so you can also test
<rsalveti> the backtrace was really really weird
<rsalveti> inside glib, then a segv in strchr
<GrueMaster> Wheee.
<rsalveti> all of that because on arm the time type is 32
<GrueMaster> heh
<GrueMaster> Gotta love non-portable typesets
<rsalveti> yeah
<rsalveti> argh, takes quite a while to install everything I need to build and then build
<rsalveti> GrueMaster: http://people.canonical.com/~rsalveti/686320/
<rsalveti> GrueMaster: please confirm the bug and test the fix later, then I can ask people to push the fix tomorrow
<GrueMaster> rsalveti: I'm shut down for the moment.  Will test first thing in the morning.
<rsalveti> GrueMaster: sure, np, also going off now
<rsalveti> see ya
<armin76> http://www.linuxfordevices.com/c/a/News/ZT-Systems-R1801e-/
<ogra_ac> dmart, hey
<ogra_ac> dmart, did my comment on the bug make the issue a bit clearer ?
<dmart> ogra_ac: hi - has that bug definitely been isolated to busybox, and do we know where/what it is ... or is that still unknown?
<ogra_ac> dmart, NCommander traced the issue down to exec so its definitely busybox, also the fact that dropping -marm fixes it while neither klibc nor initamfs-tools changed between maverick and natty (not even a rebuild) somehow points to busysbox
<ogra_ac> or rather the toolchain
<dmart> ogra_ac: do you know what is being exec'd and from where?
<ogra_ac> dmart, run-init is from /init
<ogra_ac> run-init exposes the same error with a random error # if you dont run it from pid 1 btw
<dmart> ogra_ac: You mean, the shell barfs on the "exec run-init" line in /init?
<ogra_ac> either run-init does because the environment changed
<ogra_ac> i.e. it might be that the PID doesnt get carried over properly
<ogra_ac> its massively hard to debug, it would be better to compare exec from busybox-initramfs with and without -marm outside of an initrd
<ogra_ac> s/either/rather/
<dmart> ogra_ac: ok ... bit of a mystery.  I don't see any asm in busybox, so to me that suggests a compiler bug or a bug in run-init
<ogra_ac> cant be in run-init
<dmart> Oh yeah, you don't rebuild that
<ogra_ac> natty and maverick initrd's are the same apart from busybox and the toolchain
<ogra_ac> everything else involved is 100% identical
<dmart> right...
<ogra_ac> thats why the bug is open for gcc
<ogra_ac> but as i said above, its very very hard to debug
<ogra_ac> since the only debugging you could do would be to change /init
<ogra_ac> but with every binary you inject in the exec call the PID will change from 1
<ogra_ac> which will expose the error in any case
<dmart> ogra_ac: gdb --attach ?
<NCommander> dmart: bit of a problem because the debugging tools stop spitting output when the kernel panic(0s
<NCommander> and my understanding is that since all processes are interconnected, when pid 1 goes, EVERYTHING goes
<ogra_ac> ah, NCommander is here, I'll hand that over then and do other vacation stuff ;)
 * NCommander goes poof
 * ogra_ac isnt offifically here until end of year 
 * NCommander just saw the hilight since I was talking to a friend on another channel
 * NCommander isn't here either
<ogra_ac> NCommander, but you will at least be in a few hours ;)
<dmart> NCommander: the kernel panics if PID 1 dies ... possibly we could hack the kernel not to do this
<dmart> Though there might be odd knock-on effects.
 * ogra_ac just tries to find out when we switched to i686 by default
<NCommander> dmart: I don't think you can, everything is a child process of PID 1
<dmart> parent process death isn't generally fatal
<NCommander> you might be able to debug from the kernel debugger, but then you run into nasty VM issues
<dmart> but you will need to suppress or ignore the SIGHUPs that the child processes would get
<dmart> None of this is easy though :/
<NCommander> dmart: according to ogra, run-init is dependent on being PID 1
<NCommander> ideally, the easiest way to debug is to remove that requirement
<dmart> Might not work though ... being PID 1 is genuinely different in some ways from being any other PID, mostly to do with signal behaviour IIUC
<ogra_ac> NCommander, not *being* only *being run by*
<NCommander> Maybe use Userspace Linux, or something like that?
<NCommander> ther ehas to be way to have a pseudo-PID 1, else Keybuk would have probably gone mad trying to debug upstart
<dmart> run-init is exec'd, so it will be PID 1 also...  and run-init execs upstart, so that will be PID 1 too
<ogra_ac> right
<dmart> Yeah, I guess he may have some good ideas...
<dmart> ogra_ac, NCommander: here's an approach which seems to work for debugging init:
<dmart> ogra_ac, NCommander: http://pastebin.ubuntu.com/540609/
<dmart> I don't have the right filesystem in front of me though
<ScottK> NCommander: You assume he didn't.
<ScottK> NCommander: Anything you changed for Alpha 1 due to Qt being dead you ought to be able to put back now.
<dmart> ogra_ac: ^ did you spot that link?  Should I post it somewhere else?
<ogra_ac> probably dump it in the bug
<dmart> ogra_ac: oh, much scrolling ... well, here it is again, just in case:
<dmart> ogra_ac:  http://pastebin.ubuntu.com/540609/
<dmart> ok
<ogra_ac> i mean the url :)
<ogra_ac> dont expect me to work on it, i'm on vacation ;)
<ogra_ac> NCommander, janimo or rsalveti have to help out, though in the end its likely to be a toolchain issue so i bet it will have to move over to linaro in the end
<rsalveti> afaik NCommander is still looking at this bug
<ogra_ac> right, but i suspect it to boild down to toolchain anyway
<ogra_ac> which puts it into linaros realm
<rsalveti> yeah
<dmart> I'm curious to find out what the actual bug is ...
<ogra_ac> gcc 4.5 :P
<dmart> but I don't want to deprive other people of the fun of tracking it down :P
<GrueMaster> Guys, NCommander is on vacation as well.  He won't be back until next week.
<ogra_ac> GrueMaster, not according to the team calendar
<rsalveti> yeah
<GrueMaster> Just because he's an idiot and forgot to update the calendar, doesn't mean he is here.  Since he lives with me, I would know.
<GrueMaster> about both.
<rsalveti> hehe
<rsalveti> GrueMaster: any chance to test the nm fix?
<GrueMaster> on the phone brb.
<rsalveti> k
<hrw> have a nice rest of day
<Sp0tter> does anyone know of ubuntu supports the hardware on the Archos 32 tablet?
<GrueMaster> rsalveti: Finally able to work again.  I downloaded, installed, and rebooted with your network manager.  system works again.  Good find.
<rsalveti> GrueMaster: nice, please post your results at the bug and let's try to find someone to sponsor the fix :-)
<GrueMaster> Yep.
<GrueMaster> You should see a flood of emails from LP.  I changed status to "In Progress, High priority, Natty-Alpha-2".
<rsalveti> GrueMaster: ouch hehe :-) but thanks
<GrueMaster> Just filling out the info for the release team.  Making the bug more complete.
<rsalveti> yeah, nice
<GrueMaster> Back to working on paperwork.
<rsalveti> I'm impressed by the time it takes to get a kernel fix released into main
<rsalveti> just got two notifications for testing the kernel released at proposed, and the bug was opened almost 1 month ago, with the fix included at the same day
<GrueMaster> And it is already in proposed and tested by me two weeks ago.
<rsalveti> yeah
<GrueMaster> I've already raised the question on #u-kernel.
<apachelogger> aloha
<apachelogger> any clues where one would get powervr graphics drivers for omap3?
<rsalveti> apachelogger: https://wiki.ubuntu.com/ARM/OMAP/Graphics
<rsalveti> not the best one, and without a proper x11 driver, but it's there already
<rsalveti> for omap4 the pvr stack is better, and also available from a ppa
<apachelogger> uh
<apachelogger> rsalveti: thanks :)
<rbelem> fala rsalveti
<rsalveti> rbelem: hey
<rbelem> rsalveti, is qt compiled with gl es support?
<rsalveti> rbelem: not yet :-)
<rbelem> for arm?
<rbelem> apachelogger, ^
<rsalveti> it'll be soon
<rsalveti> now that we got qt building fine again
 * apachelogger has a change for that in pipeline
<apachelogger> rbelem: http://people.ubuntu.com/~apachelogger/mobile/qt.tar.gz
<apachelogger> binaries for testing
<rbelem> rsalveti, what is going on about the qt neon discussion?
<rsalveti> rbelem: still missing someone to sit and do the final work :-)
<rsalveti> for maverick it'll be a little bit harder, as need proper backport
<rbelem> :-)
<rsalveti> problem is that qt takes too much time to build
<rsalveti> any simple test turns out in days
<rbelem> rsalveti,  and that gcc patch?
<rbelem> rsalveti, does the arm toolchain works fine with icecc?
<rbelem> that could speed up the builds
<rbelem> apachelogger, hum... with gles and neon?
<rsalveti> rbelem: https://launchpad.net/ubuntu/+source/qt4-x11/4:4.7.1-0ubuntu4/+build/2052893
<apachelogger> rbelem: if maverick did not yet get changed to build without neon...
<apachelogger> it is based on the most recent maverick package
<rsalveti> rbelem: did finish fine this time
<rbelem> cool :-)
<rsalveti> rbelem: yeah, but I don't have lots of boards around to let them just building qt atm
<apachelogger> rbelem: see my blog post on icecc & arm :P
<apachelogger> qt builds in about 12 hours
<rsalveti> yeah, half the time
<apachelogger> if you did nt screw up and the build fails 3 times ^^
<rbelem> apachelogger, wow :-(
 * apachelogger notes that even on his laptop it took quite a while with -j10
<rbelem> at work i usually use -j20 :-)
<rsalveti> and the webkit linking part needs a lot of memory
<rsalveti> and also takes quite a while
<rbelem> rsalveti, xdeb works to build qt?
<rsalveti> didn't try, but saw someone posting a but while cross building qt days ago
<rsalveti> *bug
<rbelem> :-/
 * rsalveti brb, need to eat something
<rbelem> :-)
<apachelogger> rsalveti: well, 4.8 doesnt have webkit anymore
<apachelogger> also I think we only need to do that stupid linking because Qt's help browser implicitly depends on its rendering in 4.7
<Sp0tter> anyone have an Archos 32?
<Sp0tter> been trying to find if Ubuntu will run on it
<Sp0tter> it's omap
#ubuntu-arm 2010-12-08
<rcn-ee> Sp0tter, it'll run ubuntu's userspace, you'll have to figure out the kernel stuff yourself..
<Sp0tter> hmm
<Sp0tter> drats i was hoping to just benifit from someone elses previous hard work :)
<Sp0tter> archos 32 is too new and not popular enough yet though to have much of a following, so maybe i'll look into it
<rcn-ee> Sp0tter, it might be as easy as copying their kernel and modules into an ubuntu rootfs..
<Sp0tter> define "their"
<Sp0tter> it runs android
<apachelogger> rsalveti: so I installed the omap3 graphics foo and now the demo apps fall over http://paste.ubuntu.com/541043/ any clues
<apachelogger> (Qt also fails to find a EGL display for that matter)
<apachelogger> oh ah eh
<apachelogger> rsalveti: apparentlyt eh init script failed because we are currently running the n900 with the meego kernel
<apachelogger> commented out the ti_something modprobe, and the script worked *but* now it segfaults ^^
 * apachelogger thinks that meego kernel and ubuntu sgx stuff does not go well together
<rsalveti> apachelogger: one thing is to make sure your user is also at the video group
<rsalveti> apachelogger: and yes, I don't think maemo's kernel will work nicely with these libraries
<rsalveti> if you're using it at the n900 you should just grab the meego's sgx libraries
<rsalveti> they are also available at meego's repository, just need to convert into deb packages
<rsalveti> GrueMaster: why did you create bug 687396? isn't it easier to just change bug 673509 saying that also affects the linaro's kernel?
<ubot2> Launchpad bug 687396 in linux-linaro (Ubuntu) "Beagleboard-XM chooses a new IP address everytime the interface is brought up (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/687396
<ubot2> Launchpad bug 673509 in linux (Ubuntu Maverick) (and 1 other project) "Beagleboard-xm chooses a new IP address on each boot (affects: 1) (heat: 12)" [Undecided,Fix committed] https://launchpad.net/bugs/673509
<GrueMaster> rsalveti: Given the current issues with the kernel team...no.
<GrueMaster> The issue is that they rely on a verification- tag, which encompasses the bug, not the package.
<rsalveti> GrueMaster: argh, true
<rsalveti> that was the reason for quite a lot of confusion lately
<GrueMaster> This is also partly why the go around for the panda fix.  The patch listed both bug reports in the commit, so both bug reports get updated when only one kernel gets patched.
<rsalveti> GrueMaster: yeah, true
<GrueMaster> There are several flaws in the current system.  I think I found 5-6 bugs tagged with verification-needed for kernel updates that I was never informed of.  Mainly for babbage & dove.
<rsalveti> janimo: so, it seems that the meego tree is our only choice for the natty cycle
<janimo> rsalveti: yes
<rsalveti> I know linaro's testing the omap 3 kernel on it, but it'd be good to make sure it works fine with our tools
<rsalveti> such as rootstock
<rsalveti> just got another answer from peter saying that the omap 3 patches are on top of the priority list
<rsalveti> and giving the qemu release cycle, those patches are probably going to end upstream luckly for n+1
<rsalveti> and the worst case for n+2
<janimo> rsalveti: right, so for natty we package maemo stuff. I wonder if we need a new source package or is it reasonable easy to patch existing qemu
<janimo> I haven;t looked yet at qemu packaging internals
<rsalveti> janimo: we discussed that at uds, and it seems that it's easier just to create a different package for arm
<janimo> rsalveti: but we need an OMAP3 compatible QEMU soon right?
<rsalveti> because otherwise the server team is going to maintain all these patches in the package itself
<janimo> notjust by release
<rsalveti> janimo: we need a working qemu, omap 3 is just the most used atm
<rsalveti> there is another blueprint from the server side, let me find it
<janimo> rsalveti: shall I take this spec over or do you prefer working on it?
 * janimo reads the new emails
<rsalveti> janimo: https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
<janimo> rsalveti: still maemo-qemu is a bit of a misnomer at this time
<rsalveti> janimo: it'd be good to get the patch set, see how many they are and ask the server team what they think about it
<rsalveti> we're ok for uploading a different package for arm
<rsalveti> but if they prefer to apply and maintain all those patches, we're also fine
<janimo> rsalveti: ok, I'll read this spec
<janimo> so we'd only pick omap3 subset of the maemo tree?
<rsalveti> janimo: I'm ok for you taking up this spec, just ping me before closing the WI so I can see the progress :-)
<janimo> rsalveti: ok :)
<rsalveti> janimo: probably, and also the arm fixes that could be also not yet integrated
<rsalveti> janimo: so please add also new WI
<janimo> rsalveti: not sure what else is in the maemo tree besides those, I need to check
<janimo> to see what we do not carry over
<janimo> probably nokia device specifics
<rsalveti> - get the patch list of the differences from the upstream tree
<rsalveti> - talk with the server team to see what they think about maintaining the patches or simply pushing a new qemu-maemo package at the archive
<rsalveti> janimo: yup
<rsalveti> janimo: - test current linaro's omap 3 kernel with qemu and report back to the server team if it's enough for us, so they can drop versatile
<rsalveti>  janimo https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
<janimo> should I add the last WI to this spec or to our spec?
<rsalveti> after changing our tools to use it, test to see if we get at least the same behavior of the main qemu-kvm package
<rsalveti> janimo: to our
<janimo> ok
<rsalveti> janimo: I'm just pointing this spec, as it's the one that they put a WI to see if they should drop versatile or not
<rsalveti> depending on our feedback
<janimo> so if omap3 works they drop versatile patches from qemu?
<rsalveti> janimo: they drop the versatile build from the ubuntu kernel
<rsalveti> at maverick, for example, the versatile build only exists because of the need from qemu
<rsalveti> as it's the only working target for arm
<janimo> rsalveti: I see
<rsalveti> as we already need an omap 3 build (now maintained by linaro), if we can get qemu working with it there's no need to keep versatile
<suihkulokki> well, there was discussion to make versatile the "virtualized" arm/qemu flavour
<suihkulokki> eg to get virtio and goodies
<rsalveti> yeah, but don't know much about the current state of it
<rsalveti> what we know is that we have already quite a lot of people using and testing the maemo tree nowadays
<rsalveti> and because of that it'd probably be the better choice for us
<prpplague> rsalveti: whats the git url for the ubuntu x-loader and u-boot?
<rsalveti> prpplague: http://gitorious.org/~rsalveti/pandaboard/rsalveti-x-loader/commits/omap4_panda_es2.1
<rsalveti> for x-loader
<rsalveti> prpplague: http://git.linaro.org/gitweb?p=ubuntu/u-boot-linaro-stable.git;a=summary
<rsalveti> u-boot
<prpplague> rsalveti: thanks
 * prpplague makes a note so he doesn't have to ask again
<rsalveti> prpplague: np :-)
<rsalveti> prpplague: any news about the 200/400mhz memory issues?
<prpplague> rsalveti: none that i am aware of
<rsalveti> hm, ok :-(
<prpplague> rsalveti: i think we just had one or two people with boards populated incorrectly
<prpplague> iirc those are going to be swapped out
<rsalveti> prpplague: oh, ok
<GrueMaster> prpplague: Any changes to the panda we should be concerned about post ES2.1 A1?
<prpplague> GrueMaster: none
<prpplague> GrueMaster: the mounting holes will be bigger
<GrueMaster> My main concern is a hardware change that needs kernel updates and I have no way to test them.
<prpplague> GrueMaster: thats about it
<GrueMaster> Ok.
<GrueMaster> Can't test the new mounting holes.  Sorry.
<GrueMaster> :P
<ogra_ac> slacker !
<GrueMaster> ogra_ac: If you were watching what has been happening in the kernel realm, you wouldn't say that.
<ogra_ac> i have
<GrueMaster> Not the PM's.
<ogra_ac> i think the prob is that the kernel team rotates every cycle so one habit yu have established with someone working on SRUs is lost if the next one comes up
<ogra_ac> we need clearer rules for them, preferably done by a spec next UDS
<ogra_ac> s/the prob/one prob/
<GrueMaster> Unfortunately, I have not seen a single trend (other than dropped patches).
<ogra_ac> well, lets make up a spec for budapest and sort that one and for all
<ogra_ac> i agree that this is an unbearable situation
 * GrueMaster feels like more weight will end up on his shoulders.
<ogra_ac> i doubt that
<ogra_ac> we just need clearly written down rules
<ogra_ac> and people to stick to them indeed ;)
<GrueMaster> I don't think it is just a set of rules.  We have broken tools.  Launchpad is part of the problem, the scripts that everyone runs in automation is another.
<ogra_ac> well, thne lets define the rules in a way that human interaction is required for armel kernels ;)
<GrueMaster> With launchpad, if we have a bug that crosses multiple packages, we can't rely solely on a verification- tag.
<ogra_ac> then lets define additional verification tags
<GrueMaster> That won't work.  The verification needs to be on a per-package basis and shouldn't be a tag.  This was discussed in the QA CoP.
<GrueMaster> The only way to make it work currently is by having separate bugs per package, but then scripts fail when a commit is made that tags multiple bugs.
<ogra_ac> well, nothing i want to discuss now, but i'm sure if we sit down all together at UDS with the right people we will find a solution
<GrueMaster> (hence the reason for the misfires on the MAC address bugs).
<ogra_ac> yeah
<GrueMaster> ok
<GrueMaster> ogra_ac: Why does it take so long for new packages to get published in armel?  Is it a manual process?
<ogra_ac> GrueMaster, depends on the package, the kernel chsanges it binary package name with every upload, so it ends up on binary-NEW and needs an archive admin to let it out
<apachelogger> rsalveti: tried that, didn't get me far, then again I fear my image was a bit broken yesterday, I'll try again with a new image
<rsalveti> oh, ok
<janimo> anyone tried 10.10 omap3 image in qemu? It does not completely boot for me
 * janimo tries passing -mtd to qemu
<apachelogger> rsalveti: so, I tried again... it only works with their xorg fbdev driver and then X segfaults
#ubuntu-arm 2010-12-09
<rsalveti> apachelogger: ouch
<apachelogger> rsalveti: do you happen to know where does our omap_rev_lt_3_0
 * apachelogger is trying to get our dkms package build modules for the meego kernel, since he is out of other options
<apachelogger> currently fails to build with omap_rev_lt_3_0 being implictly defined
<rsalveti> apachelogger: what exactly are you trying to do, port ubuntu to n900?
<rsalveti> when I was trying that I basically ported the meego patches to the ubuntu tree, got it booting but didn't have time to test the sgx packages
<apachelogger> porting is a bit of a strong word, ScottK tells me someone is working on a kernel that will run on the n900
<apachelogger> meanwhile I am trying to work out what needs doing on the kubuntu side of things to give decent user experience
<rsalveti> I was doing that, then mpoirier also got some work on it
<rsalveti> ok
<rsalveti> so for now I'd recommend you to use at least the sgx kernel patch available for meego
<rsalveti> then try using their libraries and x driver, but that's what you said you did
<rsalveti> would be interesting to see your segfault
<apachelogger> yeah
<rsalveti> this weekend I'm planing to waste some time on that, now that I got my n900 back
<apachelogger> hooray
<rsalveti> at least to get a proper kernel tree that can be properly used by ubuntu's userspace
<apachelogger> having a working kernel makes things a lot more fixable for me ^^
<rsalveti> apachelogger: this was the latest tree that I did some work http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-master-n900
<apachelogger> ok
<rsalveti> got it booting until x11, and then used the efl interface
<rsalveti> but then I had to give my n900 to a friend of mine
<rsalveti> and I got it back this week
<rsalveti> while at uds I was debugging this with rbelem
<rcn-ee> apachelogger, which kernel?  give this a shot.. http://gitorious.org/angstrom/angstrom-linux/commit/38adc41c6f6d686156083ff0889d0b2dd71f2e14
<apachelogger> rcn-ee: 1.1
<apachelogger> we did dirty kernel copies ^^
<apachelogger> https://wiki.ubuntu.com/ARM/n900
<rcn-ee> ah, the meego kernel..
<apachelogger> aye
<rsalveti> rcn-ee: yeah, there are some other patches just to make n900 work properly
<apachelogger> DKMS: install Completed.
<apachelogger> omg
 * apachelogger gets all jumpy
 * rbelem o/
<apachelogger> QGLShader: could not create shader
<apachelogger> Warning: "" failed to compile!
 * apachelogger sighs
<rbelem> apachelogger, which plasma-mobile are you running?
<apachelogger> whatever is in maverick
<apachelogger> oh
<apachelogger> omg
<apachelogger> uh
<apachelogger> OGLES2Coverflow works
 * apachelogger got gles2 it seems \\o/
<rbelem> \o/
<rbelem> apachelogger, you rock!
<apachelogger> now if only plasma would like to work too
<rsalveti> apachelogger: cool
<apachelogger> rsalveti: would Qt need to be compiled against special sgx headers?
<apachelogger> currently it is built against mesa's gles
<rsalveti> just to be compiled with opengl
<rsalveti> apachelogger: nops, that should work
<apachelogger> strange
 * rsalveti brb
<rbelem> apachelogger, do you know any tool that makes debian/copyright maintainance easy? :-)
<apachelogger> http://people.ubuntu.com/~apachelogger/scripts/
<apachelogger> copyright and license scripts
<apachelogger> http://paste.ubuntu.com/541253/
<rbelem> apachelogger, maybe martin has better clues about that
<apachelogger> http://comments.gmane.org/gmane.comp.lib.qt.qml/1749
<apachelogger> that does not sound very good
<rbelem> apachelogger, qt not compiled with gl es?
<apachelogger> no, it is
<apachelogger> but apparenlty it needs to be compiled against an appropriate version
<GrueMaster> I'd look at the problem in a deeper vein.  "The device itself is runs on a Atom Z520 processor".  That is Poulsbo video, which (when I worked on it) wasn't that great.
<rbelem> apachelogger, hum... martin said something about use mesa gl es libs to compile
<GrueMaster> And I don't know of any GMA500 (Poulsbo) support in Ubutnu since 8.04.
<apachelogger> rbelem: that is what I did
 * apachelogger did not even know one needed proprietary blob until this week ^^
<rbelem> brb
<apachelogger> in the lands of meego the have sgx devel packages, making me think they build against it...
<apachelogger> rbelem: if you can find someone to give input on the problem, that would be great
 * apachelogger needs to go to bed
<apachelogger> rbelem: also, fwiw, plasma-netbook does not manage to come up with *anything*
<hrw> hi
<hrw> do we have kernel for pandaboard which will work with 1G ram finally?
<rsalveti> maybe cooloney knows better
<cooloney> hrw: yeah,
<hrw> cooloney: is it available in natty?
<cooloney> i think maverick kernel works with mem=1G, but we use 2:2 split
<hrw> cooloney: which maverick kernel?
<cooloney> hrw: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
<rsalveti> for me it never worked well with high cpu loades
<rsalveti> always giving weird crashes
<cooloney> that's maverick
<rsalveti> but that might be fixed already at the lates ti kernel
<hrw> btw - definition of stable kernel: "apt-get source somethingbig -b"
<cooloney> hrw: if you wanna try natty, please try linaro natty kernel
<rsalveti> cooloney: are you able already to boot upstream on panda?
<cooloney> http://git.linaro.org/gitweb?p=ubuntu/linux-linaro-natty.git;a=summary
<hrw> cooloney: I use natty and maverick-14 kernel
<cooloney> rsalveti: i can boot up the upstream kernel. but it is panic when it try to use our ubuntu mininal root filesystem
<cooloney> rsalveti: but you can try linaro natty kernel
<cooloney> which is .37 based and very close to mainline
<cooloney> with our ubuntu sauce and config.
<cooloney> so it boots fine with on my panda
<rsalveti> that's nice
<cooloney> rsalveti: so in mainline highmem is disabled defaultly
<cooloney> rsalveti: i can still see such instability with linaro natty kernel
<rsalveti> hm
<cooloney> rsalveti: but if you have time, you can try that on your board
<hrw> otyher thing: usb. 13MB/s is max?
<rsalveti> cooloney: sure, will try it later
<tmzt> does that linaro support omap3/beagle?
<tmzt> kernel
<cooloney> tmzt: sure
<tmzt> cooloney: we are trying to port to the new nook color, which is an omap3+slcd on the lvds, and very similar to beagle
<cooloney> tmzt: so one linaro kernel can boots up on omap3/beagle and omap4/panda with the same natty file system
<tmzt> and we have the source from bn to port the board
<cooloney> tmzt: that's good start point. mainline supports beagle very well
<cooloney> but limited to panda
<cooloney> we still miss some driver or feature of omap4 in mainline
<hrw> nothing strange - omap4 is still young
<tmzt> this is omap3 though
<tmzt> looking for the best support (tony kernel?) for that
<cooloney> tmzt: i think mainline is good for omap3
<tmzt> okay
<janimo1> I am trying to run 10.10 omap3 image under qemu but it hangs timeing out on mtd
<janimo1> qemu-maemo-system-arm -M beagle -m 256 -sd ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img -serial stdio
<janimo1> how can I create a valid beagleboard mtd file to see if that is the prob?
<tmzt> mtd file?
<janimo1> tmzt: something to stand for the expected mtdbloc device in the guest
<janimo1> there
<janimo1> is a sdcard image
<janimo1> and I understand there's a NAND image as well
<tmzt> I guess mtd image has to have an ftl
<tmzt> how's the tegrabook going?
<davidm> ndec1, call time?
<GrueMaster> To all that were planning on attending the Mobile/Arm team meeting today at 15:00 UTC; the meeting has been canceled do to key players' otehr commitments and holiday schedules.  Thank you.
<dmart> asac: yes
<GrueMaster> Hmm.  It would appear that one of the recent changes to Natty since A1 has clobbered X on panda.
<rsalveti> GrueMaster: with which image?
<GrueMaster> No new image.  Just using A1 and running apt-get udgrade.
<rsalveti> ok
<GrueMaster> I'm looking into it now.  Had to check my other board I had sent to Lexington to make sure it survived.  Also had to run a vehicle to the shop (another transmission) and get a bag of fresh ground coffee.
<GrueMaster> Busy morning.
<rsalveti> :-)
<GrueMaster> rsalveti: I stand corrected.  I had used the latest image, 20101206, and updated from there.  Am now running clean image to see what update clobbered X.
<rsalveti> ok
<GrueMaster> Hrm.  Networking fails when the cord isn't plugged in.  (oops).
#ubuntu-arm 2010-12-10
<rsalveti> ndec: vstehle: call?
<ndec> rsalveti: i am coming
<rsalveti> ndec: https://blueprints.launchpad.net/ubuntu/+spec/other-dx-n-2d-experience-fallback
<rbelem> the surgery is starting
<rbelem> rsalveti
<rbelem> my baby boy is about to born
<rsalveti> rbelem: holy! :-)
<rsalveti> rbelem: good luck man!
<rbelem> thank you rsalveti :D
<rsalveti> GrueMaster: a new network-manager package should be in the archive soon
<GrueMaster> cool.  I'll keep an eye out for it.
<GrueMaster> As to the image build failures, I am actually getting used to it.  One program or library gets an update, and a huge chunk of the pool gets churned.
<GrueMaster> I just use apt-get update to wade through and keep testing.
<GrueMaster> Grrr.  Now I can't reproduce the issue I saw.  Ran apt-get -d upgrade to pull all of the packages local, then apt-get install on batches between reboots.  Fully updated, system still works.
<sveinse> Are there some differences between the native gcc and the ARM cross gcc config? I keep getting "comparison between signed and unsigned integer expressions" from the cross compiler, which I dont on the native.
<topfs2> added a -Wall in one of them perhaps?
<topfs2> just fix the warning otherwise, shouldn't be mixing those :)
<sveinse> No, its the same code on both.
<topfs2> I said -Wall as in compiler argument
<sveinse> Well, its from google's protobuf included header...
<topfs2> are they comparing in the header?
<sveinse> Yes. Inlined code. And c++
<topfs2> ick
<topfs2> at any rate, it complaining is afaik usually via -wall
<sveinse> Perhaps the specfile for ARM contains -Wall while the native dont
<sveinse> I suppose hrw can answer, but it seems he's away
<hrw> sveinse: cross one in archive is old
<hrw> updates are queued
<sveinse> Ah. I'll retry everything then
<sveinse> Are the updated/fixed libc cross also queued?
<sveinse> hrw: BTW Do you have the url to the build queue?
<sveinse> found it
<GrueMaster> rsalveti: Well, after taking my second system from 20101206 to current in batches, I couldn't reproduce the X failure.  I then updated the failing system, and it now works.  Sigh.
<rsalveti> GrueMaster: I saw that there was a problem with gdm
<rsalveti> so that could be your case
<GrueMaster> I did notice that the failing system pulled in mutter-common on updating.
<rsalveti> and that is fixed at the archive already
<GrueMaster> No, the failing system didn't pull gdm.
<rsalveti> hm
<rsalveti> well, if it's working now then we're happy :-)
<GrueMaster> But since I can't reproduce it on two systems, I'm moving on.
<GrueMaster> yep
<rsalveti> ok
<rsalveti> GrueMaster: just finished: https://launchpad.net/ubuntu/+source/network-manager/0.8.3+git.20101209t061929.638fb18-0ubuntu1/+build/2091214
<rsalveti> should be available at the archive soon
 * GrueMaster waits with baited breath.
#ubuntu-arm 2010-12-11
<sveinse> Yes! Finally it seems I've found a way to cross compile ARM applications (outside of xdeb) for Ubuntu ARM target!
<gcl> apw: ping?  You wrote conmux, right?
#ubuntu-arm 2011-12-05
<Xase>  lilstevie, any thoughts?
<jamespage> good morning: should we be enabling neon support for libraries that support it for ARM on Ubuntu?
<infinity> jamespage: If they do runtime detection yes, if not, no.
<infinity> jamespage: (Not all our targets support neon, so we can't use it by default)
<jamespage> infinity, great - thats what I thought but wanted to check first - thanks!
<infinity> (We have lots of code in the archive that does runtime neon detection, and it's a huge win when you can)
<infinity> libjpeg-turbo being an obvious one.  Pretty sure there's handcrafted neon in libssl.  Etc, etc.
<infinity> Well, it's a huge win if it's well-written neon. :P
<ppisati> infinity: do you know if any babbage builder is using the kernel with the "large mmap() support"?
<ppisati> bug 861296
<ubot2> Launchpad bug 861296 in linux "mmap fails to allocate 2030Mb heap on ARM" [High,Confirmed] https://launchpad.net/bugs/861296
<ppisati> infinity: or do you know to whom shall i talk for the arm builders?
<ogra_> lamont
<ogra_> but i think he switched tham already
<ogra_> or at least he tested that kernel on one
<ppisati> OlivierN: mail sent
<ppisati> ops
<ppisati> ogra_: ^
<ogra_> :)
<lool> Hey
<lool> would someone know why "step" isn't built on ARM?
<lool> it seems to be purposedly disabled on Ubuntu only
<lool> (and this means kdeedu is uninstallable on armel)
<ogra_> lool, i dont think anyone fo ubuntu-arm touched it ... probably the kde people did
<ogra_> *of
<infinity> lool: Arch is specified in the source, no idea why.  If it builds and runs, by all means, change that.
<lool> infinity: It seems to be an intentional change from Riddell, see latest changelog entry, that's why I was digging a bit
<lool> it's built in experimental (on armel)
<infinity> lool: Looks like it's been like that since it was first uploaded to oneiric.  No clue why.
<lool> since I couldn't commit to its Vcs-Bzr which doens't exist, I've pinged the kubuntu team
<infinity> jcrigby: Are you going to have time to do some judicious s/armel/armel armhf/ (and other required tweaks) mojo on uboot-linaro and assorted kernels soon?
<ogra_> oh, surprise, banshee failed on armhf
<ogra_> infinity, do we still need the linux-libc-dev entry in the topic ? looks like it built
* infinity changed the topic of #ubuntu-arm to: Ubuntu ARMv7 Discussion & Development | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Get oneiric while it's hot ! http://cdimage.ubuntu.com/releases/11.10/release/ | Logs at http://irclogs.ubuntu.com/ | armhf builds are running
<infinity> Nope.
<infinity> adconrad@cocoplum:~$ suite-diff.py /srv/launchpad.net/ubuntu-archive/ubuntu/dists/precise/main/binary-arm*/Packages.gz gt | wc -l
<infinity> 238
<infinity> Only 238 binary packages in main different (or missing) compared to armel.
<ogra_> yay
<ogra_> and only 4800 jobs in the queue
<ogra_> not bad
<doko_> infinity, is this suite-diff command complete?
<infinity> doko_: The copy in ~adconrad/bin is.
<infinity> Well, FSVO "complete".  It's a hackish fix of a hackish branch of Colin's.
<doko_> good enough
<doko_> infinity, why is apr rescored to -1?
<infinity> doko_: Testsuite that hangs on the buildds, if I recall.  Was saving it for "later".
<infinity> (Or until I had a chance to look at it)
<doko_> ok, starting a local build
<jcrigby> infinity, tell me about armhf and u-boot, u-boot does no floating point
<jcrigby> infinity, I think I just answered my own question.  U-boot should be built for both and go into both archives?
<infinity> jcrigby: Yup.
<infinity> jcrigby: Same story with kernel packages.
<infinity> jcrigby: But u-boot's our current blocker.
<doko_> infinity, apr tests run fine here
<infinity> doko_: Whacky.  Which kernel and hardware?
<infinity> doko_: But I'm happy to potentially eat a buildd to find out.
<doko_> infinity, oneiric panda
<infinity> Kay.  The buildds are natty panda, but we can try.  I'm game.
<infinity> Score it up.
<kenws> Hi there, I noticed that the Packages.gz for armel on Oneiric has gcc-avr 4.3.5 while on x86 it's 4.5.3. The funny thing is that 1) avr-libc depends on gcc-avr 4.5.3 and 2) the gcc-avr 4.5.3 deb is actually available.
<kenws> http://paste.ubuntu.com/760527/
<infinity>    gcc-avr |  1:4.3.5-1 | oneiric/universe | armel
<infinity>    gcc-avr |  1:4.5.3-2 | oneiric/universe | source, amd64, i386, powerpc
<ogra_> looks like NBS
<kenws> infinity: yeah, but the avr-libc for armel depends on gcc-avr 4.5.3
<infinity> kenws: The reason the deb is there is because it was built in precise.
<kenws> infinity: ok, I see.
<infinity> avr-libc is arch:all, hence the weird dep.
<kenws> aah, ok - interesting
<kenws> I haven't tried it but it looks like there is no easy way (without apt pinning) to get avr-libc installed on armel oneiric.
<infinity> That should have been tidied and removed before release. :/
<infinity> Would be just as broken, but less confusing.
<ogra_> yep
<infinity> You could always try running precise. ;)
<kenws> : )
<ogra_> armhf indeed :)
<kenws> dOh, wdo we have armhf packages for precise already?
<ogra_> sure
<kenws> s/dOh/Oh/
<kenws> cool
<infinity> No installers yet, and missing some desktop bits (and lots of universe), but we're getting there.
<ogra_> send flowers to infinity
<ogra_> looks good for FF if we dont hit a bad disaster now
<infinity> Yeah, I think we're going to be fine.
<infinity> It might actually be in better shape than armel soon. :P
<ogra_> well, lets see how the build system behaves
<infinity> (Which won't hurt my feelings at all)
<ogra_> i expect a bunch of changes to the subarch bits
<infinity> Which build system?
<ogra_> (image builds i mean(
<kenws> so, the way for armhf is to deboostrap a rootfs or are there better ways?
<infinity> d-i's done, livecd-rootfs is done, live-build is done.
<infinity> All we need is uboot and kernels.
<ogra_> kenws, use ubuntu-core
<ogra_> infinity, cdimage and debian-cd
<infinity> I did cdimage.
<infinity> debain-cd is cake.
<infinity> I'll do it tomorrow.
<ogra_> there are plenty areas weher we check for armel
<ogra_> *where
<infinity> Like i said, cdimage is all done. :P
<kenws> ogra_: ok, thanks
<infinity> debian-cd won't take long.
<ogra_> k
<xranby> infinity: debootstrap of armhf are ticking on nicely... thanks!
<kenws> will there be a precise release for the softfp abi as well?
<infinity> kenws: Yes.
<ogra_> might be an unsupported one though
<infinity> kenws: But only one of them (probably armhf) will get official LTS support.
<ogra_> which will get really funny wrt binary drivers
<infinity> Binary drivers are going to be fun.
<kenws> ok, so lets that the proprietaryGL libs will be available for hf as well ; )
<kenws> yep
 * kenws is looking for the ubuntu-core root fs
<infinity> We have some good relationships with some vendors who will (hopefully) DTRT there.
<infinity> But not all vendors.
<ogra_> well, i think TI might be with us here if we can actually provide them a build and test env early enough
<ogra_> but for others ...
<kenws> which abi a the binaries in the precise-core-armel.tar.gz? (http://cdimage.ubuntu.com/ubuntu-core/releases/precise/alpha-1/)
<ogra_> dont take A1
<ogra_> take the last daily that built
<ogra_> (and that should have the most recent abi)
<kenws> ok, so http://cdimage.ubuntu.com/ubuntu-core/daily/current/
<ogra_> right
<kenws> thanks
<infinity> ubuntu-core will actually be producing dailies again shortly.  Just fixing the buildd right now. :P
<infinity> kenws: As for "which abi", armel is always softfp, armhf is always hard.  That's the point of having two. ;)
<kenws> infinity: I agree : ). when I looked a the alpha-1 there was only one tarball and I didn't know how the binaries were built
<infinity> kenws: Yeah, I landed all this post-A1. ;)
<lilstevie> also, nvidia do have hf binary drivers for tegra
<infinity> lilstevie: \o/
<ogra_> yay, where ?
<lilstevie> trimslice developer forums
<infinity> lilstevie: Of course, if they also have executables with those, they won't run, I bet.
<infinity> lilstevie: But the libraries and drivers will work.
<lilstevie> they were built post a12r1
<lilstevie> but they do have those daemon bits that aren't strictly needed anymore
<ogra_> nice !
<ogra_> bah, sigh
<ogra_> so not like the linux4tegra drop then
<infinity> Yeah, the daemon bits won't work.
<lilstevie> not quite
<infinity> We really need to push our linker changes upstream and get every toolchain on the same page.
<infinity> Like, yesterday.
<lilstevie> the daemons weren't running on Mer
<lilstevie> but using the drivers
<lilstevie> but in any case
<lilstevie> they use them for the trimslice on Mer, and Archlinux
<lilstevie> hf drivers that is
<Xase> lilstevie: any abstract thoughts on my problem?
<lilstevie> Xase: not yet, been a little busy
<Xase> No sweat, any knowledge anyone could provide is a great help.
<infinity> And we have Unity on armhf.  Welcome to a (probably partially broken) desktop.
<lilstevie> infinity: heh
<lilstevie> nice
<lilstevie> I love comments on forums like "-it might be a good idea to test the binaries before running the script to make sure they don't segfault, since this seems to be a relatively common problem"
<lilstevie> :/
<lilstevie> 1) I have had 0 reports of this, and have no idea where this 'common problem' is. 2) I give an email address for people to report bugs to; nobody has
<lilstevie> oh, and my favorite... 3) I use the stuff I do myself
<doko_> ppisati, could you build linux-ti-omap4 for armhf please?
<ppisati> doko_: is the next item in my todo list
<infinity> \o/
<doko_> ppisati, thanks, including the mmap patch?
<ppisati> yep
<ndec> ogra_: hi. do you think i could get another PPA on tiomap-dev? something for 'experimental' stuff that we want ubuntu users to get access to easily?
<ogra_> ndec, will have to talk to davidm about that, but he is traveling, how urgent is that ?
<ndec> not so many things in terms of build load, but i just need to make sure that we make a clear separation between what should work (release PPA) and our sandbox
<ndec> not too much urgent.
<ogra_> ok
<ogra_> i'll get an answer before the friday meeting
<ndec> good!
<GrueMaster> ppisati: Does this round of SRU kernels have the mmap fix?
<ppisati> GrueMaster: nope
<ppisati> GrueMaster: it entered the trees today
<GrueMaster> sigh.  Why so late?  It was tested a couple of weeks ago?
<GrueMaster> Now we have to wait for another round of SRU updates.
<infinity> Hey look, d-i succeeded.
<ogra_> wohoo
<ogra_> quick, lets build alternates :P
<GrueMaster> For?  armhf???
<infinity> I haven't done the debian-cd mangling yet. ;)
<infinity> GrueMaster: Yeah.
<ogra_> yep :P
<GrueMaster> If only we had a kernel.
<ogra_> well, netinst should work
<ogra_> we do (if it finished yet)
<ogra_> for omap at least
<infinity> We have omap.
<infinity> d-i wouldn't have built without it.
<ogra_> ah, right
<ogra_> u-boot is missing
<infinity> Is not.
<GrueMaster> omap?  Cool.  I can start testing it later today once my mirror has pulled it in.
<infinity> Again, d-i won't build without it. :P
<ogra_> you fixed it ?
<ogra_> oookay
<infinity> Just needed armhf added to the arch list.
 * ogra_ wants ac100 :P
<infinity> doko did uboot and x-loader.
<ogra_> i saw x-loader
<ogra_> missed u-boot somehow
<infinity> I think he's just been looking at suite-diff.py output and adding armhf everywhere it wasn't. ;)
<ogra_> heh
<infinity> I've been focusing on getting the desktop built.
<infinity> unity-2d done.
<infinity> Some ubuntuone stuff still to go.
<ogra_> yeah, and that lenses thing for 3d
<infinity> Hey, we have a libinfinity.
<infinity> The file lens needs actual fixing.
<ogra_> well, a bunch hasnt built yet for -desktop
<infinity> The desktop guys are on it.
<ogra_> yep, saw that
<infinity> I don't know about "a bunch".  We're only 153 packages short in main.
<doko_> ogra_, all packages on armhf should be built, which also exist on armel (or are currently building ...)
<infinity> Binary packages, that is.
<ogra_> http://qa.ubuntuwire.org/ftbfs/primary-precise-armhf.html shows 10 (one ftbfs)
<infinity> doko_: Redboot failed.  Calling the compiler by ABI name.  Not that it matters.
<doko_> infinity, currently fixing
<ogra_> for the ubuntu-desktop set
<doko_> had to do libinfinity first ;)
<ogra_> doko_, i wonder if we shouldnt just remove redboot
<GrueMaster> redboot fails?  Oh no!  Panic time. :P
<infinity> banshee's just waiting on ubuntuone stuff to sort out.
<ogra_> nobody maintains it
<infinity> ogra_: We don't boot any subarches with it anymore.
<ogra_> and nothing uses it anymore
<infinity> ogra_: Freescale moved entirely to u-boot.
<ogra_> infinity, well, we probably kept it around for oem or something
<infinity> I'm game for removal.
<infinity> Or at least demotion.
<ogra_> not sure
<ogra_> huh
<GrueMaster> Only redboot platform we have is Babbage3, which is stuck on Lucid.
<ogra_> it was demoted ages ago
<infinity> Or is it already in universe
<infinity> ?
<ogra_> if its in main again thats a bug
<infinity> In that case, no idea why doko uploaded it. :P
<ogra_> heh
<ogra_> nostalgy :)
<infinity> redboot-imx | 200952-0ubuntu2 |       precise | source
<infinity> ^-- Looks main to me.
<ogra_> GrueMaster, the vodafone netbook is babbage "like" so it might have helped having around a redboot package to patch it
<infinity> Find where that's seeded and get rid of it.
<ogra_> infinity, wow
<infinity> Actually, I will.
<ogra_> it shouldnt be seeded
<ogra_> weird
<infinity> ... wow.  I still don't have the precise seeds locally?  I fail at life.
<GrueMaster> ogra_: So is the Efika, but iirc, it is u-boot.
<infinity> platform.oneiric/installer: * redboot-tools-udeb [armel]
<infinity> Yeah, it's seeded.
<infinity> Now to fix it in precise.
<ogra_> GrueMaster, right, i think the vodabook is actually very close to bbg
<ogra_> so might use redboot
<GrueMaster> ENOCLUE.
<infinity> Freescale ditched redboot ages ago.
<infinity> Any newer imx51 stuff should be u-boot, from what I understand.
<ogra_> infinity, yes, thats what i say, the HW is based on a board where no u-boot existed
<GrueMaster> I thought we were looking at switching bbg3 during Lucid also, but couldn't get it working.
<ogra_> right
<infinity> Well, I'll keep it seeded then.
<ogra_> code was immature and incomplete
<infinity> ogra_: Care to verify with our new PES overlords? :)
<ogra_> infinity, no, drop it
<ogra_> thats a 2009 source that nobody touched afterwards if people need the source package they should pull from lucid
<ogra_> i dont think it changed since
<GrueMaster> If needed, universe isn't too far to see for the eye of Sauron.
<infinity> Yeah, I won't remove it, just demote it.
<infinity> Committed.
 * ogra_ just asked about the vidabook, if they dont use it i'll file a removal bug
<ogra_> *voda
<infinity> It does little harm being in universe.
<infinity> If some keener wants to do a home-brew precise setup on their babbage.
<ogra_> hm
<ogra_> as long as nobody bothers me about it (it might have my name all over the changelog)
<infinity> :P
<ogra_> hmm, looks like the xubuntu seeds would like to know about armhf
<micahg> ogra_: indeed, but I was waiting for universe to be more complety built before doing that
<ogra_> ah
<infinity> micahg: Hey, I spent some time unsnagging at least the core of xubuntu...
<micahg> infinity: I wasn't blaming anyone :)
<infinity> micahg: libxfcegui4 needs love, though.
<infinity> micahg: (hint, hint)
<micahg> infinity: doko fixed that I thought
<infinity> Oh, so he did.
<infinity> He's been rather nuts with the uploads today.
<ogra_> argh
<infinity> And banshee's off!
<ogra_> root@horus:/# exit
<ogra_> ogra@horus:~/chroot-hf$ ps ax
<ogra_> Killed
<infinity> ogra_: Reboot.
<ogra_> no way to umount the /proc inside the chroot now i guess
<ogra_> grr
<infinity> ogra_: You upgraded your chroot without having a no-op policy-rc.d in place.
<infinity> ogra_: And something broke your init.
<micahg> infinity: I can update the xubuntu seeds tomorrow for armhf if you think everything's close enough for it to work
<infinity> micahg: No huge rush.
<micahg> ok
<ogra_> infinity, well, i upgraded without /proc or /sys mounted ... and only mounted them for configuring procps ...
<ogra_> afterwards
<infinity> ogra_: And procps is what killed you, then.
<infinity> I bet. :P
<ogra_> likely
<ogra_> not init though
 * ogra_ crosses fingers and reboots
<infinity> I should go do debian-cd now.
<infinity> We're closer to desktop images than I thought we would be.
<infinity> ogra_: debian-cd done.
<infinity> ogra_: If you want to review the latest revision (but I already merged it into production...)
<ogra_> well, if its already merged i'll look at the fallout :P
<ogra_> livecd-rootfs (or rather BuildLiveCD) dont seem happy at,
<ogra_> *atm
<ogra_> the failure mail i got looks like a quoting issue in BuildLiveCD
<ogra_> Subject: LiveFS --f-omap4/ubuntu/armel+omap4 failed to build on 20111205 ...
<ogra_> -f is usually for the filesystem call
<infinity> ogra_: But does the failure log itself look goofy?
<ogra_> there is no content
<infinity> ogra_: Or just the subject line?
<infinity> Weird...
 * GrueMaster has become numb to these emails.
<ogra_> seems to have failed in buildLiveCd already
<infinity> Cause I have a log...
<infinity> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-omap4/20111205/livecd-20111205-armel.out
<ogra_> GrueMaster, i only glance over them if they roll in ... that way such inconsistencies jump in my face
<infinity> ogra_: I've done literally nothing to BuildLiveCD that would lead to that.
<ogra_> stramge
<infinity> Which host mailed that to you?
<ogra_> nusakan
<ogra_> indeed
<infinity> So, it's not from BuildLiveCD at all...
<ogra_> if it starts with LiveFS it is from the buildlive run
<ogra_> (the subject i mean)
<infinity> Yes, but not BuildLiveCD.
<ogra_> well, thatrs just a subsequent call indeed
<ogra_> buildlive isnt doing much else but running BuildLiveCD remotely
<ogra_> but yeah, i indeed meant the execution of BuildLiveCD
<infinity> I blame Colin's revision.
<infinity> -                       mail -s "LiveFS $PROJECT/$DIST/$arch failed to build on $datestamp" \
<infinity> +                       mail -s "LiveFS $PROJECT${SUBPROJECT:+-$SUBPROJECT}${subarch:+-$subarch}${UBUNTU_DEFAULTS_LOCALE:+-$UBUNTU_DEFAULTS_LOCALE}/$DIST/$arch failed to build on $datestamp" \
<ogra_> oh
<infinity> Though, how we're getting OPTIONS in there, I don't know...
<infinity> Oh, we're not.
<ogra_> where does --f come from then ?
 * ogra_ doesnt see it
<ogra_> must come out of $PROJECT${SUBPROJECT:+-$SUBPROJECT}
<infinity> Did you get that mail more than once?
<ogra_> nope, not yet
<infinity> I suspect it was a manual build with bad options on the CLI.
<ogra_> ah
<infinity> Leading to the empty mail and the whacky subject.
<ogra_> it would really help if it would publish the euid of the executing user :)
<ogra_> that way we should be able to distinguish between sudoed CLI calls and cron runs :)
<ogra_> SUDO_USER sshould be unset if it runs from cron, right ?
<ogra_> that way we should be able to tag it as manual build, i think that would help
<infinity> cron runs as root, so yes.
<jhobbs> where is the most proper place to check for the status of an ubuntu package for arm?
<micahg> jhobbs: in most cases it should be the same as any other architecture, you can use rmadison in devscripts to query what the latest version per arch is of a package
<GrueMaster> jhobbs: You can also search launchpad.net for the package.
<GrueMaster> Just select the version "in Ubuntu".
<jhobbs> thanks
<infinity> ppisati: So, on pressure, but if we had a ti-omap4 kernel on armhf, we could build desktop CDs in about an hour (without libreoffice, it's still building... But close enough!)
<infinity> ppisati: s/on pressure/no pressure/ ;)
 * GrueMaster increases the pressure.
<infinity> ubuntu-core/armhf dailies re-enabled, tomorrow we build desktop images.
<infinity> Or maybe tonight after I've napped. :P
<GrueMaster> W00T!
<doko> infinity, exo ftbfs on armhf, succeeds here locally ...
#ubuntu-arm 2011-12-06
<arinel> is this a good channel to ask about the ARM architecture?
<twb> If it's ubuntu-related, sure
<twb> If not, maaaybe
<arinel> I'll take my chances then. I was wondering if the carry_out from the shifter is fed into the ALU?
<arinel> in ARM v1-v5 (or so)
<twb> Way above my head
<arinel> I can't find a diagram that would show details on this
<twb> ##workingset might know of an appropriate channel, also recommend you lurk here
<arinel> aha, thx!
<doko> infinity, can you see what is wrong with exo?
<infinity> doko: Well, the log just looks like bad quoting in variable assignment...
<infinity> FOO=bar baz ./quux ; bash: bar: No such file or directory
<infinity> Err, "baz: No such"... But you get the idea.
<infinity> Should be FOO="bar baz" ./quux
<doko> must have been blind ...
<ogra_> WOAH !
<ogra_> 0 upgraded, 1021 newly installed, 0 to remove and 0 not upgraded.
<ogra_> Need to get 325 MB of archives.
<ogra_> After this operation, 955 MB of additional disk space will be used.
<ogra_> ....
<ogra_> thats from apt-get install ubuntu-desktop in my hf chroot !
<ogra_> doko, infinity, you guys rock !
<ogra_> janimo, can i have an armhf ac100 kernel ? :)
<infinity> ppisati: Any progress on ti-omap4 kernels for armhf?
<infinity> ogra_: 1021 newly installed?  What was that the build-deps for? :)
<ogra_> build deps ?
<ogra_> thats just a plain apt-get install ubuntu-desktop
<ogra_> no build deps :)
<ogra_> on top of -core btw
<ogra_> abh, abootimg hasnt been built yet
<ogra_> *bah even
<infinity> Ahh.
<infinity> Can fix.
<infinity> Anything else you need?
<ogra_> can you trigger a build without uploading a build1 version ?
<ogra_> else i'm happy to do that
<infinity> There's nothing to trigger, I just had to score it up.
<infinity> https://launchpad.net/ubuntu/+source/abootimg/0.6-1/+build/2960109
<ogra_> oh, ok
<sefokuma> hi, i have a ecafe slim netbook with a A8 freescale i.MX515
<infinity> Can I have it?
<sefokuma> i'm triying to change OS to Ubuntu from this way https://wiki.ubuntu.com/ARM/MX5/QuickStart
<ogra_> infinity, stay with the qiockstart :)
<sefokuma> but when i try to boot system dont boot from sd crad
<sefokuma> *card
<infinity> sefokuma: The uBoot on that card won't boot your system.
<infinity> And the kernel may or may not.
<ogra_> unlikely that the kernel works, but you should be able to boot with the exiting kernel and bootloader the device ships with
<ogra_> you will need to do a bit of fiddling
<sefokuma> infinity i select boot from external card with dip switch, i think that netbook must boot from it
<sefokuma> if ubuntu armel for MX5 its prepared with uboot bootable... why dont work?
<ogra_> sefokuma, the bootloader on the SD wont support that hardware
<infinity> ^
<sefokuma> ogra_ ok
<ogra_> you need to find a u-boot binary that does and replace the one on the SD
<ogra_> same goes for the kernel i guess
<sefokuma> ogra_ aham ok
<ogra_> these images are specifically built for the quickstart board
<sefokuma> oh! ok now i understand
<ogra_> userspace will work on your device
<sefokuma> i will try install image on SD but overwrite uboot and ulinuximage with originals from guillemot
<ogra_> right
<ppisati> infinity: i'm starting it now
<ppisati> janimo: off topic
<infinity> ppisati: Awesome.
<infinity> ppisati: I uploaded meta that assumes 1401 will build on armhf.  So, now I just need a kernel. ;)
<ppisati> janimo: is mosh micolay (whatever is the name/pronunciation) today?
<ppisati> janimo: Nicolai Mosh actually
<infinity> ppisati: It should just be a question of "for i in `rgrep -l armel *`; do sed -i -e 's/armel/armel armhf/'; done && for i in find . -name \*armel\*; do (I can't be bothered to type a decent automated version of "cp foo-armel foo-armhf"); done
<ppisati> infinity: somehow :)
<infinity> ppisati: I fact, I can do that right now, if you like, and you can work on newer ABIs and shiny feature merges with 3.2? ;)
<ppisati> infinity: i'm doing it manuallu right now
<infinity> ppisati: I would have done it already, but I didn't want to step on your toes and make you grumpy if you were half done.
<infinity> ppisati: Alright, cool.
<infinity> ppisati: Just watch for both "rgrep armel *" and "find . -name \*armel\*"... The file copies was what bit apw when he did it. :P
<infinity> (As in, he forgot)
<apw> ppisati, very true, you need the d-i bits as well which are in files by arch name
<infinity> ogra_: https://launchpad.net/ubuntu/+source/abootimg/0.6-1/+build/2960109/+files/abootimg_0.6-1_armhf.deb
<ogra_> yay, thanks !
<ogra_> now i just need a kernel
<infinity> You have omap.  Break out a Beagle.
 * ogra_ would change the existing one himself but i really really dont want to touch git 
<infinity> But I can do ac100 on armhf, if you like.
<ogra_> well, there is a 3.0 branch ready for testing
<infinity> I wasn't going to touch git, I was just going to mangle the packaging and let jani sort it.  Not because I dislike git (I quite like it), but because I suspect I can't merge to whatever branch he's using anyway.
<ogra_> i would assume that janimo is already on it and we get armhf with the next upload
<infinity> 3.0 would be shiny, but any working kernel is good for now.
<infinity> Though it's unsupported anyway, blah blha.
<infinity> So.
<ogra_> hmm, so you wouldnt touch git either
<infinity> Wait for ppisati, and go armhf on your panda? :)
<ogra_> then i can do it as well
<ogra_> i want to upgrade my ac100 to precise anyway
<ogra_> so i can as well try the adventurous cross grade :)
<infinity> It won't even remotely work.
<infinity> So, like.  Don't try.
<ogra_> pfft
<infinity> libc-bin makes the world explode.
<infinity> Well, I guess you can try.  But be prepared to wipe and reinstall right after. :P
<infinity> ogra_: Anyhow.  I'm about to do the ac100 armhf thing.  Unless you really want to.
<ogra_> if i unpack -core over my rootfs and then do a simple desktop install ....
<ogra_> no. do it if you feel like
<infinity> Doing.
<infinity> Build needed 45:44:37, 8327584k disk space
<infinity> ^-- qt4-x11 on a babbage.
<ogra_> nice
<infinity> We can't get rid of those things fast enough...
<infinity> It takes, like, 13 hours on a Panda.
<ogra_> yeah
<ogra_> and 10min on a calxeda :)
<dmart> Build needed 45:44:37, 8327584k disk space> hah, I remember that.  Pretty painful
<apw> ogra_, but do you have one
<dmart> 10min> nice
<apw> and indeed does anyone
 * apw would like one to build kernels on
<ogra_> apw, sadly not yet
<ogra_> in a year from now though ....
<ogra_> *g*
<apw> then build time ->infinity right now on one ;/
<xranby> yesterday i started a armhf deboostrap... http://paste.ubuntu.com/761449/   for some reason it stalled and have now been stuck for 12h I: Configuring console-setup...
<dmart> Sure 1 year + 10 mins ?
<xranby> am i the only one hitting this?
<infinity> xranby: I've not seen it.
<ogra_> xranby, did you mount /proc and /sys ?
<ogra_> i had it doing weird things to my host when it configured procps
<infinity> The procps madness only happens on upgrade.
<infinity> Not on debootstrap.
<xranby> ogra_: no i simply crated the precise-hf foler and executed sudo debootstrap --verbose --arch armhf precise /media/dh0/chroot/precise-hf
<infinity> xranby: Ctrl-C and try harder? :P
<ogra_> oh, right mine was an upgrade
<infinity> xranby: Although, I haven't tried a full debootstrap yet.  I'm only using --variant=buildd and --variant=minbase
<infinity> xranby: (I'd recommend one of those)
<xranby> ok i have now used ctrl-c
<xranby> will chroot into it and see if it are usable
<infinity> It won't be.
<infinity> Just wipe it and use --variant=buildd.
<xranby> heh ok
<soren> Would Ubuntu work on the new Eee Transformer Prime (including graphics support)?
<infinity> soren: Graphics are a big "maybe, but not sure yet".  The bigger issue right now will be locked bootloaders.
<infinity> soren: So, uhh.  We'll see.
<infinity> soren: But I suspect a number of people will be buying them to make it happen. :P
<soren> infinity: What will I need to keep an eye on? Is there a tegra X.org driver where this is likely to land (for the graphics stuff, obviously)?
<soren> infinity: ...or is this all kernel-side these days, so keeping an eye on LKML will suffice?
<infinity> soren: Oh, we'll probably have non-accelerate video out of the gate.  It's binary drivers that will be iffy.
<xranby> infinity:  --variant=buildd = works for me
<xranby> thanks
<infinity> xranby: Figured it would.
<infinity> soren: But, until we get past the bootloader, I make no promises about... Well... Anything. ;)
<soren> infinity: Oh, cool. Is there a generic graphics sort of thing for ARM as well (akin to VESA)?
<infinity> There are a few framebuffer drivers.
<infinity> For some large value of "few".
<infinity> ogra_: Running a test-build of linux-ac100...
<infinity> ogra_: If it's good, I'll upload before bed.
<soren> infinity: Using one of these framebuffer drivers instead of proper accelerated drivers, will that drain the battery with normal use, or only if I try to do a lot of OpenGL stuff, for instance?
<infinity> soren: Who knows.  The hardware's still a mystery to me until I have one.
<soren> infinity: Alright. I just thought that was the sort of thing you could answer based on past experience. No worries.
<infinity> soren: Well, on the Tegra2 netbook I use, I don't use binary drivers, and I get insanely good battery life.  Not sure how useful that data point is, but I imagine Tegra3 stuff will play out similarly.
<soren> infinity: Wicked. Thanks.
<ogra_> infinity, awesome !
 * infinity taps foot.
<infinity> My Panda needs some go-faster juice.
<ppisati> infinity: i want to do another thing to P/omap4 before i upload, but if you want i can give you an omap4 armhf kernel now
<ogra_> ppisati, we need it in the archive
<ogra_> to build images
<sefokuma> hi again
<sefokuma> i have now a ubuntu-core running on my arm
<sefokuma> but.. i dont know default password of ubuntu-core fs lol
<sefokuma> any idea?
<ogra_> there is none
<sefokuma> and userÂ¿
<ogra_> nor is there a user or any networking config
<ogra_> you need to configure that by hand
<ogra_> -core is to build images on top of it, not for plain usage
<sefokuma> yes i know
<sefokuma> but i need first boot and login
<sefokuma> to continue making system
<ogra_> if you want to use it you need to make a bunch of adjustments before using it (create a user, install the networking bits, configure the system etc
<ogra_> (before booting into it)
<sefokuma> ok
<sefokuma> i was following his steps
<sefokuma> https://wiki.ubuntu.com/Core - Deploying Ubuntu Core
<ogra_> yeah, thats not complete yet
<sefokuma> oh ok
<ogra_> we have a task to update the documentation for precise
<sefokuma_> sorry coniecction time out
<sefokuma> ok works
<sefokuma> but im thinking on copy armel MX5 rootfs directly to SD cardroot filesystem
<lool> hey folks, does someone know whether someone still cares for the "mobile" packageset?
<ogra_> nobody does
<ogra_> same for netbook
<ogra_> though i'm not sure kubuntu-mobile didnt migrate to just be called mobile
<ogra_> better ask them :)
<infinity> I'm not sure what mobile is anymore.
<infinity> It has xfce stuff in it..
<doko> xfce should build now, unless the desktop team hates xfce even more ...
<lool> is there a web ui to check packagesets contents and upload permissions?
<lool> I figure launchpadlib might expose it
<infinity> lool: No idea.  I'm pretty packageset ignorant.
<infinity> lool: I know that creating/managing them is still an annying by-hand affair with some voodoo.
<Daviey> lool: edit_acl.py
<lool> Daviey: I'm not an archive admin
<Daviey> lool: neither am i, but you can use it to check who has upload access where
<Daviey> and packageset contents
<lool> Daviey: where is it?
<lool> oh wow, lp:ubuntu-archive-tools is public and I never used it
<Daviey> $ edit_acl.py -P mobile -S precise query
<lool> worked fine, thanks
<Daviey> groovy
<infinity> hildon and xfce and other bits.
<infinity> That's so painfully obsolete.
<ogra_> kill it !
<lool> it seems we don't have a process for removing sources from packagesets
<lool> I mean binaries from packagesets when we remove sources
<ogra_> but you should be able to remove the whole packageset
<ogra_> which in this case would be proper
<infinity> lool: Eh?  Binaries aren't in packagesets.
<infinity> lool: Package set define archive rights, it's source-level ganularity.
<lool> ah right
<lool> indeed these are used for source upload rights
<lool> Ok; going to lie down a bit, I feel too sick
<infinity> top - 13:55:57 up  7:18,  0 users,  load average: 12.08, 10.66, 9.29
<infinity> And they said the Panda wasn't server hardware...
<ogra_> ha ha
<Daviey> infinity: did you do mdad raid via partitions on a single sdcard?
<Daviey> redundancy++
<S0NiC> hi
<S0NiC> can anyone help me to change some values for this tutorial https://wiki.ubuntu.com/ARM/BuildEABIChroot? because http://ports.ubuntu.com/ubuntu-ports/dists/karmic/Release doesnt exist
<ogra_> S0NiC, that howto i sreally really outdated
<ogra_> S0NiC, if you feel like, please delete it ....
<ogra_> (else we will delete it along woth the rootfs from scratch page etc)
<ogra_> *with
<S0NiC> ogra_ can you tell me another howto?
<ogra_> not yet, we will rework all this with the switch to live-build
<ogra_> currently the existing howtos refer to obsolete tools adn the new tools arent properly documented yet
<S0NiC> hmm shit i have to crosscompile a programm for amr7
<ogra_> as for building a chroot, install qemu-user-static, run qemu-debootstrap
<S0NiC> mom
<ogra_> that will create an arm chroot on an x86 machine
<ogra_> at least on systems newer than lucid
<ogra_> for lucid ask in #linaro for the lucid PPA of qemu
<S0NiC> i am useing maverick
<S0NiC> -.e
<ogra_> might be ok ...
<S0NiC> have i to specifiy a target-arch=
<S0NiC> http://nopaste.info/cae429e70f.html
<S0NiC> because i get this error?
<ogra_> i think aemu-debootstrap defaults to armel ... if not, the same options debootstrap uses apply
<ogra_> *qemu
<ogra_> yeah, try --arch armel
<ogra_> beyond that, all other debootstrap options apply
<S0NiC> ogra_ i tried... http://nopaste.info/4493dfff57.html but doesnt work ;(
<ogra_> well, it tells you what you are missing
<ogra_> just follow the suggestion the "usage" line gives you
<ogra_> suite is the release name i.e. oneiric, maverick etc ...
<ogra_> target is the dir relative to the dir you run the command in
 * ogra_ hugs infinity 
<ogra_> so tomorrow is the image day :)
<ogra_> ndec, before end of the week we should have armhf images for panda, beagle and ac100 ...
<ndec> ogra_: hey! cool.
<ogra_> ndec, an armhf  recompiled gles driver for panda would rock soooo hard :)
<S0NiC> sorry i was away
<S0NiC> ogra_ now it works. thanks
<ogra_> :)
<ogra_> S0NiC, does your project have heavy dependencies ? else you could just use the cross compiler
<S0NiC> ogra_ i have a question for my understanding: if its finished i change to the directory and can compile there my program?
<S0NiC> what do you mean by heavy depndencies?
<ogra_> you can run: sudo chroot <path to your target dir>
<ogra_> that will switch your filesystem root to the chroot
<ogra_> well, libraries etc
<S0NiC> ogra_ iam new to this ;D thanks, i read this already
<S0NiC> i try to compile a qtwebkit program
<S0NiC> i think, thats heavy? ;)
<ogra_> ah, k, then the chroot approach is probably better
<S0NiC> i did some tries but the conclusion was not soooooooooo good ;)
<ogra_> if it would have been a cmdline thing that only needs libc that would be lightweight enough to not use a chroot
<S0NiC> e.g. with make i can compile my program on my target (pandaboard) and on my desktop machine. i tried it with g++ and it doesnt work (its a little c++ program)
<S0NiC> i see thx
<ndec> ogra_: are armel PPA building for armhf by default as well?
<ogra_> ndec, not yet
<ogra_> all that armhf stuff went way faster than expected (after massive probs in the bringup phase we're suddenly far ahead of the plan)
<ogra_> ndec, but whats there should be enough to re-roll the binary blob in preparation
<ogra_> i'll take care for PPAs soon
<ogra_> (i hope we can just make them dual build for both arm arches and be done)
<S0NiC> ogra_ wow that needs a lot of time... to build the chroot
<ogra_> S0NiC, well, it downloads all packages from the archive
<S0NiC> yes
<ogra_> then it unpacks them without using dpkg ...
<ogra_> and then it configures them by running the maintainer scripts ... in a qemu chroot each process is wrapped by a qemu call ...
<ogra_> so while thats a lot faster than running an actual qemu machine, its indeed a lot slower than if you would build an x86 chroot
<S0NiC> sounds deep in the system ;D
<ogra_> it is deep in the system ... actually on kernel level (for the wrapping of the processes)
<S0NiC> okay finished no i try to chroot
<S0NiC> okay i chrooted an now i can try to compile my program ?
<ogra_> you will want to install some bits to actually be able to compile
<infinity> ogra_: "dual build for both arches"?
<ogra_> a chroot like this is a virgin system
<ogra_> infinity, armel and armhf
<ogra_> in two runs
<ogra_> would that be very complex ?
<infinity> ogra_: Yeah, I didn't quite get what you were driving at, though.
<S0NiC> orga tahn apt-get updaten and so on?
<infinity> ogra_: PPAs get armel and armhf build records.  Just like every other arch.
<ogra_> S0NiC, apt-get update; apt-get install build-essential
<ogra_> that should get you the very basics
<S0NiC> ah thanks
<ogra_> infinity, well, the armel ones are currently limited (artificailly i think) to build armel only
<infinity> ogra_: Not entirely true.
<ogra_> S0NiC, and then indeed the -dev packages for the libs your app needs
<infinity> ogra_: There's been plenty of armhf PPA activite.
<ogra_> infinity, ah, cool, i didnt know
<S0NiC> orga thanks
<infinity> ogra_: It's only the "virtual" ones that have that strange limitation (and they're not actuall virtual, obviously)
<infinity> ogra_: It's... Messy.
<ogra_> infinity, well, we need to enable ndec's PPA for hf then so he can build us the shiny for panda :)
<infinity> Which team/ppa is that again?
<ogra_> that has a physical builder attached
<ogra_> TI
<S0NiC> ogra_ sorry for interrupt your conversation but i get an E: Unable to locate package build-essential
<infinity> ogra_: That was remarkably unhelpful.
<ogra_> ti-omap-dev is teh team iirc
<infinity> 404.
<infinity> I'm thinking not. ;)
<ogra_> S0NiC, hmm, did you apt-get update ?
 * infinity asks his panda.
<S0NiC> yes
<S0NiC> nopaste.info/e869c03242.html
<infinity> ogra_: Oh, I can't tell from looking at it what kind of PPA it is.  But it might just magically get armhf build records on the next upload.  Dunno.
<infinity> ogra_: Oh, I can't tell from looking at it what kind of PPA it is.  But it might just magically get armhf build records on the next upload.  Dunno.
<ogra_> infinity, https://launchpad.net/~tiomap-dev/+archive/release
 * ogra_ had a crash here 
<ogra_> chromium actung up usually leads to OOM at some point
<ogra_> i'll better buy a bucket to stop the leaking
<ogra_> *acting
<infinity> Or open fewer tabs.
<S0NiC> ogra_ i have to leave now, it possible to talk later to you=?
<ogra_> luckily i dont use a laptop ... so it doesnt leak on my lap ...
<ogra_> a netbook must leak to the net, right ?
<S0NiC> cu guys and thanks for the help
<ogra_> ciao
<doko> infinity, can you apply the mmap patch to the ac100 image too?
<ogra_> doko, i guess thats rather a task for janimo
<ogra_> (he maintains the git tree)
<doko> ok
<infinity> doko: Yeah, I was just enabling armhf in the packaging, jani's working on 3.x source mangling.
<ogra_> and he doesnt seem around today
<ogra_> (probably a holiday in romania)
<infinity> I believe someone said it was, yeah.
<infinity> Anyhow..
<infinity> ogra_: You have an ac100 kernel.
<ogra_> done already ?
<ogra_> geez, these pandas are so fast
<infinity> ogra_: Can't make images with it yet, cause I can't publish it until the librarian is recovered. :P
<infinity> ogra_: But you can download it from LP and install it locally and such.
<ogra_> right, i plan to roll manual builds tomorrow
<ogra_> and will then test the full image
<infinity> Builds should Just Work.
<infinity> Unless I screwed up. ;)
<ogra_> sure
<infinity> But what are the odds, right?
<ogra_> else i'll fix them
<ogra_> if they all work fine i wonder how to make them autobuild ... i fear we are getting to a point where a full set of images will take 24h :)
<ogra_> i guess we should just do some selected areches for the start
<ogra_> ac100 and omap4 or so
<infinity> Well, it's on a different machine.
<ogra_> sure sure
<infinity> And post-processing doesn't take long at all.
<Xase> How do I mount the preinstalled image again to replace the kernel, i cant seem to find it on the wiki.
<ogra_> Xase, just re-plug the card after writing it
<infinity> I bet all 4 flavours on armhf will build in about the same time as they do on armel over two buildds.
<ogra_> right
<Xase> Oh lol..
<ogra_> thats 4h per build and flavour
<Xase> Never thought about tbhat
<Xase> it's not even dd'd yet
<Xase> klol
<Xase> brb
<ogra_> so 8h for two flavours of the same subarch
<infinity> ogra_: Yes, but arches build in parallel.
<ogra_> 16 for 4 etc etc
<infinity> ogra_: My point is that armhf should be about the same speed as armel, so adding it slows nothing down.
<ogra_> it fuills the few time gaps we have Ã¶eft
<ogra_> *left
<infinity> ...?
<infinity> What?
<infinity> Parallel.
<infinity> Same time.
<aquadran> hi, i'm sure it's good place to ask here. i have issue with hdmi audio working on pandabaord with ubuntu 11.10. analog audio works. for hdmi i get 0,5 sec proper sound then it cut and nothing and only some low clicks. worked fine on 10.10
<ogra_> you can only build two in paralell
<infinity> What are you talking about? :)
<ogra_> omap4 is always built on the same builder
<infinity> armel+omap4 is.
<ogra_> we build at least four flavours of omap4 images atm
<infinity> armhf+omap4 is another machine.
<ogra_> we have new live builders ?!?
<infinity> Adding armhf slows nothing.
<infinity> Yes...
<aquadran> is there know issue for hdmi audio, i know for some it works fine
<ogra_> OH !
<infinity> Lamont and I have been debugging the armhf builder for the last two days. :P
 * ogra_ humps infinity's leg
<ogra_> i DIDNT KNOW !
<ogra_> whoops
<ogra_> i would say disregard the caps but they somehow feel appropriate :)
<lilstevie> haha
<GrueMaster> Erm, ogra_, infinity.  Kernel panic with the omap armhf netinstall kernel.
<ogra_> :(
<ogra_> when ? did you get to any console or directly on boot
<infinity> GrueMaster: Output of the panic would be nice.
<GrueMaster> Working on it now.
<infinity> GrueMaster: To see if it's the kernel's fault, or a userspace fuckup.
<ogra_> or the bootloader probably :)
<ogra_> on omap you never know
<infinity> My bet's on userspace (well, the initramfs), but I'm blindly guessing. ;)
<infinity> I haven't actually done a by-hand install yet.
<ogra_> thats why i asked about console :)
<infinity> I guess with the ti-omap4 kernel rolling, I can replace armel on my Panda with armhf.
<ogra_> yeah
<ogra_> how do we go forward btw
<ogra_> do we concentrate all efforts on armhf and leave el be el ?
<ogra_> given the state of it i would actually be in favour of that
<GrueMaster> Hmmm.  Not finding init.
<ogra_> OTOH, if we find a hard blocker we might be screwed
<GrueMaster> http://paste.ubuntu.com/761820/
<infinity> ogra_: I don't see why they're mutually exclusive.  99% of the work I've done for armhf was duplicating armel.
<Xase> will renaming uInitrd to uRamdisk be the same thing or is it different?
<infinity> ogra_: In rare cases, you need an entry for each in a rules file or something (a package that cares about float-abi), but that's 5 seconds of your time.
<ogra_> well, i wouldnt like to duplicate testing efforts etc
<infinity> ogra_: For testing efforts, that's tougher, I agree.
<Xase> Because the u-boot on the nook color looks for uRamdisk
<GrueMaster> Xase: ???
<Xase> not uInitrd
<GrueMaster> Ah.  Should
<infinity> ogra_: Testing effectively 8 arches instead of 4 is daunting.
<rcn-ee> GrueMaster, i'm seeing that same with Debian Sid armhf with mainline.. ;)
<ogra_> infinity, plus the work janimo does on live images :) thats one more
<GrueMaster> rcn-ee: ouch.
<ogra_> and likely really slow
<infinity> GrueMaster: Okay, I'll replace armel with armhf on my Panda today and figure out WTF that's all about.
<GrueMaster> ogra_: I thought the live images were manually built for the moment.
<infinity> GrueMaster: It's almost certainly userspace.
<ogra_> GrueMaster, yes, currently
<ogra_> infinity, i'm not sure
<GrueMaster> As to image testing, I am working hard to get a lot of it automated.  All the headless testing should be automated by EOY.  That leave me with desktop to manually muck about.
<infinity> ogra_: I did say "almost".
<ogra_> "Trying to unpack rootfs image as initramfs..."
<Xase> Lessee if udev crashes like crazy this time.
<ogra_> thats usually the line before "freeing init memory"
<GrueMaster> Although I will be short non-omap4 platforms for automated installs.
<ogra_> i dotn see it in tobins paste
<Xase> Nope... it seems to be working :D
<Xase> YAY
<Xase> Mouse
<Xase> ubuntu on Nook Color with a mouse :p
<ogra_> GrueMaster, well, omap4 should soon be netinstallable on hf too
<Xase> Nothing else so far =/
<Xase> Probably something else broke...
<GrueMaster> Or equally broken.  :P
<infinity> GrueMaster: Does current omap netinstall work on armel?
<infinity> GrueMaster: Cause the kernel's identical.
<Xase> but if it got past the kernel loading, I should now be able to retrieve some sort of log from the SDCard right?
<Xase> Oh wait
<GrueMaster> I wonder if the switch to no initrd has anything to do with this breakage?
<Xase> Its still doing its thing
<ogra_> Trying to unpack rootfs image as initramfs...
<infinity> GrueMaster: That should be the nail in the coffin.
<ogra_> hmm
<Xase> Guest Session login ;)
<GrueMaster> Will try armel.
<ogra_> no error though
<Xase> Hmmm. Ghetto. The touchscreen is nil working
<GrueMaster> Xase: You have an ubuntu image on nook color????  COOL!!!
<GrueMaster> Well, aside from touch.
<Xase> Yeah, it needs cypress truetouch...
<Xase> Hmm
<Xase> I'm using Dalingrin CM sources plus some patches from a  mer developer.
<Xase> But mer dies while loading udev.
<Xase> Figured it'd continue on the Ubuntu image
<Xase> Because the suspect in the Mer case is bad dding
<Xase> However now it's time to see if I can recompile with TrueTouch in menuconfig :D
<ogra_> GrueMaster, "switch to no initrd" ? do you refer to my spec ? nothing has been done for that yet
<ogra_> so no worries
<Xase> make ARCH=arm menuconfig right?
<ogra_> i guess apw will explicitly tell us if he (potentially) breaks the world
<GrueMaster> Ok, something broken on the hf image.  I'm in netinstall on armel on omap.
<ogra_> k
<ogra_> lets wait for omap4
<ogra_> and see if thats omap3 specific
<Xase> GrueMaster: the ubuntu image doesn't seem to see battery... something having to do with Kernel?
<ogra_> rcn-ee, you dont happen to know a workaround ?
<apw> GrueMaster, odd indeed as the armel and armhf should basically be the same bits
<GrueMaster> Xase: Possibly.  Not sure, since I haven't had time to muck about on my NC.
<Xase> also I  need SGX530, can I chroot into the ARM image from my machine and apt-get install that way?
<ogra_> apw, well, compiled differently
<ogra_> (theoretically that shouldnt have any impact indeed .... theoretically ...)
<apw> ogra_, well not really the only change is the float interfaces, and they kernel doesn't use float ever
<rcn-ee> ogra_, nope, debugging it too right now..  what's weird, it worked fine with the "debian unstable armhf" (sep time frame) repo's.. so something changed between that timeframe and the current sid repo.
<ogra_> yeah
<apw> kernel normally panics if you do use float as the fpu isn't available
<ogra_> well, it doesnt seem to be the kernel
<ogra_> and by the looks of it even the initrd is fine
<apw> ogra_, well that is something at least
<ogra_> it just chokes on "no init found"
<apw> hmmm ... maybe we have no upstart
<Xase> Hrmmm...
<rcn-ee> GrueMaster, if it helps, my old armhf image is still available: http://elinux.org/BeagleBoardDebian#armhf_Demo_Image
<Xase> Truetouch is enabled in my kernel already...
<Xase> but I'm getting no response from the screen.
<ogra_> i dont think d-i uses upstart
<ogra_> (unless it has been ported recently)
<apw> oh alternative cds are they, i was assuming live
<ogra_> netinstall
<ogra_> easiest to test :)
<apw> could be a heap of things, do you have the network drivers in your initrd for instance
<ogra_> it loads all fine, see the paste of the dmesg output
<GrueMaster> What (if any) config changes to the kernel are in the armhf rev?
<ogra_> GrueMaster, none
<GrueMaster> apw: See my pastebin.
<ogra_> its just a rebuilds for armhf
<ogra_> *rebuild
<apw> its configuration is identicle between armel and armhf
<infinity> The kernels should be almost literally identical.
<GrueMaster> ok
<infinity> I'm sure the issue is userspace.
<ogra_> probably d-i's init uses floating point :P
<infinity> No.
<ogra_> yeah, i know
<infinity> My bet's on initramfs-tools, and possibly the interpreter not landing in the initramfs.
<ogra_> well, lets see how desktop images behave tomorrow, could as well be a d-i issue
<infinity> I haven't actually built an initramfs on armhf yet.
<ogra_> d-i doesnt use initramfs-tools, does it ?
<GrueMaster> I think it does.
 * ogra_ thought it uses cpio and whatever compressor directly 
<ogra_> as it doesnt use upstarts init
<infinity> It might do.
<ogra_> so i would rather like to wait until we have desktop images and compare with that
<GrueMaster> We have core, right?  I could muck something together that way.
<infinity> 	initramfs) \
<infinity> 		  (cd ./tmp/omap_netboot/tree && find . | cpio --quiet -o -H newc) >  ./tmp/omap_netboot/initrd; \
<infinity> 		gzip -v9f ./tmp/omap_netboot/initrd; \
<ogra_> yeah
<infinity> So, how it's populating that will be interesting.
<ogra_> from udebs indeed
<ogra_> intresting would also be what init it uses
<infinity> My bet's still on the linker.
<GrueMaster> Could it be busybox?  How do I differentiate between armel and armhf versions?
<infinity> Let me tear apar this initrd.
<ogra_> hmm. good question, the file command doesnt know the difference
<ogra_> at least not with std output
<infinity> adconrad@cthulhu:~/ung$ cat initrd | cpio -t | grep ld-linux
<infinity> lib/ld-linux.so.3
<infinity> And that's the problem.
<infinity> I figured.
<infinity> Now to see if that's the udeb's fault, or d-i's build process.
<GrueMaster> diff initrd/bin/busybox busybox/usr/lib/initramfs-tools/bin/busybox
<GrueMaster> Binary files initrd/bin/busybox and busybox/usr/lib/initramfs-tools/bin/busybox differ
<infinity> GrueMaster: Of course they differ.
<ogra_> indeed
<infinity> GrueMaster: But the problem is above.
<infinity> Linker in the wrong place.
<GrueMaster> Where should it be?
<infinity>  /lib/arm-linux-gnueabihf/ld-linux.so.3
<GrueMaster> in the initrd?
<GrueMaster> Seems odd.
<infinity> Yes.
<infinity> And it's my fault.
<infinity> The udeb has it in the wrong location.
<GrueMaster> Ok.
<infinity> eglibc upload incoming. :/
 * GrueMaster points blame.
<GrueMaster> :P
<GrueMaster> In the meantime, I'll reassemble this and tally forth.
<ogra_> awesome, that means desktop images wont be affected :D
<infinity> Can you manually mangle the initrd to move ld-2.13.so and ls-linux.so.3 to that path?
<ogra_> why not
<ogra_> you can cat cpio archives together, the one you append acts like an overlay
<infinity> I meant to be asking GrueMaster to try that. :P
<infinity> Not asking if it was possible.
<GrueMaster> I have a couple of scripts for exploding and reassembling initrd.img
<infinity> GrueMaster: If you can move those two files (and make sure the symlink still resolves), and try again?
<ogra_> so just pull both files out, roll a cpio archive witgh them in the right place, and just cat it at the end of the existing cpio initrd ... then compress it again
<GrueMaster> ogra_: Don't over-complicate things.
<ogra_> GrueMaster, huh ?
<GrueMaster> Easier for me to reroll with my existing scripts.
<Xase> So... I have my touch driver enabled in kernel... however, I don't know how to get xorg to use it.
<ogra_> thats way faster than unpacking everything and re-rolling the whole thing
<GrueMaster> ogra_: On a Core2Quad running at 3ghz?  Speed is not the issue.
<ogra_> k
<GrueMaster> (actually takes longer for this discussion).
<GrueMaster> infinity: Not seeing ld-2.13.so.
<ogra_> grab it from a -core image ?
<infinity> GrueMaster: It's in lib...
<infinity> GrueMaster: I see it here.
<infinity> Oh.
<infinity> No.
<infinity> I'm looking at the udeb.
<ogra_> IT SHOUDL ALSO BE IN /LIB/TRIPLET/
<ogra_> argh
<ogra_> sorry
<GrueMaster> No /lib/triplet directory.
<infinity> Yeah, nevermind.  d-i canonicalises the paths, so no ld-2.13.so
<ogra_> lib/arm-blah-foo-bar
<infinity> ld-linux.so.3 is a real file, not a symlink.
<infinity> So just move that.
<Xase> Bah.
<infinity> GrueMaster: You have to create the directory, it's not there. :P
<infinity> GrueMaster: /lib/arm-linux-gnueabihf/ld-linux.so.3 is where that one file needs to live.
<ogra_> GrueMaster, lib/arm-linux-gnueabihf/ that is :)
<GrueMaster> I know that part.  I was just looking for the other file.
<infinity> Yeah, the other file isn't on the initrd.
<infinity> On a real system, ld-linux.so.3 is a symlink to ld-2.13.so, in the initrd, ld-linux.so.3 *is* ld-2.13.so.
<GrueMaster> Had me worried.  find was returning nothing in the initrd.
<GrueMaster> Thought this was horribly broken.
<infinity> Also, glibc's udeb building is making my eyes cross.
<GrueMaster> ogra_: time pack-initrd initrd.img initrd
<GrueMaster> real    0m1.341s
<GrueMaster> user    0m1.340s
<GrueMaster> sys     0m0.076s
<GrueMaster> Just fyi.
<ogra_> yeah yeaqh
<GrueMaster> :P
<ogra_> :)
<GrueMaster> Much better.
<ogra_> boots through `
<ogra_> ?`
<GrueMaster> I'm in the installer.
<ogra_> yay
<infinity> \o/
 * ogra_ goes afk for an hour or so
<GrueMaster> grrrr.
<GrueMaster> I'm being hit by bug 838200 (not an armhf issue).
<ubot2> Launchpad bug 838200 in u-boot-linaro "No network support on Beagle XM" [High,Confirmed] https://launchpad.net/bugs/838200
<GrueMaster> Ok, moving forward again.
<Xase> o.o
<GrueMaster> Yea.  seems to only affect me, as I have a rev B beagleXM.  Rest of the world is on rev C.
<GrueMaster> Hrm.  "No installable kernel was found in the defined APT sources."  Might need to fix this in d-i.
 * GrueMaster can preseed around it for now.
<infinity> That sounds like an oops.
<GrueMaster> I think d-i has hardcoded arches.
<infinity> It does.
<infinity> I suspect Colin just missed a spot or something.
 * GrueMaster facepalms
<infinity> Let me guess, it's using archive instead of ports?
<GrueMaster> No, actually it is using my local mirror.
<GrueMaster> But it is updated every 2h, so that shouldn't be the issue.
<GrueMaster> I think I had to do the same thing for omap4.  I know I have the linux-omap4 meta listed there.
<rcn-ee> sweet, the /lib/ld-linux.so -> /lib/arm-linux-gnueabi fixes debian sid armhf.. ;)
<infinity> rcn-ee: Yeah.  Working on fixing eglibc now, will push to Debian too.
<rcn-ee> thanks infinity! was about to just figure out where to submit the bug.. ;)
<Xase> is there a sample xorg.conf or some way of telling xorg to use evtouch?
<Xase> No one? :(
<GrueMaster> Xase: You might be better asking that in #ubuntu-desktop.  I think all the xorg guys hang out there.
<Xase>  ok
<GrueMaster> infinity: Rebooting into armhf.  Fingers crossed.
<infinity> GrueMaster: If it installed, I'm confident it'll boot. ;)
<infinity> (eglibc uploaded and building)
<GrueMaster> Grr.  I hate that it sits and spins waiting for a network.  On this broken system, means I have to manually unplug/plug in the cable for link detect to work.
<GrueMaster> Still waiting on something in init to finish.
<GrueMaster> It is pingable, but no getty so far.  Will need to enable console logging in the boot.scr to see what is borked.
<GrueMaster> Do I need the updated eglibc or something?  It is hanging after "Starting configure network device".  System is pingable, but no login.
<infinity> Nope.  Not eglibc's fault there.
<GrueMaster> ssh appears to work, but no shell.
<infinity> No shell sounds ominous.
<GrueMaster> ssh logs in, lays out the welcome mat, then closes.
<GrueMaster> Hrm.  Appears there is no /bin/bash
<infinity> That seems rather unlikely...
<GrueMaster> Nothing stands out in syslog.
<GrueMaster> I have the rootfs drive on my PC now, so I can root arount.
<GrueMaster> *around
<Xase> Well that's pretty useless no one helpful with X seems to be in #ubuntu at the moment
<GrueMaster> Xase: Some of them may be on vacation.
<Xase> just my luck.
<Xase> I'm unsure why the already there evdev rules don't catch the screen
<GrueMaster> It could need to be updated with your device info, and an xorg.conf file could work around it.  I am just not sure how to do that.
<Xase> Well if I even try to add anything to a new rules file or an xorg.conf ubuntu fails to boot.
<Xase> meh.
<GrueMaster> Hmmm.
<GrueMaster> Do you get an Xorg.0.log when you change the config or rules?
<Xase> Well I have to change it on the sdcard but I'll check, I have no other way to input besides the non working touch screen ;)
<Xase> Where would it exactly be located?
<GrueMaster> Yea, I know (I have a Nook Color as well).
<GrueMaster> Should be in /var/log
<Xase> Nope it's blank.
<Xase> I'm sure I'm editing them wrong anyways.
<GrueMaster> Odd.
<Xase> It gives me a very specific error
<GrueMaster> It should at least complain.  Anything in /var/log/sysog?
<Xase> When I mess with xorg it gives this during boot.
<Xase> (stk) :line disc installation timed out
<Xase> ti_st_open: st_register failed -22
<GrueMaster> That looks like a bluetooth error.
<Xase> Ah.
<Xase> So I'm seeing something normally hidden by x
<Xase> Then boot isn't crashing
<Xase> X just isn't loading
<Xase> I'm definitely editing things wrong :D
<Xase> Nothing in syslog about x11 or xorg
<GrueMaster> I just got a link from one of our devs.  https://help.ubuntu.com/community/EloTouchScreen
<Xase> o.o
<GrueMaster> Although he also says evtouch is obsolete.
<Xase> yeah apparently just evdev is used
<Xase> So try evtouch?
<GrueMaster> I can't really answer.  But the link has some good pointers at least.
<Xase> well I have no clue how to do that. as I have no idea how to chroot into this sdcard since it's arm.
<GrueMaster> What are you using for a base image?
<Xase> Ubuntu Preinstalled Omap3
<GrueMaster> I don't know if the gadget port can be enabled or not, but if you could figure that out, you might be able to get a serial console working.
<Xase> Someone else I'm working with had issues...
<GrueMaster> Also, the preinstalled image will be a bit more difficult, as it resizes the rootfs and launches oem-config.
<Xase> Hmm
<GrueMaster> but if you are able to boot this far, there is a lot that can go forward.  I don't know how to do it, but I'm sure you could use qemu to chroot into the image for adding packages and such.
<janimo> infinity, thanks for the armhf/ac100 bits, I'll add them to the packaging git tree (also I'll check if zinc is still alive in the meantime for user kernels trees)
<Xase> would... syslog show what devices were detected at startup GrueMaster ?
<GrueMaster> I would think so.  You could also edit one of the init scripts (/etc/init.d) to execute some discovery commands that pipe to a log file.
<Xase> alright
<Xase> sort of lshal >> /var/log/lshal
<Xase> ?
<GrueMaster> Can you give me a link to your kernel?  I'll try to muck with it a bit here in my spare time this week.
<GrueMaster> Yea, something like that.
<Xase> Sure, just my uImage?
<GrueMaster> Actually, I would need that and any modules.  Or are they all built-in?
<GrueMaster> Better still, if you can give me a dd of your sd boot partition, that would give me everything I need.
<Xase> All bubuilt in sure
<GrueMaster> dd bs=4M if=/dev/mmcblk0p1 |gzip boot.img.gz
<Xase> ok I was just about to ask.
<Xase> o.o
<Xase> gzip: boot.img.gz: No such file or directory
<GrueMaster> Oops.  dd bs=4M if=/dev/mmcblk0p1 |gzip >boot.img.gz
<GrueMaster> Missed the >
<GrueMaster> my bad
<GrueMaster> infinity: Any hints for what to look for as to why the beaglexm won't boot all the way in armhf?
<infinity> GrueMaster: Not sure off the top of my head.
<GrueMaster> I can chroot into the image (using a preinstalled-server image).
<infinity> GrueMaster: But I'm going to fiddle on my panda in a bit.
<GrueMaster> Fiddler on the Root.
 * GrueMaster is in a weirdish mood today.
<Xase> Hold on.
<janimo> infinity, do you know what's with many FTBFS (today at least) not having build logs available?
<Xase> GrueMaster:  data.excloo.com/~jase/boot.img.gz
<GrueMaster> Cool, got it.
<Xase> Fack I can't remember how to add a host to known_hosts
<GrueMaster> On your desktop?  Which release?
<Xase> I have debian to be honest =/
<Xase> I'm trying to ssh into my ipod
<Xase> ad it's omplaining about it... probably because I downgraded its firmware
<GrueMaster> I usually just delete the offending key entry.
<Xase> Yeah
<Xase> That's what I just did.
<Xase> man sftp is frustrating
<infinity> janimo: The librarian is down.
<infinity> janimo: Or, rather, was.  It's being recovered.
<janimo> infinity, I had moments today when it worked so I was not sure if it is down or just being flakey atm
<janimo> it being LP, I do not know of intricacies such as the 'librarian'
<infinity> janimo: The librarian is the massive back-end filesystem where large things that aren't database bits are kept.
<infinity> janimo: packages, logs, etc.
#ubuntu-arm 2011-12-07
<Xase> GrueMaster: I think I figured something out.
<Xase> I think the current "NookBuntu" on XDA Developers is also using EvTouch.
<Xase> And something titled tslib
<lilstevie> Xase: is that NookBuntu using an older version of ubuntu?
<lilstevie> because that seems rather overkill for natty+
<Gioyik> HI..
<Gioyik> I have a question...
<Gioyik> I'm interest in use rootstock..
<Gioyik> and my question is..
<Gioyik> if i modify the OS host.. (Ubuntu)
<Gioyik> with new packges and wallpapers..
<Gioyik> when i build the arm image with the rootstock..
<Gioyik> that changes apply for that build?
<Xase> lilstevie: I thing it's actually a hybrid of ubuntu and Angstrom though not sure.
<twb> Xase: what could POSSIBLY go wrong
<Xase> Several parts say Angstrom... but it looks like and is advertised as ubuntu
<Xase> I think I'm going to build me a root fs from scratch so I can install the deprecated evtouch...
<Xase> Since there are rules for it in that nookbuntu lilstevie
<Xase> Even single touch would be a step in the right direction
<Xase> I think I should install Ubuntu... I'm tired of Debian =(
<Xase> A lot of my packages are broken.
<Xase> I converted a Crunchbang Statler/Squeeze to Wheezy.
<twb> Xase: testing or- yeah, well, if you run testing you get to keep both halves
<Xase> twb: I'm an idiot, can you clarify that sentence.
<twb> testing breaks a lot
<Xase> Ah, a joke?
<twb> If you can't deal with that you're not supposed to run testing
<Xase> Oh I can.
<twb> Xase: yes the line is "with open source, when it breaks you get to keep both halves"
<Xase> The breakage is mainly from converting.
<twb> Fair enough
<Xase> Testing is actually really nice... though I really wanna give Unity another go now that 11.10 is out.
<Xase> Ubuntu is great... but so is Debian... but so is Linux in general.
<twb> Bleh
<Xase> I flip flop a lot.
<Xase> Not a unity fan?
<twb> I'm not a fan of much of anything ubuntu has done to debian
<Xase> I've been digging gnome 3.0, but I'm still partial to open box/xfce
<Xase> :p
<twb> In particular upstart as at lucid routinely fucks me up the arse, no lube
<Xase> lol
<Xase> Not a ubuntu fan in general.
<Xase> ?
<Xase> s/?/./
<Xase> I really need to practice regexps more :(
<Xase> I'm slacking in my auto-didactic ruby learning :(
<twb> Well, I will cheerfully take Ubuntu LTS if the alternative is RHEL or SLES or SCO or Solaris or W2k8 or ...
<Xase> My main dither is I don't have a seperate home partition...
<Xase> So installing Ubuntu kills all my files... unless I dual boot, copy crap over and chmod/chown a lot of crap.
<Xase> And then kill my debian install.
<Xase> Meh, I'd just upload the important stuff if my upload speed wasn't like 0kb/s
<twb> If your /home isn't separate from the OS, you deserve anything that happens to you
<Xase> I normally do have a seperate home, but I had a two year old clinging to my back at the moment, and couldn't focus on much of anything.
<Xase> The only thing I managed to make separate was /boot
<twb> That's why you hang them on the coat hook by their overalls
<Xase> Do Dresses work as well?
<twb> Dunno
<Xase> I think I'd murder the family member to give my daughter overalls.
<Xase> Reminds me of my Grandaddy... who always mows the lawn once a week in just overalls.
<Xase> No shoes, socks, underwear or shit...
<Xase> shirt*
<Xase> just overalls.
<twb> She's two, she probably rolls around in mud and stuff, overalls sound practical to me
<twb> Or maybe not overalls but a jumpsuit like a mechanic or a pilot wears
<Xase> Nah, she's sophisticated, she can navigate the ipod, the nook color, and my Inspire, and her mother's laptop.
<Xase> She's a tomboyish dress wearing nerd in growth :D
<twb> That doesn't preclude mud
<Xase> Man she's got a mouth.
<Xase> The only time she gets near mud is when she's kicking it at ya'. :p
<twb> I don't have a good solution re. mouth, except maybe wearing noise-cancelling headphones
<Xase> Eh I only have a x86 install disc =/
<twb> PXE FTW
<Xase> She is the noise cancelling headphones...
<Xase> You know... I've never given PXE a try...
<Xase> Give that baby netflix... and out!
<Xase> Yeah but don't I already have to have something serving the media @ twb ?
<twb> EH?
<twb> Oh, yeah, you need a PXE server
<Xase> I'll just go minimal...
<Xase> I'll just redownload all my crap, though it will take a lengthy ass time over my connection :D
<Xase> o.o
<Xase> Really lengthy.
<Xase> It'd be faster to just download the whole CD...
<twb> Whatever
<Xase> Too bad I can't bypass my ISP and use my shell's internet as my internet :D
<Xase> 20mbits would be nice
<twb> "your shell" ?
<Xase> I have a shell account provided by a friend on their data server.
<twb> Oh right.
<Xase> I use it for irssi, and stuff.
<twb> Sure, just use sneakernet between there and you
<twb> apt-walk or debmirror or so
<twb> 20mbps is only about standard ADSL2+ speed, tho.
<Xase> Sneakernet doesn't quite cut it over two oceans.
<twb> :P
<Xase> Man I forgot the line to check bandwidth via ternminal
<lilstevie> Xase: the depreciated package is a little overkill
<lilstevie> it is depreciated cause it was rolled into evdev AFAIK
<S0NiC> hi guys
<S0NiC> ogra_ are u there? ;)
<ogra_> S0NiC, yes, whats up ?
<S0NiC> ogra_ do you know rootstock?
<ogra_> i wrote it ...
<ogra_> its obsolete
<S0NiC> more obsolete than this https://wiki.ubuntu.com/ARM/BuildEABIChroot?
<ogra_> same level :)
<S0NiC> ah ok, i have two questions
<XorA> lilstevie: the same dude thats ubuntu on transformer?
<S0NiC> 1. is armv5tel compatible to arm7?
<S0NiC> sounds no. right?
<XorA> ubuntu doesnt have an armv5 build :-(
<ogra_> not sure, check wikipedia ... i thougth v5tel was arm11 but i'm usually wrong with the old stuff (and we dont support it anywhere anyway)
<xranby> can we reduce the default thread stack size in glibc from 8MB to say 2MB or less...? i find it waste of resources on arm to fill up the 512Mb of memory by simply starting some programs that are totally running 64 threads on the system
<S0NiC> ogra_ ill check it
<ogra_> S0NiC, well, wrt ubuntu it wont gain you anything, we only support armv7, cortex-a8 and upwards
<S0NiC> ogra_ armv7 is what i need
<ogra_> well, i was just wondering since you asked about v5 above
<S0NiC> what you recommend?
<ogra_> ??
<ogra_> for pre-cortex-a8 you mean ? use debian, they support older SoCs
<S0NiC> ogra_ how i get a toolchain with armv7, i tried https://wiki.ubuntu.com/ARM/BuildEABIChroot? and uname -m tells me armv5tel
<S0NiC> thats why iam wondering
<ogra_> then you muss use a very old release in your chroot
<ogra_> we dont have any supported release for pre-v7
<S0NiC> did you remember we did this yesterday? and you told me that is deprecated
<ogra_> karmic and jaunty used to support older HW but both of them are EOL
<S0NiC> ogra_ ok, how i get a toolchain running arm7. thats the question
<S0NiC> :)
<ogra_> (and we only supported them because immediately switching to v7 was to hard)
<S0NiC> ah ok
<ogra_> use a decebt release for your chroot ...
<ogra_> *decent
<S0NiC> and what you recommend? sorry i have no plan ;_7
<lilstevie> XorA: yes, I am he
<XorA> lilstevie: sweet, one day I shall stop travelling without my Transformer and actually get it installed
<ogra_> S0NiC, take natty its the last stable release, fully supports v7 and has the longest life cycle
<lilstevie> XorA: hehe, I hope on making the process even easier soon :)
<S0NiC> ogra_ ok ill download it, and how can i get a funcitionally toolchain?
<XorA> lilstevie: complex Im not worried about as Im an embedded linux guy, but the transformer always being 1000s of miles from my hand is an issue ;-D
<ogra_> S0NiC, its is inside there ... you just install the build-essential package
<XorA> lilstevie: BTW what PMIC is in Transformer do you know?
<S0NiC> ogra_ thanks. you mean this Ubuntu 11.04 right? is der any stuff i can read especially for this?
<ogra_> S0NiC, just use qemu-debootstrap like you did yesterday
<S0NiC> ogra_ ill try ;D
<lilstevie> XorA: good question :p
<lilstevie> XorA: I am really only on the surface still
<lilstevie> still a lot of work to go before it is 100%
<XorA> lilstevie: its not one of my PMICs
<XorA> found it in teardown
<lilstevie> heh
<lilstevie> well I haven't noticed any driver issues with the PMIC anyway
<lilstevie> it wakes up fine, just the framebuffer that doesn't
<XorA> PMIC probably 90% controlled by its internal power sequencer anyway
<lilstevie> yeah
<lilstevie> my only problem with sleep/wake is the framebuffer not coming back up correctly
<S0NiC> q
<S0NiC> ogra_ can i bother you again? ;)
<ogra_> sure
<S0NiC> i have to install qemu-arm-static again=?
<S0NiC> i only bootet now ubuntu 11.04 in my vm
<S0NiC> booted
<ogra_> qemu-user-static is the actual name since a few releases
<S0NiC> ah ok thx
<ogra_> and from that use qemu-debootstrap like yesterday
<ogra_> with suite set to natty
<S0NiC> that was what i thought. thx
<S0NiC> qemu-debootstrap --arch armel --suite natty illl try this
<ogra_> not --suite
<ogra_> qemu-debootstrap --arch armel natty <target dir>
<S0NiC> ogra_ i trie
<S0NiC> try
<S0NiC> ogra_ then i can do "sudo chroot <mydir>?
<ogra_> right
<S0NiC> and the i do update? and after that built-essentials?
<doko> ogra_, what tags are used for armhf ftbfs issues? stll arm-porting-qeuue?
<ogra_> doko, ask rsalveti :) i never use tags for that, i usually just pick from ubuntuwire
 * ogra_ finds using bugs for ftbfs overkill 
<rsalveti> doko: yes
<S0NiC> ogra_ iam here again...  i cant update/install anything, i get the following error: http://nopaste.info/1edf6eb8ad.html
<ogra_> S0NiC, check /etc/pat/sources.list
<ogra_> */etc/apt/sources.list
<S0NiC> mom
<S0NiC> ogra_ its empty
<ogra_> k
<ogra_> add the following line to it
<ogra_> deb http://ports.ubuntu.com/ubuntu-ports natty main restricted universe multiverse
<ogra_> then run apt-get update again
<S0NiC> if i try ifconfig i get this ifocnfig Warning: cannot open /proc/net/dev (No such file or directory). Limited output. SIOCGIFCONF: Bad address maybe this is a point?
<ogra_> that should give you the packages
<S0NiC> ok
<S0NiC> ah now it works
<S0NiC> thx
<ogra_> :)
<S0NiC> that are problems, i have no idea where i have to search for an solution... ;(
<ogra_> well, thats basic knowledge about .deb based systems
<ogra_> not even ubuntu specific
<S0NiC> i only run gentoo ;)
<S0NiC> update / upgrade is done
<S0NiC> now i try to install  build-essential
<S0NiC> ok worked
<ogra_> and then you want the -dev packages for the libs your app links against :)
<S0NiC> and hopefully it worked after that ;D
<S0NiC> ogra_ http://nopaste.info/9ea21b319d.html i get an ARM file... hope it works...
<S0NiC> cross your fingers ;)
<ogra_> good luck :)
<xranby> ogra_: no armhf image sin http://cdimage.ubuntu.com/daily-preinstalled/current/ ?
<xranby> im looking for a pandaboard armhf omap4
<ogra_> xranby, patience !
<ogra_> ac100 just finished, i'll start omap4 soon
<xranby> ogra_: ok, patence lasted ~10 min this time..  will the ac100 image appear at the daily-preinstalled location?
<ogra_> yes, once the post processing is done ...
<ogra_> the livefs build succeeded, waiting for the second part to finish atm
<ogra_> its my first testbuild ... might be that it has issues
<xranby> ogra_: i appreciate the work you do.
<xranby> will occupy myself with  browsing through and triage armhf bugs while i wait
<ogra_> hmm, it finished
<ogra_> but i dont see it being mirrored
<ogra_> http://cdimage.ubuntu.com/daily-preinstalled/20111207.1/ shoudl theoretically have an armhf image for ac100
<xranby> which package maintains contains the imager's code?
<ogra_> some of it isnt public
<ogra_> generally its the cdimage and the debian-cd projects
<ogra_> nope. no trace of armhf anywhere
 * ogra_ tries something else
<ogra_> re-running the second part of the build
<ogra_> with some different options
<ogra_> (that will take about 30min)
<ogra_> AAAND !!! THERE WE GO !!!
<ogra_> omap4 started
<ogra_> xranby, ^^^
<xranby> \o/
<ogra_> should be ready in about 2.5-3h
<xranby> too bad i cant text you a beer... so here have a â
<ogra_> *slurp*
<ogra_> :)
<S0NiC> ogra_ IT WORKS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ;D
<ogra_> congrats :)
<ogra_> seems to be a good day for everyone today
<S0NiC> ogra_ it was a good idea to join this channel, your help was awesome ;)
<S0NiC> many many thanks
<S0NiC> !
<ogra_> youre welcome :)
<ogra_> hmm, intresting, the hf image is 20M smaller than the armel one
<ogra_> janimo, did you notice that adam added hf support to the ac100 package ? it not merged into git ...
<ogra_> *it is
<janimo> ogra_, I noticed, yes
<ogra_> so before going to 3.0 please merge :)
<janimo> looked at the quite impressive diff
<janimo> I need to merge it to git tree of course before 3.0
<janimo> :)
<ogra_> beyond that see above, ac100 armhf image is available ;)
<janimo> yup :) nice
<janimo> looking forward to drop all armel images :)
<ogra_> yeah
<ogra_> i'm really curious why hf is so much smaller though
<doko> btw, libreoffice needs some porting work. won't continue with this myself
<doko> ogra_, well, compare some single packages
<ogra_> doko, we lost about 20MB
<ogra_> quite impressive
<janimo> doko, I plan to look at Libo armhf myself
<doko> ogra_, I don't think this is all code
<ogra_> probably not
<doko> janimo, see bug #900636
<ubot2> Launchpad bug 900636 in libreoffice "libreoffice ftbfs on armhf" [High,Confirmed] https://launchpad.net/bugs/900636
<ogra_> i'm to lazy to compare the manifests before testing
<ogra_> will do that later ...
<janimo> doko, thanks for the diff. I suspect I'll have another few days of 'fun' with libo source tree
<ogra_> it didnt error out or anything during the live build phase so there cant be anythng missing, whats seeded will be installed
<doko> janimo: I think it's only the bridge, passing the arguments in floating point registers
<janimo> ogra_, does the amrhf gcc have different build option defaults than armel?
<janimo> doko, indeed, uno bridge assembly and stack wizardry
<ogra_> not that i know of
<ogra_> beyonf the vfp stuff indeed
<doko> no, just -mfloat-abi=hard
<janimo> ogra_, could be we have some optional package deps somewhere which only are active for armel?
<janimo> so for armhf they are not brought in?
<ogra_> shouldnt be anymore
<ogra_> we used to ... banshee etc
<ogra_> but that was all dropped
<ogra_> well, something to examine later
<doko> could be; currently we only did fix building package to build on armhf, which only built on armel
<ogra_> lets see how omap4 looks like
<GrueMaster> Can we get started on a netinstall image for mx5 soonish?  It will help for future testing, and a lot of people with sata will be pleased.
<ogra_> GrueMaster, do we have the hf kernel yet ?
<ogra_> i dont think we do until linaro uploads the change
<GrueMaster> No, but we have an armel kernel since Oneiric.
 * ogra_ is afke for a moment
<GrueMaster> We can at least get the prelim work done so when there is a HF kernel, we're ready for it.
<ogra_> GrueMaster, oh, netinst ... i guess that wont work, d-i needs the kernel in main iirc
<ogra_> anyway, back soon
<GrueMaster> For all armel platforms, the kernel needs to be preseeded anyway.
<janimo> doko, what is a good example of a package that has armhf and armel separate codepaths with ifdefs (or whatever is necessary) ?
<GrueMaster> janimo: If you are looking at the size diffs between packages, it could simply be less instructions needed to perform the same operation determined by the compiler.
<doko> janimo, I think you would need to look at the sources control file for things like [armel] in dependencies. you won't see this in the packages file
<doko> janimo, infinity has a modified suite-diff.py which we used to find packages not built on armhf at all. but this won't help much for universe until most of the archive is built
<doko> ogra_, so what is the status about the ac100 images?
<xranby> doko: ac100 armhf image status https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/901315
<ubot2> Launchpad bug 901315 in ubiquity "crash during background user creation during ac100 armhf precise installer" [Undecided,New]
<ogra_> doko, ubiquity is broken, but all other bits seem fine (the bug was apparently sent using firefox :) )
<ogra_> GrueMaster, preseeding isnt the point ... d-i only uses main during its own build afaik ... you need vmlinuz from the .deb to actually roll the netinst images
<xranby> yes i have sent it using firefox from inside the armhf precise userspace
<ogra_> yay
<ogra_> bah, but the omap4 image failed to build :(
 * ogra_ checks why
<ogra_> geez, language-selector explodes
<ogra_> Setting up hunspell-en-us (20070829-4ubuntu2) ...
<ogra_> Error: update-openoffice-dicts not present or executable. Missing dependency on
<ogra_> dpkg: error processing hunspell-en-us (--configure):
<ogra_>  subprocess installed post-installation script returned error exit status 1
<ogra_> No apport report written because MaxReports is reached already
<doko> ogra_, a new ubiquity is still building ...
<doko> * Add armhf support.
<ogra_> yeah
<ogra_> the hunspell thing looks weird though
<ogra_> 3h before the ac100 build succeeded and i dont think the packages changed in that area
<xranby> janimo: jamvm in openjdk have separate code paths  http://git.berlios.de/cgi-bin/cgit.cgi/jamvm/tree/src/os/linux/arm/callNative.S
<NekoXP> GrueMaster, there's no work required to get an armhf kernel running, the kernel is agnostic as to floating point ABI
<ogra_> NekoXP, it needs to match dpkg
<NekoXP> you just need to change the arch in the packager
<ogra_> which means a rebuild
<GrueMaster> Yes, I figured as such.  More a case of adding support for register dumps during task switches and what-not.
<NekoXP> GrueMaster, no support at all, kernels don't need to change for armhf no matter what
<GrueMaster> I don't know enough about arm architecture, but I would be surprised if it didn't need a little support added for context switching (same as SSE* on x86).
<NekoXP> if it supports floating point units at all, it will dump them as it always did, there's no userspace<->kernel ABI difference as floating point registers can't be used for syscalls
<NekoXP> it's there for softfp
<NekoXP> you have to save floating point registers regardless, but for hardfp userspace gets to *pass arguments* in floating point registers
<NekoXP> but that's only if you're passing a float or double, you can't pass floating point to the kernel
<GrueMaster> Still, if the kernel isnt building for armHF, then some work needs to be done, even if it is only at the package build level.
<NekoXP> right. that said, I would really really like to see someone take the initiative and decouple the kernel arch from the userspace arch :)
<NekoXP> surely dpkg could be modified to have knowledge of a "suitable kernel architecture"...
<GrueMaster> It is more than just dpkg.  A lot of other package managers would also need modifying.
<NekoXP> for instance with this x32 architecture project, that means running 32-bit apps in a 64-bit compatible ABI, it would be another example of different kernels being fully capable of running the same userspace (and x64 already can run a ia32 userspace)
<NekoXP> actually what would be less weird is if any binaries are required to go into packages, mark the package as that ABI. Since binaries that don't use VFP on armel or armhf can run together anyway it will reduce package building for things that don't touch fp at all
<NekoXP> that was the original idea, I guess it's difficult though right?
<NekoXP> but not so different from the differentiation between ${my_running_arch} and "all"?
<GrueMaster> hey, the pandaboard ES is now on pandaboard.org.  Cool.
<GrueMaster> NekoXP: I can already do that partially on arm.  I was running a chroot to an armhf image from an armel image (although I should have used lxc as it left the platform unstable).
<ogra_> just because you mounted /proc :)
<NekoXP> sure, the only incompatibility is if it uses vfp instructions AND uses the vfp abi extension it's basically mutually incompatible for those functions only. If you had libc and libm, libc would be basically completely agnostic.. libm would need to be linked depending on the elf header.. that kind of thing
<NekoXP> the vast majority of stuff doesn't actually throw around fp arguments, but there's some stuff like OpenGL which definitely does and it makes a hell of a difference
<NekoXP> and even then you could get the benefit of the improved ABI internally, and use assembler stubs or macros to call out to armel libs if need be (or the other way around). I actually do wonder if gcc would use the vfp abi extension for static functions even if it was built with armel?
<GrueMaster> Well, I think the goal is to switch to armhf before release, and leave armel to bit-rot, making the whole argument moot.
<NekoXP> good point
<GrueMaster> Aven if we keep armel floating along, it should be easy to run armel packages on an armhf system using multilib.
<GrueMaster> *Even
<GrueMaster> The opposite is not guaranteed to work.
<ogra_> well, moot once we shot down the armel archive
 * GrueMaster reads up on the sysboot3 switch on the pandaboard ES.  Switches boot from USB/MMC1 to UART/MMC1.  Useless.
<S0NiC> cu guys
<janimo> xranby, thanks for the pointer
<apw> GrueMaster, has ppisati given you any 3.2 based ti-omap4 kernels to test ?
<GrueMaster> I haven't seen one yet.
<GrueMaster> Nothing on my mirror (updated from ports.u.c bi-hourly).
<infinity> GrueMaster: It's not uploaded/built yet.  apw's just about to do that for us.
<GrueMaster> ah, ok.
<apw> GrueMaster, yeah was wondering if you had had a preview
<GrueMaster> Nope.  Loop {everyone}; me.  Same as always.  :p
<infinity> You and I entered the loop at the same time. :)
<infinity> And I'm not sure anyone else is in it.
<infinity> So, you can claim first this time!
<GrueMaster> This looks prommisint though:  linux-image-3.0.0-1402-omap4_3.0.0-1402.3_armhf.deb on my mirror.
<MrCurious> anyone here have any experience with asm on arm?
<GrueMaster> And netinstall images!  Santa came early last night.
<MrCurious> http://pastebin.com/zkP6Zbbs <-  trying to understand why it doesnt like REGS_TO_SAVE  i think it may be in a invalid format for the __asm__  volatile call
<GrueMaster> (even if my fingers are cramping up and I can't type).
<GrueMaster> Ewww.  gcc inline assembly.
<GrueMaster> Brings back bad memories from my early Intel days.
<apw> GrueMaster, that is the previous kernel, we are taking about jumping that 2 kernel versions :)
<apw> but if you have working netinstall images finally thats great
<MrCurious> if i trim regs to save down to 1, then it flies
<GrueMaster> apw: Understood, but having an armhf kernel for omap4 now means I can have one system play while I way for your spin.
<apw> GrueMaster, sounds like a good things
<infinity> GrueMaster: I'm curious if that omap4 netinst plays up for you.
<GrueMaster> I'll let you know in a few minutes.
<infinity> GrueMaster: If you get the same "everything works, but I get no login" issue, then it's definitely time for me to get digging on reproducing.
<GrueMaster> I was able to get further with init=/bin/sh.  Something in unity seemed to be hosing the system.
<infinity> Unity, feh.
<infinity> Netboot a server install instead of a desktop one? :)
<GrueMaster> Oops.  Meant upstart.
<infinity> Oh.  That's potentially less pleasant.
<infinity> Could be neverending respawning gettys.
<GrueMaster> Does ssh spawn a getty?
<infinity> I think upstart helpfully hides that situation from you, unlike sysv that would spam the console with "YOU'RE FUCKED, MATE".
<GrueMaster> Heh.
<infinity> Hrm, no.  SSH doesn't run a getty binary.  Though, it does still use PTYs.
<GrueMaster> Crap.  Kernel Panic.  initrd issue.
<infinity> Initrd issue? :(
<infinity> Don't tell me I need to fix it harder.
<MrCurious> solved :D
<infinity> Fucksake.  It's still putting it in /lib isn't it?
<infinity> d-i needs a talking to.
<GrueMaster> Looking
<GrueMaster> yep.  Get out the flogging stick.
<infinity> I figured moving it in the udeb would be enough.  Apparently, it's braindead and just flattens everything to /lib >:(
<GrueMaster> No arm-linux-gnueabihf in /lib.
<infinity> Will fix later today.
<infinity> But if you repack that mess, here's hoping it work.
<infinity> s
<infinity> (Works better than omap, that is)
<GrueMaster> I'll have to wait for a little bit (or cobble the boot process manually).  The current setup pxeboots and pulls from my mirror, which is now updating.  If I manually flog uInitrd, it will just get erased.
<GrueMaster> Ok, onward.  Netinstall started.  Moving on.
<GrueMaster> grmbl.  "Loading libc6-udeb failed for unknown reasons. Aborting."
<GrueMaster> infinity: ^^^
<infinity> ...
<infinity> GrueMaster: Anything in syslog?
<GrueMaster> And how do you propose I look when I can't launch a shell or save the log w/o libc6?
<GrueMaster> (logs are in the ramdisk until post-install).
<lool> Error: update-openoffice-dicts not present or executable. Missing dependency on
<lool> dictionaries-common?
<lool> Looks like armhf images will need libreoffice in some way
<infinity> We'll get there.
<infinity> But it also looks like some package is, indeed, missing a dependency. :P
<infinity> (Or missing an [ -x /foo ] guard.
<infinity> )
#ubuntu-arm 2011-12-08
<twb> lilstevie: my btrfs netbook decided to become corrupt with warning this morning, so I think I will be fast-tracking my TF101 now :-P
<lilstevie> lol
<twb> At least the notes were copied to another box
<GrueMaster> Grrr.  Looks like hunspell-en-us has clobbered all arm desktop images.
<Xase> lilstevie: oh @ evdev, rollup.
<twb> lilstevie: what's the URL for your latest tarball of stuff?
<twb> IIRC you changed its name and suchlike
<twb> Ah, "OLiFE"
<ogra_> hmm, where does that second omap4 armhf image build come from
<ogra_> infinity, was that you ?
 * ogra_ definitely didnt trigger a second build 
<infinity> ogra_: Eh?  What second build?
<infinity> ogra_: Oh, cdimage?  I've been asleep.  So, not me.
<ogra_> k
<ogra_> i'll add the SUDO_USER stuff today then :P
<ogra_> but first i would love to know why ubiquity is broken :(
<infinity> The build, you mean?
 * ogra_ sees no valid reason for it not finding flash-kernel-installer
<infinity> I was going to look at that today.
<infinity> After I get this mklibs hackery committed for netboot.
<ogra_> it complains about f-k-i missing in its source tree
<infinity> Yeah, I saw that.  Made little sense.
<infinity> Ooo, my bootstrap build of ghc finished.
<ogra_> but f-k-i definitely built for hf and the last ubiquity upload calims it pulled it in in the changelog
<infinity> Time to get the archive building it.
<ogra_> hmm, though it claims it can not create the target in the build log
<ogra_> not that the source file isnt there
<ogra_> i wonder if there is just a mkdir missing
<ogra_> (or -d for the install command)
<infinity> But it works on armel.
<infinity> Should be the same code.
<ogra_> yes
<infinity> Looking, though.
<ogra_> well, colin claims in the changelog that he adapted links for hf or some such
 * ogra_ checks for the exacrt wording
<ogra_> hmm, no, that was d-i
<ogra_> ubiquity only has * Add armhf support.
 * ogra_ doesnt really get it 
<infinity> lrwxrwxrwx 1 adconrad adconrad  15 2011-12-08 04:06 armhf -> d-i/lists/armel
<infinity> That could be the problem.
<ogra_> hmm
<infinity> That should be a link to the same directory.
<ogra_> geez, unpacking the xz takes my ac100 close to a halt
<ogra_> still running
<ogra_> fun
<ogra_> infinity, to the same file you mean
<infinity> Well, to the file in the same directory, yes.
<ogra_> yup
<infinity> Same problem in debian/
<ogra_> you mean the .install file ? yeah
<infinity> And that's probably your missing target.
<ogra_> and .dirs as well it seems
 * infinity is also curious why ./d-i/source/base-installer/kernel/armhf.sh is different from ./d-i/source/base-installer/kernel/armel.sh
<infinity> But I'm also not entirely convinced that's used.
<ogra_> i doubt it, but it will surely caquse d-i issues since it originates there i think
<infinity> Well, let's see if fixing those symlinks makes ubiquity happy.
<infinity> To test build or not to test build...
<ogra_> pfft
<ogra_> just upload
<ogra_> will just waste 1h of your day to do a testbuilt, if it fails we can upload again
<ogra_> *testbuild
<ogra_> testbuilds are for freezes :P
 * ogra_ wonders why gcc-4.5 is in the core seed
<ogra_> arent we using 4.6 since a while ?
<infinity> 4.4 is still in main too.
<ogra_> main, sure
<ogra_> but core ?
<infinity> Eh?
<infinity> "core" is just an upload packageset.
<infinity> I don't ever want any version of GCC living outside core, do you?
<ogra_> i want the default one in core ...
<infinity> Packagesets != Seeds.
<ogra_> why would i want the fallback there
<infinity> You want MOTU updating every compiler other than the primary one?
<infinity> Possibly accidentally dropping vital patches and breaking them? :)
<ogra_> well, -snapshot is in universe as well
<infinity> Yeah, because we don't build packages with snapshot.
<ogra_> afaik at least
<infinity> Sometimes we fall back to building packages with older versions of gcc.
<infinity> (MySQL is built with 4.5, for instance)
<ogra_> ah, k
<ogra_> i thought we fobid that a while ago
<ogra_> *forbid
<infinity> We can't, really.
<infinity> If a new compiler is broken for some chunk of code, what do we do?
<ogra_> fix it :)
<infinity> Just say "well, we can't ship MySQL unless the compiler is fixed"?
<ogra_> scream and shout to linaro ...
<infinity> That sort of thing doesn't work well with time-based releases. :P
<ogra_> heh
<doko> infinity, hmm, what is wrong with https://buildd.debian.org/status/package.php?p=gcc-4.4&suite=sid ?
<doko> armel
<infinity> doko: You forget to backport your -mfloat-abi=softfp change from 4.6 to earlier versions?
<infinity> doko: (The one where you explicitly set that for the Debian/armel build)
<infinity> s/forget/forgot/
<infinity>   else
<infinity>     # Debian armel
<infinity>     CONFARGS += --with-arch=armv4t --with-float=$(float_abi)
<infinity>   endif
<infinity> doko: ^-- That?
<doko> infinity, it's the default anyway, and 4.4 doesn't know about hard-float yet. it's just 4.4 linaro. so I assume I just back out this change for debian
<infinity> doko: Eh?  softfp wasn't the default, that's why you had to add it to 4.6...
<infinity> (Or, rather, the switch wasn't SET by default)
<infinity> doko: --with-float=$(float_abi) only happens in the ifeq Ubuntu block, so no float bits set for debian/armel.
<doko> infinity, Debian armel is soft, not softfp
<infinity> Well, whatever it was. :P
<infinity> I was just copying your else..endif from 4.6 up there.
<infinity> Anyhow.  You could just revert and not build on armhf at all.
<infinity> Or just make rules2's arm* block match 4.6
<infinity> 4.5 is in the same boat, I imagine.
<doko> infinity, ahh, no -mfloat-abi= parameter passed at all, which breaks the patch :-/
<doko> I know I dislike this default stuffing of config parameters
<infinity> I'm sure we can work up a more elegant patch later.  But this "works".
<infinity> doko: ghc is building on the buildds now, BTW.
<infinity> Local build took forever.  Silly haskell.
<ogra_> hmm
<ogra_> what i wonder is why did ubiquity 2.9.5 build flawless on armhf ... it shuld have had the same issues as .9.6
 * ogra_ just noticed there is a binary
<IamTrying> I was using Ubuntu-ARM in my Eee pad transformer, now i get this: http://i.imgur.com/6lY5H.png  . How can i restore to Android using OLiFE.sh ? 1. Backup 2. Flash 3. Inject
 * ogra_ would suggest to ask that in a transformer channel ... i doubt anyone here knows OLiFE.sh (apart from lilstevie probably)
<IamTrying> Fixed, with OLiFE.sh > Menu update > 1. Android kernel
<IamTrying> But i want to go back to Ubuntu again and see what caused it?
<lilstevie> IamTrying: sec
<lilstevie> wow
<lilstevie> wtf did you do
<lilstevie> 0.o
<IamTrying> Yea i was also thinking what i did. I actually Ubuntu-ARM but it does not auto boot
<IamTrying> So i needed to press always Vol+ to boot
<lilstevie> yeah, but that framebuffer connection is... just not normal
<IamTrying> Then i decided to re-install Ubuntu-ARM again so that auto it boots
<lilstevie> and yeah, that is normal if android is set as default boot
<lilstevie> ok, still doesn't really answer the question
<lilstevie> if you try running it as the recovery boot does it do the same
<ogra_> probably the antenna is just mis-adjusted :P
<IamTrying> I used this OLiFE.sh script to restore to Android ( https://gist.github.com/1447187 ) and it caused this > http://i.imgur.com/6lY5H.png
<lilstevie> that isn't what I asked
<lilstevie> ogra_: lol
<lilstevie> ogra_: that is like total fb corruption; I don't understand it in the slightest
<ogra_> bootloader probably
<lilstevie> ogra_: shouldn't be, bootloader goes with the OLiFE scripts
<lilstevie> purposely done so I don't have to deal with bootloader issues
<ogra_> isnt the frambuffer initialized by the bootloader on the transformer ?
<ogra_> like on the ac100
<lilstevie> yeah, but corruption like that would be kernel level
<lilstevie> or above
<IamTrying> Let me freshly install the Ubunt-ARM using OLiFE.sh. But it does not boot auto.
<lilstevie> maybe something done to xorg
<ogra_> on ac100 we dont re-initialize the fb ... so such a thing cant happen here
<IamTrying> I did always need to press vol+ to boot. and finally today it was failing to boot.
<ogra_> do you re-init it in the transformer kernel =
<ogra_> ?
<lilstevie> no, which is why I don't understand
<ogra_> yeah, weird
<lilstevie> also IamTrying yes, that means you set ubuntu to be secondary boot
<IamTrying> I did those steps and it fixed it now and i am back to Android PRime
<IamTrying> https://gist.github.com/1447187
<lilstevie> AKA; it is meant to do that
<lilstevie> as I said last time we had this little conversation
<IamTrying> Yes, when i try to setup for option 2, its very odd, it shows a loop of ASUS Screen and Linux unless i press manually down and then up button.  1. Turn device on or 2. Hold vol-down then press vol-up
<lilstevie> IamTrying: all I can really suggest is post in the QandA thread on XDA developers, maybe someone has come across your condition before and can help
<IamTrying> lilstevie, Yes sure, OLiFE.sh is excellent its genius, its working actually, saved my Android device. I just want to install the Ubuntu-Arm as power-on default boot, but optionally if requires i want to go back like now i did.
<lilstevie> default boot can be a little flakey tbh
<lilstevie> the mem carveout is not nice
<IamTrying> Ok, still fine, but There was a strange crash today. I pressed vol-down, i got the choice then i press vol-up to boot in my Ubuntu-Arm, but it shows lots of error and then nothing just happened. So then i decided to go back to Android.
<IamTrying> I just re-installed Ubuntu-Arm using OLiFE.sh just like Day 1. And i have the same crash everytime when i boot e.g: http://i.imgur.com/AGSzH.png
<IamTrying> Any idea?
<infinity> doko_: I'll fix qtmobility right after my next meeting.
#ubuntu-arm 2011-12-09
<twb> lilstevie: hey, you around?
<twb> lilstevie: I'm trying to use your menu doodad from OLiFE 1.2, it isn't happy about something
<twb> nvflash configuration file error: partition/ filesystem_type invalid
<twb> lilstevie: it gets farther if I pick dualboot, so I think there's a typo in your configs/linux.cfg, investigating now
<lilstevie> yeah, there is :p
<lilstevie> twb: I need to fix it but there is a misplaced c
<lilstevie> sed -i 's/ext3c/ext3/g' ./configs/*
<twb> Ah, I saw that and thought it looked suspicious :-)
<lilstevie> yeah, was a typo, but haven't really gotten around to fixing it because I cbf, I don't want that script to be around for much longer
<lilstevie> and the more I fiddle around with trying to fix it the less time I have to work on the gui
<lilstevie> oh btw, interesting thing, someone else came across the same issue you were having with u-boot
<twb> Hooray
<twb> Did they fix it?
<lilstevie> well,
<lilstevie> no
<lilstevie> I did
<lilstevie> they were a little more helpful
 * twb looks guilty
<lilstevie> turns out; not following instructions to the letter doesn't work
<twb> What did I fuck up?
<lilstevie> did you apply ARCH=arm on the same command line, or were you doing it from env vars
<twb> IIRC no because I was compiling on the device itself
<lilstevie> ok
<lilstevie> well the guy who also had the problem; if ARCH=arm was not supplied, it produced the same non working image you had
<twb> I've lost most of that when my netbook exploded yesterday
<lilstevie> fair enough
<twb> Interesting and annoying, tho
<twb> Do you know if he was cross-compiling?
<lilstevie> yeah
<twb> k
<lilstevie> he was, but I supply ARCH=arm when I compile on device
<twb> Hum
<lilstevie> cause I use the same script to build
<lilstevie> and supply the cross compiler in envvars
<twb> scripts/flash.sh: line 108: return: can only `return' from a function or sourced script
<twb> FYI you also appear to have done + ./bins/nvflash --bct ./images/transformer.bct --setbct --configfile ./configs/linux.cfg.cfg --bl ./images/bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync
<lilstevie> I always call the other scripts with source 0.o
<twb> OK my fault then
<twb> Also when flashing it gets to "Device needs to be put back into APX mode" but doesn't pause
<lilstevie> odd
<lilstevie> it should
<twb> Why does linux.cfg say USP instead of UBT?
<twb> nm, UBT is further up
<twb> When I boot it, it coms up with the eeepad/asus/nvidia logos, and just sits at that screen
<twb> I am using your olife prime edition, maybe the asus bootloader that ships with that is wrong for the 32G
<lilstevie> no
<lilstevie> there is one bootloader
<twb> OK
<twb> I asked because now when I do boot+voldn, it gives me only "wipe data" and no second icon, last time IIRC there were two icons and volup switched between them
<lilstevie> newer versions doesn't
<lilstevie> don't*
<twb> ah ok
<lilstevie> you may need to put the kernel in recovery position and write recovery-boot to msc
<twb> ./bins/nvflash --bct ./images/transformer.bct --setbct --configfile ./configs/linux.cfg --create --bl ./images/bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --go
<twb> ./bins/nvflash --bct ./images/transformer.bct --setbct --configfile ./configs/linux.cfg.cfg --bl ./images/bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync && ./bins/nvflash -r --download 8 ./images/ubuntu.img
<twb> ...those were the commands that ran
<lilstevie> yeah
<lilstevie> there has been some wierd condition though with decompressing the initrd
<lilstevie> in main boot
<lilstevie> where quite frankly, it dies on its ass and has a kernel panic
<twb> I don't think that's what's happening to me
<lilstevie> what is happening to you
<twb> 14:47 <twb> When I boot it, it coms up with the eeepad/asus/nvidia logos, and just sits at that screen
<twb> If it was oopsing in the ramdisk I would expect it to say so onscreen
<lilstevie> yeah it does
<lilstevie> incomplete write
<lilstevie> ./bins/nvflash --bct ./images/transformer.bct --setbct --configfile ./configs/linux.cfg --bl ./images/bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync && ./bins/abootimg-$(uname -m) --create ./tmp/linux.img -f ./boot/purelinux.cfg -k ./kernels/2636-zImage -r ./kernels/initrd-2.6.36.img && ./bins/nvflash -r --download 6 ./tmp/linux.img
<twb> 6 not 8 ?
<lilstevie> why would you write the kernel over the rootfs :p
<twb> Well because 8 is what you're doing in olife script
<lilstevie> yeah but that is writing the rootfs
<twb> oh right
<twb> That didn't seem to help
<lilstevie> what happened
<lilstevie> same thing, or something else
<twb> same thing
<lilstevie> hm
<lilstevie> do it to 5 and boot recovert
<lilstevie> recovery*
<twb> wtf I hit reboot and it just displayed linux for a second
<twb> So it had booted the kernel but not drawn anything onscreen
<twb> yeah, it was oopsing
<lilstevie> ah
<lilstevie> ^^
<twb> somethign about not syncing VFS
<twb> unable to mount root filesystem
<twb> if I pick dualboot and ubuntu default, then I get the thing you described where linux starts and oopses onscreen
<twb> Then if I bounce it again it comes up normally, and resize2fs's and everything
<lilstevie> hm
<twb> my guess is config/linux.cfg and boot/purelinux.cfg don't line up somehwere
<TheMuso> I wonder whether Linux would still boot if some of the fat was trimmed from the initramfs when in the default boot configuration.
<twb> TheMuso: strictly the ramdisk isn't needed at all
<TheMuso> twb: I know that.
<TheMuso> twb: But the initramfs sets up framebuffer stuff, runs jasper bits, etc.
<twb> haha, it's been in D for >120 seconds, the kernel guard just said
<twb> "kinteractiveup" has
<lilstevie> TheMuso: have you written anything up yet for that blueprint
<twb> TheMuso: if you want to remove plymouth from ramdisk I won't object ;-)
<twb> lilstevie: during oem, what is the username and password?  It used to be oem/oem, but this doesn't appear to be the case here
<lilstevie> stuffed if I know
<twb> (I need to know so I can run "ip a" and find out the wifi MAC address, since wifi here pegs PSKs to MACs)
<twb> hum
<lilstevie> ubiquity is autorun
<twb> yeah but ubiquity prompts for a PSK without telling me what the MAC address is, so I can't give it the PSK
<twb> I just skipped wifi for now
<lilstevie> well then do wifi once booted :p
<lilstevie> like post ubiquity
<twb> I'm used to network installs where you can't :-)
<TheMuso> lilstevie: Beyond actually adding the blueprint, not yet. Hopefully this weekend. Why whats up?
<lilstevie> was just wondering :p
<twb> lilstevie: how do you get keyboard repeat working?
<twb> lilstevie: ok, excitingly even though I was happily running ubuntu and did ubiquity and rebooted and such, after I switched into prime and back, ubuntu kernel detected the ramdisk was an incomplete write, and then oopsed
<twb> lilstevie: THAT makes me think that maybe the ramdisk is wider than the partition its on, but it happens to work until you run android which overwrites some of the overlapping blocks.  or something.
<lilstevie> no
<lilstevie> it is bootloader space
<lilstevie> it works if kernel is in recovery position but not in main
<twb> That hurts my brain
<twb> If I pick the first option (dual boot, prime default), jasper seems to want to resize the root filesystem *every* boot
<twb> lilstevie: I'm going home now.  I'm a hard-code bash-fu weenie, so feel free to ping me if you want someone to wangle those olife scripts
<ogra_> doko, someone in #ac100 just complained that python2.7 segfaults on armhf, is that known ?
<doko> ogra_, extension or core code?
<ogra_> he claims the package cant execute bytecode compilation from its postinst
<ogra_> seems core code
<ogra_> he said that 1.5h ago, i only saw it now, i pinged him
<ogra_> i'm also not sure if he doesnt use a chroot or if thats the hf ac100 image
<ogra_> (hf chroots seem to behave weird if /proc is mounted ... )
<infinity> Err.
<infinity> No.
<infinity> They don't.
<ogra_> they did here
<ogra_> several times
<infinity> You mean procps upgrades killing your system?
<infinity> That's not "hf chroots misbehaving with proc mounted".
<ogra_> that too, i had two other incidents where it affectzed the host
<infinity> Well, any chroot can affect the host through proc.
<infinity> Not an hf thing.
<ogra_> sure, but usually that doesnt mean i need to reboot :)
<infinity> The procps thing is not hf-specific either, I suspect.
<infinity> I just haven't cared to look at it.
<ogra_> well, i have never seen that on other setups
<infinity> Anyhow, python not being able to execute its postinst is pretty clearly not true, since it happens on nearly every build on the buildds..
<infinity> So, there's something more subtle going on there.
<ogra_> for 2.7 ?
<infinity> 2.7 is our default python.
<infinity> So, yeah.
<ogra_> hmm, intresting
<infinity> Any package that build-deps on python (which is, well, lots of them), python2.7 gets installed.
<ogra_> well, then i guess that guy simply has a broken setup or some such
<ogra_> i asked him to file a bug
<infinity> Or a dying machine.
<infinity> If he can reproduce the same segv every time, then it's worth looking into.
<infinity> But still might be something with the ac100 kernel or some such.
<ogra_> well, i installed ubiquity b-deps yesterday in my chroot ... that should definitely install 2.7 alongside then
<ogra_> and i had no errors
<ogra_> its likely that he uses one of the early -core tarballs or some such
<ogra_> and didnt upgrade
<infinity> Should have been fine back then too.
<infinity> If python had been broken at any point in the bootstrap, I would have known.
<infinity> Well, broken to that extent.
<ogra_> k
<infinity> I'm sure it's slightly broken somewhere. ;)
<infinity> All software is.
<ogra_> well, we'll see what he says (if he answers or writes the bug)
<MMlosh> How does one use the USB OTG   port on ubuntu oneiric?  (device mode)
<jjardon> Hi, I have problems compiling eglibc in my ARM board. This is the error message: http://paste.ubuntu.com/765163/
<jjardon> I already set CFLAGS="-fno-stack-protector -U_FORTIFY_SOURCE" Any another idea?
<infinity> jjardon: I suppose asking why you don't use the packaged version would be a stupid question?
<infinity> jjardon: (And your CFLAGS pretty clearly aren't making it there)
<jjardon> infinity: mmm, strange, I export the CFLAGS environment var and I get the same result
<infinity> I assume they're being reset by the Makefiles.
<infinity> Still, why are you building eglibc at all?
<jjardon> infinity: playing with lfs
<infinity> Ahh, so not really an Ubuntu question. ;)
<infinity> Anyhow, in the eglibc packages, we work around the upstream Makefiles being draconian about CFLAGS by cheating.
<infinity> We set CC="gcc-4.6 -fno-stack-protector -U_FORTIFY_SOURCE" CXX="g++-4.6 -fno-stack-protector -U_FORTIFY_SOURCE"
<jjardon> infinity: no, not really ;) . I was wondering if the ubuntu-linaro compiler was setting any special flag or something
<infinity> (ie: passing the flags as part of the compiler name instead)
<jjardon> oo, I'll try that
<ogra_> janimo, could you take a look if we could get teh fix for bug 861296 into the ac100 oneiric package ?
<ubot2> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
<shadeslayer> lilstevie: no luck on getting ubuntu to boot on the transformer? :(
<shadeslayer> ( SBK v2 )
<MMlosh> How does one use the pandaboard's USB OTG   port on ubuntu oneiric?  (device mode)  Loading g_ether does not seem to be enough
<GrueMaster> infinity: Any progress onlibc6
<infinity> GrueMaster: The netisnt issue?  Haven't had a chance to test yet.
<GrueMaster> well, last build still failed libc6-udeb
<GrueMaster> uInitrd was fine though.
<infinity> Yeah, I know.  Getting to it.
<doko> infinity, did you see my message about happy being unhappy?
<infinity> doko: Yeahp, it's building.
<doko> thanks
<infinity> GrueMaster: Oh, FFS.
<GrueMaster> ?
 * infinity looks...
<infinity> -rw-r--r-- root/root     93484 2011-12-06 16:45 ./lib/arm-linux-gnueabihf/ld-2.13.so
<infinity> Lack of executable bits.
<infinity> I could just back out my path change from eglibc, since I fixed that in d-i anyway...
<parin1> i just got a pandaboard what should be the status of LED1 and LED2 when you boot?
 * infinity tries to sort out how that's happening...
<parin1> i am not getting anything on console neither on display
<parin1> SD card booting from ubuntu 11/05 netbook prebuilt image
<parin1> 11.04
<infinity> parin1: Nothing on serial?  Wiggle the card or try another.
<infinity> parin1: It very unhelpfully does precisely nothing if it doesn't think there's an SD in the slot.
<parin1> nope nothing on serial
<parin1> i am using eclipse Terminal plugin not the minicom
<parin1> whish should not matter i think
<parin1> i am trying other card
<parin1> but what should be the stutus of LEDs in a normal situation?
<infinity> I don't recall what they do initially on boot.
<infinity> Looks like both come on.
<infinity> If there's no card in, only 2 comes on.
<parin1> ok now i insetred the card, plugged the power in and pressed the power on button but still nothing
<parin1> LED2 comes on and goes off
<parin1> LED1 isnt turning on
<parin1> i pressed power button one more time no LED2 is on
<parin1> LED1 is off
<parin1> but not getting anything
<parin1> any idea?
<infinity> You don't even need to press the power button.  Just card then plug is enough.
<infinity> If LED2 is blinking out like that, I suspect it thinks there's nothing worth looking at on the card.
<janimo> ogra_, we do not have it yet, I pinged upstream about it too
<infinity> janimo: Locally patch it into your upcoming 3.x release? :)
<janimo> I think we only need it for precise though?
<janimo> infinity, that too if upstream does not put it in their 3.0 tree :)
<infinity> janimo: I don't think it's dreadfully necessary to backport it for a "community" kernel, but we did do so for all the supported ones.
<janimo> infinity,I figured it is not that important a bug to have another oneiric upload for it
<infinity> janimo: No, but maybe queue it up if there are other things that need SRUing.
<infinity> janimo: But, really, I supect you're not even doing security support on that kernel, so...
<janimo> I not so secretly hope we no longer upload SRU for ac100 kernel, unless critical security issues
<janimo> it works ok so far and people are not complainig
<janimo> the thing which do not work are minor (headphone mic etc) but those are not working upstream either yet
<janimo> the last SRU did not get even one tester even though there was a call or two asking for it, so I think people are ok with what they have and not falling over to get new hotness
<infinity> I don't much care, as long as things kinda work.
<infinity> Security support would be nice, but I also plan to replace oneiric on my ac100 with precise really soon now.
<infinity> So... Will I get security support from you on precise? ;)
<janimo> infinity, heh, let me think before I decide if this is a trap question or not ok?
<infinity> (It is)
<janimo> if we get the port in good shape to be more than a community thing, we should probably have SRUs for it
<infinity> "More than a community thing" meaning?
<infinity> It'll never be more than a community thing. :P
<janimo> although since this is a space of arm/netbook tablets where the ac100 will look stone age in 2 years I am not sure people will care about updates for too long
<infinity> Canonical's not gong to put any official support behind a subarch aimed at hardware that isn't available.
<infinity> Although.
<janimo> well, more than it is now, a bit more poliesh and with more users, in that regard
<infinity> lilstevie and I were saying the other day that changing the ac100 subarch to a tegra subarch might not be an awful idea, if we can make the same kernel boot on a few devices.
<janimo> that would indeed make a lot of sense
<infinity> (Might be limited to tegra2, which still makes it DOA, but just maybe a unified tegra2/3 thing is possible?)
<janimo> the 'One ARM kernel to boot them all' is still far away I guess. Not sure what subarchs linaro is targetting with that (if still the plan indeed)
<infinity> Well, it relies on two things.
<infinity> The first being Devicetree/ACPI on all target devices.
<janimo> no idea how the tegra3 differs from t2 for such a kernel to be possible. Would be nice of course
<infinity> The second being no more driver conflicts between all the source trees. :P
<infinity> (ie: so you can have one source tree)
<infinity> Given nvidia's engineering practices with GPUs, I'd be shocked if tegra3 couldn't boot on tegra2 kernels.
<infinity> But then again, it's probably a whole different set of engineers.
<infinity> (I still love that the same drivers work from Riva TNT all the way to GeForce FancyPants 2011)
<infinity> Well, except for bitrot.
<janimo> infinity, same drivers? I thought there were about 3 deb packages for different eras of NV chipsets? But as usual I may misremember
<infinity> janimo: There are, but that's only because they drop "official" support for old GPUs every once in a while so they don't have to keep testing and tweaking for dead hardware they don't care about.
<infinity> janimo: The oldest driver will still init the newest card (if you jam in the PCI IDs), just won't know all the extensions, and the newest driver will still drive the oldest card, it just might be buggy due to bitrot and lack of testing/caring.
<janimo> I'd like to think  the lack of love for L4T is because they work on tegra3 support and will release together, and not just because they couldn't care less for linux
<janimo> infinity, that is impressive if so, had no idea
<janimo> but I do not want to image how that code must look like
<janimo> imagine
<infinity> The code's reasonable, except for the TNT compat (which they did actually drop completely at one point).
<MMlosh> ogra_,  I am not sure if you're the right one to ask..   who might know how to use the pandaboard as a usb device?  loading g_ether is not enough.  and I apologize again for the highlight..
<infinity> So, I suppose I should say GeForce GTS -> GeForce now (but that's still 11 years of GPUs?)
<infinity> janimo: When they come up with shiny new ways to do old things, they often toss in a bit of a translation layer in microcode instead of in the drivers.  One of the things that happens when they drop support for old GPUs is dropping support for those translation interfaces and writing to the newer instructions.
<infinity> janimo: But, like I said, the core ISA never changes much.  Think of it like x86-for-graphics (which actually isn't far off, sadly).
<infinity> janimo: Stupidly complex, very extensible, and remarkably backward-compatible.
<janimo> hmm, they do not change the core ISA even with such changes in hw? impressive too
<infinity> janimo: They took a very Intel approach to the whole thing.  Think of the Riva128 and RivaTNT as the 8088 and 80286 (ish).  The GeForce was their "80386", and much like Intel, they decided that was good enough, and just kept extending the ISA after that instead of breaking it.
<infinity> janimo: Which was pretty different from how most other video chip vendors were doing things at the time.  And probably led to their rapid iterations and World Domination(tm) in the space for a while until ATI caught on and started doing similar things.
<infinity> GrueMaster: Found and fixing your bug.  Needs yet another eglibc upload.  FML.
<GrueMaster> Figrues.  Thanks.  Let me know when it goes through.
<GrueMaster> I thought it might have something to do with the udeb change you had made earlier.
<infinity> Sort of, yeah.  All passes do a find | chmod +x run to make sure ld.so is excutable.
<infinity> For the normal passes, that find was fixed to scan subdirectories.  For udebs, no one made that change.
<infinity> So, no +x on ld.so.
<infinity> GrueMaster: Fixing a couple of other eglibc bugs while I'm in there.  And it takes forever to build anyway, so you wouldn't have it by EOD even if I uploaded now.  But you should have working netinst by Monday.
<GrueMaster> Ok.  Cool.
<mksh> hi, can someone who has precise/arm{el,hf} run a test for me?
<mksh> i've read the mksh build logs and am not fully sure about the regression testsuite results
<mksh> (or just gimme a shell)
<mksh> or if thereâs something like debianâs porterboxen, tell me where âº
<infinity> lynx: The test suite seemed to have run fine...?
<infinity> lynx: Anyhow, I can help a bit later today.  I'm in the middle of fixing my clutch right now. :P
<lynx> it actually did not run at all, for mksh-static
<lynx> thanks, if I'm still around later tell me
<lilstevie> janimo: Tegra2 and Tegra3 are very similar at a core level, just the Tegra3 has 4 of them,
#ubuntu-arm 2011-12-10
<infinity> lynx: I'm back, if you're still needing help.
<Netham45> Anyone know what the username/pass is for the AC100 images?
<Netham45> (https://wiki.ubuntu.com/ARM/TEGRA/AC100)
<infinity> Netham45: There isn't one unti you've booted the installer.
<infinity> Netham45: If you follow the instructions on the page, on first boot, you'll end up (eventually) in a graphical installer that asks you to create a users.
<infinity> s/users/user/
<Netham45> I'm not on an AC100 but another tegra device
<infinity> Okay... And?
<infinity> That image is an installer image.
<infinity> If you just want a rootfs, try ubuntu-core.
<infinity> (which you'll have to manually configure as you want, but it at least won't have an installer in it that you won't be running)
<Netham45> There's an alternate installer image that'd normally install this one, apparantly.
<Netham45> Okay, I'll just make an acc't on my laptop for the image before I reflash it.
<Netham45> I'm being really confusing, aren't I.
<infinity> Perhaps, but that's alright. :P
<Netham45> http://cdimage.ubuntu.com/releases/11.10/release/ubuntu-11.10-preinstalled-desktop-armel+ac100.tar.gz < Downloaded that and flashed to my tablet, an Acer Iconia A500. That's meant to be installed through that installer, but I just extracted so it got flashed w/o any accounts.
<Netham45> So I need to mount my image on my PC and make an acc't and put the wifi drivers on and it should all be good
<infinity> Yeah, as I said, the instructions on the page point to needing the actual boot image as well.
<Netham45> I have it booting, it just only has a 'Guest' user that obviously has no root access.
<infinity> That said, you could run oem-config on that image on first boot and have it properly "install".
<infinity> Just touch "/var/lib/oem-config/run" in that image before you flash it.
<infinity> And on first boot, you should get the installer running.
<Netham45> Okay. That installer won't muck with my partitions, will it
<infinity> Which will set up a user "correctly", among other things.
<Netham45> ?
<Netham45> heh, I was just going to chroot and adduser
<Netham45> (or is it useradd)
<infinity> adduser.
<infinity> useradd is the lower-level utility.
<infinity> But you'll need to also add yourself to a few groups if you want to mimic what the installer does.
<Netham45> adduser, add to admin group, right?
<Netham45> (or whatever the default sudoers group is)
<Netham45> y'know, the installer sounds easier, I'ma just use that.
<infinity> adm, dialout, cdrom, plugdev, lpadmin, admin.
<infinity> The installer might fail due to you not actually using the ac100 kerel (at least, I assume you're not?)
<infinity> But I guess we'll see.
<Netham45> No, I'm not.
<Netham45> Installer started.
<infinity> It may well die if it tries to do anything kernel-related.
<infinity> Unless you removed linux-\* from the image first.
<infinity> Which I probably should have mentioned. :P
<infinity> (I'm not sure what the installer will do with no kernel packages installed, but I'm hoping the answer is "nothing").
<infinity> It may not break anyway, though.
<Netham45> Worst-case if it tries to overwrite one of the kernels I'll have another to boot to.
<Netham45> infinity, in case you were wondering, other than not clearing the run file the installer worked great.
<infinity> Netham45: If it didn't clear the file in /var/run, it means it didn't actually finish to the point of cleaning up.  Might want to run "oem-config-remove" as root to get it to clean up.
<Xase> GrueMaster: any time to look at that nook kernel I posted by any chance?
<mirabilos> infinity: now _I_ am awake too (having a late breakfast ;)
<sergey_> I've just start with pandaboard. write ubuntu-11.10-desktop into 8Gb mmc card. Start board. It shows ubunto logo. "Resizing, please wait" and then drops to BusyBox (initramfs) :(
<sergey_> what I am doing wrong?
<mksh> infinity: nvm, I could confirm it on a debian armhf porterbox that it's broken
<mksh> the debian/armhf build also came in today and has the same problem
<mksh> so it's not ubuntu specific, and I'll retreat
<Xase> Hey, is it possible to use the ubuntu-core in qemu to build it the way I want/need for my target device?
<Xase> Because I have no way to interface with my target device once booted.
<doko> aK2amypC@H
<infinity> doko: And which password was that?
<doko> infinity, my router :-/
<infinity> doko: And changed already? :P
<doko> infinity, pitti's png optimizations talk loong on opendnssec  :-/
<infinity> doko: It takes forever on a lot of packages.  Maybe we need to optimize the optimizer.
<doko> infinity, did you change the dynamic linker name in both ghc and ocaml?
<infinity> Do either of them use the C PI?
<infinity> Given that haskell and ocaml stuff seems to be running, I'd assume not.
<doko> both call ld directly
<infinity> Cause the old PI isn't on the buildds.
<doko> currently trying to fix clang
<infinity> clang's broken on all arches, isn't it?
<infinity> Or, there's an open bug that would suggest that.
<infinity> https://bugs.launchpad.net/ubuntu/+source/clang/+bug/792146
<ubot2> Launchpad bug 792146 in llvm "clang canât link any programs: cannot find crt1.o, crti.o, crtn.o" [Wishlist,Confirmed]
<infinity> See comment 13, it's apparently "still broken".
<doko> yep
<infinity> But yeah, whatever ghc and ocaml are doing, I assume they're doing it right, cause the binaries they produce are running fine as build-deps for other packages.
<infinity> And /lib/ld-linux.so.3 doesn't exist on our buildds.
<infinity> Hrm, down to only 307 packages with dep-waits.
<doko> that's now most of the haskell infrastructure in place
<Netham45> Anyone know what I have to do to get plasma mobile to work?
<Netham45> nevermind, got it.
<infinity> jcrigby: We're trying to dump gcc-4.5 out of main this cycle, and u-boot-linaro is one of the last packages still using it.  I assume you need to do some hand verification of code generation with gcc-4.6 or something before you can switch?
<infinity> jcrigby: If you could put that on your TODO (sooner, rather than later), that would be seven kinds of awesome.
#ubuntu-arm 2011-12-11
<jcrigby> infinity, ok will do, there have been many "cleanup 4.6" patch sets upstream so maybe things will just work once I rebase against v2011.12
<infinity> jcrigby: Awesome.  Here's hoping.
<lilstevie> infinity: also with that universal kernel plan
<lilstevie> infinity: http://trimslice.com/forum/viewtopic.php?f=34&t=260 <-- seems archlinux have already started on such a project
<lilstevie> infinity: although I do see the problem of all older devices being id'd as harmony, and honeycomb tablets being id'd as ventana
<ceti331> how well does ubuntu work on android tablets genially these days
<ceti331> can you run it on an android phone such as galaxy s2.. can it dual boot
<lilstevie> I'm sure you could run it on the GS2, you probably wouldn't have acceleration, but it will boot; oh and samsungs bootloader is a bit of a pain so there wouldn't be dual boot
<lilstevie> samsung use 1 kernel for both normal and recovery boots
<lilstevie> where as on the asus transformer I use the boot/recovery split to wedge in dual boot
<ceti331> whats
<ceti331> what android devices are best for running ubuntu
<ceti331> i don't have any so purchase decision could be influenced by existing ubuntu support
<lilstevie> hard to say
<lilstevie> what form factor would you be looking at
<lilstevie> I mean overall the AC100 is the most feature complete port
<ceti331> phone or tablet, not sure. I don't currently have a smartphone. i have an iPad - so an android phone is tempting
<lilstevie> they actually have a decent team behind them, but that is really a netbook formfactor
<lilstevie> really the AC100 is probably the only one I could suggest right now
<Martyn> There is an upcoming Toshiba with an nvidia3 in it
<Martyn> Also a cortex A9, but more memory and power
<ceti331> that sounds cool
<Martyn> nvidia tegra3 rather
<Martyn> Yep, but it's due late Feb, early March
<Martyn> the AC100 is, I'd agree, the most complete port
<lilstevie> my port for the TF101 is really incomplete, and there is the problem that new devices don't have nvflash access to run the installer
<Martyn> I'd avoid the Genesi MX .. it's got the least support right now
<ceti331> i guess the ideal for me would be something like the asus transformer
<ceti331> i like the idea of that a lot
<lilstevie> ceti331: the tf101 is amazing
<lilstevie> but frankly the port isn't quite there yet :)
<Martyn> lilstevie: Where can I get the tf101?  I've had a hell of a time finding one
<Martyn> (plenty on Amazon, but for higher-than-I'd-like prices)
<Martyn> and do they come with the keyboard?  Or do you have to buy them separately?
<lilstevie> Martyn: well David Barth got mine for me, that was sans keyboard; but they do come with the keyboard if you get the 32GB vers, there is also a 16GB vers that comes with keyboard, but I have not seen it anywhere
<lilstevie> Martyn: if you are in the US I hear best buy have them
<lilstevie> and with a good price at the moment
<steev_> Martyn: least support how?
<lilstevie> TF101-A2 /B2 come with the dock, TF101-A1/B1 are sans dock
<Martyn> steev_ : Genesei is always behind the main release by a whole release
<Martyn> so they are -just- working on natty
<Martyn> and Oneric is already out
<steev_> not entirely true, but also not entirely our fault... but he left so doesn't matter
<maystar> Hello! Can anybody give me an advise which ubuntu version currently is the most stable and supports the basic features like wifi, video acceleration and bluetooth of the pandaboard? I would like to use it as a multimedia platform. I've tried oneiric, but it seems to be not stable yet and there were problems with wifi, bluetooth and video
<lilstevie> maystar: if you are having problems with oneiric try natty
<maystar> I've read in the omapedia wiki that there is no video acceleration support in natty "yet". Is this information outdatet?
<maystar> Hey! Is anybody, who can explain me what's the difference between the linux-image-version-linaro-omap and the linux-image-version-linaro-lt-omap kernel version? They are both available in the linaro ppa, but I can't find any specific information about them
<TheMuso> maystar: You probably want to ask in another 24 hours or so. For many devs its still the weekend, and they are likely not around at the moment.,
<maystar> ok, thanks!
<infinity> maystar: It has to do with how far they diverge from upstream.  -linaro- kernels use linaro's common head, and -linaro-lt- kernels have extra patches from the SoC landing teams.
<infinity> maystar: The goal is for things to flow from landing teams to linaro common code to kernel.org upstream, but if you want to try the latest, greatest (and possibly broken) shiny that the landing teams are working on, that's what the -lt- kernels are for.
#ubuntu-arm 2012-12-03
<ptl> does any of you know how to enable HDMI sound on the UG802 with ubuntu?
<stgraber>  /win 37
<dholbach> good morning
<feasty> morning dholbach
<dholbach> hey feasty
<feasty> Cheers for the email the other day.
<dholbach> thank YOU
<dholbach> I'll reply to it in a bit - just finishing up some other small bits
<feasty> Hey no worries.
<hrw> hello
<smartboyhw> hello
<feasty> hey
<xnox> ogra-cb_: so i get initramfs busybox from the nexus boot/rootfs on cdimage.
<xnox> ogra-cb_: and I haven't been able to boot a single one off cdimage so far (as far as i remember)
<xnox> the one from hwe still works... but I do use the 16GB specific image there.
<ogra_> xnox, how did you install ?
<hrw> ogra_: does unity 3d works on opengles?
<ogra_> hrw, sure
<ogra_> else nexus7 wouldnt be possible
<hrw> ogra_: someone complains for chromebook: https://bugs.launchpad.net/chromebook-arm/+bug/1085596
<ubot2> Launchpad bug 1085596 in Cross distro support for Samsung Chromebook (ARM based) "Graphics acceleration not working in ubuntu desktop 12.10" [Undecided,New]
<ogra_> yes, seems the GLES driver doesnt offer all features, you can force it to GLES though but that will still render parts in SW
<ogra_> though its fast enough to be usable even with that
<hrw> nux-tools has a tool to check it iirc?
<ogra_> yes, and that seems toi be bugy
<ogra_> *buggy
<ogra_> xnox, just installing the latest daily here, seems to work fine so far
<ogra_> zsync http://cdimage.ubuntu.com/daily-preinstalled/current/raring-preinstalled-desktop-armhf+nexus7.img.gz.zsync
<ogra_> zcat raring-preinstalled-desktop-armhf+nexus7.img.gz >raring-preinstalled-desktop-armhf+nexus7.img
<ogra_> sudo fastboot erase boot
<ogra_> sudo fastboot erase userdata
<ogra_> sudo fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img
<ogra_> sudo fastboot flash boot raring-preinstalled-desktop-armhf+nexus7.bootimg
<ogra_> sudo fastboot reboot
<ogra_> xnox, thats my installation preocess, there is no reason it shouldnt work for you the same way
<ogra_> *process
<mjrosenb> odd, my chromebook does not seem to ant to update to 12.10
<mjrosenb> it seems to really like 12.04
<ogra_> mjrosenb, you need to tell update-manager that you want to run non LTS releases
<mjrosenb> did that already
<ogra_> (somewhere in /etc/default)
<mjrosenb> oh, I think I did it through the gui.
<ogra_> well, should be the same
 * mjrosenb verifies that he did this...
<hrw> mjrosenb: I wish you lack with alsa mixer then
<hrw> s/lack/luck
<ogra_> it is actually in /etc/update-manager/release-upgrades
<hrw> mjrosenb: when you will start playing with alsa mixer switches be aware of smoke possibilities
<mjrosenb> hrw: alsamixer isn't currently working, so upgrading can't hurt.
<xnox> ogra_: I'll purge my downloads and redownload just in case.
<mjrosenb> hrw: "smoke possibilities"?
<ogra_> xnox, on the 16G model it should still work, it just wont use all of the available diskspace
<hrw> mjrosenb: many people (including me) already fried speakers in chromebook
<ogra_> mjrosenb, you can blow up the speakers apparently
<mjrosenb> neato.
<hrw> mjrosenb: smoke, melted plastic etc
<hrw> and lot of heat of course
<mjrosenb> I usually leave my laptop's speakers muted, so unless that option is inverted...
<hrw> it is a bit more complicated
 * ogra_ is in oem-config
<ogra_> gah
<ogra_> the WLAN paswword input field doesnt take any input
<ogra_> xnox, hmm, i thinnk compiz screws up onboard here
<ogra_> i can provide the wlan PW via the NW applet ... but not through the installer
<xnox> ogra_: interesting.
<ogra_> and now i cant type in my name
<ogra_> fridays image worked though
<ogra_> sigh
<ogra_> not being able to create a user is kind of a blocker
 * ogra_ reboots
<ogra_> ah, better, a reboot fixed it (though probably because i didnt need to configure the wlan this time)
<hrw> ogra_: which keymap does ac100 uses?
<hrw> ogra_: kernel one, own xkb one, generic xkb one?
<ogra_> consoilesetup as every ub untu out there
<ogra_> *console-setup
<ogra_> nexus7 install finished ... no issues beyond the kbd input stuff above
<hrw> ogra_: console-setup is just a package.
<ogra_> yes, the package conatining all kbd and console font related setup bits
<ogra_> it uses keyboard-configuration, xkb-data and kbd in the backend
<hrw> ok, but did you added ac100 specific keymap or not had to?
<ogra_> why would i `
<hrw> ok
<hrw> I am wondering how to handle chromebook keyboard. default keymap under chromium has set of useful mappings (pgup/down home/end) which are missing under ubuntu
<ppisati> ok, this is weird
<ppisati> i've a package (oprofile) that was removed in precise
<ppisati> but later was reintroduced
<ppisati> but was only built for armel
<ppisati> ?!?!
<ppisati> https://launchpad.net/ubuntu/+source/oprofile/
<ppisati> here is the Q version
<ogra-cb> likely debian/control messed up
<ppisati> showing that it was only built for i386/amd64 and armel
<ppisati> https://launchpad.net/ubuntu/+source/oprofile/0.9.8-0ubuntu1
<ogra-cb> check debian/control if it is "Architecture: any"
<ogra-cb> (it should)
<ppisati> nope
<ppisati> Architecture: alpha amd64 arm armel hppa i386 ia64 mips mipsel powerpc ppc64 s390 sparc
<ogra-cb> yeah. fix that then :)
<ppisati> adding armhf should be enough
<ogra-cb> well, it defines all available arches anyway
<ogra-cb> so "Architecture: any" would be proper
<ppisati> yeah, "any" is probably better
<ppisati> actually it's more than this
<ppisati> the importer fails
<ppisati> http://package-import.ubuntu.com/status/oprofile.html
<ppisati> bah
<janimo> ogra-cb, do you know what could have bringed and empty  /lib/modules/3.5.0-213-omap4/ on the nexus7?
<janimo> I only noticed it now, no idea which package brought it
<ppisati> weird
<janimo> I suppose it's not via the default install. It only had a build symlink in it
<ogra-cb> ppisati, well, bug 653312 shows some activity at least
<ubot2> Launchpad bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged] https://launchpad.net/bugs/653312
<ogra-cb> ppisati, make some noise there :)
<ogra-cb> janimo, headers most likely
<ogra-cb> 3.1.10-8-nexus7  3.5.0-215-omap4
<ogra-cb> ogra@nexus7:~$ dpkg -S /lib/modules/3.5.0-215-omap4
<ogra-cb> linux-headers-3.5.0-215-omap4: /lib/modules/3.5.0-215-omap4
<ogra-cb> yeah
<ogra-cb> ogra@nexus7:~$ apt-cache show linux-headers-3.5.0-215-omap4|grep Task
<ogra-cb> Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb
<ogra-cb> ppisati, err, whats that about disabling ondemand +
<ogra-cb> ?
<ppisati> ondemand is broken in P
<ppisati> or actually
<ppisati> cpufreq was broken back then
<ppisati> in fact the default scheduler is performance
<ppisati> but there's one guy insisting in using ondemand
<ogra-cb> cant be, i never had a simgle issue with that
<ppisati> so i decided to swith it off completely
<ppisati> precise?
<ogra-cb> and thats an essential ubuntu default
<ppisati> no, it's not
<ogra-cb> natty to raring
<ppisati> here is the original bug
<ppisati> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/971091
<ogra-cb> ppisati, yes, we forcefully set it in userspace since 2008
<ubot2> Launchpad bug 971091 in Linaro-Ubuntu "Pandaboard ES freezes with the default CPU scaling governor ondemand" [Medium,Fix committed]
<ogra-cb> i know, i see the bug (you mention it in the merge request too)
<ppisati> comment #16 says "AFAIK this should be solved in tilt-3.4, the problem was coming from frequency update code which should now be in good shape."
<ogra-cb> if you disable it in kernel, did you test how the userspace bits behave if the module is nonexisting ?
<ppisati> wait
<ppisati> i'm not using on demand on my boards
<ppisati> i mean, no one forces it
<ogra-cb> afaik the only prob we ever had with ondemand vs perfocmance that was actiually traceable against cpufreq was when we switched to cpuidle for a short period in precise
<ogra-cb> ppisati, see the init scripts
<ogra-cb> specifically /etc/init.d/ondemand
<ppisati> ogra-cb: wait
<tassadar_> ogra-cb: will 12.10 ubuntu for nexus7 receive any updates or will you update only raring now?
<ogra-cb> tassadar_, *i* wont touch quantal (but i also havent touched it since UDS)
<ogra-cb> tassadar_, quantal is a very evil hacked up demo image that shoouldnt actually be used for more than demoing or looking at bugs
<ogra-cb> raring recieves all the love
<tassadar_> okay, thanks, one more annoying question: I would like ubuntu to be able to use some folder in /data/media/ as root folder and to be able to use .img file from flash drive as /. Is there a chance that modification like that would get into official ubuntu packages, if it is clean&properly done?
<ogra-cb> yes, i think i told you about the work in grub that linaro is doing
<ogra-cb> thats exactly using such a setup
<ogra-cb> using grub for a boot menu, then lupin for mounting an img
<ogra-cb> atter all i would still suggest to just use the recovery partition, apply two minot changes to the userspace and be done though
<ogra-cb> *minor
<tassadar_> I don't want to lose recovery :/
<ogra-cb> (ita auper trivial)
<ogra-cb> *its super ...
 * ogra-cb cant see his keys in the dark
<ogra-cb> you can even do dual boot with the current images with a minor modificatio
<ogra-cb> n
<tassadar_> ...continue...)
<ogra-cb> ?
<tassadar_> what exactly do you mean by minor modification
<ogra-cb> well, flash bootimg to recovery and develop a patch for flash-kernel to respect that
<ogra-cb> thats all dual boot needs
<ogra-cb> ppisati, is there no way to fix it in kernel ?
<tassadar_> well, now that kexec-hardboot support is in n7 kernel, I can just use files from /boot folder in Ubuntu's root, which is awesome
<ogra-cb> instead of chopping out the option
<ppisati> ogra-cb: the fix is "somewhere" is tilt-3.4
<ppisati> ogra-cb: so it could be anywhere
<ogra-cb> tassadar_, that wont save you, it will berak on the fist run of update-initramfs
<tassadar_> yes, I'll have to remove the flash-kernel hook
<ogra-cb> which you really want to keep in case someone uses i.e. an encrypted homedir
<ogra-cb> tassadar_, if you want to avoid flashing, tra to have a file that exports FLASH_KERNEL_SKIP on boot
<ogra-cb> (set it to something indeed)
<ogra-cb> that should save you
<ogra-cb> thats better than removing packaged files
<tassadar_> yeah, saw that in the hooks, that will indeed be better
<ogra-cb> (they have a tendency to re-appear) ;)
<ppisati> ogra-cb: anyhow, if you try to use a governor that is not available, it's a noop
<ogra-cb> k
<ogra-cb> still, its an ubuntu default we dont offer
<ogra-cb> also are we sure the thing wont overheat if it permanently runs at full speed ?
<ppisati> either we do this, or we have to disable cpufreq
<ogra-cb> which means full power anyway and bigger changes
<ogra-cb> well, seems there is no way around unless we offer a backported kernel then :/
<ppisati> ogra-cb: btw, i was pretty sure i asked what our builders were running, and i was told it was performance
<ogra-cb> ppisati, ah, could be, i think they use ubuntu-core or something similar, that might not ship these userspace bits
<ppisati> ogra-cb: so if they don't melt, i'm good with performance
<ogra-cb> heh, k
<ogra-cb> infinity, so whats your plan wrt nexus7 and flavours
<infinity> Not sure I have one.
<ogra-cb> currently an ubuntu desktop build takes 130-150min
<ogra-cb> if we switch doing tarball post processing on nusakan i guess we could get to 90min or so
<ogra-cb> i have definitive requests from kubuntu. lubuntu and edubuntu
<ogra-cb> and would like to provide something for them by A2 time
<infinity> We'll have to talk about it in a bit, then.
<infinity> It may require bringing up another buildd.
<ogra-cb> do you think there are chances for simply getting a second builder in place
<ogra-cb> ah, snap
<whatissixbynine> sup sup
<whatissixbynine> I've got a galaxy s3 i9300 (exynos 4212 quad core version, 1gb ram, no lte). Would like to get this going for it.. any advice?
<whatissixbynine> 4412 i meant, sorry!
<whatissixbynine> :/
<whatissixbynine> jeez guys
<whatissixbynine> how ya gonna pick up momentum if no one is ever around ;_;
 * ogra-cb sees 178 people in the channel
<ogra-cb> whatissixbynine, usually people react to questions in this channel, you should probably ask yours :)
<whatissixbynine> [09:18] <whatissixbynine> I've got a galaxy s3 i9300 (exynos 4212 quad core version, 1gb ram, no lte). Would like to get this going for it.. any advice?
<ogra-cb> thats not a question is it ?
<whatissixbynine> sure looks like it to me o.O
<ogra-cb> what exactlyy do you want to know ?
<whatissixbynine> its enough information to correctly ident it (was 4412 rather than 4212 cpu btw)
<ogra-cb> we dont offer any images for phones
<whatissixbynine> well, i don't see an ubuntu for general exynos, but i do see one for odroid-x
<ogra-cb> so its up to you
<ogra-cb> the userspace can surely run on that HW
<whatissixbynine> there was a great project with the motorola, vids and such, calls and texts working
<ogra-cb> not from here though
<whatissixbynine> so your saying that no one bothered to pull the stuff in?
<ogra-cb> there is a commercial project from canonical, if you mean ubuntu for android
<whatissixbynine> hm
<ogra-cb> of which there is nothing more available than these videos
<xnox> publically that is.
<ogra-cb> ubuntu-arm offrers current;y images for panda and beagleboard as well as the nexus7 tablet and the ac100 netbook
<ogra-cb> if you want anything else you need to build it
<ogra-cb> (oh, and i forgot highbank and armadaxp arches on server)
<whatissixbynine> hm
<whatissixbynine> yeah i figured i would have to build it, but i thought i could take something like the odroid and hack it towards this. anyway not sure how to start.
<whatissixbynine> so
<whatissixbynine> Would like to get this going for it.. any advice? where do i start?
<whatissixbynine> I can get chroot working, and i don't like it. vnc sucks.
<ogra-cb> well, userspace is usuallz always the same in ubuntu-arm
<whatissixbynine> just its crashing is a dealbreaker
 * xnox is not sure what "odroid" is that you are talking about.
<whatissixbynine> the ubuntu for android is what I am looking for
<ogra-cb> so you need to know how to modify the bootloader and shoudl provide your own kernel
<whatissixbynine> http://www.hardkernel.com/renewal_2011/main.php
<ogra-cb> ubuntu for android only exists in videos
<whatissixbynine> ok, so the repos for the packages i want arn't open source or openly available?
<ogra-cb> no idea if there are repos
<ogra-cb> there is surely code, but yeah, thats not public yet
<whatissixbynine> i dont really care if i got to build from scratch, i'm looking for a guide or howto or something
<ogra-cb> well, there is nothing yet
<whatissixbynine> well, how does one go about porting arm to a new device?
<whatissixbynine> one that's NOT new
<whatissixbynine> 99% of what i need driver wise should be in the odroid image
<ogra-cb> well, userspace is usually ported :)
<whatissixbynine> ?
<whatissixbynine> no comprende
<ogra-cb> as long as you have an ARMv7 device all of ubuntu will just run
<whatissixbynine> yes it is
<ogra-cb> what you need to get your specific device going is ehough insight into the bootloader and boot process and your own kernel build
<whatissixbynine> give me a sec
<ogra-cb> (as i said above a few lines)
<whatissixbynine> i'm having trouble with ur head
<ogra-cb> all of ubuntu is built and available for ARMv7 ... if you have a working setup you can just apt-get install whatever you want ... not different to any intel PC
<ogra-cb> but whats not in ubuntu is any support for your device
<ogra-cb> (bootloader and kernel)
<ogra-cb> everything above bootloader and kernel level is already there and usable ...
<ogra-cb> so to enable your device you need to get these two bits working
<whatissixbynine> ok
<whatissixbynine> that makes a bit more sense
<whatissixbynine> when I chroot into it, and do the vnc type install, that does not create an acceptable kernel/bootloader?
<whatissixbynine> that's actually a vm?
<ogra-cb> no, that uses the android kernel and bootloader
<ogra-cb> its a chroot, a VM emulates a machine
<whatissixbynine> right, thought so
<ogra-cb> the chroot just uses the android and runs an ubuntu rootfs inside
<ogra-cb> whcih also means that various bits indeed wont work
<whatissixbynine> got it
<whatissixbynine> hm
<Ethernin> yeah it would be great if you could just install full arm ubuntu with it's own kernel on android phones...
<Ethernin> like the Nexus 7
<whatissixbynine> yes
<whatissixbynine> Ethernin, it really should be possible. very annoying that it's even this hard. even more annoying that there's little to no open projects for porting to new devices
<RaYmAn> It's not hard at all. Getting basic linux/debian/ubuntu running on any arm device where you can flash your own kernel is trivial..Getting it running good is a whole other matter of course.
<whatissixbynine> RaYmAn, ok now your talking sir!
<whatissixbynine> i have ability to dual boot into secondary rom, so initially i would slam in there
<whatissixbynine> running good may indeed take a lot more, but i would be happy to get a start on
<whatissixbynine> currently downloading the android sammy source for my i9300 and gonna try to slam the linux image from odroid inside it
<RaYmAn> usually the easiest is just a couple of steps. 1) get a standard rootfs that doesn't start anything graphical - disable plymouth.Put it on an sdcard 2) build a kernel with fbconsole enabled and point cmdline at sdcard. fbcon should give some info
<whatissixbynine> not sure at all what i'm doing at this point, but i suppose i could update yall as we go
<whatissixbynine> right
<slangasek> hey, anyone here who could help with a gdb-multiarch issue?
<slangasek> am trying to run gdb-multiarch on x86_64 against an Ubuntu armhf corefile + executable; I swear this used to work, but I never remember quite how to do it so I'm not sure if gdb has regressed or if I'm just missing the magic option
#ubuntu-arm 2012-12-04
<mjrosenb> so I'm trying to update my chromebook to 12.10
<mjrosenb> and it is failing due to a checksum mismatch
<mjrosenb> W:Failed to fetch
<mjrosenb> gzip:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_quantal_main_binary-armhf_Packages
<persia> Try again now (it's been 5 minutes).  That usually means a mirror goes wonky, which is usually solved shortly for the mirrors identified by "ports.ubuntu.com"
<mjrosenb> I tried at like noon, and was getting it then
 * mjrosenb tries again
<mjrosenb> nopepe, still there
<mjrosenb> s/pe//
<mjrosenb> any other suggestions?
<persia> Maybe delete everything under /var/lib/apt/lists/ and run `apt-get update` again?  This should redownload everything, but it won't fix it if it's an issue with the checksums on the server.
<infinity> It won't be a mirror issue, that file has been static for months.
<infinity> Unless it's actually corrupt on the mirror he's hitting.
<infinity> Which is pretty unlikely for ports.
<infinity> Nope, looks fine from here.
<infinity> mjrosenb: Try persia's "delete the world and try harder" approach.
 * mjrosenb is running apt-get update as i type
<mjrosenb> well, that is strange
<mjrosenb> it says there is no new release
<mjrosenb> but dist-upgrade wants to upgrade 1,223 packages
<mjrosenb> and /etc/issue now says that I am running 12.10
<TheMuso> Are the nexus7 raring images working yet?
<persia> apt believes you to be running 12.10 with outdated packages (based on the content of /etc/apt/sources.list)
<mjrosenb> persia: sounds right.
 * mjrosenb wonders if this is going to attempt to install a new kernel
<mjrosenb> and how that is going to go if it does
<persia> It will only do so if you have a kernel package installed for which there is a newer package available in your currently configured archives.
<mjrosenb> I never installed a kernel package
<mjrosenb> although I should still get perf on here at some point or other.
<mjrosenb> and iirc, the kernel that this is running was just copied from chromium so we'd get nice driver support out of the box
<mjrosenb> great, now plymouth is throwing an assertion
<mjrosenb> hrmm
<mjrosenb> actually, I have absolutely no clue how to recover this system
<[mbm]> mjrosenb: nexus7?
<[mbm]> there was an open bug about that one; the console=none in the kernel commandline was causing issues, and plymouth had been disabled until it could be fixed
<mjrosenb> [mbm]: no, chromebook.
<mjrosenb> although I would not be surpred if this is the same assertion that the nexus 7 is throwing
<mjrosenb> so, I'd like to do something fancy like init=/bin/bash
<mjrosenb> but I don't actually know how to touch the kernel arguments on here.
<dholbach> good morning
<mjrosenb> morning.
<ppisati> http://lwn.net/Articles/526920/
<ppisati> Support for Tegra 2D hardware
<ogra_> ppisati, heh, you just missed the person intrested in it most :)
<ogra_> (though igues marvin24 has seen it already)
<ogra_> marvin24, <ppisati> http://lwn.net/Articles/526920/
<ogra_> ppisati, sadly tegradrm doesnt work with the binary driver yet
<ogra_> (afaik)
<marvin24> ogra_, ppisati: yeah, this will take a *long* time
<ogra_> right, and thanks to our new desktop policy we are bound to the GLES drivers
<ogra_> so even if it would land tomorrow, we couldnt use it
<lilstevie> cause of unity
<ogra_> well, compiz, but yeah
<marvin24> what abount software gles?
<marvin24> *about*
<ogra_> i didnt get it working on the nexus yet
<ogra_> i have it working on the chromebook and dont know why :)
<mjrosenb> does anyone know how to change the parameters that the kernel gets on a chromebook?
<marvin24> ogra_: strange ...
<ogra_> mjrosenb, probably hrw
<hrw> mjrosenb: you have to sign kernel and at that stage you can change cmdline
<hrw> easy
<hrw> mjrosenb: >
<hrw> >
<hrw> >
<hrw> ops
<hrw> mjrosenb: https://plus.google.com/u/0/109993695638569781190/posts/34PYU79eUqP
<ogra_> so just get a pen then :P
<hrw> ogra_: any progres on teaching plymouth to check proper console=?
<ogra_> hrw, it isnt the console parameter at all :)
<hrw> or whatever
<ogra_> hrw, it is a missing piece of console-setup
<hrw> ogra_: tell me more
<ogra_> if you build your initrd with FRAMEBUFFER=1 set in the initramfs.conf, plymouth works fine
<hrw> I do not have initrd
<ogra_> i'm working on tracking it down to a specific function in console-setup, once i have that well just add it to the plymouth upstart job and it should work
<ogra_> we'll
<mjrosenb> hrw: the issue is I cannot currently boot into ubuntu
<ogra_> hrw, right, initrd doesnt matter its just that you can fix it by having an initrd that runs console-setup
<hrw> mjrosenb: tell me more?
<ogra_> which means running that console-setup bit from an upstart job before plymouth starts should work as well
<mjrosenb> hrw: I attempted to upgrade from 12.04 to 12.10 with the standard do-dist-upgrade, and now it plymouth just thros an assertion, and I cannot continue booting.
<hrw> mjrosenb: boot chromium, mount ubuntu, cd ubuntu/etc/init/;rm plymouth*;reboot
<hrw> works just fine
<ogra_> no, the biuts will re-appear on next update
<hrw> or s/rm plymouth*/for f in plymouth*;do echo manual > ${f}.override/
<hrw> or s/rm plymouth*/for f in plymouth*;do echo manual > ${f}.override;done/
<ogra_> drop the rm's
<mjrosenb> iirc, I can boot into chromium by just turning on the validation again?
<ogra_> yeah
<ogra_> the above looks fine
<hrw> mjrosenb: better is keep chromium kernel in KERN-A and boot ubuntu with KERN-B or KERN-C
<mjrosenb> *nod*
<hrw> so all you need is change of partition priorities
<hrw> works just fine
<mjrosenb> hrw: so I didn't touch the kernels, I just ran do-dist-upgrade; apt-get dist-upgrade
<mjrosenb> err, maybe it wasn't do-dist-upgrade
<mjrosenb> do-release-upgrade?
<hrw> mjrosenb: do update to 13.04
<mjrosenb> I tab-completed it
<ogra_> do-release-upgrade is the right tool
<mjrosenb> hrw: is support better in 13.04?
<ogra_> yes
<hrw> mjrosenb: s/better//
<ogra_> hrw, up0loads packages and fixes all the time :)
<hrw> 12.10 does not know anything about chromebook
<mjrosenb> hrw: does 12.04?
<hrw> you are joking or not?
<ogra_> the 12.04 that you can install with that weird script that downloads 50 tarballs will work
<ogra_> (since it is hacked up)
<mjrosenb> yeah, that is how I installed it to begin with.
<hrw> I used python to calculate offsets and did setup with linaro image
<hrw> that's why my chromebook may lack some packages
<hrw> I am waiting for 32GB microsd card to arrive so will have pristine ubuntu install on it
<hrw> unless courier would bring me another chromebook...
<hrw> but this will rather not happen
<mjrosenb> is there a microsd card reader other than the full-sized sdcard on the side?
<hrw> there are small usb readers
<hrw> which sticks out for 3mm from socket
<mjrosenb> ahh.  I've seen those
<mjrosenb> this one that holds the microsd card so it will eject *into* the computer if you could theoretically eject it when it was inside the computer?
<hrw> no idea - order not arrived yet
<mjrosenb>  this mount command is taking quite a while to complete...
<mjrosenb> aaand, ^C does not do anything on this terminal :/
<mjrosenb> ok, problem solved
<mjrosenb> i assume I need to re-run |sudo cgpt add -i 6 -P 5 -S 1 /dev/mmcblk0| in order to get this machine to want to boot into ubuntu again?
<hrw> -T5
<hrw> or -T1 at least
<mjrosenb> ok, this time, it finished the kernel initializations, then "mountall: Disconnected from Plymouth" and is now hung there
<mjrosenb> what does that do?
<hrw> sets 'tries' field
<mjrosenb> oh, so it'll boot into ubuntu N times, then go back to cros?
<hrw> no, thats matter of priority field
<hrw> you have 3 fields: tries, priority, successful
<hrw> priority == which kernel boot first and which if first one fail
<hrw> successful = this kernel boots at all
<ogra-cb> i think i'll go with something like the second one here http://tbreak.com/tech/2012/06/quick-look-apacer-32gb-usb-3-0-memory-sticks/
<ogra-cb> the values arent stellar but still far beyond USB 2.0
<ogra-cb> (for the chromebook rootfs)
<hrw> ogra-cb: nice :)
<ogra-cb> i havent found a place to buy it yet though
<hrw> http://www.shopmania.co.uk/external-memory/p-apacer-ah152-super-mini-usb-drives-16gb-48812413 but 16GB only
<ogra-cb> it is small enough to not turn into a lever that opens the netbook case if you press it :)
<hrw> I have to connect my usb3.0 harddrive and check speed
<ogra-cb> you should see between 80 and 120M/s
<ogra-cb> i personally think even 60 are awesome alreadfy though :)
<RaYmAn> ogra-cb: it's just a pity you can't use usb 3.0 to boot kernel from :(
<ogra-cb> i dont care
<ogra-cb> as long as my rootfs runs off a fast device
<ogra-cb> and as long as i *can* boot a kernel somehow :)
<hrw> RaYmAn: you put kernel in KERN-C on internal and boot rootfs on usb3 - fine
<RaYmAn> sure
<hrw> internal emmc has 59 MB/s average read in gnome-disks bench
<hrw> ech. gnome-disks fails to bench my usb3 drive
<hrw> on chromebook
<ogra-cb> file a bug :)
<hrw> hdparm has 92MB/s
<hrw> Bug #1081019 already exists
<ubot2> Launchpad bug 1081019 in gnome-disk-utility (Ubuntu) "Benchmark for Harddisk fail" [Undecided,Confirmed] https://launchpad.net/bugs/1081019
<hrw> same hdd connected to desktop has 147 MB/s average
<hrw> I miss "maximize to whole available desktop space" action in WM
<ogra_> which WM ?
<hrw> kwin
<fmoreau> hi. Does anybody know why ext4 fs is prefered over a "flash" fs such as ubifs ?
<suihkulokki> fmoreau: for a flash file system, such as ubifs, you need a raw interface to the flash. most device these days instead have a MMC interface where you can only put block filesystems, such as ext4
<sfeole> o/
<ogra_> yippie !
<ogra_> slideshow is back
<ogra_> xnox, hmm, so that onboard behavior is really bad in oem-config since the switch to compiz
<ogra_> i actually have to reboot to make typing work
<ogra_> plars, janimo, so i dont get why you need adbd instead of just using ssh over usbnet
<janimo> ogra_, no idea if usbnet works I never used it
<ogra_> it does
<ogra_> pretty agressively even :)
<janimo> ogra_, if the current kernel needs some patch or config options enabled feel free to ping the kernel team :)
<janimo> if not then a wiki entry would be nice
 * ogra_ accidentially built it in into one of his test kernels ... made my desktop NM go crazy :)
<janimo> I never used this feature
<janimo> it should not interfere with normal work though and not be buggy :)
<plars> ogra_: same, never tried usbnet. If you have some pointers I'd like to hear more about it though.  adb is nice from the perspective of being a similar tool for what a lot of people would have normally used there, and has some neat features, but I'm not really stuck on it
<ogra_> it doesnt
<ogra_> but NM shows you it tries to auto establish the network (it only shows you a wired connection)
<plars> ogra_: will usbnet have issues since the n7 might be on a server, potentially with several other n7's attached doing the same thing?
<ogra_> it just took me quite aq while to find out that this behavior comes from the attched nexus (which didnt have the NIC up )
<ogra_> plars, usbnet just behaves like any other network
<plars> ogra_: So I'd need to be able to bring up those connections and distinguish between them
<ogra_> just that your device is called usb0 and that the wire is actually a usb connection to the next machine
<plars> ogra_, janimo: so it sounds like we just need a kernel with it turned on, and give it a try
<ogra_> right
<janimo> ogra_, and it shows up depending on whether you connect the nexus to a laptop or not?
<ogra_> i simply assume you want to issue more than just a reboot via ssh
<ogra_> janimo, plugging in the USB connection with usbnet *buioltin* will always try to bring up usb0 (and the desktop/laptop side for it)
<ogra_> indeed you shouldnt build it in :)
<ogra_> but load it on demand as module
<plars> ogra_: I don't actually have NM running on the ubuntu-server they are attached to currently
<ogra_> well, you want to attach more of them
<ogra_> i would actually runs something like dnsmasq
<ogra_> so you can hand out IPs to them via dhcp
<ogra_> and preseed usb0 properly for that
<xnox> ogra_: why does a reboot help after flashing in oem-config? a reboot is still treated as first boot if oem-config is not completed?
<xnox> ogra_: is it a problem with fastboot reboot then?
<ogra-cb> xnox, nope. rather with some ubiquity-dm race or onboard
<ogra-cb> and yes, oem-config-remove is run last, it removed ubiquity-dm ... as long as that didnt run you will always end up in oem-config on next boot
<ogra-cb> *removes
<xnox> ogra-cb: right so if I reboot a few times sometimes onboard is fine and sometimes it isn't? but doesn't ubiquity launch onboard anyway ...
 * xnox will have to play with it.
<ogra-cb> err no
<ogra-cb> if you reboot onboard will always work fine
<ogra-cb> it just doesnt if it boots through from the tarball installer
<ogra-cb> i could add another reboot to the process but imho we already have to many (especially with the one we will need for the hostname later)
<plars> janimo: so from what I'm reading, it looks like it's could just be CONFIG_USB_ETH that we need to turn on?
<janimo> plars, ogra-cb should know as he had a kernel with that enabled. I am not certain what other (if any) options are required
<mjrosenb> hrw: ping
<mjrosenb> unrelatedy, if I don't want oneconf or update-manager running, what is the right way to turn them off?
<mjrosenb> ok, so I'm going to assume that the best way forward at this point is to just go through the chrubuntu setup again, since all of the data I care about is on an external sdcard
<hrw> mjrosenb: pong
<mjrosenb> hrw: should I try to get 12.10 working, or should I just give up, re-install from the crazy tarball-downloading script, then try to update directly to 13.04?
<hrw> mjrosenb: I suggest skipping 12.10
<mjrosenb> well, the plann was to get 12.10 booting, then immediately upgrade to 13.04
<hrw> mjrosenb: make a backup, upgrade to 13.04 directly. if fail - restore backup
<mjrosenb> hrw: that shouldn't be too hard, the partitions are small enough that I can dd them both onto an external sd card.
<philhug> is anyone familiar with the rockchip rk3066 devices? e.g. those chinese hdmi sticks like MK808?
<philhug> and does anyone have a complete kernel source? the chinese manufacturers don't seem to care much about the GPL.
#ubuntu-arm 2012-12-05
<mjrosenb> ok, I'm not entirely sure how to back up my chromebook's ubuntu install
<mjrosenb> normally, I'd just boot into another OS, then dd if=/dev/root of=/backup, but there isn't another OS that I can easily boot into
<mjrosenb> well
<mjrosenb> I guess I could boot into cros
<mjrosenb> ok, are there directions for updating the chromebook to 13.04?
<sfeole> mjrosenb: regarding your 1st question above, what about using rsync ?
<sfeole> mjrosenb: regarding your 2nd question about updating to 13.04, you could always add the raring ppa's to your /etc/apt/sources.list and upgrade that way. Of course after you do a full backup ;)
<sfeole> mjrosenb: if your looking for an 'official' announcement then I would have to say, google is your friend...
 * sfeole is thinking about purchasing a chromebook
<mjrosenb> sfeole: i've been happy about it thusfar
<sfeole> mjrosenb: the last few days I was watching some youtube videos. I was impressed with the speed and video playback
<mjrosenb> sfeole: I didn't want to use rsync because I had no guarantee that the files would be consistent, since there are lots of things accessing everything
<mjrosenb> sfeole: now, I suspect that the ubuntu update scripts have *no* clue how to update the kernel
<sfeole> mjrosenb: mmmm , i see
<mjrosenb> and updating to 12.10 did not go spectacularly
<mjrosenb> so I suspect I also need to know how to update the kernel
<sfeole> mjrosenb: I see what you mean, I just came across this while googling, http://bit.ly/rFDYjt
<mjrosenb> sfeole: that does not seem to be talking about updating an already installed system, nor about a kernel
<sfeole> mjrosenb: no it does not, just general installation..
<sfeole> mjrosenb: If I catch any good articles relating to your problems during my research I'll be sure to let you know
<mjrosenb> I've googled a bunch, but mostly find how to install it
<mjrosenb> and even less about arm chromebooks.
<mjrosenb> but yes, thanks in advance if you find anything!
<dholbach> good morning
<dholbach> ogra_, did you check out the unity build didrocks mentioned?
<ogra_> dholbach, i will once everything is built
<ogra_> libunity is still missing ...
<dholbach> I tried the raring image earlier and found it impossible to enter anything at all :)
<dholbach> so I reflashed with quantal and will dist-upgrade and then install it manually
<ogra_> dholbach, yeah, havent filed that bug yet, a reboot fixes it
<dholbach> it didn't for me
<dholbach> I tried external keyboard and onboard
<dholbach> no dice
<ogra_> it only happens when the installer boots directly from the tarball installer into X
<ogra_> the subsequent boots it should work fine
<dholbach> I tried, it didn't :/
<ogra_> (onboard that is, i dont use external kbds anymore here)
<dholbach> but I'm happy to try again some other time
<dholbach> ok, upgrade is running, I'll take the dog for a walk now
<ogra_> but touches ... i.e. button presses worked ?
<dholbach> yes, but I couldn't anything into any of the textboxes
<ogra_> or did no input work at all
<ogra_> k
<ogra_> so its the same bug, just worse for you
<DogP> is there a setting to make kernel output go to the screen or not?  running Debian on my tablet outputs text during boot, Ubuntu shows a black screen until the login prompt
<ogra_> i wonder why, HW is the same
<dholbach> no idea
<dholbach> I'll be back in a bit
<ogra_> yep, walk the dog
<ogra_> DogP, ubuntu defaults to having "quiet" and "splash" on the kernel cmdline
<ogra_> if you remove them you should get some output
<DogP> ogra_: ah, I'll check that... thx
<ogra_> xnox, heh, if ubuntu archive would only accept source uploads the nvidia and ati users would be severely screwed :)
<xnox> ogra_: software != hardware drivers.
<ogra_> well, we have enough binary only software in multiverse as well
<ogra_> the archive only accepts source packages, but doesnt care whats inside them
<xnox> ogra_: OpenERP is pure python modules. And if a person mentions "no change debs" it's something that will be hard to support with ever changing python & OpenERP versions.
<ogra_> oh, yeah, i wouldnt want him to upload his cruft :)
<ogra_> but your statement wasnt right, we have tons of binary only software
<xnox> ogra_: sure sure. Do we have binary only software in multiverse? /me thought it was more about restricted licenses (e.g. education only)
<ogra_> multivers means everything that is distributable, no matter what format
<ogra_> as long as the license allows redistribution
<xnox> ogra_: I have tried to choose my language carefully =))))) (e.g. to discourage but still stay on the slippery slope)
<xnox> "source uploads only" as in .changes is source only ;-)
<ogra_> yeah
<xnox> ogra_: e.g. I have seen people put debs in a native source package and in debian/rules do "tadah" here is your package.
<ogra_> lol
<ogra_> not in any archive i hope
<ogra_> janimo, plars, so i played a bit with the gadget stuff ... you cant compile it as a module (the power supply needs it builtin, seems power is routed through gadget) .... using the composite or usbnet option makes NM on a desktop you attach to try to initiate a usb0 point to point connection, that looks quite weird so i think we cant do that
<ogra_> janimo, plars, what works really well is the cdc_serial gadget though, it simply gives you a serial device if you connect the USB cable ... serial is probably a bit harder to script than ssh though
<janimo> ogra_, I know about the failing build due to power supply that is why I did not pursue it last time
<janimo> if CDC works that is ok too
<janimo> as I said, I never used any of these gadgety functionality with overlapping use cases
<mjrosenb> ok, silly problem-- my laptop does not seem to be setting the correct dns server
<ogra_> janimo, plars http://paste.ubuntu.com/1412283/
<mjrosenb> I'm decently sure that the dhcp server is broadcasting it correctly
<mjrosenb> is there any way to see what the dhcp server is actuall sending?
<ogra_> janimo, plars, thats the needed changes, /etc/init/ttyS1.conf can be shipped in ubuntu-default-settings-nexus7
<ogra_> mjrosenb, logs :)
<mjrosenb> ogra_: what logfile would that be in?
<janimo> ogra_, any chance you tell that to kernel team as in case they want extra info they come back to bug you? :)
<ogra_> dunno
<ogra_> grep DHCPOFFER /var/log/*
<janimo> such as is nothing lost when disabling g_android?
<ogra_> janimo, sure, just wanted to hear from plars if serial is enough for him before i move on
<ogra_> janimo, nah, nothing lost apart from replacind adbd with getty on serial :)
<ogra_> that feels a lot more "linuxy" imho :)
<janimo> ogra_, but this could not be shipped turned on by default to help devs who have broken wifi or no USB peripherals?
<mjrosenb> hahha.
<mjrosenb> this image still has logs from the person who set up the image.
<janimo> having something that works by default even if not adb would be great
<ogra_> janimo, why not ?
<janimo> ogra_, just asking :)
<janimo> if it can we should I say
<mjrosenb> ok, there is "nameserver 192.168.0.1" in the logfile
<ogra_> it shouldnt do any harm to have an extra serial port on by default
<mjrosenb> but not in /etc/resolv.conf
<mjrosenb> wtf
<janimo> then we can stop recommening USB keyboard if someone wants to debug their system
<ogra_> janimo, definitely
<mjrosenb> ok, I killed dnsmasq, and /etc/resolv.conf still has 127.0.0.1 and 8.8.8.8
<mjrosenb> but not the one that dhcp specified
<dholbach> hum, I get "Wi-Fi Networks - device not ready" in network manager
<dholbach> maybe you're discussing the same problem just now?
<mlankhorst> I was testing the raring iamge on the nexus7, but it seems that unity is showing only corruption..
<mlankhorst> background image is fine, all panels are just noise
<dholbach> mlankhorst, I get the same here - do you use the unity daily build ppa?
<mlankhorst> I just used the instructions for installing the raring image
<dholbach> ok
<dholbach> unity in the daily build ppa just finished building - maybe that'll fix it
<dholbach> I'll just need to fix my net connection to see if it makes it work
<mlankhorst> does the image enable the ppa?
<dholbach> no, not AFAIK
<dholbach> it's ppa:ubuntu-unity/daily-build (https://launchpad.net/~ubuntu-unity/+archive/daily-build?field.series_filter=raring)
<mlankhorst> hm how do I even enable it then.. corruption is making it impossible :-)
<dholbach> attach keyboard and ctrl-alt-t
<mlankhorst> oh right
<ogra-cb> use onboard :)
<ogra-cb> its in the panel, just click blindly until you find it
<ogra-cb> (then use ctrl-alt-t in onboard and install openssh-server)
<dholbach> ogra-cb, I get "Wi-Fi Networks - device not ready" in network manager
<dholbach> not sure what to do about it
<ogra-cb> dholbach, did you reboot already ?
<dholbach> yes
<ogra-cb> weird, i dont get that here
<dholbach> man, I want your Nexus7
<dholbach> everything just magically works there
<dholbach> "reboot" seems our equivalent of 2004's http://paste.ubuntu.com/1412338/ :)
<ogra-cb> well, the HW should be the same for all but the 3G devices
<dholbach> no 3G here
<ogra-cb> lol
<dholbach> and after a reboot it's still unhappy
<ogra-cb> geez, where did you dig that one up
<dholbach> 3mal darfste fragen :)
<ogra-cb> heh
<mlankhorst> I'll let you know, it's not exactly acting fast
<dholbach> ogra-cb, which kernel are you running?
<dholbach> -7 or -8?
<ogra-cb> YIPPIE !!!!
<ogra-cb> the ppa packages work !!!!
<ogra-cb> dholbach, currently some self compiled one that has serial gadget support enabled
<dholbach> ogra-cb, could you try to boot the current raring one and see if that breaks your network?
<ogra-cb> but its originallz the -8 package i think
<dholbach> mlankhorst, does wifi work for you with the -8 kernel?
<ogra-cb> that is the latest raring image
<ogra-cb> installed last night
<ogra-cb> dholbach, ome-config didnt offer you to set up WLAN ?
<ogra-cb> *oem
<dholbach> ogra-cb, it's a dist-upgrade - as I said earlier: installing the image didn't work for me (no keyboard input)
<dholbach> (or at least I couldn't enter anything into the text boxes)
<ogra-cb> upgrade with the PPA still enabled ?
<ogra-cb> i wonder if that could break something
<dholbach> no, update-manager disabled it
<ogra-cb> what definitely works is if you ignore oem-config and actually use NM applet to set up wlan
<ogra-cb> at least for me
<ogra-cb> non ubiquity windows seem to get the focus just fine
<ogra-cb> so i did set up wlan via NM, rebooted and onboard just worked
<dholbach> nm-applet tells me that "device not ready"
<dholbach> whatever that means
<ogra-cb> i'm talking about the installer here
<ogra-cb> oh
<dholbach> yes, I realise you're talking about the installer - I didn't use it :)
<ogra-cb> i have an idea what coudl eb wrong for upgrades (no easy way to solve it though)
<dholbach> ok, I'll try flashing again in a couple of days  :-(
<ogra-cb> the linux-firmware-nexus7 package isnt seeded, upgrades wont pull it in
<dholbach> yes, it's not installed
<dholbach> can't I just copy it over with a usb stick?
<ogra-cb> dholbach, in a couple of dazs i'll be on vacation, if you want to debug it and have it fixed before end of year you should ebug it now :)
<ogra-cb> indeed you can just copy it over
<dholbach> yeah, but I have quite a lot of other tasks too :/
<dholbach> and I spent all morning on this
<dholbach> ok
<dholbach> I'll try that then
<infinity> ogra-cb: It shouldn't be seeded...
<ogra-cb> infinity, well, but depended on by something or so
<ogra-cb> i know it shouldnt be seeded, thats why it isnt :)
<ogra-cb> i assume making ubuntu/defaults/nexus7 depend on it should work
<infinity> By the nexus7 kernel metapackage, yes.
<ogra-cb> or the meta, yeah
<ogra-cb> not sure whats harder to hack up ... we shouldnt make it a dep though
<ogra-cb> but a recommends
<infinity> Why not a dep?
<dholbach> ok, package installed - let's see if that makes it work
<infinity> linux-firmware is a dep of all linux-image metapackages.
<ogra-cb> infinity, so the hardcode free SW guys can use it without the firmware (and make the free drivers work)
<dholbach> ogra-cb, I'm happy
<dholbach> is there a bug report for this, or will this be fixed soon?
 * ogra-cb hugs dholbach 
<ogra-cb> feel free to file it
<infinity> ogra-cb: Fair enough.  Can make it a recommends of the linux-image, then.
 * infinity does so.
<ogra-cb> ah, no need to file it then
<dholbach> great, thanks
<ogra-cb> i guess i can hack it out of livecd-rootfs then
<infinity> ogra-cb: Uploaded.
<ogra-cb> yay, thx
<dholbach> we still need an onboard release in raring
<dholbach> the upstream folks generally seemed receptive to the idea - I'll ping them again today
<ogra-cb> well, onboard works for me
<ogra-cb> oh, for the versioning and upgrades ?
<dholbach> yes
<ogra-cb> yeah
<dholbach> new unity makes us happy
<dholbach> :-D
<dholbach> mlankhorst, ^
<ogra-cb> yep, works quite okayish
<ogra-cb> seems eth workspace switcher has some issue though
<ogra-cb> (no icon and it seems to hang after using it a few times for me)
<ogra-cb> oh, its not the W|S switcher that hangs, the mouse is stuck in grab mode
<ogra-cb> so thats the old xinput issue
<infinity> The workspace switcher is sketchy on a desktop machine, nevermind introducting touch input. :/
<ogra-cb> yeah, but its not the switchers fault in this case
<ogra-cb> i have a firefox window stuck to my mouse atm
<infinity> I disagree.  The switcher's default it to attempt to grab if you left-click, not switch.
<infinity> And left-click is all you have.
<ogra-cb> luckily the powerbutton causes a propwe shutdown after 60sec
<ogra-cb> *proper
<infinity> It's a subtly annoying behaviour on desktop machines that's amplified on touch.
 * ogra-cb wonders why we have the system settings in the launcher as well as in the session indicator
<ogra-cb> seems redundant
<infinity> We.... Do?
<ogra-cb> yeah
<infinity> I don't here.
<infinity> Maybe you pinned it by accident? :P
<ogra-cb> i have the gear with the wrences in a fresh nexus7 install
<infinity> Weird.  I guess it could be a fresh install versus upgrade thing, since this is a raring machine that used to be precise.
<infinity> And I absolutely agree it shouldn't be there if it is.
<ogra-cb> well, we had it in the quantal images too
<ogra-cb> at least on the nexus
<ogra-cb> the math of upower seems really wrong
 * ogra-cb has 93% battery left according to it ... which results in 1.7h (!?!)
<infinity> Maybe you've killed your battery already? :P
<ogra-cb> nah, i think its the new kernel or rarings fault
<vibhav> Man, I really want a nexus 7 now :(
<ogra-cb> why dont you have one yet ?
<ogra-cb> iirc your manager even sits on the spare ones
 * sfeole wonders if the nux fix has landed for raring yet
<ogra-cb> sfeole, in the daily ppa .... it will get uploaded to the archive soon
<ogra-cb> (the unity ppa that is)
<sfeole> ogra-cb: thats great news
<ogra-cb> with luck it makes tomorrows image
<sfeole> ogra-cb: which ppa is the unity-team daily?
<mlankhorst> dholbach: yeah I forgot to hit send :-)
<mlankhorst> still a bit glitchy or slow with redraw though, not sure yet
<sfeole> dah i found it, in /staging
<ogra_> sfeole, well, the binaries are just getting published into raring
<ogra_> you shouldnt need the ppa anymore after thats done
<sfeole> ogra_: ack
<plars> ogra_, ogra-cb, janimo: serial is better than nothing at all, but it's not ideal. It lacks an easy way to transfer files. adbd or ssh would be much nicer.
<plars> ogra_, ogra-cb, janimo: how far away from working do you think adbd would be, given that janimo says he's had it working in the past?
<ogra_> plars, i simply heavily dislike the fact to depend on any android stuff ... the kernel patch was just sent to the kernel ML to change to g_serial
<janimo> plars, I think adb could be made to work if someone gave it a day of work since we know others have done it
<janimo> ogra_, is the new patch preventing adb from working even in theory?
<janimo> plars, adbd would need to be packaged too though
<ogra_> janimo, no idea if adb can attach to a serial connection
<janimo> ogra_, I see no problem leveraging android related free software, especially since it is for debugging and testing, not something that androidized the Ubuntu experience
<ogra_> janimo, well, the proper fix imho would be if someone fixed the kernel to accept gadget support to be modular
<janimo> ogra_, if the g_android functionality is removed then adbd will not work over USB as it could now? In this case I think it is a regression even if we did not get it to work
<ogra_> i have no idea about adbd
<janimo> I thought the patch introduces no regression whatsoever
<vibhav> ogra-cb: Actually, my parents wouldnt buy me one :(
<ogra_> janimo, how do you mean regression ?
<ogra_> tecnically i think the target of what we are doing here is to make ubuntu work right ... androidizing ubuntu instead of fixing the setup to just work with linux oboard bits doesnt seem right to me
<janimo> ogra_, as in not supporting something the unpatched kernel does
<janimo> with the current one adbd has at least the chance to work if someone figures it out
<ogra_> what does the unpatched kernel do ?
<ogra_> which adbd ?
<ogra_> we dont have the userspace
<janimo> stock adbd binary from android
<ogra_> we do have the userspace to support g_serial
<ogra_> (we even have the userspace to support ssh over usbnet ... the issue is the androidization of the kernel that avoids us from modularizing the gardget stuff)
<ogra_> instead of poking at the symptoms, someone should fix the cause and sort the kernel issue here
<ogra_> plars, xz/yz shoudl work fine for transferring files over serial
<ogra_> (or however the tools lrzsz ships are called)
<plars> ogra_: those are some things I haven't used since my bbs days :)
<ogra_> and the good thing is that you can have that access in initrd already
<plars> but yes, might be ok as long as we don't have to transfer anything too huge.  Probably mostly just logfiles and the sort I *think*
<ogra_> so you can have initrds with scripts you can trigger for whatever thing you do (re-flash for example)
<ogra_> plars, oh, note also that there was a kexec patch added recently, you might be intrested in that one for testing setups
<ogra_> hmm, so we still need a fix for bug 1055949
<mjrosenb> is there someone in particular that deals with firefox on ubuntu/arm, or do the people that deal with firefox/x86 also deal with arm issues?
<ubot2> Launchpad bug 1055949 in unity (Ubuntu Raring) "Unity panel shadow appears as solid black bar on GLES/ARM (Pandaboard, Nexus 7)" [Medium,Confirmed] https://launchpad.net/bugs/1055949
<ogra_> mjrosenb, yes
<ogra_> :P
<ogra_> chrisccoulson, ^^^ a customer for you
<mjrosenb> the overlap between #ubuntu-arm #pandaboard and #linaro is impressive :-p
<ogra_> #pandaboard often enough just redirects people to us
<ogra_> #linaro is kind of upstream from #ubuntu-arm perspective
<mjrosenb> I know, that is why I'm in here
<hrw> ;D
<mjrosenb> I don't actually understand the relationship between linaro and ubuntu
<hrw> there is also #debian-arm on oftc but less popular
<ogra_> linaro does core upstream stuff
<ogra_> ubuntu assembles a distro
<hrw> mjrosenb: Linaro works on making linux on arm the best possible. Ubuntu (as a distro) makes use of it
<hrw> mjrosenb: and Linaro makes use of Ubuntu as source of packages for test images
<ogra_> i.e. linaro cares upstream for kernels, bootloaders, GLES support, toolchain
<hrw> multimedia, graphics etc
<ogra_> ubuntu just grabs these bits, applies glue and bling and whoops, there's a distro :)
<mjrosenb> gotcha.  thanks.
<infinity> hrw: I dunno if #debian-arm is "less popular", or just has a different focus.
<infinity> hrw: We're almost always talking about toolchain type scary in there, and this channel is more about device enablement and pretty fluff.
<ogra_> definitely it is annoyingly on a different network
<infinity> ogra_: I consider it annoying that Ubuntu settled/stayed on freenode, to be fair. :P
 * ogra_ used to be there when it was still freenode
<ogra_> well, debian used to be here too
<infinity> Yes, a very, very long time ago.
<infinity> June 4th, 2006 was the switch, apparently.
<ogra_> yeah, i remember it
<ogra_> thanks for making me feel old !
 * ogra_ was already suspecting the grey hair isnt a morning hallucination
<hrw> infinity: and I like that split
<janimo> marvin24, did you get a chance to look at ac100 patches to the mainline kernel as a possibility of syncing to 3.8 for 13.04?
<marvin24> janimo: I wanted to wait until 3.7 is out before posting patches against 3.8
<janimo> marvin24, sounds good
<marvin24> you can allways get patches against -next at http://gitorious.org/~marvin24/ac100/marvin24s-kernel/commits/for-next-thierry btw
<marvin24> janimo: ^^^
<marvin24> if you want to try out
 * ogra_ thought the binary drivers wont work with mainline 
<janimo> marvin24, thanks.
<janimo> I wish my ac100's wifi wasn't broken though
<ogra_> janimo, i thought you did the HW fix
<janimo> ogra_, nope
<janimo> I was not sure it was a hw issue and I have not reinstalled since. But it probably is even if it appeared out of the blue
<ogra_> it most likely is
<ogra_> geez that new nexus kernel really misbehaves wrt battery sometimes
<ogra_> "your system will shut down soon if you do not apply power to it (13min, 93%)"
<ogra_> inbetween it dumps to something like 8% but then it shows several hours left
<ogra_> and sometimes it just works like it did with the old kernel
<ogra_> very weird
<marvin24> ogra_: you don't need binary driver if you have tegra drm
<ogra_> marvin24, for GLES and video playback ?
<marvin24> for this children game stuff, yes
<marvin24> on the other hand, nvidia tries to upstream nvhost stuff to make it going with their binary drivers
<ogra_> yeah, i was expecting that
<marvin24> so we will get both, tegra drm, open source ddx and binary drivers for 3d/video decode
<ogra_> move to the community what you can, only keep the actual proprietary bity yourself :)
<ogra_> *bits
<ogra_> but its not there yet
<marvin24> well, I guess it's not decided yet if they also open up 3d stuff
<marvin24> I guess that depends on user demand
<marvin24> or maybe some nouveau people will step in once the user interface is in the kernel
<marvin24> *user api*
<ogra_> well, even if they dont
<ogra_> having the 2D stuff maintained by the community simply saves money if you can flange your 3D stuff on top
<ogra_> so they dont need to care for the kernel side
<marvin24> yes, it reduces the maintaince burden
<marvin24> even nvidia started to recon this
<ogra_> they stole that ingenoius concept from robclark ;)
<marvin24> but it also cause more work at the beginning
<ogra_> yeah, definitely
<ogra_> but pays off massively in the end
<marvin24> also device tree makes things lot of easier
<marvin24> but also needs carefull thinking at the beginning
<Zero_Chaos> I'm going to buy ODROID-X2, anyone know a good reason I shouldn't?
<mjrosenb> chrisccoulson: ping?
<Ethernin> Hey guys, I'm sure this gets asked every day but does anyone know if the ubuntu install for the Nexus 7 32GB with 3G works yet?
<Ethernin> last time I tried it a couple weeks ago it didn't work, just wondering if there's been any progress since?
<Ethernin> thanks
<tassadar_> Ethernin: 13.04 should work if I'm not mistaken
<mjrosenb> anyone know what timezone chrisccoulson is in?
<mjrosenb> or what time he is likely to respond?
<tassadar_> whois says he's from germany
<infinity> tassadar_: No, /whois says he's connected to a server in Germany, which doesn't mean much, since the servers are on a DNS round-robin.
<RaYmAn> whois chrisccoulson
<infinity> mjrosenb: He's in the UK.  Not sure what his usual working hours are.
<RaYmAn> that was silly.
<RaYmAn> :)
<mjrosenb> infinity: thanks.
 * tassadar_ will keep his mouth shut now, it'll be better for everyone)
<Ethernin> tassadar_, hey thanks man i'll try it
<achiang> janimo: gave you https://bugs.launchpad.net/ubuntu-nexus7/+bug/1070770
<ubot2> Launchpad bug 1070770 in ubuntu-nexus7 "bluetoothd dies with glibc malloc memory corruption when used with brcm_patchram" [Medium,Confirmed]
<janimo> achiang, I wonder if I need some BT peripherals or an android phone would do for debugging
<achiang> janimo: you don't own any BT devices? :)
<janimo> achiang, hey I only got my first smartphone 3 months ago what do you want? :)
<achiang> heh
<janimo> I'll get some BT headset if it is needed fo debugging though
<achiang> janimo: alternative is to spin up a kernel and ask people to test it
<achiang> janimo: i'm sure you'll find lots of interested helpers
 * janimo checks the bug details
#ubuntu-arm 2012-12-06
<mjrosenb> huh, this is interesting
<mjrosenb> on my chomebook, the status bar seems to know about my battery
<mjrosenb> but acpitool is clueless
<sfeole> janimo: i can take a look at the kernel tomorrow AM
<lilstevie> mjrosenb, have a look at the output from "upower -d"
<lilstevie> mjrosenb, that is where the power applet gets the data from
<mjrosenb> lilstevie: most excellent.
<mjrosenb> lilstevie: has this replaced acpi?
<lilstevie> mjrosenb, arm doesn't have acpi
<lilstevie> Well, it is possible those Windows RT tablets do, but current ARM hardware does not
<mjrosenb> well
<mjrosenb> that makes sense
<TheMuso> Here is hoping that acpi doesn't come to arm in any form. :S
<dholbach> good morning
<mjrosenb> anyone know if the raspberry pi has vfp on it?
<feasty> morning all
<mjrosenb> feasty: morning.
<sfeole> hello
<ogra_> yo
<sspiff> I'm trying to run Ubuntu on my pandaboard, but the 12.10 release only had an installer image, not a preinstalled image. I want to run the rootfs off of my SD card, not a USB stick/disk, is there any way to achieve this?
<sfeole> sspiff: have you tried building a linaro image?
<infinity> sspiff: Unofficially, you can use the netboot image, and when d-i/partman asks where to install, tell it to use the "largest contiguous free space".
<infinity> sspiff: Officially, we don't support installing to SD, as the user experience is awful.
<sfeole> has anyone tried upgrading the nexus7 from 12.04 -> 13.04 recently?
<sfeole> via dist-upgrade
<ogra_> sfeole, dholbach did and found a bug, should be fixed by now
<sfeole> ogra_: with bluez ?
<ogra_> the bluetooth fix wasnt uploaded yet
<ogra_> and wemdont have brcm-patchram in raring yet
<ogra_> *we don't
<asiekierka> how to recover a EEE Pad TF101 with battery issues? gets into APX mode but error -71
<asiekierka> battery or cable, not sure
<dholbach> there were a couple of problems 1) onboard needs an upload to raring (I'm in touch with upstream), 2) bluez did not start/stop correctly, 3) nexus7-firmware wasn't pulled in (fixed by infinity), 4) do-release-upgrade did not work (seems fixed in my last try), 5) unrelated to upgrades, but during an installation I couldn't enter anything into oem-config's text-boxes, neither with onboard, nor attached keyboard
<dholbach> sfeole, ogra: ^ that's all I noticed
<ogra_> yeah, the last one is really bad
<dholbach> did the unity stack land in standard raring already? or should we advise to use the daily-build still?
<ogra_> landed yesterday
<dholbach> yes baby!
<ogra_> in 1.5h there should be images with it
<ogra_> (and wit the new serial console by default)
<ogra_> no more wlan needed for debugging ;)
<lilstevie> asiekierka, this probably isn't the place to get support with that, but usually you are looking at an issue with the usb cable
<asiekierka> lilstevie: there's no place to get a support with that and this looks like the best bet seeing as you're here often
<lilstevie> #asus-transformer looks kinda more suited
<asiekierka> oh
<asiekierka> asked.
 * lilstevie heads to bed
<sfeole> for everyone else watching i meant 12.10 -> 13.04 , I just noticed that
<ogra_> heh
<gurgalof> does this: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1045741 affect ubuntu on nexus7?
<ubot2> Launchpad bug 1045741 in firefox (Ubuntu) "since the switch to unity 3D and the GLES driver by default firefox on the pandaboard reders extremely slow" [Undecided,New]
<ogra_> my firefox works fine here
 * ogra_ is currently typing from his nexus
<gurgalof> i think firefox is a bit slow, but that could be due to the arm isn't as fast as a desktop...:P
<hrw> I think that ogra_ is spoiled by ac100 speed
<sfeole> lol
<sfeole> arg still hangs for me when replacing bluez
<dholbach> sfeole, I had to kill the process, twice - once for stopping and another time for starting the service
<sfeole> dholbach: yea, that did it for me, what I will do is document this for now, I know we are recommended a fresh install to raring but you know there will be some people trying the upgrade path ;P
<sfeole> upgrade path == dist-upgrade
<dholbach> yeah, I did it too, as the installation from the image did not work for me
<ogra_> upgrades should definitely be functional
<ogra_> so thats a high  prio bug
<sfeole> ogra_: agreed, my installation is now continuing .. I'm already filing the bug now
<ogra_> great, thx
<ogra_> sadly the touchscreen still dies after a while :(
<sfeole> hmm the nexus7-firmware0.2 package looks like it was pulled down and made me confirm it, but it failed to install
<sfeole> looking into why
<janimo> infinity, ogra_ I am just curious, is armhf going to switch from ports.ubuntu.com ?
<ogra_> i dont think so, but ask infinity he might know more ans part of the release team :)
<ogra_> *as
<infinity> janimo: Probably not for a long while, if ever.  It has nothing to do with official or unofficial support, it has to do with amount of traffic.
<ogra_> and mirrors
<infinity> janimo: Mirrors don't want to mirror a whole port just for the sake of 1% of users.
<infinity> ogra_: Yes, mirror traffic was what I meant.
<ogra_> yup
<janimo> sounds reasonable
<ogra_> sfeole, "screen /dev/ttyACM0 115200" could you run that on your PC with the nexus attached via USB ? hitting enter should get you a login (needs the latest kernel nad the latest default settings)
<ogra_> it works for me, just want to make sure it works for everyone
<prpplague> ogra_: http://www.elinux.org/PandaBoard-NC
<prpplague> ogra_: think there would be any market interested in that?
<sfeole> ogra_: i will try after I get upped to Raring
<ogra_> yeah,, needs raring indeed
<sfeole> ogra_: will let you know
<ogra_> prpplague, microsd and no ethernet ?
<ogra_> might be intresting for beagle guys that want to go up one level
<prpplague> ogra_: ethernet is there, just no connector for it, you have to wire it up yourself
<ogra_> yeah
<prpplague> ogra_: more for doing hardware dev
<ogra_> likewise for the USB hub
<prpplague> ogra_: yea
<prpplague> ogra_: you can use the standard usb panel connectors
<ogra_> well, surely intresting for getting a panda into a slim case
<prpplague> ogra_: yea
<ogra_> but i wouldnt expect massive sales from it i think
<ogra_> seems pretty special cased ... will it be the same priice as a "normal" panda ?
<prpplague> cheaper
<ogra_> that might be a sales argument then ... i personally would prefer a normal panda if i dont plan to put it into any case or so
<ogra_> having the little feet, and all sockets on board makes it easier to use for me ... if i would want to build a server with 10 pandas in a 4u case i would pick the NC
<ogra_> or when putting a panda into an ac100 shell :)
<prpplague> ogra_: yea that is the thought process
<prpplague> brb, need a reboot
<plars> janimo, ogra_: so is usb-serial turned on in today's image? I'd like to give it a try today if possible
<ogra_> plars, see above :)
<sfeole> ogra_: do you have the linux-firmware pkg installed on your Raring image?   version 1.98?
<ogra_> plars, as long aas you have the latest kernel and latest ubuntu-default-settings-nexus7
<plars> ogra_: awesome, thanks!
<ogra_> sfeole, indeed i do, else i wouldnt have wlan
<sfeole> and linux-image-nexus7
<sfeole> ogra_: i'm trying to find out what each pkg does,   linux-firmware-nexus7_0.2  and linux-image-nexus7
<ogra_> linux-image-nexus7 is a metapackage that depends on the latest kernel
<ogra_> linux-firmware-nexus7 carries the closed binary firmware bits used on the nexus
<sfeole> ok
<ogra_> both need to always be installed
<ogra_> plars, crap, i think we're missing a securetty entry, i get a prompt but cant log in
 * sfeole cheers as he upgrades to raring from Q,  
<sfeole> ogra_: i just filed a 2nd bug.. #1087335
<ogra_> bug #1087335
<ubot2> Launchpad bug 1087335 in ubuntu-nexus7 "linux-firmware-nexus7_0.2 fails to install while dist-upgrading from Q -> R" [Critical,Confirmed] https://launchpad.net/bugs/1087335
<ogra_> janimo, ^^^
<sfeole> thats why i was asking about those packages
<janimo> ogra_, are we still supposed to support Q->R upgrades? I thought 12.10 were play only demo images and we should recommend fresh install on R
<janimo> it would save us a lot of trouble
<ogra_> janimo, well, we said upgrades should work, even though we dont encourage them
<janimo> ogra_, would we need conflicts markers in the package just because we used linux-firmware in the PPA?
<janimo> I thought the whole point of 12.10 was here, you get to keep both pieces and we do not spend time on anything related besides initial UDS bringup
<ogra_> ogra@nexus7:~$ dpkg -l |grep firmware
<ogra_> ii  linux-firmware                            1.98                                        all          Firmware for Linux kernel drivers
<ogra_> ii  linux-firmware-nexus7                     0.2                                         all          Firmware for the Nexus 7 tablet.
<ogra_> janimo, conflicts wouldnt help
<ogra_> since you want both installed
<ogra_> oh, wait, conflicts ony
<ogra_> *only
<ogra_> yeah, that should work
<ogra_> or rarther replaces in that case
<janimo> well whatever marker says some files moved to another package
<janimo> what if we apt-get install linux-firmware
<janimo> this will remove the nexus binaries
<janimo> and then apt-get install linux-firmware-nexus7
<janimo> so make sure we do not let order be determined by apt
<ogra_> yes, that way would work, but isnt how apt does it
<janimo> or even more hackily backport linux-firmware-nexus7 to Q PPA
<ogra_> just a replaces should do
<janimo> ogra well would apt do anything else beyond installing the single specified package?
<sfeole> ogra_: "screen /dev/ttyACM0 115200" drops me into a login prompt ;)
<janimo> Replaces for a PPA package - so carrying some cruft in a baely opened series feels ugly to me :(
<ogra_> sfeole, but can you get in ? i seem to have issues with that here
<janimo> I think people insatlling 12.10 images are really knowledgable anyway and I would rather they sort the upgrade out by themselves or guided by a wiki
<ogra_> janimo, well, its a minor change that will save us lots of silly support questions
<sfeole> ogra_: yes i'm in, I had to hit "enter" initially to display the password prompt
<ogra_> yeah, thats normal
<ogra_> ok, i'll blame my chromebook (client side) then
<sfeole> http://pastebin.ubuntu.com/1415103/
<sfeole> ogra_: ^^
<ogra_> perfect, thanks for checking !
<ogra_> plars, see above
<sfeole> bad chromebook!
<ogra_> heh, yeah, i blame hrw
<ogra_> he does all the chromebook stuff, so it must be his fault :P
<hrw> ;D
<steev> fwiw, i blame him for everything.  if it weren't for him talking about how awesome the chromebook is, my checking account wouldn't be so light
<plars> ogra_: so I have the usb serial stuff working fine (Thanks!) but I'm having a bit of trouble getting preseeding to work.  I've tried adding my preseed file to the initrd that I'm pushing to it, but I'm guessing that by the time it gets there, it's already remounted userdata as root so I'm not finding it.  Any suggestions?
<vanhoof> \o/ usb serial ftw
 * vanhoof just flashed todays image
<plars> vanhoof: yes, it's working pretty nicely I think, but any ideas on how to preseed the remainder of the install?
<plars> vanhoof: I've tried sticking a preseed in the initrd, as well as in the rootfs, no luck so far, but tbh I don't have much experience with preseeding just the oem-config portion so I'm not confident that I'm doing it right
<vanhoof> plars: i've never done a oem-config preseed myself :\
 * vanhoof takes a look
* You're now known as ubuntulog
<mjrosenb> hey, anyone know if the raspberry pi has vfp?
<lilstevie> yes it does
<mjrosenb> sweet.
<infinity> mjrosenb: It's v6, however.
<lilstevie> that indeed
<infinity> mjrosenb: Which means that neither Ubuntu nor Debian armhf will run on it (but there's an unofficial Debian v6+hardfloat port called "raspian" just for the Pi)
<mjrosenb> infinity: yup. I need an armv6/vfp machine to test on.
<mjrosenb> infinity: and it certainly sounds like the raspberry pi fits the bill.
<infinity> What an odd requirement. :)
<mjrosenb> well, I already have like 10 armv7 devices
<infinity> As long as you like testing in slooooow motion, you'll have fun with the Pi.
<infinity> It's cute, at least.
<mjrosenb> what is it clocked at?
<mjrosenb> I thought it was like 600 mhz
<mjrosenb> ok, 700 mhz
<infinity> Yeah, 700.
<mjrosenb> so like half the clock rate of the upper end of my armv7's
<infinity> Still, a 700MHz ARM11 isn't anywhere near 7/10 of Cortex-A8.
<mjrosenb> true.
<infinity> And nowhere close to 7/10 of a 1G A9.
<lilstevie> mjrosenb, why would you want to test on an armv6+vfp
<infinity> The newer model with 512M of RAM might prevent urges to shoot yourself, though.
<lilstevie> I'm getting my fix for that with a roku 2 :p
<lilstevie> at least that is optimised for arm11
<lilstevie> and the one good thing I have heard about the pi, or really the bcm soc is that it is good at media
<mjrosenb> lilstevie: because firefox is going to attempt to support armv6, and I would like to make sure that we can do that.
<lilstevie> oh I see
<mjrosenb> but we are requiring armv6 + vfp
<mjrosenb> because javascript uses doubles *EVERYWHERE*
<infinity> Raspbian on a Pi may well be just the right testbed, then.
<infinity> It ain't fast, but it should do the trick.
<infinity> (For the love of god, though, don't compile on the thing)
<lilstevie> haha
<lilstevie> compiling on dual and quad core a9s is painful enough
<infinity> I've come to terms with A9 performance.
<infinity> Then again, I came from 68k porting, so I'm a bit weird.
<mjrosenb> infinity: I can't remember the last time I built on an a9
<infinity> Sadly, software is like goldfish, and it seems to bloat to fit your computer.
<mjrosenb> I cross compile basically everything
<mjrosenb> except on my a15
<infinity> Cause I swear today's (very fast, in comparison) ARM cores don't really do anything any faster than a 68k 10 years ago performing similar tasks.
<mjrosenb> 126 minutes to build firefox!
<infinity> I did get a refresher course in just how many crazy drivers we build in distro kernels the other day.
<infinity> Was doing some benchmarking with an upstream defconfig (cause building the package is just plain no fun as a benchmark)... Turns out that a defconfig on a Panda is about 10 minutes.
<infinity> Whereas our distro kernels take hours.
<Zero_Chaos> infinity: most distro kernels just enable everything possible as a module
<infinity> Zero_Chaos: Yes, and I know that.  I just didn't realise how many modules that IS these days.
<infinity> Zero_Chaos: Apparently, the answer is "a lot".
<Zero_Chaos> infinity: yeah, make -j64 is nice
<infinity> Not on a Panda, it's not. :P
<Zero_Chaos> infinity: I would imagine not ;-)
<infinity> Still, a defconfig in 10m isn't bad.  It wasn't that long ago I used to build my own barebones monolithic kernels on x86 kit, and that was around 30m.
<infinity> (Might have been around P200ish days?)
<infinity> Okay, maybe I'm getting old, when I imply that the P200 wasn't that long ago.
<lilstevie> -j5 is about as far as I can take the prime before more jobs make things slower
<lilstevie> (tegra3)
<infinity> http://paste.ubuntu.com/1413025/ <-- My unscientific quick tests on a PandaES.
<lilstevie> and also agreed, computers may have gotten faster, but the software has gotten bigger
<lilstevie> infinity, heh
<lilstevie> building a kernel deb with pbuilder takes about an hour and a half on my trimslice
<infinity> -j64 would probably make it weep.
<infinity> lilstevie: Do you talk to the Trimslice guys much?
<infinity> lilstevie: I'm kinda curious if they plan to rev the hardware with newer and shinier SoCs, or if it was a one-shot deal.
<lilstevie> infinity, not really, the only times I have had questions for them I get "why would you want that"
<infinity> Cause I like the idea and the form-factor, but it's obsolete by now.
<lilstevie> yeah, someone has asked that question, and they said no comment
<Zero_Chaos> infinity: -j64 brings most systems to their knees pretty quick. -j brings nearly all systems to their knees
<infinity> Zero_Chaos: The build machine we use for internal kernel test builds seems to have a sweet spot around -j256... Ish.
<lilstevie> infinity, http://emea.kontron.com/products/boards+and+mezzanines/embedded+motherboards/miniitx+motherboards/ktt30mitx.html has my attention, except I am getting to the point where I would rather avoid tegra
<infinity> (It's a 32-core i7-base Xeon with stupid amounts of RAM and a shamelessly fast stripe)
<lilstevie> infinity, although most of the crippling in tegra systems is slow eMMC
<Zero_Chaos> infinity: yeah on that I'm guessing you could just rock "-j" and let it fork as much as it likes. even on kernel builds like that I can't keep it >200 jobs for very long so if you have that many procs give up and use -j
<infinity> lilstevie: Curious that that's only clocked at 900MHz.
<Zero_Chaos> infinity: I have 32 amd cores and build in RAM
<lilstevie> that board would be an interesting test cause it does have SATA
<lilstevie> infinity, yeah, I noticed that too
<Zero_Chaos> infinity: so about 1/2 the intel system you describe
<lilstevie> infinity, I wonder if it is for cooling
<lilstevie> infinity, throw a heatsink on it and go nuts
<lilstevie> on the tf201 they have managed to bring it out to 1.8GHz with all 4 cores active
<lilstevie> but it does make the metal case nice and toasty
<infinity> lilstevie: Maybe.  I'm probably not going to buy any more A9s out of pocket.  I suspect I'll pick up one A15 at some point with my own money, and then wait for someone to bless me with aardvarch64 silicon.
<infinity> lilstevie: (Not counting useful items I actually need, like phones, of course.  I just mean I'm not going to keep collecting toys)
<lilstevie> infinity, yeah, I am getting a surface (waiting for it to arrive right now) but after that I am not paying for any more arm systems until aarch64
<lilstevie> infinity, the only exception to that may be a quad core S4, cause krait is crazy fast compared to A9
<lilstevie> but yeah, I am going to live with my current arm machines for as long as possible
#ubuntu-arm 2012-12-07
<Ethernin> Hey anyone here been messing around with ubuntu on the Nexus7?
<Ethernin> has anyone tried lxde yet?
<plars> xnox: any ideas on preseeding the oem-config install stuff for n7?
<plars> xnox: I'm trying to have it finish the setup (time zone, language, user, etc) on the first boot automagically
<plars> xnox: I tried sticking the preseed in the initrd, and also in the rootfs, but so far haven't had much success with it, nor do I seem to be able to ctrl-alt-f1 to see what's going on under the covers
<plars> xnox: but tbh, I don't know if maybe there's some difference with the preseeding that I need to account for
<xenome> hi guys, I've heard ubuntu doesn't run as fast on a BBxm when compared to Angstrom, is that still true today?
<rcn-ee> xenome, "heard" is that quantifiable. ;)
<xenome> well I've seen some posts about bogo mips too but I think that has to do with the calculation
<rcn-ee> bogo = bogus...
<xenome> rcn-ee, I believe I'm running your kernel I setup from the wiki
<xenome> is there a good way to benchmark?
<rcn-ee> with ondemand cpufreq, the bogomips calc is useless, as it does not get updated..
<xenome> well it's different now then at bootup when I cat /proc/cpuinfo
<rcn-ee> xenome, what will get you, post v3.6.x 800Mhz is no longer stable when rebooting, so I had to disable that in my builds.. SO if your Angstrom is running v3.0.x it'll be at 1Ghz, where as i'm at 600Mhz max.. ;)
<rcn-ee> If you don't care if it hardlocks on a softrware reset, you can reenable 800Mhz..
<xenome> is that a bug in the kernel?
<xenome> or did something change and that capability was just lost
<rcn-ee> looks for Tony Lindgren's email...
<rcn-ee> xenome, http://www.spinics.net/lists/linux-omap/msg78218.html (basically we need the Nokia fixes..)
<xenome> even at 800 if it worked, is there a reason for not hitting 1GHz like on angstrom
<Zero_Chaos> wait, ubuntu, not stable? unpossible
<rcn-ee> Well, there was hacks to make it work with v3.0.x & v3.2.x but with the 2 or 3 omap power managment rewrites, those patches are useless..
<rcn-ee> Basicly if you want it, complain to TI. ;)
<xenome> does TI offer a commercial solution?
<xenome> for people who buy this chip, what OS do they recommend to leverage all the features?
<rcn-ee> well, there was the 2.6.32-psp, then 2.6.37-psp and i think a v3.0.x based branch for those customers..
<xenome> oh so the psp branches are the TI modded kernels?
<xenome> is it possible to setup ubuntu and just drop back to one of their older kernels, or is that a big mess?
<rcn-ee> TI's psp are here: http://arago-project.org/git/projects/
<rcn-ee> sure, in theory you can go all the way back to 2.6.32 as long as DEVTMPFS is enabled..
<rcn-ee> but, it'll be a fun adventure, specially with all the gcc bugs. ;)
<xenome> because I'd be using a recent ubuntu dist, or because their code does not work well with gcc?
<xenome> i've started off with the demo image that shipped with my board.  I'm hesitant to even do a package upgrade as I'm afraid I may lose support for all the optimized programs
<rcn-ee> on arm, depending on far back you go with the kernel version, you better find a version of gcc built at the same time. ;)
<xenome> i'm not sure how I can check to see what I might lose
<xenome> ah, ok
<rcn-ee> did you rebuild your programs or just apt-get them?
<xenome> well I was using ubuntu at first, and now I'm back playing with arm
<xenome> err angstrom
<xenome> is it a tremendous amount of work to get a video player built under ubuntu that leverages the dsp?
<xenome> that's where I see the biggest difference
<rcn-ee> you can mix/match the kernel's too..  there's some things nice in angstrom's userspace..  but i need dpkg. ;)
<xenome> I saw some demo of synergy on youtube with 6 beagleboards...that looked amazing
<rcn-ee> oh that was mans's project, no dsp their..
<rcn-ee> all cortex...
<xenome> oh I love ubuntu, I'd must rather work in it...but I think I need the drivers unless I can with get something optimized built
<xenome> how exactly did that work? I haven't really seen a program that does that screen division like that
<xenome> should I just google synergy beagleboard?
<rcn-ee> but for the dsp: instead of working the dsplink guys i followed the tidspbridge guys.. (aka nokia) it works for video.. but yeah, no more changes now.. ;)
<xenome> because of their microsoft deal?
<rcn-ee> here's the wall: http://www.youtube.com/watch?v=9pwUdRKllo0
<rcn-ee> pretty much, before Microsoft all Nokia phones had omap34/36xx based devices.. now qualcomm..
<xenome> yeah that's amazing
<xenome> too bad omapfbplay doesn't have sound :)
<rcn-ee> and i think sounds now finally works on the beagle in v3.7-rcX! ;)
<rcn-ee> it was broken for a long time.
<xenome> running under angstrom?
<xenome> when it says "usb networked" does that just refer to the nics that connect via usb, or was there some special program running over usb (not ethernet)
<xenome> is there a version of ubuntu I could drop back to to be on par with the best angstrom, or is there just too much optimization by the angstrom guys to compete?
<rcn-ee> alot of those 'usb networked' device notes go back when we didn't have any real ethernet devices on the original beagle..
<rcn-ee> just grab the kernel/modules from here: http://downloads.angstrom-distribution.org/demo/beagleboard/  They'll run just fine on ubuntu...
<xenome> so is v3.7-rcX another kernel besides the one you're hosting?
<xenome> so I just need to drop my kernel back to 3.0.17?
<rcn-ee> we are at v3.7-rc8: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary  (in this merge the twl4030 (beagle/etc) was rewritten..)
<xenome> that chip does the power management?
<rcn-ee> Well, you could use my legacy v3.2.x branch on github.. 800Mhz works..
<rcn-ee> audio/usb/etc...
<rcn-ee> it's a very complex multifunction/mult power/etc device..
<xenome> does torvald's kernel have the myriad of patches in your repo?
<xenome> seems like you've done a great deal of work to get things to where they are
<rcn-ee> We (beagleboard.org community) use torvald kernel as a base..  Most of the patches we have in the repo is stuff heading mainline.. or the last gasp of board based changes, before we have to fianlly convert to device tree..
<xenome> so is that a good thing?
<rcn-ee> yeah, it keeps it easy to rebase and keep following torvald's tree..  but we give up on backporting to old stuff. ;)
<xenome> I see...so do the angstrom guys do something special to get 1 GHz?
<rcn-ee> here's their patch list for '1 Ghz' : https://github.com/beagleboard/kernel/tree/beagleboard-3.0/patches/pm-wip (both directories)
<rcn-ee> Unless you work for TI and are paid to do it, yeah that massive list of patches to keep track of and push mainline. ;)
<xenome> wow, it takes all that go from 800 to 1 GHz?
<rcn-ee> Correct.. ;)  IF you didn't care about the life of the silicon and had heat spreader... well you could just bump the Vcc voltage and enable 1Ghz. .;)
<xenome> so did someone do that once for the angstrom kernel, and it's just too much work to follow the new revs?
<rcn-ee> and one user actually did that in 2.6.36: https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/z3Jsk_nHLNU
<rcn-ee> That was pulled from ti's 3.0.x-psp, they were even posted to the linux-omap mailing list, but after asked for more comments the poster never rebased so they got lost..
<raster> moo
<raster> anyone here doing any nexus7 ubuntuey stuff?
<xenome> so TI will make the board work in their branch at 1 GHz
<xenome> ?
<xenome> that doesn't quite seem as big of a patch as the site you just showed me
<xenome> but I guess that was for 2.6.36
<rcn-ee> that small patch just over volts the core with no protection. ;)
<xenome> and that's what TI does in their tree?
<rcn-ee> no.. that small patch was from a users..
<rcn-ee> btw, i have no interest in TI's tree, i know it supports 1Ghz.. and there's a lot of patches to accomplish it.. but it's not mainline..
<xenome> oh it's really far off?
<xenome> is your goal to get most of the stuff pushed into mainline, is that realistic?
<rcn-ee> why not? ;) btw you should talk to the fedora-arm guys: they will not except even a small patch: it has to be 100% mainline. ;)
<xenome> heh
<xenome> so to get the serial port working for output I had to diable getty in /etc/init, but keep the console line in uEnv.txt
<xenome> i thought from what I read online I had to remove that line fro uEnv.txt
<rcn-ee> You need both places... uEnv.txt just redirects the boot console... /etc/init/serial inits getty..
<xenome> well it didn't work when I removed it from uEnv.txt
<xenome> but maybe that's because it's also setting up the port correctly for me
<xenome> i.e. 9600, etc..
<rcn-ee> technically we don't need it in uEnv.txt..  but who wants to wait 10 Seconds waiting for a login to appear..
<xenome> well I suppose I better remove it if I don't want messages coming out
<rcn-ee> the problem for a lot of people... if your actually using the port with something.. you also need to quite MLO/u-boot..
<xenome> oh so do more than just uEnv.txt?
<rcn-ee> The easy way: just change u-boot to use a different serial port.. then you'll never see that either..
<rcn-ee> fun to debug..
<xenome> via uEnv.txt?
<xenome> you wouldn't happen to know what disconnects getty in angstrom?  I figured my first test would be to do that, then to yank the uEnv.txt line
<xenome> that's at least how I got success with ubuntu
<rcn-ee> no just use a different serial port: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/omap3_beagle.h;hb=HEAD#l89  then u-boot will dump all the boot stuff somewhere else..
<rcn-ee> no idea, it's systemd... yuck..
<raster> any ideas on hunting down an apparent kernel-side memory leak on tegra3?
<raster> i can only account for about 128m of userspace memory being used
<xenome> is that file used by the kernel or just u-boot?
<raster> but kernel reports 420m gone
<xenome> so rcn-ee, if I want to stick with ubuntu yet leverage the prexisting kernel modules, is it best to drop back to 3.0.17 and use the BBxm modules, or try to use your 3.2 kernel?
<dholbach> good morning
<gurgalof> morning
<achiang> dholbach: good morning
<dholbach> hey achiang
<dholbach> ogra_, I can't use onboard when gksu is active!
<raster> yay for mouse grabs!
<dholbach> aha, it's filed already: bug 421660
<ubot2> Launchpad bug 421660 in gksu (Ubuntu) "gksu's and gksudo's modal password prompt prevents OnBoard's virtual keyboard input, causing accessibility issues" [Medium,Confirmed] https://launchpad.net/bugs/421660
<raster> anyone here doing nexus7/tegra3 stuffs?
 * ogra_ waves to raster
<raster> ogra_: moo
<ogra_> i'm rolling the nexus images, whats your question
<raster> memory
<raster> i've found a 270mb memory black hole
<raster> not in userspace
<raster> not in kernel slab info
<raster> i cant find it
<raster> but theres 270mb or so of mem i cant account for no matter how i try
<raster> fyi
<raster> i've already chopped out 200m of memory usage
<ogra_> using our image ?
<raster> the standard setup uses about 630m
<raster> yup
<ogra_> is that 12.10 or 13.04 ?
<raster> i'm down to around 430m
<raster> 12.10
<raster> 13.04 is broken as it gets
<ogra_> 13.04 installs zram by default
<raster> gl is busted nasty-like
<raster> bah
<raster> dont need zram
<raster> :)
<ogra_> hmm, i use it fine here
<ogra_> it has some issues butu you can work around them
<raster> if i can find this memory hole i'll have a base footprint of less than 130m
<raster> thats plenty good enough for a 1g device and me :)
<ogra_> did you check the cmdline ? the bootloader prefixes a mad amount of stuff to it ... hardcoded
<raster> ummm
<raster> i did indeed not
<raster> where can i find it
<raster> ?
<ogra_> cat /proc/cmdline
<raster> from regular userspace?
<raster> aaaah of course
<raster> nm
 * raster slaps himself
<ogra_> heh, dont :)
<raster> i was thinking grub
<raster> but realised "hmmm.. no.. no grub there"
<raster> then i blanked out
<raster> :)
<ogra_> abootimg is the tool to use for fiddling with cmdline, kernel or initrd bootloader stuff
<raster> lp0_vec=8192@0xbddf9000
<raster> tegra_fbmem=8195200@0xabe01000
<ogra_> yeah. no idea how you can get rid fo that
<raster> re thos in.. bytes?
 * ogra_ guesses they are
<ogra_> not sure though
<Ethernin> ogra_, Hey man any info on the Nexus 32GB with 3G?
<raster> hmm
<raster> well 8mb for fbmem...
<Ethernin> just tried like 5 minutes ago installing the latest raring
<raster> kind redundant to use that much
<Ethernin> still no go
<ogra_> Ethernin, hmm, how does it hang ?
<raster> ogra_:  have u been in touch with the nvidia guys?
<raster> the gl/tegra drivers are not doing vsyn swaps
<raster> vsync swaps
<raster> its severely offensive
<raster> especially since i asked for them :)
<ogra_> raster, only through some guys in #ac100 (tegra2 netbook)
<raster> (set swapinterval to 1)
<ogra_> but i doubt they will be able to help you here
<raster> aaah boogers
<ogra_> the stuff you look at comes hardcoded from the bootloader
<ogra_> thats rather googles side of things i'd say
<Ethernin> ogra_, well i noticed that in the bootimg.cfg within the bootimg file it's still pointing to the partition9 instead of partition10
<Ethernin> ogra_, cmdline = root=/dev/mmcblk0p9 ro console=tty0 fbcon=rotate:1 access=m2 quiet splash
<raster> vmalloc is 128m
<raster> hmm i wonder what that does
<ogra_> Ethernin, yes, thats fine, it detects the right partition during first boot, resets the cmdline and reboots
<Ethernin> ok
<ogra_> at least it is supposed to :)
<raster> hmm
<raster> i wonder if ont he tegra kernel the vmalloc literally snarfs those 128m away and never allows userspace to get it
<raster> that accounts for almost half my vanished mem
<ogra_> i would bet thats most likely used for the binary drivers
<raster> i wonder ifr it gets it wrong and uses it as real physical ram
<Ethernin> ogra_, so i've tried downloading from http://hwe.ubuntu.com/uds-r/nexus7/ (the 32GB version) and the latest raring from: http://cdimage.ubuntu.com/daily-preinstalled/current/
<raster> ogra_:  quite possible
<raster> if its where ti stuffs texture and backbuffer data etc.
<Ethernin> neither one of those works using fastboot 1.6 flashing Nexus 32gb with 3g
<Ethernin> at least so far
<Ethernin> oh shit!
<raster> or where it gets it from
<Ethernin> NM!
<Ethernin> it worked!
<Ethernin> wahoooo!!!
<ogra_> :)
<raster> yay!
<Ethernin> !_!
<Ethernin> BOOOYAH!
<raster> ogra_: also.. wheni suspend.. it just insta wakes up
<raster> liek suspend for 200ms
<raster> then wake
<raster> all onits own
<Ethernin> it was hanging at first saying is wasnt a modem or soemthing
<ogra_> raster, i noticed that too, next suspend persists though
<raster> /usr/sbin/pm-suspend
<raster> when i go direct
<raster> hmm
<raster> nah - it keeps doing it every time for me
<raster> again and again
<ogra_> (using just the UI, not sure what that calls additionally beyond pm-suspend)
<raster> i was wondering if i can figure out the wakeup src?
<raster> dmesg didnt seem to help
<raster> wsell not that i could find
<raster> hmm ok
<raster> i'm bypassing the ui
<raster> :)
<ogra_> heh
<ogra_> trying to get E17 to work ?
<raster> already working
<raster> thats why i saved 200m
<raster> :)
<ogra_> heh
<raster> compositing works a treat
<raster> everything working
<raster> multitouch works
<ogra_> yeah, as bad as binary drivers are, the tegra ones are a pleasure to use
<raster> it would seem the hw fb is actually portrait mode
<raster> noting how the screen updates/scans
<raster> or appears to
<ogra_> heh, yeah
<ogra_> we tricked it into landscape
<raster> ewww
<ogra_> using a desktop distro that somewhat seemed better
<raster> can i untrick it
<raster> without xrotate?
<raster> :)
<ogra_> i dont think you can untrick the touchscreen easily
<raster> i noticed its dodgey when i xrotate back to portrait
<raster> and noting the rendeirng speed
<raster> it feels like its doing extra copies and rotates along the way
<raster> maybe 2 times
<raster> so render to buffer
<raster> rotate to the tricked landscape
<raster> then when in portrait
<ogra_> but yeah, for the rest, there is a) a rotation option set on the cmdline (use abootimg on /dev/mmcblk0p2 to change it) and b) an xorg.conf snippet
<raster> rotate YET again back to portrait
<raster> ooh docs?
<ogra_> abootimg -h
<ogra_> :)
<raster> aaah there it is
<raster> fbcon=rotate:1
<ogra_> /dev/mmcblk0p2 carries the bootimg raw
<raster> btw
<raster> is the IO meant to be that slow?
<ogra_> sudo abootimg -i /dev/mmcblk0p2
<ogra_> we didnt do much to optimize for MMC yet
<raster> hmm
<raster> fair enough - it's pretty sluggish
<ogra_> i'll likely set some sysctrl bits during the cycle
<raster> well ok- sluggish compared to equivalent devices i have.. around the place
<raster> that lets say.. some big oem's like to make
<ogra_> there isnt much we can do wrt filesystem optimization ... the ext4 we use needs to be created by the android tools to make it work with fastboot
<raster> ie i can see 2-3x the io rate
<raster> ext4 isnt the problem
<raster> :)
<ogra_> so on that side there isnt much we can imrpove
<raster> it know - ext4 works a treat on some over-the-top ssd's i have
<ogra_> but userspace surely still has room
<raster> and on.. other arm devices on emmc
<raster> oh btw
<raster> do u try and change governor by default?
<raster> i realized theres a new interactive governor
<ogra_> well, ubuntu defaults to ondemand
<ogra_> everywhere
<raster> its AWESOMELY better than ondemand or conservative
<raster> oh no no
<raster> dont do that on this
<raster> change to interactive
<ogra_> file a bug ;)
<raster> its like night and day
<raster> nah :) i alrwady fixed that
<raster> e17 just sets it itself
<raster> i just have to select it in the menu
<raster> :)
<ogra_> there are the android init scripts that set a lot of these optimizations on boot, i havent had the time to go through all of them in detail yet
<raster> when u get toit - i suggest u try it
<raster> u can try it now to see what i mean
<ogra_> iirc there is some code for the interactive governor
<Ethernin> Hey have any of you guys made a custom onboard keyboard before?
<Ethernin> just looking at trying to make it a little more usable on the nexus
<Ethernin> i know it uses svg files and you can create your own custom keyboard maps
<raster> echo "interactive" > /sys/devices/system/cpu/cpu[0123]/cpufreq/scaling_governor
<Ethernin> just wondering if anyone had some good ideas on a simple way to do it?
<raster> u dont need any code
<raster> just do that and try it out
<ogra_> well, interactive means you can set options ;)
<raster> no
<raster> i think it means its designed for interactivity
<raster> ie so the gui is responsive
<raster> as it beocmes really responsive
<raster> it htink it clocks up fast
<ogra_> https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/init.grouper.rc
<raster> much faster than ondemand/conservative
<ogra_> line 171 ff.
<raster> sou get high clockrates fast
<raster> then clocks down
<ogra_> the lp_ options could probably help your suspend issue
<raster> hmm
<raster> interesting
<ogra_> 194 ff. looks intresting for MMC performance
<raster> well the out-of-the-box interactive governor options make it great :)
<ogra_> the prob is that we need to change a really badly implemented ubuntu default here
<ogra_> i would much rather fix it by a complete re-implementation but wont have the time for this in 13.04
<raster> where are those lp_ options?
<raster> hmm wtc
<raster> wtf
<raster> oooh
<raster> 2k
<raster> nm
<raster> wait
<raster> 2mb
<raster> thats insane
<ogra_> well, the device is pretty fast on android :)
<ogra_> btw ... /etc/init.d/ondemand is what i was talking about above
<raster> sure
<raster> well for nexus7 i'd suggest using interactive
<raster> just as is it makes it massively less sluggish
<raster> oh
<ogra_> right, the point is it should a) be autodetected which one is needed or b) be configurable
<raster> u mean lp2_in_idle, no_lp, lp2_0_in_idle ?
<ogra_> yes
<raster> aaah yeah
<raster> u want to have a single ubuntu image for eveyrhting
<raster> sure
<ogra_> no, but the things that are installed by default should work either automatically or be configurable to cover different tasks :)
<raster> u COULD do some evil shellness in there looking at uname/proc/sys etc.
<raster> And if in tegra3 ... then try a different one
<raster> :)
<ogra_> this initrscript is simply assuming the whole world wants ondemand all the time
<raster> sure
<raster> it dpeends if u are happy to hack init scripts to maek these work
<ogra_> heh, sure
<raster> personally i despise init scripts and want to see them die :)
<ogra_> it just needs to function on x86, ppc, arm and under all ubuntu flavours after i touched it :)
<raster> sure
<ogra_> its not the coding, its the "make sure it does it right on all arches and flavours" bit thats hard for such generic bits in the distro
<raster> and if [] ...; then ... ; else ;; fi
<ogra_> boo
<raster> to detect tegra3 at least .. if there is an interactive one
<ogra_> case arch in; .... esac
<raster> in fact i think if there were an interactive governor for desktop and laptop anyway u'd want it
<raster> :)
<ogra_> 3x faster than if ;)
<raster> its shell
<ogra_> yep
<raster> 3x faster still means abotu the speed ofr continental drift :)
<raster> but sure - i get it :)
<ogra_> heh, well, if its a script executed during boot, 3x faster matters
<raster> true
<raster> tho imoh unity should take care of that higher up
<raster> as such 1 size does not fit all with governors
<raster> i have 1 laptop i have to clock at 600mhz
<ogra_> right, but it should staay in the plumbing layer i think
<ogra_> unity is to high up
<raster> any more and it'll overheat after 1 min of compiling and throttle itself to death
<ogra_> lovely ...
<raster> as such i can clock in vast improvements in compiling times if i clokc to performance for the whole compile session
<raster> then let it go back to auto afterwards
<ogra_> write more shell and less C ;)
<raster> thats why e17 has a control in it with some suid root fun
<raster> hahaha
<infinity1> I'd tend to agree that this doesn't need to be machine-specific, and interactive is the sane choice if it's available.
<ogra_> infinity1, oh, you mean just looking at available_governors ?
<ogra_> hmm, sounds like a good idea
<infinity1> ogra_: Yeah.
 * ogra_ will play with that 
<ogra_> first .... coffee though ....
<ogra_> brb
<infinity1> ogra_: One could concievably build a kernel with no governors, and that init script should just exit silently in that case.
<infinity1> ogra_: But if interactive is in the set, use that, else if ondemand, use that.
<raster> ok
<raster> lets hope the rotate thing is.. better
<raster> ogra_:  yeah - just use interative form avilable_governes if there.. if not - use ondemand :)
<raster> simple
<raster> but interactive is miles better
<raster> hmm
<infinity> Yeah, I'm guessing it's not mainline yet.
<raster> read are better with 2m readahead indeed
<infinity> My 3.7 kernel doesn't seem to have it built in, at any rate.
<raster> infinity: i think its something android added
<raster> i read about it as part of 4.0 or 4.1
<raster> its a new governor to improve interactivity
<ogra_> yeah, we dont use it on x86 i think
<raster> and it clocks up to max cloickrate almost immediately
<raster> and then pulls back after that
<infinity> Yeah, it's definitely not in the 3.7 sources.
<raster> so it leads to slightly more power drain
<infinity> raster: Yeah, I've read what it does, seems a bit saner.
<raster> but its much more repsonsive as the cpu clocks up the moment it needs to do even just a little more work than the "trivial"
<infinity> And it's not necessarily more power drain, if it changes usage habits.
<raster> sure
<infinity> Much like we discovered that 7200rpm laptop drives draw less power than 4200rpm ones.
<raster> it makes sense to me - why it isnt in ondemand by default.. dunno
<raster> :)
<infinity> Because they spin up faster, get shit done, and spin down.
<ogra_> hmm, could it happen that not all cores have the same set of available governors ?
<infinity> ogra_: Not on any systems we support out of the box.
<ogra_> k
<raster> ogra_:  that'd be highly odd
<infinity> Co, checking cpu0/available would be fine.
<infinity> Which is, I assume, why you asked.
<ogra_> well, sysfs exposes it by core
<raster> it could be that they cant all do the same clockrates tho
<infinity> s/Co/So/
<ogra_> so you can obviously set it by core
<ogra_> which makes me think its not that odd (not that i see how it would help anything)
<infinity> No kernel we ship would/could have a different supported set per CPU.
<ogra_> right
<infinity> One could potentially do such a thing, but it would be rather odd.
<raster> yeah
<raster> odd
<ogra_> ok ok
<ogra_> odd
<ogra_> :)
<infinity> (Now, setting the governor per CPU is a less odd use-case, but that's left as an exercise for the end-user, not something we need to cater to)
<raster> tho the tegra3 does have this awesome 5th cpu thing
<raster> thats an example of 1 cpu only going up to.. hmm 400 or 500mhz
<infinity> Like having a many-core server with one core set to performance and the rest to ondemand.
<raster> cant rememebr
<raster> tho its jnot exposes in sysfs
<raster> its glued in under the covers as u can do 4 cpus or 1
<infinity> raster: Yeah, their own take on big.LITTLE, but not.
<raster> depending on needs/clockrate
<raster> yeah
<raster> different
<raster> but it was rather neat when i saw it in a presnetation from them a while back
<raster> the fact that it uses a specific lower power process to make ti too i guess makes sense
<infinity> Yeah, all the big.LITTLE type ideas are pretty slick, both ARM's and NVIDIA's.
<raster> either way - its just what us hackers need
<raster> as we often just need a single core only going up to some middling clockrate
<raster> eg to play some mp3 data
<raster> we dont need the rest
<infinity> Kernel folks are still working on sane ways to make the scheduler take advantage of all of this.
<raster> maybe just shuffle some bits from disk into the video decode buffers
<raster> who knows
<infinity> The ARM big.LITTLE design involves a low-clocked A7 (the successor to the A9, which isn't confusing at all) and a bunch of A15s.
<infinity> But it definitely needs serious software support to make it as cool as the whitepapers and slides.
<raster> sure
<infinity> Also has knock-on effect for high end computing clusters and such too, though, so it's an interesting problem to wrap one's head around.
<raster> indeed not just kernel support
<raster> but i think userspace too
<raster> kernel cant predict what an app WILL do
<raster> it can guess what it might based on history
<raster> but an app is much more likely to know
<raster> based on its knowledge of the world
<infinity> Yes, response time is one of the concerns if it's all kernel-side.
<raster> so having interfaces to "hint" to the kernel what u are doing would be useful
<raster> an example would be the std mainloop toolkits have
<raster> when we wake up.. we take a quick look at the fd's that are active
<infinity> Since the initial cut here looks basically like an ondemand scheduler (again), but hotplugging cores in addition to frequency scaling.
<raster> if x is active
<raster> then we can assume we wil be doing some rendering
<raster> so we can issue a "hey - clock up mate.. i need you now!"
<raster> or if its an fd from wayland compositor
<raster> or wherever
<raster> :)
<raster> we dont need absolute control
<raster> but we need the ability to let the kernel knwo what we need
<raster> or might need
<infinity> It goes back to the same discussion as hard drive RPM, really.  Faster response times win the day (both in user experience and actual energy consumption), but you can't clock up "for no reason", or you lose hard on energy.
<raster> not necessarily
<raster> depending on soc/cpu/whatever
<raster> eg 1.5ghz may be nice
<raster> u CAN do 2ghz
<raster> but you drain 3x the power as u have to up voltages and what not all over
<infinity> Oh, sure, clocking to max isn't always a win.
<raster> theres a "fast sweetspot"
<infinity> I just mean "fast enough to get work done".
<raster> and then thers the "give me everything u have"
<raster> sure
<infinity> The key being that the largest power drain on these systems is actually the display.
<raster> but if an app can hint at what it needs - semantically
<infinity> Then the RAM.
<infinity> Then the CPU.
<raster> that'd be majorly helpful
<raster> true
<raster> ram? really?
<infinity> Yeah.
<raster> thats the first time i hear it in the lsit
<raster> its normally after cpu
<infinity> It's after CPU on low-RAM devices.
<raster> hmm
<infinity> SRAM battery drain goes up rather quickly.
<raster> oh sram... sure
<raster> i'm thinking dram
<raster> your usual run of the mill
<raster> garden variety
<infinity> Anyhow.  The display is always the biggest killer.
<infinity> So anything that gets the user through his task faster and the screen off faster is a win.
<infinity> To a point.
<infinity> As long as it doesn't mean "your cores are always awake and spun up, sucks to be you".
<infinity> Cause then the CPU takes over the battery wars. :P
<raster> what is this no_lp thing...
<raster> sure
<raster> thats the "screen is on" scenario
<raster> if its "screen off playing my music"... thats another matter
<raster> a bit of amoled action and a nice dark theme... helpeth :)
<infinity> Yeah, that helps a lot.
<infinity> Though my phone isn't amoled.
<raster> :(
<raster> the samoleds are gorgeous
<raster> i have to say
<raster> tho they suffer from burn-in
<raster> and pentile is just plain offensive
<infinity> The LG IPS displays are also pretty sexy.
<raster> well offensive to me
<infinity> :)
<raster> the s2 was the only one to get it right so far
<raster> tho the s3 is getting into "totally silly" dpi land so it begins to all just vanish in the blur :)
<infinity> No DPI is silly, it just needs marketing fluff comparing it to your ocular anatomy and suddenly it's "innovative".
<infinity> Duh.
<raster> hahaha
<raster> sure
<raster> hmm
<raster> time to go home and see if my rotate works...
<raster> or non-rotate
<raster> enough sshying twice acorss the pacific to talk to my nexus7
<ogra_> infinity, http://paste.ubuntu.com/1416620/
<mjrosenb> is there a bot in here that keeps track of the last time someone said something?
<ogra_> nope
<infinity> ogra_: That's an inverse optimisation for the less likely case.
<ogra_> hmm
<infinity> ogra_: Dropping the block at the top with the exit would solve that, ish.
<infinity> ogra_: Forking grep for every core is a bit much too, though.
<ogra_> not really, let me think about something where we dont run grep all the time :)
<infinity> ogra_: fork-free version: http://paste.ubuntu.com/1416644/
<ogra_> awesome
<ogra_> let me test that
<infinity> Seems to DTRT here in some quick testing with governors I actually have.
<ogra_> yeah, rebooting the nexus now
<gurgalof> is raring usable now on the nexus7?
<ogra_> it has issues and bugs but isnt much worse than 12.10 was
<infinity> ogra_: On a side note, I find that once you wrap your head around "while read foo; do ...; done < /file", it becomes a claw hammer to remove many a shell-forking nail.
<ogra_> yeah
<ogra_> i was thinking about how to use case here ... "while read" wasnt striking me though :)
<gurgalof> then I may flash raring, instead of using quantal as I do now...
<ogra_> gurgalof, there are some input issues with onboard in the graphical installer where you cant type into text fields, for some people it works to reboot the device if that happens
<ogra_> thats the only blocker i currently know about
<infinity> ogra_: Actually, being a single line file, the while loop is unnecessary.
<infinity> ogra_: Though, upstream could always make it multiline just to prove me wrong. :P
<ogra_> heh
<ogra_> unlikely though
<ogra_> ogra@nexus7:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
<ogra_> interactive
<ogra_> interactive
<ogra_> interactive
<ogra_> interactive
<ogra_> great
<ogra_> and raster was actually right, it feels a lot more responsive
<ogra_> (finger scrolling in the browser actually got smooth)
<infinity> http://paste.ubuntu.com/1416666/
<infinity> ^-- Ditching the while loop.
<infinity> And renaming the variable to something more readable.
<infinity> ogra_: Want me to upload this, if you're happy with the testing?
<infinity> ogra_: Is there a bug ref?
<ogra_> case "$(cat $AVAILABLE)" in
<ogra_> save you the read
<infinity> Err, but it forks cat.
<ogra_> no bug ref, nope
<infinity> read is a builtin.
<infinity> Which was the point.
<ogra_> oh,. fork free, indeed
<ogra_> heh
<ogra_> yeah, go ahead and upload
<ogra_> raster just came up with it during conversation, there was no time for a bug :)
<ogra_>       case $governors in
<ogra_>                 *conservative*)
<ogra_>                         GOVERNOR="interactive"
<ogra_>                         break
<ogra_>                         ;;
<ogra_> infinity, better dont upload it that way :)
<infinity> Yeah, that was me testing. :P
<ogra_> guessing you want to match interactive for interactive
<ogra_> :)
<infinity> (Since I don't have interactive).
<infinity> But I appreciate the review concern. :)
<ogra_> your manager should really give you one of the nexuses he sits on :P
<ogra_> ogra@nexus7:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
<ogra_> userspace
<ogra_> hrm
<infinity> ogra_: I have one, but I was iterating on the laptop cause, well, laptop.
<ogra_> ah
<ogra_> well, it didnt work here
<infinity> Oh.  You mean, even after fixing it, it doesn't do anything?
<ogra_> it is set to userspace
<ogra_> which the kernel defaults to
<infinity> That's odd, since if you neuter the echos and test it, it does exactly what it used to (except for adding interactive as an option).
<ogra_> (performance makes it hang)
<infinity> Does that mean it wasn't set to ondemand before either?
<ogra_> it was
 * ogra_ doesnt see any paste errors or typos 
<infinity> (base)adconrad@cthulhu:~$ ./ondemand background
<infinity> echo -n interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<infinity> echo -n interactive > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
<infinity> echo -n interactive > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
<infinity> echo -n interactive > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
<infinity> Don't make me reflash my N7 at 5am to test this...
<infinity> I guess I may as well.
<ogra_> nah
<infinity> Nah, I have to get a recent image on it anyway.
<infinity> This is a fair excuse.
<infinity> And I want to know why this fails.
<ogra_> i'm running a set -x atm
<ogra_> but missed to take out the sleep 60 :P
<ogra_> bah
<infinity> The only thing I can think is that AVAIL points to nowhere on your device.
<ogra_> http://paste.ubuntu.com/1416687/
<ogra_> weird
<ogra_> why didnt it work at boot then
<infinity> That looks right...
<ogra_> yeah, it is
 * ogra_ reboots again
<ogra_> oh, wait !
<infinity> ?
<ogra_> heh
<ogra_> i was likely to fast
<ogra_> there is that sleep 60
<infinity> Oh, you may have checked too early?
<infinity> Derp.
<ogra_> ogra@nexus7:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
<ogra_> userspace
 * ogra_ twiddles thumbs for a minute
<ogra_> ogra@nexus7:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
<ogra_> interactive
<ogra_> HA !
<infinity> Why is it that, even though I own about 400 micro USB cables from my Nokia days, I can never find one?
<infinity> Okay, panic averted, this works?
<ogra_> yep
<ogra_> just the silly sleep
<ogra_> i guess though, we could also solve that on a kernel level
<infinity> Uploaded, then.
<ogra_> we cant run performance by default on boot anyway
<infinity> We could default the kernel to interactive, but this is still "more right" for all devices, IMO.
<ogra_> so instead of pointing to userspace we could as well just default to interactive
<ogra_> oh, yeah, toitally independent from that fix
<infinity> If/when interactive gets mainlined, this is what I want ondemand doing.
<infinity> Doesn't "userspace" end up being "fully clocked until you do something to it" anyway?
<ogra_> well, i wonder if preformance is broken because interactrive is there :)
<infinity> Yeah, it could just be that the code around performance is broken.
<ogra_> since interactive seems to be an android thing
<ogra_> but yeah, i think userspace behaves similar to performance
<ogra_> if you dont touch it
<infinity> Right, then that's what we want on boot.
<infinity> That's why we have the 60s delay.
<infinity> Suck battery while booting, but get it done quick and without scaling getting in the way.
<infinity> Then scale.
<ogra_> yep
<ogra_> hmm, so should i ship a default-settings file for the SD card sysctrl
<ogra_> # Default Read Ahead value for sdcards
<ogra_>     write /sys/block/mmcblk0/queue/read_ahead_kb 2048
<ogra_>     write /sys/block/mmcblk1/queue/read_ahead_kb 2048
<ogra_> thats what the android init script sets
<ogra_> i wonder if we should make that generic, i see that value used in BSPs since years
<infinity> I wouldn't be against that being true for every system.
<infinity> At which point, it probably belongs in all the kernels.
<ogra_> not sure how it affects i.e. a vfat card from a camera on x86 though ... i.e. if you dont run your rootfs from the SD
<infinity> But I'm not opposed to a global sysctl hack for now.
<infinity> I'd think it would improve typical VFAT usage too, since those are usually large (ish) files.
<ogra_> true
<infinity> Oh bah.  There's no raring version of the nexus7-installer PPA.
<ogra_> its 5 cmdline commands to flash
<infinity> Yeah, I wanted to try this the "blessed" way for once, instead of being a hack.
<ogra_> wget/zsync the img.gz and bootimg ...
<ogra_> unzip it to get an img
<infinity> I full well know how to do it the hack way. :)
<ogra_> oh, ok
<ogra_> i dont think ita a hack way :)
<ogra_> its my preferred way ;)
<infinity> It's a hack if it's not what we tell other people to do.
<ogra_> well, its just what the zenity shell script does in the backend
<infinity> Bah, and this version of fastboot doesn't ship with a sane udev rule, does it?
 * infinity grumps about having to be root.
<ogra_> you dont if you have the udev rules installed
<gurgalof> wow, interactive is way faster, just had to try...
<ogra_> we'lll ship them with usb-creator later
<infinity> ogra_: Yes, I don't if I have the udev rules installed, which I don't.  That was my point. :P
<ogra_> heh
<infinity> Cause android-tools-fastboot only has /usr/bin/fastboot
<infinity> We had an old fastboot package from elsewhere that had pretty udev rules.
<ogra_> the installer has the udev rules since we switched to the debian packaged fastboot
<xnox> hmm....
 * xnox wonders where I lost those.
<infinity> Hrm, does it?
<infinity> Oh, maybe this is because I plugged it in before installing the packages.
<ogra_> that might be
<infinity> Nope.
<ogra_> iirc it is supposed to run root-less
<ogra_> so it needs the rules
<xnox> ogra_: no udev rules in android-tools-fastboot from the mirror. I think I may have lost them somewhere, as I sure have to be root when flashing =/
<ogra_> xnox, well, we could add them to fastboot
<infinity> No udev rule in the installer package either.
<xnox> ogra_: can you point me to where I can find those?
<infinity> I can fish my udev rules off my old laptop.
 * ogra_ is looking
<ogra_> SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e40", TAG+="udev-acl"
<ogra_> SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="d001", TAG+="udev-acl"
<ogra_> something like that shoudl work
<ogra_> probably even only the first line, the second one is for detecting the device in recovery mode iirc
<ogra_> (while the first one is for flash mode)
<infinity> Hrm, I seem to have misplaced my old android/fastboot rules.
<infinity> I guess the above works. :P
 * ogra_ goes for a break
<gurgalof> it would be nice witch hardware accel in firefox
<gurgalof> now it says "GLXtest process failed"
<gurgalof> in about:support
<mjrosenb> chrisccoulson: ping?
<mjrosenb> chrisccoulson: well, you'll find out soon enough :-p
<chrisccoulson> mjrosenb, hi, what's up?
<mjrosenb> chrisccoulson: ahh. i've heard that you are responsible for firefox on ubuntu/arm?
<chrisccoulson> i'm responsible for firefox. not specifically on arm though
<mjrosenb> ahh.
<mjrosenb> so, in about a month, we're going to be putting out 18, which will have ionmonkey as part of its js engine
<mjrosenb> and it doesn't have hardfp support yet.
<chrisccoulson> mjrosenb, it's still possible to run it on systems that provide hardfp though, isn't it?
<chrisccoulson> we have 18.0 builds already, and nobody has mentioned that they don't work yet :)
<mjrosenb> you'd need to either turn off the new jit, or grab the patch that i'll be landing today... for 20.0
<xnox> Can I force unaligned memory access on armhf port because a very silly application that wants unaligned memory access.
<mjrosenb> chrisccoulson: I'm not horribly surprised, since the calling conventions are the same for functions that only take integers or values
<xnox> And what are the consequences of unaligned memory access for other applications?
<mjrosenb> chrisccoulson: but they differ when passing doubles, and I suspect on pages like slashdot, you don't call math.pow() that frequently
<infinity> xnox: Uhm, what?
<infinity> xnox: Fix the silly code.
<chrisccoulson> mjrosenb, ah, i've just noticed there's quite a lot of test failures on our armhf builds
<infinity> Yeah, there would be.
<xnox> infinity: oh, it's not a bug, but an "architecture design feature" they load memory mapped files from disk and do loads of crazy things.
<infinity> xnox: Sounds like a bug to me, still.
<chrisccoulson> mjrosenb, hopefully we'll notice these in the future, as i'm working on exposing test results via https://jenkins.qa.ubuntu.com/ ;)
<infinity> xnox: Given the number of platforms that just plain Won't Work on, that's unportable to the extreme.
<infinity> xnox: And probably also slower on x86 than it needs to be.
<sfeole> morning
<mjrosenb> chrisccoulson: how are you running the tests?
<xnox> infinity: the package in question is mongodb =)))
<infinity> xnox: Yeah, mongodb in unportable code shocker.
<infinity> xnox: They're the same upstream that spent a year saying "we only support x86, cause everything else is toooo haaaard".
<chrisccoulson> mjrosenb, we're packaging most of the tests and running them on an installed system
 * xnox goes away to write some portable C
<mjrosenb> chrisccoulson: firefox has like 10 testsuites :-p
<chrisccoulson> mjrosenb, yeah, we're doing it with all of the xpcshell tests, reftests, crashtest, js tests and mochitests. but we run everything that normally runs during make check as part of the build
<mjrosenb> cool.
<mjrosenb> chrisccoulson: random note: I found that using gold with xpcshell on arm generated an xpcshell that is incapable of running.
<chrisccoulson> mjrosenb, ah, i've not tried using gold yet. i just build it with our defaults. thanks for letting me know though
<chrisccoulson> mjrosenb, so, i guess for pre-firefox 20 builds we should be using --disable-ion on armhf?
<mjrosenb> of course, it might just be something else related to my setup.
<mjrosenb> chrisccoulson: that is probably a good idea, unless you want to backport this patch.
<chrisccoulson> mjrosenb, i finish for the rest of the year today, so i'll probably go with the easy option for now :)
<mjrosenb> https://bugzilla.mozilla.org/show_bug.cgi?id=802358
<ubot2> Mozilla bug 802358 in JavaScript Engine "IonMonkey: (ARM) Add support for hardfp" [Normal,New]
<mjrosenb> there we go
<infinity> Reasonably simple patch.
<infinity> I'd go for backporting it so we can get some testing, personally.
<chrisccoulson> mjrosenb, thanks
<mjrosenb> chrisccoulson: not a problem.
<sfeole> ogra_: ping
<ogra_> sfeole, whats up ?
<sfeole> ogra_: hey, any word on the brcm-patchram for raring?
<ogra_> not sure yet, its an evil hack
<sfeole> is that being tracked somewhere in LP ?
<sfeole> just so i dont have to keep pestering you ;P
<ogra_> not that i know of, i know there was some upstream work to support patchram
<ogra_> bug 1065400
<ubot2> Launchpad bug 1065400 in linux (Ubuntu Raring) "Support for loading Broadcom bluetooth firmware" [Medium,In progress] https://launchpad.net/bugs/1065400
<ogra_> sfeole, ^
<sfeole> ogra_: sweet thx
<ogra_> it might need a newer kernel than we have on the nexus though
<kyleN_> ogra_, so we will hod our weekly un7 meeting in 50 minutes. mostly status updates.
<ogra_> yep, np
<kyleN_> thanks
<ogra_> nexus7 meeting is in #ubuntu-meeting right now
<ogra_> xnox, so originally i thought i would like ot keep the two file approach, simply to make manual flashing easier (having to unzip the img.gz is already annoying) .... but noticing that even infinity preferred the installer script i might reconsider my attitude here
<xnox> ogra_: I was chatting with vanhoof the other night. How about publishing just a single tarball, which has: individual bits to construct boot img + userdata squashfs.
<xnox> and then do the whole sparse image packaging client side & constructing the boot image.
<ogra_> i dont want to put to much local processing in
<ogra_> currently you could flash from windows
<ogra_> we would lose that opportunity
<ogra_> (or from fedora or suse)
<ogra_> so i prefer to have ready made images .... i donw mind to repack them on the fly, but the generic image we offer should just be flashable from any fastboot install you have imho
<xnox> ogra_: ok.
<vanhoof> ogra_: just trying to figure out the easiest way to resize is the tricky part, its easy w/ the tarball, suppose we could unpack/rebuild
<vanhoof> and /me didnt notice xnox was building -fsutils now (thanks xnox for the update in the ppa btw!)
<ogra_> right, we would need make_ext4fs
<xnox> ogra_: so a tarball of bootimg & userdata? can we still publish just the user-data tarball as well? (the way some images publish their inner squashfs)
<ogra_> ans simg2img
<ogra_> *and
<xnox> for the repacking to larger sizes, while still by default offering "flash & go"
<ogra_> xnox, well, i can just tar up both files in debina=cd, thats most trivial
<ogra_> *debian-cd
<xnox> ogra_: don't the simg2img require target space size (8GB?!) =/
<ogra_> not that much
<ogra_> its still a sparse img
<ogra_> but yeah. you require some space for repacking
<ogra_> and root
<ogra_> you need to loop mount the img, copy the tarball somewhere and call make_ext4fs on that
<xnox> ogra_: by "packing both files" do you mean  the download will be ~ double the current size and contain: bootimg, userdata.img, userdata-just-tarball?
<ogra_> bootimg and img.gz in one tarball
<xnox> ogra_: yeah, but I can't loop mount simg, and img is 100% the size.
<xnox> ogra_: ah, ok.
<xnox> ogra_: why .gz?
<ogra_> size ... :)
<ogra_> saves 100M
<vanhoof> saves ~100m iirc
<xnox> tar.gz: boot.img & img.gz
<ogra_> we wont need that if we wrap a tar.gz around it
<ogra_> i guess
<ogra_> i'll do some tests on the weekend
<ogra_> how much size differs
<ogra_> also note that i'm not sure the image will be flashable in its current state if you resize it
<ogra_> i fear it will get to big to be flashed without -S switch to fastboot
<ogra_> fo that we have a plan but nobody worked on it yet ...
<ogra_> (using tar.xz instead of tar.gz for the internal tarball(
<ogra_> doing that will need some work on cdimage/debian-cd that i wont manage to do before end of the year though
<xnox> ogra_: to what extend have you tried the bog standard mkfs.ext4 and tweaking it's settings? to the point that it doesn't ever work with img2simg, or it's too big, or you tried every mkfs.ext4 option to try to reduce the size and it was still too big?
<ogra_> its way to big
<xnox> ogra_: tar.xz is interesting.
<ogra_> like 200m bogger than fsutils
<ogra_> *bigger
<xnox> argh.
<ogra_> i think the tar.xz way is best
<ogra_> but for that we need to re-write the image creation stuff quite a bit
<ogra_> (xz compression is to slow to run on the live builder, builds already take over 2h)
<ogra_> (currently the whole build is done by live-build, we need to move 50% out of that and into debian-cd)
<ogra_> xnox, i think targeting the usb-creator bits for alpha2 should be fine and not put to much pressure on us
<ogra_> until then vanhoof's installer will serve us fine
<ogra_> (A2 is due on feb 7th)
<ogra_> sfeole, hmm, was that mail actually supposed to go to canonical-tech ? (sounds more like it was intended for ubuntu-devel tbh)
<sfeole> ogra_: I don't think it hurts sending to canonical-tech, I was just doing it as a general announce. There have been many emails like that in the past to CT.
<ogra_> well, i think we should make the info a bit more widely known :)
<sfeole> ogra_: Sure! I will forward to ubuntu-devel as well
<ogra_> ++
<sfeole> :P
<sfeole> enjoy your vaca btw
<sfeole> have a safe rest-of-2012
 * ogra_ will blog on the weekend so it goes on planet as well
<ogra_> heh, dont think you will get rid of me for the rest of the year :)
 * ogra_ will be around on IRC and surely work on non work related projects
<ogra_> i dont really feel like doing vacation ... its just a formal thing to burn the days
<vanhoof> ogra_: you never know, the mayan's could be right ;)
<tassadar_> they just used too small data type for their timestamp
<ogra_> lol, yeah i was saving the buying of xmas presents for the 22nd this year
<ogra_> just to be sure
<vanhoof> best idea i heard all day!
<infinity> *snicker*
<achiang> vanhoof: hi, i'm lazy and jetlagged. where can i download a copy of the installer that would run on precise? :)
<vanhoof> achiang: same place as always
<vanhoof> apt-get install ubuntu-nexus7-installer
<vanhoof> you'll get 1.7~p
<achiang> rad
<vanhoof> the ~{p,q,r} are just rebuilds of the same bits for diffrerent series
<vanhoof> so anyone can install from the ppa
<vanhoof> sfeole and bjf asked that I upload a ~r today
<achiang> ah, i don't have the ppa in sources.list
 * achiang goes to download the .deb :)
<infinity> vanhoof: When is the installer going to switch to installing raring by default?
<vanhoof> infinity: 8 hours ago
<infinity> Hah.
<vanhoof> :)
<infinity> Nice.
<infinity> Did you update the wiki to reflect that?
<vanhoof> infinity: believe sfeole did, but ill check
<infinity> Yup, apparently so.
<infinity> Though, it now has "Installing 13.04" twice.  Maybe the second section should have a "Manually" prepended. :P
<vanhoof> infinity: figured w/ the changes that landed today, its a good time to move folks to raring for new installs vs the quantal image at UDS
<LisaNori> Been using raring images for a few days now.  It's quite usable and will be even more so once that button1 stuck bug is fixed.  :)
<infinity> The raring images should get much more responsive as of my initscripts change earlier this morning.
<achiang> infinity: what changed there?
<infinity> http://launchpadlibrarian.net/125105308/sysvinit_2.88dsf-13.10ubuntu13_2.88dsf-13.10ubuntu14.diff.gz
<infinity> Android kernels have a shiny new governer that behaves a bit more pleasantly than ondemand.
<infinity> Kinda hoping this lands in mainline sometime, my laptop would be much happier.
<achiang> interesting. upstream has been recommending ondemand for a long time
<infinity> Which upstream?
<achiang> lkml?
<infinity> Well, lkml isn't really relevant here, interactive isn't in mainline.
<infinity> ondemand is the best we've got on non-Android kernels.
<achiang> infinity: did you test interactive vs ondemand for power consumption?
<infinity> No, if it proves horrible, we can revert.
<vanhoof> achiang: got some feedback from our 32G+3G folks as well, they're happy with 1.7 as well
<infinity> It's the default governor on most Android devices, though, and they seem better at power than we are. :P
 * achiang just has latent suspicion of all governors !ondemand but maybe that's outdated knowledge by now
<vanhoof> infinity: if you give a new install a whirl lmk
<infinity> vanhoof: Probably not today.  I've been up and working since midnight or so. :P
<vanhoof> yeah i know i slept last night but i swear you're in every hour of scrollback somewhere :)
<infinity> I try for 24/7 coverage.
<vanhoof> infinity: well you made diwic happy w/ his pa upload today :)
<vanhoof> so infinity++ :D
<achiang> cool, from 0% to 12% battery. maybe i can try an install now :)
<vanhoof> achiang: lmk how it goes
#ubuntu-arm 2012-12-08
<achiang> vanhoof: all went well, going through oem-config now
<vanhoof> cool
<vanhoof> i got through it no probs a few times
<vanhoof> you should be all set
<vanhoof> achiang: screen /dev/ttyACM0 115200 ... once you're done
 * vanhoof is in heaven
<achiang> what's that, debug console?
<vanhoof> yup
<vanhoof> usb/serial
<vanhoof> full console even
<achiang> whee, i'm on R
<achiang> machine name is 'mfer'
<achiang> ;)
<vanhoof> lol
<achiang> what's new and shiny for me to play with?
<vanhoof> plymouth, usb-serial, an actual panel, oem-config? :)
<achiang> ah, the answer is "nothing" because i hit the button1 stuck issue
<achiang> feh
<vanhoof> you're landscape?
<achiang> yeah
 * vanhoof must have small fingers
<vanhoof> i dont hit that often :)
<vanhoof> achiang: if you get bored play w/ sound
<vanhoof> i had some troubling noises today playing radio w/ rb
<vanhoof> not sure if its my own breakage
<vanhoof> achiang: but now you have dailys to flash ;)
<achiang> from here on out, it's dist-upgrade every day, baby
 * sfeole reads scrollback
<sfeole> achiang, vanhoof , infinity : Yea guys, I went on a wiki updating rampage today. sort of sloppy but got the job done. Everything should be up there, updating instructions / new features / some bug updates etc...
 * sfeole goes back into his cave
<sfeole> also i fixed the 2nd heading for installed 13.04 on the nexus7, looks like my draft never saved.
<sfeole> it now says "Manually Installing... blah blah"
<wookey_> infinity: I see you fixed tcl crossing. What did you do about multiarching the tclconfig.sh path?
<infinity> wookey_: I didn't touch tcl, just tk.
<wookey_> Or did you just fix tcl bulding itself, not anything building against it?
<infinity> wookey_: Though, tk builds against tcl, so maybe someone already fixed the thing you're talking about.
<gurgalof> aww, I want to run 13.04 on the nexus, but I need Bluetooth...
<wookey_> OK. That would be good if true - I've beenwondering what to do about it for months :-)
<wookey_> I see you had a go at apr too - is there a bug for that? It was an abomination when we looked at it a couple of years back
<wookey_> somebody tried to add cross-support but did it in a completely broken way
<infinity> wookey_: I'm holding off on filing bugs (or committing directly) to apr/apr-util/apache2 until I'm happy with my "solutions" (and I use that term loosely).
<infinity> wookey_: apr and apache2 work in Ubuntu now (apr-util needs some twiddling with libraries it links to), but neither is pretty, so I'll likely revisit.
<wookey_> I have a really long mail for the apache people that we weren't allowed to send a couple of yrears back, asking what tey thought they were _trying_ to do
<wookey_> so we could work out how to fix it properly
<infinity> http://launchpadlibrarian.net/124947530/apr_1.4.6-3_1.4.6-3ubuntu1.diff.gz
<infinity> ^-- The ugly is just a bunch of autoconf cache preseeding.
<infinity> But there's got to be a less hideous way.
<infinity> As for apache2 itself, it's all fixed upstream, I just had to backport patches.
<wookey_> Ah cool
<infinity> (And fix debian/rules to be less retarded)
<infinity> So, I'll probably commit the apache2 stuff to Debian (or file a bug and make sf do it), but the apr/apr-utils things need some thought, I think.
<infinity> And, really, apache is useless without apr, so...
<raster> mooo
 * Tassadar hides the gnomes
<raster> i'm not here to gorge on gnomes today
<raster> yargh
<raster> what is the magic to get sound out of this little beastie
<Tassadar> You mean n7?
<raster> yeah
<raster> i have gotten it to hiss at me
<raster> and thats about it
<raster> yes - i know - suspend and resume
<raster> doesnt do squat
<raster> i've been swizzling everythng randomly in alsamixer for a while to try see what low-level knob makes it work
<marvin24> nvidia just published tegra boot process description: ftp://download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html
<marvin24> (for those who didn't got it yet)
<raster> nv is getting better at this
<RaYmAn> sadly, it's not much use on most 'real' devices (given they are locked mostly down), but it's a nice move either way
<raster> not much nv can do there
<raster> thats oems
<RaYmAn> indeed
 * RaYmAn looks at google
<raster> i have a working nexus7
<raster> minus sound
<raster> i cant divine how to make it peep
<RaYmAn> raster: it's just a pity e.g. google makes the n7 unlockable and then locks down the bootloader still. :/
<raster> well to some extent thats to avoid bricking
<raster> oems are paranoid about having hoards of users send in bricked devices under warranty
<RaYmAn> tegra is unbrickable if you have access to APX mode (e.g. tegrarcm)
<marvin24> well, there is still the rom bootloader, which cannot be bricked by nature
<marvin24> on the other hand, who cares if the locked bl can load an unlocked one?
<raster> if a user cant boot it to a state of a ui withotu some cruptic pc tools
<raster> then its a brick
<raster> form an oem pov
<raster> fastboot is not an answer in their eyes
<marvin24> write a simple tools then
<raster> it has to be unbrickable without tools
<raster> ie withotu needint to plug it into a pc and "use tools"
<raster> same with plugging in special mucro-sd cards with rescue images etc.
<RaYmAn> but how is that different from now? users could easily perceive it as bricked even if they have fastboot.
<RaYmAn> and that is possible now
<raster> dont they stil lock the bootloader down
<raster> but the rest u can play with as u like
<lilstevie> flash a non working kernel to both boot and recovery
<raster> so long as u use the bootloader to boot it
<raster> ala the ubuntu nexus77 images
<RaYmAn> lilstevie: isn't that fixed on n7?
<lilstevie> and it will be in the state you just called a brick
<lilstevie> RaYmAn, yeah, n7 also uses scratch rather than msc for bootloader messages
<RaYmAn> hm
<lilstevie> RaYmAn, but I am referring to "<raster> fastboot is not an answer in their eyes"
<RaYmAn> did you test if that works on tf201?
<lilstevie> RaYmAn, I did not
<lilstevie> RaYmAn, it is in the shutdown kernel code
<raster> lilstevie: i work for an oem
<raster> if ti requires anything more than absolute basic knowledge to fix
<lilstevie> raster, still doesn't change the fact, even unlocking a device will cause the definition you just called "brick"
<raster> (press a reset button for example) it's undesired and everything is done to avoid it
<raster> problem is a reset button is also aloiability in normal use
<raster> lilstevie: yes - its a risk google has pushed asus to do
<lilstevie> raster, that asus also offer on their entire tegra 3 range
<raster> prbably so google can use the n7 itself for hacking as well as allow others to do custom android roms and otherwise spread android around in general
<RaYmAn> raster: tbh, if oems wanted to get around that, it *should* be possible to hook up boot strap pins in such a way that it can boot a special (signed) image incl. bootloader from sdcard. Then a win app that writes the sdcard
<RaYmAn> also, they could just charge to fix bricks that could be fixed with e.g. nvflash if it was available
<raster> RaYmAn: you expect them to figure out all for a tiny percentage of their customerbase
<raster> when they can just continue with the old solution they have used for many years
<RaYmAn> nah, I've lost faith in them bothering to do such stuff long ago
<raster> so have most
<raster> :)
<RaYmAn> though, it would probably cut down on software repair costs =P
<RaYmAn> anyways, your argument was that e.g. nvflash was too complex for normal users (I disagree) - there's plenty of ways they could make it simpler
<raster> u are free to sit in meetings with some taiwanese, korea, etc. ppl and make your argument
<raster> :)
<RaYmAn> I don't expect an invitation any time soon
<RaYmAn> ;)
<raster> i've been there, done that... many times over the years :)
<raster> and i get the bonus of the "listen to me" badge onmy chest
<raster> even then its insanely hard
<lilstevie> although they may have to soon if the sony tool thing catches on
<raster> the things that make themj move.. is if someone else moves
<raster> and if it means market share gain, profits or somethnig
<raster> that gets attention
<RaYmAn> yeah, that's a pretty decent way of doing it - nice and semi-userfriendly tool that installs drivers and reflashes devices. It would be fairly easy for e.g. asus or google to do something similar with a custom nvflash for n7
<RaYmAn> raster: incidentally, it's amusing they spend so many resources on locking down things. You'd think it would be less resources to just make it open :)
<gurgalof_mobil> i flashed raring using the tool in ubuntu,  but i only get a 8GB partition on my 32GB nexus7
<raster> RaYmAn: the locking down has already been done and it was a product requirement from the product specs team to begin with
<raster> or something like that
<gurgalof_mobil> and i have a black bar under the notification bar in raring
<RaYmAn> raster: it's a choice e.g. google makes. Of course it has already been done, but it's still a choice they made
<RaYmAn> and then you have stuff like the arm chromebook which is completely open/unlockable.
<raster> a choice made by a product specs dept that doesnt knowq nor care about hackers/development
<raster> as they are not
<raster> they expect the o9nly development happens inside this engineering dept they have
<raster> and nowhere else
<RaYmAn> I somehow doubt google is that naive
<raster> people wanting to hack on their PRODUCTs is a bizarre foreign concept to them
<raster> raster: did i not mention oems above?
<raster> not google?
<raster> :)
<RaYmAn> google is essentially an oem too :)
<raster> well since they bougt moto - sure
<raster> tho within large companies its not so simple
<raster> its a lot of hops from left to right hand
<raster> :)
<gurgalof_mobil> is everyone sleeping?
<smartboyhw> gurgalof_mobil, NO
<gurgalof_mobil> :D
<gurgalof_mobil> feels like no one notices me, but ill ask again later...
<gurgalof_mobil> hmm i didnt even write a question, well well
<ogra_> gurgalof_mobil,  the current ikmmge only uses a 6G partition, we're working on getting it to work for bigger devices too, the broken panel shadow is known and reported as a bug already
<ogra_> *image
<gurgalof_mobil> okay,  thanks
<gurgalof_mobil> i'll revert to quantal for the moment then
<ogra_> raster, do you use pulse in youir setup ? iirc fixing the sound was a combo of alsa UCM profiles and pulse profile changes
<raster> yup
<raster> pulse is there
<gurgalof_mobil> oh and the slideshow in raring says 12.10
<infinity> gurgalof_mobil: It usually does for the first few months.
<raster> i use it on all y setups
<raster> hell
<raster> my mier eeven detects pulse and is happy
<infinity> gurgalof_mobil: It'll say 13.04 before release. :P
<ogra_> raster, also note that the master is muted by default ... only suspend/resume isnt enough
<raster> yup
<raster> i checked
<raster> :)
<gurgalof_mobil> :P hopefully
<raster> pulse is unmuted
<raster> rhythmobx doest play
<ogra_> hmmm, then i dont know
<raster> aplay doesnt play (bypassing pulse going right to alsa)
<ogra_> it works flawless under unity for me
<raster> weird
<ogra_> boot, suspend/resume, hit vol-up omce (easier than unmuting) always gets me sound
<raster> i didnt get to test audio until i had the rest settled
<infinity> ogra_: That's an odd definition of "flawless". ;)
<ogra_> heh
<ogra_> well, "as described" :)
<infinity> Thou shalt swing the mutilated chicken thrice above thine head, whilst chanting "ALSA, our lord, hear my prayers."
<ogra_> *giggle*
<raster> ogra_: yaaargh
<raster> any info as to.. what this magic pulse + alsa magic was?
<ogra_> ask diwic during the week
<raster> ok
<raster> either way
<raster> suspend/resume is all happy now
<ogra_> he is our sound guru and added the fixes
<raster> it was wifi simply not being shut off before suspend
<ogra_> ah
<raster> u have to rfkill it or it gens wake interrupts
<raster> :)
<raster> my screen is all nicely portraited now
<ogra_> yeah,, the pm-utils scripts care for that iirc
<ogra_> portrait with working input ?
<raster> i tried the 6.1-7 xorg thing and it fixes some of the funkiness of the touch when in portrait
<raster> yeah
<ogra_> oh, sweet
<gurgalof_mobil> in quantal BT stays on while suspending as moving bt-mouse unsuspends it
<raster> tho the pointer jumps around like its obsessed
<raster> inptu works tho
<ogra_> you have a pointer ?
<ogra_> unity/compiz hides it if there isnt an actual mouse
<ogra_> (that hides such issues)
<raster> yeah
<raster> i haveth one
<raster> i can hide it if i want
<raster> i just like seeing it
<raster> its kind alike a nice debug thing
<raster> :)
<raster> i'm down to 180m of mem usage
<ogra_> heh, yeah
<raster> for some reaosn my mystery missing ram... comes back after some time
<ogra_> i think there are some oddities with the kernel
<raster> definitely
<raster> like on boot - 420m ram gone
<raster> i compile a bunch of stuff
<raster> suspend/resume a few times
<ogra_> it also shows some strange load values that i cant really confirm
<raster> restart wm etc.
<raster> and it goes DOWN.. to about 150-200
<raster> oh yeah
<raster> and DONT use powertop
<gurgalof_mobil> WAT
<raster> it somehow turns off the cores
<raster> and makes u have only 1 core
<ogra_> file a bug !
<raster> everything nicely slows down to a crawl
<raster> :)
<ogra_> that should definitely be fixed
<raster> i'll kick arjan next i get the chance
<ogra_> great
<raster> :)
<raster> rightr now.. i dont know what it did
<lilstevie> you should confirm that is powertop that did it
<raster> i was compiling at the time
<raster> lilstevie: certain - i was runing htop at the time
<raster> and i rant it
<lilstevie> I've come across that exact issue as a kernel bug on the tf201
<raster> and then immediately everything jumpt to a single core
<raster> it has never happend otherwise
<raster> so far anyway
<lilstevie> raster, lather rinse repeat
<raster> busy lathering a lot of other things
<raster> :)
<lilstevie> I've never been able to trace the exact moment before, but I have never run powertop
<raster> they were too suspiciously timed together
<raster> i dont know if its pt's bug tho
<raster> it may simply innocently do something that happens to trigger the kernel bug
<raster> these things happen :) i'm rather used to them
<lilstevie> someone else should probably try the above on a n7, cause if it is the case, it is n7 specific and doesn't affect T3 in general
 * lilstevie just tested
<raster> i only have the n7
<raster> so...  :)
<lilstevie> well then :p reproduce
<raster> \would love to
<raster> but i'm busy with.. other fun
<raster> like nixing backlight artifacts
<gurgalof> where do i find the 12.10 nexus7 image?
<gurgalof> or can i resize the partiton to 32GB? instead of 6?
<Tassadar> http://hwe.ubuntu.com/uds-r/nexus7/
<krawi> hi all
<krawi> can someone give me a hint for alsa playback on pandaboard with ubuntu 12.04 server?
<krawi> in syslog: OMAP ABE Media: asoc: OMAP ABE Media no valid playback route from source to sink
<krawi> in mplayer [AO_ALSA] alsa-lib: pcm_hw.c:1293:(snd_pcm_hw_open) open '/dev/snd/pcmC0D0p' failed (-22): Invalid argument
<krawi> and nothing is played
<krawi> one step foward
<krawi> now it is: omap_hwmod: aess: _wait_target_disable failed
<krawi> got it
<gurgalof> can i resize the partition on my nexus7 with gparted?
<gurgalof> or is there some other way?
<gurgalof> why do we have swap enabled in 13.04 on nexus7?
<gurgalof> I think everyone is sleeping again...
#ubuntu-arm 2012-12-09
<Ethernin> Hey guys, anyone played with multitouch stuff on Nexus 7 running ubuntu?
<Ethernin> when i search the repos for multitouch i find:
<Ethernin> xserver-xorg-input-mtrack - Multitouch X input driver
<Ethernin> xserver-xorg-input-multitouch - Multitouch X input driver
<Ethernin> also wondering if magick-rotation is worth the trouble?
<Ethernin> would be siiiiiiick
<Ethernin> I've got things running pretty darn well with XFCE4, but it would be nice to actually use the touch screen effeciently
<Ethernin> one of the problems is by default you can drag the windows around or maximize or close the windows via touchscreen....
<Ethernin> which is pretty lame considering it works so well in gnome-classic and lxde ect
<Ethernin> holla?
<Tassadar> don't worry, there are people still awake and coding, but as for me, I did not really tried multitouch on n7)
<Tassadar> *haven't...dammit 1AM
<Ethernin> lol
<Ethernin> right on thanks man
<Ethernin> Tassadar, it's usually 1am here and im the only one ranting!
<Ethernin> lol
<Ethernin> yeah i saw some sweet links of people using it, not on the Nexus7 but i thought id give it a try
<Ethernin> going to look up the system requirements to see if it's even doable
<Ethernin> but i figure it should be
<Tassadar> it must, on android it can handle up to 10 fingers
<Tassadar> or at least 10 fingers, because I don't have any more to test
<Ethernin> hahahaha
<Ethernin> totally
<Ethernin> i've been messing with a lot of different desktop environments trying to find one that's both stable and usable
<Ethernin> unity is just too damn slow, and i haven't been able to get unity2d to work
<lilstevie> Ethernin, there isn't really much point in those packages, evdev does multitouch, you just need a wm that supports it
<lilstevie> unity2d doesn't exist anymore
<Ethernin> i did however try, xfce4, lxde, and gnome-classic via fallback
<Ethernin> yeah no kidding
<Ethernin> not in raring that's for sure
<Zero_Chaos> evdev does multitouch? but how to enable it?
<Ethernin> evdev?
<Zero_Chaos> Ethernin: it's the main keyboard and mouse xorg driver
<lilstevie> Zero_Chaos, you don't need to enable it, it already tracks multiple fingers
<lilstevie> Zero_Chaos, you need a part of the windows manager to track
<Zero_Chaos> lilstevie: ahh
<Ethernin> lilstevie, awesome what part of the windows manager ?
<lilstevie> Zero_Chaos, or something like utouch-geis
<lilstevie> Ethernin, I'm not sure, I don't care enough
<Ethernin> lilstevie, sweet, ill look around
<Zero_Chaos> Ethernin: search for utouch and have fun.
<Zero_Chaos> Ethernin: I'm going to five guys
<Zero_Chaos> :-)
<Ethernin> hahaha nice Zero_Chaos
<Zero_Chaos> bbiaf
<Ethernin> Zero_Chaos, yeah going to take a break myself
<Ethernin> Zero_Chaos, ill be back in a bit
<Ethernin> ah yes, xserver-xorg-input-multitouch - Multitouch X input driver comes up
<davecheney> why does zentiy installer use 100% cpu while running ?
<davecheney> is this ia bug
<davecheney> or just one of those things ?
<davecheney> lp #1077973
<ubot2> Launchpad bug 1077973 in ubuntu-nexus7 "zenity consumes about 100% CPU when installing Ubuntu on nexus 7" [Low,Triaged] https://launchpad.net/bugs/1077973
<davecheney> after flashing with the 1.7 installer to raring
<davecheney> and waiting for the disk resize to complete
<davecheney> i am greated with random video corruption
<davecheney> just static on the screen
<davecheney> any suggestions ?
<Julle131> I'm trying to make a kernel boot android 4.1 and Ubuntu. Got any tips? I'm a beginner.
<Julle131> There is a kernel that can boot Ubuntu for my device, and a kernel that can boot 4.1. But no kernel that can do them both.
<lilstevie> some things required for android break ubuntu, and vice versa
<Julle131> Well, I keep looking then. I don't know does these matter, but the board is OMAP 4460 and kernel version is 3.0.8+ for both kernels.
#ubuntu-arm 2013-12-02
<chrs_> i'm tring to get the mesa demos source code into my chromebook
<chrs_> apt-get source mesa-demos isn't work
<chrs_> source package not found
<chrs_> i can clone the git repo, but i wanted to install via apt-get
<chrs_> i don't know why it isn't working, the mesa-demos binary package installed fine
<chrs_> whoops, forgot to add deb-src to my sources.list
#ubuntu-arm 2013-12-03
<digitlman> does this channel cover picuntu?
<digitlman> or any other arm-based ports?
<k1l_> this is for general ubuntu arm development. but for own ports it might be better to ask the specific guys that build that port
<digitlman> ok
#ubuntu-arm 2013-12-04
<kjsa> what is the cheapest TI omap processor that can run ubuntu-server?
<suihkulokki> kjsa, probably the one in beaglebone black
<kjsa> thank you
<kjsa> suihkulokki, I read that it uses AM3358 and I search its price on mouser and the cheapest one is this one http://se.mouser.com/ProductDetail/Texas-Instruments/AM3358ZCZD72/?qs=sGAEpiMZZMtMbLhITnKwtwIIYllslySK which is 31.6 euro and begleboard black is almost about that price :) of course beagleboard is produced in a large volume
<kjsa> above 500 unit is 25.55 euro, it is still expensive
<kjsa> am I checking the wrong processor or how it is possible to produce beagleboard black that cheap
<kjsa> and the producer also adds profit margin
<suihkulokki> kjsa, you will have to ask someone else, i'm not privy to exect pricing details
<suihkulokki> you can try asking on #beagle , i think the bom is available
<kjsa> I will do that, thank you. I have one more question that I am curious about. I would be glad if you can reply that one as well
<kjsa> I see some open source hardwares that uses arm processors and run linux
<kjsa> if I produce such board by myself, do I need to program the CPU
<kjsa> to run linux?
<suihkulokki> these cpus are already supported by linux, so you would only need to programm support for your own hardware on the board
<kjsa> thank you
#ubuntu-arm 2013-12-05
<sveinse> Is it http://ports.ubuntu.com/ubuntu-ports which still is the official repo for armhf?
<ogra_> yes
<sveinse> I'm trying to install some dev tools into a armhf build server and I find that some packages like kpartx, genisoimage and even debootstrap does not exist in armhf
<sveinse> I wonder if missing deboostrap be related to missing binfmt-support
<sveinse> I though you guys aren't bootstrapping on intel for arm[el|hf] anymore, and are doing all native. How do you do that without debootstrap?
<infinity> sveinse: debootstrap isn't missing.  In fact, none of those packages should be.
<infinity> sveinse: Yeah, they all look available to me.  I suspect your sources.list is a bit confused.
#ubuntu-arm 2013-12-08
<LiuKangWins> hey guys, is this where i could get some assistance with lubuntu arm?
<LiuKangWins> anyone? bueller?
<LiuKangWins> i have a login loop problem with my arm lubuntu on a tab, anyone else had this problem?
<yairabr> hii im trying to wrine ubunu on an sd card for beaglboard-xm (new user), but after unzipping the image file i get an .raw file shouldnt i get .img file?
<yairabr> ?
<yairabr> hii im trying to wrine ubunu on an sd card for beaglboard-xm (new user), but after unzipping the image file i get an .raw file shouldnt i get .img file?
<infinity> yairabr: Not really an Ubuntu question, since I assume that image didn't come from us.
<infinity> yairabr: But the filename really doesn't matter.
#ubuntu-arm 2014-12-05
<abiogenesis> Hi guys. I have Ubuntu 14.04 with custom 2.6.35 kernel. I have noticed that systemd-udevd process uses 100% CPU. Any hints?
<abiogenesis> All packages are upgraded
<abiogenesis> strace -p <pid of udevd> shows infinite loop of this: accept4(3, 0, NULL, SOCK_CLOEXEC|SOCK_NONBLOCK) = -1 ENOSYS (Function not implemented)
<abiogenesis> ok...fixed by patching the kernel as suggested here http://unix.stackexchange.com/questions/78385/udevd-eats-too-many-cpu-cycles
#ubuntu-arm 2015-11-30
<imjacobclark> All, why is it that register 7 of an ARM11 has to be used for a syscall number?
<imjacobclark> mov r7, $1
<imjacobclark> Why is it mov r8, $1 would not work, is r7 reserved for sys calls?
#ubuntu-arm 2015-12-01
 * alimj looks at the topic, wonders if Raspberry Pi 2 is ARMv7?
<alimj> Anyone using this? http://www.hardkernel.com/main/products/prdt_info.php
<ikonia> it is
<alimj> Looking for a simple SBC for light GUI bases apps. e.g. Web browser with few open tabs
<alimj> less than $100
<alimj> XFCE desktop
#ubuntu-arm 2015-12-02
<alimj> Such an active channel. I ask about ARM based SBCs and do not get an answer after 24 hours :-/
#ubuntu-arm 2015-12-04
<regum> hello everyone
<regum> Is there a clear step by step way to connect to wifi with wpa from the terminal?
<regum> I've been trying to do this for quite some time but nothing seems to work
<regum> I've got ubuntu arm running and I can't use a gui, for some reason the system stops detecting the usb wifi stick if I do
<regum> so I need to do everything from the command prompt
#ubuntu-arm 2017-12-06
<raph0x> hello, I've written Ubuntu Server Precise Pangolin 12.04 prebuilt OMAP4 image to an SD card to boot on my pandaboard, it booted, but it goes to login screen and I hav eno idea which is the password for ubuntu prebuilt images
<genii> Try: ubuntu without a password
<genii> alternately, ubuntu and ubuntu
#ubuntu-arm 2017-12-08
<ColdKeyboard> I would like to be able to take pictures with Pi Cam V2 as fast as possible. Right now raspistill takes ~1s, which is relatively fast but not enough. What would you guys suggest? Should I get more familiar with camera interface and try to write low-level stuff to optimize camera, should I look at some existing libraries or there is already a piece of code that would alow me to do this?
<rbasak> ColdKeyboard: try http://picamera.readthedocs.io/. If that can't do it, I suspect nothing can.
<rbasak> It's pretty low level.
